Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

[Liu Hao <lh_mouse at 126 dot com>]

在 2018-08-10 18:53, Kim Gräsman 写道:
> I'm worried that this might only serve to trick the compiler.

It shouldn't. If it was merely a trick then `std::aligned_storage` would 
be completely unusable.

> Explicitly using `-fno-strict-aliasing` for GCC < 6 would seem more
> direct to me -- as Jonathan says, if the compiler classifies a strict
> aliasing rule violation as undefined behavior, and that is further
> used to optimize in an unexpected manner, it doesn't matter whether it
> warns or not. Then again, I guess disabling strict aliasing would also
> disable optimizations that are generally useful for LLVM as a whole.
>
> I'm reading up on safe aliasing techniques, but so far nothing stands
> out to me as applicable in this scenario.

The C++ standard requires creation of objects in such ways to use new 
expressions (a.k.a. placement new). Athough [intro.object]-3 only 
defines /provides storage/ for arrays of a character type or 
`std::byte`, the specification of `aligned_storage` and `aligned_union` 
in [meta.trans.other] doesn't require the type used as uninitialized 
storage to be an array of a character type or `std::byte` - in fact it 
cannot be, because alignment information is not part of the nominal type 
system of C and will be lost when obtaining the `type` member.

Focusing on the cast: As long as the compiler is unable to know whether 
a placement new has been made on the union (i.e. whether it is providing 
storage for another object), I don't think a standard-conforming 
compiler is ever allowed to ignore such possibility.

> - Kim


--
Best regards,
LH_Mouse