EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Re: Strict aliasing blog-post
From: Michael Davidsaver <[email protected]>
To: [email protected]
Date: Wed, 16 Mar 2016 09:57:14 -0400
@Andrew,

The specific case where breakage in shown by
http://blog.regehr.org/archives/1307 in our language would be as
follows.  With the problem being where prec==prec2.

> int foo(dbCommon *prec, longinRecord *prec2)

To my knowledge this never happens in Base, and should be considered a
bug if it is.  So the issue is rather

> int foo(dbCommon *prec) {
>    longinRecord *prec2 = (longinRecord*)prec;
>    prec->scan = 0;
>    prec2->scan = 1;
>    return *prec->scan;
> }

and it's complement, which are frequent.  While I suppose an optimizer
might not be smart enough to recognize that prec and prec2 are aliases,
imo if this were happening the breakage would be widespread.

A quick check with -O3 with gcc 4.9.2 and clang 3.5.0 for amd64 and gcc
4.9.2 for arm7 shows that it recognizes the alias and does what I
expected (store and return 1).  So the store of 0 is optimized out.  See
attached.

So I vote no to adding -fno-strict-aliasing until it can be demonstrated
to be necessary for a relevant case.  IMO to do so otherwise is to start
down the path which would logically lead to disabling optimizations
completely.  Some trust of compiler authors is necessary.

Nothing wrong with adding some test code though.

FYI, if someone wants to push the look for interesting bugs in this are,
a good way to start would be the link time optimization (LTO) feature,
or trying to compile all the .c files at once.  This would give the
compiler maximum latitude to do unexpected things.

On 03/16/2016 02:56 AM, Torsten Bögershausen wrote:
> In general, yes.
> But: This is really compiler dependent.
>
>
> A better approach would be to go through the code base, and rework the problematic code,
> step by step.
>
> And when this is done, have a look if there are „volatile“ missing,
> and/or if we need better support for multi-core, like synchronizing the L2 caches
> on some ARM platforms.
> (But I’m not sure, if anybody is running EPICS on this kind of hardware)
>
> It may be good enough to enable it for gcc, if version >= 5.
> And what about clang ?
>
> /Torsten
>
>
>
> Am 15.03.2016 um 19:08 schrieb Andrew Johnson <[email protected]>:
>
>> http://blog.regehr.org/archives/1307
>>
>> Should we add the -fno-strict-aliasing flag to the EPICS build rules?
>>
>> - Andrew
>

typedef struct {
  int a;
  int b;
  int c;
} A;

typedef struct {
  int a;
  int b;
} B;

int foo(B *b)
{
  A *a = (A*)b;
  a->b = 0;
  b->b = 1;
  return a->b;
  /* expected effect, is to store and return 1 */
}

int foo2(B *b1, B *b2)
{
  A *a1=(A*)b1, *a2=(A*)b2;
  b1->b = 1;
  b2->b = 2;
  a1->b = 3;
  a2->b = 4;
  /* expected effect, is to store 3 and 4, load 3 return */
  return a1->b;
}

int foo3(B * __restrict__ b1, B * __restrict__ b2)
{
  A *a1=(A*)b1, *a2=(A*)b2;
  b1->b = 1;
  b2->b = 2;
  a1->b = 3;
  a2->b = 4;
  /* expected effect, is to store 3 and 4 and return 3 */
  return a1->b;
}

Replies:
Re: Strict aliasing blog-post Michael Davidsaver
References:
Strict aliasing blog-post Andrew Johnson
Re: Strict aliasing blog-post Torsten Bögershausen

Navigate by Date:
Prev: Re: Strict aliasing blog-post Torsten Bögershausen
Next: Re: Strict aliasing blog-post Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: Strict aliasing blog-post Torsten Bögershausen
Next: Re: Strict aliasing blog-post Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
ANJ, 16 Mar 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·