* Bruno Haible wrote on Tue, Dec 19, 2006 at 02:13:56PM CET:
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.
So you'll need -fwrapv for CLN, as well as -fno-strict-aliasing.
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?
I intend to, but I'll wade through the thread only after the storm has calmed down.
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.
But then you need a declaration for exit. FYI, the last variant Autoconf had can be inferred from this thread: <http://lists.gnu.org/archive/html/autoconf-patches/2006-04/msg00045.html>
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.
I don't think the "will break strict aliasing" warnings tell you about likely failures. I think they tell you about certain (in the sense of "for sure") failures, given enough optimization (IOW, without -fno-strict-aliasing). IIRC, GCC is entitled to think that the converted pointer points to uninitialized data, and fill in whatever it likes. So yes, there is aliasing involved here, between the pointer (cl_number_ring_ops<cl_number>*) &N_ops and the pointer &N_ops, but reading the former doesn't guarantee to give you the data pointed to by the latter. Cheers, Ralf