http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #6 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Harald Anlauf from comment #5)
> (In reply to Vittorio Zecca from comment #4)
> > Also I do not understand the different behaviour with different levels of
> > optimization,
>
> I think that compile-time optimization realizes that the exponent y
> is actually exactly a positive integer and does some simplification.
> At -O0, you get an evaluation by the run-time library.
Looking at the dump tree, one find that the following is generated:
D.1825 = __builtin_cpowf (D.1824, __complex__ (1.0e+0, 0.0));
Without optimization, this is converted into a call to cpowf.
A straigtforward C example shows that the exception is generated
within libm:
#define _GNU_SOURCE
#include <complex.h>
#include <fenv.h>
#include <stdio.h>
main()
{
complex x, y, z;
x = 0.;
y = 1.;
feenableexcept (FE_DIVBYZERO | FE_OVERFLOW | FE_INVALID);
z = cpowf (x, y);
printf("z = %f + %f * i\n", creal(z), cimag(z));
}
(gdb) run
Starting program: /home/anlauf/a.out
Program received signal SIGFPE, Arithmetic exception.
0xb7f98ea3 in clogf () from /lib/libm.so.6
Missing separate debuginfos, use: zypper install
glibc-debuginfo-2.14.1-14.27.1.i686
(gdb) where
#0 0xb7f98ea3 in clogf () from /lib/libm.so.6
#1 0xb7f9a4d4 in cpowf () from /lib/libm.so.6
#2 0x080485a2 in main () at check-cpow.c:12
That's with glibc-2.14.1.
