On 04.04.2024 14:59, Nicola Vetrini wrote:
> On 2024-03-28 11:25, Jan Beulich wrote:
>> On 11.07.2023 18:40, Roberto Bagnara wrote:
>>> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
>>> overlapping object) is directly targeted at two undefined behaviors,
>>> one of which is the subject of 6.5.16.1p3, namely:
>>>
>>> If the value being stored in an object is read from another object
>>> that overlaps in any way the storage of the first object, then the
>>> overlap shall be exact and the two objects shall have qualified or
>>> unqualified versions of a compatible type; otherwise, the behavior
>>> is undefined.
>>
>> I'd like to come back to this, for two reasons:
>>
>> 1) In the description of -fstrict-aliasing, gcc 13.2 doc says "Even
>> with
>> -fstrict-aliasing, type-punning is allowed, provided the memory is
>> accessed
>> through the union type." We even build with -fno-strict-aliasing, yet
>> misra/rules.rst has no mention at all of type punning being permitted.
>>
>> 2) With us using -fno-strict-aliasing, I wonder in how far e.g. commit
>> 7225f13aef03 ("x86: avoid Misra Rule 19.1 violations") wasn't
>> pointless, as
>> imo the "compatible types" part of the C spec clause then can be
>> treated as
>> irrelevant.
>>
>> To me both simply mean we're relying on another compiler extension
>> that's
>> not exactly spelled out as such.
>>
>> Opinions?
>
> Regardless of whether the compiler will do the right thing or not,
> Mandatory guidelines can't be deviated.
Are you suggesting then that we need to build with -fstrict-aliasing,
sorting out all the issues that there may be? And avoid type-punning
as well?
Jan
