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

[via cfe-dev]

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.