Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
<== Date ==> <== Thread ==>

Subject: Re: Is breaking strict-aliasing rules something to worry about?
From: "Johnson, Andrew N." <anj@anl.gov>
To: "core-talk@aps.anl.gov" <core-talk@aps.anl.gov>
Date: Wed, 3 Oct 2018 18:07:52 +0000
Did I read recently that apparently even the use of a union (as shown by
Ben at the end of that thread) is no longer guaranteed to prevent
problems with the latest language rules? *That* would be somewhat
worrying if true...

- Andrew

On 10/03/2018 11:06 AM, Michael Davidsaver wrote:
> This question sounds familiar.
> 
> https://epics.anl.gov/core-talk/2017/msg00722.php
> 
> On 10/3/18 7:12 AM, Dirk Zimoch wrote:
>> I had removed all the -fno-strict-aliasing flags from my configurations because I thought it was not necessary any more with EPICS 7, but the warnings are back:
>>
>> /usr/local/epics/base-7.0.1/include/pv/anyscalar.h:111: warning: dereferencing pointer ‘<anonymous>’ does break strict-aliasing rules
>>
>> As I understand, strict aliasing rules allow the compiler to do some aggressive optimization by assuming an assignment to a pointer of type A* can never change a variable of type B, given A and B are sufficiently different types. Thus a variable of type B can be safely kept in a register and does not need to be reloaded from memory only because a pointer of type A* has been written to.
>>
>> The option -fno-strict-aliasing switches off that optimization and thus the warning as well.
>>
>> But I don't know if the warning means that the optimizer will not touch the expressions that break strict-aliasing rules or if the optimizer will do its work anyway, potentially leading to very subtle and hard to debug run-time errors.
>>
>> I propose to either
>> a) Fix the code and be careful to never break strict-aliasing rules, i.e fix it immediately when such warnings pop up.
>> b) Use -fno-strict-aliasing for all compilers that support it (gcc 3+ ?)
>>
>> Dirk
> 

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Replies:
Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
References:
Is breaking strict-aliasing rules something to worry about? Dirk Zimoch
Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver

Navigate by Date:
Prev: Re: Something wrong with the repo? Johnson, Andrew N.
Next: Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
Navigate by Thread:
Prev: Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Next: Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021 
ANJ, 03 Oct 2018 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·