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