[cfe-dev] Clang 4.0.1 C++ code generation issue (bug?)

[Serge Preis via cfe-dev]

Please disregard this. This was from internal discussion of the issue - wrong addressees :(

Sorry.


12.07.2017, 12:29, "Serge Preis" <spreis at yandex-team.ru>:
> Хорошие новости - я полазил по баг-трекеру, ревьюшнице и коммитнице LLVM и, похоже, проблему починили вот этим коммитом:
>
> https://reviews.llvm.org/rL303851
>
> К сожалению этот коммит не вошёл в 4.0.1 (я проверил по их svn), так что если решим перейти на 4.0.1 этот патч неплохо было бы забрать, ну или ждать 4.0.2.
>
> --
> Сергей Прейс
> stuff/spreis
>
> 12.07.2017, 08:01, "via cfe-dev" <cfe-dev at lists.llvm.org>:
>>  Thanks, Dimitry, for your rapid reply.
>>
>>  On 11 Jul 17, at 09:39:55, Dimitry Andric <dimitry at andric.com> wrote:
>>
>>>   See https://bugs.llvm.org/show_bug.cgi?id=31928 for a similar story.
>>
>>  Ouch!
>>  (I tried searching bugs.llvm.org, but there were too many unresolved issues & 31928’s title didn’t seem relevant.)
>>
>>  As this has changed from Clang 3.9.1 to 4.0.0 it should be in the release notes. It is not. Why not?
>>  This is going to silently bite may users. (scan-build also reports nothing.)
>>  A very quick check shows this may well break CoreFoundation (CFByteOrder.h) and sqlite (shell.c). There are very probably many, many more.
>>
>>>   Short answer: do not write to one member of a union, then read from another, since that is "implementation defined" behavior, and this was broken going from clang 3.9.0 to 4.0.0 (or maybe it was always broken, and it did not optimize "enough" to be of influence).
>>
>>  I agree that this may be “implementation defined”. The C++ standard appears to state that it is defined behaviour. Where is this behaviour defined for Clang? Why has it changed?
>>  Also “implementation defined” means it should behave the same with & without -O2. With Clang 4.0 it does not. Therefore it is now “undefined behaviour”. Thus, Clang 4.0 is broken.
>>
>>>   If your code really must write one union member and read another, and you do not want to refactor these accesses using memcpy, you will have to use -fno-strict-aliasing.
>>
>>  Where is -fstrict-aliasing/-fno-strict-aliasing defined for clang?
>>  For that matter where is it stated that -O2 also sets -fstrict-aliasing?
>>
>>  Clang is stated to be “GCC compatible”. GCC explicitly states that “type-punning” using a union is allowed with -fstrict-aliasing <https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Optimize-Options.html>.
>>
>>  Therefore, I now assert that Clang 4.0.0 & 4.0.1 are broken. Please will someone fix it.
>>  (I doubt most people are using Clang 4.0 yet. This may change when Xcode 9.0 ships. That would be bad.)
>>
>>  Regards,
>>
>>  CHRIS
>>
>>  PS Further testing shows that the issue also affects clang 4.0.1 with -std=c++11.
>>
>>  _______________________________________________
>>  cfe-dev mailing list
>>  cfe-dev at lists.llvm.org
>>  http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev