http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > And I still believe the result should not depend on the optimization level. Well, it does and IMO it has to (see below). > Note that compiling without -ffpe-trap the result > with default optimization, -O0, is ( 0.00000000 , -0.00000000 ), > higher optimizations deliver ( 0.00000000 , 0.00000000 ). > Another mystery. IMO there is no mystery. zero is a constant that is propagated during the optimization pass: looking at pr57749.f90.165t.optimized, I see D.1881 = __complex__ (0.0, 0.0); _gfortran_transfer_complex_write (&dt_parm.0, &D.1881, 4); i.e., zero**1e0 is computed during the optimization (hence cannot generate exception at run time). In pr57749.f90.003t.original, I see D.1881 = __builtin_cpowf (D.1880, __complex__ (1.0e+0, 0.0)); _gfortran_transfer_complex_write (&dt_parm.0, &D.1881, 4); so at run time you call a "buggy(?)" cpowf that generates the exception and (0.0,-0.0). As said in comment #6, this is not a gfortran bug, but a libgcc/libm one to be reported upstrean.