Jonathan Wakely via llvm-dev
2018-Aug-09 22:02 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Thu, 9 Aug 2018 at 22:59, Kim Gräsman <kim.grasman at gmail.com> wrote:> > Thanks all for pitching in to help! > > On Thu, Aug 9, 2018 at 1:25 PM, Sam McCall <sam.mccall at gmail.com> 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 me firmly > incompetent to judge what's valid and not :) > > But since both Clang and GCC 6+ are happy with this, it seems > plausible that this would be a false positive.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 warns. Unless you're sure that not only is the code OK, but GCC is just being noisy and doesn't misoptimise, then I think using -fno-strict-aliasing is safer than just suppressing the warning.> > Still if there's a simple source-level workaround, or we can suppress the > > warning with a #pragma, I'd be happy to do that. GCC 4.9.3 is a supported > > compiler for LLVM and the more configurations we build cleanly in, the > > better. > > I *think* Leslie's warning-disable patch should work even with MSVC > (it should ignore unknown #pragmas, right?). I can't think of a > straight-up code change that would fix this. > > Cheers, > - Kim
Kim Gräsman via llvm-dev
2018-Aug-09 22:20 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely <jwakely.gcc at gmail.com> 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 warns. > > Unless you're sure that not only is the code OK, but GCC is just being > noisy and doesn't misoptimise, then I think using -fno-strict-aliasing > is safer than just suppressing the warning.Good point, I can see how that would play out nicer. So this would probably need to be addressed in the LLVM build system, I'll try and work up a patch tomorrow. Thanks, - Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/3ae4272a/attachment.html>
Liu Hao via llvm-dev
2018-Aug-10 04:30 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
在 2018-08-10 06:20, Kim Gräsman 写道:> On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely <jwakely.gcc at gmail.com> > 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 warns. >> >> Unless you're sure that not only is the code OK, but GCC is just being >> noisy and doesn't misoptimise, then I think using -fno-strict-aliasing >> is safer than just suppressing the warning. > > Good point, I can see how that would play out nicer. > > So this would probably need to be addressed in the LLVM build system, I'll > try and work up a patch tomorrow. >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: 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. That is to say, in order to eliminate the aliasing problem an intermediate lvalue pointer is required. Hence, altering ``` return *reinterpret_cast<T *>(Union.buffer); ``` to ``` auto p = static_cast<void *>(Union.buffer); return *static_cast<T *>(p); ``` will probably resolve this problem.> Thanks, > - Kim >-- Best regards, LH_Mouse