[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG76e85ae268f8: [clang][Sparc] Default to -mcpu=v9 for Sparc 
V8 on Solaris (authored by ro).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

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

Index: compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -11,9 +11,6 @@
 // FIXME: not %run %t 8 2>&1 | FileCheck %s --check-prefix=CHECK-8
 // RUN: not %run %t 9 2>&1 | FileCheck %s --check-prefix=CHECK-9
 
-// Bug 42535
-// XFAIL: sparc-target-arch
-
 // This test assumes float and double are IEEE-754 single- and double-precision.
 
 #if defined(__APPLE__)
Index: compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
===
--- compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
+++ compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
@@ -10,9 +10,6 @@
 RUN: llvm-cov gcov instrprof-gcov-parallel.target.gcda
 RUN: FileCheck --input-file instrprof-gcov-parallel.target.c.gcov %s
 
-# Bug 42535
-# XFAIL: sparc-target-arch
-
 # Test if the .gcda file is correctly created from one of child processes
 # and counters of all processes are recorded correctly.
 # 707 = CHILDREN * COUNT
Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3235,9 +3235,26 @@
 // RUN: -target sparc-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
 // CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9: #define __sparcv9__ 1
+
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
+
+// RUN: %clang -mcpu=v8 -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcel-unknown-linux \
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -347,6 +347,8 @@
   case llvm::Triple::sparcv9:
 if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";
 return "";
 
   case llvm::Triple::x86:
Index: clang/lib/Basic/Targets/Sparc.h
===
--- clang/lib/Basic/Targets/Sparc.h
+++ clang/lib/Basic/Targets/Sparc.h
@@ -166,10 +166,15 @@
   PtrDiffType = SignedLong;
   break;
 }
-// Up to 32 bits are lock-free atomic, but we're willing to do atomic ops
-// on up to 64 bits.
+// Up to 32 bits (V8) or 64 bits (V9) are lock-free atomic, but we're
+// willing to do atomic ops on up to 64 bits.
 MaxAtomicPromoteWidth = 64;
-MaxAtomicInlineWidth = 32;
+if (getCPUGeneration(CPU) == CG_V9)
+  MaxAtomicInlineWidth = 64;
+else
+  // FIXME: This isn't correct for plain V8 which lacks CAS,
+  // only for LEON 3+ and Myriad.
+  MaxAtomicInlineWidth = 32;
   }
 
   void getTargetDefines(const LangOptions ,
Index: clang/lib/Basic/Targets/Sparc.cpp

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma accepted this revision.
efriedma added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

Ping?  It's been a week and AFAICT there's nothing left for me to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

Is there anything left to do to get approval?  Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 289658.
ro added a comment.

Add FIXME for SparcV8 `MaxAtomicInlineWidth`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

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

Index: compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -11,9 +11,6 @@
 // FIXME: not %run %t 8 2>&1 | FileCheck %s --check-prefix=CHECK-8
 // RUN: not %run %t 9 2>&1 | FileCheck %s --check-prefix=CHECK-9
 
-// Bug 42535
-// XFAIL: sparc-target-arch
-
 // This test assumes float and double are IEEE-754 single- and double-precision.
 
 #if defined(__APPLE__)
Index: compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
===
--- compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
+++ compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
@@ -10,9 +10,6 @@
 RUN: llvm-cov gcov instrprof-gcov-parallel.target.gcda
 RUN: FileCheck --input-file instrprof-gcov-parallel.target.c.gcov %s
 
-# Bug 42535
-# XFAIL: sparc-target-arch
-
 # Test if the .gcda file is correctly created from one of child processes
 # and counters of all processes are recorded correctly.
 # 707 = CHILDREN * COUNT
Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3233,9 +3233,26 @@
 // RUN: -target sparc-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
 // CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9: #define __sparcv9__ 1
+
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
+
+// RUN: %clang -mcpu=v8 -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcel-unknown-linux \
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -347,6 +347,8 @@
   case llvm::Triple::sparcv9:
 if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";
 return "";
 
   case llvm::Triple::x86:
Index: clang/lib/Basic/Targets/Sparc.h
===
--- clang/lib/Basic/Targets/Sparc.h
+++ clang/lib/Basic/Targets/Sparc.h
@@ -166,10 +166,15 @@
   PtrDiffType = SignedLong;
   break;
 }
-// Up to 32 bits are lock-free atomic, but we're willing to do atomic ops
-// on up to 64 bits.
+// Up to 32 bits (V8) or 64 bits (V9) are lock-free atomic, but we're
+// willing to do atomic ops on up to 64 bits.
 MaxAtomicPromoteWidth = 64;
-MaxAtomicInlineWidth = 32;
+if (getCPUGeneration(CPU) == CG_V9)
+  MaxAtomicInlineWidth = 64;
+else
+  // FIXME: This isn't correct for plain V8 which lacks CAS,
+  // only for LEON 3+ and Myriad.
+  MaxAtomicInlineWidth = 32;
   }
 
   void getTargetDefines(const LangOptions ,
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -147,19 +147,20 @@
 void 

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

ro wrote:
> efriedma wrote:
> > ro wrote:
> > > efriedma wrote:
> > > > ro wrote:
> > > > > efriedma wrote:
> > > > > > ro wrote:
> > > > > > > efriedma wrote:
> > > > > > > > This probably should be refactored so the target-independent 
> > > > > > > > code generates it based on MaxAtomicInlineWidth, instead of 
> > > > > > > > duplicating it for each target.  But I guess you don't need to 
> > > > > > > > do that here.
> > > > > > > > 
> > > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > > > should only guard the definition of 
> > > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > > > > This probably should be refactored so the target-independent 
> > > > > > > > code generates it based on MaxAtomicInlineWidth, instead of 
> > > > > > > > duplicating it for each target.  But I guess you don't need to 
> > > > > > > > do that here.
> > > > > > > 
> > > > > > > Good: one issue at a time ;-)
> > > > > > > 
> > > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > > > should only guard the definition of 
> > > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > > > 
> > > > > > > I don't think so: at least `gcc` defines none of the four with 
> > > > > > > `-m32 -mcpu=v8` and all with `-m32 -mcpu=v9`.
> > > > > > This code, the code that sets MaxAtomicInlineWidth, and the code 
> > > > > > inSPARCISelLowering.cpp that calls 
> > > > > > setMaxAtomicSizeInBitsSupported() all need to agree about the 
> > > > > > supported atomic operations.
> > > > > > 
> > > > > > I guess the current setting of MaxAtomicInlineWidth is wrong?
> > > > > I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while 
> > > > > `clang-11 -m32 -mcpu=v9` doesn't.
> > > > Oh, hmm, it looks like the backend's support for 32-bit v9 is really 
> > > > limited; we basically generate v8 code, with a couple limited 
> > > > exceptions.  Probably okay to make clang assume 64-bit atomics are 
> > > > actually supported, even if we don't inline the implementation at the 
> > > > moment; they should still behave correctly.
> > > > 
> > > > I was more wondering about what we do for v8: we set 
> > > > MaxAtomicInlineWidth to 32, but I don't think it supports atomic 
> > > > cmpxchg at all.
> > > I've now found [[http://temlib.org/pub/SparcStation/Standards/V8plus.pdf 
> > > | The V8+ Technical Specification ]].  I've not checked how far LLVM 
> > > makes use of that, though (gcc seems to be pretty extensive, and it 
> > > certainly makes use of `casx` for v8plus).
> > > 
> > > I'm not really clear on the semantics of `MaxAtomicInlineWidth`: 
> > > `TargetInfo.h`'s description of `getMaxAtomicInlineWidth` only states
> > > ```
> > >   /// Return the maximum width lock-free atomic operation which can be
> > >   /// inlined given the supported features of the given target.
> > > ```
> > > which would be satisfied given that **some** 32-bit atomic ops are 
> > > inlined for v8.
> > > 
> > > 
> > The definition of C atomic operations requires that we only expose 
> > lock-free atomic operations on targets that have a lock-free cmpxchg.  This 
> > is necessary to allow the implementation in libatomic to work: even if an 
> > operation is "atomic", it wouldn't correctly honor the libatomic locks.
> > 
> > Note that the dynamic component of libatomic allows using lockfree 
> > operations in a "v8plus" environment. The libatomic implementation should 
> > dynamically check whether the CPU supports casx, and use lock-free 
> > operations if it does.
> Honestly, I don't see this as my job, though: the issue is pre-existing, it 
> doesn't affect any of my targets and I see that GCC's libatomic forces 
> `-mcpu=v9` for the 32-bit sparc library.
If you don't want to touch it, please leave a FIXME so the next person looking 
at this code has a reference.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

efriedma wrote:
> ro wrote:
> > efriedma wrote:
> > > ro wrote:
> > > > efriedma wrote:
> > > > > ro wrote:
> > > > > > efriedma wrote:
> > > > > > > This probably should be refactored so the target-independent code 
> > > > > > > generates it based on MaxAtomicInlineWidth, instead of 
> > > > > > > duplicating it for each target.  But I guess you don't need to do 
> > > > > > > that here.
> > > > > > > 
> > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > > should only guard the definition of 
> > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > > > This probably should be refactored so the target-independent code 
> > > > > > > generates it based on MaxAtomicInlineWidth, instead of 
> > > > > > > duplicating it for each target.  But I guess you don't need to do 
> > > > > > > that here.
> > > > > > 
> > > > > > Good: one issue at a time ;-)
> > > > > > 
> > > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > > should only guard the definition of 
> > > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > > 
> > > > > > I don't think so: at least `gcc` defines none of the four with 
> > > > > > `-m32 -mcpu=v8` and all with `-m32 -mcpu=v9`.
> > > > > This code, the code that sets MaxAtomicInlineWidth, and the code 
> > > > > inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() 
> > > > > all need to agree about the supported atomic operations.
> > > > > 
> > > > > I guess the current setting of MaxAtomicInlineWidth is wrong?
> > > > I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while 
> > > > `clang-11 -m32 -mcpu=v9` doesn't.
> > > Oh, hmm, it looks like the backend's support for 32-bit v9 is really 
> > > limited; we basically generate v8 code, with a couple limited exceptions. 
> > >  Probably okay to make clang assume 64-bit atomics are actually 
> > > supported, even if we don't inline the implementation at the moment; they 
> > > should still behave correctly.
> > > 
> > > I was more wondering about what we do for v8: we set MaxAtomicInlineWidth 
> > > to 32, but I don't think it supports atomic cmpxchg at all.
> > I've now found [[http://temlib.org/pub/SparcStation/Standards/V8plus.pdf | 
> > The V8+ Technical Specification ]].  I've not checked how far LLVM makes 
> > use of that, though (gcc seems to be pretty extensive, and it certainly 
> > makes use of `casx` for v8plus).
> > 
> > I'm not really clear on the semantics of `MaxAtomicInlineWidth`: 
> > `TargetInfo.h`'s description of `getMaxAtomicInlineWidth` only states
> > ```
> >   /// Return the maximum width lock-free atomic operation which can be
> >   /// inlined given the supported features of the given target.
> > ```
> > which would be satisfied given that **some** 32-bit atomic ops are inlined 
> > for v8.
> > 
> > 
> The definition of C atomic operations requires that we only expose lock-free 
> atomic operations on targets that have a lock-free cmpxchg.  This is 
> necessary to allow the implementation in libatomic to work: even if an 
> operation is "atomic", it wouldn't correctly honor the libatomic locks.
> 
> Note that the dynamic component of libatomic allows using lockfree operations 
> in a "v8plus" environment. The libatomic implementation should dynamically 
> check whether the CPU supports casx, and use lock-free operations if it does.
Honestly, I don't see this as my job, though: the issue is pre-existing, it 
doesn't affect any of my targets and I see that GCC's libatomic forces 
`-mcpu=v9` for the 32-bit sparc library.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

ro wrote:
> efriedma wrote:
> > ro wrote:
> > > efriedma wrote:
> > > > ro wrote:
> > > > > efriedma wrote:
> > > > > > This probably should be refactored so the target-independent code 
> > > > > > generates it based on MaxAtomicInlineWidth, instead of duplicating 
> > > > > > it for each target.  But I guess you don't need to do that here.
> > > > > > 
> > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > should only guard the definition of 
> > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > > This probably should be refactored so the target-independent code 
> > > > > > generates it based on MaxAtomicInlineWidth, instead of duplicating 
> > > > > > it for each target.  But I guess you don't need to do that here.
> > > > > 
> > > > > Good: one issue at a time ;-)
> > > > > 
> > > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > > should only guard the definition of 
> > > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > 
> > > > > I don't think so: at least `gcc` defines none of the four with `-m32 
> > > > > -mcpu=v8` and all with `-m32 -mcpu=v9`.
> > > > This code, the code that sets MaxAtomicInlineWidth, and the code 
> > > > inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() 
> > > > all need to agree about the supported atomic operations.
> > > > 
> > > > I guess the current setting of MaxAtomicInlineWidth is wrong?
> > > I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while 
> > > `clang-11 -m32 -mcpu=v9` doesn't.
> > Oh, hmm, it looks like the backend's support for 32-bit v9 is really 
> > limited; we basically generate v8 code, with a couple limited exceptions.  
> > Probably okay to make clang assume 64-bit atomics are actually supported, 
> > even if we don't inline the implementation at the moment; they should still 
> > behave correctly.
> > 
> > I was more wondering about what we do for v8: we set MaxAtomicInlineWidth 
> > to 32, but I don't think it supports atomic cmpxchg at all.
> I've now found [[http://temlib.org/pub/SparcStation/Standards/V8plus.pdf | 
> The V8+ Technical Specification ]].  I've not checked how far LLVM makes use 
> of that, though (gcc seems to be pretty extensive, and it certainly makes use 
> of `casx` for v8plus).
> 
> I'm not really clear on the semantics of `MaxAtomicInlineWidth`: 
> `TargetInfo.h`'s description of `getMaxAtomicInlineWidth` only states
> ```
>   /// Return the maximum width lock-free atomic operation which can be
>   /// inlined given the supported features of the given target.
> ```
> which would be satisfied given that **some** 32-bit atomic ops are inlined 
> for v8.
> 
> 
The definition of C atomic operations requires that we only expose lock-free 
atomic operations on targets that have a lock-free cmpxchg.  This is necessary 
to allow the implementation in libatomic to work: even if an operation is 
"atomic", it wouldn't correctly honor the libatomic locks.

Note that the dynamic component of libatomic allows using lockfree operations 
in a "v8plus" environment. The libatomic implementation should dynamically 
check whether the CPU supports casx, and use lock-free operations if it does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

efriedma wrote:
> ro wrote:
> > efriedma wrote:
> > > ro wrote:
> > > > efriedma wrote:
> > > > > This probably should be refactored so the target-independent code 
> > > > > generates it based on MaxAtomicInlineWidth, instead of duplicating it 
> > > > > for each target.  But I guess you don't need to do that here.
> > > > > 
> > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > should only guard the definition of 
> > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > > This probably should be refactored so the target-independent code 
> > > > > generates it based on MaxAtomicInlineWidth, instead of duplicating it 
> > > > > for each target.  But I guess you don't need to do that here.
> > > > 
> > > > Good: one issue at a time ;-)
> > > > 
> > > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check 
> > > > > should only guard the definition of 
> > > > > __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > 
> > > > I don't think so: at least `gcc` defines none of the four with `-m32 
> > > > -mcpu=v8` and all with `-m32 -mcpu=v9`.
> > > This code, the code that sets MaxAtomicInlineWidth, and the code 
> > > inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() all 
> > > need to agree about the supported atomic operations.
> > > 
> > > I guess the current setting of MaxAtomicInlineWidth is wrong?
> > I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while 
> > `clang-11 -m32 -mcpu=v9` doesn't.
> Oh, hmm, it looks like the backend's support for 32-bit v9 is really limited; 
> we basically generate v8 code, with a couple limited exceptions.  Probably 
> okay to make clang assume 64-bit atomics are actually supported, even if we 
> don't inline the implementation at the moment; they should still behave 
> correctly.
> 
> I was more wondering about what we do for v8: we set MaxAtomicInlineWidth to 
> 32, but I don't think it supports atomic cmpxchg at all.
I've now found [[http://temlib.org/pub/SparcStation/Standards/V8plus.pdf | The 
V8+ Technical Specification ]].  I've not checked how far LLVM makes use of 
that, though (gcc seems to be pretty extensive, and it certainly makes use of 
`casx` for v8plus).

I'm not really clear on the semantics of `MaxAtomicInlineWidth`: 
`TargetInfo.h`'s description of `getMaxAtomicInlineWidth` only states
```
  /// Return the maximum width lock-free atomic operation which can be
  /// inlined given the supported features of the given target.
```
which would be satisfied given that **some** 32-bit atomic ops are inlined for 
v8.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

ro wrote:
> efriedma wrote:
> > ro wrote:
> > > brad wrote:
> > > > ro wrote:
> > > > > efriedma wrote:
> > > > > > Do we want to make sparc and sparcel behave differently here?
> > > > > The only thing about little-endian SPARC is that UltraSPARC CPUs can 
> > > > > be run in little-endian  mode, presumably to ease a Windows NT port 
> > > > > that never materialized.
> > > > > 
> > > > > I could barely find any info on sparcel: the triplet isn't in 
> > > > > `config.guess`, there's very little else about such CPUs and 
> > > > > certainly no specification or even an ABI. That's why I tend to leave 
> > > > > sparcel-specific code alone unless someone who knows these beasts 
> > > > > tells me otherwise.
> > > > > 
> > > > > What I can say for certain that Solaris never ran on little-endian 
> > > > > SPARC.
> > > > "The Sparcle is an experimental 32-bit microprocessor chip developed in 
> > > > 1992 by a consortium of MIT, LSI Corporation, and Sun Microsystems. It 
> > > > was an evolution Sun's SPARC RISC architecture with features geared 
> > > > towards "large-scale multiprocessing".[1] The chip was manufactured by 
> > > > LSI."
> > > > 
> > > > https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf
> > > > 
> > > > From what little I can find I believe this prototype CPU / system was 
> > > > based on Linux.
> > > Ah, thanks.  So this predates Solaris 2.0 (also released in 1992). But 
> > > even if not, current Solaris 11 is SPARC V9-only.
> > > 
> > > However, if this is the only implementation, this bears the question why 
> > > support for such an experimental CPU almost 30 years old still lives in 
> > > LLVM.  It comes with a cost, if only for reasoning what needs and needs 
> > > not to be done to the V8el code.
> > The sparcv9 manual says the CPU has a little-endian mode; I assume that 
> > means all sparcv9 chips support it.  If nobody actually does that in 
> > practice, though, we should drop the sparcel target.
> Right.  However, that's a privileged operation AFAIU and non of the OSes I 
> know about (Solaris, Linux, the BSDs) run in little-endian mode.  Besides, it 
> would be weird to restrict oneself to the sparcv8 insns if one were using 
> that v9 facility.  On top of all that, gcc doesn't support the little-endian 
> mode at all.
Seems we missed something, though: 
[[https://ec.europa.eu/research/participants/documents/downloadPublic?documentIds=080166e5a6e0e311=PPGMS]]
 states (p.18):
```
6.3.5. Endianness
The Leon processors are both working in little endian same as the SHAVE 
processors. No extra requirements are needed to ensure endianess consistency.
```
Judging from that, Myriad is the primary user of sparcel these days.  So unless 
we can get rid of that, too, sparcel will have to stay.

The point of no available documentation remains, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

efriedma wrote:
> ro wrote:
> > brad wrote:
> > > ro wrote:
> > > > efriedma wrote:
> > > > > Do we want to make sparc and sparcel behave differently here?
> > > > The only thing about little-endian SPARC is that UltraSPARC CPUs can be 
> > > > run in little-endian  mode, presumably to ease a Windows NT port that 
> > > > never materialized.
> > > > 
> > > > I could barely find any info on sparcel: the triplet isn't in 
> > > > `config.guess`, there's very little else about such CPUs and certainly 
> > > > no specification or even an ABI. That's why I tend to leave 
> > > > sparcel-specific code alone unless someone who knows these beasts tells 
> > > > me otherwise.
> > > > 
> > > > What I can say for certain that Solaris never ran on little-endian 
> > > > SPARC.
> > > "The Sparcle is an experimental 32-bit microprocessor chip developed in 
> > > 1992 by a consortium of MIT, LSI Corporation, and Sun Microsystems. It 
> > > was an evolution Sun's SPARC RISC architecture with features geared 
> > > towards "large-scale multiprocessing".[1] The chip was manufactured by 
> > > LSI."
> > > 
> > > https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf
> > > 
> > > From what little I can find I believe this prototype CPU / system was 
> > > based on Linux.
> > Ah, thanks.  So this predates Solaris 2.0 (also released in 1992). But even 
> > if not, current Solaris 11 is SPARC V9-only.
> > 
> > However, if this is the only implementation, this bears the question why 
> > support for such an experimental CPU almost 30 years old still lives in 
> > LLVM.  It comes with a cost, if only for reasoning what needs and needs not 
> > to be done to the V8el code.
> The sparcv9 manual says the CPU has a little-endian mode; I assume that means 
> all sparcv9 chips support it.  If nobody actually does that in practice, 
> though, we should drop the sparcel target.
Right.  However, that's a privileged operation AFAIU and non of the OSes I know 
about (Solaris, Linux, the BSDs) run in little-endian mode.  Besides, it would 
be weird to restrict oneself to the sparcv8 insns if one were using that v9 
facility.  On top of all that, gcc doesn't support the little-endian mode at 
all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

ro wrote:
> brad wrote:
> > ro wrote:
> > > efriedma wrote:
> > > > Do we want to make sparc and sparcel behave differently here?
> > > The only thing about little-endian SPARC is that UltraSPARC CPUs can be 
> > > run in little-endian  mode, presumably to ease a Windows NT port that 
> > > never materialized.
> > > 
> > > I could barely find any info on sparcel: the triplet isn't in 
> > > `config.guess`, there's very little else about such CPUs and certainly no 
> > > specification or even an ABI. That's why I tend to leave sparcel-specific 
> > > code alone unless someone who knows these beasts tells me otherwise.
> > > 
> > > What I can say for certain that Solaris never ran on little-endian SPARC.
> > "The Sparcle is an experimental 32-bit microprocessor chip developed in 
> > 1992 by a consortium of MIT, LSI Corporation, and Sun Microsystems. It was 
> > an evolution Sun's SPARC RISC architecture with features geared towards 
> > "large-scale multiprocessing".[1] The chip was manufactured by LSI."
> > 
> > https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf
> > 
> > From what little I can find I believe this prototype CPU / system was based 
> > on Linux.
> Ah, thanks.  So this predates Solaris 2.0 (also released in 1992). But even 
> if not, current Solaris 11 is SPARC V9-only.
> 
> However, if this is the only implementation, this bears the question why 
> support for such an experimental CPU almost 30 years old still lives in LLVM. 
>  It comes with a cost, if only for reasoning what needs and needs not to be 
> done to the V8el code.
The sparcv9 manual says the CPU has a little-endian mode; I assume that means 
all sparcv9 chips support it.  If nobody actually does that in practice, 
though, we should drop the sparcel target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

ro wrote:
> efriedma wrote:
> > ro wrote:
> > > efriedma wrote:
> > > > This probably should be refactored so the target-independent code 
> > > > generates it based on MaxAtomicInlineWidth, instead of duplicating it 
> > > > for each target.  But I guess you don't need to do that here.
> > > > 
> > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should 
> > > > only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > > This probably should be refactored so the target-independent code 
> > > > generates it based on MaxAtomicInlineWidth, instead of duplicating it 
> > > > for each target.  But I guess you don't need to do that here.
> > > 
> > > Good: one issue at a time ;-)
> > > 
> > > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should 
> > > > only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > 
> > > I don't think so: at least `gcc` defines none of the four with `-m32 
> > > -mcpu=v8` and all with `-m32 -mcpu=v9`.
> > This code, the code that sets MaxAtomicInlineWidth, and the code 
> > inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() all 
> > need to agree about the supported atomic operations.
> > 
> > I guess the current setting of MaxAtomicInlineWidth is wrong?
> I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while `clang-11 
> -m32 -mcpu=v9` doesn't.
Oh, hmm, it looks like the backend's support for 32-bit v9 is really limited; 
we basically generate v8 code, with a couple limited exceptions.  Probably okay 
to make clang assume 64-bit atomics are actually supported, even if we don't 
inline the implementation at the moment; they should still behave correctly.

I was more wondering about what we do for v8: we set MaxAtomicInlineWidth to 
32, but I don't think it supports atomic cmpxchg at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

brad wrote:
> ro wrote:
> > efriedma wrote:
> > > Do we want to make sparc and sparcel behave differently here?
> > The only thing about little-endian SPARC is that UltraSPARC CPUs can be run 
> > in little-endian  mode, presumably to ease a Windows NT port that never 
> > materialized.
> > 
> > I could barely find any info on sparcel: the triplet isn't in 
> > `config.guess`, there's very little else about such CPUs and certainly no 
> > specification or even an ABI. That's why I tend to leave sparcel-specific 
> > code alone unless someone who knows these beasts tells me otherwise.
> > 
> > What I can say for certain that Solaris never ran on little-endian SPARC.
> "The Sparcle is an experimental 32-bit microprocessor chip developed in 1992 
> by a consortium of MIT, LSI Corporation, and Sun Microsystems. It was an 
> evolution Sun's SPARC RISC architecture with features geared towards 
> "large-scale multiprocessing".[1] The chip was manufactured by LSI."
> 
> https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf
> 
> From what little I can find I believe this prototype CPU / system was based 
> on Linux.
Ah, thanks.  So this predates Solaris 2.0 (also released in 1992). But even if 
not, current Solaris 11 is SPARC V9-only.

However, if this is the only implementation, this bears the question why 
support for such an experimental CPU almost 30 years old still lives in LLVM.  
It comes with a cost, if only for reasoning what needs and needs not to be done 
to the V8el code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

efriedma wrote:
> ro wrote:
> > efriedma wrote:
> > > This probably should be refactored so the target-independent code 
> > > generates it based on MaxAtomicInlineWidth, instead of duplicating it for 
> > > each target.  But I guess you don't need to do that here.
> > > 
> > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should 
> > > only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > > This probably should be refactored so the target-independent code 
> > > generates it based on MaxAtomicInlineWidth, instead of duplicating it for 
> > > each target.  But I guess you don't need to do that here.
> > 
> > Good: one issue at a time ;-)
> > 
> > > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should 
> > > only guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > 
> > I don't think so: at least `gcc` defines none of the four with `-m32 
> > -mcpu=v8` and all with `-m32 -mcpu=v9`.
> This code, the code that sets MaxAtomicInlineWidth, and the code 
> inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() all need 
> to agree about the supported atomic operations.
> 
> I guess the current setting of MaxAtomicInlineWidth is wrong?
I'd say so, yes: gcc -m32 inlines ops on `_Atomic long long` while `clang-11 
-m32 -mcpu=v9` doesn't.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

ro wrote:
> efriedma wrote:
> > This probably should be refactored so the target-independent code generates 
> > it based on MaxAtomicInlineWidth, instead of duplicating it for each 
> > target.  But I guess you don't need to do that here.
> > 
> > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should only 
> > guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> > This probably should be refactored so the target-independent code generates 
> > it based on MaxAtomicInlineWidth, instead of duplicating it for each 
> > target.  But I guess you don't need to do that here.
> 
> Good: one issue at a time ;-)
> 
> > From the other code, the `getCPUGeneration(CPU) == CG_V9` check should only 
> > guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> 
> I don't think so: at least `gcc` defines none of the four with `-m32 
> -mcpu=v8` and all with `-m32 -mcpu=v9`.
This code, the code that sets MaxAtomicInlineWidth, and the code 
inSPARCISelLowering.cpp that calls setMaxAtomicSizeInBitsSupported() all need 
to agree about the supported atomic operations.

I guess the current setting of MaxAtomicInlineWidth is wrong?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Brad Smith via Phabricator via cfe-commits]

brad added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

ro wrote:
> efriedma wrote:
> > Do we want to make sparc and sparcel behave differently here?
> The only thing about little-endian SPARC is that UltraSPARC CPUs can be run 
> in little-endian  mode, presumably to ease a Windows NT port that never 
> materialized.
> 
> I could barely find any info on sparcel: the triplet isn't in `config.guess`, 
> there's very little else about such CPUs and certainly no specification or 
> even an ABI. That's why I tend to leave sparcel-specific code alone unless 
> someone who knows these beasts tells me otherwise.
> 
> What I can say for certain that Solaris never ran on little-endian SPARC.
"The Sparcle is an experimental 32-bit microprocessor chip developed in 1992 by 
a consortium of MIT, LSI Corporation, and Sun Microsystems. It was an evolution 
Sun's SPARC RISC architecture with features geared towards "large-scale 
multiprocessing".[1] The chip was manufactured by LSI."

https://people.eecs.berkeley.edu/~kubitron/cs252/handouts/papers/sparcle-micro-final.pdf

From what little I can find I believe this prototype CPU / system was based on 
Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

In D86621#2249240 , @jrtc27 wrote:

> Actually, `__sparcv8` is only for V8; if you have 32-bit V9 on Solaris it 
> defines `__sparcv8plus` _instead_:
>
>   jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -xarch=v9 -m32 
> -xdumpmacros &1 | grep sparc
>   #define __sparcv8plus 1
>   #define __sparc 1
>   #define sparc 1

That's only true up to Studio 12.4: 12.5 and 12.6 define both `__sparcv8` and 
`__sparcv8plus`, and strangely even the 12.4 and 12.3 `cc(1)` man pages only 
documents `__sparcv8` while 12.2 only has `__sparc`.  We could also define 
`__sparcv8plus`, but `gcc` doesn't do that, so it would only help people 
compiling with `cc`.

> In fact, -xarch=v9 + -m32 is a bit weird because -xarch=v9 implies -m64 so 
> the argument order matters, and the modern way to do it is (if you read the 
> man page, -xarch=sparc means V9 and -xarch=v9 is an alias for -m64 
> -xarch=sparc...):

Right; 12.5 and 12.6 `cc` even warn

  cc: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead



>   jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -m32 
> -xarch=sparc -xdumpmacros &1 | grep sparc
>   #define __sparcv8plus 1
>   #define __sparc 1
>   #define sparc 1
>
> (gcc211 on the GCC compile farm; any open-source developer can register, it's 
> not specific to GCC developers despite the name)

I do have a cfarm account already.  However, there's no need for that: I do 
have every version of Studio back to 11 installed locally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

Actually, `__sparcv8` is only for V8; if you have 32-bit V9 on Solaris it 
defines `__sparcv8plus` _instead_:

  jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -xarch=v9 -m32 
-xdumpmacros &1 | grep sparc
  #define __sparcv8plus 1
  #define __sparc 1
  #define sparc 1

In fact, -xarch=v9 + -m32 is a bit weird because -xarch=v9 implies -m64 so the 
argument order matters, and the modern way to do it is (if you read the man 
page, -xarch=sparc means V9 and -xarch=v9 is an alias for -m64 -xarch=sparc...):

  jrtc27@gcc-solaris11:~$ /opt/solarisstudio12.4/bin/cc -E - -m32 -xarch=sparc 
-xdumpmacros &1 | grep sparc
  #define __sparcv8plus 1
  #define __sparc 1
  #define sparc 1

(gcc211 on the GCC compile farm; any open-source developer can register, it's 
not specific to GCC developers despite the name)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro updated this revision to Diff 289128.
ro added a comment.

Define `__sparcv8` only on 32-bit Solaris/SPARC.
Update testcase.
Remove `XFAIL`s that only apply to `clang`/2-stage builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

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

Index: compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -11,9 +11,6 @@
 // FIXME: not %run %t 8 2>&1 | FileCheck %s --check-prefix=CHECK-8
 // RUN: not %run %t 9 2>&1 | FileCheck %s --check-prefix=CHECK-9
 
-// Bug 42535
-// XFAIL: sparc-target-arch
-
 // This test assumes float and double are IEEE-754 single- and double-precision.
 
 #if defined(__APPLE__)
Index: compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
===
--- compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
+++ compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
@@ -10,9 +10,6 @@
 RUN: llvm-cov gcov instrprof-gcov-parallel.target.gcda
 RUN: FileCheck --input-file instrprof-gcov-parallel.target.c.gcov %s
 
-# Bug 42535
-# XFAIL: sparc-target-arch
-
 # Test if the .gcda file is correctly created from one of child processes
 # and counters of all processes are recorded correctly.
 # 707 = CHILDREN * COUNT
Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3233,9 +3233,26 @@
 // RUN: -target sparc-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
 // CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9-NOT: #define __sparcv8__ 1
 // CHECK_SPARC-V9: #define __sparc_v9__ 1
 // CHECK_SPARC-V9: #define __sparcv9 1
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
+// CHECK_SPARC-V9: #define __sparcv9__ 1
+
+// RUN: %clang -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
+
+// RUN: %clang -mcpu=v8 -E -dM %s -o - 2>&1 \
+// RUN: -target sparc-sun-solaris \
+// RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
+// CHECK_SPARC_SOLARIS_GCC_ATOMICS-V8-NOT: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
 
 // RUN: %clang -E -dM %s -o - 2>&1 \
 // RUN: -target sparcel-unknown-linux \
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -347,6 +347,8 @@
   case llvm::Triple::sparcv9:
 if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";
 return "";
 
   case llvm::Triple::x86:
Index: clang/lib/Basic/Targets/Sparc.h
===
--- clang/lib/Basic/Targets/Sparc.h
+++ clang/lib/Basic/Targets/Sparc.h
@@ -166,10 +166,13 @@
   PtrDiffType = SignedLong;
   break;
 }
-// Up to 32 bits are lock-free atomic, but we're willing to do atomic ops
-// on up to 64 bits.
+// Up to 32 bits (V8) or 64 bits (V9) are lock-free atomic, but we're
+// willing to do atomic ops on up to 64 bits.
 MaxAtomicPromoteWidth = 64;
-MaxAtomicInlineWidth = 32;
+if (getCPUGeneration(CPU) == CG_V9)
+  MaxAtomicInlineWidth = 64;
+else
+  MaxAtomicInlineWidth = 32;
   }
 
   void getTargetDefines(const LangOptions ,
Index: clang/lib/Basic/Targets/Sparc.cpp
===
--- clang/lib/Basic/Targets/Sparc.cpp
+++ clang/lib/Basic/Targets/Sparc.cpp
@@ -147,19 +147,20 @@
 void 

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

In D86621#2247791 , @jrtc27 wrote:

> GCC on Linux defines `__sparc_v9__` even with `-m32`. I don't know what 
> Solaris does but please don't break other operating systems just because 
> Solaris has broken headers that conflate the CPU and the ABI.

I'd have sworn that I checked gcc on Linux/sparc64: must have been dreaming.

I quoted the relevant snippet of the Studio `cc(1)` man page which shows that 
Solaris compilers predefine `__sparcv8` for `-m32` and `__sparcv9` for `-m64`.  
I'd argue that the creators of the CPU, the OS, and the initial compiler can 
decide to do so as they please (after all, AFAICT that's not part of any ABI 
and I couldn't find an API document that mentioned those), nothing broken or 
conflated here.

I've now looked at the GCC sources and found:

- FreeBSD/sparc64 is 64-bit-only, no 32-bit support in sight
- while the NetBSD/sparc64 port still includes bi-arch support, it is disabled 
because the don't ship a 32-bit environment and even if they did, they only 
define `__sparc_v9__` etc. for `-m64`.
- OpenBSD/sparc64 again is 64-bit only

I'll see how best to reconcile those.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

In D86621#2247786 , @efriedma wrote:

> 



> For compiler-rt, the XFAILs should probably reflect whatever config the bot 
> is running.  (Alternatively, you could use UNSUPPORTED, but that doesn't seem 
> warranted here.)

That's been my guess, too (with the goal of getting the bot green eventually in 
mind).  Once the underlying `clang` bug is fixed, the tests will pass with both 
compilers, so I agree that `UNSUPPORTED` isn't warranted here.




Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

efriedma wrote:
> This probably should be refactored so the target-independent code generates 
> it based on MaxAtomicInlineWidth, instead of duplicating it for each target.  
> But I guess you don't need to do that here.
> 
> From the other code, the `getCPUGeneration(CPU) == CG_V9` check should only 
> guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?
> This probably should be refactored so the target-independent code generates 
> it based on MaxAtomicInlineWidth, instead of duplicating it for each target.  
> But I guess you don't need to do that here.

Good: one issue at a time ;-)

> From the other code, the `getCPUGeneration(CPU) == CG_V9` check should only 
> guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?

I don't think so: at least `gcc` defines none of the four with `-m32 -mcpu=v8` 
and all with `-m32 -mcpu=v9`.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

efriedma wrote:
> Do we want to make sparc and sparcel behave differently here?
The only thing about little-endian SPARC is that UltraSPARC CPUs can be run in 
little-endian  mode, presumably to ease a Windows NT port that never 
materialized.

I could barely find any info on sparcel: the triplet isn't in `config.guess`, 
there's very little else about such CPUs and certainly no specification or even 
an ABI. That's why I tend to leave sparcel-specific code alone unless someone 
who knows these beasts tells me otherwise.

What I can say for certain that Solaris never ran on little-endian SPARC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

And notably _doesn't_ define the V8 macros, which this patch then reintroduces.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 requested changes to this revision.
jrtc27 added a comment.
This revision now requires changes to proceed.

GCC on Linux defines `__sparc_v9__` even with `-m32`. I don't know what Solaris 
does but please don't break other operating systems just because Solaris has 
broken headers that conflate the CPU and the ABI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> While the fix proper is trivial: just two lines in 
> lib/Driver/ToolChains/CommonArgs.cpp, finding the right place has been 
> nightmarishly difficult: I'd have expected handling of a Solaris/SPARC CPU 
> default in either of Solaris or SPARC specific files, but not deeply hidden 
> in common code. I've come across issues like this over and over again: 
> configuration information in LLVM is spread all over the place, difficult to 
> find or just to know that it exists.

The clang driver is messy, yes.  Other places are pretty good about this, 
mostly.

For compiler-rt, the XFAILs should probably reflect whatever config the bot is 
running.  (Alternatively, you could use UNSUPPORTED, but that doesn't seem 
warranted here.)




Comment at: clang/lib/Basic/Targets/Sparc.cpp:224
+Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
+  }
 }

This probably should be refactored so the target-independent code generates it 
based on MaxAtomicInlineWidth, instead of duplicating it for each target.  But 
I guess you don't need to do that here.

From the other code, the `getCPUGeneration(CPU) == CG_V9` check should only 
guard the definition of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:350
   return A->getValue();
+if (T.getArch() == llvm::Triple::sparc && T.isOSSolaris())
+  return "v9";

Do we want to make sparc and sparcel behave differently here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added reviewers: venkatra, efriedma.
ro added a comment.
Herald added a subscriber: danielkiss.

Ping? It's been a week.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro added a comment.

While doing 2-stage builds, the 2 `XFAIL`s due to Bug 42493 were required.  
However, I've since also done a 1-stage build with gcc 10, which shows

  Unexpectedly Passed Tests (2):
UBSan-Standalone-sparc :: TestCases/Float/cast-overflow.cpp
UBSan-Standalone-sparc :: TestCases/Misc/log-path_test.cpp

which is no wonder since the underlying bug only exists in `clang` `long 
double` handling.

I'm a bit uncertain how to deal with this: since the Solaris/sparcv9 buildbot 
currently does 1-stage builds with gcc, the resulting `XPASS`es would turn the 
bot red.  However, currently there's no clang-vs.-gcc feature in `lit` to 
distinguish the two builds, AFAICT.  `libcxx` has something like this, but that 
might be overkill to extract.

Perhaps just remove the `XFAIL`s for now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

[Rainer Orth via Phabricator via cfe-commits]

ro created this revision.
ro added reviewers: brad, jyknight.
ro added a project: clang.
Herald added subscribers: Sanitizers, jfb, jrtc27, fedor.sergeev.
Herald added a reviewer: jfb.
Herald added a project: Sanitizers.
ro requested review of this revision.
Herald added a subscriber: dexonsmith.

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-bitSolaris/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. 
 However, one of those and another testcase now `FAIL` due to Bug 42493 and are 
thus `XFAIL`ed.

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

While the fix proper is trivial: just two lines in 
`lib/Driver/ToolChains/CommonArgs.cpp`, finding the right place has been 
nightmarishly difficult: I'd have expected handling of a Solaris/SPARC CPU 
default in either of Solaris or SPARC specific files, but not deeply hidden in 
common code.  I've come across issues like this over and over again: 
configuration information in LLVM is spread all over the place, difficult to 
find or just to know that it exists.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86621

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

Index: compiler-rt/test/ubsan/TestCases/Misc/log-path_test.cpp
===
--- compiler-rt/test/ubsan/TestCases/Misc/log-path_test.cpp
+++ compiler-rt/test/ubsan/TestCases/Misc/log-path_test.cpp
@@ -25,6 +25,9 @@
 // FIXME: log_path is not supported on Windows yet.
 // XFAIL: windows-msvc
 
+// Bug 42493
+// XFAIL: sparc-target-arch
+
 #include 
 #include 
 int main(int argc, char *argv[]) {
Index: compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
===
--- compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
+++ compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp
@@ -11,7 +11,7 @@
 // FIXME: not %run %t 8 2>&1 | FileCheck %s --check-prefix=CHECK-8
 // RUN: not %run %t 9 2>&1 | FileCheck %s --check-prefix=CHECK-9
 
-// Bug 42535
+// Bug 42493
 // XFAIL: sparc-target-arch
 
 // This test assumes float and double are IEEE-754 single- and double-precision.
Index: compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
===
--- compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
+++ compiler-rt/test/profile/Posix/instrprof-gcov-parallel.test
@@ -10,9 +10,6 @@
 RUN: llvm-cov gcov instrprof-gcov-parallel.target.gcda
 RUN: FileCheck --input-file instrprof-gcov-parallel.target.c.gcov %s
 
-# Bug 42535
-# XFAIL: sparc-target-arch
-
 # Test if the .gcda file is correctly created from one of child processes
 # and counters of all processes are recorded correctly.
 # 707 = CHILDREN * COUNT
Index: clang/test/Preprocessor/predefined-arch-macros.c
===
--- clang/test/Preprocessor/predefined-arch-macros.c
+++ clang/test/Preprocessor/predefined-arch-macros.c
@@ -3232,10 +3232,26 @@
 // RUN: %clang -mcpu=v9 -E -dM %s -o - 2>&1 \
 // RUN: -target sparc-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefix=CHECK_SPARC-V9
-// CHECK_SPARC-V9-NOT: #define __sparcv8 1
-// CHECK_SPARC-V9: #define __sparc_v9__ 1
-// CHECK_SPARC-V9: #define