Re: C strict aliasing rules

[Benjamin Franksen <benjamin.franksen@bessy.de>]

On Tuesday 28 November 2006 03:02, Eric Norum wrote:
> On Nov 27, 2006, at 7:20 PM, Benjamin Franksen wrote:
> > Cheers
> > Ben
> > PS: whatever happened to the notorious compiler warning 'xyz
> > disables strict aliasing rules'? Seems to me as if compilers once
> > were able to detect cases where the assumptions broke down. Hmmm.
>
> The explicit cast is what's suppressing any warning.   Unfortunately
> I expect that we have lots of casts in EPICS which might cause
> similar (and silent) problems.
> FWIW, here's a version of the code that actually does produce the
> warning to which Benjamin is referring:
> norume@gnarly 704> cat a.c
> void
> writethree(short *p)
> {
>      short *palias = p;
>     *palias = 3;
> }
>
> int
> testalias()
> {
>      int value = 12345678;
>      writethree((short *)&value);
>      return value;
> }
> norume@gnarly 705> m68k-rtems4.7-gcc -O4 -Wall -S a.c
> a.c: In function 'testalias':
> a.c:12: warning: dereferencing type-punned pointer will break strict-
> aliasing rules

Ah, yes, that was it. Thanks for the research. So it appears that 
detecting this condition breaks down as soon as you introduce an 
intermediate pointer variable?

If this is correct, then detection of the aliasing condition is surely 
not something we can rely on.

> So, do we:
> 1) Ensure that EPICS is built with an optimization level that doesn't
> use the strict aliasing rules?
> or
> 2) Explictly prevent the compiler from using the strict aliasing
> rules (-fnostrict-aliasing for gcc, ??? for other compilers)?
> or
> 3) Bury our heads in the sand and hope that the problem never arises
> in our code?

I'd vote for (2). It is the safest bet, and I very much doubt that we'd 
be able to purify all code in base to honor strict aliasing rules. What 
about doing some tests to find out how much (if any) efficiency is lost 
if we disable the optimization?

Just my 2c.

Ben