[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #11 from Jonathan Wakely --- (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 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 not ". 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. 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 ***
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #10 from Andrew Pinski --- 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).
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #9 from vincenzo Innocente --- 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.
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-26 Status|UNCONFIRMED |WAITING --- Comment #8 from Andrew Pinski --- 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?
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #6) > For the specific case of , you know that includes and > always adds abs(int) to the global namespace, right? It's actually a bug > that 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?
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #6 from Jonathan Wakely --- But is not a standard C++ header, there's no guarantee it doesn't include (or any other header). For the specific case of , you know that includes and always adds abs(int) to the global namespace, right? It's actually a bug that doesn't always add abs(long) and abs(long long) to the global namespace too, see PR 89855. The standard says 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).
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #5 from Andrew Pinski --- Note this header has been this way for almost 20 years too ...
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #4 from vincenzo Innocente --- in C++ one is supposed to #include not I do not think that there is an explicit version of C++ headers for the intrinsics that avoids the conflicts between C and C++.
[Bug target/114484] #include changes ::abs in std::abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484 --- Comment #3 from Andrew Pinski --- Why do you think this is a bug? Including an intrinsic header will almost always pull in other headers.
