[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2018-12-20 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-20 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #12 from Yichao Yu --- Since the LLVM miscompilation isn't fixed, is there any way to check the alias assumptions more programmatically? (I can see that the TrailingObject might easily introduce something like this but given the

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-16 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #11 from Yichao Yu --- The case pointed out is fixed in https://reviews.llvm.org/rL284336 although as expected that doesn't fix the error. Still not sure whose bug is this...

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #10 from Yichao Yu --- That does look like an violation (this particular one should be hidden behind shared library boundary in the reduced case though). Reported to LLVM at https://llvm.org/bugs/show_bug.cgi?id=30711 .

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #9 from Andrew Pinski --- here is one example where LLVM could be violating C aliasing rules: void FoldingSetNodeID::AddPointer(const void *Ptr) { Bits.append(reinterpret_cast(), reinterpret_cast(+1)); } There could

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #8 from Yichao Yu --- > Can you try with -fno-strict-aliasing ? That seems to fix it for both the original case (LLVM) and the reduced case (the linked tarball). Is there a way to figure out the problematic (either bug in LLVM's

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #7 from Andrew Pinski --- Can you try with -fno-strict-aliasing ?

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #6 from Yichao Yu --- I've compiled a gcc at 951db45 using the same configuration as archlinux arm PKGBUILD and I can reproduce the problem using the `code/` in

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #5 from Yichao Yu --- Compiling current llvm trunk (r284322) still shows the same error. The script I used to compile LLVM is here https://github.com/yuyichao/arch-pkg/blob/master/pkg/all/llvm-svn/PKGBUILD. Compiling gcc 951db45

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #4 from Andrew Pinski --- # Arch Linux installs 64bit libraries /lib So non-standard (but that is not an issue here).

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread yyc1992 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #3 from Yichao Yu --- > What exact version of LLVM are you trying to compile? Revision of the LLVM > sources including revision of clang, etc. I was compiling the trunk version. The version I started reducing from was

[Bug middle-end/77996] Miscompilation due to LTO on aarch64

2016-10-15 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77996 --- Comment #2 from Andrew Pinski --- *** Bug 77997 has been marked as a duplicate of this bug. ***