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.
- Navigate by Date:
- Prev:
Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.
- Next:
Jenkins build is back to normal : EPICS-7 #118 Jenkins Epics PSI
- 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
|