Opened 19 months ago

Closed 19 months ago

Last modified 19 months ago

#12958 closed defect (fixed)

llvm-9.0.1 breaks rustc-1.37.0

Reported by: ken@… Owned by: blfs-book
Priority: normal Milestone: 9.1
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description (last modified by Bruce Dubbs)

Since this got mentioned on the llvm ticket but that is closed, let's have a ticket for this. Thread at [http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-December/037040.html

No consensus on how we should approach this.

Attachments (1)

rustc-1.37.0-llvm9_fixes-1.patch (52.0 KB ) - added by Douglas R. Reno 19 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 by Bruce Dubbs, 19 months ago

Description: modified (diff)

by Douglas R. Reno, 19 months ago

comment:2 by Douglas R. Reno, 19 months ago

Here is the patch that I came up with. I didn't add a header to it though.

I'd prefer if a couple of other people looked at it before dropping it in.

renodr [ /sources/rustc-1.37.0-src ]$ grep 'test result:' rustc-testlog | awk '{ sum += $6 } END { print sum }' 9 renodr [ /sources/rustc-1.37.0-src ]$ grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }' 16805

comment:3 by Bruce Dubbs, 19 months ago

rustc=1.37.0 builds fine with the patch and llvm-9.0.1. I build librsvg, cbindgen, and gdb with the new rust without issues. All the rustc tests seemd to pass:

# of expected passes    63534
# of unexpected failures   1305
# of unexpected successes  1
# of expected failures     342
# of unknown successes     5
# of known failures     85
# of unresolved testcases  2
# of untested testcases    77
# of unsupported tests     257

But that seems normal for gdb. I'll note that 1072 of the failures are in the gdb.reverse directory.

comment:4 by ken@…, 19 months ago

I've now built llvm and rustc, both without tests, on an 8 core system from late September. I previously had llvm-8.0.1 and old rustc-1.35.0 on this system. With 8 cores llvm has gone from 25.5 SBU to 28.2 SBU, so about 10% slower.

But rustc with 8 cores took 41.3 SBU which is far slower than what is in the book.

Continuing, to prove our current versions of thunderbird and firefox build.

in reply to:  4 comment:5 by Bruce Dubbs, 19 months ago

Replying to ken@…:

Continuing, to prove our current versions of thunderbird and firefox build.

Both worked for me:
  Thunderbird 18.1 SBU (MOZ_MAKE_FLAGS="-j10")
  Firefox     14.8 SBU (MOZ_MAKE_FLAGS="-j10")

comment:6 by ken@…, 19 months ago

Interesting. I've just had two failed builds of thunderbird. For the first I had not noticed that the sed for undocumented rust macros was no longer used in the book (I hadn't updated my builds to keep abreast of the book, just dropped in the newer version). Retried, similar failure - both were segfaults in clang.

Currently retrying thunderbird without my C{,XX}FLAGS (I of course used them for llvm and the c/c++ parts of compiling rust), had no problems with them in mozilla packages until now (-O3 -march=native -DFORTIFY_SOURCE=2 -fstackprotector-strong -D_GLIBCXX_ASSERTIONS). To be clear, I've used these, except when manually timing builds for the book, for several months and on this machine I've built rustc 1.35/37/39/40 and thunderbird-68.1.0. I've also built firefox 69, 68.{1,2,3}, 70, 71, 72beta with those flags, but of course using gcc and g++.

comment:7 by ken@…, 19 months ago

Thunderbird now built ok without my CFLAGS.

comment:8 by Bruce Dubbs, 19 months ago

Resolution: fixed
Status: newclosed

Fixed by Doug at revision 22521.

comment:9 by ken@…, 19 months ago

Just a note that for me too, cbindgen, firefox and librsvg build ok.

comment:10 by ken@…, 19 months ago

For clang in thunderbird, the problem is highlighted by using -march=native. Looking at the output from llc --version it correctly shows llc was compiled on znver1.

comment:11 by ken@…, 19 months ago

After using -j1 for the clang part of the build I was able to see that the problem was in elfhack. I see no point in trying to raise an upstream bug with llvm (elfhack has periodically been buggy).

I've now managed to build thunderbird with -march=native on Zen1 (znver1) by adding --disable-elf-hack. Unlike with previous firefox problems from this, the build fails near the end, not the install. Will add that, commented, to thunderbird's mozconfig.

Note: See TracTickets for help on using tickets.