LTO seems to change the outcome of the division by zero raises SIGFPE test.

LTO seems to change the outcome of the division by zero raises SIGFPE test.

[Kao Dome]

Hi, when I noticed it I was building binutils in MSYS2 (so, Windows) I checked in Linux to see if the same would happen and it seems to.The test itself is in the intl configure script, but I'll reproduce it here:------------------#include <stdlib.h>#include <signal.h>static void#ifdef __cplusplussigfpe_handler (int sig)#elsesigfpe_handler (sig) int sig;#endif{  /* Exit with code 0 if SIGFPE, with code 1 if any other signal.  */  exit (sig != SIGFPE);}int x = 1;int y = 0;int z;int nan;int main (){  signal (SIGFPE, sigfpe_handler);/* IRIX and AIX (when "xlc -qcheck" is used) yield signal SIGTRAP.  */#if (defined (__sgi) || defined (_AIX)) && defined (SIGTRAP)  signal (SIGTRAP, sigfpe_handler);#endif/* Linux/SPARC yields signal SIGILL.  */#if defined (__sparc__) && defined (__linux__)  signal (SIGILL, sigfpe_handler);#endif  z = x / y;  nan = y / y;  exit (1);}------------------When CFLAGS include a flavor of LTO, for example, "-flto", executing the binary leads to a return value of 1, but it exists through the one at end of the program, *not* the signal handler. When no LTO is used, executing returns 0. Also, it happens when CFLAGS have some optimization going on, so it'd be "-O2 -flto" vs "-O2" for example.I don't think it is important, but because it defines INTDIV0_RAISES_SIGFPE to either 1 or 0, I'm guessing it is there for a reason and means something in intl, so I decided to report it just in case.That's the only thing that changes throughout the whole configuration phase when having LTO in CFLAGS, the rest stays the same (save ar and the like which are set to gcc-ar). The versions of what I'm using to build are GCC 12.1.0 and Binutils 2.38.Regards,Kao.

Re: LTO seems to change the outcome of the division by zero raises SIGFPE test.

[Nick Clifton]

Hi Kao,

> When CFLAGS include a flavor of LTO, for example, "-flto", executing the binary leads to a 
> return value of 1, but it exists through the one at end of the program, *not* the signal 
> handler. When no LTO is used, executing returns 0. 

I am pretty sure that this is a gcc issue, rather than a binutils one.  When LTO
is enabled the compiler is invoked twice, and it would be my guess that it is this
second invocation which is changing the behaviour of the final program.

This could be a known issue.  I suggest that you check to see which version of gcc
you are using, and if it is not the latest, upgrade.  If the problem persists then
please file a bug report with the gcc bugzilla system.

Cheers
   Nick