[cmake] Don't build with -O3 -fPIC on Solaris/sparcv9

Authored by ro on Fri, Aug 28, 2:40 AM.

Unpublished Commit ยท Learn More

Not On Permanent Ref: This commit is not an ancestor of any permanent ref.


[cmake] Don't build with -O3 -fPIC on Solaris/sparcv9

Tests on Solaris/sparcv9 currently show about 250 failures when building
with gcc, most of them like the following:

FAIL: LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures (4269 of 67884)
******************** TEST 'LLVM-Unit :: Support/./SupportTests/TaskQueueTest.UnOrderedFutures' FAILED ********************
Note: Google Test filter = TaskQueueTest.UnOrderedFutures
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from TaskQueueTest
[ RUN      ] TaskQueueTest.UnOrderedFutures
0  SupportTests        0x0000000100753b20 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 32
1  SupportTests        0x0000000100752974 llvm::sys::RunSignalHandlers() + 68
2  SupportTests        0x0000000100752b18 SignalHandler(int) + 372
3  libc.so.1           0xffffffff7eedc800 __sighndlr + 12
4  libc.so.1           0xffffffff7eecf23c call_user_handler + 852
5  libc.so.1           0xffffffff7eecf594 sigacthandler + 84
6  SupportTests        0x00000001006f8cb8 std::thread::_State_impl<std::thread::_Invoker<std::tuple<llvm::ThreadPool::ThreadPool(llvm::ThreadPoolStrategy)::'lambda'()> > >::_M_run() + 512
7  libstdc++.so.6.0.28 0xfffffffc628117cc execute_native_thread_routine + 16
8  libc.so.1           0xffffffff7eedc6a0 _lwp_start + 0

Since it's effectively impossible to debug such a SEGV in a Release
build, I tried a Debug build instead, only to find that the failures had
gone away.

Further investigation revealed that most of the issue centers around
llvm/lib/Support/ThreadPool.cpp. That file is built with -O3 -fPIC in
a Release build. The failure vanishes if

  • compiling without -fPIC
  • compiling with -O -fPIC
  • linking with GNU ld instead of Solaris ld

It has meanwhile been determined that gcc doesn't correctly heed some TLS
code sequences. To make things worse, Solaris ld doesn't properly
validate its assumptions against the input, generating wrong code.

gld like gcc is more liberal here and correctly deals with the code it
gets fed from gcc.

There's PR target/96607: GCC feeds SPARC/Solaris linker with unrecognized
TLS sequences https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 now.

An attempt to build with -DLLVM_ENABLE_PIC=Off initially failed since
neither libRemarks.so (D85626 https://reviews.llvm.org/D85626) nor
LLVMPolly.so (D85627 https://reviews.llvm.org/D85627) heed that option.
Even with that fixed, a few codegen failures remain.

Next I tried to build just ThreadPool.cpp with -O -fPIC. While that
fixed the vast majority of the failures, 16 LLVM :: CodeGen/X86 failures

Given that that solution was both incomplete and fragile, I went for
building the whole tree with -O -fPIC for Release and RelWithDebInfo

As detailed in Bug 47304, 2-stage builds also show large numbers of
failures when building with -O3 or -O2, which are likewise worked
around by building with -O until they are sufficiently analyzed and

This way, all failures relative to a Debug build go away.

Tested on sparcv9-sun-solaris2.11.

Differential Revision: https://reviews.llvm.org/D85630

(cherry picked from commit 15c66b10114d239c96282cf8fc5330186178974b)


hansMon, Aug 31, 5:41 AM
rGdefbc77a7c95: [DAGCombine] Don't delete the node if it has uses immediately