[Xtensa] Default to unsigned char

[arichardson]

This matches GCC.

Partially addresses #115964

[llvmbot]

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Alexander Richardson (arichardson)

Changes

This matches GCC.

Partially fixes #115964

---

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

2 Files Affected:

• (modified) clang/lib/Driver/ToolChains/Clang.cpp (+1)
• (added) clang/test/Driver/xtensa-char.c (+4)

diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 0952262c360185..29954bfbc560c1 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -1347,6 +1347,7 @@ static bool isSignedCharDefault(const llvm::Triple &Triple) {
   case llvm::Triple::riscv64:
   case llvm::Triple::systemz:
   case llvm::Triple::xcore:
+  case llvm::Triple::xtensa:
     return false;
   }
 }
diff --git a/clang/test/Driver/xtensa-char.c b/clang/test/Driver/xtensa-char.c
new file mode 100644
index 00000000000000..13f8f67727e75d
--- /dev/null
+++ b/clang/test/Driver/xtensa-char.c
@@ -0,0 +1,4 @@
+/// Check that char is unsigned by default.
+// RUN: %clang -### %s --target=xtensa -c 2>&1 | FileCheck %s
+// CHECK: "-cc1" "-triple" "xtensa"
+// CHECK-SAME: "-fno-signed-char"

[brad0]

cc @andreisfr

[gerekon]

Looks like it is related to #118008

[gerekon]

Hi @arichardson.

Thanks for this change. Acc to the doc which I have The char type is unsigned by default for Xtensa processors. Our GCC Xtensa toolchain also interprets char type as unsigned by default.

[arichardson]

Hi @arichardson.

Thanks for this change. Acc to the doc which I have The char type is unsigned by default for Xtensa processors. Our GCC Xtensa toolchain also interprets char type as unsigned by default.

Thanks, do you believe we need a backwards compatibility flag for the ABI to be consistent with older clang or is this safe to land?

[gerekon]

Thanks, do you believe we need a backwards compatibility flag for the ABI to be consistent with older clang or is this safe to land?

I think as far as we can control behavior with -fsigned-char we do not need another option for this.

@MabezDev WDYT? Will it be critical for Rust builds? After that Xtensa behavior will be in sync with RISCV.

[arichardson]

Looking at #118008 it sounds like we don't yet have complete codegen support for XTensa in Clang, so it sounds like this is safe without a flag.

[gerekon]

Looking at #118008 it sounds like we don't yet have complete codegen support for XTensa in Clang, so it sounds like this is safe without a flag.

Yes, it is not upstreamed yet. We are working on it. But after rebasing on the LLVM 20 we might get this fix in our repo, so that will influence our Clang toolchain and Rust, Swift ones. So I asked @MabezDev if he sees any potential problems with this.

Sorry my bad. This is related to Clang only. Neither Rust nor Swift will be influenced.