[CLN-list] GCC 4.3 (experimental) -O2 dislikes intparam.h
Bruno Haible
bruno at clisp.org
Tue Dec 19 14:13:56 CET 2006
Hello Ralf,
Thanks for the early gcc testing!
> I have reduced the difference to compiling the program below on
> GNU/Linux x86:
>
> $ gcc-4.3 -W -Wall -o foo foo.i
> $ ./foo
> /* Integers of type int have 32 bits. */
> #define int_bitsize 32
>
> $ gcc-4.3 -O2 -W -Wall -o foo foo.i
> $ ./foo
> #error "Integers of type int have no binary representation!!"
>
> Now, I was about to report a compiler bug ... except that I think the
> compiler is right here: integer overflow produces undefined behavior,
> so I think intparam.c should be fixed instead.
There are hundreds of places in CLN where signed integers are shifted
left, or where unsigned integers are added, assuming a "modulo 2^n"
behaviour. Without a GCC diagnostic that points to the source code places
where gcc does not follow the "modulo 2^n" behaviour, this GCC is unusable
for CLN.
If the GCC people don't consider it a bug in the compiler, can you please
ask them for a warning that accompanies these new optimizations?
> Next, please note that intparam.c uses exit but does not provide for a
> prototype. I recommend returning from main instead.
Exit and return from main is not the same on VMS.
> Furthermore, please note that the CLN headers cause many "might break
> strict aliasing" warnings, and a few "will break strict aliasing"
> warnings. The latter are (at least) here:
> src/complex/ring/cl_C_ring.cc:131
> src/rational/ring/cl_RA_ring.cc:129
> src/real/ring/cl_R_ring.cc:133
I think you can ignore these 3 warnings; there is not much opportunity for
aliasing here.
Bruno
More information about the CLN-list
mailing list