llvm dev - Aug 2018 - 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.

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>

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

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