Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix use of undeclared identifier __cpuidex error on MinGW #92488

Merged
merged 1 commit into from
Jun 7, 2024

Conversation

TCROC
Copy link
Contributor

@TCROC TCROC commented May 28, 2024

This change requires the target to be msvc in order to reference the method __cpuidex. The reasoning is due to a breaking change that appears to have come into effect recently across all major c / c++ compilers. Details are as follows:

LLVM, Zig (which uses LLVM under the hood), and GCC all recently updated their compilers changing what was a warning to an error. The compiler will now error if attempting to reference __cpuidex and not targetting msvc. It will no longer work for MINGW targets.

Here are relevant docs / source code for reference

Discovered by @Rexicon226, here is the LLVM code and how it handles it:

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Support/BLAKE3/blake3_dispatch.c#L46-L60

Another helpful zig dev who's discord username is "random internet person" found: https://github.com/ziglang/zig/blob/master/lib/zig.h#L3902-L3913

Which appears similar to LLVM's new implementation.

And GNU posted a more formal announcement notifying of the warn to error change that appears to have propagated across all major compilers recently: https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors

Shoutout to @paperdave for all the help and guidance along the way! :)

@TCROC TCROC requested a review from a team as a code owner May 28, 2024 19:42
@TCROC
Copy link
Contributor Author

TCROC commented May 28, 2024

For further clarification. The warning-to-error is not specific to __cpuidex. That is one of the effected methods. Through conversation in the zig discord, I believe it has to do with no longer allowing implicit function definitions at compile time. Fortunately this is the only affected spot I've found so far.

@akien-mga akien-mga added this to the 4.3 milestone May 28, 2024
@akien-mga akien-mga added cherrypick:3.x Considered for cherry-picking into a future 3.x release cherrypick:3.5 Considered for cherry-picking into a future 3.5.x release cherrypick:4.1 Considered for cherry-picking into a future 4.1.x release cherrypick:4.2 Considered for cherry-picking into a future 4.2.x release labels May 28, 2024
@akien-mga
Copy link
Member

Thanks for the research and the fix. Some comments:

  • This should be reported / PR'ed upstream to https://github.com/RenderKit/embree. We can have a downstream patch temporarily but eventually this needs to be fixed in the original library.
  • I haven't looked into details yet, but would it work to use the #else (non _WIN32) branch, which I supposed is meant for GCC/Clang? It might work with MinGW GCC/Clang. So the fix would then be:
diff --git a/thirdparty/embree/common/sys/sysinfo.cpp b/thirdparty/embree/common/sys/sysinfo.cpp
index d01eab3c9d..4c5495c2ce 100644
--- a/thirdparty/embree/common/sys/sysinfo.cpp
+++ b/thirdparty/embree/common/sys/sysinfo.cpp
@@ -293,11 +293,8 @@ namespace embree
     int cpuid_leaf_7[4] = { 0,0,0,0 };
     int cpuid_leaf_e1[4] = { 0,0,0,0 };
     if (nIds >= 1) __cpuid (cpuid_leaf_1,0x00000001);
-#if _WIN32
-#if _MSC_VER && (_MSC_FULL_VER < 160040219)
-#else
+#if _MSC_VER && (_MSC_FULL_VER >= 160040219)
     if (nIds >= 7) __cpuidex(cpuid_leaf_7,0x00000007,0);
-#endif
 #else
     if (nIds >= 7) __cpuid_count(cpuid_leaf_7,0x00000007,0);
 #endif

@akien-mga akien-mga changed the title Fixed use of undeclared identifier '__cpuidex' error on mingw Fix use of undeclared identifier __cpuidex error on MinGW May 28, 2024
@TCROC
Copy link
Contributor Author

TCROC commented May 28, 2024

Thanks for the research and the fix. Some comments:

* This should be reported / PR'ed upstream to https://github.com/RenderKit/embree. We can have a downstream patch temporarily but eventually this needs to be fixed in the original library.

* I haven't looked into details yet, but would it work to use the `#else` (non `_WIN32`) branch, which I supposed is meant for GCC/Clang? It might work with MinGW GCC/Clang. So the fix would then be:
diff --git a/thirdparty/embree/common/sys/sysinfo.cpp b/thirdparty/embree/common/sys/sysinfo.cpp
index d01eab3c9d..4c5495c2ce 100644
--- a/thirdparty/embree/common/sys/sysinfo.cpp
+++ b/thirdparty/embree/common/sys/sysinfo.cpp
@@ -293,11 +293,8 @@ namespace embree
     int cpuid_leaf_7[4] = { 0,0,0,0 };
     int cpuid_leaf_e1[4] = { 0,0,0,0 };
     if (nIds >= 1) __cpuid (cpuid_leaf_1,0x00000001);
-#if _WIN32
-#if _MSC_VER && (_MSC_FULL_VER < 160040219)
-#else
+#if _MSC_VER && (_MSC_FULL_VER >= 160040219)
     if (nIds >= 7) __cpuidex(cpuid_leaf_7,0x00000007,0);
-#endif
 #else
     if (nIds >= 7) __cpuid_count(cpuid_leaf_7,0x00000007,0);
 #endif

I will try and see if that works

@TCROC
Copy link
Contributor Author

TCROC commented May 28, 2024

@akien-mga

I can confirm that it does not like that. It errors with:

[ 29%] thirdparty/embree/common/sys/sysinfo.cpp:299:59: error: too few arguments provided to function-like macro invocation
  299 |     if (nIds >= 7) __cpuid_count(cpuid_leaf_7,0x00000007,0);
      |                                                           ^
/home/tcroc/dev/BlockyBallOT/submodules/godot-src/gitignore/zig/0.13.0-dev.267+793f820b3/zig-linux-x86_64-0.13.0-dev.267+793f820b3/lib/include/cpuid.h:265:9: note: macro '__cpuid_count' defined here
  265 | #define __cpuid_count(__leaf, __count, __eax, __ebx, __ecx, __edx) \
      |         ^
thirdparty/embree/common/sys/sysinfo.cpp:299:20: error: use of undeclared identifier '__cpuid_count'
  299 |     if (nIds >= 7) __cpuid_count(cpuid_leaf_7,0x00000007,0);
      |                    ^
[ 30%] 2 errors generated.

Anything else you would like me to try or should we leave it as is? Should I put a PR upstream to see if they have any feedback?

@akien-mga
Copy link
Member

Should I put a PR upstream to see if they have any feedback?

Yes, please do. If they're reactive, they should point to the proper / best solution for their codebase.

@TCROC
Copy link
Contributor Author

TCROC commented May 28, 2024

Should I put a PR upstream to see if they have any feedback?

Yes, please do. If they're reactive, they should point to the proper / best solution for their codebase.

Perfect! Then we can replace our patch with their fix assuming its appropriate for our codebase as well :)

@TCROC
Copy link
Contributor Author

TCROC commented May 28, 2024

Put in an upstream PR over here: RenderKit/embree#487

@akien-mga
Copy link
Member

Could you also include the patch we made to thirdparty code as a patch file in the same commit?

I.e. thirdparty/embree/patches/mingw-no-cpuidex.patch:

diff --git a/thirdparty/embree/common/sys/sysinfo.cpp b/thirdparty/embree/common/sys/sysinfo.cpp
index d01eab3c9d..4ecab05265 100644
--- a/thirdparty/embree/common/sys/sysinfo.cpp
+++ b/thirdparty/embree/common/sys/sysinfo.cpp
@@ -295,7 +295,7 @@ namespace embree
     if (nIds >= 1) __cpuid (cpuid_leaf_1,0x00000001);
 #if _WIN32
 #if _MSC_VER && (_MSC_FULL_VER < 160040219)
-#else
+#elif defined(_MSC_VER)
     if (nIds >= 7) __cpuidex(cpuid_leaf_7,0x00000007,0);
 #endif
 #else

This is how we document (and reapply on update) the downstream changes we made.

@TCROC
Copy link
Contributor Author

TCROC commented Jun 4, 2024

@akien-mga Got distracted by some things on our game. I'll look into that this week.

@TCROC
Copy link
Contributor Author

TCROC commented Jun 4, 2024

@akien-mga I added the patch file :)

@akien-mga akien-mga merged commit 688f956 into godotengine:master Jun 7, 2024
16 checks passed
@akien-mga
Copy link
Member

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug cherrypick:3.x Considered for cherry-picking into a future 3.x release cherrypick:3.5 Considered for cherry-picking into a future 3.5.x release cherrypick:4.1 Considered for cherry-picking into a future 4.1.x release cherrypick:4.2 Considered for cherry-picking into a future 4.2.x release platform:windows topic:buildsystem topic:thirdparty
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants