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

[Rainer Orth via Phabricator via llvm-commits]

ro added a comment.

In D85630#2223313 <https://reviews.llvm.org/D85630#2223313>, @ro wrote:

> In D85630#2223248 <https://reviews.llvm.org/D85630#2223248>, @hans wrote:
>
>> I agree with James.
>>
>> Also, since you're applying this work-around for gcc, I assume the tests pass in the bootstrapped build, i.e. when compiling with clang?
>
> I'd initially restricted the workaround to `gcc` because the reduced testcase attached to the GCC PR works when compiled with `clang++` instead of `g++`.  However, a bootstrap build is still nightmarishly bad on Solaris/sparcv9: the 11.0.0-rc1 one had 4817 failures, a fresh one on master with the workaround applied to both `gcc` and `clang` is down to 1365.
>
> So there's at least some improvement, but still a long way to go.

I've now clarified the `gcc` situation, adding a reference to the GCC PR for the issue.

I've also managed to reproduce the LLVM 11 2-stage builds on master: 4581 failures with just gcc -O (instead of -O3) vs. 1325 failures with the stage 2 `clang` built with -O, too.

I couldn't get the 2-stage builds to finish initially because this is a 128-strand box: I had restricted stage 1 to `-j24`, carefully restricting the lit parallelism using `LLVM_LIT_ARGS=-v -j 24`.  Unfortunately, that isn't automatically passed on to stage 2 and a test run at `-j128` totally killed the box, overwhelming even 256 GB RAM.

Unfortunately, I haven't yet made much progress investigating the failures in the 2-stage builds: a pure `Release` build is useless for that, and a `Debug` build fails in a different way.  I'm trying a `RelWithDebInfo` right now.

The question is how to proceed, though: with the workaround at least a 1-stage build with `gcc` shows no errors, so this is at least a basis.  Getting a clean 2-stage build will require quite a bit of effort, also in areas long reported/known, but so far ignored (no atomic support in 32-bit unlike gcc, wrong `long double` on 32-bit sparc).

It would be nice to get this workaround in for now, forming a basis for further work.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85630/new/

https://reviews.llvm.org/D85630