Re: [PATCH] D58326: [Driver][Gnu] Support -nolibc flag

[Roland McGrath via cfe-commits]

See
https://fuchsia.googlesource.com/fuchsia/+/48c987febf4077e52985f1ce1edc957b39bc5481/zircon/public/gn/config/BUILD.gn#219
and
https://fuchsia.googlesource.com/fuchsia/+/48c987febf4077e52985f1ce1edc957b39bc5481/zircon/public/gn/config/libc-dummy
for what happens without it...

On Sat, Feb 16, 2019 at 5:29 PM Eric Christopher  wrote:

> Weird. Ok.
>
> On Sat, Feb 16, 2019, 5:20 PM Petr Hosek via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> phosek created this revision.
>> phosek added reviewers: echristo, mcgrathr.
>> Herald added a project: clang.
>> Herald added a subscriber: cfe-commits.
>>
>> This can be used to disable libc linking. This flag is supported by
>> GCC since version 9 as well as some Clang target toolchains.
>>
>>
>> Repository:
>>   rC Clang
>>
>> https://reviews.llvm.org/D58326
>>
>> Files:
>>   clang/lib/Driver/ToolChains/Gnu.cpp
>>   clang/test/Driver/nodefaultlib.c
>>   clang/test/Driver/nolibc.c
>>
>>
>> Index: clang/test/Driver/nolibc.c
>> ===
>> --- /dev/null
>> +++ clang/test/Driver/nolibc.c
>> @@ -0,0 +1,5 @@
>> +// RUN: %clang -target i686-pc-linux-gnu -### -rtlib=libgcc -nolibc %s
>> 2>&1 | FileCheck %s
>> +// CHECK: crtbegin
>> +// CHECK: "-lgcc"
>> +// CHECK-NOT: "-lc"
>> +// CHECK: crtend
>> Index: clang/test/Driver/nodefaultlib.c
>> ===
>> --- clang/test/Driver/nodefaultlib.c
>> +++ clang/test/Driver/nodefaultlib.c
>> @@ -1,4 +1,4 @@
>> -// RUN: %clang -target i686-pc-linux-gnu -### -nodefaultlibs %s 2>&1 |
>> FileCheck -check-prefix=TEST1 %s
>> +// RUN: %clang -target i686-pc-linux-gnu -### -rtlib=libgcc
>> -nodefaultlibs %s 2>&1 | FileCheck -check-prefix=TEST1 %s
>>  // TEST1-NOT: start-group
>>  // TEST1-NOT: "-lgcc"
>>  // TEST1-NOT: "-lc"
>> Index: clang/lib/Driver/ToolChains/Gnu.cpp
>> ===
>> --- clang/lib/Driver/ToolChains/Gnu.cpp
>> +++ clang/lib/Driver/ToolChains/Gnu.cpp
>> @@ -518,7 +518,8 @@
>>if (Args.hasArg(options::OPT_fsplit_stack))
>>  CmdArgs.push_back("--wrap=pthread_create");
>>
>> -  CmdArgs.push_back("-lc");
>> +  if (!Args.hasArg(options::OPT_nolibc))
>> +CmdArgs.push_back("-lc");
>>
>>// Add IAMCU specific libs, if needed.
>>if (IsIAMCU)
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Provide `-fno-/-fvisibility-global-new-delete` option (PR #75364)

[Roland McGrath via cfe-commits]

frobtech wrote:

The meaning that we want to make clear is that this toggles the special 
behavior of forcing the visibility of these symbols despite all the other 
mechanisms that usually control visibility for all other symbols.  So perhaps 
`-fforced-global-new-delete-visibility` (or even 
`-fforced-global-new-delete-visibility=default`) describes the status quo ante, 
and `-fno-forced-global-new-delete-visibility` describes the new opt-in wherein 
these symbols are not treated differently than others. (The `=...` variant of 
the positive form would permit forcing to a different visibility than 
`default`, though I'm not sure there's a real need for that capability since in 
`-fno-forced-...` state the usual pragmas et al can arrange for that.)



https://github.com/llvm/llvm-project/pull/75364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Sema] Provide `-fno-/-fvisibility-global-new-delete` option (PR #75364)

[Roland McGrath via cfe-commits]

frobtech wrote:

> Actually I kind of prefer all these options to have `-fvisibility-` as a 
> prefix. Even if it doesn't read quite naturally, it strongly implies that the 
> options are related (which is true) and any lexically sorted list of options 
> will naturally group them together. WDYT @frobtech ?

I don't have a strong opinion about the exact spelling. I just recommend that 
it be as unambiguous as possible, and the use of "forced" in the name seems 
like a good way to help with that.

https://github.com/llvm/llvm-project/pull/75364
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1a963d3 - [Driver] Make -moutline-atomics default for aarch64-fuchsia targets

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2022-03-28T16:51:55-07:00
New Revision: 1a963d3278c2daab7e12125371442cd129c09954

URL: 
https://github.com/llvm/llvm-project/commit/1a963d3278c2daab7e12125371442cd129c09954
DIFF: 
https://github.com/llvm/llvm-project/commit/1a963d3278c2daab7e12125371442cd129c09954.diff

LOG: [Driver] Make -moutline-atomics default for aarch64-fuchsia targets

This makes Fuchsia consistent with Linux on AArch64.

Reviewed By: abrachet

Differential Revision: https://reviews.llvm.org/D122613

Added: 


Modified: 
clang/lib/Driver/ToolChains/Fuchsia.h
clang/test/Driver/fuchsia.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.h 
b/clang/lib/Driver/ToolChains/Fuchsia.h
index c0e69df228219..f9f3bbfa9fbfe 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.h
+++ b/clang/lib/Driver/ToolChains/Fuchsia.h
@@ -75,24 +75,27 @@ class LLVM_LIBRARY_VISIBILITY Fuchsia : public ToolChain {
 
   RuntimeLibType
   GetRuntimeLibType(const llvm::opt::ArgList &Args) const override;
-  CXXStdlibType
-  GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
+  CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const 
override;
+
+  bool IsAArch64OutlineAtomicsDefault(
+  const llvm::opt::ArgList &Args) const override {
+return true;
+  }
 
-  void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
- llvm::opt::ArgStringList &CC1Args,
- Action::OffloadKind DeviceOffloadKind) const 
override;
+  void
+  addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args,
+Action::OffloadKind DeviceOffloadKind) const override;
   void
   AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
 llvm::opt::ArgStringList &CC1Args) const override;
-  void
-  AddClangCXXStdlibIncludeArgs(const llvm::opt::ArgList &DriverArgs,
-   llvm::opt::ArgStringList &CC1Args) const 
override;
+  void AddClangCXXStdlibIncludeArgs(
+  const llvm::opt::ArgList &DriverArgs,
+  llvm::opt::ArgStringList &CC1Args) const override;
   void AddCXXStdlibLibArgs(const llvm::opt::ArgList &Args,
llvm::opt::ArgStringList &CmdArgs) const override;
 
-  const char *getDefaultLinker() const override {
-return "ld.lld";
-  }
+  const char *getDefaultLinker() const override { return "ld.lld"; }
 
 protected:
   Tool *buildLinker() const override;

diff  --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index 3e8d7211a4e96..888f6b1a2c4b7 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -34,6 +34,7 @@
 // CHECK-AARCH64: "-fsanitize=shadow-call-stack"
 // CHECK-X86_64: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
+// CHECK-AARCH64: "-target-feature" "+outline-atomics"
 // CHECK-NOT: "-fcommon"
 // CHECK: {{.*}}ld.lld{{.*}}" "-z" "max-page-size=4096" "-z" "now" "-z" 
"rodynamic" "-z" "separate-loadable-segments" "-z" "rel" 
"--pack-dyn-relocs=relr"
 // CHECK: "--sysroot=[[SYSROOT]]"



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

[clang] [llvm] [X86] Add Support for X86 TLSDESC Relocations (PR #83136)

[Roland McGrath via cfe-commits]

@@ -0,0 +1,165 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py 
UTC_ARGS: --version 4
+; RUN: llc < %s -mtriple=i686-unknown-unknown --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-pc-linux-gnux32 --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X32
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X64
+
+@x = thread_local global i32 0, align 4
+@y = internal thread_local global i32 0, align 4

frobtech wrote:

That example allows the variables to be optimized out entirely because there's 
no way they can ever be modified. https://godbolt.org/z/63oz4xrj1 shows an 
example where it's generating LD model accesses.

Note that in some cases I've seen GCC generate a local anchor symbol instead of 
using `_TLS_MODULE_BASE_`. That is less optimal than using `_TLS_MODULE_BASE_`, 
because multiple uses of `_TLS_MODULE_BASE_` across multiple TUs can be 
resolved by the linker to a single GOT slot (pair), whereas a local anchor 
symbol will always have its own GOT slot (pair) that won't be shared with any 
other TU.

https://github.com/llvm/llvm-project/pull/83136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [X86] Add Support for X86 TLSDESC Relocations (PR #83136)

[Roland McGrath via cfe-commits]

@@ -0,0 +1,165 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py 
UTC_ARGS: --version 4
+; RUN: llc < %s -mtriple=i686-unknown-unknown --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-pc-linux-gnux32 --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X32
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown --relocation-model=pic 
-enable-tlsdesc | FileCheck %s --check-prefix=X64
+
+@x = thread_local global i32 0, align 4
+@y = internal thread_local global i32 0, align 4

frobtech wrote:

I think it's worthwhile to have test cases that are `dso_local` but not 
internal linkage as well, and mixing the two.  These can and should also use 
`_TLS_MODULE_BASE_` with the secondary `dtpoff` offset after the TLSDESC call 
returns. e.g.
```
extern __thread int x __attribute__((visibility("hidden")));
static __thread int y;
int foo() { return ++x + ++y; }
```

The ideal thing is probably *not* to use `_TLS_MODULE_BASE_` when its result is 
used only once in the function, regardless of the linkage details of the 
referenced TLS symbol.  That's because a second addition with the `dtpoff` 
value will always be needed for that. If it's a case where that addition is 
"free", e.g. because it can be rolled into the displacement of a load you're 
doing anyway, then using `_TLS_MODULE_BASE_` is ideal even if it's the only use 
in the function (because the GOT slot & relocs will be shared with any other 
such use in the whole link).  However, if it requires an extra instruction to 
do the add after the TLSDESC call returns, then it's probably better overall to 
have the separate reloc for just that access.

https://github.com/llvm/llvm-project/pull/83136
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] cf36142 - [clang] Add missing header guard in

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2020-11-10T19:34:25-08:00
New Revision: cf36142d342a46689007df3b508b2ef059d76e46

URL: 
https://github.com/llvm/llvm-project/commit/cf36142d342a46689007df3b508b2ef059d76e46
DIFF: 
https://github.com/llvm/llvm-project/commit/cf36142d342a46689007df3b508b2ef059d76e46.diff

LOG: [clang] Add missing header guard in 

This header has long lacked a standard multiple inclusion guard
like other headers have, for no apparent reason.  The GCC header
of the same name likewise lacks one up through release 10.1, but
trunk GCC (release 11, and perhaps future 10.x) has fixed it
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96238).

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D91226

Added: 


Modified: 
clang/lib/Headers/cpuid.h
clang/test/Headers/cpuid.c

Removed: 




diff  --git a/clang/lib/Headers/cpuid.h b/clang/lib/Headers/cpuid.h
index c903c3adf981..34f0e76807c5 100644
--- a/clang/lib/Headers/cpuid.h
+++ b/clang/lib/Headers/cpuid.h
@@ -7,6 +7,9 @@
  *===---===
  */
 
+#ifndef __CPUID_H
+#define __CPUID_H
+
 #if !(__x86_64__ || __i386__)
 #error this header is for x86 only
 #endif
@@ -312,3 +315,5 @@ static __inline int __get_cpuid_count (unsigned int __leaf,
 __cpuid_count(__leaf, __subleaf, *__eax, *__ebx, *__ecx, *__edx);
 return 1;
 }
+
+#endif /* __CPUID_H */

diff  --git a/clang/test/Headers/cpuid.c b/clang/test/Headers/cpuid.c
index b0ba07af2f2a..7e485495c106 100644
--- a/clang/test/Headers/cpuid.c
+++ b/clang/test/Headers/cpuid.c
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 %s -ffreestanding -triple i386 -emit-llvm -o - | FileCheck 
%s --check-prefix=CHECK-32
 
 #include 
+#include  // Make sure multiple inclusion protection works.
 
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A 
cpuid\0A xchgq %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}})
 // CHECK-64: {{.*}} call { i32, i32, i32, i32 } asm "  xchgq  %rbx,${1:q}\0A  
cpuid\0A  xchgq  %rbx,${1:q}", 
"={ax},=r,={cx},={dx},0,2,~{dirflag},~{fpsr},~{flags}"(i32 %{{[a-z0-9]+}}, i32 
%{{[a-z0-9]+}})



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

[clang] 70764c0 - [CMake][Fuchsia] Install llvm-elfabi

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2020-12-02T11:59:14-08:00
New Revision: 70764c02e474504e2ebfb5b230a3b2ccdbedc5c2

URL: 
https://github.com/llvm/llvm-project/commit/70764c02e474504e2ebfb5b230a3b2ccdbedc5c2
DIFF: 
https://github.com/llvm/llvm-project/commit/70764c02e474504e2ebfb5b230a3b2ccdbedc5c2.diff

LOG: [CMake][Fuchsia] Install llvm-elfabi

The canonical Fuchsia toolchain configuration installs llvm-elfabi.

Reviewed By: haowei

Differential Revision: https://reviews.llvm.org/D92444

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index 74c393fa7a8b..16bc96be1138 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -245,6 +245,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-dlltool
   llvm-dwarfdump
   llvm-dwp
+  llvm-elfabi
   llvm-gsymutil
   llvm-lib
   llvm-mt



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

[clang] ff11f0a - [Clang] Pass -z rel to linker for Fuchsia

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2021-11-10T13:31:22-08:00
New Revision: ff11f0aa5de1fffaec5f0dde53fad2ba333116b1

URL: 
https://github.com/llvm/llvm-project/commit/ff11f0aa5de1fffaec5f0dde53fad2ba333116b1
DIFF: 
https://github.com/llvm/llvm-project/commit/ff11f0aa5de1fffaec5f0dde53fad2ba333116b1.diff

LOG: [Clang] Pass -z rel to linker for Fuchsia

Fuchsia already supports the more compact relocation format.
Make it the default.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D113136

Added: 


Modified: 
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/test/Driver/fuchsia.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index ee79007fe9a61..b8570fce9eb7d 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -60,6 +60,8 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 CmdArgs.push_back("rodynamic");
 CmdArgs.push_back("-z");
 CmdArgs.push_back("separate-loadable-segments");
+CmdArgs.push_back("-z");
+CmdArgs.push_back("rel");
 CmdArgs.push_back("--pack-dyn-relocs=relr");
   }
 

diff  --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index 926594da95c3a..ecf811d9401ba 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -35,7 +35,7 @@
 // CHECK-X86_64: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK-NOT: "-fcommon"
-// CHECK: {{.*}}ld.lld{{.*}}" "-z" "max-page-size=4096" "-z" "now" "-z" 
"rodynamic" "-z" "separate-loadable-segments" "--pack-dyn-relocs=relr"
+// CHECK: {{.*}}ld.lld{{.*}}" "-z" "max-page-size=4096" "-z" "now" "-z" 
"rodynamic" "-z" "separate-loadable-segments" "-z" "rel" 
"--pack-dyn-relocs=relr"
 // CHECK: "--sysroot=[[SYSROOT]]"
 // CHECK: "-pie"
 // CHECK: "--build-id"



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

[clang] 03ff435 - [RISCV] Default to -ffixed-x18 for Fuchsia

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2023-02-05T18:51:18-08:00
New Revision: 03ff435da540b0feb8272784e05ce742831d5bc2

URL: 
https://github.com/llvm/llvm-project/commit/03ff435da540b0feb8272784e05ce742831d5bc2
DIFF: 
https://github.com/llvm/llvm-project/commit/03ff435da540b0feb8272784e05ce742831d5bc2.diff

LOG: [RISCV] Default to -ffixed-x18 for Fuchsia

Fuchsia's ABI always reserves the x18 (s2) register for the
ShadowCallStack ABI, even when -fsanitize=shadow-call-stack is
not enabled.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D143355

Added: 


Modified: 
clang/lib/Driver/SanitizerArgs.cpp
clang/test/Driver/sanitizer-ld.c
llvm/include/llvm/TargetParser/RISCVTargetParser.h
llvm/lib/Target/RISCV/RISCVSubtarget.cpp
llvm/lib/TargetParser/RISCVTargetParser.cpp
llvm/test/CodeGen/RISCV/reserved-regs.ll

Removed: 




diff  --git a/clang/lib/Driver/SanitizerArgs.cpp 
b/clang/lib/Driver/SanitizerArgs.cpp
index 84be06b90ee62..49ae5cc6d88c9 100644
--- a/clang/lib/Driver/SanitizerArgs.cpp
+++ b/clang/lib/Driver/SanitizerArgs.cpp
@@ -19,6 +19,7 @@
 #include "llvm/Support/TargetParser.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/TargetParser/AArch64TargetParser.h"
+#include "llvm/TargetParser/RISCVTargetParser.h"
 #include "llvm/Transforms/Instrumentation/AddressSanitizerOptions.h"
 #include 
 
@@ -545,7 +546,8 @@ SanitizerArgs::SanitizerArgs(const ToolChain &TC,
   if ((Kinds & SanitizerKind::ShadowCallStack) &&
   ((TC.getTriple().isAArch64() &&
 !llvm::AArch64::isX18ReservedByDefault(TC.getTriple())) ||
-   TC.getTriple().isRISCV()) &&
+   (TC.getTriple().isRISCV() &&
+!llvm::RISCV::isX18ReservedByDefault(TC.getTriple( &&
   !Args.hasArg(options::OPT_ffixed_x18) && DiagnoseErrors) {
 D.Diag(diag::err_drv_argument_only_allowed_with)
 << lastArgumentForMask(D, Args, Kinds & SanitizerKind::ShadowCallStack)

diff  --git a/clang/test/Driver/sanitizer-ld.c 
b/clang/test/Driver/sanitizer-ld.c
index 3621d12eeb8c6..0ba209d870c2a 100644
--- a/clang/test/Driver/sanitizer-ld.c
+++ b/clang/test/Driver/sanitizer-ld.c
@@ -731,6 +731,11 @@
 // RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-LINUX-RISCV64 %s
 // CHECK-SHADOWCALLSTACK-LINUX-RISCV64: '-fsanitize=shadow-call-stack' only 
allowed with '-ffixed-x18'
 
+// RUN: %clang -fsanitize=shadow-call-stack -### %s 2>&1 \
+// RUN: --target=riscv64-unknown-fuchsia -fuse-ld=ld \
+// RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-FUCHSIA-RISCV64 %s
+// CHECK-SHADOWCALLSTACK-FUCHSIA-RISCV64-NOT: error:
+
 // RUN: %clang -fsanitize=shadow-call-stack -### %s 2>&1 \
 // RUN: --target=aarch64-unknown-linux -fuse-ld=ld -ffixed-x18 \
 // RUN:   | FileCheck --check-prefix=CHECK-SHADOWCALLSTACK-LINUX-AARCH64-X18 %s

diff  --git a/llvm/include/llvm/TargetParser/RISCVTargetParser.h 
b/llvm/include/llvm/TargetParser/RISCVTargetParser.h
index da2ecd8c1339d..f50576b8fee16 100644
--- a/llvm/include/llvm/TargetParser/RISCVTargetParser.h
+++ b/llvm/include/llvm/TargetParser/RISCVTargetParser.h
@@ -18,6 +18,9 @@
 #include 
 
 namespace llvm {
+
+class Triple;
+
 namespace RISCV {
 
 // We use 64 bits as the known part in the scalable vector types.
@@ -38,6 +41,8 @@ void fillValidCPUArchList(SmallVectorImpl &Values, 
bool IsRV64);
 void fillValidTuneCPUArchList(SmallVectorImpl &Values, bool IsRV64);
 bool getCPUFeaturesExceptStdExt(CPUKind Kind, std::vector 
&Features);
 
+bool isX18ReservedByDefault(const Triple &TT);
+
 } // namespace RISCV
 } // namespace llvm
 

diff  --git a/llvm/lib/Target/RISCV/RISCVSubtarget.cpp 
b/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
index 2d134b2514a2b..1101d7eeeff8b 100644
--- a/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
+++ b/llvm/lib/Target/RISCV/RISCVSubtarget.cpp
@@ -83,6 +83,9 @@ RISCVSubtarget::RISCVSubtarget(const Triple &TT, StringRef 
CPU,
   FrameLowering(
   initializeSubtargetDependencies(TT, CPU, TuneCPU, FS, ABIName)),
   InstrInfo(*this), RegInfo(getHwMode()), TLInfo(TM, *this) {
+  if (RISCV::isX18ReservedByDefault(TT))
+UserReservedRegister.set(RISCV::X18);
+
   CallLoweringInfo.reset(new RISCVCallLowering(*getTargetLowering()));
   Legalizer.reset(new RISCVLegalizerInfo(*this));
 

diff  --git a/llvm/lib/TargetParser/RISCVTargetParser.cpp 
b/llvm/lib/TargetParser/RISCVTargetParser.cpp
index 89cd5c082d72d..933a82b7c6cb2 100644
--- a/llvm/lib/TargetParser/RISCVTargetParser.cpp
+++ b/llvm/lib/TargetParser/RISCVTargetParser.cpp
@@ -14,6 +14,7 @@
 #include "llvm/TargetParser/RISCVTargetParser.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/TargetParser/Triple.h"
 
 namespace llvm {
 namespace RISCV {
@@ -100,5 +101,10 @@ bool getCPUFeaturesExceptStdExt(CPUKind Kind,
   return true;
 }
 
+bool isX18ReservedByDefault(const Triple &TT) {
+  // X18 is reserved for the ShadowCallStac

[clang] f08d86f - [RISCV] Default to -fsanitize=shadow-call-stack for Fuchsia

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2023-02-05T18:58:59-08:00
New Revision: f08d86fc7f4479d5f44d75c720201334682075b8

URL: 
https://github.com/llvm/llvm-project/commit/f08d86fc7f4479d5f44d75c720201334682075b8
DIFF: 
https://github.com/llvm/llvm-project/commit/f08d86fc7f4479d5f44d75c720201334682075b8.diff

LOG: [RISCV] Default to -fsanitize=shadow-call-stack for Fuchsia

The ShadowCallStack is the preferred and default ABI for Fuchsia.

Reviewed By: phosek

Differential Revision: https://reviews.llvm.org/D143357

Added: 


Modified: 
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/test/Driver/fuchsia.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index d0e035f205ae0..36bd93a4913c6 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -466,13 +466,13 @@ SanitizerMask Fuchsia::getDefaultSanitizers() const {
   SanitizerMask Res;
   switch (getTriple().getArch()) {
   case llvm::Triple::aarch64:
+  case llvm::Triple::riscv64:
 Res |= SanitizerKind::ShadowCallStack;
 break;
   case llvm::Triple::x86_64:
 Res |= SanitizerKind::SafeStack;
 break;
   default:
-// TODO: Enable SafeStack on RISC-V once tested.
 break;
   }
   return Res;

diff  --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index a8bae5f655415..c785e3a52251c 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -31,6 +31,7 @@
 // CHECK: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK: "-internal-externc-isystem" "[[SYSROOT]]{{/|}}include"
 // CHECK-AARCH64: "-fsanitize=shadow-call-stack"
+// CHECK-RISCV64: "-fsanitize=shadow-call-stack"
 // CHECK-X86_64: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK-AARCH64: "-target-feature" "+outline-atomics"



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

[clang] [clang][Driver] Obey -fuse-ld=... for -print-prog-name=ld output (PR #66698)

[Roland McGrath via cfe-commits]

https://github.com/frobtech created 
https://github.com/llvm/llvm-project/pull/66698

GCC makes `-print-prog-name=ld` a special case that looks up the
linker that will be used according to the `-fuse-ld=...` option
state.  This makes Clang follow suit.


>From aff75e8f64c8d2515f5fc152b33d5be514568269 Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Mon, 18 Sep 2023 13:39:08 -0700
Subject: [PATCH] [clang][Driver] Obey -fuse-ld=... for -print-prog-name=ld
 output

GCC makes `-print-prog-name=ld` a special case that looks up the
linker that will be used according to the `-fuse-ld=...` option
state.  This makes Clang follow suit.
---
 clang/lib/Driver/Driver.cpp| 3 ++-
 clang/test/Driver/print-prog-name-ld.c | 4 
 2 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 clang/test/Driver/print-prog-name-ld.c

diff --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 84b8fc7685fed42..afda1bb14b420b6 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2189,7 +2189,8 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
 
 // Null program name cannot have a path.
 if (! ProgName.empty())
-  llvm::outs() << GetProgramPath(ProgName, TC);
+  llvm::outs() << (ProgName == "ld" ? TC.GetLinkerPath()
+: GetProgramPath(ProgName, TC));
 
 llvm::outs() << "\n";
 return false;
diff --git a/clang/test/Driver/print-prog-name-ld.c 
b/clang/test/Driver/print-prog-name-ld.c
new file mode 100644
index 000..0aa75306bb01a8d
--- /dev/null
+++ b/clang/test/Driver/print-prog-name-ld.c
@@ -0,0 +1,4 @@
+// Test that -print-prog-name=ld correctly obeys -fuse-ld=...
+
+// RUN: %clang -print-prog-name=ld -fuse-ld=lld 2>&1 | FileCheck %s
+// CHECK:{{.*ld(64)?\.lld}}

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

[clang] [clang][Driver] Obey -fuse-ld=... for -print-prog-name=ld output (PR #66698)

[Roland McGrath via cfe-commits]

https://github.com/frobtech ready_for_review 
https://github.com/llvm/llvm-project/pull/66698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Driver] Obey -fuse-ld=... for -print-prog-name=ld output (PR #66698)

[Roland McGrath via cfe-commits]

frobtech wrote:

> I think the 2013 GCC feature adding -fuse-ld= made this change, which is, 
> frankly, strange. I wish that we don't this...

It's too late now. Build system code in the wild uses `$CC -print-prog-name=ld` 
and then expects to be able to invoke that program to get the linker that `$CC` 
usually uses.  When `CC=gcc -fuse-ld=foo` that works, but when `CC=clang` it 
doesn't, whether there's a `-fuse-ld=...` in there or just the default in the 
toolchain configuration is something other than `ld`, such as when `ld.lld` is 
the default.
 
> lld has several names. For windows-msvc target triples it is `lld-link`, and 
> for wasm triples it is wasm-ld.

ISTM that GetLinkerPath ought to produce the right name regardless and if it 
doesn't we can fix it to do so.


https://github.com/llvm/llvm-project/pull/66698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Driver] Obey -fuse-ld=... for -print-prog-name=ld output (PR #66698)

[Roland McGrath via cfe-commits]

frobtech wrote:

> Can you comment on what projects need this? Can't we fix the projects 
> instead? And what do they do with the linker path? Why don't they invoke the 
> clang driver to run a link action?

They are legion. It comes from autoconf checks for libtool. It doesn't really 
matter why they're doing it. They are doing it and it will be years before they 
can all be changed. If you want to use Clang as the compiler for random open 
source code, it needs to be compatible with GCC in this regard.

> > ISTM that GetLinkerPath ought to produce the right name regardless and if 
> > it doesn't we can fix it to do so.
> 
> It is, but the current test will fail.

I'll be happy to adjust the test so that it matches all the right names, or so 
that it's restricted to only running on the targets where we know what the 
names might be. Can you suggest how to do that?

https://github.com/llvm/llvm-project/pull/66698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Fuchsia] Build with -fvisibility=default (PR #67067)

[Roland McGrath via cfe-commits]

https://github.com/frobtech approved this pull request.

lgtm

https://github.com/llvm/llvm-project/pull/67067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Fuchsia] Build with -fvisibility=default (PR #67067)

[Roland McGrath via cfe-commits]

https://github.com/frobtech edited 
https://github.com/llvm/llvm-project/pull/67067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Fuchsia] Build with -fvisibility=default (PR #67067)

[Roland McGrath via cfe-commits]

@@ -52,6 +52,7 @@ set(ENABLE_LINKER_BUILD_ID ON CACHE BOOL "")
 set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
+set(CMAKE_CXX_VISIBILITY_PRESET default CACHE STRING "")

frobtech wrote:

It merits a comment here that this works around some issues with relative 
vtables.
I think we want to actually figure out and resolve those issues so they don't 
come up, so I think this should be a TODO(bug#) comment pointing to a bug about 
the unresolved issues with mixing those TUs.

https://github.com/llvm/llvm-project/pull/67067
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 9d4162f - [clang-tidy] Add fix-it support to `llvmlibc-inline-function-decl`

[Roland McGrath via cfe-commits]

Author: Roland McGrath
Date: 2023-08-07T12:15:59-07:00
New Revision: 9d4162ff28b479c93d55df67bf38507bdc50a2d1

URL: 
https://github.com/llvm/llvm-project/commit/9d4162ff28b479c93d55df67bf38507bdc50a2d1
DIFF: 
https://github.com/llvm/llvm-project/commit/9d4162ff28b479c93d55df67bf38507bdc50a2d1.diff

LOG: [clang-tidy] Add fix-it support to `llvmlibc-inline-function-decl`

This is very simplistic and could be more thorough by replacing
an existing `LIBC_INLINE` in the wrong location or a redunant
`inline` when inserting the right macro use.  But as is this
suffices to automatically apply fixes for most or all of the
instances in the libc tree today and get working results (despite
some superfluous `inline` keywords left behind).

Reviewed By: abrachet

Differential Revision: https://reviews.llvm.org/D157164

Added: 


Modified: 
clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp 
b/clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
index f901cd115a8ff7..c119e393d3ab69 100644
--- a/clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
+++ b/clang-tools-extra/clang-tidy/llvmlibc/InlineFunctionDeclCheck.cpp
@@ -88,7 +88,7 @@ void InlineFunctionDeclCheck::check(const 
MatchFinder::MatchResult &Result) {
 
   diag(SrcBegin, "%0 must be tagged with the LIBC_INLINE macro; the macro "
  "should be placed at the beginning of the declaration")
-  << FuncDecl;
+  << FuncDecl << FixItHint::CreateInsertion(Loc, "LIBC_INLINE ");
 }
 
 } // namespace clang::tidy::llvm_libc

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp 
b/clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
index ab4410ad4fb478..0028c575b1d687 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/llvmlibc/inline-function-decl.hpp
@@ -17,11 +17,13 @@ LIBC_INLINE constexpr long addl(long a, long b) {
 
 constexpr long long addll(long long a, long long b) {
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'addll' must be tagged with the 
LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE constexpr long long addll(long long a, long long 
b) {
   return a + b;
 }
 
 inline unsigned long addul(unsigned long a, unsigned long b) {
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'addul' must be tagged with the 
LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE inline unsigned long addul(unsigned long a, 
unsigned long b) {
   return a + b;
 }
 
@@ -30,11 +32,13 @@ class  MyClass {
 public:
   MyClass() : A(123) {}
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'MyClass' must be tagged with 
the LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE MyClass() : A(123) {}
 
   LIBC_INLINE MyClass(int V) : A(V) {}
 
   constexpr operator int() const { return A; }
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'operator int' must be tagged 
with the LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE constexpr operator int() const { return A; }
 
   LIBC_INLINE bool operator==(const MyClass &RHS) {
 return RHS.A == A;
@@ -42,6 +46,7 @@ class  MyClass {
 
   static int getVal(const MyClass &V) {
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'getVal' must be tagged with the 
LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE static int getVal(const MyClass &V) {
 return V.A;
   }
 
@@ -51,6 +56,7 @@ class  MyClass {
 
   constexpr static int addInt(MyClass &V, int A) {
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'addInt' must be tagged with the 
LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+  // CHECK-FIXES:   LIBC_INLINE constexpr static int addInt(MyClass &V, int A) 
{
 return V.A += A;
   }
 
@@ -78,6 +84,7 @@ LIBC_INLINE void goodSimpleFunction() {}
 
 inline void badSimpleFunction() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: 'badSimpleFunction' must be tagged 
with the LIBC_INLINE macro; the macro should be placed at the beginning of the 
declaration [llvmlibc-inline-function-decl]
+// CHECK-FIXES: LIBC_INLINE inline void badSimpleFunction() {}
 
 void LIBC_INLINE badSimpleFunctionWrongLocation() {}
 // CHECK-MESSAGES: :[[@LINE-1]]:1: war

Re: r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled

[Roland McGrath via cfe-commits]

Kostya, do you remember the exact original case in glibc for 22830 and
what glibc change fixed it?
I vaguely recall the case, but not enough to find the actual change
and compare it to the new scenarios.
I suspect that the original case was easy to fix because it was just
that the hidden_proto magic had been put in the wrong place.

The fstat/__fxstat case is harder.  The original declaration of
__fxstat and the extern inline (that is, 'extern __inline
__attribute__ ((__gnu_inline__))') definition of fstat (which calls
__fxstat) is in the installed header, while the hidden_proto (i.e.
redeclaration with asm label) is in the wrapper header (and
necessarily must come after the #include of the installed header).

A GNU extern inline case is one where the rationale I mentioned in
https://llvm.org/bugs/show_bug.cgi?id=22830#c1 for Clang not being
able to match GCC's semantics might not really apply: you never need
to emit the code for fstat before the redeclaration, because you only
ever inline it and never emit an actual function.

Perhaps there is a defensible reason that Clang really cannot match
the GNU semantics even for this case.  Regardless, Clang really needs
to thoroughly document its semantics for every language extension when
its semantics are not completely identical to the GNU language
extension's semantics.

If Clang's asm labels extension persists in having semantics
incompatible with the original semantics of the asm labels extension
invented by GNU, we might be able to work around it adequately in the
glibc build just by making sure __USE_EXTERN_INLINES is not defined
during the build.


On Mon, Jan 4, 2016 at 3:39 PM, Kostya Serebryany  wrote:
> Thanks for checking, Nick!
> +Roland, FYI (recent changes in clang break compilation of all of the
> glibc),
> similar to https://llvm.org/bugs/show_bug.cgi?id=22830#c1
>
> On Mon, Jan 4, 2016 at 3:21 PM, Nick Lewycky  wrote:
>>
>> On 01/04/2016 01:40 PM, Kostya Serebryany wrote:
>>>
>>>
>>>
>>> On Thu, Dec 17, 2015 at 5:03 PM, Richard Smith >> > wrote:
>>>
>>> On Thu, Dec 17, 2015 at 3:59 PM, Nick Lewycky via cfe-commits
>>> mailto:cfe-commits@lists.llvm.org>>
>>> wrote:
>>>
>>> On 12/17/2015 10:47 AM, Kostya Serebryany wrote:
>>>
>>> I am now observing this error message when building glibc
>>> with clang
>>> (from trunk):
>>> ../include/string.h:101:28: error: cannot apply asm label to
>>> function
>>> after its first use
>>> libc_hidden_builtin_proto (memcpy)
>>> (many more instances)
>>>
>>>
>>> Do you think this is a bug in glibc code, or the error
>>> message could be
>>> more relaxed?
>>>
>>>
>>> Could you email me a .i copy of a failing build? That will help
>>> me decide whether it's a bug in the error or in glibc.
>>>
>>>
>>> [sorry for delay,]
>>> here is the preprocessed source file from glibc:
>>> % clang  ~/tmp/a.i 2>&1 | grep error:
>>> ../include/sys/stat.h:16:28: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:17:30: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:18:28: error: cannot apply asm label to function
>>> after its first use
>>> ../include/sys/stat.h:19:30: error: cannot apply asm label to function
>>> after its first use
>>> ...
>>>
>>>
>>> Also PR22830 comment 1 seems relevant here.
>>>
>>>
>>> Probably, but since this is a very recent regression in clang I thought
>>> I should report it.
>>
>>
>> This looks like it's WAI:
>>
>> 3783extern int __fxstat (int __ver, int __fildes, struct stat
>> *__stat_buf)
>> 3784 __attribute__ ((__nothrow__ )) ;
>> ...
>> 3827extern __inline int
>> 3828__attribute__ ((__nothrow__ )) fstat (int __fd, struct stat
>> *__statbuf)
>> 3829{
>> 3830  return __fxstat (1, __fd, __statbuf);
>> 3831}
>> ...
>> 3910extern __typeof (__fxstat) __fxstat __asm__ ("" "__GI___fxstat")
>> __attribute__ ((visibility ("hidden")));
>>
>> This is exactly the situation where GCC and Clang will emit a different .o
>> file.
>>
>> Nick
>>
>>> On Fri, Dec 11, 2015 at 1:28 PM, Nick Lewycky via cfe-commits
>>> >> 
>>> >>
>>> >> wrote:
>>>
>>>  Author: nicholas
>>>  Date: Fri Dec 11 15:28:55 2015
>>>  New Revision: 255371
>>>
>>>  URL:
>>> http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
>>>  Log:
>>>  Error on redeclaring with a conflicting asm label and
>>> on redeclaring
>>>  with an asm label after the first ODR-use. Detects
>>> problems like the
>>>  one in PR228

[clang] [InstCombine] Add multi-use tests for shift-of-shift transform (NFC) (PR #95497)

[Roland McGrath via cfe-commits]

https://github.com/frobtech created 
https://github.com/llvm/llvm-project/pull/95497

Also drop irrelevant function attributes from tests.

>From c4e8968197c401f03baaed904d07a5ce77c19ace Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Thu, 13 Jun 2024 20:25:24 -0700
Subject: [PATCH] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia
 targets

This aligns Fuchsia targets with other similar OS targets such as
Linux.  Fuchsia's libc already uses unsigned rather than the
compiler-provided __WINT_TYPE__ macro for its wint_t typedef, so
this just makes the compiler consistent with the OS's actual ABI.
The only known manifestation of the mismatch is -Wformat warnings
for %lc no matching wint_t arguments.

The closest thing I could see to existing tests for each target's
wint_t type setting was the predefine tests that check various
macros including __WINT_TYPE__ on a per-machine and/or per-OS
basis.  While the setting is done per-OS in most of the target
implementations rather than actually varying by machine, the only
existing tests for __WINT_TYPE__ are in per-machine checks that
are also wholly or partly tagged as per-OS.  x86_64 and riscv64
tests for respective *-linux-gnu targets now check for the same
definitions in the respective *-fuchsia targets.  __WINT_TYPE__
is not among the type checked in the aarch64 tests and those lack
a section that's specifically tested for aarch64-linux-gnu; if
such is added then it can similarly be made to check for most or
all of the same value on aarch64-fuchsia as aarch64-linux-gnu.
But since the actual implementation of choosing the type is done
per-OS and not per-machine for the three machines with Fuchsia
target support, the x86 and riscv64 tests are already redundantly
testing that same code and seem sufficient.
---
 clang/lib/Basic/Targets/OSTargets.h | 1 +
 clang/test/Preprocessor/init-x86.c  | 1 +
 clang/test/Preprocessor/init.c  | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 4366c1149e405..5f27c3469f861 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -868,6 +868,7 @@ class LLVM_LIBRARY_VISIBILITY FuchsiaTargetInfo : public 
OSTargetInfo {
 public:
   FuchsiaTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
+this->WIntType = TargetInfo::UnsignedInt;
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::Fuchsia);
   }
diff --git a/clang/test/Preprocessor/init-x86.c 
b/clang/test/Preprocessor/init-x86.c
index 1268419e18a5c..6f5aa5674e48e 100644
--- a/clang/test/Preprocessor/init-x86.c
+++ b/clang/test/Preprocessor/init-x86.c
@@ -999,6 +999,7 @@
 // X32:#define __x86_64__ 1
 
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-pc-linux-gnu < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-unknown-fuchsia < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
 //
 // X86_64-LINUX:#define _LP64 1
 // X86_64-LINUX:#define __BIGGEST_ALIGNMENT__ 16
diff --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index 2641fee940231..6e7c0ea5c730b 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -2527,6 +2527,8 @@
 // RUN:   | FileCheck -match-full-lines -check-prefix=RISCV64 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=riscv64-unknown-linux < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=RISCV64,RISCV64-LINUX 
%s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=riscv64-unknown-fuchsia < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=RISCV64 %s
 // RISCV64: #define _LP64 1
 // RISCV64: #define __ATOMIC_ACQUIRE 2
 // RISCV64: #define __ATOMIC_ACQ_REL 4

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

[clang] [InstCombine] Add multi-use tests for shift-of-shift transform (NFC) (PR #95497)

[Roland McGrath via cfe-commits]

https://github.com/frobtech closed 
https://github.com/llvm/llvm-project/pull/95497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia targets (PR #95499)

[Roland McGrath via cfe-commits]

https://github.com/frobtech created 
https://github.com/llvm/llvm-project/pull/95499

This aligns Fuchsia targets with other similar OS targets such as
Linux.  Fuchsia's libc already uses unsigned rather than the
compiler-provided __WINT_TYPE__ macro for its wint_t typedef, so
this just makes the compiler consistent with the OS's actual ABI.
The only known manifestation of the mismatch is -Wformat warnings
for %lc no matching wint_t arguments.

The closest thing I could see to existing tests for each target's
wint_t type setting was the predefine tests that check various
macros including __WINT_TYPE__ on a per-machine and/or per-OS
basis.  While the setting is done per-OS in most of the target
implementations rather than actually varying by machine, the only
existing tests for __WINT_TYPE__ are in per-machine checks that
are also wholly or partly tagged as per-OS.  x86_64 and riscv64
tests for respective *-linux-gnu targets now check for the same
definitions in the respective *-fuchsia targets.  __WINT_TYPE__
is not among the type checked in the aarch64 tests and those lack
a section that's specifically tested for aarch64-linux-gnu; if
such is added then it can similarly be made to check for most or
all of the same value on aarch64-fuchsia as aarch64-linux-gnu.
But since the actual implementation of choosing the type is done
per-OS and not per-machine for the three machines with Fuchsia
target support, the x86 and riscv64 tests are already redundantly
testing that same code and seem sufficient.

>From c4e8968197c401f03baaed904d07a5ce77c19ace Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Thu, 13 Jun 2024 20:25:24 -0700
Subject: [PATCH] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia
 targets

This aligns Fuchsia targets with other similar OS targets such as
Linux.  Fuchsia's libc already uses unsigned rather than the
compiler-provided __WINT_TYPE__ macro for its wint_t typedef, so
this just makes the compiler consistent with the OS's actual ABI.
The only known manifestation of the mismatch is -Wformat warnings
for %lc no matching wint_t arguments.

The closest thing I could see to existing tests for each target's
wint_t type setting was the predefine tests that check various
macros including __WINT_TYPE__ on a per-machine and/or per-OS
basis.  While the setting is done per-OS in most of the target
implementations rather than actually varying by machine, the only
existing tests for __WINT_TYPE__ are in per-machine checks that
are also wholly or partly tagged as per-OS.  x86_64 and riscv64
tests for respective *-linux-gnu targets now check for the same
definitions in the respective *-fuchsia targets.  __WINT_TYPE__
is not among the type checked in the aarch64 tests and those lack
a section that's specifically tested for aarch64-linux-gnu; if
such is added then it can similarly be made to check for most or
all of the same value on aarch64-fuchsia as aarch64-linux-gnu.
But since the actual implementation of choosing the type is done
per-OS and not per-machine for the three machines with Fuchsia
target support, the x86 and riscv64 tests are already redundantly
testing that same code and seem sufficient.
---
 clang/lib/Basic/Targets/OSTargets.h | 1 +
 clang/test/Preprocessor/init-x86.c  | 1 +
 clang/test/Preprocessor/init.c  | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 4366c1149e405..5f27c3469f861 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -868,6 +868,7 @@ class LLVM_LIBRARY_VISIBILITY FuchsiaTargetInfo : public 
OSTargetInfo {
 public:
   FuchsiaTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
+this->WIntType = TargetInfo::UnsignedInt;
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::Fuchsia);
   }
diff --git a/clang/test/Preprocessor/init-x86.c 
b/clang/test/Preprocessor/init-x86.c
index 1268419e18a5c..6f5aa5674e48e 100644
--- a/clang/test/Preprocessor/init-x86.c
+++ b/clang/test/Preprocessor/init-x86.c
@@ -999,6 +999,7 @@
 // X32:#define __x86_64__ 1
 
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-pc-linux-gnu < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-unknown-fuchsia < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
 //
 // X86_64-LINUX:#define _LP64 1
 // X86_64-LINUX:#define __BIGGEST_ALIGNMENT__ 16
diff --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index 2641fee940231..6e7c0ea5c730b 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -2527,6 +2527,8 @@
 // RUN:   | FileCheck -match-full-lines -check-prefix=RISCV64 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=riscv64-unknown-linux < /dev/null \
 // RUN:   | FileChe

[clang] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia targets (PR #95499)

[Roland McGrath via cfe-commits]

https://github.com/frobtech updated 
https://github.com/llvm/llvm-project/pull/95499

>From c4e8968197c401f03baaed904d07a5ce77c19ace Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Thu, 13 Jun 2024 20:25:24 -0700
Subject: [PATCH] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia
 targets

This aligns Fuchsia targets with other similar OS targets such as
Linux.  Fuchsia's libc already uses unsigned rather than the
compiler-provided __WINT_TYPE__ macro for its wint_t typedef, so
this just makes the compiler consistent with the OS's actual ABI.
The only known manifestation of the mismatch is -Wformat warnings
for %lc no matching wint_t arguments.

The closest thing I could see to existing tests for each target's
wint_t type setting was the predefine tests that check various
macros including __WINT_TYPE__ on a per-machine and/or per-OS
basis.  While the setting is done per-OS in most of the target
implementations rather than actually varying by machine, the only
existing tests for __WINT_TYPE__ are in per-machine checks that
are also wholly or partly tagged as per-OS.  x86_64 and riscv64
tests for respective *-linux-gnu targets now check for the same
definitions in the respective *-fuchsia targets.  __WINT_TYPE__
is not among the type checked in the aarch64 tests and those lack
a section that's specifically tested for aarch64-linux-gnu; if
such is added then it can similarly be made to check for most or
all of the same value on aarch64-fuchsia as aarch64-linux-gnu.
But since the actual implementation of choosing the type is done
per-OS and not per-machine for the three machines with Fuchsia
target support, the x86 and riscv64 tests are already redundantly
testing that same code and seem sufficient.
---
 clang/lib/Basic/Targets/OSTargets.h | 1 +
 clang/test/Preprocessor/init-x86.c  | 1 +
 clang/test/Preprocessor/init.c  | 2 ++
 3 files changed, 4 insertions(+)

diff --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 4366c1149e405..5f27c3469f861 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -868,6 +868,7 @@ class LLVM_LIBRARY_VISIBILITY FuchsiaTargetInfo : public 
OSTargetInfo {
 public:
   FuchsiaTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
+this->WIntType = TargetInfo::UnsignedInt;
 this->MCountName = "__mcount";
 this->TheCXXABI.set(TargetCXXABI::Fuchsia);
   }
diff --git a/clang/test/Preprocessor/init-x86.c 
b/clang/test/Preprocessor/init-x86.c
index 1268419e18a5c..6f5aa5674e48e 100644
--- a/clang/test/Preprocessor/init-x86.c
+++ b/clang/test/Preprocessor/init-x86.c
@@ -999,6 +999,7 @@
 // X32:#define __x86_64__ 1
 
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-pc-linux-gnu < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=x86_64-unknown-fuchsia < /dev/null | FileCheck -match-full-lines 
-check-prefix X86_64-LINUX %s
 //
 // X86_64-LINUX:#define _LP64 1
 // X86_64-LINUX:#define __BIGGEST_ALIGNMENT__ 16
diff --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index 2641fee940231..6e7c0ea5c730b 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -2527,6 +2527,8 @@
 // RUN:   | FileCheck -match-full-lines -check-prefix=RISCV64 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=riscv64-unknown-linux < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=RISCV64,RISCV64-LINUX 
%s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=riscv64-unknown-fuchsia < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=RISCV64 %s
 // RISCV64: #define _LP64 1
 // RISCV64: #define __ATOMIC_ACQUIRE 2
 // RISCV64: #define __ATOMIC_ACQ_REL 4

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

[clang] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia targets (PR #95499)

[Roland McGrath via cfe-commits]

https://github.com/frobtech ready_for_review 
https://github.com/llvm/llvm-project/pull/95499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Fuchsia] Use unsigned int for wint_t on *-fuchsia targets (PR #95499)

[Roland McGrath via cfe-commits]

https://github.com/frobtech closed 
https://github.com/llvm/llvm-project/pull/95499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] [libc] Update libc namespace clang-tidy checks (PR #98088)

[Roland McGrath via cfe-commits]

@@ -11,6 +11,8 @@
 namespace clang::tidy::llvm_libc {
 
 const static llvm::StringRef RequiredNamespaceStart = "__llvm_libc";
+const static llvm::StringRef RequiredNamespaceHiddenMacroName =

frobtech wrote:

I think it would be better to call this one "...NamespaceDecl" and the other 
one "...NamespaceRef".


https://github.com/llvm/llvm-project/pull/98088
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][Fuchsia] Avoid "argument unused" warnings (PR #118416)

[Roland McGrath via cfe-commits]

https://github.com/frobtech created 
https://github.com/llvm/llvm-project/pull/118416

There should not be an error or warning reported for using
redundant options to control what goes into the link.  For
example, -nolibc -nostdlib.


>From 5a039fa6003a7612ddc6603192a121d92d3903cc Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Mon, 2 Dec 2024 13:33:47 -0800
Subject: [PATCH] [Driver][Fuchsia] Avoid "argument unused" warnings

There should not be an error or warning reported for using
redundant options to control what goes into the link.  For
example, -nolibc -nostdlib.
---
 clang/lib/Driver/ToolChains/Fuchsia.cpp | 30 -
 clang/test/Driver/fuchsia.c |  6 +
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 72accbff4a3bf2..c2badc80a7b452 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -156,6 +156,12 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
+  // Sample these options first so they are claimed even under -nostdlib et al.
+  bool NoLibc = Args.hasArg(options::OPT_nolibc);
+  bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
+ !Args.hasArg(options::OPT_static);
+  bool Pthreads = Args.hasArg(options::OPT_pthread, options::OPT_pthreads);
+  bool SplitStack = Args.hasArg(options::OPT_fsplit_stack);
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
 if (Args.hasArg(options::OPT_static))
@@ -163,8 +169,6 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 if (D.CCCIsCXX()) {
   if (ToolChain.ShouldLinkCXXStdlib(Args)) {
-bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) 
&&
-   !Args.hasArg(options::OPT_static);
 CmdArgs.push_back("--push-state");
 CmdArgs.push_back("--as-needed");
 if (OnlyLibstdcxxStatic)
@@ -188,14 +192,13 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
-if (Args.hasArg(options::OPT_pthread) ||
-Args.hasArg(options::OPT_pthreads))
+if (Pthreads)
   CmdArgs.push_back("-lpthread");
 
-if (Args.hasArg(options::OPT_fsplit_stack))
+if (SplitStack)
   CmdArgs.push_back("--wrap=pthread_create");
 
-if (!Args.hasArg(options::OPT_nolibc))
+if (!NoLibc)
   CmdArgs.push_back("-lc");
   }
 
@@ -229,7 +232,7 @@ void fuchsia::StaticLibTool::ConstructJob(Compilation &C, 
const JobAction &JA,
 
   for (const auto &II : Inputs) {
 if (II.isFilename()) {
-   CmdArgs.push_back(II.getFilename());
+  CmdArgs.push_back(II.getFilename());
 }
   }
 
@@ -343,16 +346,14 @@ std::string Fuchsia::ComputeEffectiveClangTriple(const 
ArgList &Args,
   return Triple.str();
 }
 
-Tool *Fuchsia::buildLinker() const {
-  return new tools::fuchsia::Linker(*this);
-}
+Tool *Fuchsia::buildLinker() const { return new tools::fuchsia::Linker(*this); 
}
 
 Tool *Fuchsia::buildStaticLibTool() const {
   return new tools::fuchsia::StaticLibTool(*this);
 }
 
-ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
-const ArgList &Args) const {
+ToolChain::RuntimeLibType
+Fuchsia::GetRuntimeLibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(clang::driver::options::OPT_rtlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "compiler-rt")
@@ -363,13 +364,12 @@ ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
   return ToolChain::RLT_CompilerRT;
 }
 
-ToolChain::CXXStdlibType
-Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
+ToolChain::CXXStdlibType Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "libc++")
   getDriver().Diag(diag::err_drv_invalid_stdlib_name)
-<< A->getAsString(Args);
+  << A->getAsString(Args);
   }
 
   return ToolChain::CST_Libcxx;
diff --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index 83dee16981690a..cf92f85040901c 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -297,3 +297,9 @@
 // RUN: %clang --target=riscv64-unknown-fuchsia -mno-relax -### %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=RISCV64-FLAGS %s
 // RISCV64-FLAGS: "-X" "--no-relax"
+
+// RUN: %clang -### %s --target=x86_64-unknown-fuchsia 2>&1 \
+// RUN: -nostdlib -nolibc \
+// RUN: | FileCheck %s -check-prefix=CHECK-NOSTDLIB-NOLIBC
+// CHECK-NOSTDLIB-NOLIBC-NOT: "warning:"
+// CHECK-NOSTDLIB-NOLIBC-NOT: "error:"

___
cfe-commits mailing list
cfe-com

[clang] [Driver][Fuchsia] Avoid "argument unused" warnings (PR #118416)

[Roland McGrath via cfe-commits]

https://github.com/frobtech updated 
https://github.com/llvm/llvm-project/pull/118416

>From 5a039fa6003a7612ddc6603192a121d92d3903cc Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Mon, 2 Dec 2024 13:33:47 -0800
Subject: [PATCH] [Driver][Fuchsia] Avoid "argument unused" warnings

There should not be an error or warning reported for using
redundant options to control what goes into the link.  For
example, -nolibc -nostdlib.
---
 clang/lib/Driver/ToolChains/Fuchsia.cpp | 30 -
 clang/test/Driver/fuchsia.c |  6 +
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 72accbff4a3bf2..c2badc80a7b452 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -156,6 +156,12 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
+  // Sample these options first so they are claimed even under -nostdlib et al.
+  bool NoLibc = Args.hasArg(options::OPT_nolibc);
+  bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
+ !Args.hasArg(options::OPT_static);
+  bool Pthreads = Args.hasArg(options::OPT_pthread, options::OPT_pthreads);
+  bool SplitStack = Args.hasArg(options::OPT_fsplit_stack);
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
 if (Args.hasArg(options::OPT_static))
@@ -163,8 +169,6 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 if (D.CCCIsCXX()) {
   if (ToolChain.ShouldLinkCXXStdlib(Args)) {
-bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) 
&&
-   !Args.hasArg(options::OPT_static);
 CmdArgs.push_back("--push-state");
 CmdArgs.push_back("--as-needed");
 if (OnlyLibstdcxxStatic)
@@ -188,14 +192,13 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
-if (Args.hasArg(options::OPT_pthread) ||
-Args.hasArg(options::OPT_pthreads))
+if (Pthreads)
   CmdArgs.push_back("-lpthread");
 
-if (Args.hasArg(options::OPT_fsplit_stack))
+if (SplitStack)
   CmdArgs.push_back("--wrap=pthread_create");
 
-if (!Args.hasArg(options::OPT_nolibc))
+if (!NoLibc)
   CmdArgs.push_back("-lc");
   }
 
@@ -229,7 +232,7 @@ void fuchsia::StaticLibTool::ConstructJob(Compilation &C, 
const JobAction &JA,
 
   for (const auto &II : Inputs) {
 if (II.isFilename()) {
-   CmdArgs.push_back(II.getFilename());
+  CmdArgs.push_back(II.getFilename());
 }
   }
 
@@ -343,16 +346,14 @@ std::string Fuchsia::ComputeEffectiveClangTriple(const 
ArgList &Args,
   return Triple.str();
 }
 
-Tool *Fuchsia::buildLinker() const {
-  return new tools::fuchsia::Linker(*this);
-}
+Tool *Fuchsia::buildLinker() const { return new tools::fuchsia::Linker(*this); 
}
 
 Tool *Fuchsia::buildStaticLibTool() const {
   return new tools::fuchsia::StaticLibTool(*this);
 }
 
-ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
-const ArgList &Args) const {
+ToolChain::RuntimeLibType
+Fuchsia::GetRuntimeLibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(clang::driver::options::OPT_rtlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "compiler-rt")
@@ -363,13 +364,12 @@ ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
   return ToolChain::RLT_CompilerRT;
 }
 
-ToolChain::CXXStdlibType
-Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
+ToolChain::CXXStdlibType Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "libc++")
   getDriver().Diag(diag::err_drv_invalid_stdlib_name)
-<< A->getAsString(Args);
+  << A->getAsString(Args);
   }
 
   return ToolChain::CST_Libcxx;
diff --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index 83dee16981690a..cf92f85040901c 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -297,3 +297,9 @@
 // RUN: %clang --target=riscv64-unknown-fuchsia -mno-relax -### %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=RISCV64-FLAGS %s
 // RISCV64-FLAGS: "-X" "--no-relax"
+
+// RUN: %clang -### %s --target=x86_64-unknown-fuchsia 2>&1 \
+// RUN: -nostdlib -nolibc \
+// RUN: | FileCheck %s -check-prefix=CHECK-NOSTDLIB-NOLIBC
+// CHECK-NOSTDLIB-NOLIBC-NOT: "warning:"
+// CHECK-NOSTDLIB-NOLIBC-NOT: "error:"

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

[clang] [Driver][Fuchsia] Avoid "argument unused" warnings (PR #118416)

[Roland McGrath via cfe-commits]

https://github.com/frobtech ready_for_review 
https://github.com/llvm/llvm-project/pull/118416
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][Fuchsia] Avoid "argument unused" warnings (PR #118416)

[Roland McGrath via cfe-commits]

https://github.com/frobtech updated 
https://github.com/llvm/llvm-project/pull/118416

>From 5a039fa6003a7612ddc6603192a121d92d3903cc Mon Sep 17 00:00:00 2001
From: Roland McGrath 
Date: Mon, 2 Dec 2024 13:33:47 -0800
Subject: [PATCH] [Driver][Fuchsia] Avoid "argument unused" warnings

There should not be an error or warning reported for using
redundant options to control what goes into the link.  For
example, -nolibc -nostdlib.
---
 clang/lib/Driver/ToolChains/Fuchsia.cpp | 30 -
 clang/test/Driver/fuchsia.c |  6 +
 2 files changed, 21 insertions(+), 15 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Fuchsia.cpp 
b/clang/lib/Driver/ToolChains/Fuchsia.cpp
index 72accbff4a3bf2..c2badc80a7b452 100644
--- a/clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ b/clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -156,6 +156,12 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
+  // Sample these options first so they are claimed even under -nostdlib et al.
+  bool NoLibc = Args.hasArg(options::OPT_nolibc);
+  bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
+ !Args.hasArg(options::OPT_static);
+  bool Pthreads = Args.hasArg(options::OPT_pthread, options::OPT_pthreads);
+  bool SplitStack = Args.hasArg(options::OPT_fsplit_stack);
   if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs,
options::OPT_r)) {
 if (Args.hasArg(options::OPT_static))
@@ -163,8 +169,6 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 if (D.CCCIsCXX()) {
   if (ToolChain.ShouldLinkCXXStdlib(Args)) {
-bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) 
&&
-   !Args.hasArg(options::OPT_static);
 CmdArgs.push_back("--push-state");
 CmdArgs.push_back("--as-needed");
 if (OnlyLibstdcxxStatic)
@@ -188,14 +192,13 @@ void fuchsia::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 
 AddRunTimeLibs(ToolChain, D, CmdArgs, Args);
 
-if (Args.hasArg(options::OPT_pthread) ||
-Args.hasArg(options::OPT_pthreads))
+if (Pthreads)
   CmdArgs.push_back("-lpthread");
 
-if (Args.hasArg(options::OPT_fsplit_stack))
+if (SplitStack)
   CmdArgs.push_back("--wrap=pthread_create");
 
-if (!Args.hasArg(options::OPT_nolibc))
+if (!NoLibc)
   CmdArgs.push_back("-lc");
   }
 
@@ -229,7 +232,7 @@ void fuchsia::StaticLibTool::ConstructJob(Compilation &C, 
const JobAction &JA,
 
   for (const auto &II : Inputs) {
 if (II.isFilename()) {
-   CmdArgs.push_back(II.getFilename());
+  CmdArgs.push_back(II.getFilename());
 }
   }
 
@@ -343,16 +346,14 @@ std::string Fuchsia::ComputeEffectiveClangTriple(const 
ArgList &Args,
   return Triple.str();
 }
 
-Tool *Fuchsia::buildLinker() const {
-  return new tools::fuchsia::Linker(*this);
-}
+Tool *Fuchsia::buildLinker() const { return new tools::fuchsia::Linker(*this); 
}
 
 Tool *Fuchsia::buildStaticLibTool() const {
   return new tools::fuchsia::StaticLibTool(*this);
 }
 
-ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
-const ArgList &Args) const {
+ToolChain::RuntimeLibType
+Fuchsia::GetRuntimeLibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(clang::driver::options::OPT_rtlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "compiler-rt")
@@ -363,13 +364,12 @@ ToolChain::RuntimeLibType Fuchsia::GetRuntimeLibType(
   return ToolChain::RLT_CompilerRT;
 }
 
-ToolChain::CXXStdlibType
-Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
+ToolChain::CXXStdlibType Fuchsia::GetCXXStdlibType(const ArgList &Args) const {
   if (Arg *A = Args.getLastArg(options::OPT_stdlib_EQ)) {
 StringRef Value = A->getValue();
 if (Value != "libc++")
   getDriver().Diag(diag::err_drv_invalid_stdlib_name)
-<< A->getAsString(Args);
+  << A->getAsString(Args);
   }
 
   return ToolChain::CST_Libcxx;
diff --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index 83dee16981690a..cf92f85040901c 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -297,3 +297,9 @@
 // RUN: %clang --target=riscv64-unknown-fuchsia -mno-relax -### %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=RISCV64-FLAGS %s
 // RISCV64-FLAGS: "-X" "--no-relax"
+
+// RUN: %clang -### %s --target=x86_64-unknown-fuchsia 2>&1 \
+// RUN: -nostdlib -nolibc \
+// RUN: | FileCheck %s -check-prefix=CHECK-NOSTDLIB-NOLIBC
+// CHECK-NOSTDLIB-NOLIBC-NOT: "warning:"
+// CHECK-NOSTDLIB-NOLIBC-NOT: "error:"

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

[clang] [clang] fix uefi target for aarch64 & x86_64 (PR #120632)

[Roland McGrath via cfe-commits]

@@ -713,8 +713,8 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
   X86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : X86TargetInfo(Triple, Opts) {
 const bool IsX32 = getTriple().isX32();
-bool IsWinCOFF =
-getTriple().isOSWindows() && getTriple().isOSBinFormatCOFF();
+bool IsWinCOFF = (getTriple().isOSWindows() || getTriple().isUEFI()) &&
+ getTriple().isOSBinFormatCOFF();
 LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64;

frobtech wrote:

Note that some of these are things we'll eventually want command-line switch 
flexibility for. Matching Windows all around is the right default. But 
structurally, keep in mind that these are no things intrinsic to the UEFI 
target per se but to a particular set of C/C++ API expectations that future 
users (i.e. me) will want to have the option of configuring to be consistent 
with other norms rather than Windows norms.

https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] fix uefi target for aarch64 & x86_64 (PR #120632)

[Roland McGrath via cfe-commits]

@@ -713,8 +713,8 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
   X86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : X86TargetInfo(Triple, Opts) {
 const bool IsX32 = getTriple().isX32();
-bool IsWinCOFF =
-getTriple().isOSWindows() && getTriple().isOSBinFormatCOFF();
+bool IsWinCOFF = (getTriple().isOSWindows() || getTriple().isUEFI()) &&
+ getTriple().isOSBinFormatCOFF();
 LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64;

frobtech wrote:

> @frobtech Yeah, that's kinda why I am unsure of the changes suggested.

Here AFAICT `IsWinCOFF` is being used only to choose the [datalayout 
string](https://llvm.org/docs/LangRef.html#langref-datalayout).  The only 
difference I see is `m:w` vs `m:e`, which is about assembler symbol naming 
details.  That's about the rules and conventions for PE-COFF compilers, 
assemblers, and linkers. This one case I don't think is something where UEFI 
users would ever need an option to differ from Windows users. There's probably 
only one right way to interface with the linker.

It seems to be called `IsWinCOFF` mainly because the way it's been checked for 
is "is COFF and is Windows".  I suspect that "is COFF" is true for other forms 
of COFF that aren't PE-COFF, but there isn't an `isOSBinFormatPECOFF()` that 
distinguishes, so this has been used as a proxy without explanation.  For this 
case, `IsPECOFF` would be better name locally, anyway, to express what it is 
that matters to the check.

IMHO it would be wisest *not* to go around making lots of things write out 
`...isOsWindows() || ...isOsUEFI()`.  Instead there should be an 
`.IsOSBinFormatPECOFF()` or the like (probably written as just that same OR 
anyway), where it's clearly expressed in the name of the call what property it 
is that is the determinant for each use case.

Just in this same file there are other local variables called `IsWinCOFF`, 
presumably likewise named because they are set the same way rather than clearly 
expressing what they are really checking for.  But that other use is do set 
`MaxVectorAlign`, which seems a lot like something that's really about runtime 
ABI subtleties, perhaps such as the expectations about stack and heap 
alignment.  Something like that very well may more properly be for Windows (and 
I don't know why it's for Windows&&COFF instead of just for Windows, maybe 
there's a distinction), and not for "all PE-COFF" and thus not for UEFI.

https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] UEFI ABI fixes for X86_64 (PR #124992)

[Roland McGrath via cfe-commits]

@@ -74,7 +74,7 @@ static CCMangling getCallingConvMangling(const ASTContext 
&Context,
   if (FD->isMain() && FD->getNumParams() == 2)
 return CCM_WasmMainArgcArgv;
 
-  if (!Triple.isOSWindows() || !Triple.isX86())
+  if (!Triple.isOSWindowsOrUEFI() || !Triple.isX86())

frobtech wrote:

As we discussed offline, I'd really rather see all sites like this use a 
predicate that's specific to what matters to the call site in precise terms.  
This predicate is really an answer to the question rather than the question 
that should be asked.  It presumes the answer is "Windows or UEFI targets", 
when the question it should be asking is something more like, "What C++ ABI 
name mangling regime is in use by this target?"

https://github.com/llvm/llvm-project/pull/124992
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] UEFI ABI fixes for X86_64 (PR #124992)

[Roland McGrath via cfe-commits]

@@ -5193,12 +5193,12 @@ bool Sema::CheckCallingConvAttr(const ParsedAttr 
&Attrs, CallingConv &CC,
 CC = CC_X86RegCall;
 break;
   case ParsedAttr::AT_MSABI:
-CC = Context.getTargetInfo().getTriple().isOSWindows() ? CC_C :
- CC_Win64;
+CC = Context.getTargetInfo().getTriple().isOSWindowsOrUEFI() ? CC_C

frobtech wrote:

This really highlights how `getTargetInfo().getCallingConv()` is what we ought 
to have.  For now it can be defined just this way, but in future it might be 
controlled by switches within a given target like UEFI.  But right now, it 
makes code like this and `checkVAStartABI` much clearer.

https://github.com/llvm/llvm-project/pull/124992
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [llvm] Enable TLSDESC by default on Fuchsia targets (PR #124990)

[Roland McGrath via cfe-commits]

@@ -1119,7 +1119,9 @@ class Triple {
 
   /// True if the target supports both general-dynamic and TLSDESC, and TLSDESC

frobtech wrote:

This comment is not precisely true of all `isOSFuchsia()` cases. That is, it 
says this is true only if the target supports non-TLSDESC as a non-default 
option.  That's not true for `aarch64-*`, so it's not true for `*-fuchsia`.
If that's actually fine for how this is used, then the comment here should be 
changed.

https://github.com/llvm/llvm-project/pull/124990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [llvm] Enable TLSDESC by default on Fuchsia targets (PR #124990)

[Roland McGrath via cfe-commits]

https://github.com/frobtech approved this pull request.


https://github.com/llvm/llvm-project/pull/124990
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] fix uefi target for aarch64 & x86_64 (PR #120632)

[Roland McGrath via cfe-commits]

@@ -820,43 +820,6 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
   }
 };
 
-// x86-64 UEFI target
-class LLVM_LIBRARY_VISIBILITY UEFIX86_64TargetInfo
-: public UEFITargetInfo {
-public:
-  UEFIX86_64TargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
-  : UEFITargetInfo(Triple, Opts) {
-this->TheCXXABI.set(TargetCXXABI::Microsoft);

frobtech wrote:

UEFI has nothing to say about C++. It is an ABI spec that is described in terms 
of C. It says nothing about what code not directly interacting with UEFI ABIs 
might do.

That said, heretofore the only way to compile code directly for the UEFI ABI is 
to use the Windows target.  Thus, the expectations for existing source code 
that targets UEFI directly via Clang is to get all the ABI and API details of 
whatever language as the Windows target does them (except of course for the 
actual OS-specific aspects per se).  So for all "ABI choice" things, the 
sensible default for UEFI target on $ARCH is what the Windows target for $ARCH 
does.  This goes for what type long is, what C++ ABI to use, alignment quirks, 
etc.  It also goes for language API details/extensions that are not directly 
related to Windows per se, such as the various pragmas for PECOFF-specific 
features or Windows spellings of generic extensions (e.g. `-fms-extensions` 
stuff).

Once we have the UEFI targets on their feet, we'll want to look into offering 
flexibility to make non-default choices (i.e. choices different from Windows) 
for various ABI and API things.  But we can get to that later.

https://github.com/llvm/llvm-project/pull/120632
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Driver][UEFI] Enable Microsoft extensions (PR #121875)

[Roland McGrath via cfe-commits]

https://github.com/frobtech approved this pull request.

LGTM given a driver test as Petr mentioned.


https://github.com/llvm/llvm-project/pull/121875
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits