Since RTH's patch <http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00860.html>,
stores to the real or imaginary part of a complex variable are represented
using a load of the other part and a COMPLEX_EXPR.
If the variable is not yet initialized, and the load of the other part does not
get optimized away, this can yield spurious floating-point exceptions (in
particular, loading a signaling NaN on the x87 raises the "invalid" exception).
This can happen with -ffloat-store (I don't have any proof that this is
restricted to -ffloat-store, but haven't observed the problem without this
option).
I observed the problem originally as a failure of glibc's test-double, which is
built with -ffloat-store and forms complex values by setting the real and
imaginary parts separately. The following testcase reproduces it on
i686-pc-linux-gnu, with trunk (-ffloat-store together with any of -O1 -O2 -O3
-Os), 4.2 branch (same options), 4.1 branch (-float-store -O1), but not for 4.0
(which predates the above mentioned patch) with any of those options. An
equivalent x86-specific test could of course be written without use of
<fenv.h>.
#include <fenv.h>
#include <stdlib.h>
volatile int x[1024];
void __attribute__((noinline))
fill_stack (void)
{
volatile int y[1024];
int i;
for (i = 0; i < 1024; i++)
y[i] = 0x7ff00000;
for (i = 0; i < 1024; i++)
x[i] = y[i];
}
volatile _Complex double vc;
void __attribute__((noinline))
use_complex (_Complex double c)
{
vc = c;
}
double t0, t1, t2, t3;
#define USE_COMPLEX(X, R, C) \
do { __real__ X = R; __imag__ X = C; use_complex (X); } while (0)
void __attribute__((noinline))
use_stack (void)
{
_Complex double a, b, c, d;
USE_COMPLEX (a, t0, t1);
USE_COMPLEX (b, t1, t2);
USE_COMPLEX (c, t2, t3);
USE_COMPLEX (d, t3, t0);
}
int
main (void)
{
fill_stack ();
feclearexcept (FE_INVALID);
use_stack ();
if (fetestexcept (FE_INVALID))
abort ();
exit (0);
}
--
Summary: [4.1/4.2/4.3 Regression] spurious exceptions with -
ffloat-store
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088