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

[Bruno Haible]

Ralf Wildenhues wrote:
> * 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

That may well be. Thanks for digging up this solution.

> as well as -fno-strict-aliasing. 

I don't think this is necessary.

> > > 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.

OK, I'm dropping VMS support and using 'return' in all cases.

> > 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.

I think you are overstating the problem. GCC uses the alias analysis to
decide whether reordering instructions is allowed, i.e. whether a write
to a memory location may interfere with a read from a memory location.
Here, N_ops is a read-only, statically initialized, memory area - no
writes can happen to it, and therefore there is no problem with aliasing.

If GCC were "entitled to think that the converted pointer points to
uninitialized data", that would be against the rules of how
reinterpret_cast<> works, IMO.

Bruno