Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: C strict aliasing rules
From: Benjamin Franksen <benjamin.franksen@bessy.de>
To: core-talk@aps.anl.gov
Date: Tue, 28 Nov 2006 11:57:27 +0100
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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·