[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
Liu Hao via llvm-dev
llvm-dev at lists.llvm.org
Fri Aug 10 05:55:27 PDT 2018
在 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
More information about the llvm-dev
mailing list