[CLN-list] GCC 4.3 (experimental) -O2 dislikes intparam.h

[Ralf Wildenhues]

* 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