Bug 19575 – core.cpuid not usable without a runtime

core.cpuid relias on static shared this() for initialization. Without a D runtime, such initializers are never called. So we had to duplicate core.cpuid. It goes further, as rounding mode in Phobos uses the runtime variable `sse` from `core.cpuid`. Again, this makes FloatingPointControl not usable Why do I need `FloatingPointControl` in -betterC? I'm implementing intel-intrinsics for both DMD and LDC, and the slow compatible path has to have the same rounding-mode. But `intel-intrinsics` package is intended to work in any situation, with or without runtime. ***The only thing needed is a way to initialized core.cpuid with a function call.***

BetterC CPUID library. Bugs, if any, will be fixed quickly. https://github.com/libmir/mir-cpuid It is constructed with C runtime constructor, not shared static this. Also, you can call extern(C) mir_cpuid_init manually.

Well I want to use the core.cpuid in druntime, not the one in a library rewrite. I also use a library rewrite, but other parts of Phobos are affected by this lack of core.cpuid Besides other problems of mir.cpuid: - it depends on mir-core - ...with a dependency version version="<0.3.0" which precludes bugfix for new compilers, why not use ~> In SemVer major version 0 means "unstable" which means mir-core doesn't have a stability guarantee? If it has, please tag a v1.0.0 - mir-core and mir-cpuid are tested with current/latest LDC and DMD but I do use older compilers all the time. I can't depend on a DUB package that will break compiler that are less than one year ago.

1. mir-core v1.0.0 has been tagged. 2. Please specify compiler vendors and the oldest versions you need for mir-cpuid. I will try to add support for them.

Well I don't promise to use Mir, but currently as an industry user I use: - LDC 1.8.0 (released Mar 4, 2018 so not that long ago) - and support equivalent DMD so v2.078.3 or later This goes for all my open source libraries (intel-intrinics, printed, gfm, dplug...) It's a bit of work, but is reassuring for library users. It also force you to avoid newer D features which are usually a bit buggy or full of traps for GUI. Besides, you can build with many compilers which derisk things. When there is a major versions I deprecate a bunch of compilers, issue a major Semver tag (because this is a breaking change), and write a changelog entry. I feel that the D ecosystem would flourish if depending on a DUB library was completely hassle-free.

@WalterBright updated dlang/dmd pull request #14671 "fix Issue 19575 - core.cpuid not usable without a runtime" fixing this issue: - fix Issue 19575 - core.cpuid not usable without a runtime https://github.com/dlang/dmd/pull/14671

dlang/dmd pull request #14671 "fix Issue 19575 - core.cpuid not usable without a runtime" was merged into master: - 63efd5f3e093e97733546f1b7c0a85882c316526 by Walter Bright: fix Issue 19575 - core.cpuid not usable without a runtime https://github.com/dlang/dmd/pull/14671