[CLN-list] GCC 4.3 (experimental) -O2 dislikes intparam.h
Ralf.Wildenhues at gmx.de
Tue Dec 19 14:41:28 CET 2006
* 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
> > 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:
> > 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
and the pointer &N_ops, but reading the former doesn't guarantee to give
you the data pointed to by the latter.
More information about the CLN-list