[Bug c++/114484] New: #include <xmmintrin.h> changes ::abs in std::abs

[Bug c++/114484] New: #include <xmmintrin.h> changes ::abs in std::abs

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

            Bug ID: 114484
           Summary: #include <xmmintrin.h>  changes ::abs in std::abs
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

[Bug c++/114484] #include <xmmintrin.h> changes ::abs in std::abs

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #1 from vincenzo Innocente <vincenzo.innocente at cern dot ch> ---
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 c++/114484] #include <xmmintrin.h> changes ::abs in std::abs

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #2 from vincenzo Innocente <vincenzo.innocente at cern dot ch> ---
*** Bug 114483 has been marked as a duplicate of this bug. ***

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Why do you think this is a bug?
Including an intrinsic header will almost always pull in other headers.

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #4 from vincenzo Innocente <vincenzo.innocente at cern dot ch> ---
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++.

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note this header has been this way for almost 20 years too ...

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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).

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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?

[Bug target/114484] #include <xmmintrin.h> changes ::abs in std::abs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-03-26
             Status|UNCONFIRMED                 |WAITING

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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 <xmmintrin.h> changes ::abs in std::abs

[vincenzo.innocente at cern dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

--- Comment #9 from vincenzo Innocente <vincenzo.innocente at cern dot ch> ---
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 <xmmintrin.h> changes ::abs in std::abs

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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 <xmmintrin.h> changes ::abs in std::abs

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114484

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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 ***