[clang] Fix name conflict with sys/mac.h on AIX

[Endilll]

Fixes clang-ppc64-aix bot failure after #88559 (0a6f6df) https://lab.llvm.org/buildbot/#/builders/214/builds/11887

[llvmbot]

@llvm/pr-subscribers-clang

Author: Vlad Serebrennikov (Endilll)

Changes

Fixes clang-ppc64-aix bot failure after #88559 (0a6f6df) https://lab.llvm.org/buildbot/#/builders/214/builds/11887

---

Full diff: https://github.com/llvm/llvm-project/pull/88644.diff

1 Files Affected:

• (modified) clang/include/clang/Basic/Cuda.h (+5)

diff --git a/clang/include/clang/Basic/Cuda.h b/clang/include/clang/Basic/Cuda.h
index acc6bb6581d857..3908e10bc61061 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -50,6 +50,11 @@ const char *CudaVersionToString(CudaVersion V);
 // Input is "Major.Minor"
 CudaVersion CudaStringToVersion(const llvm::Twine &S);
 
+// We have a name conflict with sys/mac.h on AIX
+#ifdef _AIX
+#undef SM_32
+#endif
+
 enum class CudaArch {
   UNUSED,
   UNKNOWN,

[jhuber6]

I can't really think of anything more clever here unfortunately and we should probably unbreak the bot. Maybe someone more familiar with PowerPC knows if it's possible to simply not include this header somewhere.

[Artem-B]

Ugh. What could possibly go wrong, if someone who needed the original definition of SM_32 ends up transitively including this header and losing the macro definition?

A better way to handle it as a workaround would be to push the macro definition, undef it, and then pop it back at the end of the header.

Even better would be to add prefixes to the macros and/or the enum here to disambiguate them

[jhuber6]

We already do that, the problem is that CudaArch::SM_32 will still invoke the preprocessorr, see https://godbolt.org/z/84xKej5K9. We can't do this from a header level, we'd need to do it around every single use as far as I know, which might be doable?

[jhuber6]

We could always just make all of these lower case instead?

[Artem-B]

We could always just make all of these lower case instead?

That would be odd. LLVM style wants them to be CamelCased.
This enum is rarely used, so renaming them to something more CUDA/NVPTXspecific would be best, IMO.
E.g NVSM_32

Or we could rename only SM_32. The constant is rather inconsequential and is used in a few places only. Renaming it to _SM_32 with a comment that AIX headers have SM_32 defined.

[jhuber6]

I mean, modern CUDA installations don't even allow you to build for anything older than sm_52 now. We could also just delete those enums entirely.

[jhuber6]

Just naming it like _SM_32 works for me, with a note that they'll get removed in the future. I can make the PR if you want.

[AaronBallman]

_SM_32 is a reserved identifier so we should not use that as a name.

[jhuber6]

Good point, totally forgot that _<uppercase> was reserved (Would've been nice if the AIX headers followed that rule).

[Artem-B]

SGTM. Thank you for taking care of this issue.

On a side note, do we know if there's a way to file a bug for AIX? They should not be setting macros with names that could conceivably be defined by a user. In theory. I think normally they should be double-underscore-prefixed.

[jhuber6]

Done in #88779