Jonathan Wakely via llvm-dev
2018-Aug-09 11:06 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
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 the older GCC.
Sam McCall via llvm-dev
2018-Aug-09 11:25 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
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 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. If this is a useful direction, could someone with an affected environment send me a small patch? I don't have the right setup to verify myself. Cheers, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180809/b07dae61/attachment.html>
Leslie Zhai via llvm-dev
2018-Aug-09 11:44 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
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 (reinterpret_cast<T *>(Union.buffer)) T(std::forward<U>(V)...); } template <typename T> T &as() const { +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstrict-aliasing" return *reinterpret_cast<T *>(Union.buffer); +#pragma GCC diagnostic pop } template <typename Indenter> 在 2018年08月09日 19:25, Sam McCall 写道:> 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?)False positive!> > 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. > > If this is a useful direction, could someone with an affected > environment send me a small patch? I don't have the right setup to > verify myself.I test it for mips64el built with gcc-4-branch: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips64el-redhat-linux/4.9.3/lto-wrapper Target: mips64el-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-arch=loongson3a --enable-languages=c,c++,objc,obj-c++,fortran,go,lto --enable-plugin --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.3/obj-mips64el-redhat-linux/cloog-install --enable-gnu-indirect-function --with-long-double-128 --build=mips64el-redhat-linux Thread model: posix gcc version 4.9.3 20150626 (Red Hat 4.9.3-8) (GCC)> > Cheers, Sam-- Regards, Leslie Zhai
Kim Gräsman via llvm-dev
2018-Aug-09 21:59 UTC
[llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h
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.> 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