Created attachment 23231 [details] bug reproduction files I use FreeBSD head on powerpc64 with LLVM 10 rc3. Compiling math/gsl port fails with: /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c -o cgbmv.lo cgbmv.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h, line 245. Stack dump: 0. Program arguments: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'cgbmv.c'. 4. Running pass 'Early CSE' on function '@cblas_cgbmv' #0 0x0000000013bac208 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x0000000013ba98d0 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67:5 #2 0x0000000013baf278 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:7 #3 0x0000000013baf4ec CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51 #4 0x0000000815732748 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:303:3 cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-rc3-1-gc290cb61fdc) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin Files for reproducing this issue are attached.
Does this reproduce on master? Maybe a duplicate of bug 41083
(In reply to Eli Friedman from comment #1) > Does this reproduce on master? Maybe a duplicate of bug 41083 That's it. It doesn't reproduce on master, because it was fixed by b8ebc11f0320. Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0. Can someone comment on the severity of this? I wasn't planning on doing another release candidate, but we could if we have to of course. *** This bug has been marked as a duplicate of bug 41083 ***
(In reply to Hans Wennborg from comment #2) > (In reply to Eli Friedman from comment #1) > > Does this reproduce on master? Maybe a duplicate of bug 41083 > > That's it. It doesn't reproduce on master, because it was fixed by > b8ebc11f0320. > > Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0. > > Can someone comment on the severity of this? I wasn't planning on doing > another release candidate, but we could if we have to of course. > > *** This bug has been marked as a duplicate of bug 41083 *** On FreeBSD we can just backport this patch, I already sent a request to dim@ (although it would be of course better to have it upstreamed for the release). I'm not in a position to talk about other systems.
(In reply to Hans Wennborg from comment #2) > (In reply to Eli Friedman from comment #1) > > Does this reproduce on master? Maybe a duplicate of bug 41083 > > That's it. It doesn't reproduce on master, because it was fixed by > b8ebc11f0320. > > Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0. > > Can someone comment on the severity of this? I wasn't planning on doing > another release candidate, but we could if we have to of course. > > *** This bug has been marked as a duplicate of bug 41083 *** The bug will manifest as an assert as shown here, but I don't have an estimate for how often that happens. I also don't know what happens with a no-asserts build. A quick check of an 'opt 9.0' here: https://godbolt.org/z/_rCqfc ...does not show a crash, so either this bug is a regression from 9.0 or that binary was built without asserts? The fix has been in trunk long enough, that I'd call the patch low risk. If it doesn't make it into 10.0.0, it should definitely be a candidate for 10.0.1.
(In reply to Sanjay Patel from comment #4) > (In reply to Hans Wennborg from comment #2) > > (In reply to Eli Friedman from comment #1) > > > Does this reproduce on master? Maybe a duplicate of bug 41083 > > > > That's it. It doesn't reproduce on master, because it was fixed by > > b8ebc11f0320. > > > > Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0. > > > > Can someone comment on the severity of this? I wasn't planning on doing > > another release candidate, but we could if we have to of course. > > > > *** This bug has been marked as a duplicate of bug 41083 *** > > The bug will manifest as an assert as shown here, but I don't have an > estimate for how often that happens. I also don't know what happens with a > no-asserts build. > > A quick check of an 'opt 9.0' here: > https://godbolt.org/z/_rCqfc > > ...does not show a crash, so either this bug is a regression from 9.0 or > that binary was built without asserts? > > The fix has been in trunk long enough, that I'd call the patch low risk. If > it doesn't make it into 10.0.0, it should definitely be a candidate for > 10.0.1. This is definitely a regression from 9.0.1 - math/gsl port built with 9.0.1 just fine.
Okay, this seems bad enough that it warrants another release candidate. I've cherry-picked the test update as cfa792458fc47f9890d94a2718288c269c8a2a6e and the fix as 623461b2ce421cd287f1bea50c0998003375a782. Then I had to re-generate the test in 5401d393f88b9fa99a8d3a2a1b3013e757d958a2. This will be in rc5. It's unfortunate that we only found out about this so late in the release process, even though the fix landed more than a month ago. But these things happen.
(In reply to Hans Wennborg from comment #6) > It's unfortunate that we only found out about this so late in the release > process, even though the fix landed more than a month ago. But these things > happen. Sorry about that. I'll try to be more aware of the release cycle going forward. Thank you for all of the work in getting the release out!