[clang] UEFI handle unsupported triples.

[Prabhuk]

The only architecture currently being supported (still a WIP) is
x86_64. Other UEFI triples targeting other architectures will now
report an unknown target triple error.

[llvmbot]

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Prabhuk (Prabhuk)

Changes

---

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

1 Files Affected:

• (modified) clang/lib/Driver/Driver.cpp (+2)

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 87855fdb799710..f1cd6353234a90 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -6677,6 +6677,8 @@ const ToolChain &Driver::getToolChain(const ArgList &Args,
       TC = std::make_unique<toolchains::AMDGPUToolChain>(*this, Target, Args);
       break;
     case llvm::Triple::UEFI:
+      if(Target.getArch() != llvm::Triple::x86_64)        
+        llvm::report_fatal_error("Currently the only architecture supported by *-uefi triples are x86_64.");
       TC = std::make_unique<toolchains::UEFI>(*this, Target, Args);
       break;
     case llvm::Triple::Win32:

[ilovepi]

This patch needs a test for the new driver logic. I'd also suggest adding some error handling in LLVM, so that it isn't possible to try an generate wrong code if this triple is supplied somewhere else (e.g. by another frontend or through opt).

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[rnk]

+1 for a test

[ilovepi]

LGTM. Lets try to follow up w/ something on the llvm side too though.