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

[Kao Dome <kaodome@icloud.com>]

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.