Experimental Physics and Industrial Control System

On 10/3/18 1:55 PM, Johnson, Andrew N. wrote:
> I have no reason to doubt your statement. I am just wary of this topic given the amount of code we have that casts pointers between dbCommon, void* and/or some specific record type.

I'm not suggesting that we ignore these potential problems.
I just don't expect to discover major new problems of this
sort arising with older compilers.

If I was going to spend time on compiler testing, it would be with newer
gcc/clang (and libc for that matter).  We know from past experience that
new issues will arise in this area.

eg. it's been in the back of my mind to build Base with latest gcc 8.x on travis-ci.

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test

https://www.google.com/search?q=ubuntu-toolchain-r-test+travis-ci


> I may have been reading this blog post or some of the items it links to: https://blog.regehr.org/archives/1621
> 
> - Andrew
> 
> -- 
> Sent from my iPad
> 
> On Oct 3, 2018, at 1:49 PM, Michael Davidsaver <[email protected] <mailto:[email protected]>> wrote:
> 
>> On 10/3/18 11:07 AM, Johnson, Andrew N. wrote:
>>> 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...
>>
>> Before we rehash this.  Is there any new information?  Specifically,
>> is there anything which casts doubt on my statement?
>>
>> https://epics.anl.gov/core-talk/2017/msg00726.php
>>
>>> The construct used (std::aligned_storage) is well defined in c++11.
>>>
>>> http://en.cppreference.com/w/cpp/types/aligned_storage
>> ...
>>> GCC >=4.8.4 (at latest) doesn't warn about this even with -std=c++98.  So if anything, this is only need for older compilers.
>>
>> cf. definition of std::aligned_storage
>>
>> https://github.com/gcc-mirror/gcc/blob/d3a3029ca7489cb168d493de3d695809e84ffb0f/libstdc%2B%2B-v3/include/std/type_traits#L1943
>>
>> Please compare with struct AnyScalar::wrap_t
>>
>> https://github.com/epics-base/pvDataCPP/blob/aa87a2a23dc825e090bae9271703e3d51717eca8/src/misc/pv/anyscalar.h#L70-L84
>>
>> class AnyScalar is itself similar in construction to std::any of c++17
>>
>> https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libstdc%2B%2B-v3/include/std/any#L71
>>
>>
>>
>>> - 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
>>>>
>>>
>>

Replies:

Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

References:

Is breaking strict-aliasing rules something to worry about? Dirk Zimoch

Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver

Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver

Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

Navigate by Date:

Prev: Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

Next: Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

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: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

Next: Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

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