[Bug c++/109344] New: feraiseexcept produces incorrect code when optimizations are enabled

[Bug c++/109344] New: feraiseexcept produces incorrect code when optimizations are enabled

[albin at yahoo dot com]

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

            Bug ID: 109344
           Summary: feraiseexcept produces incorrect code when
                    optimizations are enabled
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: albin at yahoo dot com
  Target Milestone: ---

At -O1, calls to feraiseexcept are inlined. But the inlined code produces
incorrect results.

See here, only the first function behaves as expected:
https://godbolt.org/z/ncc3cjoKh

The behavior persists across many versions.

(A side note, I don't understand how the first function works, in order to
produce a divbyzero exception it appears to divide 0 / 1, not 1 / 0, am I
reading the assembly wrong?)

[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Why should the second and third function only raise FE_INVALID?

[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I get the same result for all of -O0/-O1/-O2, all 3 functions raise both
exceptions and that is correct, glibc has removed the inline versions some time
ago:
https://sourceware.org/pipermail/libc-alpha/2020-March/111753.html

The bug was on the glibc side:
both the
      /* One example of an invalid operation is 0.0 / 0.0.  */
      float __f = 0.0;

# ifdef __SSE_MATH__
      __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
and
      float __f = 1.0;
      float __g = 0.0;

# ifdef __SSE_MATH__
      __asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
part, because glibc didn't tell the compiler the inline assembly actually
modifies the register.
So, the first one was supposed to be
      __asm__ __volatile__ ("divss %0, %0 " : "+x" (__f));
and the second
      __asm__ __volatile__ ("divss %1, %0" : "+x" (__f) : "x" (__g));
Not a bug on the GCC side and on glibc side it has been fixed by the removal of
the inline version.

[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

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

--- Comment #3 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
INVALID then.

[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled

[albin at yahoo dot com]

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

--- Comment #4 from albin <albin at yahoo dot com> ---
Thanks for the info. If it was fixed three years ago how come it is still seen
when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using an
obsolete glibc?

[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled

[xry111 at gcc dot gnu.org]

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

--- Comment #5 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to albin from comment #4)
> Thanks for the info. If it was fixed three years ago how come it is still
> seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using
> an obsolete glibc?

It uses Glibc-2.31: https://godbolt.org/z/h348q7fbh