[all-commits] [llvm/llvm-project] 76e85a: [clang][Sparc] Default to -mcpu=v9 for Sparc V8 on...

[rorth via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 76e85ae268f8e64540703b0d1710d27ef0d36040
      https://github.com/llvm/llvm-project/commit/76e85ae268f8e64540703b0d1710d27ef0d36040
  Author: Rainer Orth <ro at gcc.gnu.org>
  Date:   2020-09-11 (Fri, 11 Sep 2020)

  Changed paths:
    M clang/lib/Basic/Targets/Sparc.cpp
    M clang/lib/Basic/Targets/Sparc.h
    M clang/lib/Driver/ToolChains/CommonArgs.cpp
    M clang/test/Preprocessor/predefined-arch-macros.c
    M compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
    M compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp

  Log Message:
  -----------
  [clang][Sparc] Default to -mcpu=v9 for Sparc V8 on Solaris

As reported in Bug 42535, `clang` doesn't inline atomic ops on 32-bit
Sparc, unlike `gcc` on Solaris.  In a 1-stage build with `gcc`, only two
testcases are affected (currently `XFAIL`ed), while in a 2-stage build more
than 100 tests `FAIL` due to this issue.

The reason for this `gcc`/`clang` difference is that `gcc` on 32-bit
Solaris/SPARC defaults to `-mpcu=v9` where atomic ops are supported, unlike
with `clang`'s default of `-mcpu=v8`.  This patch changes `clang` to use
`-mcpu=v9` on 32-bit Solaris/SPARC, too.

Doing so uncovered two bugs:

`clang -m32 -mcpu=v9` chokes with any Solaris system headers included:

  /usr/include/sys/isa_defs.h:461:2: error: "Both _ILP32 and _LP64 are defined"
  #error "Both _ILP32 and _LP64 are defined"

While `clang` currently defines `__sparcv9` in a 32-bit `-mcpu=v9`
compilation, neither `gcc` nor Studio `cc` do.  In fact, the Studio 12.6
`cc(1)` man page clearly states:

            These predefinitions are valid in all modes:
  [...]
               __sparcv8 (SPARC)
               __sparcv9 (SPARC -m64)

At the same time, the patch defines `__GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248]`
for a 32-bit Sparc compilation with any V9 cpu.  I've also changed
`MaxAtomicInlineWidth` for V9, matching what `gcc` does and the Oracle
Developer Studio 12.6: C User's Guide documents (Ch. 3, Support for Atomic
Types, 3.1 Size and Alignment of Atomic C Types).

The two testcases that had been `XFAIL`ed for Bug 42535 are un-`XFAIL`ed
again.

Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.

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