On Fri, Aug 10, 2018 at 6:08 PM, Sam McCall wrote:
> json::Value in JSON.h is a discriminated union.
> The storage is a char array of appropriate type and alignment. The storage
> holds one object at a time, it's initialized (and for nontrivial types,
> destroyed) at the right times to ensure this
json::Value in JSON.h is a discriminated union.
The storage is a char array of appropriate type and alignment. The storage
holds one object at a time, it's initialized (and for nontrivial types,
destroyed) at the right times to ensure this. The cast is only to the type
of object that's already ther
On 08/10/2018 05:30 AM, Liu Hao wrote:
> Only an lvalue of a pointer to (possibly CV-qualified) `void` or a
> pointer to a character type (in C) / any of `char`, `unsigned char` or
> `std::byte` (in C++) can alias objects.
Yes.
> That is to say, in order to eliminate the aliasing problem an
>
在 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
Hi LH_Mouse,
Thanks!
On Fri, Aug 10, 2018 at 6:30 AM, Liu Hao wrote:
>
> When I used to do such type punning in C, I got similar warnings. Then I
> looked for some solutions... I can't recall the principle now and I fail to
> find it in the C or C++ standard. Despite that, the solution is simple
在 2018-08-10 06:20, Kim Gräsman 写道:
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely
wrote:
If GCC 4.9.3 thinks there's an aliasing violation it might
misoptimise. It doesn't matter if it's right or not, it matters if it
treats the code as undefined or not.
And apparently GCC does think ther
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely
wrote:
>
> If GCC 4.9.3 thinks there's an aliasing violation it might
> misoptimise. It doesn't matter if it's right or not, it matters if it
> treats the code as undefined or not.
>
> And apparently GCC does think there's a violation, because it w
On Thu, 9 Aug 2018 at 22:59, Kim Gräsman wrote:
>
> Thanks all for pitching in to help!
>
> On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote:
> >
> > Obviously if there really is something illegal here we should fix it in
> > LLVM, but it looks like this warning is a false positive (anyone disagr
Thanks all for pitching in to help!
On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall wrote:
>
> Obviously if there really is something illegal here we should fix it in
> LLVM, but it looks like this warning is a false positive (anyone disagree?)
The little I've read about strict aliasing rules leaves
Hi Sam,
Thanks for your response!
Please review it, thanks a lot!
A patch by Loongson!
diff --git a/include/llvm/Support/JSON.h b/include/llvm/Support/JSON.h
index da3c5ea..fd60b40 100644
--- a/include/llvm/Support/JSON.h
+++ b/include/llvm/Support/JSON.h
@@ -452,7 +452,10 @@ private:
new
Author of the problematic code here. Thanks everyone, and sorry to have
caused difficulty!
Obviously if there really is something illegal here we should fix it in
LLVM, but it looks like this warning is a false positive (anyone disagree?)
Still if there's a simple source-level workaround, or we c
On Thu, 9 Aug 2018 at 12:04, Leslie Zhai wrote:
>
> Hi Jonathan,
>
> Thanks for your response!
>
> So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5
> to build old clang, then bootstrap latest LLVM with old clang.
It would be much easier to just use -fno-strict-aliasing with
Hi Jonathan,
Thanks for your response!
So workaround for Kim's issue is bootstrap old version LLVM with GCC 4/5
to build old clang, then bootstrap latest LLVM with old clang.
在 2018年08月09日 17:16, Jonathan Wakely 写道:
On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote:
Could you test to compile
On Thu, 9 Aug 2018 at 03:09, Leslie Zhai wrote:
> Could you test to compile LLVM with GCC old versions 4/5/6? Does it need
> to backport your patch to GCC old version?
GCC versions before 6.4 are not supported, so no backports will happen
to 4.x or 5 releases and I doubt anybody's going to routine
Hi Kim,
Thanks for your report!
My GCC 4.9.3 is *not* able to reproduce the issue with reduced testcase[1]
But it is able to reproduce the issue by compiling LLVM with GCC
toolchain[2]
In file included from /home/loongson/llvm/lib/Support/JSON.cpp:10:0:
/home/loongson/llvm/include/llvm/Supp
15 matches
Mail list logo
