[Bug target/94194] New: x86: Provide feraiseexcept builtins

[Bug target/94194] New: x86: Provide feraiseexcept builtins

[adhemerval.zanella at linaro dot org]

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

            Bug ID: 94194
           Summary: x86: Provide feraiseexcept builtins
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adhemerval.zanella at linaro dot org
  Target Milestone: ---

GCC should support inline code generation for feraiseexcept. These optimization
has been provided by glibc through fenv.h and glibc idea is to remove both the
headers and the optimization [1].

[1] https://sourceware.org/pipermail/libc-alpha/2020-March/111753.html

[Bug target/94194] x86: Provide feraiseexcept builtins

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Is there a convenient way for gcc to know the value of FE_DIVBYZERO, etc on the
target? Do we need to hardcode it? Can we rely on different libc on the same
processor to use the same value?
What happens if the user calls feraiseexcept and compiles with
-fno-trapping-math?

[Bug target/94194] x86: Provide feraiseexcept builtins

[adhemerval.zanella at linaro dot org]

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

--- Comment #2 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
Afaik the libc implementation is free to set any macro value for FE_*, although
glibc and other implementations I am awre of try to make is related to
architecture values when it does make sense (and it also tend to simplify the
implementation).

So I would expect that the compiler either would need to export a
system-neutral value (GCC_FE_* or something related) with the drawback it would
not be a direct replacement for the system library call (as other builtins tend
to be) or define functions that does not use input arguments (something like 
__builtin_feraiseexcept_div_by_zero). For -fno-trapping-math I would expect to
be a nop in such a scenario, although I haven't given much thought about it.

However, I opened this bug more to check if this optimization would be worth
implementing. My take is to remove it from glibc installed headers [1], and my
impression is this should not add much from the compiler side of view as well.

[1] https://sourceware.org/pipermail/libc-alpha/2020-March/111775.html

[Bug target/94194] x86: Provide feraiseexcept builtins

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
GCC already has implicit knowledge of how FE_* for exceptions relate to 
the hardware, because it generates calls to __atomic_feraiseexcept, which 
is defined in libatomic using FE_* from <fenv.h>.  I think SPARC Solaris 
is the only case where this actually turned out to be OS-specific (see 
SPARC_LOW_FE_EXCEPT_VALUES).