Segfault during i686 windows bootstrap

[Keno]

May or may not be related to #18123, but I'm still seeing this with binutils 2.27, so it's not fixed yet by that version:

    JULIA usr/lib/julia/sys.o
Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_PRIV_INSTRUCTION at 0x2365da9a -- unknown function (ip: 2365DA9A)
while loading sysimg.jl, in expression starting on line 6

[tkelman]

doesn't happen on gcc 4.9, does happen with 5.4.0 and 6.1.0

[Keno]

Looks like a miscompile of some sort to me.

Stopped in function Most likely __ZN12_GLOBAL__N_113SLPVectorizer14tryToVectorizeEPN4llvm14BinaryOperatorERNS_7BoUpSLPE
=> 0x0000000001f32ad6<+0>:  retl    $12
   0x0000000001f32ad9<+3>:  nop
   0x0000000001f32ada<+4>:  pushl   %ebp
1|debug > reg esp
0x0000000000c5e820

julia> icxx"$(sess)->add_watchpoint($(current_task(sess)), $(RemotePtr{Void}(0x0000000000c5e820)), 4, rr::WATCH_READWRITE);"

1|debug > rc
Stopped in function Most likely __ZN4llvm19SmallPtrSetImplBaseC2EPPKvRKS0_
=> 0x00000000017d2688<+0>:  popl    %esi
   0x00000000017d2689<+1>:  popl    %edi
   0x00000000017d268a<+2>:  popl    %ebp
1|debug >

[Keno]

Investigated and and filed upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333.

[vchuravy]

Assuming this is reproducible by cross-compiling from Linux it seems to be fixed with 6.2.

cat Make.user
LLVM_VER=3.9.0
LLVM_ASSERTIONS=1
XC_HOST = i686-w64-mingw32

i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[tkelman]

I certainly saw this in a cross compile with 6.2. I didn't try LLVM 3.9, so it's possibly not triggering the gcc bug in the same way that 3.7 was.

[tkelman]

I can confirm that this doesn't happen when using LLVM 3.9 with i686-w64-mingw32-gcc 5.4 from cygwin, but it does happen with LLVM 3.7 and the same compiler version. So something that changed in LLVM is no longer triggering the GCC bug, but that doesn't inspire a lot of confidence that it won't come back at some point. And we need to keep the buildbots capable of building release-0.5 which won't be upgrading LLVM, so we need to have a compiler version installed there that can successfully build with LLVM 3.7 for some time.

[tkelman]

Apparently the commit that caused this to stop happening on the llvm side was llvm-mirror/llvm@225dd82d634ca277 - which looks pretty small and not hugely consequential?

[Keno]

Yeah, that gcc bug should still be fixed.

[tkelman]

Any ideas how we get a gcc dev to triage it? We could attempt to run creduce on everything that goes into opt.exe maybe to get a smaller test case, but that's a lot of source.

[Keno]

Maybe ping the developer whose commit caused the regression?

[tkelman]

Fixed upstream in gcc 7.1, 6.4, and 5.5 (if there will ever be a 5.5) - the cygwin cross compilers are at 5.4 and they're carrying a patch that isn't quite what got applied in the end, but seemed to fix the issue (who knows if any other side effects though).