[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