Experimental Physics and Industrial Control System

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

Replies:

Re: C strict aliasing rules Kay-Uwe Kasemir

References:

C strict aliasing rules Eric Norum

Re: C strict aliasing rules Benjamin Franksen

Re: C strict aliasing rules Eric Norum

Navigate by Date:

Prev: Re: C strict aliasing rules Eric Norum

Next: Re: C strict aliasing rules Kay-Uwe Kasemir

Index: 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: Re: C strict aliasing rules Eric Norum

Next: Re: C strict aliasing rules Kay-Uwe Kasemir

Index: 2002  2003  2004  2005  <2006>  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024