XMGLOBALCONST poorly initialized when used within a cpp modules project

[MartinDew]

I've been using directx on a personal project that uses modules and had crashes because some of the XMGLOBALCONST declared constants simply don't have the proper values at runtime. In our case it was specifically g_XMInfinity and g_XMOneHalf (The values were 000). The crashes were caused by asserts failing on XMIsInfinity, among others, due to those.

In our case, we use DXTK and simplemath and import it through a Module partition with the following syntax : export import <SimpleMath.h>.

It looks like it has something to do with how __declspec(selectany) reacts when used within modules.

Are we right or is there something we are missing?

Thanks!

[walbourn]

Can you link to how you are building the SimpleMath module?

[walbourn]

It might also be a good idea to open your project in VS, and use https://aka.ms/vsfeedback or the "Report a problem..." link. This seems like a bug in the compiler or linker.

[MartinDew]

Can you link to how you are building the SimpleMath module?

Not sure if it's what you meant but I am using MSbuild and a VS project. We're using https://github.com/ubisoft/Sharpmake to create our sln and proj files.

[MartinDew]

Update : I ended up importing DXMath as source into my project and switching the XMGLOBALCONST to be static constexpr fixes the problem.

[walbourn]

Can you check the code-generation when using static constexpr. Does it look like it's coming from a shared read-only datasegment, or are you getting a lot of copies of the same data in each module?

[walbourn]

Also it does not appear there is any standard define to know if its being used in a C++20 module or not.

Note you DO NOT have the modify my source. You can use #define XMGLOBALCONST static constexpr before including the headers.

If I were to change the source, I'd probably have to go with (assuming C++20 code gen is not worse with it)

#ifndef XMGLOBALCONST
#if __cplusplus >= 202002L
#define XMGLOBALCONST static constexpr
#elif defined(__GNUC__) && !defined(__MINGW32__)
#define XMGLOBALCONST extern const __attribute__((weak))
#else
#define XMGLOBALCONST extern const __declspec(selectany)
#endif
#endif

My main concern is that math-heavy code would end up with many copies of the constants instead of just one.

[MartinDew]

Sorry for the late reply and thanks for your help!
I wouldn't honestly know if it causes any more copies.
I think that any new variable copying one of the constants would create a copy, but any static constexpr should be there only once in the compiled binaries.

[MikeMarcin]

How about defining it as inline constexpr?

[MartinDew]

That could probably work.

[walbourn]

As a quick look, it appears inline constexpr works, but I'm not sure how to robustly tell as a preprocessor symbol WHEN C++20 modules are being built vs. not. __cpp_modules is always defined for MSVC C++20, and in clang it's not defined unless you #include <version> first.

Note that for now a workaround is:

#define XMGLOBALCONST inline constexpr
#include <DirectXMath.h>

Is there a standard preprocessor symbol that I could use to know if the header is being used in a C++20 module?