Allow building LLVM 13 with newer compilers

[samestep]

Currently external/build-llvm.sh works with GCC 11 which we use in CI, but does not work with GCC 13 or newer:

In file included from /home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/lib/Support/Signals.cpp:14:
/home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/include/llvm/Support/Signals.h:119:24: error: unknown type name 'uintptr_t'; did you mean '__intptr_t'?
  119 |   void CleanupOnSignal(uintptr_t Context);
      |                        ^~~~~~~~~
      |                        __intptr_t

And also does not work with any version of Clang that I've tried, including Clang 12 and Clang 13 (although I don't quite understand why Clang 13 wouldn't be able to build itself):

In file included from /home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/lib/Support/Signals.cpp:14:
/home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/include/llvm/Support/Signals.h:119:8: error: variable or field 'CleanupOnSignal' declared void
  119 |   void CleanupOnSignal(uintptr_t Context);
      |        ^~~~~~~~~~~~~~~
/home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/include/llvm/Support/Signals.h:119:24: error: 'uintptr_t' was not declared in this scope
  119 |   void CleanupOnSignal(uintptr_t Context);
      |                        ^~~~~~~~~
/home/saestep/github/shader-slang/slang/build/slang-llvm_src/llvm/include/llvm/Support/Signals.h:18:1: note: 'uintptr_t' is defined in header '<cstdint>'; this is probably fixable by adding '#include <cstdint>'
   17 | #include <string>
  +++ |+#include <cstdint>
   18 |

This is because GCC 13 started requiring explicit #include <cstdint>, which was not added to llvm/include/llvm/Support/Signals.h until llvm/llvm-project@ff1681d a few months after the llvmorg-13.0.1 tag.

This PR allows LLVM 13 to be built with Clang, and with newer versions of GCC, by implicitly including <cstdint>.

[jkwak-work]

Shouldn't we add this line somewhere in the source code rather than in cmake?

[samestep]

@jkwak-work you mean, in the LLVM source code?

[jkwak-work]

It seems like this issue was addressed a while ago

• Backport missing #include <cstdint> for upcomit gcc-13 to stable branch llvm/llvm-project#55711

Maybe we should use a newer version of LLVM?

Claude Code told me the following,

● Based on my research, the minimal LLVM version bump needed to fix the uintptr_t/cstdint issue is llvmorg-14.0.5.

Here's what I found:

The Issue

• LLVM 13.0.1 (currently used by Slang) has missing #include headers
• This causes compilation failures with newer compilers like GCC 13 and newer Clang versions
• The error manifests as 'uintptr_t' was not declared in this scope and similar issues

The Fix

• Commits: ff1681d and 5e9be93 added the missing #include headers
• Target Version: These fixes were targeted for LLVM 14.0.5 milestone
• Release Date: LLVM 14.0.5 was released on June 11, 2022

Recommendation

Update the Slang build script from:
branch=llvmorg-13.0.1
to:
branch=llvmorg-14.0.5

This is the closest version to 13.0.1 that includes the GCC 13 compatibility fixes. LLVM 14.0.5 was specifically a bug-fix release that maintained API/ABI compatibility with 14.0.0,
making it a safer upgrade path than jumping to a much newer major version.

This approach is much cleaner than the CMake workaround in PR #8028 and addresses the root cause rather than just patching the symptoms.

[samestep]

@jkwak-work yes, I already linked to llvm/llvm-project@ff1681d in my PR description above.

I have no problem with upgrading our LLVM dependency, but I don't know what that would break in Slang, so I didn't try it.

[samestep]

@jkwak-work I see a couple other instances of LLVM 13 mentioned in our codebase:

• external/glslang/kokoro/linux-clang-cmake/build-docker.sh
• external/spirv-tools/kokoro/scripts/linux/build-docker.sh

Would this mean we'd need to update our dependencies on glslang and SPIR-V Tools too?

[samestep]

Also, would updating LLVM constitute a breaking change or a non-breaking change?

[samestep]

I opened #8031 with an attempt to upgrade from LLVM 13 to LLVM 14; seems to work after some minor changes.

[csyonghe]

Nothing should break for an LLVM update. We use LLVM at a very coarse granularity.

[samestep]

Makes sense.

I wasn't sure what LLVM version we actually want to upgrade to, so I just made PRs for all of them, so we can choose whichever we prefer:

• Update LLVM from 13.0.1 to 14.0.6 #8031
  • seems to just work
• Update LLVM from 13.0.1 to 15.0.7 #8035
  • works on Linux and Mac but not Windows for some reason; would appreciate help debugging the Windows build here
• Update LLVM from 13.0.1 to 16.0.6 #8036
  • same situation as LLVM 15
• Update LLVM from 13.0.1 to 17.0.6 #8034
  • same Windows build failure as previous ones, but also some tests are failing even on Linux; marked as draft for now
• Update LLVM from 13.0.1 to 18.1.8 #8038
  • same situation as LLVM 17
• Update LLVM from 13.0.1 to 19.1.7 #8039
  • fails to even run CMake on LLVM
• Update LLVM from 13.0.1 to 20.1.8 #8033
  • same situation as LLVM 19

[csyonghe]

Closing this PR, since we have decided to upgrade to LLVM 14.6 PR which won't have this problem.