xmmintrin.h includes mm_malloc.h which #include <stdlib.h> which using std::abs; (among others) see https://godbolt.org/z/cxo65rnr9 or this excerpt from c++ -E dump ``` # 32 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/xmmintrin.h" 2 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 1 3 4 # 27 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 1 3 4 # 36 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 3 4 # 1 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 1 3 4 # 39 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 3 4 # 40 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/cstdlib" 3 # 37 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/include/c++/12.3.1/stdlib.h" 2 3 4 using std::abort; using std::atexit; using std::exit; using std::at_quick_exit; using std::quick_exit; using std::div_t; using std::ldiv_t; using std::abs; using std::atof; using std::atoi; using std::atol; using std::bsearch; using std::calloc; using std::div; using std::free; using std::getenv; using std::labs; using std::ldiv; using std::malloc; using std::mblen; using std::mbstowcs; using std::mbtowc; using std::qsort; using std::rand; using std::realloc; using std::srand; using std::strtod; using std::strtol; using std::strtoul; using std::system; using std::wcstombs; using std::wctomb; # 28 "/data/cmssw/el9_amd64_gcc12/external/gcc/12.3.1-40d504be6370b5a30e3947a6e575ca28/lib/gcc/x86_64-redhat-linux-gnu/12.3.1/include/mm_malloc.h" 2 3 4 ```
*** Bug 114483 has been marked as a duplicate of this bug. ***
Why do you think this is a bug? Including an intrinsic header will almost always pull in other headers.
in C++ one is supposed to #include <cstdlib> not <stdlib.h> I do not think that there is an explicit version of C++ headers for the intrinsics that avoids the conflicts between C and C++.
Note this header has been this way for almost 20 years too ...
But <xmmintrin.h> is not a standard C++ header, there's no guarantee it doesn't include <stdlib.h> (or any other header). For the specific case of <cstdlib>, you know that includes <stdlib.h> and always adds abs(int) to the global namespace, right? It's actually a bug that <cstdlib> doesn't always add abs(long) and abs(long long) to the global namespace too, see PR 89855. The standard says <cstdlib> might add the names to the global namespace, so you seem to be asking for something that is not required by the standard, and very difficult to implement (without replacing all libc headers).
(In reply to Jonathan Wakely from comment #6) > For the specific case of <cstdlib>, you know that includes <stdlib.h> and > always adds abs(int) to the global namespace, right? It's actually a bug > that <cstdlib> doesn't always add abs(long) and abs(long long) to the global > namespace too, *and* abs(float), abs(double), and abs(long double) too. > see PR 89855. Maybe that bug is the real issue you're reporting?
Can you expand on what is going wrong with the way the include files are done this way? Because it is not obvious what the issue you are running into. Is it because you want to include the intrinsic header inside a header and then it is bringing in some of the declarations to the toplevel namespace and it is breaking the build depending on the target you are compiling on? Or something else?
We observe that including xmmintrin.h the behaviour of some code, notably abs(x), when x is float or double changes. And this depends on the platform as xmmintrin.h is x86_64 specific. Yes, is 20 years that is like that and people always wandered why abs(x) was behaving differently in different parts of the code and now asking why it behaves differently on x86_64 and ARM. The workaround is obvious: use std::abs. I personally find very unconfortable that including (even through cascade) xmmintrin.h changes the behaviour of "abs(x)" If everybody on GCC side is confortable with this situation we will just take note and try to be more strict with code visual inspection.
arm_neon.h includes stdint.h . arm_acle.h includes stdint.h and stddef.h . arm_sve.h includes stdint.h. These all will define types and functions in the global namespace. So basically including intrinsic header will always include in other headers and will depend on the target since those target specific. The whole "arm vs x86_64" behavior seems more like the code depending on target specific headers in the first place so obvious they will be different. Sounds more like people have the wrong expectations here. Also note ICX, and clang have the same issue (maybe even worse with libc++ not wrapping stdlib.h).
(In reply to vincenzo Innocente from comment #9) > We observe that including xmmintrin.h the behaviour of some code, > notably abs(x), when x is float or double changes. Yeah, it *fixes* your code. Without <xmmintrin.h> your abs(f) code calls abs(int) which is wrong. e.g. https://godbolt.org/z/sxv69hv5K The arm code uses abs(int) which is wrong. The problem here is not that xmmintrin.h includes another header, it's that your code is not including the headers it requires. The fact that xmmintrin.h includes stdlib.h means you get away with it on one platform, but not on another. That portability problem isn't great, but it's not actually a bug in xmmintrin.h. > And this depends on the platform as xmmintrin.h is x86_64 specific. Yes, but different headers having different transitive inclues on different platforms is not actually a bug. > Yes, is 20 years that is like that and people always wandered why abs(x) was > behaving differently in different parts of the code and now asking why it > behaves differently on x86_64 and ARM. Righ, so *that's* the bug, not that xmmintrin.h includes another header, and not that C++ code is "supposed to #include <cstdlib> not <stdlib.h>". There is nothing wrong with xmmintrin.h including other headers. > The workaround is obvious: use std::abs. > > I personally find very unconfortable that including (even through cascade) > xmmintrin.h changes the behaviour of "abs(x)" When Bug 89855 is fixed, it won't change it. <cmath> will put all overloads of abs in the global namespace. This is a dup of Bug 89855 *** This bug has been marked as a duplicate of bug 89855 ***