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

[Michael Davidsaver <mdavidsaver@gmail.com>]

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 <mdavidsaver@gmail.com <mailto:mdavidsaver@gmail.com>> 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
>>>>
>>>
>>