[PATCH] D110614: [clang-tidy] Fix false positives in cppcoreguidelines-virtual-class-destructor

2021-09-29 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added a subscriber: whisperity.
carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp:26
 
+  ast_matchers::internal::Matcher InheritsVirtualDestructor =
+  hasAnyBase(hasType(cxxRecordDecl(has(cxxDestructorDecl(isVirtual());

aaron.ballman wrote:
> I'm confused as to why this is necessary -- this AST matcher calls through to 
> `CXXMethodDecl::isVirtual()` which is different from `isVirtualAsWritten()` 
> and should already account for inheriting the virtual specifier.
In the Bug report, @whisperity mentioned this problem could be somewhere else:

> Nevertheless, if you check the AST for the test code at 
> http://godbolt.org/z/6MqG4Kb85, we can see that the derived destructor is in 
> fact **not** marked virtual. So it's Sema which does not give this flag to 
> the AST-clients properly.

I don't even know what Sema is so I don't really know how to fix it at that 
level, and I wonder if it would break other things.

If anyone has some time to walk me through where the fix should go I'm happy to 
try it out!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110614/new/

https://reviews.llvm.org/D110614

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


[PATCH] D110673: [clang] Don't modify OptRemark if the argument is not relevant

2021-09-29 Thread James Nagurne via Phabricator via cfe-commits
JamesNagurne added a comment.

I'll take a quick look tomorrow, but the general idea is that on calling 
ParseOptimizationRemark on line 1909 with a -cc1 command line containing 
-Rpass=inline -Rno-pass, Opts.OptimizationRemarkMissed and 
Opts.OptimizationRemarkAnalysis are set to valid patterns (Regex is ".*", 
Pattern is "", and Kind is RK_Missing). This happens around line 1909 in the 
change set.

This configuration makes it into the LLVM backend. When prompted by specific 
calls to llvm::shouldInline (or something similar, can't remember the spelling 
off hand), emits an optimization-missed remark when one of the functions in the 
test's IR is not inlined.

> "...in clang::ProcessWarningOptions() we'll separately look at all -R 
> arguments and turn on/off corresponding diagnostic groups."

Why would -Rno-pass turn off "pass-missed" or "pass-analysis" diagnostic 
groups? That seems counterintuitive. They seem to be different groups, 
considering how they're used in the backend.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110673/new/

https://reviews.llvm.org/D110673

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


[PATCH] D110614: [clang-tidy] Fix false positives in cppcoreguidelines-virtual-class-destructor

2021-09-29 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp:216-218
+template 
+struct TemplatedDerived : PublicVirtualBaseStruct {
+};

aaron.ballman wrote:
> I think there are more interesting template test cases that should be checked.
> ```
> // What to do when the derived type is definitely polymorphic
> // but the base class may or may not be?
> template 
> struct Derived : Ty {
>   virtual void func();
> };
> 
> struct S {};
> struct  T { virtual ~T(); };
> 
> void instantiate() {
>   Derived d1; // Diagnose
>   Derived d2; // Don't diagnose
> }
> ```
> 
Very interesting example.

The problem is that the diagnostic is shown where `Derived` is, not where the 
template is instantiated. How to go about that?

Seems like more testing and better diagnostics are needed to lower the amount 
of false positives, I wonder if we should disable the test meanwhile?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110614/new/

https://reviews.llvm.org/D110614

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


[PATCH] D110684: [RISCV] Define _m intrinsics as builtins, instead of macros.

2021-09-29 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai created this revision.
HsiangKai added reviewers: craig.topper, rogfer01, frasercrmck.
Herald added subscribers: achieveartificialintelligence, StephenFan, vkmr, 
dexonsmith, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, 
benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, edward-jones, 
zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, 
rbar, asb.
HsiangKai requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

In the original design, we levarage _mt intrinsics to define macros for
_m intrinsics. Such as,

__builtin_rvv_vadd_vv_i8m1_mt((vbool8_t)(op0), (vint8m1_t)(op1), 
(vint8m1_t)(op2), (vint8m1_t)(op3), (size_t)(op4), (size_t)VE_TAIL_AGNOSTIC)

However, we could not define generic interface for mask intrinsics any
more due to clang_builtin_alias only accepts clang builtins as its
argument.

In the example,
__rvv_overloaded
 __attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1_mt)))

  vint8m1_t vadd(vbool8_t op0, vint8m1_t op1, vint8m1_t op2, vint8m1_t
  op3, size_t op4, size_t op5);

op5 is the tail policy argument. When users want to use vadd generic
interface for masked vector add, they need to specify tail policy in the
previous design. In this patch, we define _m intrinsics as clang
builtins to solve the problem.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110684

Files:
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics/vadd-policy.c
  clang/utils/TableGen/RISCVVEmitter.cpp

Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -158,6 +158,7 @@
   bool HasMaskedOffOperand;
   bool HasVL;
   bool HasPolicy;
+  bool IsPolicyIntrinsic;
   bool HasNoMaskedOverloaded;
   bool HasAutoDef; // There is automiatic definition in header
   std::string ManualCodegen;
@@ -173,7 +174,8 @@
   RVVIntrinsic(StringRef Name, StringRef Suffix, StringRef MangledName,
StringRef MangledSuffix, StringRef IRName, bool HasSideEffects,
bool IsMask, bool HasMaskedOffOperand, bool HasVL,
-   bool HasPolicy, bool HasNoMaskedOverloaded, bool HasAutoDef,
+   bool HasPolicy, bool IsPolicyIntrinsic,
+   bool HasNoMaskedOverloaded, bool HasAutoDef,
StringRef ManualCodegen, const RVVTypes &Types,
const std::vector &IntrinsicTypes,
StringRef RequiredExtension, unsigned NF);
@@ -185,6 +187,7 @@
   bool hasMaskedOffOperand() const { return HasMaskedOffOperand; }
   bool hasVL() const { return HasVL; }
   bool hasPolicy() const { return HasPolicy; }
+  bool isPolicyIntrinsic() const { return IsPolicyIntrinsic; }
   bool hasNoMaskedOverloaded() const { return HasNoMaskedOverloaded; }
   bool hasManualCodegen() const { return !ManualCodegen.empty(); }
   bool hasAutoDef() const { return HasAutoDef; }
@@ -201,9 +204,6 @@
   // init the RVVIntrinsic ID and IntrinsicTypes.
   void emitCodeGenSwitchBody(raw_ostream &o) const;
 
-  // Emit the define macors for mask intrinsics using _mt intrinsics.
-  void emitIntrinsicMaskMacro(raw_ostream &o) const;
-
   // Emit the macros for mapping C/C++ intrinsic function to builtin functions.
   void emitIntrinsicMacro(raw_ostream &o) const;
 
@@ -764,14 +764,16 @@
StringRef NewMangledName, StringRef MangledSuffix,
StringRef IRName, bool HasSideEffects, bool IsMask,
bool HasMaskedOffOperand, bool HasVL, bool HasPolicy,
-   bool HasNoMaskedOverloaded, bool HasAutoDef,
-   StringRef ManualCodegen, const RVVTypes &OutInTypes,
+   bool IsPolicyIntrinsic, bool HasNoMaskedOverloaded,
+   bool HasAutoDef, StringRef ManualCodegen,
+   const RVVTypes &OutInTypes,
const std::vector &NewIntrinsicTypes,
StringRef RequiredExtension, unsigned NF)
 : IRName(IRName), HasSideEffects(HasSideEffects), IsMask(IsMask),
   HasMaskedOffOperand(HasMaskedOffOperand), HasVL(HasVL),
-  HasPolicy(HasPolicy), HasNoMaskedOverloaded(HasNoMaskedOverloaded),
-  HasAutoDef(HasAutoDef), ManualCodegen(ManualCodegen.str()), NF(NF) {
+  HasPolicy(HasPolicy), IsPolicyIntrinsic(IsPolicyIntrinsic),
+  HasNoMaskedOverloaded(HasNoMaskedOverloaded), HasAutoDef(HasAutoDef),
+  ManualCodegen(ManualCodegen.str()), NF(NF) {
 
   // Init Name and MangledName
   Name = NewName.str();
@@ -785,7 +787,7 @@
 MangledName += "_" + MangledSuffix.str();
   if (IsMask) {
 Name += "_m";
-if (HasPolicy)
+if (IsPolicyIntrinsic)
   Name += "t";
   }
   // Init RISC-V

[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

2021-09-29 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

nits




Comment at: clang/test/Analysis/ptr-arith.c:336
+  int v;
+  char y;
+};

It's probably unnecessary.



Comment at: clang/test/Analysis/ptr-arith.c:339
+
+void clang_analyzer_dump(int);
+

I would probably put this at the top of the file.



Comment at: clang/test/Analysis/ptr-arith.c:344
+  struct s ss = *ps;
+  clang_analyzer_dump((*ps).v);// expected-warning{{reg_$3}.v>}}
+  clang_analyzer_dump(ps[0].v);// expected-warning{{reg_$3}.v>}}

You should not hardcode the internal counter in the tests.
You can use regexp matching to workaround the issue. Here is an example:
`// expected-warning-re@-2 {{reg_${{[[:digit:]]+`

`@-2` denotes that we expect a warning two lines above.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110625/new/

https://reviews.llvm.org/D110625

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


[PATCH] D110622: [HIPSPV][3/4] Enable SPIR-V emission for HIP

2021-09-29 Thread Henry Linjamäki via Phabricator via cfe-commits
linjamaki created this revision.
Herald added subscribers: Naghasan, dexonsmith, dang, Anastasia, yaxunl, 
jholewinski.
linjamaki updated this revision to Diff 375783.
linjamaki added a comment.
linjamaki updated this revision to Diff 375786.
linjamaki added reviewers: yaxunl, bader.
linjamaki published this revision for review.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Style fixes.


linjamaki added a comment.

Remove noisy change.


This patch enables SPIR-V binary emission for HIP device code via the
HIPSPV tool chain.

- ‘--offload’ option, which is envisioned in [1], is added for specifying 
offload targets. This option is used to override default device target 
(amdgcn-amd-amdhsa) for HIP compilation for emitting device code as SPIR-V 
binary. The option is handled in getHIPOffloadTargetTriple().

- getOffloadingDeviceToolChain() function (based on the design in the SYCL 
repository) is added to select HIPSPVToolChain when HIP offload target is 
‘spirv64’.

- The HIPActionBuilder is modified to produce LLVM IR at the backend phase. 
HIPSPV tool chain expects to receive HIP device code as LLVM IR so it can run 
external LLVM passes over them. HIPSPV TC is also responsible for emitting the 
SPIR-V binary.

- A Cuda GPU architecture ‘generic’ is added. The name is picked from the LLVM 
SPIR-V Backend. In the HIPSPV code path the architecture name is inserted to 
the bundle entry ID as target ID. Target ID is expected to be always present so 
a component in the target triple is not mistaken as target ID.

- Tests are added for checking the HIPSPV tool chain.

[1]: https://lists.llvm.org/pipermail/cfe-dev/2020-December/067362.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110622

Files:
  clang/include/clang/Basic/Cuda.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/Inputs/hipspv-dev-lib/a/a.bc
  clang/test/Driver/Inputs/hipspv-dev-lib/b/b.bc
  clang/test/Driver/Inputs/hipspv-dev-lib/hipspv-spirv64.bc
  clang/test/Driver/Inputs/hipspv/bin/.hipVersion
  clang/test/Driver/Inputs/hipspv/lib/hip-device-lib/hipspv-spirv64.bc
  clang/test/Driver/Inputs/hipspv/lib/libLLVMHipSpvPasses.so
  clang/test/Driver/Inputs/pass-plugin.so
  clang/test/Driver/hipspv-device-libs.hip
  clang/test/Driver/hipspv-pass-plugin.hip
  clang/test/Driver/hipspv-toolchain-rdc.hip
  clang/test/Driver/hipspv-toolchain.hip
  clang/test/Driver/invalid-offload-options.cpp

Index: clang/test/Driver/invalid-offload-options.cpp
===
--- /dev/null
+++ clang/test/Driver/invalid-offload-options.cpp
@@ -0,0 +1,18 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// UNSUPPORTED: system-windows
+
+// RUN: %clang -### -x hip -target x86_64-linux-gnu --offload= \
+// RUN:   --hip-path=%S/Inputs/hipspv -nogpuinc -nogpulib %s \
+// RUN: 2>&1 | FileCheck --check-prefix=INVALID-TARGET %s
+// RUN: %clang -### -x hip -target x86_64-linux-gnu --offload=foo   \
+// RUN:   --hip-path=%S/Inputs/hipspv -nogpuinc -nogpulib %s \
+// RUN: 2>&1 | FileCheck --check-prefix=INVALID-TARGET %s
+
+// INVALID-TARGET: error: Invalid or unsupported offload target: '{{.*}}'
+
+// RUN: %clang -### -x hip -target x86_64-linux-gnu --offload=foo,bar \
+// RUN:   --hip-path=%S/Inputs/hipspv -nogpuinc -nogpulib %s \
+// RUN: 2>&1 | FileCheck --check-prefix=TOO-MANY-TARGETS %s
+
+// TOO-MANY-TARGETS: error: Only one offload target is supported in HIP.
Index: clang/test/Driver/hipspv-toolchain.hip
===
--- /dev/null
+++ clang/test/Driver/hipspv-toolchain.hip
@@ -0,0 +1,37 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// UNSUPPORTED: system-windows
+
+// RUN: %clang -### -target x86_64-linux-gnu --offload=spirv64 \
+// RUN:   --hip-path=%S/Inputs/hipspv -nohipwrapperinc %s \
+// RUN: 2>&1 | FileCheck %s
+
+// CHECK: [[CLANG:".*clang.*"]] "-cc1" "-triple" "spirv64"
+// CHECK-SAME: "-aux-triple" "{{.*}}" "-emit-llvm-bc"
+// CHECK-SAME: "-fcuda-is-device"
+// CHECK-SAME: "-fcuda-allow-variadic-functions"
+// CHECK-SAME: "-mlink-builtin-bitcode" {{".*/hipspv/lib/hip-device-lib/hipspv-spirv64.bc"}}
+// CHECK-SAME: "-isystem" {{".*/hipspv/include"}}
+// CHECK-SAME: "-fhip-new-launch-api"
+// CHECK-SAME: "-o" [[DEV_BC:".*bc"]]
+// CHECK-SAME: "-x" "hip"
+
+// CHECK: {{".*llvm-link"}} [[DEV_BC]] "-o" [[LINK_BC:".*bc"]]
+
+// CHECK: {{".*opt"}} [[LINK_BC]] "-load-pass-plugin"
+// CHECK-SAME: {{".*/hipspv/lib/libLLVMHipSpvPasses.so"}}
+// CHECK-SAME: "-passes=hip-post-link-passes" "-o" [[LOWER_BC:".*bc"]]
+
+// CHECK: {{".*llvm-spirv"}} "-spirv-max-version=1.1" "--spirv-ext=+all"
+// CHECK-SAME:

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

Nice!




Comment at: clang/lib/Basic/CLWarnings.cpp:17
+  switch (CLWarningID) {
+  case 4005: return "macro-redefined";
+  case 4018: return "sign-compare";

Would it be possible to reference the DiagGroup symbolically here somehow 
instead of using a string? That way, if the DiagGroup gets renamed, we don't 
risk forgetting to update this string.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110668/new/

https://reviews.llvm.org/D110668

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


[PATCH] D110687: [Driver] Check that short triples are supported for Fuchsia

2021-09-29 Thread Petr Hosek via Phabricator via cfe-commits
phosek created this revision.
phosek added reviewers: leonardchan, haowei, gulfem.
Herald added subscribers: pengfei, s.egerton, simoncook, kristof.beyls.
phosek requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

{x86_64,aarch64}-unknown-fuchsia and {x86_64,aarch64}-fuchsia should
behave identically as targets, update the test to make sure that's the
case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110687

Files:
  clang/test/Driver/fuchsia.c
  clang/test/Driver/fuchsia.cpp


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -13,6 +13,21 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"
Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -10,6 +10,18 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -13,6 +13,21 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"
Index: clang/test/Driver/fuchsia.c
==

[PATCH] D110614: [clang-tidy] Fix false positives in cppcoreguidelines-virtual-class-destructor

2021-09-29 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp:26
 
+  ast_matchers::internal::Matcher InheritsVirtualDestructor =
+  hasAnyBase(hasType(cxxRecordDecl(has(cxxDestructorDecl(isVirtual());

carlosgalvezp wrote:
> aaron.ballman wrote:
> > I'm confused as to why this is necessary -- this AST matcher calls through 
> > to `CXXMethodDecl::isVirtual()` which is different from 
> > `isVirtualAsWritten()` and should already account for inheriting the 
> > virtual specifier.
> In the Bug report, @whisperity mentioned this problem could be somewhere else:
> 
> > Nevertheless, if you check the AST for the test code at 
> > http://godbolt.org/z/6MqG4Kb85, we can see that the derived destructor is 
> > in fact **not** marked virtual. So it's Sema which does not give this flag 
> > to the AST-clients properly.
> 
> I don't even know what Sema is so I don't really know how to fix it at that 
> level, and I wonder if it would break other things.
> 
> If anyone has some time to walk me through where the fix should go I'm happy 
> to try it out!
`Sema` is the Clang module responsible for **sema**ntic analysis, hence the 
name. It is an egregiously complex and huge class (you know something's weird 
when a header of 80k lines is implemented over like 20 separate CPP files...) 
that is basically responsible for building the AST.

It was just a hunch from my side because I went into Godbolt to try seeing why 
the matching logic would fail!



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp:26
 
+  ast_matchers::internal::Matcher InheritsVirtualDestructor =
+  hasAnyBase(hasType(cxxRecordDecl(has(cxxDestructorDecl(isVirtual());

whisperity wrote:
> carlosgalvezp wrote:
> > aaron.ballman wrote:
> > > I'm confused as to why this is necessary -- this AST matcher calls 
> > > through to `CXXMethodDecl::isVirtual()` which is different from 
> > > `isVirtualAsWritten()` and should already account for inheriting the 
> > > virtual specifier.
> > In the Bug report, @whisperity mentioned this problem could be somewhere 
> > else:
> > 
> > > Nevertheless, if you check the AST for the test code at 
> > > http://godbolt.org/z/6MqG4Kb85, we can see that the derived destructor is 
> > > in fact **not** marked virtual. So it's Sema which does not give this 
> > > flag to the AST-clients properly.
> > 
> > I don't even know what Sema is so I don't really know how to fix it at that 
> > level, and I wonder if it would break other things.
> > 
> > If anyone has some time to walk me through where the fix should go I'm 
> > happy to try it out!
> `Sema` is the Clang module responsible for **sema**ntic analysis, hence the 
> name. It is an egregiously complex and huge class (you know something's weird 
> when a header of 80k lines is implemented over like 20 separate CPP files...) 
> that is basically responsible for building the AST.
> 
> It was just a hunch from my side because I went into Godbolt to try seeing 
> why the matching logic would fail!
Sadly I'm a bit short on time nowadays due to university and bureaucracy, but 
remember that either Clang-Query is your friend (available on Godbolt, with 
visual highlight of the matched things back in the source code!) and you can 
sandbox match expressions there (`match ...` for matching, `let X ...` for 
saving `...` into `X` to reuse later), or you could do `AnyASTNode->dump()` in 
the code while development to observe what the node is on the output.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/VirtualClassDestructorCheck.cpp:36
   has(cxxDestructorDecl(isProtected(), unless(isVirtual()))
   .bind("ProblematicClassOrStruct"),
   this);

Nit: `ProblematicRecord` might be a better, and certainly shorter, name, while 
meaning the same thing.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp:206
+
+// The following two checks cover bug 
https://bugs.llvm.org/show_bug.cgi?id=51912
+// Forward declarations

aaron.ballman wrote:
> Rather than use a comment, we typically put the test cases into a namespace. 
> e.g.,
> ```
> namespace PR51912 {
> // tests cases for that bug live here
> } // namespace PR51912
> ```
Nit: "PR" could be mistaken for //Pull Request// especially since the project 
now lives on GitHub (even though we don't use pull requests (yet?)), so maybe 
explicitly saying `Bugzilla_51912` or something like that instead would be more 
obvious. And it's worthy to put the link in, still.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp:208
+// Forward declarations
+// CHECK-MESSAGES-NOT: :[[@LINE+1]]:8: warning: destructor of 
'ForwardDeclaredStruct' is publi

[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

2021-09-29 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

This is going to break Fuchsia as implemented. We assume that 
`{x86_64,aarch64}-unknown-fuchsia` and `{x86_64,aarch64}-fuchsia` behave 
identically and developers are allowed to use whichever spelling they prefer. 
With this change that's no longer true. This may break other platforms that 
make similar assumptions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110663/new/

https://reviews.llvm.org/D110663

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


[PATCH] D109625: [compiler-rt] Ensure required deps for tests targets are actually built

2021-09-29 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

I'm still unsure if this is the right strategy because it creates a dependency 
cycle. Specifically, you have the LLVM build trigger the build of runtimes, and 
that build would invoke LLVM build again to ensure that the necessary tools 
have been built. That shouldn't be necessary though. The LLVM build already 
ensures that those tools are being built by making the runtimes build depend on 
these tools, see 
https://github.com/llvm/llvm-project/blob/ac2daacb310cbb1732de1c139be7a0e8e982169e/llvm/runtimes/CMakeLists.txt#L461

What might be needed is a way to tell the compiler-rt build where to find these 
tools. I looked elsewhere in LLVM and it seems like Polly is already taking 
that approach, see 
https://github.com/llvm/llvm-project/blob/main/polly/test/CMakeLists.txt#L6. Do 
you think that we could use this strategy?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109625/new/

https://reviews.llvm.org/D109625

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


[clang] 4da744a - [OpenCL] Fix as_type3 invalid store creation

2021-09-29 Thread Sven van Haastregt via cfe-commits

Author: Sven van Haastregt
Date: 2021-09-29T09:40:06+01:00
New Revision: 4da744a20ff58c9b3d8df0e2eb9e8b69d9e5cc3d

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

LOG: [OpenCL] Fix as_type3 invalid store creation

With -fpreserve-vec3-type enabled, a cast was not created when
converting from a non-vec3 type to a vec3 type, even though a
conversion to vec3 was performed.  This resulted in creation of
invalid store instructions.

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

Added: 


Modified: 
clang/lib/CodeGen/CGExprScalar.cpp
clang/test/CodeGenOpenCL/preserve_vec3.cl

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 67c581b46eae7..6bef004987828 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -4804,12 +4804,10 @@ Value *ScalarExprEmitter::VisitAsTypeExpr(AsTypeExpr 
*E) {
   // to vec4 if the original type is not vec4, then a shuffle vector to
   // get a vec3.
   if (NumElementsSrc != 3 && NumElementsDst == 3) {
-if (!CGF.CGM.getCodeGenOpts().PreserveVec3Type) {
-  auto *Vec4Ty = llvm::FixedVectorType::get(
-  cast(DstTy)->getElementType(), 4);
-  Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
- Vec4Ty);
-}
+auto *Vec4Ty = llvm::FixedVectorType::get(
+cast(DstTy)->getElementType(), 4);
+Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
+   Vec4Ty);
 
 Src = ConvertVec3AndVec4(Builder, CGF, Src, 3);
 Src->setName("astype");

diff  --git a/clang/test/CodeGenOpenCL/preserve_vec3.cl 
b/clang/test/CodeGenOpenCL/preserve_vec3.cl
index 2237cf1e27e46..3dc703d320eca 100644
--- a/clang/test/CodeGenOpenCL/preserve_vec3.cl
+++ b/clang/test/CodeGenOpenCL/preserve_vec3.cl
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown 
-fpreserve-vec3-type | FileCheck %s
 
 typedef char char3 __attribute__((ext_vector_type(3)));
+typedef char char8 __attribute__((ext_vector_type(8)));
 typedef short short3 __attribute__((ext_vector_type(3)));
 typedef double double2 __attribute__((ext_vector_type(2)));
 typedef float float3 __attribute__((ext_vector_type(3)));
@@ -38,6 +39,15 @@ void kernel float3_to_double2(global float3 *a, global 
double2 *b) {
   *b = __builtin_astype(*a, double2);
 }
 
+void kernel char8_to_short3(global short3 *a, global char8 *b) {
+  // CHECK-LABEL: spir_kernel void @char8_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast <8 x i8> addrspace(1)* %b to <4 x i16> 
addrspace(1)*
+  // CHECK: %[[LOAD_B:.*]] = load <4 x i16>, <4 x i16> addrspace(1)* %[[IN_BC]]
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[LOAD_B]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %a, align 8
+  *a = __builtin_astype(*b, short3);
+}
+
 void from_char3(char3 a, global int *out) {
   // CHECK-LABEL: void @from_char3
   // CHECK: %[[ASTYPE:.*]] = shufflevector <3 x i8> %a, <3 x i8> poison, <4 x 
i32> 
@@ -53,3 +63,19 @@ void from_short3(short3 a, global long *out) {
   // CHECK: store <4 x i16> %[[ASTYPE]], <4 x i16> addrspace(1)* %[[OUT_BC]]
   *out = __builtin_astype(a, long);
 }
+
+void scalar_to_char3(int a, global char3 *out) {
+  // CHECK-LABEL: void @scalar_to_char3
+  // CHECK: %[[IN_BC:.*]] = bitcast i32 %a to <4 x i8>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i8> %[[IN_BC]], <4 x i8> 
poison, <3 x i32> 
+  // CHECK: store <3 x i8> %[[ASTYPE]], <3 x i8> addrspace(1)* %out
+  *out = __builtin_astype(a, char3);
+}
+
+void scalar_to_short3(long a, global short3 *out) {
+  // CHECK-LABEL: void @scalar_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast i64 %a to <4 x i16>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[IN_BC]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %out
+  *out = __builtin_astype(a, short3);
+}



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


[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

2021-09-29 Thread Sven van Haastregt via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4da744a20ff5: [OpenCL] Fix as_type3 invalid store creation 
(authored by svenvh).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108470/new/

https://reviews.llvm.org/D108470

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGenOpenCL/preserve_vec3.cl


Index: clang/test/CodeGenOpenCL/preserve_vec3.cl
===
--- clang/test/CodeGenOpenCL/preserve_vec3.cl
+++ clang/test/CodeGenOpenCL/preserve_vec3.cl
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown 
-fpreserve-vec3-type | FileCheck %s
 
 typedef char char3 __attribute__((ext_vector_type(3)));
+typedef char char8 __attribute__((ext_vector_type(8)));
 typedef short short3 __attribute__((ext_vector_type(3)));
 typedef double double2 __attribute__((ext_vector_type(2)));
 typedef float float3 __attribute__((ext_vector_type(3)));
@@ -38,6 +39,15 @@
   *b = __builtin_astype(*a, double2);
 }
 
+void kernel char8_to_short3(global short3 *a, global char8 *b) {
+  // CHECK-LABEL: spir_kernel void @char8_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast <8 x i8> addrspace(1)* %b to <4 x i16> 
addrspace(1)*
+  // CHECK: %[[LOAD_B:.*]] = load <4 x i16>, <4 x i16> addrspace(1)* %[[IN_BC]]
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[LOAD_B]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %a, align 8
+  *a = __builtin_astype(*b, short3);
+}
+
 void from_char3(char3 a, global int *out) {
   // CHECK-LABEL: void @from_char3
   // CHECK: %[[ASTYPE:.*]] = shufflevector <3 x i8> %a, <3 x i8> poison, <4 x 
i32> 
@@ -53,3 +63,19 @@
   // CHECK: store <4 x i16> %[[ASTYPE]], <4 x i16> addrspace(1)* %[[OUT_BC]]
   *out = __builtin_astype(a, long);
 }
+
+void scalar_to_char3(int a, global char3 *out) {
+  // CHECK-LABEL: void @scalar_to_char3
+  // CHECK: %[[IN_BC:.*]] = bitcast i32 %a to <4 x i8>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i8> %[[IN_BC]], <4 x i8> 
poison, <3 x i32> 
+  // CHECK: store <3 x i8> %[[ASTYPE]], <3 x i8> addrspace(1)* %out
+  *out = __builtin_astype(a, char3);
+}
+
+void scalar_to_short3(long a, global short3 *out) {
+  // CHECK-LABEL: void @scalar_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast i64 %a to <4 x i16>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[IN_BC]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %out
+  *out = __builtin_astype(a, short3);
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -4804,12 +4804,10 @@
   // to vec4 if the original type is not vec4, then a shuffle vector to
   // get a vec3.
   if (NumElementsSrc != 3 && NumElementsDst == 3) {
-if (!CGF.CGM.getCodeGenOpts().PreserveVec3Type) {
-  auto *Vec4Ty = llvm::FixedVectorType::get(
-  cast(DstTy)->getElementType(), 4);
-  Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
- Vec4Ty);
-}
+auto *Vec4Ty = llvm::FixedVectorType::get(
+cast(DstTy)->getElementType(), 4);
+Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
+   Vec4Ty);
 
 Src = ConvertVec3AndVec4(Builder, CGF, Src, 3);
 Src->setName("astype");


Index: clang/test/CodeGenOpenCL/preserve_vec3.cl
===
--- clang/test/CodeGenOpenCL/preserve_vec3.cl
+++ clang/test/CodeGenOpenCL/preserve_vec3.cl
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown -fpreserve-vec3-type | FileCheck %s
 
 typedef char char3 __attribute__((ext_vector_type(3)));
+typedef char char8 __attribute__((ext_vector_type(8)));
 typedef short short3 __attribute__((ext_vector_type(3)));
 typedef double double2 __attribute__((ext_vector_type(2)));
 typedef float float3 __attribute__((ext_vector_type(3)));
@@ -38,6 +39,15 @@
   *b = __builtin_astype(*a, double2);
 }
 
+void kernel char8_to_short3(global short3 *a, global char8 *b) {
+  // CHECK-LABEL: spir_kernel void @char8_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast <8 x i8> addrspace(1)* %b to <4 x i16> addrspace(1)*
+  // CHECK: %[[LOAD_B:.*]] = load <4 x i16>, <4 x i16> addrspace(1)* %[[IN_BC]]
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[LOAD_B]], <4 x i16> poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %a, align 8
+  *a = __builtin_astype(*b, short3);
+}
+
 void from_char3(char3 a, global int *out) {
   // CHECK-LABEL: void @from_char3
   // CHECK: %[[ASTYPE:.*]] = shufflevector <3 x i8> %a, <3 x i8> poison, <4 x i32> 
@@ -53,3 +63,19 @@
   // CHECK: store <4 x i16> %[[ASTYPE]], <4 

[PATCH] D110636: [OpenCL][NFC] Refactor vloada_half and vstorea_half decls

2021-09-29 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110636/new/

https://reviews.llvm.org/D110636

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


[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

2021-09-29 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers updated this revision to Diff 375810.
vabridgers added a comment.

updates per @steakhal comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110625/new/

https://reviews.llvm.org/D110625

Files:
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/test/Analysis/ptr-arith.c


Index: clang/test/Analysis/ptr-arith.c
===
--- clang/test/Analysis/ptr-arith.c
+++ clang/test/Analysis/ptr-arith.c
@@ -2,6 +2,7 @@
 // RUN: %clang_analyze_cc1 
-analyzer-checker=alpha.core.FixedAddr,alpha.core.PointerArithm,alpha.core.PointerSub,debug.ExprInspection
 -analyzer-store=region -Wno-pointer-to-int-cast -verify -triple 
i686-apple-darwin9 -Wno-tautological-pointer-compare -analyzer-config 
eagerly-assume=false %s
 
 void clang_analyzer_eval(int);
+void clang_analyzer_dump(int);
 
 void f1() {
   int a[10];
@@ -330,3 +331,26 @@
   simd_float2 x = {0, 1};
   return x[1]; // no-warning
 }
+
+struct s {
+  int v;
+};
+
+// These three expressions should produce the same sym vals.
+void struct_pointer_canon(struct s *ps) {
+  struct s ss = *ps;
+  clang_analyzer_dump((*ps).v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps[0].v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps->v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_eval((*ps).v == ps[0].v); // expected-warning{{TRUE}}
+  clang_analyzer_eval((*ps).v == ps->v);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ps[0].v == ps->v);   // expected-warning{{TRUE}}
+}
+
+void struct_pointer_canon_bidim(struct s **ps) {
+  struct s ss = **ps;
+  clang_analyzer_eval(&(ps[0][0].v) == &((*ps)->v)); // 
expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Core/Store.cpp
===
--- clang/lib/StaticAnalyzer/Core/Store.cpp
+++ clang/lib/StaticAnalyzer/Core/Store.cpp
@@ -442,6 +442,15 @@
 
 SVal StoreManager::getLValueElement(QualType elementType, NonLoc Offset,
 SVal Base) {
+
+  // Special case, if index is 0, return the same type as if
+  // this was not an array dereference.
+  if (Offset.isZeroConstant()) {
+QualType BT = Base.getType(this->Ctx);
+if (!BT.isNull() && BT->getPointeeType() == elementType)
+  return Base;
+  }
+
   // If the base is an unknown or undefined value, just return it back.
   // FIXME: For absolute pointer addresses, we just return that value back as
   //  well, although in reality we should return the offset added to that


Index: clang/test/Analysis/ptr-arith.c
===
--- clang/test/Analysis/ptr-arith.c
+++ clang/test/Analysis/ptr-arith.c
@@ -2,6 +2,7 @@
 // RUN: %clang_analyze_cc1 -analyzer-checker=alpha.core.FixedAddr,alpha.core.PointerArithm,alpha.core.PointerSub,debug.ExprInspection -analyzer-store=region -Wno-pointer-to-int-cast -verify -triple i686-apple-darwin9 -Wno-tautological-pointer-compare -analyzer-config eagerly-assume=false %s
 
 void clang_analyzer_eval(int);
+void clang_analyzer_dump(int);
 
 void f1() {
   int a[10];
@@ -330,3 +331,26 @@
   simd_float2 x = {0, 1};
   return x[1]; // no-warning
 }
+
+struct s {
+  int v;
+};
+
+// These three expressions should produce the same sym vals.
+void struct_pointer_canon(struct s *ps) {
+  struct s ss = *ps;
+  clang_analyzer_dump((*ps).v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps[0].v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_dump(ps->v);
+  // expected-warning-re@-1{{reg_${{[[:digit:]]+}}}.v>}}
+  clang_analyzer_eval((*ps).v == ps[0].v); // expected-warning{{TRUE}}
+  clang_analyzer_eval((*ps).v == ps->v);   // expected-warning{{TRUE}}
+  clang_analyzer_eval(ps[0].v == ps->v);   // expected-warning{{TRUE}}
+}
+
+void struct_pointer_canon_bidim(struct s **ps) {
+  struct s ss = **ps;
+  clang_analyzer_eval(&(ps[0][0].v) == &((*ps)->v)); // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Core/Store.cpp
===
--- clang/lib/StaticAnalyzer/Core/Store.cpp
+++ clang/lib/StaticAnalyzer/Core/Store.cpp
@@ -442,6 +442,15 @@
 
 SVal StoreManager::getLValueElement(QualType elementType, NonLoc Offset,
 SVal Base) {
+
+  // Special case, if index is 0, return the same type as if
+  // this was not an array dereference.
+  if (Offset.isZeroConstant()) {
+QualType BT = Base.getType(this->Ctx);
+if (!BT.isNull() && BT->getPointeeType() == elementType)
+  return Base;
+  }
+
   // If the base is an unknown or undefined value, just return it back.
   // FIXME: For absolute pointer addresses, we just return that value back as
   //  well, although in reality we should return the offset added to that

[PATCH] D110625: [analyzer] canonicalize special case of structure/pointer deref

2021-09-29 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers marked 3 inline comments as done.
vabridgers added a comment.

Thanks @steakhal and @martong for the comments! The patch has been updated.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110625/new/

https://reviews.llvm.org/D110625

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


[PATCH] D109740: [OpenCL] Add atomic_half type builtins

2021-09-29 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh added a comment.

Looks good at a first quick glance, but please fix the formatting errors that 
are reported on the lines that you are adding.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109740/new/

https://reviews.llvm.org/D109740

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


[PATCH] D109174: [MSP430][Clang] Infer CPU type from -mcpu= or -mmcu=

2021-09-29 Thread Jozef Lawrynowicz via Phabricator via cfe-commits
jozefl updated this revision to Diff 375811.
jozefl added a comment.

Rebase after updates to parent revision D108301 
.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109174/new/

https://reviews.llvm.org/D109174

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Basic/Targets/MSP430.cpp
  clang/lib/Basic/Targets/MSP430.h
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/MSP430.cpp
  clang/lib/Driver/ToolChains/MSP430.h
  clang/test/Driver/msp430-cpu.c
  clang/test/Driver/msp430-mmcu.c
  clang/test/Driver/msp430-toolchain.c
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/msp430-defs.c
  llvm/lib/Target/MSP430/MSP430.td
  llvm/lib/Target/MSP430/MSP430Subtarget.cpp
  llvm/lib/Target/MSP430/MSP430Subtarget.h
  llvm/test/CodeGen/MSP430/build-attrs.ll

Index: llvm/test/CodeGen/MSP430/build-attrs.ll
===
--- llvm/test/CodeGen/MSP430/build-attrs.ll
+++ llvm/test/CodeGen/MSP430/build-attrs.ll
@@ -8,6 +8,8 @@
 ; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430,SMALL
 ; RUN: llc -mtriple=msp430 -mcpu=msp430x -filetype=obj < %s \
 ; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430X,SMALL
+; RUN: llc -mtriple=msp430 -mcpu=msp430xv2 -filetype=obj < %s \
+; RUN:   | llvm-readelf -A - | FileCheck %s --check-prefixes COMMON,MSP430X,SMALL
 
 ; COMMON: BuildAttributes {
 ; COMMON: FormatVersion: 0x41
Index: llvm/lib/Target/MSP430/MSP430Subtarget.h
===
--- llvm/lib/Target/MSP430/MSP430Subtarget.h
+++ llvm/lib/Target/MSP430/MSP430Subtarget.h
@@ -36,7 +36,7 @@
 
 private:
   virtual void anchor();
-  bool ExtendedInsts = false;
+  bool MSP430X = false;
   HWMultEnum HWMultMode = NoHWMult;
   MSP430FrameLowering FrameLowering;
   MSP430InstrInfo InstrInfo;
@@ -60,6 +60,8 @@
   bool hasHWMult32() const { return HWMultMode == HWMult32; }
   bool hasHWMultF5() const { return HWMultMode == HWMultF5; }
 
+  bool hasMSP430X() const { return MSP430X; }
+
   const TargetFrameLowering *getFrameLowering() const override {
 return &FrameLowering;
   }
Index: llvm/lib/Target/MSP430/MSP430Subtarget.cpp
===
--- llvm/lib/Target/MSP430/MSP430Subtarget.cpp
+++ llvm/lib/Target/MSP430/MSP430Subtarget.cpp
@@ -40,9 +40,6 @@
 
 MSP430Subtarget &
 MSP430Subtarget::initializeSubtargetDependencies(StringRef CPU, StringRef FS) {
-  ExtendedInsts = false;
-  HWMultMode = NoHWMult;
-
   StringRef CPUName = CPU;
   if (CPUName.empty())
 CPUName = "msp430";
Index: llvm/lib/Target/MSP430/MSP430.td
===
--- llvm/lib/Target/MSP430/MSP430.td
+++ llvm/lib/Target/MSP430/MSP430.td
@@ -18,8 +18,8 @@
 // Subtarget Features. 
 //===--===//
 def FeatureX
- : SubtargetFeature<"ext", "ExtendedInsts", "true",
-"Enable MSP430-X extensions">;
+ : SubtargetFeature<"msp430x", "MSP430X", "true",
+"Enable MSP430X extensions">;
 
 def FeatureHWMult16
  : SubtargetFeature<"hwmult16", "HWMultMode", "HWMult16",
@@ -42,6 +42,7 @@
 def : Proc<"generic", []>;
 def : Proc<"msp430",  []>;
 def : Proc<"msp430x", [FeatureX]>;
+def : Proc<"msp430xv2",   [FeatureX]>;
 
 //===--===//
 // Register File Description
Index: clang/test/Preprocessor/msp430-defs.c
===
--- /dev/null
+++ clang/test/Preprocessor/msp430-defs.c
@@ -0,0 +1,20 @@
+// Check the correct macros are defined for each CPU.
+
+// RUN: %clang -target msp430 -x c -E -dM %s -o - | FileCheck  %s
+// RUN: %clang -target msp430 -mcpu=generic -x c -E -dM %s -o - | FileCheck %s
+// RUN: %clang -target msp430 -mcpu=msp430 -x c -E -dM %s -o - | FileCheck %s
+
+// CHECK: MSP430
+// CHECK: __ELF__
+// CHECK-NOT: __MSP430X__
+// CHECK: __MSP430__
+
+// RUN: %clang -target msp430 -mcpu=msp430x -x c -E -dM %s -o - \
+// RUN:   | FileCheck --check-prefix=MSP430X %s
+// RUN: %clang -target msp430 -mcpu=msp430xv2 -x c -E -dM %s -o - \
+// RUN:   | FileCheck --check-prefix=MSP430X %s
+
+// MSP430X: MSP430
+// MSP430X: __ELF__
+// MSP430X: __MSP430X__
+// MSP430X: __MSP430__
Index: clang/test/Misc/target-invalid-cpu-note.c
===
--- clang/test/Misc/target-invalid-cpu-note.c
+++ clang/test/Misc/target-invalid-cpu-note.c
@@ -209,3 +209,7 @@
 // RUN: not %clang_cc1 -triple riscv64 -tune-cpu not-a-cpu -fsyntax-only %s 2>&1 | FileCheck %s --check-prefix TUNE-RISCV64
 // TUNE-RISCV64: error: unknown target CPU 'not-a-cpu'
 // TUNE-RISCV64:

[PATCH] D110258: [AArch64] Always add -tune-cpu argument to -cc1 driver

2021-09-29 Thread Dave Green via Phabricator via cfe-commits
dmgreen added a comment.

In D110258#3024418 , @david-arm wrote:

> Hi @dmgreen, would you be happy for me to do the splitting-out of arch and 
> tuning features in a separate follow-on patch? I think it's a good idea and I 
> don't object to doing it, but I'm not sure that it really needs to hold up 
> this initial patch? I personally think it makes sense to live in a separate 
> patch because it seems riskier in terms of possible effects on performance. 
> As far as I understand it, this isn't a functional requirement, but more for 
> completeness.

I think that the `ARMProcFamily` subtarget features are really tuning features, 
which would mean that the AArch64Subtarget::initializeProperties would end up 
being based on tuning features and the code in D110259 
 would simplify as a result, not needing to 
pass TuneCPU around and check for specific cpus. We could change how that works 
code later, but I am a little worried about it being half finished, having 
tune-cpu not really working as it should but being required for some features. 
I would be fine as a separate patch so long as we are pretty confident that 
-mtune was going to work correctly before we start using it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110258/new/

https://reviews.llvm.org/D110258

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


[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

2021-09-29 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106102/new/

https://reviews.llvm.org/D106102

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


[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

2021-09-29 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

In D106102#3028584 , @manas wrote:

> The pre-merge checks fail due to the patch being unable to get applied. The 
> troubleshooting 
> 
>  suggest to update the patch via `arc diff ```git merge-base HEAD origin``` 
> --update D106102` and it would include all local changes into that patch. 
> Shouldn't I avoid including all local changes, as some local changes are 
> still WIP?

I guess `HEAD` should refer to the commit that represents this patch, in this 
case that is `ce82443c69be`. And I believe you local changes that are not 
committed should not affect `arc diff` at all. But, as a precaution, you could 
first stash your local changes before calling `arc`. Hope this helps.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106102/new/

https://reviews.llvm.org/D106102

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


[PATCH] D107450: [clang-tidy] Fix wrong FIxIt in performance-move-const-arg

2021-09-29 Thread Whisperity via Phabricator via cfe-commits
whisperity added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp:254
+  showInt(std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: std::move of the variable 'a' 
of the trivially-copyable type 'int' has no effect; consider changing showInt's 
parameter from 'int &&' to 'const int &'
+}

From `int &`? Isn't the parameter `int &&` there?



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp:267-270
+void showTmp(Tmp &&) {}
+void testTmp() {
+  Tmp t;
+  showTmp(std::move(t));

Sockke wrote:
> whisperity wrote:
> > Is there a test case covering if there are separate invocations of the 
> > function? Just to make sure that the //consider changing the parameter// 
> > suggestion won't become an annoyance either, and result in conflicts with 
> > other parts of the code.
> The warning will only be given when calling this function and passing in the 
> parameters wrapped with std::move. Is my understanding correct?
> 
Yes, that is what I mean. But I would like to see a test case where the "target 
function" is called **multiple times** with different arguments. One call with 
`std::move(x)`, one with a direct temporary, etc. So we can make sure that if a 
function is called more than 1 time, we can still be sure there won't be bad 
warnings or bad fixits that contradict each other.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/performance-move-const-arg.cpp:261
+  showInt(std::move(a));
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: std::move of the variable 'a' 
of the trivially-copyable type 'int' has no effect; consider changing showInt's 
parameter from 'int'&& to 'int'&
+  return std::move(a);

Sockke wrote:
> whisperity wrote:
> > MTC wrote:
> > > Change **'int'&&**  -> **'int&&'** and **'int&'** -> **int**. 
> > > 
> > > Make `consider changing showInt's parameter from 'int'&& to 'int'&` as a 
> > > note instead of a warning. And I don't have a strong preference for the 
> > > position of the note, but I personally want to put it in the source 
> > > location of the function definition. and 
> > >>! In D107450#2936824, @MTC wrote:
> > > but I personally want to put it in the source location of the function 
> > > definition
> > 
> > (I think you submitted the comment too early, @MTC, as there's an 
> > unterminated sentence there.)
> > 
> > But I agree with this. It should be put there when we're talking about the 
> > function's signature. The reason being the developer reading the warning 
> > could dismiss a potential false positive earlier if they can also 
> > immediately read (at least a part of...) the function's signature.
> > 
> > @Sockke you can do this by doing **another** `diag()` call with the `Note` 
> > value given as the 3rd parameter. And you can specify the SourceLocation of 
> > the affected parameter for this note.
> > >>! In D107450#2936824, @MTC wrote:
> > > but I personally want to put it in the source location of the function 
> > > definition
> > 
> > (I think you submitted the comment too early, @MTC, as there's an 
> > unterminated sentence there.)
> > 
> > But I agree with this. It should be put there when we're talking about the 
> > function's signature. The reason being the developer reading the warning 
> > could dismiss a potential false positive earlier if they can also 
> > immediately read (at least a part of...) the function's signature.
> > 
> > @Sockke you can do this by doing **another** `diag()` call with the `Note` 
> > value given as the 3rd parameter. And you can specify the SourceLocation of 
> > the affected parameter for this note.
> 
> Yes, it is reasonable to add a note, but would you mind adding this 
> modification to the patch that fixes AutoFix? If you don't mind, I will 
> update it.
I think it is okay if the additional note for this is added in this patch, 
there is no need for a separate patch on that. It helps understand WHY the 
FixIt is wrong or not wrong, anyway.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107450/new/

https://reviews.llvm.org/D107450

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


[PATCH] D106102: [analyzer][solver] Introduce reasoning for not equal to operator

2021-09-29 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

This patch seems pretty straightforward, good job @manas, and for the folks 
giving review comments.
Aside from polishing the tests, I think it's good to go.




Comment at: clang/test/Analysis/constant-folding.c:470
+
+void testEqualityRules(unsigned int a, unsigned int b, int c, int d) {
+  // Checks when ranges are not overlapping





Comment at: clang/test/Analysis/constant-folding.c:470
+
+void testEqualityRules(unsigned int a, unsigned int b, int c, int d) {
+  // Checks when ranges are not overlapping

steakhal wrote:
> 
I would prefer `u1`, `u2`, `s1`, `s2` respectively.
This way the name would signify the signess of the variable.



Comment at: clang/test/Analysis/constant-folding.c:473
+  if (a <= 10 && b >= 20) {
+clang_analyzer_eval((a != b) != 0); // expected-warning{{TRUE}}
+  }

Isn't  `a != b` enough? Why do you need the `(..) != 0` part?



Comment at: clang/test/Analysis/constant-folding.c:476-478
+  if (c <= INT_MIN + 10 && d >= INT_MAX - 10) {
+clang_analyzer_eval((c != d) == 0); // expected-warning{{FALSE}}
+  }

How is this different compared to the previous case? The difference I can see 
is that now we use different constants and the `==` operator in the outer 
expression. None of which should really change the behavior AFAICT.



Comment at: clang/test/Analysis/constant-folding.c:481
+  // Checks when ranges are completely overlapping and have more than one point
+  if (a >= 20 && a <= 50 && b >= 20 && b <= 50) {
+clang_analyzer_eval((a != b) != 0); // expected-warning{{UNKNOWN}}

You could have a comment that `a: [20,50]  b:[20,50]`.
It would be easier to comprehend than the chain of conjunctions.
Similarly, how at L464 does.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106102/new/

https://reviews.llvm.org/D106102

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-29 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 updated this revision to Diff 375655.
gandhi21299 added a comment.

- declare failure when lowering an accessor of a callee which is not a 
function, in GlobalISel


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109707/new/

https://reviews.llvm.org/D109707

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
  llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
  llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
  llvm/lib/Target/AMDGPU/SIISelLowering.cpp
  llvm/test/CodeGen/AMDGPU/inline-calls.ll

Index: llvm/test/CodeGen/AMDGPU/inline-calls.ll
===
--- llvm/test/CodeGen/AMDGPU/inline-calls.ll
+++ llvm/test/CodeGen/AMDGPU/inline-calls.ll
@@ -1,6 +1,4 @@
 ; RUN: llc -march=amdgcn -mcpu=tahiti -verify-machineinstrs < %s | FileCheck  %s
-; RUN: llc -march=amdgcn -mcpu=tonga -verify-machineinstrs < %s | FileCheck  %s
-; RUN: llc -march=r600 -mcpu=redwood -verify-machineinstrs < %s | FileCheck %s
 
 ; ALL-NOT: {{^}}func:
 define internal i32 @func(i32 %a) {
@@ -18,8 +16,8 @@
   ret void
 }
 
-; CHECK-NOT: func_alias
-; ALL-NOT: func_alias
+; CHECK: func_alias
+; ALL: func_alias
 @func_alias = alias i32 (i32), i32 (i32)* @func
 
 ; ALL: {{^}}kernel3:
Index: llvm/lib/Target/AMDGPU/SIISelLowering.cpp
===
--- llvm/lib/Target/AMDGPU/SIISelLowering.cpp
+++ llvm/lib/Target/AMDGPU/SIISelLowering.cpp
@@ -3007,6 +3007,13 @@
   bool IsSibCall = false;
   bool IsThisReturn = false;
   MachineFunction &MF = DAG.getMachineFunction();
+  GlobalAddressSDNode *GSD = dyn_cast(Callee);
+
+  if (GSD) {
+const GlobalValue *GV = GSD->getGlobal();
+if (!isa(GV))
+  return lowerUnhandledCall(CLI, InVals, "callee is not a function ");
+  }
 
   if (Callee.isUndef() || isNullConstant(Callee)) {
 if (!CLI.IsTailCall) {
@@ -3264,7 +3271,7 @@
   Ops.push_back(Callee);
   // Add a redundant copy of the callee global which will not be legalized, as
   // we need direct access to the callee later.
-  if (GlobalAddressSDNode *GSD = dyn_cast(Callee)) {
+  if (GSD) {
 const GlobalValue *GV = GSD->getGlobal();
 Ops.push_back(DAG.getTargetGlobalAddress(GV, DL, MVT::i64));
   } else {
Index: llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
@@ -913,14 +913,19 @@
   if (Info.Callee.isReg()) {
 CallInst.addReg(Info.Callee.getReg());
 CallInst.addImm(0);
-  } else if (Info.Callee.isGlobal() && Info.Callee.getOffset() == 0) {
-// The call lowering lightly assumed we can directly encode a call target in
-// the instruction, which is not the case. Materialize the address here.
+  } else if (Info.Callee.isGlobal()) {
 const GlobalValue *GV = Info.Callee.getGlobal();
-auto Ptr = MIRBuilder.buildGlobalValue(
-  LLT::pointer(GV->getAddressSpace(), 64), GV);
-CallInst.addReg(Ptr.getReg(0));
-CallInst.add(Info.Callee);
+if (!isa(GV))
+  return false;
+if (Info.Callee.getOffset() == 0) {
+  // The call lowering lightly assumed we can directly encode a call target
+  // in the instruction, which is not the case. Materialize the address
+  // here.
+  auto Ptr = MIRBuilder.buildGlobalValue(
+  LLT::pointer(GV->getAddressSpace(), 64), GV);
+  CallInst.addReg(Ptr.getReg(0));
+  CallInst.add(Info.Callee);
+}
   } else
 return false;
 
Index: llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
===
--- llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
+++ llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp
@@ -93,6 +93,8 @@
 
   for (GlobalAlias &A : M.aliases()) {
 if (Function* F = dyn_cast(A.getAliasee())) {
+  if (A.getLinkage() != GlobalValue::InternalLinkage)
+continue;
   A.replaceAllUsesWith(F);
   AliasesToRemove.push_back(&A);
 }
Index: clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
@@ -0,0 +1,17 @@
+// REQUIRES: amdgpu-registered-target, clang-driver
+
+// RUN: %clang --offload-arch=gfx906 --cuda-device-only -x hip -emit-llvm -S -o - %s \
+// RUN:   -fgpu-rdc -O3 -mllvm -amdgpu-early-inline-all=true -mllvm -amdgpu-function-calls=false | \
+// RUN:   FileCheck %s
+
+#include "Inputs/cuda.h"
+
+// CHECK: %struct.B = type { i8 }
+struct B {
+
+  // CHECK: @_ZN1BC1Ei = hidden unnamed_addr alias void (%struct.B*, i32), void (%struct.B*, i32)* @_ZN1BC2Ei
+  __device__ B(int x);
+};
+
+__device__ B::B(int x) {
+}
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib

[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp:96-97
 if (Function* F = dyn_cast(A.getAliasee())) {
+  if (A.getLinkage() != GlobalValue::InternalLinkage)
+continue;
   A.replaceAllUsesWith(F);

If we do this for older GPU's (e.g. Tonga/redwood), IR's using aliases will 
fail on them. I don't think it is acceptable.

Is it possible to restrict this change to gfx9 and above? Or should we 
introduce some feature to indicate 'alias support' and use that to restrict 
this change to subtargets supporting this feature.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109707/new/

https://reviews.llvm.org/D109707

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: llvm/test/CodeGen/AMDGPU/inline-calls.ll:1
 ; RUN: llc -march=amdgcn -mcpu=tahiti -verify-machineinstrs < %s | FileCheck  
%s
 

need to add check for gfx906 and gfx1030


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109707/new/

https://reviews.llvm.org/D109707

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


[PATCH] D109707: [HIP] [AlwaysInliner] Disable AlwaysInliner to eliminate undefined symbols

2021-09-29 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added inline comments.



Comment at: llvm/lib/Target/AMDGPU/AMDGPUAlwaysInlinePass.cpp:96-97
 if (Function* F = dyn_cast(A.getAliasee())) {
+  if (A.getLinkage() != GlobalValue::InternalLinkage)
+continue;
   A.replaceAllUsesWith(F);

yaxunl wrote:
> If we do this for older GPU's (e.g. Tonga/redwood), IR's using aliases will 
> fail on them. I don't think it is acceptable.
> 
> Is it possible to restrict this change to gfx9 and above? Or should we 
> introduce some feature to indicate 'alias support' and use that to restrict 
> this change to subtargets supporting this feature.
Restricting this change to gfx9 and above sounds simpler and more relevant with 
the problem as well.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109707/new/

https://reviews.llvm.org/D109707

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


[clang] c9539f9 - [PowerPC] Define XL-compatible macros only for AIX and Linux

2021-09-29 Thread Nemanja Ivanovic via cfe-commits

Author: Nemanja Ivanovic
Date: 2021-09-29T06:14:45-05:00
New Revision: c9539f957f57c0c2c59dab98f25215f241d4debf

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

LOG: [PowerPC] Define XL-compatible macros only for AIX and Linux

Since XLC only ever shipped on PowerPC AIX and Linux, it is not reasonable to
provide the compatibility macros on any target other than those two. This patch
restricts those macros to AIX/Linux.

Differential revision: https://reviews.llvm.org/D110213

Added: 


Modified: 
clang/lib/Basic/Targets/PPC.cpp
clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
clang/test/CodeGen/builtins-ppc-xlcompat-cipher.c
clang/test/CodeGen/builtins-ppc-xlcompat-cmplx.c
clang/test/CodeGen/builtins-ppc-xlcompat-compare.c
clang/test/CodeGen/builtins-ppc-xlcompat-conversionfunc.c
clang/test/CodeGen/builtins-ppc-xlcompat-darn.c
clang/test/CodeGen/builtins-ppc-xlcompat-error.c
clang/test/CodeGen/builtins-ppc-xlcompat-expect.c
clang/test/CodeGen/builtins-ppc-xlcompat-fetch.c
clang/test/CodeGen/builtins-ppc-xlcompat-fp.c
clang/test/CodeGen/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
clang/test/CodeGen/builtins-ppc-xlcompat-load-store-reversed.c
clang/test/CodeGen/builtins-ppc-xlcompat-macros.c
clang/test/CodeGen/builtins-ppc-xlcompat-math.c
clang/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.c
clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
clang/test/CodeGen/builtins-ppc-xlcompat-prefetch.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-warning.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
clang/test/CodeGen/builtins-ppc-xlcompat-stfiw.c
clang/test/CodeGen/builtins-ppc-xlcompat-swdiv_nochk.c
clang/test/CodeGen/builtins-ppc-xlcompat-sync.c
clang/test/CodeGen/builtins-ppc-xlcompat-test.c
clang/test/CodeGen/builtins-ppc-xlcompat-trap-64bit-only.c
clang/test/CodeGen/builtins-ppc-xlcompat-trap.c
clang/test/CodeGen/builtins-ppc-xlcompat-vec-error.c
clang/test/CodeGen/builtins-ppc-xlcompat.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 8ada8c5106b31..4835f1d816741 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -250,7 +250,10 @@ static void defineXLCompatMacros(MacroBuilder &Builder) {
 void PPCTargetInfo::getTargetDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
 
-  defineXLCompatMacros(Builder);
+  // We define the XLC compatibility macros only on AIX and Linux since XLC
+  // was never available on any other platforms.
+  if (getTriple().isOSAIX() || getTriple().isOSLinux())
+defineXLCompatMacros(Builder);
 
   // Target identification.
   Builder.defineMacro("__ppc__");

diff  --git 
a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
index f305166f2b088..81bf4d54db025 100644
--- a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
@@ -3,9 +3,9 @@
 // RUN: FileCheck %s --check-prefix=CHECK32-ERROR
 // RUN: %clang_cc1 -O2 -triple=powerpc64-unknown-aix -emit-llvm %s -o - | \
 // RUN: FileCheck %s --check-prefix=CHECK64
-// RUN: %clang_cc1 -O2 -triple=powerpc64le-unknown-unknown -emit-llvm %s \
+// RUN: %clang_cc1 -O2 -triple=powerpc64le-unknown-linux-gnu -emit-llvm %s \
 // RUN:  -o - | FileCheck %s --check-prefix=CHECK64
-// RUN: %clang_cc1 -O2 -triple=powerpc64-unknown-unknown -emit-llvm %s \
+// RUN: %clang_cc1 -O2 -triple=powerpc64-unknown-linux-gnu -emit-llvm %s \
 // RUN:  -o - | FileCheck %s --check-prefix=CHECK64
 
 long test_ldarx(volatile long* a) {

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
index 22c668f73f3d9..7c898f523dc85 100644
--- a/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
@@ -3,9 +3,9 @@
 // RUN:  -emit-llvm %s -o - | FileCheck %s
 // RUN: %clang_cc1 -O2 -target-cpu pwr8 -triple=powerpc64-unknown-aix \
 // RUN:  -e

[PATCH] D110213: [PowerPC] Define XL-compatible macros only for AIX and Linux

2021-09-29 Thread Nemanja Ivanovic via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc9539f957f57: [PowerPC] Define XL-compatible macros only for 
AIX and Linux (authored by nemanjai).

Changed prior to commit:
  https://reviews.llvm.org/D110213?vs=374084&id=375829#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110213/new/

https://reviews.llvm.org/D110213

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cipher.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cmplx.c
  clang/test/CodeGen/builtins-ppc-xlcompat-compare.c
  clang/test/CodeGen/builtins-ppc-xlcompat-conversionfunc.c
  clang/test/CodeGen/builtins-ppc-xlcompat-darn.c
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-expect.c
  clang/test/CodeGen/builtins-ppc-xlcompat-fetch.c
  clang/test/CodeGen/builtins-ppc-xlcompat-fp.c
  clang/test/CodeGen/builtins-ppc-xlcompat-load-store-reversed-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-load-store-reversed.c
  clang/test/CodeGen/builtins-ppc-xlcompat-macros.c
  clang/test/CodeGen/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.c
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
  clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
  clang/test/CodeGen/builtins-ppc-xlcompat-prefetch.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-warning.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
  clang/test/CodeGen/builtins-ppc-xlcompat-stfiw.c
  clang/test/CodeGen/builtins-ppc-xlcompat-swdiv_nochk.c
  clang/test/CodeGen/builtins-ppc-xlcompat-sync.c
  clang/test/CodeGen/builtins-ppc-xlcompat-test.c
  clang/test/CodeGen/builtins-ppc-xlcompat-trap-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-trap.c
  clang/test/CodeGen/builtins-ppc-xlcompat-vec-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat.c
@@ -1,9 +1,9 @@
 // REQUIRES: powerpc-registered-target
 // RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
-// RUN:   -triple powerpc64-unknown-unknown -emit-llvm %s -o - \
+// RUN:   -triple powerpc64-unknown-linux-gnu -emit-llvm %s -o - \
 // RUN:   -D__XL_COMPAT_ALTIVEC__ -target-cpu pwr7 | FileCheck %s
 // RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
-// RUN:   -triple powerpc64le-unknown-unknown -emit-llvm %s -o - \
+// RUN:   -triple powerpc64le-unknown-linux-gnu -emit-llvm %s -o - \
 // RUN:   -D__XL_COMPAT_ALTIVEC__ -target-cpu pwr8 | FileCheck %s
 #include 
 vector double vd = { 3.4e22, 1.8e-3 };
Index: clang/test/CodeGen/builtins-ppc-xlcompat-vec-error.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-vec-error.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-vec-error.c
@@ -1,7 +1,7 @@
 // REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -fsyntax-only \
 // RUN:   -target-cpu pwr8 -Wall -Werror -verify %s
-// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -target-cpu pwr8 -Wall -Werror -verify %s
 // RUN: %clang_cc1 -triple powerpc64-unknown-aix -fsyntax-only \
 // RUN:   -target-cpu pwr8 -Wall -Werror -verify %s
Index: clang/test/CodeGen/builtins-ppc-xlcompat-trap.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-trap.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-trap.c
@@ -1,8 +1,8 @@
 // REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-unknown \
+// RUN: %clang_cc1 -O2 -triple powerpc64-unknown-linux-gnu \
 // RUN:   -emit-llvm %s -o - -target-cpu pwr7 | \
 // RUN:  FileCheck %s
-// RUN: %clang_cc1 -O2 -triple powerpc64le-unknown-unknown \
+// RUN: %clang_cc1 -O2 -triple powerpc64le-unknown-linux-gnu \
 // RUN:   -emit-llvm %s -o - -target-cpu pwr8 | \
 // RUN:  FileCheck %s
 // RUN: %clang_cc1 -O2 -triple powerpc-unknown-aix \
Index: clang/test/CodeGen/builtins-ppc-xlcompat-trap-64bit-only.c
===
--- clang/te

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

2021-09-29 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal added a comment.

Apologies for late reply. Most of the tests now do not try to call malloc, so 
no page fault errors. But all of them are producing wrong results. For e.g. 
declare_mapper_target.cpp produces Sum = 132608 with the patch applied. 
Similarly for other tests as well. So don't know what's happening yet.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102107/new/

https://reviews.llvm.org/D102107

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


[PATCH] D110485: Support [[no_unique_address]] for all targets.

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.
This revision now requires changes to proceed.

In D110485#3026629 , @rjmccall wrote:

> MSVC gets to chose the ABI rules for their platform.  It is not Clang policy 
> to pick ABI rules and then break them later.
>
> If you'd like to contribute an implementation of 
> `[[msvc::no_unique_address]]` that matches MSVC's ABI,  that would be 
> welcome.  I don't know, maybe that's as simple as making it use the existing 
> implementation; @zygoloid might know better.  But "add an ABI feature ahead 
> of the platform owner and then fix the ABI problems later" is not how we do 
> things.

I concur with John.

In D110485#3028553 , @expnkx wrote:

> I cannot find out where to add attribute that starts with msvc::x.

To Attr.td; you'd give a new spelling, like: `CXX11<"msvc", 
"no_unique_address">`

> I am just applying this "potential" patch to the clang upstream. In the 
> future we can just remove TargetItaniumCXXABI attr in the clang table gen 
> file without worrying about too much. So it is a "noop".
>
> So this patch changes nothing but it makes us be convenient to fix it in the 
> future.

This patch is changing behavior and cannot be landed as-is. I don't think we 
should do anything in this area unless it's an implementation of 
`[[msvc::no_unique_address]]` that is ABI compatible with the Microsoft 
implementation.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110485/new/

https://reviews.llvm.org/D110485

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


[clang] 09b67aa - [PowerPC] Implement builtin for vbpermd

2021-09-29 Thread Nemanja Ivanovic via cfe-commits

Author: Nemanja Ivanovic
Date: 2021-09-29T06:34:31-05:00
New Revision: 09b67aa1c38279daa54246e3f216186e35a3e5b9

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

LOG: [PowerPC] Implement builtin for vbpermd

The instruction has similar semantics to vbpermq but for doublewords.
It was added in Power9 and the ABI documents the builtin.

Differential revision: https://reviews.llvm.org/D107899

Added: 
llvm/test/CodeGen/PowerPC/p9-vbpermd.ll

Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-p8vector.c
clang/test/CodeGen/builtins-ppc-p9vector.c
llvm/include/llvm/IR/IntrinsicsPowerPC.td
llvm/lib/Target/PowerPC/PPCInstrAltivec.td

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 76c953272b4db..6fee978530dd6 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -397,6 +397,7 @@ BUILTIN(__builtin_altivec_vcmpgtfp_p, "iiV4fV4f", "")
 
 BUILTIN(__builtin_altivec_vgbbd, "V16UcV16Uc", "")
 BUILTIN(__builtin_altivec_vbpermq, "V2ULLiV16UcV16Uc", "")
+BUILTIN(__builtin_altivec_vbpermd, "V2ULLiV2ULLiV16Uc", "")
 
 // P8 Crypto built-ins.
 BUILTIN(__builtin_altivec_crypto_vsbox, "V2ULLiV2ULLi", "")

diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 6cfe9815228fa..0ccd63af8791a 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -17369,12 +17369,22 @@ vec_vbpermq(vector unsigned char __a, vector unsigned 
char __b) {
 }
 
 #if defined(__powerpc64__) && defined(__SIZEOF_INT128__)
-static __inline__ vector unsigned long long __attribute__((__always_inline__))
+static __inline__ vector unsigned long long __ATTRS_o_ai
 vec_bperm(vector unsigned __int128 __a, vector unsigned char __b) {
   return __builtin_altivec_vbpermq((vector unsigned char)__a,
(vector unsigned char)__b);
 }
 #endif
+static __inline__ vector unsigned char __ATTRS_o_ai
+vec_bperm(vector unsigned char __a, vector unsigned char __b) {
+  return __builtin_altivec_vbpermq(__a, __b);
+}
+#endif // __POWER8_VECTOR__
+#ifdef __POWER9_VECTOR__
+static __inline__ vector unsigned long long __ATTRS_o_ai
+vec_bperm(vector unsigned long long __a, vector unsigned char __b) {
+  return __builtin_altivec_vbpermd(__a, __b);
+}
 #endif
 
 

diff  --git a/clang/test/CodeGen/builtins-ppc-p8vector.c 
b/clang/test/CodeGen/builtins-ppc-p8vector.c
index 68a2c95e870eb..16a306cc82ed2 100644
--- a/clang/test/CodeGen/builtins-ppc-p8vector.c
+++ b/clang/test/CodeGen/builtins-ppc-p8vector.c
@@ -1177,10 +1177,13 @@ void test1() {
 // CHECK: llvm.ppc.altivec.vgbbd
 // CHECK-LE: llvm.ppc.altivec.vgbbd
 
-  res_vull = vec_bperm(vux, vux);
-// CHECK: llvm.ppc.altivec.vbpermq
-// CHECK-LE: llvm.ppc.altivec.vbpermq
-// CHECK-PPC: warning: implicit declaration of function 'vec_bperm'
+  res_vull = vec_bperm(vux, vuc);
+  // CHECK: llvm.ppc.altivec.vbpermq
+  // CHECK-LE: llvm.ppc.altivec.vbpermq
+
+  res_vull = vec_bperm(vuc, vuc);
+  // CHECK: llvm.ppc.altivec.vbpermq
+  // CHECK-LE: llvm.ppc.altivec.vbpermq
 
   res_vsll = vec_neg(vsll);
 // CHECK: sub <2 x i64> zeroinitializer, {{%[0-9]+}}

diff  --git a/clang/test/CodeGen/builtins-ppc-p9vector.c 
b/clang/test/CodeGen/builtins-ppc-p9vector.c
index 1766f2507308b..d984deb58d3e1 100644
--- a/clang/test/CodeGen/builtins-ppc-p9vector.c
+++ b/clang/test/CodeGen/builtins-ppc-p9vector.c
@@ -1260,3 +1260,9 @@ vector signed long long test_vec_signextll_sll_si(void) {
 // CHECK-NEXT: ret <2 x i64>
 return vec_signextll(vsia);
 }
+
+vector unsigned long long test_vbpermd(void) {
+  // CHECK: @llvm.ppc.altivec.vbpermd(<2 x i64>
+  // CHECK-BE: @llvm.ppc.altivec.vbpermd(<2 x i64>
+  return vec_bperm(vula, vuca);
+}

diff  --git a/llvm/include/llvm/IR/IntrinsicsPowerPC.td 
b/llvm/include/llvm/IR/IntrinsicsPowerPC.td
index be2a795f26d21..d4f1e5e985b22 100644
--- a/llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ b/llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1042,6 +1042,9 @@ let TargetPrefix = "ppc" in {  // All PPC intrinsics 
start with "llvm.ppc.".
   def int_ppc_altivec_vbpermq : GCCBuiltin<"__builtin_altivec_vbpermq">,
   Intrinsic<[llvm_v2i64_ty], [llvm_v16i8_ty, llvm_v16i8_ty],
 [IntrNoMem]>;
+  def int_ppc_altivec_vbpermd : GCCBuiltin<"__builtin_altivec_vbpermd">,
+  Intrinsic<[llvm_v2i64_ty], [llvm_v2i64_ty, llvm_v16i8_ty],
+[IntrNoMem]>;
 }
 
 def int_ppc_altivec_vexptefp  : PowerPC_Vec_FF_Intrinsic<"vexptefp">;

diff  --git a/llvm/lib/Target/PowerPC/PPCInstrAltivec.td 
b/llvm/lib/Target/PowerPC/PPCInstrAltivec.td
index 2bc7fb2a1a5fa..1e0e2d88e54be 100

[PATCH] D107899: [PowerPC] Implement builtin for vbpermd

2021-09-29 Thread Nemanja Ivanovic via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG09b67aa1c382: [PowerPC] Implement builtin for vbpermd 
(authored by nemanjai).

Changed prior to commit:
  https://reviews.llvm.org/D107899?vs=365731&id=375832#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107899/new/

https://reviews.llvm.org/D107899

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p8vector.c
  clang/test/CodeGen/builtins-ppc-p9vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrAltivec.td
  llvm/test/CodeGen/PowerPC/p9-vbpermd.ll

Index: llvm/test/CodeGen/PowerPC/p9-vbpermd.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/p9-vbpermd.ll
@@ -0,0 +1,32 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:  -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:  -mcpu=pwr9 < %s | FileCheck %s
+
+@vull = common global <2 x i64> zeroinitializer, align 16
+@vuc = common global <16 x i8> zeroinitializer, align 16
+@res_vull = common global <2 x i64> zeroinitializer, align 16
+
+define void @test1() {
+; CHECK-LABEL: test1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:addis 3, 2, .LC0@toc@ha
+; CHECK-NEXT:ld 3, .LC0@toc@l(3)
+; CHECK-NEXT:lxv 34, 0(3)
+; CHECK-NEXT:addis 3, 2, .LC1@toc@ha
+; CHECK-NEXT:ld 3, .LC1@toc@l(3)
+; CHECK-NEXT:lxv 35, 0(3)
+; CHECK-NEXT:addis 3, 2, .LC2@toc@ha
+; CHECK-NEXT:ld 3, .LC2@toc@l(3)
+; CHECK-NEXT:vbpermd 2, 2, 3
+; CHECK-NEXT:stxv 34, 0(3)
+; CHECK-NEXT:blr
+entry:
+  %0 = load <2 x i64>, <2 x i64>* @vull, align 16
+  %1 = load <16 x i8>, <16 x i8>* @vuc, align 16
+  %2 = call <2 x i64> @llvm.ppc.altivec.vbpermd(<2 x i64> %0, <16 x i8> %1)
+  store <2 x i64> %2, <2 x i64>* @res_vull, align 16
+  ret void
+}
+declare <2 x i64> @llvm.ppc.altivec.vbpermd(<2 x i64>, <16 x i8>)
Index: llvm/lib/Target/PowerPC/PPCInstrAltivec.td
===
--- llvm/lib/Target/PowerPC/PPCInstrAltivec.td
+++ llvm/lib/Target/PowerPC/PPCInstrAltivec.td
@@ -1518,8 +1518,8 @@
 (int_ppc_altivec_vprtybq v1i128:$vB))]>;
 
 // Vector (Bit) Permute (Right-indexed)
-def VBPERMD : VXForm_1<1484, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
-   "vbpermd $vD, $vA, $vB", IIC_VecFP, []>;
+def VBPERMD : VX1_Int_Ty3<1484, "vbpermd", int_ppc_altivec_vbpermd,
+  v2i64, v2i64, v16i8>;
 def VPERMR : VAForm_1a<59, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB, vrrc:$vC),
"vpermr $vD, $vA, $vB, $vC", IIC_VecFP, []>;
 
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1042,6 +1042,9 @@
   def int_ppc_altivec_vbpermq : GCCBuiltin<"__builtin_altivec_vbpermq">,
   Intrinsic<[llvm_v2i64_ty], [llvm_v16i8_ty, llvm_v16i8_ty],
 [IntrNoMem]>;
+  def int_ppc_altivec_vbpermd : GCCBuiltin<"__builtin_altivec_vbpermd">,
+  Intrinsic<[llvm_v2i64_ty], [llvm_v2i64_ty, llvm_v16i8_ty],
+[IntrNoMem]>;
 }
 
 def int_ppc_altivec_vexptefp  : PowerPC_Vec_FF_Intrinsic<"vexptefp">;
Index: clang/test/CodeGen/builtins-ppc-p9vector.c
===
--- clang/test/CodeGen/builtins-ppc-p9vector.c
+++ clang/test/CodeGen/builtins-ppc-p9vector.c
@@ -1260,3 +1260,9 @@
 // CHECK-NEXT: ret <2 x i64>
 return vec_signextll(vsia);
 }
+
+vector unsigned long long test_vbpermd(void) {
+  // CHECK: @llvm.ppc.altivec.vbpermd(<2 x i64>
+  // CHECK-BE: @llvm.ppc.altivec.vbpermd(<2 x i64>
+  return vec_bperm(vula, vuca);
+}
Index: clang/test/CodeGen/builtins-ppc-p8vector.c
===
--- clang/test/CodeGen/builtins-ppc-p8vector.c
+++ clang/test/CodeGen/builtins-ppc-p8vector.c
@@ -1177,10 +1177,13 @@
 // CHECK: llvm.ppc.altivec.vgbbd
 // CHECK-LE: llvm.ppc.altivec.vgbbd
 
-  res_vull = vec_bperm(vux, vux);
-// CHECK: llvm.ppc.altivec.vbpermq
-// CHECK-LE: llvm.ppc.altivec.vbpermq
-// CHECK-PPC: warning: implicit declaration of function 'vec_bperm'
+  res_vull = vec_bperm(vux, vuc);
+  // CHECK: llvm.ppc.altivec.vbpermq
+  // CHECK-LE: llvm.ppc.altivec.vbpermq
+
+  res_vull = vec_bperm(vuc, vuc);
+  // CHECK: llvm.ppc.altivec.vbpermq
+  // CHECK-LE: llvm.ppc.altivec.vbpermq
 
   res_vsll = vec_neg(vsll);
 // CHECK: sub <2 x i64> zeroinitializer, {{%[0-9]+}}
Index: clang/lib/Headers/altivec.h
===

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

We typically do not introduce new off-by-default warnings into Clang because 
experience has shown that users typically do not enable them (so they tend not 
to be worth the maintenance burden). Instead, we try to make warnings that can 
be on-by-default with a very low false positive rate. Have you run over a large 
corpus of C and C++ code to see what false positives arise? Do you have ideas 
on what it would take to make this on by default? The one big one I can think 
of is that it's not at all uncommon in C to only initialize one element of the 
array to zero and rely on zero initialization of the rest (because an empty 
initializer list is technically not valid C code; it's a GNU extension we 
support): 
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=%3D+%7B0%7D%3B&search=Search.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110656/new/

https://reviews.llvm.org/D110656

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


[clang-tools-extra] 722e705 - Revert 9b944c184396ce55a3ad608779cc326ba12c9ee3 with fixes

2021-09-29 Thread Aaron Ballman via cfe-commits

Author: Salman Javed
Date: 2021-09-29T08:00:45-04:00
New Revision: 722e705f72dd3077a1f51dc62717828e7ccf23e8

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

LOG: Revert 9b944c184396ce55a3ad608779cc326ba12c9ee3 with fixes

This reintroduces c0687e1984a82925918c874b7bb68ad34c32aed0 (Add support
for `NOLINTBEGIN` ... `NOLINTEND` comments) but with fixes to the tests.

Added: 

clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/error_in_include.inc

clang-tools-extra/test/clang-tidy/infrastructure/Inputs/nolintbeginend/nolint_in_include.inc

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-at-eof.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-global-end-specific.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-specific-end-global.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-begin-without-end.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-end-at-sof.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-end-without-begin.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-error-within-include.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-mismatched-check-names.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-mismatched-delims.cpp

clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend-typo-in-check-name.cpp
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp

Modified: 
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/index.rst
clang-tools-extra/test/clang-tidy/infrastructure/nolint.cpp
clang-tools-extra/test/clang-tidy/infrastructure/nolintnextline.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp 
b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
index 1457f145f552c..1aa093a2e8db2 100644
--- a/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -23,6 +23,7 @@
 #include "clang/AST/Attr.h"
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Basic/FileManager.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Frontend/DiagnosticRenderer.h"
 #include "clang/Lex/Lexer.h"
@@ -202,6 +203,17 @@ DiagnosticBuilder ClangTidyContext::diag(
   return DiagEngine->Report(ID);
 }
 
+DiagnosticBuilder ClangTidyContext::diag(const ClangTidyError &Error) {
+  SourceManager &SM = DiagEngine->getSourceManager();
+  llvm::ErrorOr File =
+  SM.getFileManager().getFile(Error.Message.FilePath);
+  FileID ID = SM.getOrCreateFileID(*File, SrcMgr::C_User);
+  SourceLocation FileStartLoc = SM.getLocForStartOfFile(ID);
+  SourceLocation Loc = FileStartLoc.getLocWithOffset(Error.Message.FileOffset);
+  return diag(Error.DiagnosticName, Loc, Error.Message.Message,
+  static_cast(Error.DiagLevel));
+}
+
 DiagnosticBuilder ClangTidyContext::configurationDiag(
 StringRef Message,
 DiagnosticIDs::Level Level /* = DiagnosticIDs::Warning*/) {
@@ -307,14 +319,26 @@ void ClangTidyDiagnosticConsumer::finalizeLastError() {
   LastErrorPassesLineFilter = false;
 }
 
-static bool IsNOLINTFound(StringRef NolintDirectiveText, StringRef Line,
-  unsigned DiagID, const ClangTidyContext &Context) {
-  const size_t NolintIndex = Line.find(NolintDirectiveText);
+static bool isNOLINTFound(StringRef NolintDirectiveText, StringRef CheckName,
+  StringRef Line, size_t *FoundNolintIndex = nullptr,
+  bool *SuppressionIsSpecific = nullptr) {
+  if (FoundNolintIndex)
+*FoundNolintIndex = StringRef::npos;
+  if (SuppressionIsSpecific)
+*SuppressionIsSpecific = false;
+
+  size_t NolintIndex = Line.find(NolintDirectiveText);
   if (NolintIndex == StringRef::npos)
 return false;
 
   size_t BracketIndex = NolintIndex + NolintDirectiveText.size();
-  // Check if the specific checks are specified in brackets.
+  if (BracketIndex < Line.size() && isalnum(Line[BracketIndex])) {
+// Reject this search result, otherwise it will cause false positives when
+// NOLINT is found as a substring of NOLINT(NEXTLINE/BEGIN/END).
+return false;
+  }
+
+  // Check if specific checks are specified in brackets.
   if (BracketIndex < Line.size() && Line[BracketIndex] == '(') {
 ++BracketIndex;
 const size_t BracketEndIndex = Line.find(')', BracketIndex);
@@ -323,16 +347,22 @@ static bool IsNOLINTFound(S

[PATCH] D108560: [clang-tidy] Add support for `NOLINTBEGIN` ... `NOLINTEND` comments

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thanks for the fix, those changes LGTM! I've recommit on your behalf in 
722e705f72dd3077a1f51dc62717828e7ccf23e8 



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108560/new/

https://reviews.llvm.org/D108560

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


[PATCH] D110276: Clean up large copies of binaries copied into temp directories in tests

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Softlinks don't work on Windows, that's why these tests use copies.

clang_f_opts.c sadly started flaking almost immediately after this went in: 
http://45.33.8.238/win/46115/step_7.txt

So I fear the Windows file system can't handle this patch as-is.

Maybe we can use `rm -f` and maybe that way the error isn't fatal even when 
deleting the file doesn't work, not sure.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110276/new/

https://reviews.llvm.org/D110276

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


[PATCH] D103938: Diagnose -Wunused-value based on CFG reachability

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103938/new/

https://reviews.llvm.org/D103938

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


[PATCH] D110485: Support [[no_unique_address]] for all targets.

2021-09-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1690
+def NoUniqueAddress : InheritableAttr {
   let Spellings = [CXX11<"", "no_unique_address", 201803>];
   let Subjects = SubjectList<[NonBitField], ErrorDiag>;

The way to do a `[[msvc::no_unique_address]]` is likely to create a new 
attribute here in Attr.td, then make the spelling be something like:

`let Spellings = [CXX11<"msvc", "no_unique_address", N>];`

Where `N` is a number that is the value of `__has_attribute` (which I note that 
MSVC has yet to implement?).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110485/new/

https://reviews.llvm.org/D110485

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


[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/lib/Basic/CLWarnings.cpp:17
+  switch (CLWarningID) {
+  case 4005: return "macro-redefined";
+  case 4018: return "sign-compare";

hans wrote:
> Would it be possible to reference the DiagGroup symbolically here somehow 
> instead of using a string? That way, if the DiagGroup gets renamed, we don't 
> risk forgetting to update this string.
As far as I can tell, diagnostic groups don't exist as enums. Options:

- Make this function return a diag:: that the number maps to, and then use 
`DiagnosticIDs::getWarningOptionForDiag()` to get that diag's group name and 
disable that. That should work, but it's a bit confusing since we'd return a 
single diag here (either of warn_deprecated, warn_property_method_deprecated, 
warn_atl_uuid_deprecated and several others would have the same effect of 
representing the group DeprecatedDeclarations) but then disable the whole group.

- Update clang-tblgen to emit something that can be used to create a DiagGroup 
enum and use that.

The latter sounds better to me, so I'll look into that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110668/new/

https://reviews.llvm.org/D110668

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


[PATCH] D110482: [clang] Implement if consteval (P1938)

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Stmt.h:164
 
-/// True if this if statement is a constexpr if.
-unsigned IsConstexpr : 1;
+/// Whether this is an if constexpr if or a consteval if or neither.
+IfStatementKind Kind : 3;

erichkeane wrote:
> 




Comment at: clang/include/clang/AST/Stmt.h:2081-2095
+  bool isConsteval() const {
+return IfStmtBits.Kind == IfStatementKind::Consteval;
+  }
+  bool isConstexpr() const {
+return IfStmtBits.Kind == IfStatementKind::Constexpr;
+  }
+

How do folks feel about this? My concern is that `if ! consteval (whatever)` is 
still a consteval if statement, and we care "is this a consteval if statement" 
more often than we care which form it is, so it's more helpful that 
`isConsteval()` returns true for both forms. For the times when we care about 
negated vs nonnegated, we can use the more explicit functions (which have 
better parity with their names).



Comment at: clang/include/clang/AST/Stmt.h:2122
   child_range children() {
-return child_range(getTrailingObjects(),
+// We always store a condition, but there is none for if consteval
+// statements, so skip it.

erichkeane wrote:
> Not sure if `consteval if` follows the same naming convention as `constexpr 
> if`?
Yup: https://eel.is/c++draft/stmt.if#4.sentence-1



Comment at: clang/include/clang/AST/Stmt.h:166
 
+/// True if this if statement is a if consteval statement.
+unsigned IsConsteval : 1;

erichkeane wrote:
> cor3ntin wrote:
> > erichkeane wrote:
> > > Not sure how others feel here, but for me, I kinda hate that we're using 
> > > 'unsigned' bitfields for all of this, particularly because these two are 
> > > mutually exclusive.  I'd prefer (though listen to others here first) if 
> > > the type of this was something more like:
> > > 
> > > IfEvalKind EvalKind : 2; // where IfEvalKind is enum class IfEvalKind 
> > > {None, Constexpr, Consteval};
> > I was not quite sure where to put an enum I could reuse in different place.
> > But I think I'd agree with you otherwise.
> > Any suggestion for where to put it?
> My best suggestion is somewhere in include/Basic.
> 
> We don't have a great file I think to fit it, but we DO have a ton where 
> we've created files for smal lthings (see ExceptionSpecificationType.h, 
> Linkage.h, or Lambda.h).
> 
> Looking through, there _IS_ a similar enum in Specifiers.h (perhaps the best 
> place for this) that might work well, ConstexprSpecKind might actually just 
> be what we want and could replace the other enum you created later.
> Not sure how others feel here, but for me, I kinda hate that we're using 
> 'unsigned' bitfields for all of this, particularly because these two are 
> mutually exclusive. 

Unfortunately I have stronger feelings here. We need the bit-fields to all have 
the same type, otherwise there's problems with layout in MSVC (also, we often 
get odd diagnostic behavior we have to come back and fix later, as in 
https://reviews.llvm.org/rGaf3a4e97d8627a32606ed32001583fe08f15b928). That's 
why we use `unsigned` for all our bit-fields.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:1506
+def warn_if_consteval_always_true : Warning<
+  "if consteval is always true in an %select{unevaluated|immediate}0 
context">,  InGroup>;
+

erichkeane wrote:
> 
I think the diagnostic group should be named `redundant-consteval-if`.



Comment at: clang/include/clang/Basic/Specifiers.h:45
+Consteval,
+ConstevalNegated
+  };

erichkeane wrote:
> Reads nicer to me maybe?  IDK, feel free to ignore.
Alternatively, `ConstevalNonnegated` and `ConstevalNegated` to make it more 
clear that they're distinguishable from one another. (I don't feel strongly 
about any particular opinion here.)



Comment at: clang/include/clang/Sema/Sema.h:1223
+/// occurs in an immediate function context - either a consteval function
+/// or an 'if consteval' function.
+ImmediateFunctionContext,

erichkeane wrote:
> 
I like the suggestion from @erichkeane, but drop the single quotes as it's no 
longer talking about syntax at that point.



Comment at: clang/include/clang/Sema/Sema.h:9137
+   "Must be in an expression evaluation context");
+for (auto it = ExprEvalContexts.rbegin(); it != ExprEvalContexts.rend();
+ it++) {

erichkeane wrote:
> cor3ntin wrote:
> > erichkeane wrote:
> > > What is our iterator type?  I THINK at minimum require this to be `auto *`
> > The iterator type is ungodly. Likely 
> > `SmallVector::reverse_iterator`. I 
> > think auto here is more readable but I can change if you want to
> > 
> I more questioned due to the lack of the `*`, I see it is the 
> reverse-iterator now, so i don't t

[PATCH] D110614: [clang-tidy] Fix false positives in cppcoreguidelines-virtual-class-destructor

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp:216-218
+template 
+struct TemplatedDerived : PublicVirtualBaseStruct {
+};

whisperity wrote:
> carlosgalvezp wrote:
> > aaron.ballman wrote:
> > > I think there are more interesting template test cases that should be 
> > > checked.
> > > ```
> > > // What to do when the derived type is definitely polymorphic
> > > // but the base class may or may not be?
> > > template 
> > > struct Derived : Ty {
> > >   virtual void func();
> > > };
> > > 
> > > struct S {};
> > > struct  T { virtual ~T(); };
> > > 
> > > void instantiate() {
> > >   Derived d1; // Diagnose
> > >   Derived d2; // Don't diagnose
> > > }
> > > ```
> > > 
> > Very interesting example.
> > 
> > The problem is that the diagnostic is shown where `Derived` is, not where 
> > the template is instantiated. How to go about that?
> > 
> > Seems like more testing and better diagnostics are needed to lower the 
> > amount of false positives, I wonder if we should disable the test meanwhile?
> First, let's try to see if printing, to the user, the matched record, prints 
> `Derived` instead of just `Derived`, irrespective of the location. If the 
> matcher matched the instantiation, the printing/formatting logic should 
> **really** pick that up.
> 
> It would be very hard to get to the `VarDecl` with the specific type if your 
> matcher logic starts the top-level matching from the type definitions 
> (`cxxRecordDecl(...)`).
> 
> If we **really** want to put some sort of a diagnostic at the location at the 
> places where the type is used, it could be done with another pass over the 
> AST. However, that has an associated runtime cost, and also could create 
> bazillions of `note: used here`-esque messages... But certainly doable. I 
> believe this is `typeLoc`, but `typeLoc` is always a thing I never understand 
> and every time I may end up using it it takes me a lot of reading to 
> understand it for a short time to use it.
> 
> 
> 
> If the previous step failed, you could still go around in a much more 
> convoluted way:
> 
> However, there is something called a `ClassTemplateSpecializationDecl` (see 
> the AST for @aaron.ballman's example here: http://godbolt.org/z/9qd7d1rs6), 
> which surely should have an associated matcher.
> 
> ```
> | |-ClassTemplateSpecializationDecl  line:2:8 struct 
> Derived definition
> | | |-DefinitionData polymorphic literal has_constexpr_non_copy_move_ctor 
> can_const_default_init
> | | | |-DefaultConstructor exists non_trivial constexpr defaulted_is_constexpr
> | | | |-CopyConstructor simple non_trivial has_const_param 
> implicit_has_const_param
> | | | |-MoveConstructor exists simple non_trivial
> | | | |-CopyAssignment simple non_trivial has_const_param 
> implicit_has_const_param
> | | | |-MoveAssignment exists simple non_trivial
> | | | `-Destructor simple irrelevant trivial
> | | |-public 'S':'S'
> | | |-TemplateArgument type 'S'
> | | | `-RecordType 'S'
> | | |   `-CXXRecord 'S'
> | | |-CXXRecordDecl prev 0x55ebcec4e600  col:8 implicit struct 
> Derived
> ```
> 
> The location for the "template specialisation" is still the location of the 
> primary template (as it is not an //explicit specialisation//), but at least 
> somehow in the AST the information of //"Which type was this class template 
> instantiated with?"// (`S`) is stored, so it is very likely that you can 
> either match on this directly, or if you can't match that way, you could 
> match all of these `ClassTemplateSpecializationDecl`s and check if their type 
> parameter matches a `ProblematicClassOrStruct`.
> 
> Of course, this becomes extra nasty the moment we have multiple template 
> parameters, or nested stuff, `template template`s (b...).
> 
> This will still not give you the location of the variable definition, but at 
> least you would have in your hand the template specialisation/instantiation 
> instance properly.
Oh, I may have caused some confusion with the comments in my example, sorry for 
that! I was imagining the diagnostics would be emitted on the line with the 
class declaration, but I commented on which instantiation I thought should 
diagnose. Being more explicit with what I was thinking:
```
// What to do when the derived type is definitely polymorphic
// but the base class may or may not be?
template 
struct Derived : Ty { // Diagnostic emitted here
  virtual void func();
};

struct S {};
struct  T { virtual ~T(); };

void instantiate() {
  Derived d1; // Instantiation causes a diagnostic above
  Derived d2; // Instantiation does not cause a diagnostic above
}
```


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110614/new/

https://reviews.llvm.org/D110614

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


[PATCH] D110482: [clang] Implement if consteval (P1938)

2021-09-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/include/clang/AST/Stmt.h:166
 
+/// True if this if statement is a if consteval statement.
+unsigned IsConsteval : 1;

aaron.ballman wrote:
> erichkeane wrote:
> > cor3ntin wrote:
> > > erichkeane wrote:
> > > > Not sure how others feel here, but for me, I kinda hate that we're 
> > > > using 'unsigned' bitfields for all of this, particularly because these 
> > > > two are mutually exclusive.  I'd prefer (though listen to others here 
> > > > first) if the type of this was something more like:
> > > > 
> > > > IfEvalKind EvalKind : 2; // where IfEvalKind is enum class IfEvalKind 
> > > > {None, Constexpr, Consteval};
> > > I was not quite sure where to put an enum I could reuse in different 
> > > place.
> > > But I think I'd agree with you otherwise.
> > > Any suggestion for where to put it?
> > My best suggestion is somewhere in include/Basic.
> > 
> > We don't have a great file I think to fit it, but we DO have a ton where 
> > we've created files for smal lthings (see ExceptionSpecificationType.h, 
> > Linkage.h, or Lambda.h).
> > 
> > Looking through, there _IS_ a similar enum in Specifiers.h (perhaps the 
> > best place for this) that might work well, ConstexprSpecKind might actually 
> > just be what we want and could replace the other enum you created later.
> > Not sure how others feel here, but for me, I kinda hate that we're using 
> > 'unsigned' bitfields for all of this, particularly because these two are 
> > mutually exclusive. 
> 
> Unfortunately I have stronger feelings here. We need the bit-fields to all 
> have the same type, otherwise there's problems with layout in MSVC (also, we 
> often get odd diagnostic behavior we have to come back and fix later, as in 
> https://reviews.llvm.org/rGaf3a4e97d8627a32606ed32001583fe08f15b928). That's 
> why we use `unsigned` for all our bit-fields.
Ah shucks!  Thanks for that Aaron!  I still like having IfStatementKind for the 
interface, but it seems like we'll have to static-cast in/out here.



Comment at: clang/include/clang/AST/Stmt.h:2081-2095
+  bool isConsteval() const {
+return IfStmtBits.Kind == IfStatementKind::Consteval;
+  }
+  bool isConstexpr() const {
+return IfStmtBits.Kind == IfStatementKind::Constexpr;
+  }
+

aaron.ballman wrote:
> How do folks feel about this? My concern is that `if ! consteval (whatever)` 
> is still a consteval if statement, and we care "is this a consteval if 
> statement" more often than we care which form it is, so it's more helpful 
> that `isConsteval()` returns true for both forms. For the times when we care 
> about negated vs nonnegated, we can use the more explicit functions (which 
> have better parity with their names).
I DO think I like that, the `isConstevalorNegatedConsteval` was a bit of 
heartburn running through this, but I couldn't come up with a better spelling.  
I think this _IS_ that better spelling.



Comment at: clang/include/clang/Basic/Specifiers.h:45
+Consteval,
+ConstevalNegated
+  };

aaron.ballman wrote:
> erichkeane wrote:
> > Reads nicer to me maybe?  IDK, feel free to ignore.
> Alternatively, `ConstevalNonnegated` and `ConstevalNegated` to make it more 
> clear that they're distinguishable from one another. (I don't feel strongly 
> about any particular opinion here.)
Mixed with your other suggestion on changing the functions, I think this ends 
up being a good suggestion.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110482/new/

https://reviews.llvm.org/D110482

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


[PATCH] D110715: [clang] Fix library name (libsupc++) in the admonition note.

2021-09-29 Thread Frederic Cambus via Phabricator via cfe-commits
fcambus created this revision.
fcambus added reviewers: rsmith, xgupta.
fcambus requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110715

Files:
  clang/docs/Toolchain.rst


Index: clang/docs/Toolchain.rst
===
--- clang/docs/Toolchain.rst
+++ clang/docs/Toolchain.rst
@@ -312,7 +312,7 @@
 
 .. note::
 
-  Clang does not currently automatically link against libatomic when statically
+  Clang does not currently automatically link against libsupc++ when statically
   linking libstdc++. You may need to manually add ``-lsupc++`` to support this
   configuration when using ``-static`` or ``-static-libstdc++``.
 


Index: clang/docs/Toolchain.rst
===
--- clang/docs/Toolchain.rst
+++ clang/docs/Toolchain.rst
@@ -312,7 +312,7 @@
 
 .. note::
 
-  Clang does not currently automatically link against libatomic when statically
+  Clang does not currently automatically link against libsupc++ when statically
   linking libstdc++. You may need to manually add ``-lsupc++`` to support this
   configuration when using ``-static`` or ``-static-libstdc++``.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D110614: [clang-tidy] Fix false positives in cppcoreguidelines-virtual-class-destructor

2021-09-29 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-virtual-class-destructor.cpp:216-218
+template 
+struct TemplatedDerived : PublicVirtualBaseStruct {
+};

aaron.ballman wrote:
> whisperity wrote:
> > carlosgalvezp wrote:
> > > aaron.ballman wrote:
> > > > I think there are more interesting template test cases that should be 
> > > > checked.
> > > > ```
> > > > // What to do when the derived type is definitely polymorphic
> > > > // but the base class may or may not be?
> > > > template 
> > > > struct Derived : Ty {
> > > >   virtual void func();
> > > > };
> > > > 
> > > > struct S {};
> > > > struct  T { virtual ~T(); };
> > > > 
> > > > void instantiate() {
> > > >   Derived d1; // Diagnose
> > > >   Derived d2; // Don't diagnose
> > > > }
> > > > ```
> > > > 
> > > Very interesting example.
> > > 
> > > The problem is that the diagnostic is shown where `Derived` is, not where 
> > > the template is instantiated. How to go about that?
> > > 
> > > Seems like more testing and better diagnostics are needed to lower the 
> > > amount of false positives, I wonder if we should disable the test 
> > > meanwhile?
> > First, let's try to see if printing, to the user, the matched record, 
> > prints `Derived` instead of just `Derived`, irrespective of the 
> > location. If the matcher matched the instantiation, the printing/formatting 
> > logic should **really** pick that up.
> > 
> > It would be very hard to get to the `VarDecl` with the specific type if 
> > your matcher logic starts the top-level matching from the type definitions 
> > (`cxxRecordDecl(...)`).
> > 
> > If we **really** want to put some sort of a diagnostic at the location at 
> > the places where the type is used, it could be done with another pass over 
> > the AST. However, that has an associated runtime cost, and also could 
> > create bazillions of `note: used here`-esque messages... But certainly 
> > doable. I believe this is `typeLoc`, but `typeLoc` is always a thing I 
> > never understand and every time I may end up using it it takes me a lot of 
> > reading to understand it for a short time to use it.
> > 
> > 
> > 
> > If the previous step failed, you could still go around in a much more 
> > convoluted way:
> > 
> > However, there is something called a `ClassTemplateSpecializationDecl` (see 
> > the AST for @aaron.ballman's example here: http://godbolt.org/z/9qd7d1rs6), 
> > which surely should have an associated matcher.
> > 
> > ```
> > | |-ClassTemplateSpecializationDecl  line:2:8 struct 
> > Derived definition
> > | | |-DefinitionData polymorphic literal has_constexpr_non_copy_move_ctor 
> > can_const_default_init
> > | | | |-DefaultConstructor exists non_trivial constexpr 
> > defaulted_is_constexpr
> > | | | |-CopyConstructor simple non_trivial has_const_param 
> > implicit_has_const_param
> > | | | |-MoveConstructor exists simple non_trivial
> > | | | |-CopyAssignment simple non_trivial has_const_param 
> > implicit_has_const_param
> > | | | |-MoveAssignment exists simple non_trivial
> > | | | `-Destructor simple irrelevant trivial
> > | | |-public 'S':'S'
> > | | |-TemplateArgument type 'S'
> > | | | `-RecordType 'S'
> > | | |   `-CXXRecord 'S'
> > | | |-CXXRecordDecl prev 0x55ebcec4e600  col:8 implicit 
> > struct Derived
> > ```
> > 
> > The location for the "template specialisation" is still the location of the 
> > primary template (as it is not an //explicit specialisation//), but at 
> > least somehow in the AST the information of //"Which type was this class 
> > template instantiated with?"// (`S`) is stored, so it is very likely that 
> > you can either match on this directly, or if you can't match that way, you 
> > could match all of these `ClassTemplateSpecializationDecl`s and check if 
> > their type parameter matches a `ProblematicClassOrStruct`.
> > 
> > Of course, this becomes extra nasty the moment we have multiple template 
> > parameters, or nested stuff, `template template`s (b...).
> > 
> > This will still not give you the location of the variable definition, but 
> > at least you would have in your hand the template 
> > specialisation/instantiation instance properly.
> Oh, I may have caused some confusion with the comments in my example, sorry 
> for that! I was imagining the diagnostics would be emitted on the line with 
> the class declaration, but I commented on which instantiation I thought 
> should diagnose. Being more explicit with what I was thinking:
> ```
> // What to do when the derived type is definitely polymorphic
> // but the base class may or may not be?
> template 
> struct Derived : Ty { // Diagnostic emitted here
>   virtual void func();
> };
> 
> struct S {};
> struct  T { virtual ~T(); };
> 
> void instantiate() {
>   Derived d1; // Instantiation causes a diagnostic above
>   Derived d2; // Instantiation does not cause a diagnostic above
> }
> ```
No worries, that was my unde

[PATCH] D110715: [clang] Fix library name (libsupc++) in the admonition note.

2021-09-29 Thread Shivam Gupta via Phabricator via cfe-commits
xgupta accepted this revision.
xgupta added a comment.
This revision is now accepted and ready to land.

LG, Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110715/new/

https://reviews.llvm.org/D110715

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


[clang] 7a7caf9 - [clang] Fix library name (libsupc++) in the admonition note.

2021-09-29 Thread Shivam Gupta via cfe-commits

Author: Frederic Cambus
Date: 2021-09-29T19:45:06+05:30
New Revision: 7a7caf97012f53172743d650fd3c97bce99f86ef

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

LOG: [clang] Fix library name (libsupc++) in the admonition note.

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

Added: 


Modified: 
clang/docs/Toolchain.rst

Removed: 




diff  --git a/clang/docs/Toolchain.rst b/clang/docs/Toolchain.rst
index 9c4099e15c98c..2ed835c0317e4 100644
--- a/clang/docs/Toolchain.rst
+++ b/clang/docs/Toolchain.rst
@@ -312,7 +312,7 @@ library version of libstdc++ contains a copy of libsupc++.
 
 .. note::
 
-  Clang does not currently automatically link against libatomic when statically
+  Clang does not currently automatically link against libsupc++ when statically
   linking libstdc++. You may need to manually add ``-lsupc++`` to support this
   configuration when using ``-static`` or ``-static-libstdc++``.
 



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


[PATCH] D110715: [clang] Fix library name (libsupc++) in the admonition note.

2021-09-29 Thread Shivam Gupta via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7a7caf97012f: [clang] Fix library name (libsupc++) in the 
admonition note. (authored by fcambus, committed by xgupta).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110715/new/

https://reviews.llvm.org/D110715

Files:
  clang/docs/Toolchain.rst


Index: clang/docs/Toolchain.rst
===
--- clang/docs/Toolchain.rst
+++ clang/docs/Toolchain.rst
@@ -312,7 +312,7 @@
 
 .. note::
 
-  Clang does not currently automatically link against libatomic when statically
+  Clang does not currently automatically link against libsupc++ when statically
   linking libstdc++. You may need to manually add ``-lsupc++`` to support this
   configuration when using ``-static`` or ``-static-libstdc++``.
 


Index: clang/docs/Toolchain.rst
===
--- clang/docs/Toolchain.rst
+++ clang/docs/Toolchain.rst
@@ -312,7 +312,7 @@
 
 .. note::
 
-  Clang does not currently automatically link against libatomic when statically
+  Clang does not currently automatically link against libsupc++ when statically
   linking libstdc++. You may need to manually add ``-lsupc++`` to support this
   configuration when using ``-static`` or ``-static-libstdc++``.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105191: [Clang][OpenMP] Add partial support for Static Device Libraries

2021-09-29 Thread Ye Luo via Phabricator via cfe-commits
ye-luo added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.h:62
+ bool postClangLink);
+void AddStaticDeviceLibs(Compilation *C, const Tool *T, const JobAction *JA,
+ const InputInfoList *Inputs, const Driver &D,

ye-luo wrote:
> Differentiate the names of all the three AddStaticDeviceLibs functions and 
> add documentation. Be sure to do document every function added in this patch.
@saiislam Fix this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105191/new/

https://reviews.llvm.org/D105191

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


[PATCH] D110436: [WIP] Add %n format specifier warning

2021-09-29 Thread Jayson Yan via Phabricator via cfe-commits
Jaysonyan updated this revision to Diff 375887.
Jaysonyan added a comment.

- Add more verbose warning message


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110436/new/

https://reviews.llvm.org/D110436

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/FixIt/format.m
  clang/test/Misc/warning-wall.c
  clang/test/Sema/format-string-percentn.c
  clang/test/Sema/format-strings-size_t.c
  clang/test/Sema/format-strings.c

Index: clang/test/Sema/format-strings.c
===
--- clang/test/Sema/format-strings.c
+++ clang/test/Sema/format-strings.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -Wformat-nonliteral -isystem %S/Inputs %s
-// RUN: %clang_cc1 -fsyntax-only -verify -Wformat-nonliteral -isystem %S/Inputs -fno-signed-char %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-format-n-specifier -Wformat-nonliteral -isystem %S/Inputs %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wno-format-n-specifier -Wformat-nonliteral -isystem %S/Inputs -fno-signed-char %s
 
 #include 
 #include 
@@ -644,6 +644,7 @@
   test14_bar("%", "%d", p); // expected-warning{{incomplete format specifier}}
 }
 
+#pragma GCC diagnostic ignored "-Wformat-n-specifier"
 void test_qualifiers(volatile int *vip, const int *cip,
  const volatile int *cvip) {
   printf("%n", cip); // expected-warning{{format specifies type 'int *' but the argument has type 'const int *'}}
Index: clang/test/Sema/format-strings-size_t.c
===
--- clang/test/Sema/format-strings-size_t.c
+++ clang/test/Sema/format-strings-size_t.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -Wno-format-n-specifier -fsyntax-only -verify %s
 
 int printf(char const *, ...);
 
Index: clang/test/Sema/format-string-percentn.c
===
--- /dev/null
+++ clang/test/Sema/format-string-percentn.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+int printf(const char *restrict, ...);
+void percentn(volatile int *n) {
+  printf("%n", n); // expected-warning{{usage of '%n' can lead to unsafe writing to memory}}
+}
Index: clang/test/Misc/warning-wall.c
===
--- clang/test/Misc/warning-wall.c
+++ clang/test/Misc/warning-wall.c
@@ -17,6 +17,7 @@
 CHECK-NEXT:  -Wformat-y2k
 CHECK-NEXT:  -Wformat-invalid-specifier
 CHECK-NEXT:  -Wformat-insufficient-args
+CHECK-NEXT:  -Wformat-n-specifier
 CHECK-NEXT:-Wfor-loop-analysis
 CHECK-NEXT:-Wframe-address
 CHECK-NEXT:-Wimplicit
Index: clang/test/FixIt/format.m
===
--- clang/test/FixIt/format.m
+++ clang/test/FixIt/format.m
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -fsyntax-only -fblocks -verify %s
-// RUN: %clang_cc1 -triple %itanium_abi_triple -fdiagnostics-parseable-fixits -fblocks %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -Wno-format-n-specifier -fsyntax-only -fblocks -verify %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -Wno-format-n-specifier -fdiagnostics-parseable-fixits -fblocks %s 2>&1 | FileCheck %s
 
 @class NSString;
 extern void NSLog(NSString *, ...);
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -8965,6 +8965,14 @@
 return true;
   }
 
+  // %n can lead to unsafe writing to memory
+  if (CS.getKind() == ConversionSpecifier::nArg) {
+EmitFormatDiagnostic(S.PDiag(diag::warn_printf_n_specifier),
+ getLocationOfByte(CS.getStart()),
+ /*IsStringLocation*/ true,
+ getSpecifierRange(startSpecifier, specifierLen));
+  }
+
   // Only scalars are allowed for os_trace.
   if (FSType == Sema::FST_OSTrace &&
   (CS.getKind() == ConversionSpecifier::PArg ||
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9226,6 +9226,8 @@
 
 def warn_printf_insufficient_data_args : Warning<
   "more '%%' conversions than data arguments">, InGroup;
+def warn_printf_n_specifier : Warning<
+  "usage of '%%n' can lead to unsafe writing to memory">, InGroup;
 def warn_printf_data_arg_not_used : Warning<
   "data argument not used by format string">, InGroup;
 def warn_format_invalid_conversion : Warning<
Index: clang/include/clang/Basic/DiagnosticGroups.td
===

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
thakis updated this revision to Diff 375891.
thakis added a comment.
Herald added subscribers: usaxena95, arphaman.

tblgen group IDs

Done, please take a look. We now have a `diag::Group` enum.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110668/new/

https://reviews.llvm.org/D110668

Files:
  clang/include/clang/Basic/CLWarnings.h
  clang/include/clang/Basic/Diagnostic.h
  clang/include/clang/Basic/DiagnosticCategories.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticIDs.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/CLWarnings.cpp
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Basic/DiagnosticIDs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Lex/Pragma.cpp
  clang/test/Driver/cl-options.c
  clang/test/Sema/pragma-warning.cpp
  clang/tools/diagtool/DiagnosticNames.cpp
  clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
  llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -55,6 +55,7 @@
   sources = [
 "Attributes.cpp",
 "Builtins.cpp",
+"CLWarnings.cpp",
 "CharInfo.cpp",
 "CodeGenOptions.cpp",
 "Cuda.cpp",
Index: clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
===
--- clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -129,6 +129,7 @@
   };
 
   struct GroupInfo {
+llvm::StringRef GroupName;
 std::vector DiagsInGroup;
 std::vector SubGroups;
 unsigned IDNo;
@@ -174,6 +175,7 @@
 Record *Group = DiagGroups[i];
 GroupInfo &GI =
 DiagsInGroup[std::string(Group->getValueAsString("GroupName"))];
+GI.GroupName = Group->getName();
 GI.Defs.push_back(Group);
 
 std::vector SubGroups = Group->getValueAsListOfDefs("SubGroups");
@@ -1279,8 +1281,8 @@
 OS << ", \"";
 OS.write_escaped(DiagTextBuilder.buildForDefinition(&R)) << '"';
 
-// Warning associated with the diagnostic. This is stored as an index into
-// the alphabetically sorted warning table.
+// Warning group associated with the diagnostic. This is stored as an index
+// into the alphabetically sorted warning group table.
 if (DefInit *DI = dyn_cast(R.getValueInit("Group"))) {
   std::map::iterator I = DiagsInGroup.find(
   std::string(DI->getDef()->getValueAsString("GroupName")));
@@ -1487,18 +1489,20 @@
   for (auto const &I: DiagsInGroup)
 MaxLen = std::max(MaxLen, (unsigned)I.first.size());
 
-  OS << "\n#ifdef GET_DIAG_TABLE\n";
+  OS << "\n#ifdef DIAG_ENTRY\n";
   unsigned SubGroupIndex = 1, DiagArrayIndex = 1;
   for (auto const &I: DiagsInGroup) {
 // Group option string.
-OS << "  { /* ";
+OS << "DIAG_ENTRY(";
+OS << I.second.GroupName << " /* ";
+
 if (I.first.find_first_not_of("abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789!@#$%^*-+=:?") !=
 std::string::npos)
   PrintFatalError("Invalid character in diagnostic group '" + I.first +
   "'");
-OS << I.first << " */ " << std::string(MaxLen - I.first.size(), ' ');
+OS << I.first << " */, ";
 // Store a pascal-style length byte at the beginning of the string.
 std::string Name = char(I.first.size()) + I.first;
 OS << GroupNames.GetOrAddStringOffset(Name, false) << ", ";
@@ -1517,7 +1521,7 @@
 DiagArrayIndex += DiagsInPedantic.size();
   DiagArrayIndex += V.size() + 1;
 } else {
-  OS << "/* Empty */ 0, ";
+  OS << "0, ";
 }
 
 // Subgroups.
@@ -1530,12 +1534,12 @@
 SubGroupIndex += GroupsInPedantic.size();
   SubGroupIndex += SubGroups.size() + 1;
 } else {
-  OS << "/* Empty */ 0";
+  OS << "0";
 }
 
-OS << " },\n";
+OS << " )\n";
   }
-  OS << "#endif // GET_DIAG_TABLE\n\n";
+  OS << "#endif // DIAG_ENTRY\n\n";
 }
 
 /// Emit the table of diagnostic categories.
Index: clang/tools/diagtool/DiagnosticNames.cpp
===
--- clang/tools/diagtool/DiagnosticNames.cpp
+++ clang/tools/diagtool/DiagnosticNames.cpp
@@ -66,9 +66,9 @@
 
 // Second the table of options, sorted by name for fast binary lookup.
 static const GroupRecord OptionTable[] = {
-#define GET_DIAG_TABLE
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups) { FlagNameOffset, Members, SubGroups },
 #include "clang/Basic/DiagnosticGroups.inc"
-#undef GET_DIAG_TABLE
+#undef DIAG_ENTRY
 };
 
 llvm::StringRef GroupRecord::getName() const {
Index: clang/test/Sema/pragma-warning.cpp
=

[PATCH] D105191: [Clang][OpenMP] Add partial support for Static Device Libraries

2021-09-29 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam marked an inline comment as done.
saiislam added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.h:62
+ bool postClangLink);
+void AddStaticDeviceLibs(Compilation *C, const Tool *T, const JobAction *JA,
+ const InputInfoList *Inputs, const Driver &D,

ye-luo wrote:
> ye-luo wrote:
> > Differentiate the names of all the three AddStaticDeviceLibs functions and 
> > add documentation. Be sure to do document every function added in this 
> > patch.
> @saiislam Fix this?
I have added documentation along with function definition in CommonArgs.cpp. 
Should I move it here? I thought keep documentation and code at the same place 
will improve readability.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105191/new/

https://reviews.llvm.org/D105191

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


[PATCH] D110276: Clean up large copies of binaries copied into temp directories in tests

2021-09-29 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D110276#3029952 , @thakis wrote:

> Softlinks don't work on Windows, that's why these tests use copies.
>
> clang_f_opts.c sadly started flaking almost immediately after this went in: 
> http://45.33.8.238/win/46115/step_7.txt
>
> So I fear the Windows file system can't handle this patch as-is.
>
> Maybe we can use `rm -f` and maybe that way the error isn't fatal even when 
> deleting the file doesn't work, not sure.

I can try submitting a change to make it use rm -f. Is this failure on a bot? I 
didn't get any bot failure notifications.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110276/new/

https://reviews.llvm.org/D110276

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


[clang] 2f1b99c - Use rm -f to fix Windows failures from test changes

2021-09-29 Thread Teresa Johnson via cfe-commits

Author: Teresa Johnson
Date: 2021-09-29T08:01:22-07:00
New Revision: 2f1b99ca67da18d858a4b070716790a8f53891d6

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

LOG: Use rm -f to fix Windows failures from test changes

Try to address Windows flakes from d87bdc272ba47b7d9109ff5c7191454ab2ae6fcb
by using 'rm -f' instead of just 'rm' as discussed in D110276. For example:
http://45.33.8.238/win/46115/step_7.txt

Added: 


Modified: 
clang/test/Driver/clang_f_opts.c
lld/test/COFF/pdb-relative-source-lines.test

Removed: 




diff  --git a/clang/test/Driver/clang_f_opts.c 
b/clang/test/Driver/clang_f_opts.c
index 2405fc9f0327e..3325dc44a8942 100644
--- a/clang/test/Driver/clang_f_opts.c
+++ b/clang/test/Driver/clang_f_opts.c
@@ -566,7 +566,7 @@
 // RUN: "%t.r/with spaces/clang" -### -S -target x86_64-unknown-linux 
-frecord-gcc-switches %s 2>&1 | FileCheck 
-check-prefix=CHECK-RECORD-GCC-SWITCHES-ESCAPED %s
 // CHECK-RECORD-GCC-SWITCHES-ESCAPED: "-record-command-line" "{{.+}}with\\ 
spaces{{.+}}"
 // Clean up copy of large binary copied into temp directory to avoid bloat.
-// RUN: rm "%t.r/with spaces/clang"
+// RUN: rm -f "%t.r/with spaces/clang"
 
 // RUN: %clang -### -S -ftrivial-auto-var-init=uninitialized %s 2>&1 | 
FileCheck -check-prefix=CHECK-TRIVIAL-UNINIT %s
 // RUN: %clang -### -S -ftrivial-auto-var-init=pattern %s 2>&1 | FileCheck 
-check-prefix=CHECK-TRIVIAL-PATTERN %s

diff  --git a/lld/test/COFF/pdb-relative-source-lines.test 
b/lld/test/COFF/pdb-relative-source-lines.test
index 2a131dd39f561..728667bc43b65 100644
--- a/lld/test/COFF/pdb-relative-source-lines.test
+++ b/lld/test/COFF/pdb-relative-source-lines.test
@@ -42,7 +42,7 @@ RUN: ./lld-link -debug -entry:main -nodefaultlib -out:out.exe 
-pdb:out.pdb pdb_l
 RUN: llvm-pdbutil pdb2yaml -modules -module-files -module-syms 
-subsections=lines,fc %t/out.pdb | FileCheck --check-prefix=ABSOLUTE %s
 
 Clean up copy of large binary copied into temp directory to avoid bloat.
-RUN: rm ./lld-link
+RUN: rm -f ./lld-link
 
 CHECK-LABEL:  - Module:  'c:\src\pdb_lines_1_relative.obj'
 CHECK-NEXT: ObjFile: 'c:\src\pdb_lines_1_relative.obj'



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


[PATCH] D110276: Clean up large copies of binaries copied into temp directories in tests

2021-09-29 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D110276#3030390 , @tejohnson wrote:

> In D110276#3029952 , @thakis wrote:
>
>> Softlinks don't work on Windows, that's why these tests use copies.
>>
>> clang_f_opts.c sadly started flaking almost immediately after this went in: 
>> http://45.33.8.238/win/46115/step_7.txt
>>
>> So I fear the Windows file system can't handle this patch as-is.
>>
>> Maybe we can use `rm -f` and maybe that way the error isn't fatal even when 
>> deleting the file doesn't work, not sure.
>
> I can try submitting a change to make it use rm -f. Is this failure on a bot? 
> I didn't get any bot failure notifications.

Made this change in 2f1b99ca67da18d858a4b070716790a8f53891d6 
. I see 
lots of "rm -f" in the tests, including elsewhere in clang_f_opts.c, so 
hopefully this should work.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110276/new/

https://reviews.llvm.org/D110276

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


[PATCH] D109607: [X86] Refactor GetSSETypeAtOffset to fix pr51813

2021-09-29 Thread Douglas Yung via Phabricator via cfe-commits
dyung added a comment.

Hi, our internal testing started to hit an assertion failure in one of our 
tests after this commit. I have put the details in PR52011, can you please take 
a look?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109607/new/

https://reviews.llvm.org/D109607

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


[PATCH] D105191: [Clang][OpenMP] Add partial support for Static Device Libraries

2021-09-29 Thread Ye Luo via Phabricator via cfe-commits
ye-luo added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.h:62
+ bool postClangLink);
+void AddStaticDeviceLibs(Compilation *C, const Tool *T, const JobAction *JA,
+ const InputInfoList *Inputs, const Driver &D,

saiislam wrote:
> ye-luo wrote:
> > ye-luo wrote:
> > > Differentiate the names of all the three AddStaticDeviceLibs functions 
> > > and add documentation. Be sure to do document every function added in 
> > > this patch.
> > @saiislam Fix this?
> I have added documentation along with function definition in CommonArgs.cpp. 
> Should I move it here? I thought keep documentation and code at the same 
> place will improve readability.
The docs are good. I was looking for "Differentiate the names of all the three 
AddStaticDeviceLibs functions"


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105191/new/

https://reviews.llvm.org/D105191

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


[PATCH] D110673: [clang] Don't modify OptRemark if the argument is not relevant

2021-09-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

In D110673#3029438 , @JamesNagurne 
wrote:

> I'll take a quick look tomorrow, but the general idea is that on calling 
> ParseOptimizationRemark on line 1909 with a -cc1 command line containing 
> -Rpass=inline -Rno-pass, Opts.OptimizationRemarkMissed and 
> Opts.OptimizationRemarkAnalysis are set to valid patterns (Regex is ".*", 
> Pattern is "", and Kind is RK_Missing). This happens around line 1909 in the 
> change set.
>
> This configuration makes it into the LLVM backend. When prompted by specific 
> calls to llvm::shouldInline (or something similar, can't remember the 
> spelling off hand), emits an optimization-missed remark when one of the 
> functions in the test's IR is not inlined.
>
>> "...in clang::ProcessWarningOptions() we'll separately look at all -R 
>> arguments and turn on/off corresponding diagnostic groups."
>
> Why would -Rno-pass turn off "pass-missed" or "pass-analysis" diagnostic 
> groups? That seems counterintuitive. They seem to be different groups, 
> considering how they're used in the backend.

It's not that -Rno-pass turns off "pass-missed" or "pass-analysis", it's that 
-Rpass turns on the "pass" diagnostic groups, and the "pass-missed" or 
"pass-analysis" groups are never turned on in the first place.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110673/new/

https://reviews.llvm.org/D110673

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


[clang-tools-extra] 7674bd4 - [clang-tidy] Merges separate isa<>/assert/unreachable/dyn_cast<>/cast<> calls

2021-09-29 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2021-09-29T16:35:29+01:00
New Revision: 7674bd4d44921d2d110cfb56f2674d4e6e8a68e3

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

LOG: [clang-tidy] Merges separate isa<>/assert/unreachable/dyn_cast<>/cast<> 
calls

We can directly use cast<> instead of separate dyn_cast<> with assertions as 
cast<> will perform this for us.

Similarly we can replace a if(isa<>)+cast<>/dyn_cast<> with if(dyn_cast<>)

Added: 


Modified: 
clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp
index 40ba3913467f2..0290789e76bfe 100644
--- a/clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp
+++ b/clang-tools-extra/clang-tidy/altera/UnrollLoopsCheck.cpp
@@ -120,9 +120,7 @@ bool UnrollLoopsCheck::hasKnownBounds(const Stmt *Statement,
   if (isa(Statement))
 return false;
   // The last loop type is a for loop.
-  const auto *ForLoop = dyn_cast(Statement);
-  if (!ForLoop)
-llvm_unreachable("Unknown loop");
+  const auto *ForLoop = cast(Statement);
   const Stmt *Initializer = ForLoop->getInit();
   const Expr *Conditional = ForLoop->getCond();
   const Expr *Increment = ForLoop->getInc();
@@ -142,8 +140,7 @@ bool UnrollLoopsCheck::hasKnownBounds(const Stmt *Statement,
 if (!Op->isIncrementDecrementOp())
   return false;
 
-  if (isa(Conditional)) {
-const auto *BinaryOp = dyn_cast(Conditional);
+  if (const auto *BinaryOp = dyn_cast(Conditional)) {
 const Expr *LHS = BinaryOp->getLHS();
 const Expr *RHS = BinaryOp->getRHS();
 // If both sides are value dependent or constant, loop bounds are unknown.
@@ -173,8 +170,7 @@ bool UnrollLoopsCheck::hasLargeNumIterations(const Stmt 
*Statement,
 assert(CXXLoopBound && "CXX ranged for loop has no loop bound");
 return exprHasLargeNumIterations(CXXLoopBound, Context);
   }
-  const auto *ForLoop = dyn_cast(Statement);
-  assert(ForLoop && "Unknown loop");
+  const auto *ForLoop = cast(Statement);
   const Stmt *Initializer = ForLoop->getInit();
   const Expr *Conditional = ForLoop->getCond();
   const Expr *Increment = ForLoop->getInc();
@@ -189,10 +185,9 @@ bool UnrollLoopsCheck::hasLargeNumIterations(const Stmt 
*Statement,
   InitValue = Evaluation->getInt().getExtValue();
 }
   }
-  assert(isa(Conditional) &&
- "Conditional is not a binary operator");
+
   int EndValue;
-  const auto *BinaryOp = dyn_cast(Conditional);
+  const auto *BinaryOp = cast(Conditional);
   if (!extractValue(EndValue, BinaryOp, Context))
 return true;
 



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


[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

2021-09-29 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added a comment.

I would greatly prefer to enable this by default, so let me build a toolchain 
and see how it holds up.

The empty initializer list extension is pretty widely supported, so I single 
zero-initialization is way less common these days, but I'll look.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110656/new/

https://reviews.llvm.org/D110656

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


[PATCH] D107506: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-09-29 Thread Sean Fertile via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9b10e2b1cf01: [PowerPC][AIX] Warn when using pragma 
align(packed) on AIX. (authored by sfertile).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107506/new/

https://reviews.llvm.org/D107506

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/aix-pragma-align-packed-warn.c


Index: clang/test/Sema/aix-pragma-align-packed-warn.c
===
--- /dev/null
+++ clang/test/Sema/aix-pragma-align-packed-warn.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff  -fxl-pragma-pack -verify 
-fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff  -fxl-pragma-pack -verify 
-fsyntax-only %s
+
+#pragma align(packed)
+struct A {  // expected-warning {{#pragma align(packed) may not be compatible 
with objects generated with AIX XL C/C++}}
+  short s1;
+  int   : 0;
+  short s2;
+};
+
+struct B {  // expected-warning {{#pragma align(packed) may not be compatible 
with objects generated with AIX XL C/C++}}
+  short a : 8;
+  short b : 8;
+  int c;
+};
+
+struct C {
+  int x, y, z;
+};
+
+struct D {
+  double d;
+  struct A a;
+};
+#pragma align(reset)
+
+struct E {
+  int a : 28;
+  int   : 0;
+  int b : 16;
+};
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -16613,6 +16613,23 @@
   // Notify the consumer that we've defined a tag.
   if (!Tag->isInvalidDecl())
 Consumer.HandleTagDeclDefinition(Tag);
+
+  // Clangs implementation of #pragma align(packed) differs in bitfield layout
+  // from XLs and instead matches the XL #pragma pack(1) behavior.
+  if (Context.getTargetInfo().getTriple().isOSAIX() &&
+  AlignPackStack.hasValue()) {
+AlignPackInfo APInfo = AlignPackStack.CurrentValue;
+// Only diagnose #pragma align(packed).
+if (!APInfo.IsAlignAttr() || APInfo.getAlignMode() != 
AlignPackInfo::Packed)
+  return;
+const RecordDecl *RD = dyn_cast(Tag);
+if (!RD)
+  return;
+// Only warn if there is at least 1 bitfield member.
+if (llvm::any_of(RD->fields(),
+ [](const FieldDecl *FD) { return FD->isBitField(); }))
+  Diag(BraceRange.getBegin(), diag::warn_pragma_align_not_xl_compatible);
+  }
 }
 
 void Sema::ActOnObjCContainerFinishDefinition() {
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -916,6 +916,9 @@
   InGroup;
 def err_pragma_options_align_mac68k_target_unsupported : Error<
   "mac68k alignment pragma is not supported on this target">;
+def warn_pragma_align_not_xl_compatible : Warning<
+  "#pragma align(packed) may not be compatible with objects generated with AIX 
XL C/C++">,
+  InGroup;
 def warn_pragma_pack_invalid_alignment : Warning<
   "expected #pragma pack parameter to be '1', '2', '4', '8', or '16'">,
   InGroup;


Index: clang/test/Sema/aix-pragma-align-packed-warn.c
===
--- /dev/null
+++ clang/test/Sema/aix-pragma-align-packed-warn.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff  -fxl-pragma-pack -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff  -fxl-pragma-pack -verify -fsyntax-only %s
+
+#pragma align(packed)
+struct A {  // expected-warning {{#pragma align(packed) may not be compatible with objects generated with AIX XL C/C++}}
+  short s1;
+  int   : 0;
+  short s2;
+};
+
+struct B {  // expected-warning {{#pragma align(packed) may not be compatible with objects generated with AIX XL C/C++}}
+  short a : 8;
+  short b : 8;
+  int c;
+};
+
+struct C {
+  int x, y, z;
+};
+
+struct D {
+  double d;
+  struct A a;
+};
+#pragma align(reset)
+
+struct E {
+  int a : 28;
+  int   : 0;
+  int b : 16;
+};
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -16613,6 +16613,23 @@
   // Notify the consumer that we've defined a tag.
   if (!Tag->isInvalidDecl())
 Consumer.HandleTagDeclDefinition(Tag);
+
+  // Clangs implementation of #pragma align(packed) differs in bitfield layout
+  // from XLs and instead matches the XL #pragma pack(1) behavior.
+  if (Context.getTargetInfo().getTriple().isOSAIX() &&
+  AlignPackStack.hasValue()) {
+AlignPackInfo APInfo = AlignPackStack.CurrentValue;
+// Only diagnose #pragma align(packed).
+if (!APInfo.IsAlignAttr() || APInfo.getAlignMode() != AlignPackInfo::Packed)
+  return;
+const RecordDecl *RD = dyn_cast(Tag);
+if (!RD)
+  return;
+// Only warn if there is 

[clang] 9b10e2b - [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

2021-09-29 Thread Sean Fertile via cfe-commits

Author: Sean Fertile
Date: 2021-09-29T11:53:46-04:00
New Revision: 9b10e2b1cf01b37f441d83ebc41d2c2f9f81831e

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

LOG: [PowerPC][AIX] Warn when using pragma align(packed) on AIX.

With xlc and xlC pragma align(packed) will pack bitfields the same way
as pragma align(bit_packed). xlclang, xlclang++ and clang will
pack bitfields the same way as pragma pack(1). Issue a warning when
source code using pragma align(packed) is used to alert the user it
may not be compatable with xlc/xlC.

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

Added: 
clang/test/Sema/aix-pragma-align-packed-warn.c

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 00b6acf8bbe68..a3944f7a6054b 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -916,6 +916,9 @@ def warn_pragma_options_align_reset_failed : Warning<
   InGroup;
 def err_pragma_options_align_mac68k_target_unsupported : Error<
   "mac68k alignment pragma is not supported on this target">;
+def warn_pragma_align_not_xl_compatible : Warning<
+  "#pragma align(packed) may not be compatible with objects generated with AIX 
XL C/C++">,
+  InGroup;
 def warn_pragma_pack_invalid_alignment : Warning<
   "expected #pragma pack parameter to be '1', '2', '4', '8', or '16'">,
   InGroup;

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index db7c9f9418042..48f298f2ce823 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -16613,6 +16613,23 @@ void Sema::ActOnTagFinishDefinition(Scope *S, Decl 
*TagD,
   // Notify the consumer that we've defined a tag.
   if (!Tag->isInvalidDecl())
 Consumer.HandleTagDeclDefinition(Tag);
+
+  // Clangs implementation of #pragma align(packed) 
diff ers in bitfield layout
+  // from XLs and instead matches the XL #pragma pack(1) behavior.
+  if (Context.getTargetInfo().getTriple().isOSAIX() &&
+  AlignPackStack.hasValue()) {
+AlignPackInfo APInfo = AlignPackStack.CurrentValue;
+// Only diagnose #pragma align(packed).
+if (!APInfo.IsAlignAttr() || APInfo.getAlignMode() != 
AlignPackInfo::Packed)
+  return;
+const RecordDecl *RD = dyn_cast(Tag);
+if (!RD)
+  return;
+// Only warn if there is at least 1 bitfield member.
+if (llvm::any_of(RD->fields(),
+ [](const FieldDecl *FD) { return FD->isBitField(); }))
+  Diag(BraceRange.getBegin(), diag::warn_pragma_align_not_xl_compatible);
+  }
 }
 
 void Sema::ActOnObjCContainerFinishDefinition() {

diff  --git a/clang/test/Sema/aix-pragma-align-packed-warn.c 
b/clang/test/Sema/aix-pragma-align-packed-warn.c
new file mode 100644
index 0..acbca792e37a3
--- /dev/null
+++ b/clang/test/Sema/aix-pragma-align-packed-warn.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff  -fxl-pragma-pack -verify 
-fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff  -fxl-pragma-pack -verify 
-fsyntax-only %s
+
+#pragma align(packed)
+struct A {  // expected-warning {{#pragma align(packed) may not be compatible 
with objects generated with AIX XL C/C++}}
+  short s1;
+  int   : 0;
+  short s2;
+};
+
+struct B {  // expected-warning {{#pragma align(packed) may not be compatible 
with objects generated with AIX XL C/C++}}
+  short a : 8;
+  short b : 8;
+  int c;
+};
+
+struct C {
+  int x, y, z;
+};
+
+struct D {
+  double d;
+  struct A a;
+};
+#pragma align(reset)
+
+struct E {
+  int a : 28;
+  int   : 0;
+  int b : 16;
+};



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


[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-09-29 Thread Quinn Pham via Phabricator via cfe-commits
quinnp updated this revision to Diff 375912.
quinnp added a comment.

Fixing failing test case after rebasing with https://reviews.llvm.org/D110213.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106959/new/

https://reviews.llvm.org/D106959

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
  llvm/test/CodeGen/PowerPC/fdiv.ll

Index: llvm/test/CodeGen/PowerPC/fdiv.ll
===
--- llvm/test/CodeGen/PowerPC/fdiv.ll
+++ llvm/test/CodeGen/PowerPC/fdiv.ll
@@ -23,3 +23,16 @@
   %3 = fdiv contract reassoc arcp nsz ninf float %0, %1
   ret float %3
 }
+
+define dso_local float @fdiv_fast(float %0, float %1) local_unnamed_addr {
+; CHECK-LABEL: fdiv_fast:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:xsresp 3, 2
+; CHECK-NEXT:xsmulsp 0, 1, 3
+; CHECK-NEXT:xsnmsubasp 1, 2, 0
+; CHECK-NEXT:xsmaddasp 0, 3, 1
+; CHECK-NEXT:fmr 1, 0
+; CHECK-NEXT:blr
+  %3 = fdiv fast float %0, %1
+  ret float %3
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
@@ -0,0 +1,80 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -ffast-math -ffp-contract=fast \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s --check-prefix CHECK-OFAST
+
+extern double a;
+extern double b;
+extern float c;
+extern float d;
+
+// CHECK-LABEL:   @test_swdiv(
+// CHECK: [[TMP0:%.*]] = load double, double* @a
+// CHECK-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-NEXT:[[SWDIV:%.*]] = fdiv double [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret double [[SWDIV]]
+//
+// CHECK-OFAST-LABEL:   @test_swdiv(
+// CHECK-OFAST: [[TMP0:%.*]] = load double, double* @a
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-OFAST-NEXT:[[SWDIV:%.*]] = fdiv fast double [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret double [[SWDIV]]
+//
+double test_swdiv() {
+  return __swdiv(a, b);
+}
+
+// CHECK-LABEL:   @test_swdivs(
+// CHECK: [[TMP0:%.*]] = load float, float* @c
+// CHECK-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-NEXT:[[SWDIVS:%.*]] = fdiv float [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret float [[SWDIVS]]
+//
+// CHECK-OFAST-LABEL:   @test_swdivs(
+// CHECK-OFAST: [[TMP0:%.*]] = load float, float* @c
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-OFAST-NEXT:[[SWDIVS:%.*]] = fdiv fast float [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret float [[SWDIVS]]
+//
+float test_swdivs() {
+  return __swdivs(c, d);
+}
+
+// CHECK-LABEL:   @test_builtin_ppc_swdiv(
+// CHECK: [[TMP0:%.*]] = load double, double* @a
+// CHECK-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-NEXT:[[SWDIV:%.*]] = fdiv double [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret double [[SWDIV]]
+//
+// CHECK-OFAST-LABEL:   @test_builtin_ppc_swdiv(
+// CHECK-OFAST: [[TMP0:%.*]] = load double, double* @a
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-OFAST-NEXT:[[SWDIV:%.*]] = fdiv fast double [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret double [[SWDIV]]
+//
+double test_builtin_ppc_swdiv() {
+  return __builtin_ppc_swdiv(a, b);
+}
+
+// CHECK-LABEL:   @test_builtin_ppc_swdivs(
+// CHECK: [[TMP0:%.*]] = load float, float* @c
+// CHECK-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-NEXT:[[SWDIVS:%.*]] = fdiv float [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret float [[SWDIVS]]
+//
+// CHECK-OFAST-LABEL:   @test_builtin_ppc_swdivs(
+// CHECK-OFAST: [[TMP0:%.*]] = load float, float* @c
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-OFAST-NEXT:[[SWDIVS:%.*]] = fdiv fast float [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret float [[SWDIVS]]
+//
+float test_builtin_ppc_swdivs() {
+  return __builtin_ppc_swdivs(c, d);
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -16077,7 +16077,7 @@
*this, E, Intrinsic::sqrt,
Intrinsic::experimental_constrained_sqrt))
 .getScalarVal();
-  case PPC::BI__builtin_ppc_tes

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D110656#3030580 , @beanz wrote:

> I would greatly prefer to enable this by default, so let me build a toolchain 
> and see how it holds up.

Awesome, SGTM!

> The empty initializer list extension is pretty widely supported, so I single 
> zero-initialization is way less common these days, but I'll look.

It may be widely supported, but there's plenty of single-zero-inits I was 
finding on that code search:

  static guint notification_signals[LAST_SIGNAL] = { 0 };
  charport_str[MAX_PORT_STR_LEN+1] = {0};
  char aBuf[64] = {0};
  unsigned char strong_checksum[SHA256_DIGEST_LENGTH] = {0};
  unsigned long zones_size[MAX_NR_ZONES] = {0};
  unsigned long zholes_size[MAX_NR_ZONES] = {0};
  // and so on


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110656/new/

https://reviews.llvm.org/D110656

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


[PATCH] D69764: [clang-format] Add Left/Right Const fixer capability

2021-09-29 Thread Simon Giesecke via Phabricator via cfe-commits
simon.giesecke added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:3233
+
+   ``QualifierAlignment`` COULD lead to incorrect code generation.
+

This is pretty unclear, for a number of reasons:
* First, this probably only refers to a setting other than `QAS_Leave`?
* Second, "lead to incorrect code generation" seems to skip a step. In the 
first place, this seems to imply that a setting other than `QAS_Leave` might 
change the semantics of the source code.
* Third, it's not clear to me when this would happen, and how likely that is. 
Does this mean "Non-default settings are experimental, and you shouldn't use 
this in production?" or rather "Under rare circumstances that are unlikely to 
happen in real code, a non-default setting might change semantics." At the 
minimum, could this give some example(s) when this happens?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69764/new/

https://reviews.llvm.org/D69764

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


[PATCH] D109607: [X86] Refactor GetSSETypeAtOffset to fix pr51813

2021-09-29 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei added a comment.

In D109607#3030478 , @dyung wrote:

> Hi, our internal testing started to hit an assertion failure in one of our 
> tests after this commit. I have put the details in PR52011, can you please 
> take a look?

Sure. Thanks for reporting it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109607/new/

https://reviews.llvm.org/D109607

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


[clang] 26db178 - [OpenCL][NFC] Refactor vloada_half and vstorea_half decls

2021-09-29 Thread Stuart Brady via cfe-commits

Author: Stuart Brady
Date: 2021-09-29T17:22:39+01:00
New Revision: 26db178cc2b39167a2fd69acfc8ba7ea564f3746

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

LOG: [OpenCL][NFC] Refactor vloada_half and vstorea_half decls

Group them together with the vload_half and vstore_half decls for
simplicity.

Reviewed By: svenvh

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

Added: 


Modified: 
clang/lib/Sema/OpenCLBuiltins.td

Removed: 




diff  --git a/clang/lib/Sema/OpenCLBuiltins.td 
b/clang/lib/Sema/OpenCLBuiltins.td
index 5d75c2bb1a84..2501e50b8968 100644
--- a/clang/lib/Sema/OpenCLBuiltins.td
+++ b/clang/lib/Sema/OpenCLBuiltins.td
@@ -808,9 +808,6 @@ multiclass VloadVstore addrspaces, bit 
defStores> {
 def : Builtin, Size, 
PointerType, AS>]>;
 def : Builtin, Size, 
PointerType, AS>]>;
   }
-  foreach name = ["vloada_half" # VSize] in {
-def : Builtin, Size, 
PointerType, AS>]>;
-  }
   if defStores then {
 foreach name = ["vstore" # VSize] in {
   def : Builtin, Size, 
PointerType]>;
@@ -825,12 +822,6 @@ multiclass VloadVstore addrspaces, bit 
defStores> {
   def : Builtin, Size, 
PointerType]>;
   def : Builtin, Size, 
PointerType]>;
 }
-foreach rnd = ["", "_rte", "_rtz", "_rtp", "_rtn"] in {
-  foreach name = ["vstorea_half" # VSize # rnd] in {
-def : Builtin, Size, 
PointerType]>;
-def : Builtin, Size, 
PointerType]>;
-  }
-}
   }
 }
   }
@@ -849,7 +840,7 @@ multiclass VloadVstoreHalf addrspaces, 
bit defStores> {
   foreach AS = addrspaces in {
 def : Builtin<"vload_half", [Float, Size, PointerType, 
AS>]>;
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vload_half" # VSize] in {
+  foreach name = ["vload_half" # VSize, "vloada_half" # VSize] in {
 def : Builtin, Size, 
PointerType, AS>]>;
   }
 }
@@ -860,7 +851,7 @@ multiclass VloadVstoreHalf addrspaces, 
bit defStores> {
   def : Builtin]>;
 }
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vstore_half" # VSize # rnd] in {
+  foreach name = ["vstore_half" # VSize # rnd, "vstorea_half" # VSize 
# rnd] in {
 def : Builtin, Size, 
PointerType]>;
 def : Builtin, Size, 
PointerType]>;
   }



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


[PATCH] D110636: [OpenCL][NFC] Refactor vloada_half and vstorea_half decls

2021-09-29 Thread Stuart Brady via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG26db178cc2b3: [OpenCL][NFC] Refactor vloada_half and 
vstorea_half decls (authored by stuart).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110636/new/

https://reviews.llvm.org/D110636

Files:
  clang/lib/Sema/OpenCLBuiltins.td


Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -808,9 +808,6 @@
 def : Builtin, Size, 
PointerType, AS>]>;
 def : Builtin, Size, 
PointerType, AS>]>;
   }
-  foreach name = ["vloada_half" # VSize] in {
-def : Builtin, Size, 
PointerType, AS>]>;
-  }
   if defStores then {
 foreach name = ["vstore" # VSize] in {
   def : Builtin, Size, 
PointerType]>;
@@ -825,12 +822,6 @@
   def : Builtin, Size, 
PointerType]>;
   def : Builtin, Size, 
PointerType]>;
 }
-foreach rnd = ["", "_rte", "_rtz", "_rtp", "_rtn"] in {
-  foreach name = ["vstorea_half" # VSize # rnd] in {
-def : Builtin, Size, 
PointerType]>;
-def : Builtin, Size, 
PointerType]>;
-  }
-}
   }
 }
   }
@@ -849,7 +840,7 @@
   foreach AS = addrspaces in {
 def : Builtin<"vload_half", [Float, Size, PointerType, 
AS>]>;
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vload_half" # VSize] in {
+  foreach name = ["vload_half" # VSize, "vloada_half" # VSize] in {
 def : Builtin, Size, 
PointerType, AS>]>;
   }
 }
@@ -860,7 +851,7 @@
   def : Builtin]>;
 }
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vstore_half" # VSize # rnd] in {
+  foreach name = ["vstore_half" # VSize # rnd, "vstorea_half" # VSize 
# rnd] in {
 def : Builtin, Size, 
PointerType]>;
 def : Builtin, Size, 
PointerType]>;
   }


Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -808,9 +808,6 @@
 def : Builtin, Size, PointerType, AS>]>;
 def : Builtin, Size, PointerType, AS>]>;
   }
-  foreach name = ["vloada_half" # VSize] in {
-def : Builtin, Size, PointerType, AS>]>;
-  }
   if defStores then {
 foreach name = ["vstore" # VSize] in {
   def : Builtin, Size, PointerType]>;
@@ -825,12 +822,6 @@
   def : Builtin, Size, PointerType]>;
   def : Builtin, Size, PointerType]>;
 }
-foreach rnd = ["", "_rte", "_rtz", "_rtp", "_rtn"] in {
-  foreach name = ["vstorea_half" # VSize # rnd] in {
-def : Builtin, Size, PointerType]>;
-def : Builtin, Size, PointerType]>;
-  }
-}
   }
 }
   }
@@ -849,7 +840,7 @@
   foreach AS = addrspaces in {
 def : Builtin<"vload_half", [Float, Size, PointerType, AS>]>;
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vload_half" # VSize] in {
+  foreach name = ["vload_half" # VSize, "vloada_half" # VSize] in {
 def : Builtin, Size, PointerType, AS>]>;
   }
 }
@@ -860,7 +851,7 @@
   def : Builtin]>;
 }
 foreach VSize = [2, 3, 4, 8, 16] in {
-  foreach name = ["vstore_half" # VSize # rnd] in {
+  foreach name = ["vstore_half" # VSize # rnd, "vstorea_half" # VSize # rnd] in {
 def : Builtin, Size, PointerType]>;
 def : Builtin, Size, PointerType]>;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Hans Wennborg via Phabricator via cfe-commits
hans accepted this revision.
hans added a comment.
This revision is now accepted and ready to land.

Nice! lgtm




Comment at: clang/include/clang/Basic/CLWarnings.h:18
+enum class Group;
+};
+

clang-tidy's comment about the extra semicolon seems valid


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110668/new/

https://reviews.llvm.org/D110668

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


[clang] 67a3d1e - [PowerPC] swdiv builtins for XL compatibility

2021-09-29 Thread Quinn Pham via cfe-commits

Author: Quinn Pham
Date: 2021-09-29T11:31:07-05:00
New Revision: 67a3d1e2755152608fcb1737f7d0519121e037b7

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

LOG: [PowerPC] swdiv builtins for XL compatibility

This patch is in a series of patches to provide builtins for compatibility with
the XL compiler. This patch implements the software divide builtin as
wrappers for a floating point divide. XL provided these builtins because it
didn't produce software estimates by default at `-Ofast`. When compiled
with `-Ofast` these builtins will produce the software estimate for divide.

Reviewed By: #powerpc, nemanjai

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

Added: 
clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c

Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/lib/Basic/Targets/PPC.cpp
clang/lib/CodeGen/CGBuiltin.cpp
llvm/test/CodeGen/PowerPC/fdiv.ll

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 6fee978530dd..26286c270905 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -101,6 +101,8 @@ BUILTIN(__builtin_ppc_compare_exp_lt, "idd", "")
 BUILTIN(__builtin_ppc_compare_exp_gt, "idd", "")
 BUILTIN(__builtin_ppc_compare_exp_eq, "idd", "")
 BUILTIN(__builtin_ppc_test_data_class, "idIi", "t")
+BUILTIN(__builtin_ppc_swdiv, "ddd", "")
+BUILTIN(__builtin_ppc_swdivs, "fff", "")
 // Compare
 BUILTIN(__builtin_ppc_cmpeqb, "LLiLLiLLi", "")
 BUILTIN(__builtin_ppc_cmprb, "iCIiii", "")

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 4835f1d81674..21376b328a24 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -243,6 +243,8 @@ static void defineXLCompatMacros(MacroBuilder &Builder) {
   Builder.defineMacro("__compare_exp_gt", "__builtin_ppc_compare_exp_gt");
   Builder.defineMacro("__compare_exp_eq", "__builtin_ppc_compare_exp_eq");
   Builder.defineMacro("__test_data_class", "__builtin_ppc_test_data_class");
+  Builder.defineMacro("__swdiv", "__builtin_ppc_swdiv");
+  Builder.defineMacro("__swdivs", "__builtin_ppc_swdivs");
 }
 
 /// PPCTargetInfo::getTargetDefines - Return a set of the PowerPC-specific

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index fe532a7d2498..c7dcde149a15 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -16077,7 +16077,7 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned 
BuiltinID,
*this, E, Intrinsic::sqrt,
Intrinsic::experimental_constrained_sqrt))
 .getScalarVal();
-  case PPC::BI__builtin_ppc_test_data_class:
+  case PPC::BI__builtin_ppc_test_data_class: {
 llvm::Type *ArgType = EmitScalarExpr(E->getArg(0))->getType();
 unsigned IntrinsicID;
 if (ArgType->isDoubleTy())
@@ -16089,6 +16089,10 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned 
BuiltinID,
 return Builder.CreateCall(CGM.getIntrinsic(IntrinsicID), Ops,
   "test_data_class");
   }
+  case PPC::BI__builtin_ppc_swdiv:
+  case PPC::BI__builtin_ppc_swdivs:
+return Builder.CreateFDiv(Ops[0], Ops[1], "swdiv");
+  }
 }
 
 namespace {

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
new file mode 100644
index ..33b3f149664b
--- /dev/null
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
@@ -0,0 +1,80 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -ffast-math 
-ffp-contract=fast \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s --check-prefix 
CHECK-OFAST
+
+extern double a;
+extern double b;
+extern float c;
+extern float d;
+
+// CHECK-LABEL:   @test_swdiv(
+// CHECK: [[TMP0:%.*]] = load double, double* @a
+// CHECK-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-NEXT:[[SWDIV:%.*]] = fdiv double [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret double [[SWDIV]]
+//
+// CHECK-OFAST-LABEL:   @test_swdiv(
+// CHECK-OFAST: [[TMP0:%.*]] = load double, double* @a
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-OFAST-NEXT:[[SWDIV:%.*]] = f

[PATCH] D106959: [PowerPC] swdiv builtins for XL compatibility

2021-09-29 Thread Quinn Pham via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG67a3d1e27551: [PowerPC] swdiv builtins for XL compatibility 
(authored by quinnp).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106959/new/

https://reviews.llvm.org/D106959

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
  llvm/test/CodeGen/PowerPC/fdiv.ll

Index: llvm/test/CodeGen/PowerPC/fdiv.ll
===
--- llvm/test/CodeGen/PowerPC/fdiv.ll
+++ llvm/test/CodeGen/PowerPC/fdiv.ll
@@ -23,3 +23,16 @@
   %3 = fdiv contract reassoc arcp nsz ninf float %0, %1
   ret float %3
 }
+
+define dso_local float @fdiv_fast(float %0, float %1) local_unnamed_addr {
+; CHECK-LABEL: fdiv_fast:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:xsresp 3, 2
+; CHECK-NEXT:xsmulsp 0, 1, 3
+; CHECK-NEXT:xsnmsubasp 1, 2, 0
+; CHECK-NEXT:xsmaddasp 0, 3, 1
+; CHECK-NEXT:fmr 1, 0
+; CHECK-NEXT:blr
+  %3 = fdiv fast float %0, %1
+  ret float %3
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-swdiv.c
@@ -0,0 +1,80 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux-gnu \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-linux-gnu -ffast-math -ffp-contract=fast \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s --check-prefix CHECK-OFAST
+
+extern double a;
+extern double b;
+extern float c;
+extern float d;
+
+// CHECK-LABEL:   @test_swdiv(
+// CHECK: [[TMP0:%.*]] = load double, double* @a
+// CHECK-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-NEXT:[[SWDIV:%.*]] = fdiv double [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret double [[SWDIV]]
+//
+// CHECK-OFAST-LABEL:   @test_swdiv(
+// CHECK-OFAST: [[TMP0:%.*]] = load double, double* @a
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-OFAST-NEXT:[[SWDIV:%.*]] = fdiv fast double [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret double [[SWDIV]]
+//
+double test_swdiv() {
+  return __swdiv(a, b);
+}
+
+// CHECK-LABEL:   @test_swdivs(
+// CHECK: [[TMP0:%.*]] = load float, float* @c
+// CHECK-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-NEXT:[[SWDIVS:%.*]] = fdiv float [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret float [[SWDIVS]]
+//
+// CHECK-OFAST-LABEL:   @test_swdivs(
+// CHECK-OFAST: [[TMP0:%.*]] = load float, float* @c
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-OFAST-NEXT:[[SWDIVS:%.*]] = fdiv fast float [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret float [[SWDIVS]]
+//
+float test_swdivs() {
+  return __swdivs(c, d);
+}
+
+// CHECK-LABEL:   @test_builtin_ppc_swdiv(
+// CHECK: [[TMP0:%.*]] = load double, double* @a
+// CHECK-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-NEXT:[[SWDIV:%.*]] = fdiv double [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret double [[SWDIV]]
+//
+// CHECK-OFAST-LABEL:   @test_builtin_ppc_swdiv(
+// CHECK-OFAST: [[TMP0:%.*]] = load double, double* @a
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load double, double* @b
+// CHECK-OFAST-NEXT:[[SWDIV:%.*]] = fdiv fast double [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret double [[SWDIV]]
+//
+double test_builtin_ppc_swdiv() {
+  return __builtin_ppc_swdiv(a, b);
+}
+
+// CHECK-LABEL:   @test_builtin_ppc_swdivs(
+// CHECK: [[TMP0:%.*]] = load float, float* @c
+// CHECK-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-NEXT:[[SWDIVS:%.*]] = fdiv float [[TMP0]], [[TMP1]]
+// CHECK-NEXT:ret float [[SWDIVS]]
+//
+// CHECK-OFAST-LABEL:   @test_builtin_ppc_swdivs(
+// CHECK-OFAST: [[TMP0:%.*]] = load float, float* @c
+// CHECK-OFAST-NEXT:[[TMP1:%.*]] = load float, float* @d
+// CHECK-OFAST-NEXT:[[SWDIVS:%.*]] = fdiv fast float [[TMP0]], [[TMP1]]
+// CHECK-OFAST-NEXT:ret float [[SWDIVS]]
+//
+float test_builtin_ppc_swdivs() {
+  return __builtin_ppc_swdivs(c, d);
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -16077,7 +16077,7 @@
*this, E, Intrinsic::sqrt,
Intrinsic::experime

[PATCH] D110482: [clang] Implement if consteval (P1938)

2021-09-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 375927.
cor3ntin marked 20 inline comments as done.
cor3ntin added a comment.

- Add Bytecode gen tests
- use consteval if consistently
- use isConsteval/isNegatedConsteval/istNonNegatedConsteval
- Address other comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110482/new/

https://reviews.llvm.org/D110482

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/Stmt.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Analysis/CFG.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprMember.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
  clang/test/AST/Interp/if_consteval.cpp
  clang/test/AST/ast-dump-if-json.cpp
  clang/test/AST/ast-dump-stmt.cpp
  clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
  clang/test/CodeGenCXX/cxx2b-consteval-if.cpp

Index: clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -o - | FileCheck %s
+
+void should_be_used_1();
+void should_be_used_2();
+void should_be_used_3();
+constexpr void should_not_be_used() {}
+
+constexpr void f() {
+  if consteval {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  } else {
+should_be_used_1();  // CHECK: call {{.*}}should_be_used_1
+  }
+
+  if !consteval {
+should_be_used_2();  // CHECK: call {{.*}}should_be_used_2
+  }
+
+  if !consteval {
+should_be_used_3();  // CHECK: call {{.*}}should_be_used_3
+  } else {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  }
+}
+
+void g() {
+  f();
+}
Index: clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
===
--- /dev/null
+++ clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
@@ -0,0 +1,147 @@
+// RUN: %clang_cc1 -std=c++2b -verify %s
+
+void test_consteval() {
+  if consteval (void) 0; // expected-error {{expected { after consteval}}
+  if consteval {
+(void)0;
+  } else (void)0; // expected-error {{expected { after else}}
+
+  static_assert([] {
+if consteval {
+  return 0;
+}
+return 1;
+  }() == 0);
+
+  static_assert([] {
+if consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 0);
+
+  static_assert([] {
+if !consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 1);
+
+  static_assert([] {
+if not consteval {
+  return 0;
+}
+return 1;
+  }() == 1);
+}
+
+void test_consteval_jumps() {
+  if consteval { // expected-note 4{{jump enters controlled statement of consteval if}}
+goto a;
+goto b; // expected-error {{cannot jump from this goto statement to its label}}
+  a:;
+  } else {
+goto b;
+goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  b:;
+  }
+  goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  goto b; // expected-error {{cannot jump from this goto statement to its label}}
+}
+
+void test_consteval_switch() {
+  int x = 42;
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+case 1:;   // expected-error {{cannot jump from switch statement to this case label}}
+default:;  // expected-error {{cannot jump from switch statement to this case label}}
+} else {
+}
+  }
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+} else {
+case 2:;  // expected-error {{cannot jump from switch statement to this case label}}
+default:; // expected-error {{cannot jump from switch statement to this case label}}
+}
+  }
+}
+
+consteval int f(int i) { return i; }
+constexpr int g(int i) {
+  if consteval {
+return f(i);
+  } else {
+return 42;
+  }
+}
+static_assert(g(10) == 10);
+
+constexpr int h(int i) { // expected-note {{declared here}}
+  if !consteval {
+return f(i); // expected-error {{call to consteval function 'f' is not a constant expression}}\
+ // expected-note

[PATCH] D110482: [clang] Implement if consteval (P1938)

2021-09-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeStmtGen.cpp:195
+  if (IS->isNegatedConsteval())
+return IS->getElse();
+

aaron.ballman wrote:
> This probably signals that we're missing some test coverage, but this is the 
> first I've heard of this file so I'm not clear on *how* to test it!
Ouch, nasty! I added tests



Comment at: clang/lib/AST/StmtPrinter.cpp:242
+if(If->isNegatedConsteval())
+OS << "!";
+OS << "consteval";

erichkeane wrote:
> You had a choice here You COULD have blessed the 'c++ operator names', 
> but chose not to.  I guess we all have to choose teams:D 
I could have :)
Also, it's easier to see that the `!` appertain to `consteval`



Comment at: clang/lib/Parse/ParseStmt.cpp:1449
+Sema::ExpressionEvaluationContextRecord::EK_Other, ShouldEnter);
 ThenStmt = ParseStatement(&InnerStatementTrailingElseLoc);
   }

aaron.ballman wrote:
> This looks incorrect for a consteval if -- that requires parsing a compound 
> statement explicitly, not just any statement.
See a little bit below



Comment at: clang/lib/Parse/ParseStmt.cpp:1520-1525
+  if (IsConsteval) {
+if (!isa_and_nonnull(ThenStmt.get())) {
+  Diag(ConstevalLoc, diag::err_expected_after) << "consteval"
+   << "{";
+  return StmtError();
+}

aaron.ballman wrote:
> Oh. I see where the diagnostic is happening. I think it's unclean to parse a 
> statement and then diagnose it later as being the wrong kind of statement -- 
> why not parse the correct kind of statement initially?
I think the code reads better that way - we need to parse any kind of statement 
in other cases. In any case the work is about the same



Comment at: clang/lib/Sema/SemaStmt.cpp:929
+  Diags.Report(IfLoc, diag::warn_if_consteval_always_true)
+  << (Immediate ? 1 : 0);
+}

aaron.ballman wrote:
> Conversions just work this way (http://eel.is/c++draft/conv.integral#2).
It just seemed more explicit



Comment at: clang/lib/Serialization/ASTReaderStmt.cpp:2756-2758
+  /* HasElse=*/Record[ASTStmtReader::NumStmtFields],
+  /* HasVar=*/Record[ASTStmtReader::NumStmtFields + 1],
+  /* HasInit=*/Record[ASTStmtReader::NumStmtFields + 2]);

aaron.ballman wrote:
> Can you explain these changes? I'm not certain why they were needed.
I could revert them back actually - I'm just storing the constexpr info after, 
which seems simpler


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110482/new/

https://reviews.llvm.org/D110482

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


[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

2021-09-29 Thread Wolfgang Pieb via Phabricator via cfe-commits
wolfgangp added a comment.

ping ...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109981/new/

https://reviews.llvm.org/D109981

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


[PATCH] D110622: [HIPSPV][3/4] Enable SPIR-V emission for HIP

2021-09-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

> A Cuda GPU architecture ‘generic’ is added. The name is picked from the LLVM 
> SPIR-V Backend. In the HIPSPV code path the architecture name is inserted to 
> the bundle entry ID as target ID. Target ID is expected to be always present 
> so a component in the target triple is not mistaken as target ID.

How generic is 'generic'? If I understand the statement above correctly, it 
should probably reflect that it's specific to spir-v.
If it's the only possible spir-v variant, then calling it`spir-v` might be more 
meaningful.
If we expect to see other spir-v variants in the future it would allow us to 
clearly differentiate between them later. 
E.g. `--offload=spirv-a,spirv-b`. It would be rather odd if we had to use 
`--offload=generic, spirv-b`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110622/new/

https://reviews.llvm.org/D110622

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


[PATCH] D110726: [clang] NFC: remove duplicated code around type constraint and templ arg subst

2021-09-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov created this revision.
mizvekov published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110726

Files:
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp

Index: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -2149,8 +2149,8 @@
 // Instantiate the explicit template arguments.
 TemplateArgumentListInfo ExplicitArgs(Info->getLAngleLoc(),
   Info->getRAngleLoc());
-if (SemaRef.Subst(Info->getTemplateArgs(), Info->getNumTemplateArgs(),
-  ExplicitArgs, TemplateArgs))
+if (SemaRef.SubstTemplateArguments(Info->arguments(), TemplateArgs,
+   ExplicitArgs))
   return nullptr;
 
 // Map the candidate templates to their instantiations.
@@ -2177,8 +2177,8 @@
 // Instantiate the explicit template arguments.
 TemplateArgumentListInfo ExplicitArgs(Info->getLAngleLoc(),
   Info->getRAngleLoc());
-if (SemaRef.Subst(Info->getTemplateArgs(), Info->getNumTemplateArgs(),
-  ExplicitArgs, TemplateArgs))
+if (SemaRef.SubstTemplateArguments(Info->arguments(), TemplateArgs,
+   ExplicitArgs))
   return nullptr;
 
 if (SemaRef.CheckFunctionTemplateSpecialization(Function,
@@ -2513,8 +2513,8 @@
 // Instantiate the explicit template arguments.
 TemplateArgumentListInfo ExplicitArgs(Info->getLAngleLoc(),
   Info->getRAngleLoc());
-if (SemaRef.Subst(Info->getTemplateArgs(), Info->getNumTemplateArgs(),
-  ExplicitArgs, TemplateArgs))
+if (SemaRef.SubstTemplateArguments(Info->arguments(), TemplateArgs,
+   ExplicitArgs))
   return nullptr;
 
 // Map the candidate templates to their instantiations.
@@ -2540,8 +2540,8 @@
 
 TemplateArgumentListInfo ExplicitArgs(Info->getLAngleLoc(),
   Info->getRAngleLoc());
-if (SemaRef.Subst(Info->getTemplateArgs(), Info->getNumTemplateArgs(),
-  ExplicitArgs, TemplateArgs))
+if (SemaRef.SubstTemplateArguments(Info->arguments(), TemplateArgs,
+   ExplicitArgs))
   return nullptr;
 
 if (SemaRef.CheckFunctionTemplateSpecialization(Method,
@@ -2709,25 +2709,7 @@
 
   // TODO: Concepts: do not instantiate the constraint (delayed constraint
   // substitution)
-  const ASTTemplateArgumentListInfo *TemplArgInfo
-= TC->getTemplateArgsAsWritten();
-  TemplateArgumentListInfo InstArgs;
-
-  if (TemplArgInfo) {
-InstArgs.setLAngleLoc(TemplArgInfo->LAngleLoc);
-InstArgs.setRAngleLoc(TemplArgInfo->RAngleLoc);
-if (SemaRef.Subst(TemplArgInfo->getTemplateArgs(),
-  TemplArgInfo->NumTemplateArgs,
-  InstArgs, TemplateArgs))
-  return nullptr;
-  }
-  if (SemaRef.AttachTypeConstraint(
-  TC->getNestedNameSpecifierLoc(), TC->getConceptNameInfo(),
-  TC->getNamedConcept(), &InstArgs, Inst,
-  D->isParameterPack()
-  ? cast(TC->getImmediatelyDeclaredConstraint())
-  ->getEllipsisLoc()
-  : SourceLocation()))
+  if (SemaRef.SubstTypeConstraint(Inst, TC, TemplateArgs))
 return nullptr;
 }
   }
@@ -3625,8 +3607,7 @@
   SmallVector ArgLocs;
   for (unsigned I = 0; I != Loc.getNumArgs(); ++I)
 ArgLocs.push_back(Loc.getArgLoc(I));
-  if (SemaRef.Subst(ArgLocs.data(), ArgLocs.size(),
-InstTemplateArgs, TemplateArgs))
+  if (SemaRef.SubstTemplateArguments(ArgLocs, TemplateArgs, InstTemplateArgs))
 return nullptr;
 
   // Check that the template argument list is well-formed for this
@@ -3751,8 +3732,8 @@
   VarTemplateArgsInfo.setLAngleLoc(TemplateArgsInfo.getLAngleLoc());
   VarTemplateArgsInfo.setRAngleLoc(TemplateArgsInfo.getRAngleLoc());
 
-  if (SemaRef.Subst(TemplateArgsInfo.getArgumentArray(),
-TemplateArgsInfo.size(), VarTemplateArgsInfo, TemplateArgs))
+  if (SemaRef.SubstTemplateArguments(TemplateArgsInfo.arguments(), TemplateArgs,
+ VarTemplateArgsInfo))
 return nullptr;
 
   // Check that the template argument list is well-formed for this template.
@@ -4019,9 +4000,8 @@
 = PartialSpec->getTemplateArgsAsWritten();
   TemplateArg

[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

2021-09-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/include/clang/Driver/Options.td:3701
   " do not include the default CUDA/HIP wrapper headers">;
+def nohipwrapperinc : Flag<["-"], "nohipwrapperinc">,
+  HelpText<"Do not include the default HIP wrapper headers">;

Is the idea to still add relevant include paths to the wrappers and SDK 
headers, but not `-include` the wrapper?

If that's the case, it should probably be generalized into `-nogpuwrapperinc` 
and apply to both CUDA and HIP.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110618/new/

https://reviews.llvm.org/D110618

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


[PATCH] D105759: [WIP] Implement P2361 Unevaluated string literals

2021-09-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 375940.
cor3ntin added a comment.

Cleanup Diagnostics In LiteralSupport


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105759/new/

https://reviews.llvm.org/D105759

Files:
  clang-tools-extra/test/clang-tidy/checkers/modernize-unary-static-assert.cpp
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/test/CXX/dcl.dcl/dcl.link/p2.cpp
  clang/test/CXX/dcl.dcl/p4-0x.cpp
  clang/test/FixIt/fixit-static-assert.cpp
  clang/test/Parser/asm.c
  clang/test/Parser/asm.cpp
  clang/test/Parser/attr-availability-xcore.c
  clang/test/Parser/attr-availability.c
  clang/test/Sema/asm.c
  clang/test/SemaCXX/static-assert.cpp

Index: clang/test/SemaCXX/static-assert.cpp
===
--- clang/test/SemaCXX/static-assert.cpp
+++ clang/test/SemaCXX/static-assert.cpp
@@ -28,12 +28,15 @@
 S s1; // expected-note {{in instantiation of template class 'S' requested here}}
 S s2;
 
-static_assert(false, L"\x"); // expected-error {{static_assert failed L"\x"}}
-static_assert(false, u"\U000317FF"); // expected-error {{static_assert failed u"\U000317FF"}}
+static_assert(false, L"\x"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, u"\U000317FF"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
 // FIXME: render this as u8"\u03A9"
-static_assert(false, u8"Ω"); // expected-error {{static_assert failed u8"\316\251"}}
-static_assert(false, L"\u1234"); // expected-error {{static_assert failed L"\x1234"}}
-static_assert(false, L"\x1ff" "0\x123" "fx\xf" "goop"); // expected-error {{static_assert failed L"\x1FF""0\x123""fx\xFgoop"}}
+static_assert(false, u8"Ω"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, L"\u1234"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, L"\x1ff"// expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+ "0\x123"
+ "fx\xf"
+ "goop");
 
 template struct AlwaysFails {
   // Only give one error here.
Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -37,14 +37,19 @@
   asm ("nop" : "=c" (a) : "r" (no_clobber_conflict) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
   asm ("nop" : "=r" (no_clobber_conflict) : "c" (c) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
   asm ("nop" : "=r" (clobber_conflict) : "c" (c) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
-  asm ("nop" : "=a" (a) : "b" (b) : "%rcx", "%rbx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}} 
+  asm("nop"
+  : "=a"(a)
+  : "b"(b)
+  : "%rcx", "%rbx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
 }
 
 // rdar://6094010
 void test3() {
   int x;
-  asm(L"foo" : "=r"(x)); // expected-error {{wide string}}
-  asm("foo" : L"=r"(x)); // expected-error {{wide string}}
+  asm(L"foo" // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+  : "=r"(x));
+  asm("foo"
+  : L"=r"(x)); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
 }
 
 // 
Index: clang/test/Parser/attr-availability.c
===
--- clang/test/Parser/attr-availability.c
+++ clang/test/Parser/attr-availability.c
@@ -18,23 +18,26 @@
 
 void f6() __attribute__((availability(macosx,unavailable,introduced=10.5))); // expected-warning{{'unavailable' availability overrides all other availability information}}
 
-void f7() __attribute__((availability(macosx,message=L"wide"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
+void f7() __attribute__((availabili

[PATCH] D110485: Support [[no_unique_address]] for all targets.

2021-09-29 Thread cqwrteur via Phabricator via cfe-commits
expnkx added a comment.

clang simply just does not truly support everything msvc supports. There are no 
things that deals [[msvc::]] attributes at all in the clang. In fact the point 
of using clang on windows is that we do not want to do the same as Microsoft 
does.

Support [[no_unique_address]] is nothing wrong tbh and that is what ISO C++ 
standard requires.

If we do not change, the Microsoft team won't wanna change either because they 
are afraid of breaking clang too.

I never understand why [[no_unique_address]] is a problem.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110485/new/

https://reviews.llvm.org/D110485

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


[clang] b2de52b - [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-09-29T13:14:23-04:00
New Revision: b2de52bec17b67887456ede40ac7c6959ce26d6a

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

LOG: [clang-cl] Accept `#pragma warning(disable : N)` for some N

clang-cl maps /wd to -Wno-flags for a few warnings that map
cleanly from cl.exe concepts to clang concepts.

This patch adds support for the same numbers to
`#pragma warning(disable : )`. It also lets
`#pragma warning(push)` and `#pragma warning(pop)` have an effect,
since these are used together with `warning(disable)`.

The optional numeric argument to `warning(push)` is ignored,
as are the other non-`disable` `pragma warning()` arguments.
(Supporting `error` would be easy, but we also don't support
`/we`, and those should probably be added together.)

The motivating example is that a bunch of code (including in LLVM)
uses this idiom to locally disable warnings about calls to deprecated
functions in Windows-only code, and 4996 maps nicely to
-Wno-deprecated-declarations:

#pragma warning(push)
#pragma warning(disable: 4996)
  f();
#pragma warning(pop)

Implementation-wise:
- Move `/wd` flag handling from Options.td to actual Driver-level code
- Extract the function mapping cl.exe IDs to warning groups to the
  new file clang/lib/Basic/CLWarnings.cpp
- Create a diag::Group enum so that CLWarnings.cpp can refer to
  existing groups by ID (and give DllexportExplicitInstantiationDecl
  a named group), and add a function to map a diag::Group to the
  spelling of it's associated commandline flag
- Call that new function from PragmaWarningHandler

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

Added: 
clang/include/clang/Basic/CLWarnings.h
clang/lib/Basic/CLWarnings.cpp
clang/test/Sema/pragma-warning.cpp

Modified: 
clang/include/clang/Basic/Diagnostic.h
clang/include/clang/Basic/DiagnosticCategories.h
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticIDs.h
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Basic/CMakeLists.txt
clang/lib/Basic/Diagnostic.cpp
clang/lib/Basic/DiagnosticIDs.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Lex/Pragma.cpp
clang/test/Driver/cl-options.c
clang/tools/diagtool/DiagnosticNames.cpp
clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Removed: 




diff  --git a/clang/include/clang/Basic/CLWarnings.h 
b/clang/include/clang/Basic/CLWarnings.h
new file mode 100644
index 0..e3351f430c437
--- /dev/null
+++ b/clang/include/clang/Basic/CLWarnings.h
@@ -0,0 +1,26 @@
+//===--- CLWarnings.h - Maps some cl.exe warning ids  ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_BASIC_CLWARNINGS_H
+#define LLVM_CLANG_BASIC_CLWARNINGS_H
+
+#include "llvm/ADT/Optional.h"
+
+namespace clang {
+
+namespace diag {
+enum class Group;
+}
+
+/// For cl.exe warning IDs that cleany map to clang diagnostic groups,
+/// returns the corresponding group. Else, returns an empty Optional.
+llvm::Optional diagGroupFromCLWarningID(unsigned);
+
+} // end namespace clang
+
+#endif // LLVM_CLANG_BASIC_CLWARNINGS_H

diff  --git a/clang/include/clang/Basic/Diagnostic.h 
b/clang/include/clang/Basic/Diagnostic.h
index 3b915fb15a891..efb725845d3e8 100644
--- a/clang/include/clang/Basic/Diagnostic.h
+++ b/clang/include/clang/Basic/Diagnostic.h
@@ -807,6 +807,9 @@ class DiagnosticsEngine : public 
RefCountedBase {
   bool setSeverityForGroup(diag::Flavor Flavor, StringRef Group,
diag::Severity Map,
SourceLocation Loc = SourceLocation());
+  bool setSeverityForGroup(diag::Flavor Flavor, diag::Group Group,
+   diag::Severity Map,
+   SourceLocation Loc = SourceLocation());
 
   /// Set the warning-as-error flag for the given diagnostic group.
   ///

diff  --git a/clang/include/clang/Basic/DiagnosticCategories.h 
b/clang/include/clang/Basic/DiagnosticCategories.h
index 0decf15080a0c..2bbdeb31a7b7d 100644
--- a/clang/include/clang/Basic/DiagnosticCategories.h
+++ b/clang/include/clang/Basic/DiagnosticCategories.h
@@ -19,6 +19,13 @@ namespace clang {
 #undef GET_CATEGORY_TABLE
   DiagCat_NUM_CATEGORIES
 };
+
+enum class Group {
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups) GroupName,
+#include "clang/Basic/DiagnosticGr

[PATCH] D110668: [clang-cl] Accept `#pragma warning(disable : N)` for some N

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
thakis marked an inline comment as done.
Closed by commit rGb2de52bec17b: [clang-cl] Accept `#pragma warning(disable : 
N)` for some N (authored by thakis).

Changed prior to commit:
  https://reviews.llvm.org/D110668?vs=375891&id=375942#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110668/new/

https://reviews.llvm.org/D110668

Files:
  clang/include/clang/Basic/CLWarnings.h
  clang/include/clang/Basic/Diagnostic.h
  clang/include/clang/Basic/DiagnosticCategories.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticIDs.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/CLWarnings.cpp
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Diagnostic.cpp
  clang/lib/Basic/DiagnosticIDs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Lex/Pragma.cpp
  clang/test/Driver/cl-options.c
  clang/test/Sema/pragma-warning.cpp
  clang/tools/diagtool/DiagnosticNames.cpp
  clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
  llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -55,6 +55,7 @@
   sources = [
 "Attributes.cpp",
 "Builtins.cpp",
+"CLWarnings.cpp",
 "CharInfo.cpp",
 "CodeGenOptions.cpp",
 "Cuda.cpp",
Index: clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
===
--- clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -129,6 +129,7 @@
   };
 
   struct GroupInfo {
+llvm::StringRef GroupName;
 std::vector DiagsInGroup;
 std::vector SubGroups;
 unsigned IDNo;
@@ -174,6 +175,7 @@
 Record *Group = DiagGroups[i];
 GroupInfo &GI =
 DiagsInGroup[std::string(Group->getValueAsString("GroupName"))];
+GI.GroupName = Group->getName();
 GI.Defs.push_back(Group);
 
 std::vector SubGroups = Group->getValueAsListOfDefs("SubGroups");
@@ -1279,8 +1281,8 @@
 OS << ", \"";
 OS.write_escaped(DiagTextBuilder.buildForDefinition(&R)) << '"';
 
-// Warning associated with the diagnostic. This is stored as an index into
-// the alphabetically sorted warning table.
+// Warning group associated with the diagnostic. This is stored as an index
+// into the alphabetically sorted warning group table.
 if (DefInit *DI = dyn_cast(R.getValueInit("Group"))) {
   std::map::iterator I = DiagsInGroup.find(
   std::string(DI->getDef()->getValueAsString("GroupName")));
@@ -1487,18 +1489,20 @@
   for (auto const &I: DiagsInGroup)
 MaxLen = std::max(MaxLen, (unsigned)I.first.size());
 
-  OS << "\n#ifdef GET_DIAG_TABLE\n";
+  OS << "\n#ifdef DIAG_ENTRY\n";
   unsigned SubGroupIndex = 1, DiagArrayIndex = 1;
   for (auto const &I: DiagsInGroup) {
 // Group option string.
-OS << "  { /* ";
+OS << "DIAG_ENTRY(";
+OS << I.second.GroupName << " /* ";
+
 if (I.first.find_first_not_of("abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789!@#$%^*-+=:?") !=
 std::string::npos)
   PrintFatalError("Invalid character in diagnostic group '" + I.first +
   "'");
-OS << I.first << " */ " << std::string(MaxLen - I.first.size(), ' ');
+OS << I.first << " */, ";
 // Store a pascal-style length byte at the beginning of the string.
 std::string Name = char(I.first.size()) + I.first;
 OS << GroupNames.GetOrAddStringOffset(Name, false) << ", ";
@@ -1517,7 +1521,7 @@
 DiagArrayIndex += DiagsInPedantic.size();
   DiagArrayIndex += V.size() + 1;
 } else {
-  OS << "/* Empty */ 0, ";
+  OS << "0, ";
 }
 
 // Subgroups.
@@ -1530,12 +1534,12 @@
 SubGroupIndex += GroupsInPedantic.size();
   SubGroupIndex += SubGroups.size() + 1;
 } else {
-  OS << "/* Empty */ 0";
+  OS << "0";
 }
 
-OS << " },\n";
+OS << " )\n";
   }
-  OS << "#endif // GET_DIAG_TABLE\n\n";
+  OS << "#endif // DIAG_ENTRY\n\n";
 }
 
 /// Emit the table of diagnostic categories.
Index: clang/tools/diagtool/DiagnosticNames.cpp
===
--- clang/tools/diagtool/DiagnosticNames.cpp
+++ clang/tools/diagtool/DiagnosticNames.cpp
@@ -66,9 +66,10 @@
 
 // Second the table of options, sorted by name for fast binary lookup.
 static const GroupRecord OptionTable[] = {
-#define GET_DIAG_TABLE
+#define DIAG_ENTRY(GroupName, FlagNameOffset, Members, SubGroups)  \
+  {FlagNameOffset, Members, SubGroups},

[PATCH] D110485: Support [[no_unique_address]] for all targets.

2021-09-29 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D110485#3030853 , @expnkx wrote:

> clang simply just does not truly support everything msvc supports. There are 
> no things that deals [[msvc::]] attributes at all in the clang. In fact the 
> point of using clang on windows is that we do not want to do the same as 
> Microsoft does.
>
> Support [[no_unique_address]] is nothing wrong tbh and that is what ISO C++ 
> standard requires.
>
> If we do not change, the Microsoft team won't wanna change either because 
> they are afraid of breaking clang too.
>
> I never understand why [[no_unique_address]] is a problem.

A requirement of Clang on Windows is that we are ABI compatible (so that we can 
link between them!), the same way that Linux must match the Itanium ABI.  
Allowing no_unique_address on Windows is an ABI compatibility issue.  In this 
case, we have to pay attention to what the platform's ABI OWNERS define as the 
ABI, which in this case is Microsoft.

THAT is why this is a problem, and THAT is what is wrong with this change.

If Microsoft defines an ABI for what this does, we can follow them and just do 
that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110485/new/

https://reviews.llvm.org/D110485

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


[PATCH] D105759: [WIP] Implement P2361 Unevaluated string literals

2021-09-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from two small nits. As for the modules question, if @rsmith doesn't 
get back to us, I think it's fine to address that post-commit.




Comment at: clang/include/clang/Lex/LiteralSupport.h:233
+  ArrayRef StringToks, Preprocessor &PP,
+  StringLiteralKind StringKind = StringLiteralKind::Evaluated);
+  StringLiteralParser(ArrayRef StringToks, const SourceManager &sm,

aaron.ballman wrote:
> We should rename anything mentioning `StringKind` similarly -- this will also 
> help avoid confusion with the `StringKind` type in Expr.h.
Did this one get missed?



Comment at: clang/test/CXX/dcl.dcl/p4-0x.cpp:24
+ R"x(")x");
\ No newline at end of file


Can you add the newline back to the end of the file?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105759/new/

https://reviews.llvm.org/D105759

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


[clang] d7ae434 - [Driver] Check that short triples are supported for Fuchsia

2021-09-29 Thread Petr Hosek via cfe-commits

Author: Petr Hosek
Date: 2021-09-29T10:35:40-07:00
New Revision: d7ae43438a04bcb651ede50c19042e08514bf729

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

LOG: [Driver] Check that short triples are supported for Fuchsia

{x86_64,aarch64}-unknown-fuchsia and {x86_64,aarch64}-fuchsia should
behave identically as targets, update the test to make sure that's the
case.

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

Added: 


Modified: 
clang/test/Driver/fuchsia.c
clang/test/Driver/fuchsia.cpp

Removed: 




diff  --git a/clang/test/Driver/fuchsia.c b/clang/test/Driver/fuchsia.c
index b0eb78b7e755..926594da95c3 100644
--- a/clang/test/Driver/fuchsia.c
+++ b/clang/test/Driver/fuchsia.c
@@ -10,6 +10,18 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"

diff  --git a/clang/test/Driver/fuchsia.cpp b/clang/test/Driver/fuchsia.cpp
index bd4c7ebeb560..7d2e342f72e6 100644
--- a/clang/test/Driver/fuchsia.cpp
+++ b/clang/test/Driver/fuchsia.cpp
@@ -13,6 +13,21 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"



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


[PATCH] D110687: [Driver] Check that short triples are supported for Fuchsia

2021-09-29 Thread Petr Hosek via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd7ae43438a04: [Driver] Check that short triples are 
supported for Fuchsia (authored by phosek).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110687/new/

https://reviews.llvm.org/D110687

Files:
  clang/test/Driver/fuchsia.c
  clang/test/Driver/fuchsia.cpp


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -13,6 +13,21 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"
Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang/test/Driver/fuchsia.c
@@ -10,6 +10,18 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clang %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -13,6 +13,21 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
+// RUN: %clangxx %s -### -no-canonical-prefixes --target=riscv64-fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
+// RUN: | FileCheck -check-prefixes=CHECK,CHECK-RISCV64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK-X86_64: "-triple" "x86_64-unknown-fuchsia"
 // CHECK-AARCH64: "-triple" "aarch64-unknown-fuchsia"
Index: clang/test/Driver/fuchsia.c
===
--- clang/test/Driver/fuchsia.c
+++ clang

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

2021-09-29 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis added a comment.

In D102107#3029825 , @pdhaliwal wrote:

> Apologies for late reply. Most of the tests now do not try to call malloc, so 
> no page fault errors. But all of them are producing wrong results. For e.g. 
> declare_mapper_target.cpp produces Sum = 132608 with the patch applied. 
> Similarly for other tests as well. So don't know what's happening yet.

Thanks @pdhaliwal. I get the right result on nvidia. Please let me know when 
you get to the bottom of it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102107/new/

https://reviews.llvm.org/D102107

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


[PATCH] D110622: [HIPSPV][3/4] Enable SPIR-V emission for HIP

2021-09-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

> --offload’ option, which is envisioned in [1], is added for specifying 
> offload targets. This option is used to override default device target 
> (amdgcn-amd-amdhsa) for HIP compilation for emitting device code as SPIR-V 
> binary. The option is handled in getHIPOffloadTargetTriple().

Can you elaborate on what exactly this option does and how it's intended to 
interact with the existing `--offload-arch`?

In general a list of values, combined with the `getLastArg` will potentially be 
an issue if/when more than one list value will be supported.
In a large build it's fairly common for the build infrastructure to set the 
default options and allowing users to extend/override them with *additional* 
options. `getLastArg` works great for scalar options, not so much for the lists.
If an option is a list, modifying it requires prior knowledge of preceding 
values and that may not always be easy.
E.g. a build configuration may be set to  target gfx900 and gfx908. If I want 
to *add* an option to target gfx1030, I would need to dig out the options for 
the currently-enabled architectures and specify all of them again. It's doable 
once, manually, but it does not scale if this option is expected to be 
regularly tweaked by the end user, as is the case with `--offload-arch`. If 
`--offload` is expected to have similar use patterns, you may need to consider 
allowing it to be adjusted per-list-element.




Comment at: clang/include/clang/Basic/Cuda.h:106
 static inline bool IsAMDGpuArch(CudaArch A) {
   return A >= CudaArch::GFX600 && A < CudaArch::LAST;
 }

Does this need to be adjusted to exclude SPIR-V? If so, you may want to add 
another enum range for SPIR-V.




Comment at: clang/include/clang/Driver/Options.td:1136
+def offload_EQ : CommaJoined<["--"], "offload=">, Flags<[NoXarchOption]>,
+  HelpText<"Specify comma-separated list of offloading targets.">;
+

`comma-separated list of offloading targets.` is, unfortunately, somewhat 
ambiguous.
Does it mean "how the offload will be done". I.e. HSA, OpenMP, SPIRV, CUDA? 
Or does it mean specific hardware we need to generate the code for? 
The code suggests it's a variant of the former, but the option description does 
not. 

E.g. `offload_arch_EQ ` also uses the term "offloading target" but with a 
different meaning.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110622/new/

https://reviews.llvm.org/D110622

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


[PATCH] D110665: [clang] Don't use the AST to display backend diagnostics

2021-09-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 375958.
aeubanks added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110665/new/

https://reviews.llvm.org/D110665

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/Frontend/backend-diagnostic.c
  clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
  clang/test/Misc/backend-stack-frame-diagnostics.cpp

Index: clang/test/Misc/backend-stack-frame-diagnostics.cpp
===
--- clang/test/Misc/backend-stack-frame-diagnostics.cpp
+++ clang/test/Misc/backend-stack-frame-diagnostics.cpp
@@ -26,7 +26,7 @@
 
 void frameSizeWarning();
 
-void frameSizeWarning() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in function 'frameSizeWarning'}}
+void frameSizeWarning() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in 'frameSizeWarning()'}}
   char buffer[80];
   doIt(buffer);
 }
@@ -45,7 +45,7 @@
 
 void frameSizeLocalClassWarning() {
   struct S {
-S() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in function 'frameSizeLocalClassWarning()::S::S'}}
+S() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in 'frameSizeLocalClassWarning()::S::S()'}}
   char buffer[80];
   doIt(buffer);
 }
@@ -55,7 +55,7 @@
 
 void frameSizeLambdaWarning() {
   auto fn =
-  []() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in lambda expression}}
+  []() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in 'frameSizeLambdaWarning()::$_0::operator()() const'}}
 char buffer[80];
 doIt(buffer);
   };
@@ -64,7 +64,7 @@
 
 void frameSizeBlocksWarning() {
   auto fn =
-  ^() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in block literal}}
+  ^() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in 'invocation function for block in frameSizeBlocksWarning()'}}
 char buffer[80];
 doIt(buffer);
   };
Index: clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
===
--- clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
+++ clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
@@ -12,7 +12,7 @@
 virtual void f();
   };
 
-  // CHECK: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in function 'frameSizeThunkWarning::B::f'
+  // CHECK: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in 'frameSizeThunkWarning::B::f()'
   // CHECK: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in function '_ZTv0_n12_N21frameSizeThunkWarning1B1fEv'
   void B::f() {
 volatile int x = 0; // Ensure there is stack usage.
Index: clang/test/Frontend/backend-diagnostic.c
===
--- clang/test/Frontend/backend-diagnostic.c
+++ clang/test/Frontend/backend-diagnostic.c
@@ -15,9 +15,9 @@
 
 extern void doIt(char *);
 
-// REGULAR: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in function 'stackSizeWarning'
-// PROMOTE: error: stack frame size ([[#]]) exceeds limit ([[#]]) in function 'stackSizeWarning'
-// IGNORE-NOT: stack frame size ([[#]]) exceeds limit ([[#]]) in function 'stackSizeWarning'
+// REGULAR: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in 'stackSizeWarning'
+// PROMOTE: error: stack frame size ([[#]]) exceeds limit ([[#]]) in 'stackSizeWarning'
+// IGNORE-NOT: stack frame size ([[#]]) exceeds limit ([[#]]) in 'stackSizeWarning'
 void stackSizeWarning() {
   char buffer[80];
   doIt(buffer);
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -25,6 +25,7 @@
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
 #include "clang/Lex/Preprocessor.h"
+#include "llvm/ADT/Hashing.h"
 #include "llvm/Bitcode/BitcodeReader.h"
 #include "llvm/CodeGen/MachineOptimizationRemarkEmitter.h"
 #include "llvm/Demangle/Demangle.h"
@@ -125,6 +126,8 @@
 std::unique_ptr Gen;
 
 SmallVector LinkModules;
+std::vector>
+ManglingFullSourceLocs;
 
 // This is here so that the diagnostic printer knows the module a diagnostic
 // refers to.
@@ -330,6 +333,14 @@
   if (LinkInModules())
 return;
 
+  for (auto &F : getModule()->functions()) {
+if (const Decl *FD = Gen->GetDeclForMangledName(F.getName())) {
+  auto Loc = FD->getASTContext().getFullLoc(FD->getLocation());
+  auto NameHash = llvm::hash_value(F.getName());
+  ManglingFullSourceLocs.push_back(std::make_pair

[PATCH] D110665: [clang] Don't use the AST to display backend diagnostics

2021-09-29 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added inline comments.



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:336-337
 
+  for (auto &F : getModule()->functions()) {
+if (const Decl *FD = Gen->GetDeclForMangledName(F.getName())) {
+  auto Loc = FD->getASTContext().getFullLoc(FD->getLocation());

dblaikie wrote:
> Could we record these earlier, partly to avoid having to do the lookup by 
> mangled name here? (eg: when the function's created instead)
We don't know if a function will be emitted into the IR when creating its AST 
node. And `GetDeclForMangledName` may not work if we haven't fully constructed 
the AST yet (not sure about this, but this would definitely require a lot of 
frontend knowledge).



Comment at: clang/lib/CodeGen/CodeGenAction.cpp:642-645
+  for (auto &Pair : ManglingFullSourceLocs) {
+if (Pair.first == Hash)
+  return Pair.second;
+  }

dblaikie wrote:
> Not worth doing anything faster (hash table, etc)?
> 
> If it's going to stay linear - could use `llvm::find_if` perhaps - though I 
> realize it doesn't add a /huge/ amount of value here.
> 
> If it's going to stay with the explicit loop, the Pair reference should 
> probably be made const.
yeah, `find_if` doesn't really make it any easier to read/shorter

I'm trying to optimize for construction time, not reporting time since 
reporting warnings/errors is much rarer. Can't get much better than a vector.



Comment at: clang/test/Frontend/backend-diagnostic.c:18-20
+// REGULAR: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in 
stackSizeWarning
+// PROMOTE: error: stack frame size ([[#]]) exceeds limit ([[#]]) in 
stackSizeWarning
+// IGNORE-NOT: stack frame size ([[#]]) exceeds limit ([[#]]) in 
stackSizeWarning

dblaikie wrote:
> I'm surprised these and other warning updates don't show the signature of the 
> function, I'd have expected demangle to have returned something like 
> 'stackSizeWarning()' rather than just 'stackSizeWarning'?
> 
> (also it seems nice to retain the word "function" and quotation marks around 
> the function name in the diagnostic messages, I think? (could end up with 
> weird situations where simple function names could be confused with prose in 
> the error message))
I've added quotes.
For the word "function", sometimes the demangling prints out actual prose, e.g. 
in backend-stack-frame-diagnostics.cpp below, we have a `invocation function 
for block in frameSizeBlocksWarning()`, and adding "function" would print 
`function 'invocation function for block in frameSizeBlocksWarning()'`. Maybe 
that's fine since those are rarer, WDYT?
For C functions, I believe since there's no overloading, we don't print 
types/parentheses.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110665/new/

https://reviews.llvm.org/D110665

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


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-29 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 375960.
xbolva00 added a comment.
Herald added subscribers: sstefan1, s.egerton, simoncook, aheejin, dschuff.
Herald added a reviewer: jdoerfert.

Emit note to explain a user how to silence this warning.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108003/new/

https://reviews.llvm.org/D108003

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/p.patch
  clang/test/Sema/warn-bitwise-and-bool.c
  clang/test/Sema/warn-bitwise-or-bool.c

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


[PATCH] D105759: [WIP] Implement P2361 Unevaluated string literals

2021-09-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 375964.
cor3ntin added a comment.

Fix EOF & unrenamed StringKind


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105759/new/

https://reviews.llvm.org/D105759

Files:
  clang-tools-extra/test/clang-tidy/checkers/modernize-unary-static-assert.cpp
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaStmtAsm.cpp
  clang/test/CXX/dcl.dcl/dcl.link/p2.cpp
  clang/test/CXX/dcl.dcl/p4-0x.cpp
  clang/test/FixIt/fixit-static-assert.cpp
  clang/test/Parser/asm.c
  clang/test/Parser/asm.cpp
  clang/test/Parser/attr-availability-xcore.c
  clang/test/Parser/attr-availability.c
  clang/test/Sema/asm.c
  clang/test/SemaCXX/static-assert.cpp

Index: clang/test/SemaCXX/static-assert.cpp
===
--- clang/test/SemaCXX/static-assert.cpp
+++ clang/test/SemaCXX/static-assert.cpp
@@ -28,12 +28,15 @@
 S s1; // expected-note {{in instantiation of template class 'S' requested here}}
 S s2;
 
-static_assert(false, L"\x"); // expected-error {{static_assert failed L"\x"}}
-static_assert(false, u"\U000317FF"); // expected-error {{static_assert failed u"\U000317FF"}}
+static_assert(false, L"\x"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, u"\U000317FF"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
 // FIXME: render this as u8"\u03A9"
-static_assert(false, u8"Ω"); // expected-error {{static_assert failed u8"\316\251"}}
-static_assert(false, L"\u1234"); // expected-error {{static_assert failed L"\x1234"}}
-static_assert(false, L"\x1ff" "0\x123" "fx\xf" "goop"); // expected-error {{static_assert failed L"\x1FF""0\x123""fx\xFgoop"}}
+static_assert(false, u8"Ω"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, L"\u1234"); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+static_assert(false, L"\x1ff"// expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+ "0\x123"
+ "fx\xf"
+ "goop");
 
 template struct AlwaysFails {
   // Only give one error here.
Index: clang/test/Sema/asm.c
===
--- clang/test/Sema/asm.c
+++ clang/test/Sema/asm.c
@@ -37,14 +37,19 @@
   asm ("nop" : "=c" (a) : "r" (no_clobber_conflict) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
   asm ("nop" : "=r" (no_clobber_conflict) : "c" (c) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
   asm ("nop" : "=r" (clobber_conflict) : "c" (c) : "%rcx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
-  asm ("nop" : "=a" (a) : "b" (b) : "%rcx", "%rbx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}} 
+  asm("nop"
+  : "=a"(a)
+  : "b"(b)
+  : "%rcx", "%rbx"); // expected-error {{asm-specifier for input or output variable conflicts with asm clobber list}}
 }
 
 // rdar://6094010
 void test3() {
   int x;
-  asm(L"foo" : "=r"(x)); // expected-error {{wide string}}
-  asm("foo" : L"=r"(x)); // expected-error {{wide string}}
+  asm(L"foo" // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
+  : "=r"(x));
+  asm("foo"
+  : L"=r"(x)); // expected-error {{an unevaluated string literal cannot have an encoding prefix}}
 }
 
 // 
Index: clang/test/Parser/attr-availability.c
===
--- clang/test/Parser/attr-availability.c
+++ clang/test/Parser/attr-availability.c
@@ -18,23 +18,26 @@
 
 void f6() __attribute__((availability(macosx,unavailable,introduced=10.5))); // expected-warning{{'unavailable' availability overrides all other availability information}}
 
-void f7() __attribute__((availability(macosx,message=L"wide"))); // expected-error {{expected string literal for optional message in 'availability' attribute}}
+void f7() __attribute__((availability(maco

[PATCH] D110742: [OpenCL] Add pure and const attributes to vload builtins

2021-09-29 Thread Stuart Brady via Phabricator via cfe-commits
stuart created this revision.
stuart added reviewers: svenvh, Anastasia, airlied, yaxunl.
Herald added a subscriber: ldrumm.
stuart requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Use the `pure` and `const` attributes for the `vload`, `vload_half` and 
`vloada_half` builtins.

For the //global//, //local//, //private// and //generic// address spaces, the 
`pure` attribute (or `readonly`) can be used.

For the //constant// address space, the `const` attribute (or `readnone`) can 
be used.  As memory in the //constant// address space is immutable, the 
statement in the langref that: "if a `readnone` function reads or writes memory 
visible to the program, or has other side-effects, the behavior is undefined" 
does not apply.  The reading of immutable memory does not have side-effects, 
nor can it be affected by side-effects.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110742

Files:
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/OpenCLBuiltins.td

Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -792,21 +792,21 @@
 // OpenCL v1.1 s6.11.7, v1.2 s6.12.7, v2.0 s6.13.7 - Vector Data Load and Store Functions
 // OpenCL Extension v1.1 s9.3.6 and s9.6.6, v1.2 s9.5.6, v2.0 s5.1.6 and s6.1.6 - Vector Data Load and Store Functions
 // --- Table 15 ---
-multiclass VloadVstore addrspaces, bit defStores> {
+multiclass VloadVstore addrspaces, bit defStores, list LoadAttr = Attr.Pure> {
   foreach AS = addrspaces in {
 foreach VSize = [2, 3, 4, 8, 16] in {
   foreach name = ["vload" # VSize] in {
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
-def : Builtin, Size, PointerType, AS>]>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
   }
   if defStores then {
 foreach name = ["vstore" # VSize] in {
@@ -834,14 +834,14 @@
   defm : VloadVstore<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.
-defm : VloadVstore<[ConstantAS], 0>;
+defm : VloadVstore<[ConstantAS], 0, Attr.Const>;
 
-multiclass VloadVstoreHalf addrspaces, bit defStores> {
+multiclass VloadVstoreHalf addrspaces, bit defStores, list LoadAttr = Attr.Pure> {
   foreach AS = addrspaces in {
-def : Builtin<"vload_half", [Float, Size, PointerType, AS>]>;
+def : Builtin<"vload_half", [Float, Size, PointerType, AS>], LoadAttr>;
 foreach VSize = [2, 3, 4, 8, 16] in {
   foreach name = ["vload_half" # VSize, "vloada_half" # VSize] in {
-def : Builtin, Size, PointerType, AS>]>;
+def : Builtin, Size, PointerType, AS>], LoadAttr>;
   }
 }
 if defStores then {
@@ -867,8 +867,8 @@
 let MinVersion = CL20 in {
   defm : VloadVstoreHalf<[GenericAS], 1>;
 }
-// vload with constant address space is available regardless of version.
-defm : VloadVstoreHalf<[ConstantAS], 0>;
+// vload_half and vloada_half with constant address space are available regardless of version.
+defm : VloadVstoreHalf<[ConstantAS], 0, Attr.Const>;
 
 // OpenCL v3.0 s6.15.8 - Synchronization Functions.
 def : Builtin<"barrier", [Void, MemFenceFlags], Attr.Convergent>;
Index: clang/lib/Headers/opencl-c.h
===
--- clang/lib/Headers/opencl-c.h
+++ clang/lib/Headers/opencl-c.h
@@ -11187,305 +11187,305 @@
  * 64-bit aligned if gentype is long, ulong, double.
  */
 
-char2 __ovld vload2(size_t offset, const __constant char *p);
-uchar2 __ovld vload2(size_t offset, const __constant uchar *p);
-short2 __ovld vload2(size_t offset, const __constant short *p);
-ushort2 __ovld vload2(size_t offset, const __constant ushort *p);
-int2 __ovld vload2(size_t offset, const __constant int *p);
-uint2 __ovld vload2(size_t offset, const __constant uint *p);
-long2 __ovld vload2(size_t offset, 

[PATCH] D85390: [Clang] Add note for bad conversion error when expression is of forward-declared type

2021-09-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Please see llvm.org/PR52014 -- this patch is not properly handling 
cv-qualifiers. We should not produce the new note if the destination type has 
qualifiers that the source type does not possess, because in that case 
inheritance makes no difference to whether the conversion is valid.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85390/new/

https://reviews.llvm.org/D85390

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


[PATCH] D110276: Clean up large copies of binaries copied into temp directories in tests

2021-09-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

It's my personal bot. It doesn't send email. IMHO the problem of how to make 
bots send emails hasn't been solved (they either send too much or too little), 
so I'm not pretending that it has been ;)

Sadly the test is still failing after the `-f` change: 
http://45.33.8.238/win/46139/step_7.txt

Maybe tacking on an `|| true` helps?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110276/new/

https://reviews.llvm.org/D110276

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


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-29 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:69
 def note_cast_to_void : Note<"cast expression to void to silence warning">;
+def note_cast_operand_to_int : Note<"cast one or both operands to int to 
silence warning">;
 

LGTM, based on the precedent set on line 68. If I were writing all these notes 
from scratch, I'd say "to silence //this// warning"; but that can be done in a 
separate PR, if ever.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108003/new/

https://reviews.llvm.org/D108003

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


[PATCH] D110727: [clang] don't instantiate templates with injected arguments

2021-09-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov created this revision.
Herald added a subscriber: kristof.beyls.
mizvekov updated this revision to Diff 375937.
mizvekov added a comment.
mizvekov updated this revision to Diff 375943.
mizvekov published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

.


mizvekov added a comment.

.


There is a special situation with templates in local classes,
as can be seen in this example with generic lambdas in function scope:

  template void foo() {
  (void)[]() {
struct S {
  void bar() { (void)[](T2) {}; }
};
  };
  };
  template void foo();

As a consequence of the resolution of DR1484, bar is instantiated during the
substitution of foo, and in this context we would substitute the lambda within
it with it's own parameters "injected" (turned into arguments).

This can't be properly dealt with for at least a couple of reasons:

- The 'TemplateTypeParm' type itself can only deal with canonical replacement 
types, which the injected arguments are not.
- If T3 were constrained in the example above, our (non-conforming) eager 
substitution of type constraints would just leave that parameter dangling.

Instead of substituting with injected parameters, this patch just leaves those
inner levels unreplaced.

Since injected arguments appear to be unused within the users of
`getTemplateInstantiationArgs`, this patch just removes that support there and
leaves a couple of asserts in place.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D110727

Files:
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaTemplate/generic-lambda.cpp


Index: clang/test/SemaTemplate/generic-lambda.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/generic-lambda.cpp
@@ -0,0 +1,62 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+template  constexpr bool is_same_v = false;
+template  constexpr bool is_same_v = true;
+template 
+concept is_same = is_same_v;
+
+template  struct X {};
+template 
+concept C1 = is_same>;
+
+template  X>> t1() {
+  return [](T2) -> X> {
+struct S {
+  static X> f() {
+return [](T3) -> X {
+  static_assert(is_same>);
+  static_assert(is_same>);
+  return X();
+}(X());
+  }
+};
+return S::f();
+  }(X());
+};
+template X>> t1();
+
+#if 0 // FIXME: crashes
+template auto t2() {
+  return [](T2) {
+struct S {
+  static auto f() {
+return [](T3) {
+  static_assert(is_same>);
+  static_assert(is_same>);
+  return X();
+}(X());
+  }
+};
+return S::f();
+  }(X());
+};
+template auto t2();
+static_assert(is_same()), X>>>);
+
+template C1>> auto t3() {
+  return [] T2>(T2) -> C1> auto {
+struct S {
+  static auto f() {
+return [] T3>(T3) -> C1 auto {
+  return X();
+}(X());
+  }
+};
+return S::f();
+  }(X());
+};
+template C1>> auto t3();
+static_assert(is_same()), X>>>);
+#endif
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -161,10 +161,9 @@
 if (isGenericLambdaCallOperatorOrStaticInvokerSpecialization(Function))
   break;
 
-  } else if (FunctionTemplateDecl *FunTmpl
-   = Function->getDescribedFunctionTemplate()) 
{
-// Add the "injected" template arguments.
-Result.addOuterTemplateArguments(FunTmpl->getInjectedTemplateArgs());
+  } else if (Function->getDescribedFunctionTemplate()) {
+assert(Result.getNumSubstitutedLevels() == 0 &&
+   "Outer template not instantiated?");
   }
 
   // If this is a friend declaration and it declares an entity at
@@ -180,11 +179,8 @@
   }
 } else if (CXXRecordDecl *Rec = dyn_cast(Ctx)) {
   if (ClassTemplateDecl *ClassTemplate = Rec->getDescribedClassTemplate()) 
{
-QualType T = ClassTemplate->getInjectedClassNameSpecialization();
-const TemplateSpecializationType *TST =
-cast(Context.getCanonicalType(T));
-Result.addOuterTemplateArguments(
-llvm::makeArrayRef(TST->getArgs(), TST->getNumArgs()));
+assert(Result.getNumSubstitutedLevels() == 0 &&
+   "Outer template not instantiated?");
 if (ClassTemplate->isMemberSpecialization())
   break;
   }


Index: clang/test/SemaTemplate/generic-lambda.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/generic-lambda.cpp
@@ -0,0 +1,62 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s
+
+// expected-no-diagnostics
+
+template  constexpr bool is_same_v = false;
+template  constexpr bool is_same_v = true;
+templa

[clang] 2240deb - [clang] Minor cleanups after b2de52bec

2021-09-29 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-09-29T14:28:13-04:00
New Revision: 2240deb9766cc080b351016b0d7f975d7249b113

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

LOG: [clang] Minor cleanups after b2de52bec

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/utils/TableGen/ClangDiagnosticsEmitter.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 463fb62b223d..9450e8b154c5 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5452,7 +5452,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 
   if (auto Group = diagGroupFromCLWarningID(WarningNumber)) {
 CmdArgs.push_back(Args.MakeArgString(
-Twine("-Wno-") + DiagnosticIDs::getWarningOptionForGroup(*Group)));
+"-Wno-" + DiagnosticIDs::getWarningOptionForGroup(*Group)));
 continue;
   }
 }

diff  --git a/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp 
b/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
index 573bb5b4039b..547ec2c82cb3 100644
--- a/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ b/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -1537,7 +1537,7 @@ static void emitDiagTable(std::map &DiagsInGroup,
   OS << "0";
 }
 
-OS << " )\n";
+OS << ")\n";
   }
   OS << "#endif // DIAG_ENTRY\n\n";
 }



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


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-29 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 updated this revision to Diff 375969.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108003/new/

https://reviews.llvm.org/D108003

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaChecking.cpp
  clang/p.patch
  clang/test/Sema/warn-bitwise-and-bool.c
  clang/test/Sema/warn-bitwise-or-bool.c

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


[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-29 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 marked 3 inline comments as done.
xbolva00 added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:69
 def note_cast_to_void : Note<"cast expression to void to silence warning">;
+def note_cast_operand_to_int : Note<"cast one or both operands to int to 
silence warning">;
 

Quuxplusone wrote:
> LGTM, based on the precedent set on line 68. If I were writing all these 
> notes from scratch, I'd say "to silence //this// warning"; but that can be 
> done in a separate PR, if ever.
Yeah, silence this warning is better and also used (well, more often) in this 
file. I will change it to this form.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108003/new/

https://reviews.llvm.org/D108003

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


[PATCH] D110482: [clang] Implement if consteval (P1938)

2021-09-29 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 375970.
cor3ntin added a comment.

use llvm::reverse


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110482/new/

https://reviews.llvm.org/D110482

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Interp/ByteCodeStmtGen.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/Stmt.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/Analysis/BodyFarm.cpp
  clang/lib/Analysis/CFG.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprMember.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Checkers/LocalizationChecker.cpp
  clang/test/AST/Interp/if_consteval.cpp
  clang/test/AST/ast-dump-if-json.cpp
  clang/test/AST/ast-dump-stmt.cpp
  clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
  clang/test/CodeGenCXX/cxx2b-consteval-if.cpp

Index: clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx2b-consteval-if.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -std=c++2b %s -emit-llvm -o - | FileCheck %s
+
+void should_be_used_1();
+void should_be_used_2();
+void should_be_used_3();
+constexpr void should_not_be_used() {}
+
+constexpr void f() {
+  if consteval {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  } else {
+should_be_used_1();  // CHECK: call {{.*}}should_be_used_1
+  }
+
+  if !consteval {
+should_be_used_2();  // CHECK: call {{.*}}should_be_used_2
+  }
+
+  if !consteval {
+should_be_used_3();  // CHECK: call {{.*}}should_be_used_3
+  } else {
+should_not_be_used(); // CHECK-NOT: call {{.*}}should_not_be_used
+  }
+}
+
+void g() {
+  f();
+}
Index: clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
===
--- /dev/null
+++ clang/test/CXX/stmt.stmt/stmt.select/stmt.if/p4.cpp
@@ -0,0 +1,147 @@
+// RUN: %clang_cc1 -std=c++2b -verify %s
+
+void test_consteval() {
+  if consteval (void) 0; // expected-error {{expected { after consteval}}
+  if consteval {
+(void)0;
+  } else (void)0; // expected-error {{expected { after else}}
+
+  static_assert([] {
+if consteval {
+  return 0;
+}
+return 1;
+  }() == 0);
+
+  static_assert([] {
+if consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 0);
+
+  static_assert([] {
+if !consteval {
+  return 0;
+} else {
+  return 1;
+}
+  }() == 1);
+
+  static_assert([] {
+if not consteval {
+  return 0;
+}
+return 1;
+  }() == 1);
+}
+
+void test_consteval_jumps() {
+  if consteval { // expected-note 4{{jump enters controlled statement of consteval if}}
+goto a;
+goto b; // expected-error {{cannot jump from this goto statement to its label}}
+  a:;
+  } else {
+goto b;
+goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  b:;
+  }
+  goto a; // expected-error {{cannot jump from this goto statement to its label}}
+  goto b; // expected-error {{cannot jump from this goto statement to its label}}
+}
+
+void test_consteval_switch() {
+  int x = 42;
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+case 1:;   // expected-error {{cannot jump from switch statement to this case label}}
+default:;  // expected-error {{cannot jump from switch statement to this case label}}
+} else {
+}
+  }
+  switch (x) {
+if consteval { // expected-note 2{{jump enters controlled statement of consteval if}}
+} else {
+case 2:;  // expected-error {{cannot jump from switch statement to this case label}}
+default:; // expected-error {{cannot jump from switch statement to this case label}}
+}
+  }
+}
+
+consteval int f(int i) { return i; }
+constexpr int g(int i) {
+  if consteval {
+return f(i);
+  } else {
+return 42;
+  }
+}
+static_assert(g(10) == 10);
+
+constexpr int h(int i) { // expected-note {{declared here}}
+  if !consteval {
+return f(i); // expected-error {{call to consteval function 'f' is not a constant expression}}\
+ // expected-note  {{cannot be used in a constant expression}}
+  }
+  return 0;
+}
+
+consteval void warn_in_consteval() {
+  if consteval { // expected-warning {{consteval if is alway

  1   2   >