[llvm] r354238 - [NFC] Better encapsulation of llvm::Optional Storage

[David Blaikie via llvm-commits]

Fair enough. I understand the potential letter of the law regarding that
approach being UB - CC'd Richard Smith in case he can correct/add some
nuance to our understanding here.

std::aligned_storage still sounds like a good idea, though.

& I don't think LLVM is generalrly compiled with -fstrict-aliasing, is it?
Do you know which compiler seems to be miscompiling these constructs?

On Mon, Feb 18, 2019 at 1:24 PM Serge Guelton <sguelton at redhat.com> wrote:

> On Mon, Feb 18, 2019 at 12:18:21PM -0800, David Blaikie wrote:
> > What was the UB/problem with the existing implementation (
> > AlignedCharArrayUnion) - and/or is std::aligned_storage an option?
>
> I'm unfortunately not 100% sure, but according to
> https://stackoverflow.com/questions/27003727/does-this-really-break-strict-aliasing-rules,
> the pattern
>
> #include <iostream>
>
> int main()
> {
>    alignas(int) char data[sizeof(int)];
>    int *myInt = new (data) int;
>    *myInt = 34;
>
>    std::cout << *reinterpret_cast<int*>(data);
> }
>
> is UB, and that's the exact pattern used in llvm::Optional.
>
> looks like libcxx is using the following pattern, I'm trusting the expert
> on that subject :-)
>
>    union { char empty; int some; } data;
>    int *myInt = new (&data.some) int;
>    *myInt = 34;
>
>    std::cout << data.some;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190218/6d398653/attachment.html>