[PATCH] D70094: [clang-tidy] new altera ID dependent backward branch check

[Frank Derry Wanye via Phabricator via cfe-commits]

ffrankies updated this revision to Diff 335195.
ffrankies added a comment.

- Addressed comments from the automated pre-merge checks
- Moved link to external documentation to the end of 
`clang-tools-extra/docs/clang-tidy/checks/altera-id-dependent-backward-branch.rst`
 as requested by @Eugene.Zelenko


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

https://reviews.llvm.org/D70094

Files:
  clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
  clang-tools-extra/clang-tidy/altera/CMakeLists.txt
  clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.cpp
  clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/altera-id-dependent-backward-branch.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp
@@ -0,0 +1,86 @@
+// RUN: %check_clang_tidy %s altera-id-dependent-backward-branch %t -- -header-filter=.* "--" -cl-std=CL1.2 -c --include opencl-c.h
+
+typedef struct ExampleStruct {
+  int IDDepField;
+} ExampleStruct;
+
+void error() {
+  //  Conditional Expressions 
+  int accumulator = 0;
+  for (int i = 0; i < get_local_id(0); i++) {
+// CHECK-NOTES: :[[@LINE-1]]:19: warning: backward branch (for loop) is ID-dependent due to ID function call and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  int j = 0;
+  while (j < get_local_id(0)) {
+// CHECK-NOTES: :[[@LINE-1]]:10: warning: backward branch (while loop) is ID-dependent due to ID function call and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  do {
+accumulator++;
+  } while (j < get_local_id(0));
+  // CHECK-NOTES: :[[@LINE-1]]:12: warning: backward branch (do loop) is ID-dependent due to ID function call and may cause performance degradation [altera-id-dependent-backward-branch]
+
+  //  Assignments 
+  int ThreadID = get_local_id(0);
+
+  while (j < ThreadID) {
+// CHECK-NOTES: :[[@LINE-3]]:3: note: assignment of ID-dependent variable ThreadID
+// CHECK-NOTES: :[[@LINE-2]]:10: warning: backward branch (while loop) is ID-dependent due to variable reference to 'ThreadID' and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  ExampleStruct Example;
+  Example.IDDepField = get_local_id(0);
+
+  //  Inferred Assignments 
+  int ThreadID2 = ThreadID * get_local_size(0);
+
+  int ThreadID3 = Example.IDDepField; // OK: not used in any loops
+
+  ExampleStruct UnusedStruct = {
+  ThreadID * 2 // OK: not used in any loops
+  };
+
+  for (int i = 0; i < ThreadID2; i++) {
+// CHECK-NOTES: :[[@LINE-9]]:3: note: inferred assignment of ID-dependent value from ID-dependent variable ThreadID
+// CHECK-NOTES: :[[@LINE-2]]:19: warning: backward branch (for loop) is ID-dependent due to variable reference to 'ThreadID2' and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  do {
+accumulator++;
+  } while (j < ThreadID);
+  // CHECK-NOTES: :[[@LINE-29]]:3: note: assignment of ID-dependent variable ThreadID
+  // CHECK-NOTES: :[[@LINE-2]]:12: warning: backward branch (do loop) is ID-dependent due to variable reference to 'ThreadID' and may cause performance degradation [altera-id-dependent-backward-branch]
+
+  for (int i = 0; i < Example.IDDepField; i++) {
+// CHECK-NOTES: :[[@LINE-24]]:3: note: assignment of ID-dependent field IDDepField
+// CHECK-NOTES: :[[@LINE-2]]:19: warning: backward branch (for loop) is ID-dependent due to member reference to 'IDDepField' and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  while (j < Example.IDDepField) {
+// CHECK-NOTES: :[[@LINE-30]]:3: note: assignment of ID-dependent field IDDepField
+// CHECK-NOTES: :[[@LINE-2]]:10: warning: backward branch (while loop) is ID-dependent due to member reference to 'IDDepField' and may cause performance degradation [altera-id-dependent-backward-branch]
+accumulator++;
+  }
+
+  do {
+accumulator++;
+  } while (j < Example.IDDepField);
+  // CHECK-NOTES: :[[@LINE-38]]:3: note: assignment of ID-dependent field IDDepField
+  // CHECK-NOTES: :[[@LINE-2]]:12: warning: backward branch (do loop) is ID-dependent due to member reference to 'IDDepField' and may cause performance degradation [altera-id-dependent-backward-branch]
+}
+
+void success() {
+  int accumulator = 0;
+
+  for (int i = 0; i < 1000; i++) {
+if (i < get_local_id(0)) {
+  accumulator++;
+}
+  }
+}
Index: 

[PATCH] D99688: [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG907af8439672: [CUDA][HIP] rename 
-fcuda-flush-denormals-to-zero (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99688

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/CodeGenCUDA/flush-denormals.cu
  clang/test/Driver/cuda-flush-denormals-to-zero.cu
  clang/test/Driver/hip-device-libs.hip

Index: clang/test/Driver/hip-device-libs.hip
===
--- clang/test/Driver/hip-device-libs.hip
+++ clang/test/Driver/hip-device-libs.hip
@@ -24,7 +24,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -33,7 +33,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -42,7 +42,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -51,7 +51,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -60,7 +60,7 @@
 // Test last flag wins, not flushing
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -68,7 +68,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -76,7 +76,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -84,7 +84,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
Index: clang/test/Driver/cuda-flush-denormals-to-zero.cu
===
--- clang/test/Driver/cuda-flush-denormals-to-zero.cu
+++ clang/test/Driver/cuda-flush-denormals-to-zero.cu
@@ -1,22 +1,26 @@
 // Checks that cuda compilation does the right thing when passed
-// -fcuda-flush-denormals-to-zero. This should be translated to
+// -fgpu-flush-denormals-to-zero. This should be translated to
 // -fdenormal-fp-math-f32=preserve-sign
 
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fgpu-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=FTZ %s
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fno-gpu-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=NOFTZ %s
+// RUN: %clang 

[clang] 907af84 - [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-04-05T00:13:51-04:00
New Revision: 907af8439672e47cf978b43625d9318dd34e13ab

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

LOG: [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

Rename it to -fgpu-flush-denormals-to-zero.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/Cuda.cpp
clang/lib/Driver/ToolChains/HIP.cpp
clang/test/CodeGenCUDA/flush-denormals.cu
clang/test/Driver/cuda-flush-denormals-to-zero.cu
clang/test/Driver/hip-device-libs.hip

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 58af122993255..a6583acd9ecb7 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -897,9 +897,13 @@ def cuda_path_ignore_env : Flag<["--"], 
"cuda-path-ignore-env">, Group,
   HelpText<"Ignore environment variables to detect CUDA installation">;
 def ptxas_path_EQ : Joined<["--"], "ptxas-path=">, Group,
   HelpText<"Path to ptxas (used for compiling CUDA code)">;
+def fgpu_flush_denormals_to_zero : Flag<["-"], "fgpu-flush-denormals-to-zero">,
+  HelpText<"Flush denormal floating point values to zero in CUDA/HIP device 
mode.">;
+def fno_gpu_flush_denormals_to_zero : Flag<["-"], 
"fno-gpu-flush-denormals-to-zero">;
 def fcuda_flush_denormals_to_zero : Flag<["-"], 
"fcuda-flush-denormals-to-zero">,
-  HelpText<"Flush denormal floating point values to zero in CUDA device 
mode.">;
-def fno_cuda_flush_denormals_to_zero : Flag<["-"], 
"fno-cuda-flush-denormals-to-zero">;
+  Alias;
+def fno_cuda_flush_denormals_to_zero : Flag<["-"], 
"fno-cuda-flush-denormals-to-zero">,
+  Alias;
 defm gpu_rdc : BoolFOption<"gpu-rdc",
   LangOpts<"GPURelocatableDeviceCode">, DefaultFalse,
   PosFlag,

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index 2ce040cfca01a..dc9c9751c851d 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -643,8 +643,8 @@ llvm::DenormalMode 
AMDGPUToolChain::getDefaultDenormalModeForType(
 auto Arch = getProcessorFromTargetID(getTriple(), JA.getOffloadingArch());
 auto Kind = llvm::AMDGPU::parseArchAMDGCN(Arch);
 if (FPType && FPType == ::APFloat::IEEEsingle() &&
-DriverArgs.hasFlag(options::OPT_fcuda_flush_denormals_to_zero,
-   options::OPT_fno_cuda_flush_denormals_to_zero,
+DriverArgs.hasFlag(options::OPT_fgpu_flush_denormals_to_zero,
+   options::OPT_fno_gpu_flush_denormals_to_zero,
getDefaultDenormsAreZeroForTarget(Kind)))
   return llvm::DenormalMode::getPreserveSign();
 

diff  --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index de47c82d73deb..be81d0f26f684 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -763,9 +763,8 @@ llvm::DenormalMode 
CudaToolChain::getDefaultDenormalModeForType(
 const llvm::fltSemantics *FPType) const {
   if (JA.getOffloadingDeviceKind() == Action::OFK_Cuda) {
 if (FPType && FPType == ::APFloat::IEEEsingle() &&
-DriverArgs.hasFlag(options::OPT_fcuda_flush_denormals_to_zero,
-   options::OPT_fno_cuda_flush_denormals_to_zero,
-   false))
+DriverArgs.hasFlag(options::OPT_fgpu_flush_denormals_to_zero,
+   options::OPT_fno_gpu_flush_denormals_to_zero, 
false))
   return llvm::DenormalMode::getPreserveSign();
   }
 

diff  --git a/clang/lib/Driver/ToolChains/HIP.cpp 
b/clang/lib/Driver/ToolChains/HIP.cpp
index 1c4eab91d6936..b5242689fffd4 100644
--- a/clang/lib/Driver/ToolChains/HIP.cpp
+++ b/clang/lib/Driver/ToolChains/HIP.cpp
@@ -400,8 +400,8 @@ HIPToolChain::getHIPDeviceLibs(const llvm::opt::ArgList 
) const {
 // If --hip-device-lib is not set, add the default bitcode libraries.
 // TODO: There are way too many flags that change this. Do we need to check
 // them all?
-bool DAZ = DriverArgs.hasFlag(options::OPT_fcuda_flush_denormals_to_zero,
-  
options::OPT_fno_cuda_flush_denormals_to_zero,
+bool DAZ = DriverArgs.hasFlag(options::OPT_fgpu_flush_denormals_to_zero,
+  options::OPT_fno_gpu_flush_denormals_to_zero,
   getDefaultDenormsAreZeroForTarget(Kind));
 // TODO: Check standard C++ flags?
 bool FiniteOnly = false;

diff  --git a/clang/test/CodeGenCUDA/flush-denormals.cu 
b/clang/test/CodeGenCUDA/flush-denormals.cu

[PATCH] D99688: [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 335192.
yaxunl marked an inline comment as done.
yaxunl added a comment.

rebase and add tests for old options


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

https://reviews.llvm.org/D99688

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/CodeGenCUDA/flush-denormals.cu
  clang/test/Driver/cuda-flush-denormals-to-zero.cu
  clang/test/Driver/hip-device-libs.hip

Index: clang/test/Driver/hip-device-libs.hip
===
--- clang/test/Driver/hip-device-libs.hip
+++ clang/test/Driver/hip-device-libs.hip
@@ -24,7 +24,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -33,7 +33,7 @@
 // Test explicit flag, opposite of target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -42,7 +42,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -51,7 +51,7 @@
 // Test explicit flag, same as target default.
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -60,7 +60,7 @@
 // Test last flag wins, not flushing
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -68,7 +68,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fcuda-flush-denormals-to-zero -fno-cuda-flush-denormals-to-zero \
+// RUN:   -fgpu-flush-denormals-to-zero -fno-gpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,NOFLUSHD
@@ -76,7 +76,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx900 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm   \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
@@ -84,7 +84,7 @@
 
 // RUN: %clang -### -target x86_64-linux-gnu \
 // RUN:   --cuda-gpu-arch=gfx803 \
-// RUN:   -fno-cuda-flush-denormals-to-zero -fcuda-flush-denormals-to-zero \
+// RUN:   -fno-gpu-flush-denormals-to-zero -fgpu-flush-denormals-to-zero \
 // RUN:   --rocm-path=%S/Inputs/rocm \
 // RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
 // RUN: 2>&1 | FileCheck %s --check-prefixes=ALL,FLUSHD
Index: clang/test/Driver/cuda-flush-denormals-to-zero.cu
===
--- clang/test/Driver/cuda-flush-denormals-to-zero.cu
+++ clang/test/Driver/cuda-flush-denormals-to-zero.cu
@@ -1,22 +1,26 @@
 // Checks that cuda compilation does the right thing when passed
-// -fcuda-flush-denormals-to-zero. This should be translated to
+// -fgpu-flush-denormals-to-zero. This should be translated to
 // -fdenormal-fp-math-f32=preserve-sign
 
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fgpu-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=FTZ %s
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_20 -fno-gpu-flush-denormals-to-zero -nocudainc -nocudalib %s 2>&1 | FileCheck -check-prefix=NOFTZ %s
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-linux-gnu -c -march=haswell --cuda-gpu-arch=sm_70 

[PATCH] D99688: [CUDA][HIP] rename -fcuda-flush-denormals-to-zero

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/test/Driver/cuda-flush-denormals-to-zero.cu:2
 // Checks that cuda compilation does the right thing when passed
-// -fcuda-flush-denormals-to-zero. This should be translated to
+// -fgpu-flush-denormals-to-zero. This should be translated to
 // -fdenormal-fp-math-f32=preserve-sign

tra wrote:
> It would be good to add a couple of tests to verify that 
> `-fcuda-flush-denormals-to-zero` still work as we still need them for 
> existing users.
will do


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

https://reviews.llvm.org/D99688

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

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha updated this revision to Diff 335182.
SaurabhJha added a comment.

Move the definition of MatrixCast to the bottom in OperationKinds.def


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

Files:
  clang/include/clang/AST/OperationKinds.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/CodeGen/matrix-cast.c
  clang/test/Sema/matrix-cast.c

Index: clang/test/Sema/matrix-cast.c
===
--- /dev/null
+++ clang/test/Sema/matrix-cast.c
@@ -0,0 +1,83 @@
+// RUN: %clang_cc1 -fenable-matrix -fsyntax-only %s -verify
+
+typedef char cx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix4x4 __attribute__((matrix_type(4, 4)));
+typedef short sx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+typedef int vec __attribute__((vector_size(4)));
+typedef struct test_struct {
+} test_struct;
+
+void f1() {
+  cx4x4 m1;
+  ix4x4 m2;
+  sx4x4 m3;
+  ix5x5 m4;
+  fx5x5 m5;
+  int i;
+  vec v;
+  test_struct *s;
+
+  m2 = (ix4x4)m1;
+  m3 = (sx4x4)m2;
+  m4 = (ix5x5)m3; // expected-error {{invalid conversion between matrix type \
+'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))') and 'sx4x4' \
+(aka 'short __attribute__((matrix_type(4, 4)))') of different size}}
+  m5 = (ix5x5)m4; // expected-error {{assigning to 'fx5x5' (aka \
+'float __attribute__((matrix_type(5, 5)))') from incompatible type 'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))')}}
+  i = (int)m4;// expected-error {{invalid conversion between matrix type \
+'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))') and non matrix type \
+'int'}}
+  m4 = (ix5x5)i;  // expected-error {{invalid conversion between matrix type \
+'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))') and non matrix type \
+'int'}}
+  v = (vec)m4;// expected-error {{invalid conversion between matrix type \
+'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))') and non matrix type \
+'vec' (vector of 1 'int' value)}}
+  m4 = (ix5x5)v;  // expected-error {{invalid conversion between matrix type \
+'ix5x5' (aka 'int __attribute__((matrix_type(5, 5)))') and non matrix type \
+'vec' (vector of 1 'int' value)}}
+  s = (test_struct *)m3; // expected-error {{invalid conversion between matrix type \
+'sx4x4' (aka 'short __attribute__((matrix_type(4, 4)))') and non matrix type \
+'test_struct *' (aka 'struct test_struct *')}}
+  m3 = (sx4x4)s; // expected-error {{invalid conversion between matrix type \
+'sx4x4' (aka 'short __attribute__((matrix_type(4, 4)))') and non matrix type \
+'test_struct *' (aka 'struct test_struct *')}}
+
+  m4 = (ix5x5)m5;
+}
+
+typedef float float2_8x8 __attribute__((matrix_type(8, 8)));
+typedef double double_10x10 __attribute__((matrix_type(10, 10)));
+typedef double double_8x8 __attribute__((matrix_type(8, 8)));
+typedef signed int signed_int_12x12 __attribute__((matrix_type(12, 12)));
+typedef unsigned int unsigned_int_12x12 __attribute__((matrix_type(12, 12)));
+typedef unsigned int unsigned_int_10x10 __attribute__((matrix_type(10, 10)));
+
+void f2() {
+  float2_8x8 m1;
+  double_10x10 m2;
+  double_8x8 m3;
+  signed_int_12x12 m4;
+  unsigned_int_12x12 m5;
+  unsigned_int_10x10 m6;
+  float f;
+
+  m2 = (double_10x10)m1; // expected-error {{invalid conversion between matrix type \
+'double_10x10' (aka 'double __attribute__((matrix_type(10, 10)))') and 'float2_8x8' \
+(aka 'float __attribute__((matrix_type(8, 8)))') of different size}}
+  m3 = (double_8x8)m1;
+
+  m5 = (unsigned_int_12x12)m4;
+  m4 = (signed_int_12x12)m5;
+  m6 = (unsigned_int_10x10)m4; // expected-error {{invalid conversion between matrix type \
+'unsigned_int_10x10' (aka 'unsigned int __attribute__((matrix_type(10, 10)))') and 'signed_int_12x12' \
+(aka 'int __attribute__((matrix_type(12, 12)))') of different size}}
+  f = (float)m4;   // expected-error {{invalid conversion between matrix type \
+'signed_int_12x12' (aka 'int __attribute__((matrix_type(12, 12)))') and non matrix type \
+'float'}}
+  m4 = (signed_int_12x12)f;// expected-error {{invalid conversion between matrix type \
+'signed_int_12x12' (aka 'int __attribute__((matrix_type(12, 12)))') and non matrix type \
+'float'}}
+}
\ No newline at end of file
Index: clang/test/CodeGen/matrix-cast.c
===
--- /dev/null
+++ 

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

In D99037#2668295 , @SaurabhJha wrote:

> One other problem is somehow this test is failing 
> https://github.com/llvm/llvm-project/blob/main/clang/test/SemaOpenCL/sampler_t_overload.cl#L6
>  with this error.
>
>   /tmp/clang/test/SemaOpenCL/sampler_t_overload.cl:6:30: error: initializer 
> element is not a compile-time constant
>   constant sampler_t glb_smp = 5;
>^
>   1 error generated.
>
> Not sure what's going on but will continue to debug. Let me know if there's 
> something simple that I am missing here.

I think I got it. If I remove the definition of `CAST_OPERATION(MatrixCast)` 
from `OperationKinds.def`, it works. So probably a matter of defining it the 
correct way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[PATCH] D93822: [clang-tidy] Add check for implicit widening of multiplication result

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:29
+  // Is this:  long r = int(x) * int(y);  ?
+  // FIXME: shall we skip brackets/casts/etc?
+  auto *BO = dyn_cast(E);

aaron.ballman wrote:
> I think we should skip parens at the very least. `x * y` should check the 
> same as `(x) * (y)`.
This is more about the future case for which there's FIXME few lines down.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:75
+  else if (Ty->isSignedIntegerType()) {
+assert(ETy->isUnsignedIntegerType() &&
+   "Expected source type to be signed.");

lebedev.ri wrote:
> aaron.ballman wrote:
> > Might be worth it to have tests around `signed char`, `unsigned char`, and 
> > `char` explicitly, as that gets awkward.
> Are you asking for test coverage, or for explicit handling of those types?
> I'll add tests.
It seems to kinda just work, because of the promotion to `int`.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:126
+  QualType SizeTy = IndexExprType->isSignedIntegerType() ? SSizeTy : USizeTy;
+  // FIXME: is there a way to actually get the QualType for size_t/ssize_t?
+  StringRef TyAsString =

aaron.ballman wrote:
> You already are using the way?
No, that's not it, because `SizeTy.getAsString()` will not be 
`size_t`/`ssize_t`, but `long`/etc.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-char.cpp:10
+
+long t0(char a, char b) {
+  return a * b;

aaron.ballman wrote:
> Can you also test the fixit behavior in addition to the diagnostic behavior 
> (at least one test for each kind of fix-it)?
I would love to do that, but as we have briefly talked with @njames93,
fix-it testing in clang-tidy, as compared to clang proper,
is rudimentary. I basically can not add tests here.
As far as i can see, it doesn't want to apply fix-its, because there are two of 
them.

So this is the best i can do, take it or leave it. /s



Comment at: clang/lib/AST/ASTContext.cpp:10158
+  if (const auto *ETy = T->getAs())
+T = ETy->getDecl()->getIntegerType();
+

lebedev.ri wrote:
> aaron.ballman wrote:
> > This looks to be getting the same value as in the 
> > `getCorrespondingUnsignedType()` call?
> Yep. Are both of them incorrect?
> I'm not sure what should be returned here.
Actually, this is correct.
Note that we don't return it, but the later code will flip it's sign.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93822

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

[PATCH] D93822: [clang-tidy] Add check for implicit widening of multiplication result

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 335169.
lebedev.ri marked 4 inline comments as done.
lebedev.ri added a comment.

@aaron.ballman thank you for taking a look!
Addressing all review notes other than `ssize_t` and `static_cast<>()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93822

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp
  
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-implicit-widening-of-multiplication-result.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-array-subscript-expression.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-char.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-extint.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-int.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-pointer-offset.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-short.cpp
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp

Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -10097,7 +10097,12 @@
 return getVectorType(getCorrespondingUnsignedType(VTy->getElementType()),
  VTy->getNumElements(), VTy->getVectorKind());
 
-  // For enums, we return the unsigned version of the base type.
+  // For _ExtInt, return an unsigned _ExtInt with same width.
+  if (const auto *EITy = T->getAs())
+return getExtIntType(/*IsUnsigned=*/true, EITy->getNumBits());
+
+  // For enums, get the underlying integer type of the enum, and let the general
+  // integer type signchanging code handle it.
   if (const auto *ETy = T->getAs())
 T = ETy->getDecl()->getIntegerType();
 
@@ -10150,6 +10155,74 @@
   }
 }
 
+QualType ASTContext::getCorrespondingSignedType(QualType T) const {
+  assert((T->hasUnsignedIntegerRepresentation() ||
+  T->isUnsignedFixedPointType()) &&
+ "Unexpected type");
+
+  // Turn <4 x unsigned int> -> <4 x signed int>
+  if (const auto *VTy = T->getAs())
+return getVectorType(getCorrespondingSignedType(VTy->getElementType()),
+ VTy->getNumElements(), VTy->getVectorKind());
+
+  // For _ExtInt, return a signed _ExtInt with same width.
+  if (const auto *EITy = T->getAs())
+return getExtIntType(/*IsUnsigned=*/false, EITy->getNumBits());
+
+  // For enums, get the underlying integer type of the enum, and let the general
+  // integer type signchanging code handle it.
+  if (const auto *ETy = T->getAs())
+T = ETy->getDecl()->getIntegerType();
+
+  switch (T->castAs()->getKind()) {
+  case BuiltinType::Char_U:
+  case BuiltinType::UChar:
+return SignedCharTy;
+  case BuiltinType::UShort:
+return ShortTy;
+  case BuiltinType::UInt:
+return IntTy;
+  case BuiltinType::ULong:
+return LongTy;
+  case BuiltinType::ULongLong:
+return LongLongTy;
+  case BuiltinType::UInt128:
+return Int128Ty;
+  // wchar_t is special. It is either unsigned or not, but when it's unsigned,
+  // there's no matching "signed wchar_t". Therefore we return the signed
+  // version of it's underlying type instead.
+  case BuiltinType::WChar_U:
+return getSignedWCharType();
+
+  case BuiltinType::UShortAccum:
+return ShortAccumTy;
+  case BuiltinType::UAccum:
+return AccumTy;
+  case BuiltinType::ULongAccum:
+return LongAccumTy;
+  case BuiltinType::SatUShortAccum:
+return SatShortAccumTy;
+  case BuiltinType::SatUAccum:
+return SatAccumTy;
+  case BuiltinType::SatULongAccum:
+return SatLongAccumTy;
+  case BuiltinType::UShortFract:
+return ShortFractTy;
+  case BuiltinType::UFract:
+return FractTy;
+  case BuiltinType::ULongFract:
+return LongFractTy;
+  case BuiltinType::SatUShortFract:
+return SatShortFractTy;
+  case BuiltinType::SatUFract:
+return SatFractTy;
+  case BuiltinType::SatULongFract:
+return SatLongFractTy;
+  default:
+llvm_unreachable("Unexpected unsigned integer or fixed point type");
+  }
+}
+
 ASTMutationListener::~ASTMutationListener() = default;
 
 void ASTMutationListener::DeducedReturnType(const FunctionDecl *FD,
Index: clang/include/clang/AST/ASTContext.h
===
--- clang/include/clang/AST/ASTContext.h
+++ 

[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

One other problem is somehow this test is failing 
https://github.com/llvm/llvm-project/blob/main/clang/test/SemaOpenCL/sampler_t_overload.cl#L6
 with this error.

  /tmp/clang/test/SemaOpenCL/sampler_t_overload.cl:6:30: error: initializer 
element is not a compile-time constant
  constant sampler_t glb_smp = 5;
   ^
  1 error generated.

Not sure what's going on but will continue to debug. Let me know if there's 
something simple that I am missing here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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

[clang] 292726b - [HIP, test] Fix use of undef FileCheck var

[Thomas Preud'homme via cfe-commits]

Author: Thomas Preud'homme
Date: 2021-04-04T19:30:49+01:00
New Revision: 292726b6443c7d7be4bb03af40cd3f60188b2ff7

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

LOG: [HIP, test] Fix use of undef FileCheck var

Clang test CodeGenCUDA/kernel-stub-name.cu uses never defined DKERN
variable in a CHECK-NOT directive. This commit replace the variable by a
regex, thereby avoiding the issue.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/test/CodeGenCUDA/kernel-stub-name.cu

Removed: 




diff  --git a/clang/test/CodeGenCUDA/kernel-stub-name.cu 
b/clang/test/CodeGenCUDA/kernel-stub-name.cu
index 0c504b612ea72..460dd6010e835 100644
--- a/clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ b/clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -126,4 +126,4 @@ void fun5() {
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HCKERN]]{{.*}}@[[CKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HNSKERN]]{{.*}}@[[NSKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HTKERN]]{{.*}}@[[TKERN]]
-// CHECK-NOT: call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@[[DKERN]]
+// CHECK-NOT: 
call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@{{[0-9]*}}



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

[PATCH] D99832: [HIP, test] Fix use of undef FileCheck var

[Thomas Preud'homme via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG292726b6443c: [HIP, test] Fix use of undef FileCheck var 
(authored by thopre).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99832

Files:
  clang/test/CodeGenCUDA/kernel-stub-name.cu


Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -126,4 +126,4 @@
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HCKERN]]{{.*}}@[[CKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HNSKERN]]{{.*}}@[[NSKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HTKERN]]{{.*}}@[[TKERN]]
-// CHECK-NOT: call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@[[DKERN]]
+// CHECK-NOT: 
call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@{{[0-9]*}}


Index: clang/test/CodeGenCUDA/kernel-stub-name.cu
===
--- clang/test/CodeGenCUDA/kernel-stub-name.cu
+++ clang/test/CodeGenCUDA/kernel-stub-name.cu
@@ -126,4 +126,4 @@
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HCKERN]]{{.*}}@[[CKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HNSKERN]]{{.*}}@[[NSKERN]]
 // CHECK: call{{.*}}@__hipRegisterFunction{{.*}}@[[HTKERN]]{{.*}}@[[TKERN]]
-// CHECK-NOT: call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@[[DKERN]]
+// CHECK-NOT: call{{.*}}@__hipRegisterFunction{{.*}}@[[HDKERN]]{{.*}}@{{[0-9]*}}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99831: [HIP-Clang, test] Fix use of undef FileCheck var

[Thomas Preud'homme via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa41b5100e438: [HIP-Clang, test] Fix use of undef FileCheck 
var (authored by thopre).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99831

Files:
  clang/test/CodeGenCUDA/device-stub.cu


Index: clang/test/CodeGenCUDA/device-stub.cu
===
--- clang/test/CodeGenCUDA/device-stub.cu
+++ clang/test/CodeGenCUDA/device-stub.cu
@@ -266,13 +266,13 @@
 // CUDANOGLOBALS-NOT: @{{.*}} = private constant{{.*}}
 // HIPNOGLOBALS-NOT: @{{.*}} = internal constant{{.*}}
 // NOGLOBALS-NOT: define internal void @__{{.*}}_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX:cuda|hip]]_module_ctor
-// NOGLOBALS-NOT: 
call{{.*}}[[PREFIX]]RegisterFatBinary{{.*}}__[[PREFIX]]_fatbin_wrapper
-// NOGLOBALS-NOT: call void @__[[PREFIX]]_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX]]_module_dtor
-// NOGLOBALS-NOT: call void @__[[PREFIX]]UnregisterFatBinary
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGLOBALS-NOT: 
call{{.*}}{{cuda|hip}}RegisterFatBinary{{.*}}__{{cuda|hip}}_fatbin_wrapper
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}_register_globals
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_dtor
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}UnregisterFatBinary
 
 // There should be no constructors/destructors if we have no GPU binary.
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_register_globals
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_ctor
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_dtor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_register_globals
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_dtor


Index: clang/test/CodeGenCUDA/device-stub.cu
===
--- clang/test/CodeGenCUDA/device-stub.cu
+++ clang/test/CodeGenCUDA/device-stub.cu
@@ -266,13 +266,13 @@
 // CUDANOGLOBALS-NOT: @{{.*}} = private constant{{.*}}
 // HIPNOGLOBALS-NOT: @{{.*}} = internal constant{{.*}}
 // NOGLOBALS-NOT: define internal void @__{{.*}}_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX:cuda|hip]]_module_ctor
-// NOGLOBALS-NOT: call{{.*}}[[PREFIX]]RegisterFatBinary{{.*}}__[[PREFIX]]_fatbin_wrapper
-// NOGLOBALS-NOT: call void @__[[PREFIX]]_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX]]_module_dtor
-// NOGLOBALS-NOT: call void @__[[PREFIX]]UnregisterFatBinary
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGLOBALS-NOT: call{{.*}}{{cuda|hip}}RegisterFatBinary{{.*}}__{{cuda|hip}}_fatbin_wrapper
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}_register_globals
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_dtor
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}UnregisterFatBinary
 
 // There should be no constructors/destructors if we have no GPU binary.
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_register_globals
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_ctor
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_dtor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_register_globals
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_dtor
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a41b510 - [HIP-Clang, test] Fix use of undef FileCheck var

[Thomas Preud'homme via cfe-commits]

Author: Thomas Preud'homme
Date: 2021-04-04T19:30:27+01:00
New Revision: a41b5100e43810694c09469bc725f560e7ef239f

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

LOG: [HIP-Clang, test] Fix use of undef FileCheck var

Commit 8129521318accc44c2a009647572f6ebd3fc56dd changed a line defining
PREFIX in clang test CodeGenCUDA/device-stub.cu into a CHECK-NOT
directive. All following lines using PREFIX are therefore using an
undefined variable since the pattern defining PREFIX is not supposed to
occur and CHECK-NOT are checked independently.

This commit replaces all uses of PREFIX by the regex used to define it,
thereby avoiding the problem.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/test/CodeGenCUDA/device-stub.cu

Removed: 




diff  --git a/clang/test/CodeGenCUDA/device-stub.cu 
b/clang/test/CodeGenCUDA/device-stub.cu
index e1fa931a13da9..9bac4e81a54a2 100644
--- a/clang/test/CodeGenCUDA/device-stub.cu
+++ b/clang/test/CodeGenCUDA/device-stub.cu
@@ -266,13 +266,13 @@ void hostfunc(void) { kernelfunc<<<1, 1>>>(1, 1, 1); }
 // CUDANOGLOBALS-NOT: @{{.*}} = private constant{{.*}}
 // HIPNOGLOBALS-NOT: @{{.*}} = internal constant{{.*}}
 // NOGLOBALS-NOT: define internal void @__{{.*}}_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX:cuda|hip]]_module_ctor
-// NOGLOBALS-NOT: 
call{{.*}}[[PREFIX]]RegisterFatBinary{{.*}}__[[PREFIX]]_fatbin_wrapper
-// NOGLOBALS-NOT: call void @__[[PREFIX]]_register_globals
-// NOGLOBALS-NOT: define internal void @__[[PREFIX]]_module_dtor
-// NOGLOBALS-NOT: call void @__[[PREFIX]]UnregisterFatBinary
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGLOBALS-NOT: 
call{{.*}}{{cuda|hip}}RegisterFatBinary{{.*}}__{{cuda|hip}}_fatbin_wrapper
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}_register_globals
+// NOGLOBALS-NOT: define internal void @__{{cuda|hip}}_module_dtor
+// NOGLOBALS-NOT: call void @__{{cuda|hip}}UnregisterFatBinary
 
 // There should be no constructors/destructors if we have no GPU binary.
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_register_globals
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_ctor
-// NOGPUBIN-NOT: define internal void @__[[PREFIX]]_module_dtor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_register_globals
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_ctor
+// NOGPUBIN-NOT: define internal void @__{{cuda|hip}}_module_dtor



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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

[Josh Haberman via Phabricator via cfe-commits]

haberman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

aaron.ballman wrote:
> haberman wrote:
> > haberman wrote:
> > > aaron.ballman wrote:
> > > > haberman wrote:
> > > > > aaron.ballman wrote:
> > > > > > This functionality belongs in SemaStmtAttr.cpp, I think.
> > > > > That is where I had originally put it, but that didn't work for 
> > > > > templates. The semantic checks can only be performed at instantiation 
> > > > > time. `ActOnAttributedStmt` seems to be the right hook point where I 
> > > > > can evaluate the semantic checks for both template and non-template 
> > > > > functions (with template functions getting checked at instantiation 
> > > > > time).
> > > > I disagree that `ActOnAttributedStmt()` is the correct place for this 
> > > > checking -- template checking should occur when the template is 
> > > > instantiated, same as happens for declaration attributes. I'd like to 
> > > > see this functionality moved to SemaStmtAttr.cpp. Keeping the attribute 
> > > > logic together and following the same patterns is what allows us to 
> > > > tablegenerate more of the attribute logic. Statement attributes are 
> > > > just starting to get more such automation.
> > > I tried commenting out this code and adding the following code into 
> > > `handleMustTailAttr()` in `SemaStmtAttr.cpp`:
> > > 
> > > ```
> > >   if (!S.checkMustTailAttr(St, MTA))
> > > return nullptr;
> > > ```
> > > 
> > > This caused my test cases related to templates to fail. It also seemed to 
> > > break test cases related to `JumpDiagnostics`. My interpretation of this 
> > > is that `handleMustTailAttr()` is called during parsing only, and cannot 
> > > catch errors at template instantiation time or that require a more 
> > > complete AST.
> > > 
> > > What am I missing? Where in SemaStmtAttr.cpp are you suggesting that I 
> > > put this check?
> > Scratch the part about `JumpDiagnostics`, that was me failing to call 
> > `S.setFunctionHasMustTail()`. I added that and now the `JumpDiagnostics` 
> > tests pass.
> > 
> > But the template test cases still fail, and I can't find any hook point in 
> > `SemaStmtAttr.cpp` that will let me evaluate these checks at template 
> > instantiation time.
> I think there's a bit of an architectural mixup, but I'm curious if @rsmith 
> agrees before anyone starts doing work to make changes.
> 
> When transforming declarations, `RebuildWhatever()` calls the 
> `ActOnWhatever()` function which calls `ProcessDeclAttributeList()` so that 
> attributes are processed. `RebuildAttributedStmt()` similarly calls 
> `ActOnAttributedStmt()`. However, `ActOnAttributedStmt()` doesn't call 
> `ProcessStmtAttributes()` -- the logic is reversed so that 
> `ProcessStmtAttributes()` is what calls `ActOnAttributedStmt()`.
> 
> I think the correct answer is to switch the logic so that 
> `ActOnAttributedStmt()` calls `ProcessStmtAttributes()`, then the template 
> logic should automatically work.
> I think the correct answer is to switch the logic so that 
> ActOnAttributedStmt() calls ProcessStmtAttributes()

I think this would require `ProcessStmtAttributes()` to be split into two 
separate functions. Currently that function is doing two separate things:

1. Translation of `ParsedAttr` into various subclasses of `Attr`.
2. Validation that the attribute is semantically valid.

The function signature for `ActOnAttributedStmt()` uses `Attr` (not 
`ParsedAttr`), so (1) must happen during the parse, before 
`ActOnAttributedStmt()` is called. But (2) must be deferred until template 
instantiation time for some cases, like `musttail`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

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

[PATCH] D99852: [Driver] Detect libstdc++ include paths for native gcc (-m32 and -m64) on Debian i386

[Fangrui Song via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe92d2b80c6c9: [Driver] Detect libstdc++ include paths for 
native gcc (-m32 and -m64) on… (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99852

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/Inputs/debian_i386_tree/lib/i386-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_i386_tree/lib/x86_64-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_i386_tree/lib64/.keep
  clang/test/Driver/Inputs/debian_i386_tree/usr/include/c++/10/backward/.keep
  
clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/.keep
  
clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/64/.keep
  clang/test/Driver/Inputs/debian_i386_tree/usr/include/x86_64-linux-gnu/.keep
  
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/64/crtbegin.o
  
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/crtbegin.o
  
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/crtend.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crt1.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crti.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crtn.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib/x86_64-linux-gnu/.keep
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/.keep
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crt1.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crti.o
  clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crtn.o
  clang/test/Driver/linux-cross.cpp


Index: clang/test/Driver/linux-cross.cpp
===
--- clang/test/Driver/linux-cross.cpp
+++ clang/test/Driver/linux-cross.cpp
@@ -49,6 +49,55 @@
 // DEBIAN_X86_64_M32-SAME: {{^}} "-L[[SYSROOT]]/lib"
 // DEBIAN_X86_64_M32-SAME: {{^}} "-L[[SYSROOT]]/usr/lib"
 
+/// Test native GCC installation on Debian i386.
+// RUN: %clang -### %s --target=i686-linux-gnu 
--sysroot=%S/Inputs/debian_i386_tree \
+// RUN:   -resource-dir=%S/Inputs/resource_dir --stdlib=platform 
--rtlib=platform 2>&1 | FileCheck %s --check-prefix=DEBIAN_I686
+// DEBIAN_I686:  "-resource-dir" "[[RESOURCE:[^"]+]]"
+// DEBIAN_I686:  "-internal-isystem"
+// DEBIAN_I686-SAME: {{^}} 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/c++/10"
+/// Debian specific - the path component after 'include' is i386-linux-gnu even
+/// though the installation is i686-linux-gnu.
+// DEBIAN_I686-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/i386-linux-gnu/c++/10"
+// DEBIAN_I686-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/c++/10/backward"
+// DEBIAN_I686-SAME: {{^}} "-internal-isystem" "[[RESOURCE]]/include"
+// DEBIAN_I686-SAME: {{^}} "-internal-isystem" "[[SYSROOT]]/usr/local/include"
+/// This resolves to /usr/i686-linux-gnu/include. Because it does not exist,
+/// having it does no harm albeit not ideal.
+// DEBIAN_I686-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../i686-linux-gnu/include"
+// DEBIAN_I686:  "-internal-externc-isystem"
+// DEBIAN_I686-SAME: {{^}} "[[SYSROOT]]/usr/include/i386-linux-gnu"
+// DEBIAN_I686:  "-L
+// DEBIAN_I686-SAME: {{^}}[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/10"
+// DEBIAN_I686-SAME: {{^}} "-L[[SYSROOT]]/lib/i386-linux-gnu"
+// DEBIAN_I686-SAME: {{^}} "-L[[SYSROOT]]/usr/lib/i386-linux-gnu"
+// DEBIAN_I686-SAME: {{^}} "-L[[SYSROOT]]/lib"
+// DEBIAN_I686-SAME: {{^}} "-L[[SYSROOT]]/usr/lib"
+
+/// Test -m64 on Debian i386.
+// RUN: %clang -### %s --target=i686-linux-gnu 
--sysroot=%S/Inputs/debian_i386_tree -m64 \
+// RUN:   -resource-dir=%S/Inputs/resource_dir --stdlib=platform 
--rtlib=platform 2>&1 | FileCheck %s --check-prefix=DEBIAN_I686_M64
+// DEBIAN_I686_M64:  "-resource-dir" "[[RESOURCE:[^"]+]]"
+// DEBIAN_I686_M64:  "-internal-isystem"
+// DEBIAN_I686_M64-SAME: {{^}} 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/c++/10"
+/// Debian specific - the path component after 'include' is i386-linux-gnu even
+/// though the installation is i686-linux-gnu.
+// DEBIAN_I686_M64-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/i386-linux-gnu/c++/10/64"
+// DEBIAN_I686_M64-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT:[^"]+]]/usr/lib/gcc/i686-linux-gnu/10/../../../../include/c++/10/backward"
+// DEBIAN_I686_M64-SAME: {{^}} "-internal-isystem" "[[RESOURCE]]/include"
+// DEBIAN_I686_M64-SAME: {{^}} "-internal-isystem" 
"[[SYSROOT]]/usr/local/include"
+// DEBIAN_I686_M64-SAME: {{^}} "-internal-isystem" 

[clang] e92d2b8 - [Driver] Detect libstdc++ include paths for native gcc (-m32 and -m64) on Debian i386

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2021-04-04T10:15:12-07:00
New Revision: e92d2b80c6c913b5c506df06a913a2ecbf761617

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

LOG: [Driver] Detect libstdc++ include paths for native gcc (-m32 and -m64) on 
Debian i386

Take gcc-8 on Debian i386 as an example. The target-specific libstdc++ search
path (`GPLUSPLUS_TOOL_INCLUDE_DIR`) uses the multiarch name `i386-linux-gnu`,
instead of the triple of the GCC installation `i686-linux-gnu` (the directory
under `usr/lib/gcc/`):

```
/usr/include/c++/8
/usr/include/i386-linux-gnu/c++/8
/usr/include/c++/8/backward
```

Clang currently detects 
`/usr/lib/gcc/i686-linux-gnu/8/../../../include/i686-linux-gnu/c++/8`.
This patch changes the second i686-linux-gnu to i386-linux-gnu so that
`/usr/include/i386-linux-gnu/c++/8` can be found.

Fix PR49827 - this was somehow regressed by my previous libstdc++ include path
cleanups and fixes for gcc-cross, but it seems that the paths were never 
properly tested before.

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

Added: 
clang/test/Driver/Inputs/debian_i386_tree/lib/i386-linux-gnu/.keep
clang/test/Driver/Inputs/debian_i386_tree/lib/x86_64-linux-gnu/.keep
clang/test/Driver/Inputs/debian_i386_tree/lib64/.keep
clang/test/Driver/Inputs/debian_i386_tree/usr/include/c++/10/backward/.keep

clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/.keep

clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/64/.keep
clang/test/Driver/Inputs/debian_i386_tree/usr/include/x86_64-linux-gnu/.keep

clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/64/crtbegin.o

clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/crtbegin.o

clang/test/Driver/Inputs/debian_i386_tree/usr/lib/gcc/i686-linux-gnu/10/crtend.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crt1.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crti.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/i386-linux-gnu/crtn.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib/x86_64-linux-gnu/.keep
clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/.keep
clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crt1.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crti.o
clang/test/Driver/Inputs/debian_i386_tree/usr/lib64/crtn.o

Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/linux-cross.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index c08972f0d7008..245c0234de640 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2983,9 +2983,13 @@ Generic_GCC::addGCCLibStdCxxIncludePaths(const 
llvm::opt::ArgList ,
   TripleStr, Multilib.includeSuffix(), DriverArgs, CC1Args))
 return true;
   // Detect Debian g++-multiarch-incdir.
diff .
+  StringRef DebianMultiarch =
+  GCCInstallation.getTriple().getArch() == llvm::Triple::x86
+  ? "i386-linux-gnu"
+  : TripleStr;
   if (addLibStdCXXIncludePaths(LibDir.str() + "/../include/c++/" + 
Version.Text,
-   TripleStr, Multilib.includeSuffix(), DriverArgs,
-   CC1Args, /*Debian=*/true))
+   DebianMultiarch, Multilib.includeSuffix(),
+   DriverArgs, CC1Args, /*Debian=*/true))
 return true;
 
   // Otherwise, fall back on a bunch of options which don't use multiarch

diff  --git 
a/clang/test/Driver/Inputs/debian_i386_tree/lib/i386-linux-gnu/.keep 
b/clang/test/Driver/Inputs/debian_i386_tree/lib/i386-linux-gnu/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/debian_i386_tree/lib/x86_64-linux-gnu/.keep 
b/clang/test/Driver/Inputs/debian_i386_tree/lib/x86_64-linux-gnu/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/Inputs/debian_i386_tree/lib64/.keep 
b/clang/test/Driver/Inputs/debian_i386_tree/lib64/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/debian_i386_tree/usr/include/c++/10/backward/.keep 
b/clang/test/Driver/Inputs/debian_i386_tree/usr/include/c++/10/backward/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/.keep
 
b/clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/debian_i386_tree/usr/include/i386-linux-gnu/c++/10/64/.keep
 

[PATCH] D99861: [Clang] Record tokens in attribute arguments for user-defined C++/C2x attributes

[Josh Junon via Phabricator via cfe-commits]

Qix- created this revision.
Qix- added a reviewer: aaron.ballman.
Qix- added a project: clang.
Herald added a subscriber: mgorny.
Qix- requested review of this revision.
Herald added a subscriber: cfe-commits.

Currently, user-defined attributes (e.g. those registered via Clang plugins) 
don't hold much information or allow for much to be done with them, as their 
argument tokens are discarded entirely in almost all cases.

However, since they are quite flexible with their syntax (pretty much anything 
can go in there), it would be massively helpful if plugins could be handed the 
pre-processed and parsed tokens as a listed to be consumed by third-party 
plugins and the like.

This diff creates a trailing data list for `ParsedAttr` objects and places the 
"recorded" tokens there from the lexer. I would have piggy-backed off of the 
normal backtrack system but unfortunately it doesn't call the handler for 
tokens being replayed from the backtrack cache, which in many cases we *do* 
care about. So I had to create a second recording callback.

The new plugin directory shows how this would be used from a plugin.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99861

Files:
  clang/examples/CMakeLists.txt
  clang/examples/PrintAttributeTokens/CMakeLists.txt
  clang/examples/PrintAttributeTokens/PrintAttributeTokens.cpp
  clang/examples/PrintAttributeTokens/PrintAttributeTokens.exports
  clang/examples/PrintAttributeTokens/README.txt
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/ParsedAttr.cpp
  clang/test/Frontend/plugin-print-attr-tokens.cpp

Index: clang/test/Frontend/plugin-print-attr-tokens.cpp
===
--- /dev/null
+++ clang/test/Frontend/plugin-print-attr-tokens.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang -cc1 -load %llvmshlibdir/PrintAttributeTokens%pluginext -fsyntax-only -ast-dump -verify %s
+// REQUIRES: plugins, examples
+
+// expected-no-diagnostics
+[[print_tokens(
+the, mitochondria,
+, Of::The($cell))]] void
+fn1a() {}
+[[plugin::print_tokens("a string")]] void fn1b() {}
+[[plugin::print_tokens()]] void fn1c() {}
+[[plugin::print_tokens(some_ident)]] void fn1d() {}
+[[plugin::print_tokens(int)]] void fn1e() {}
Index: clang/lib/Sema/ParsedAttr.cpp
===
--- clang/lib/Sema/ParsedAttr.cpp
+++ clang/lib/Sema/ParsedAttr.cpp
@@ -45,10 +45,11 @@
   else if (HasParsedType)
 return totalSizeToAlloc(0, 0, 0, 1, 0);
+detail::PropertyData, Token>(0, 0, 0, 1, 0, 0);
   return totalSizeToAlloc(NumArgs, 0, 0, 0, 0);
+  detail::PropertyData, Token>(NumArgs, 0, 0, 0, 0,
+   NumTokens);
 }
 
 AttributeFactory::AttributeFactory() {
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -4096,13 +4096,39 @@
   LO.CPlusPlus ? ParsedAttr::AS_CXX11 : ParsedAttr::AS_C2x;
 
   // If the attribute isn't known, we will not attempt to parse any
-  // arguments.
+  // arguments. Instead, we just record the tokens and add the attribute
+  // directly. The recording happens here because this is the only place
+  // where user-defined (via plugins) attributes are parsed, and thus
+  // they care about the token stream directly.
   if (!hasAttribute(LO.CPlusPlus ? AttrSyntax::CXX : AttrSyntax::C, ScopeName,
 AttrName, getTargetInfo(), getLangOpts())) {
-// Eat the left paren, then skip to the ending right paren.
+// Begin recording session.
+SmallVector RecordedTokens;
+assert(!PP.hasTokenRecorder());
+PP.setTokenRecorder(
+[](const Token ) { RecordedTokens.push_back(Tok); });
+
+// Eat the left paren.
 ConsumeParen();
+
+// skip to the ending right paren.
 SkipUntil(tok::r_paren);
-return false;
+
+// End recording session.
+PP.setTokenRecorder(nullptr);
+
+// Add new attribute with the token list.
+// We assert that we have at least one token,
+// since we have to ignore the final r_paren.
+assert(RecordedTokens.size() > 0);
+Attrs.addNew(
+AttrName,
+SourceRange(ScopeLoc.isValid() ? ScopeLoc : AttrNameLoc, AttrNameLoc),
+ScopeName, ScopeLoc, nullptr, 0,
+getLangOpts().CPlusPlus ? ParsedAttr::AS_CXX11 : ParsedAttr::AS_C2x,
+RecordedTokens.data(), RecordedTokens.size() - 2);
+
+return true;
   }
 
   if (ScopeName && (ScopeName->isStr("gnu") || ScopeName->isStr("__gnu__"))) {
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -2828,7 +2828,7 

[PATCH] D99755: Remove clang/runtime and `COMPILER_RT_INSTALL_PATH`

[John Ericson via Phabricator via cfe-commits]

Ericson2314 updated this revision to Diff 335154.
Ericson2314 added a comment.

Put on top of D99860 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99755

Files:
  clang/CMakeLists.txt
  clang/runtime/CMakeLists.txt
  clang/runtime/compiler-rt/clang_linux_test_input.c
  llvm/runtimes/CMakeLists.txt

Index: llvm/runtimes/CMakeLists.txt
===
--- llvm/runtimes/CMakeLists.txt
+++ llvm/runtimes/CMakeLists.txt
@@ -1,6 +1,6 @@
 # TODO: This file assumes the Clang toolchain so it'd be better if it lived in
-# Clang, except there already is clang/runtime directory which contains
-# similar although simpler functionality. We should figure out how to merge
+# Clang, except there already is runtimes directory which contains
+# similar functionality. We should figure out how to merge
 # the two files.
 
 # TODO: Selecting runtimes should be always performed inside the runtimes
Index: clang/runtime/compiler-rt/clang_linux_test_input.c
===
--- clang/runtime/compiler-rt/clang_linux_test_input.c
+++ /dev/null
@@ -1,4 +0,0 @@
-// This file is used to check if we can produce working executables
-// for i386 and x86_64 archs on Linux.
-#include 
-int main(){}
Index: clang/runtime/CMakeLists.txt
===
--- clang/runtime/CMakeLists.txt
+++ /dev/null
@@ -1,167 +0,0 @@
-# TODO: Set the install directory.
-
-include(ExternalProject)
-
-set(known_subdirs
-  "libcxx"
-  )
-
-foreach (dir ${known_subdirs})
-  if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/CMakeLists.txt)
-add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/${dir})
-  endif()
-endforeach()
-
-function(get_ext_project_build_command out_var target)
-  if (CMAKE_GENERATOR MATCHES "Make")
-# Use special command for Makefiles to support parallelism.
-set(${out_var} "$(MAKE)" "${target}" PARENT_SCOPE)
-  else()
-set(${out_var} ${CMAKE_COMMAND} --build . --target ${target}
---config $ PARENT_SCOPE)
-  endif()
-endfunction()
-
-set(COMPILER_RT_SRC_ROOT ${LLVM_MAIN_SRC_DIR}/projects/compiler-rt)
-# Fallback to the external path, if the other one isn't available.
-# This is the same behavior (try "internal", then check the LLVM_EXTERNAL_...
-# variable) as in add_llvm_external_project
-if(NOT EXISTS ${COMPILER_RT_SRC_ROOT})
-  # We don't want to set it if LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR is ""
-  if(LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR)
-set(COMPILER_RT_SRC_ROOT ${LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR})
-  endif()
-endif()
-
-if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND EXISTS ${COMPILER_RT_SRC_ROOT}/)
-
-  # Add compiler-rt as an external project.
-  set(COMPILER_RT_PREFIX ${CMAKE_BINARY_DIR}/projects/compiler-rt)
-
-  set(STAMP_DIR ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-stamps/)
-  set(BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/compiler-rt-bins/)
-
-  add_custom_target(compiler-rt-clear
-COMMAND ${CMAKE_COMMAND} -E remove_directory ${BINARY_DIR}
-COMMAND ${CMAKE_COMMAND} -E remove_directory ${STAMP_DIR}
-COMMENT "Clobberring compiler-rt build and stamp directories"
-)
-
-  # Find all variables that start with COMPILER_RT and populate a variable with
-  # them.
-  get_cmake_property(variableNames VARIABLES)
-  foreach(variableName ${variableNames})
-if(variableName MATCHES "^COMPILER_RT")
-  string(REPLACE ";" "\;" value "${${variableName}}")
-  list(APPEND COMPILER_RT_PASSTHROUGH_VARIABLES
--D${variableName}=${value})
-endif()
-  endforeach()
-
-  set(compiler_rt_configure_deps)
-  if(TARGET cxx-headers)
-list(APPEND compiler_rt_configure_deps "cxx-headers")
-  endif()
-  if(LLVM_INCLUDE_TESTS)
-list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
-  endif()
-
-  ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${compiler_rt_configure_deps}
-PREFIX ${COMPILER_RT_PREFIX}
-SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
-STAMP_DIR ${STAMP_DIR}
-BINARY_DIR ${BINARY_DIR}
-CMAKE_ARGS ${CLANG_COMPILER_RT_CMAKE_ARGS}
-   -DCMAKE_C_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-   -DCMAKE_CXX_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang++
-   -DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang
-   -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-   -DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}
-   -DLLVM_CONFIG_PATH=${LLVM_RUNTIME_OUTPUT_INTDIR}/llvm-config
-   -DLLVM_LIT_ARGS=${LLVM_LIT_ARGS}
-   -DCOMPILER_RT_OUTPUT_DIR=${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}
-   -DCOMPILER_RT_EXEC_OUTPUT_DIR=${LLVM_RUNTIME_OUTPUT_INTDIR}
-   -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}/lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION}
-   

[PATCH] D99755: Remove clang/runtime and `COMPILER_RT_INSTALL_PATH`

[John Ericson via Phabricator via cfe-commits]

Ericson2314 added a comment.

See also D99860 . We may still want to remove 
`clang/runtime`, but I don't think it's necessary. I will turn this revision 
into one on top of that just for for removing `clang/runtime`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99755

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

[PATCH] D99860: Remove `COMPILER_RT_INSTALL_PATH`

[John Ericson via Phabricator via cfe-commits]

Ericson2314 created this revision.
Herald added a subscriber: mgorny.
Ericson2314 requested review of this revision.
Herald added projects: clang, Sanitizers.
Herald added subscribers: Sanitizers, cfe-commits.

It turns out we don't neeed to remove `clang/runtime` to make this work,
as @phosek thought might be acceptable is in fact not.

To do this, we just set `CMAKE_INSTALL_PREFIX` rather than
`COMPILER_RT_INSTALL_PATH` in `clang/runtime` in the child CMake
invocation. Since it's a separate CMake invocation, we don't have to
worry about mutation "bleeding over" and effecting other projects.

However I am still worrie about redefining of `CMAKE_INSTALL_PREIX` in
`compiler-rt/cmake/base-config-ix.cmake`. This occurs under
`LLVM_TREE_AVAILABLE`. If this is just for separate compiler-rt builds
(separate invocation of CMake, that is), this is fine. But if on the
other hand this is for combination builds in a single CMake run, then
this sort of redefinition is no good as it will effect more than
compiler-rt.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99860

Files:
  clang/runtime/CMakeLists.txt
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/cmake/base-config-ix.cmake
  compiler-rt/include/CMakeLists.txt
  compiler-rt/lib/dfsan/CMakeLists.txt

Index: compiler-rt/lib/dfsan/CMakeLists.txt
===
--- compiler-rt/lib/dfsan/CMakeLists.txt
+++ compiler-rt/lib/dfsan/CMakeLists.txt
@@ -62,4 +62,4 @@
DEPENDS done_abilist.txt libc_ubuntu1404_abilist.txt)
 add_dependencies(dfsan dfsan_abilist)
 install(FILES ${dfsan_abilist_filename}
-DESTINATION ${COMPILER_RT_INSTALL_PATH}/share)
+DESTINATION share)
Index: compiler-rt/include/CMakeLists.txt
===
--- compiler-rt/include/CMakeLists.txt
+++ compiler-rt/include/CMakeLists.txt
@@ -69,22 +69,22 @@
 install(FILES ${SANITIZER_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/sanitizer)
+  DESTINATION include/sanitizer)
 # Install fuzzer headers.
 install(FILES ${FUZZER_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/fuzzer)
+  DESTINATION include/fuzzer)
 # Install xray headers.
 install(FILES ${XRAY_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/xray)
+  DESTINATION include/xray)
 # Install profile headers.
 install(FILES ${PROFILE_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/profile)
+  DESTINATION include/profile)
 
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDEs.
   add_custom_target(install-compiler-rt-headers
Index: compiler-rt/cmake/base-config-ix.cmake
===
--- compiler-rt/cmake/base-config-ix.cmake
+++ compiler-rt/cmake/base-config-ix.cmake
@@ -42,7 +42,7 @@
   # Setup the paths where compiler-rt runtimes and headers should be stored.
   set(COMPILER_RT_OUTPUT_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION})
   set(COMPILER_RT_EXEC_OUTPUT_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-  set(COMPILER_RT_INSTALL_PATH lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
+  set(CMAKE_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX}lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests."
  ${LLVM_INCLUDE_TESTS})
   option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered"
@@ -68,8 +68,6 @@
 "Path where built compiler-rt libraries should be stored.")
   set(COMPILER_RT_EXEC_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin CACHE PATH
 "Path where built compiler-rt executables should be stored.")
-  set(COMPILER_RT_INSTALL_PATH ${CMAKE_INSTALL_PREFIX} CACHE PATH
-"Path where built compiler-rt libraries should be installed.")
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests." OFF)
   option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered" OFF)
   # Use a host compiler to compile/link tests.
@@ -92,12 +90,12 @@
   set(COMPILER_RT_LIBRARY_OUTPUT_DIR
 ${COMPILER_RT_OUTPUT_DIR})
   set(COMPILER_RT_LIBRARY_INSTALL_DIR
-${COMPILER_RT_INSTALL_PATH})
+"")
 else(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
   set(COMPILER_RT_LIBRARY_OUTPUT_DIR
 ${COMPILER_RT_OUTPUT_DIR}/lib/${COMPILER_RT_OS_DIR})
   set(COMPILER_RT_LIBRARY_INSTALL_DIR
-${COMPILER_RT_INSTALL_PATH}/lib/${COMPILER_RT_OS_DIR})
+lib/${COMPILER_RT_OS_DIR})
 endif()
 
 if(APPLE)
Index: 

[PATCH] D99755: Remove clang/runtime and `COMPILER_RT_INSTALL_PATH`

[John Ericson via Phabricator via cfe-commits]

Ericson2314 updated this revision to Diff 335149.
Ericson2314 added a comment.

Remove stray `COMPILER_RT_INSTALL_PATH`

I am uncertain about is the redefining of `CMAKE_INSTALL_PREIX` in
`compiler-rt/cmake/base-config-ix.cmake`. This occurs under
`LLVM_TREE_AVAILABLE`. If this is just for separate compiler-rt builds
(separate invocation of CMake, that is), this is fine. But if on the other hand
this is for combination builds in a single CMake run, then this sort of
redefinition is no good as it will effect more than compiler-rt.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99755

Files:
  clang/CMakeLists.txt
  clang/runtime/CMakeLists.txt
  clang/runtime/compiler-rt/clang_linux_test_input.c
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/cmake/base-config-ix.cmake
  compiler-rt/include/CMakeLists.txt
  compiler-rt/lib/dfsan/CMakeLists.txt
  llvm/runtimes/CMakeLists.txt

Index: llvm/runtimes/CMakeLists.txt
===
--- llvm/runtimes/CMakeLists.txt
+++ llvm/runtimes/CMakeLists.txt
@@ -1,6 +1,6 @@
 # TODO: This file assumes the Clang toolchain so it'd be better if it lived in
-# Clang, except there already is clang/runtime directory which contains
-# similar although simpler functionality. We should figure out how to merge
+# Clang, except there already is runtimes directory which contains
+# similar functionality. We should figure out how to merge
 # the two files.
 
 # TODO: Selecting runtimes should be always performed inside the runtimes
Index: compiler-rt/lib/dfsan/CMakeLists.txt
===
--- compiler-rt/lib/dfsan/CMakeLists.txt
+++ compiler-rt/lib/dfsan/CMakeLists.txt
@@ -62,4 +62,4 @@
DEPENDS done_abilist.txt libc_ubuntu1404_abilist.txt)
 add_dependencies(dfsan dfsan_abilist)
 install(FILES ${dfsan_abilist_filename}
-DESTINATION ${COMPILER_RT_INSTALL_PATH}/share)
+DESTINATION share)
Index: compiler-rt/include/CMakeLists.txt
===
--- compiler-rt/include/CMakeLists.txt
+++ compiler-rt/include/CMakeLists.txt
@@ -69,22 +69,22 @@
 install(FILES ${SANITIZER_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/sanitizer)
+  DESTINATION include/sanitizer)
 # Install fuzzer headers.
 install(FILES ${FUZZER_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/fuzzer)
+  DESTINATION include/fuzzer)
 # Install xray headers.
 install(FILES ${XRAY_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/xray)
+  DESTINATION include/xray)
 # Install profile headers.
 install(FILES ${PROFILE_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/profile)
+  DESTINATION include/profile)
 
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDEs.
   add_custom_target(install-compiler-rt-headers
Index: compiler-rt/cmake/base-config-ix.cmake
===
--- compiler-rt/cmake/base-config-ix.cmake
+++ compiler-rt/cmake/base-config-ix.cmake
@@ -42,7 +42,7 @@
   # Setup the paths where compiler-rt runtimes and headers should be stored.
   set(COMPILER_RT_OUTPUT_DIR ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION})
   set(COMPILER_RT_EXEC_OUTPUT_DIR ${LLVM_RUNTIME_OUTPUT_INTDIR})
-  set(COMPILER_RT_INSTALL_PATH lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
+  set(CMAKE_INSTALL_PREFIX ${CMAKE_INSTALL_PREFIX}lib${LLVM_LIBDIR_SUFFIX}/clang/${CLANG_VERSION})
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests."
  ${LLVM_INCLUDE_TESTS})
   option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered"
@@ -68,8 +68,6 @@
 "Path where built compiler-rt libraries should be stored.")
   set(COMPILER_RT_EXEC_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin CACHE PATH
 "Path where built compiler-rt executables should be stored.")
-  set(COMPILER_RT_INSTALL_PATH ${CMAKE_INSTALL_PREFIX} CACHE PATH
-"Path where built compiler-rt libraries should be installed.")
   option(COMPILER_RT_INCLUDE_TESTS "Generate and build compiler-rt unit tests." OFF)
   option(COMPILER_RT_ENABLE_WERROR "Fail and stop if warning is triggered" OFF)
   # Use a host compiler to compile/link tests.
@@ -92,12 +90,12 @@
   set(COMPILER_RT_LIBRARY_OUTPUT_DIR
 ${COMPILER_RT_OUTPUT_DIR})
   set(COMPILER_RT_LIBRARY_INSTALL_DIR
-

[PATCH] D99852: [Driver] Detect libstdc++ include paths for native gcc (-m32 and -m64) on Debian i386

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru accepted this revision.
sylvestre.ledru added a comment.
This revision is now accepted and ready to land.

Many thanks. it fixed my issues!

/usr/include/i386-linux-gnu/c++/8 is indeed much nicer :)

Thanks for all your hard work on fixing the header detection. it was indeed too 
complex!

And, thanks for asking for review ;)

About the g++-multiarch-incdir.diff, I cced the gcc maintainer!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99852

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

[PATCH] D98070: [clang-tidy] Add option to ignore macros in readability-function-cognitive-complexity check.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri requested changes to this revision.
lebedev.ri added a comment.
This revision now requires changes to proceed.

In D98070#2616042 , @lebedev.ri wrote:

> Please also add a test with global `IgnoreMacros=1` and 
> `readability-function-cognitive-complexity.IgnoreMacros` unset.
> (The code is correct as-is, global `IgnoreMacros` should not affect the check 
> here.)
>
> I'm also somewhat worried about forward compatibility.
> If in future a mode will be implemented that allows to count the cost of 
> macro arguments,
> how'd we expose it in check's params, without breaking the existing 
> `IgnoreMacros=1` config support?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98070

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

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:5011
+!ValType->isFloatingType()) {
+  Diag(ExprRange.getBegin(), 
diag::err_atomic_op_needs_atomic_int_ptr_or_fp)
   << IsC11 << Ptr->getType() << Ptr->getSourceRange();

rjmccall wrote:
> Does LLVM support atomics on all floating-point types?
LLVM IR parser requires atomicrmw value operand must have size of power of 2, 
therefore LLVM does not support atomicrmw on x86_fp80 which has size of 80 
bytes. LLVM supports atomicrmw on all other floating-point types (bfloat, half, 
float, double, fp128, ppc_fp128).


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

https://reviews.llvm.org/D71726

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

[PATCH] D75844: [clang] Set begin loc on GNU attribute parsed attrs

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D75844#2668095 , @thakis wrote:

> The test fails on macOS: http://45.33.8.238/macm1/6821/step_6.txt
>
> Please take a look and revert for now if it takes a while to fix.

I've committed a speculative fix in 241d42c38226e46ff01b774da3167ec54420bf24 
.


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

https://reviews.llvm.org/D75844

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

[clang] 241d42c - Speculative fix for failing build bot.

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2021-04-04T10:58:56-04:00
New Revision: 241d42c38226e46ff01b774da3167ec54420bf24

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

LOG: Speculative fix for failing build bot.

This attempts to resolve an issue found by 
http://45.33.8.238/macm1/6821/step_6.txt

Added: 


Modified: 
clang/test/Parser/cxx0x-attributes.cpp

Removed: 




diff  --git a/clang/test/Parser/cxx0x-attributes.cpp 
b/clang/test/Parser/cxx0x-attributes.cpp
index 6ecbb5af14a4d..0b2bad6b00021 100644
--- a/clang/test/Parser/cxx0x-attributes.cpp
+++ b/clang/test/Parser/cxx0x-attributes.cpp
@@ -372,14 +372,14 @@ template struct TemplateStruct {};
 class FriendClassesWithAttributes {
   // We allow GNU-style attributes here
   template  friend class 
__attribute__((__type_visibility__("default"))) vector;
-  template  friend class 
__declspec(code_seg("whatever")) vector2;
+  template  friend class 
__declspec(code_seg("foo,whatever")) vector2;
   // But not C++11 ones
   template  friend class[[]] vector3; 
// expected-error {{an attribute list cannot appear 
here}}
   template  friend class 
[[clang::__type_visibility__(("default"))]] vector4; // expected-error {{an 
attribute list cannot appear here}}
 
   // Also allowed
   friend struct __attribute__((__type_visibility__("default"))) 
TemplateStruct;
-  friend struct __declspec(code_seg("whatever")) 
TemplateStruct;
+  friend struct __declspec(code_seg("foo,whatever")) 
TemplateStruct;
   friend struct[[]] TemplateStruct;   
// expected-error {{an attribute list cannot appear 
here}}
   friend struct [[clang::__type_visibility__("default")]] 
TemplateStruct; // expected-error {{an attribute 
list cannot appear here}}
 };



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

[PATCH] D75844: [clang] Set begin loc on GNU attribute parsed attrs

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

The test fails on macOS: http://45.33.8.238/macm1/6821/step_6.txt

Please take a look and revert for now if it takes a while to fix.


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

https://reviews.llvm.org/D75844

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

[PATCH] D93822: [clang-tidy] Add check for implicit widening of multiplication result

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:67
+  << FixItHint::CreateInsertion(E->getBeginLoc(),
+"(" + Ty.getAsString() + ")(")
+  << FixItHint::CreateInsertion(E->getEndLoc(), ")") << 
E->getSourceRange();

We might want to consider letting the user select between `static_cast` and 
C-style casts via an option.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:130
+  StringRef TyAsString =
+  IndexExprType->isSignedIntegerType() ? "ssize_t" : "size_t";
+

One thing that's awkward about this is that there's no portable `ssize_t` type 
-- that's a POSIX type but it doesn't exist on all platforms (like Windows). We 
shouldn't print out a typecast that's going to cause compile errors, but we 
also shouldn't use the underlying type for `ssize_t` as that may be incorrect 
for other target architectures.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/ImplicitWideningOfMultiplicationResultCheck.cpp:75
+  else if (Ty->isSignedIntegerType()) {
+assert(ETy->isUnsignedIntegerType() &&
+   "Expected source type to be signed.");

lebedev.ri wrote:
> aaron.ballman wrote:
> > Might be worth it to have tests around `signed char`, `unsigned char`, and 
> > `char` explicitly, as that gets awkward.
> Are you asking for test coverage, or for explicit handling of those types?
> I'll add tests.
Just test coverage to make sure we're doing the right thing for them and not 
triggering these assertions.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-implicit-widening-of-multiplication-result.rst:6-9
+The check diagnoses instances where a result of a multiplication is implicitly
+widened, and suggests (with fix-it) to either silence the code by making
+widening explicit, or to perform the multiplication in a wider type,
+to avoid the widening afterwards.

I think the documentation would be stronger if it explained why this diagnostic 
is helpful (show some examples of bugs that it catches and that the suggested 
fixes remove the bug).



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-implicit-widening-of-multiplication-result-char.cpp:10
+
+long t0(char a, char b) {
+  return a * b;

Can you also test the fixit behavior in addition to the diagnostic behavior (at 
least one test for each kind of fix-it)?



Comment at: clang/lib/AST/ASTContext.cpp:10158
+  if (const auto *ETy = T->getAs())
+T = ETy->getDecl()->getIntegerType();
+

lebedev.ri wrote:
> aaron.ballman wrote:
> > This looks to be getting the same value as in the 
> > `getCorrespondingUnsignedType()` call?
> Yep. Are both of them incorrect?
> I'm not sure what should be returned here.
I think I confused myself on the code, I think both are correct.



Comment at: clang/lib/AST/ASTContext.cpp:10204
+return SatLongFractTy;
+  default:
+llvm_unreachable("Unexpected unsigned integer or fixed point type");

lebedev.ri wrote:
> aaron.ballman wrote:
> > It looks like `_ExtInt` is missing from both this function and the 
> > corresponding unsigned one.
> Likewise, i'm not sure what should be returned for that.
> Just the original `_ExtInt`?
`_ExtInt` has `signed` and `unsigned` variants. You can use 
`ASTContext::getExtIntType()` to get the type with the correct signedness. 
However, I see now that it's not a builtin type (huh, I thought it was!), so 
it'd have to be above the `switch` but after the `enum` handling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93822

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

[PATCH] D96853: [clang][AVR] Support variable decorator '__flash'

[Ben Shi via Phabricator via cfe-commits]

benshi001 marked an inline comment as done.
benshi001 added a comment.

In D96853#2661168 , @Anastasia wrote:

> In D96853#2660443 , @benshi001 wrote:
>
>> In D96853#2659266 , @Anastasia 
>> wrote:
>>
>>> Btw is any pointer conversion between address space 1 and the default 
>>> address space allowed? I.e. is the following code valid:
>>>
>>>   __flash static const int var1[] = {111, 222, 333};
>>>   void foo(int*);
>>>   
>>>   foo(var1);
>>>
>>> or
>>>
>>>   __flash static const int var1[] = {111, 222, 333};
>>>   void foo(int*);
>>>   
>>>   foo((int*)var1);
>>>
>>> ?
>>
>> No. clang denied with `error: passing 'const 
>> __attribute__((address_space(1))) int *' to parameter of type 'const int *' 
>> changes address space of pointer` while avr-gcc accepted it.
>>
>> It seems I need more efforts to make clang-avr fully compatible with avr-gcc.
>
> Ok, it makes sense for clang to align with gcc in general but do you know 
> whether or where this conversions are described? By default if not specified 
> explicitly implicit conversions are always disallowed in  `ISO/IEC DTR 18037` 
> and explicit casts are always allowed but can yeild undefined behavior if 
> address spaces don't overlap.

I do not think clang needs to fully follow avr-gcc's way. Since avr-gcc 
generates wrong assembly that c code.

  __flash static const int var1[] = {111, 222, 333};
  void foo(int*);
  
  foo(var1);

`LDD` (which is used access data space) is generated in th function `foo`, 
while `LPM` is needed for accessing `var1` (in the program space).
avr-gcc silently accepts the c code with any warning and generates wrong 
assembly. And I think clang should rise an error .


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

https://reviews.llvm.org/D96853

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

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

haberman wrote:
> haberman wrote:
> > aaron.ballman wrote:
> > > haberman wrote:
> > > > aaron.ballman wrote:
> > > > > This functionality belongs in SemaStmtAttr.cpp, I think.
> > > > That is where I had originally put it, but that didn't work for 
> > > > templates. The semantic checks can only be performed at instantiation 
> > > > time. `ActOnAttributedStmt` seems to be the right hook point where I 
> > > > can evaluate the semantic checks for both template and non-template 
> > > > functions (with template functions getting checked at instantiation 
> > > > time).
> > > I disagree that `ActOnAttributedStmt()` is the correct place for this 
> > > checking -- template checking should occur when the template is 
> > > instantiated, same as happens for declaration attributes. I'd like to see 
> > > this functionality moved to SemaStmtAttr.cpp. Keeping the attribute logic 
> > > together and following the same patterns is what allows us to 
> > > tablegenerate more of the attribute logic. Statement attributes are just 
> > > starting to get more such automation.
> > I tried commenting out this code and adding the following code into 
> > `handleMustTailAttr()` in `SemaStmtAttr.cpp`:
> > 
> > ```
> >   if (!S.checkMustTailAttr(St, MTA))
> > return nullptr;
> > ```
> > 
> > This caused my test cases related to templates to fail. It also seemed to 
> > break test cases related to `JumpDiagnostics`. My interpretation of this is 
> > that `handleMustTailAttr()` is called during parsing only, and cannot catch 
> > errors at template instantiation time or that require a more complete AST.
> > 
> > What am I missing? Where in SemaStmtAttr.cpp are you suggesting that I put 
> > this check?
> Scratch the part about `JumpDiagnostics`, that was me failing to call 
> `S.setFunctionHasMustTail()`. I added that and now the `JumpDiagnostics` 
> tests pass.
> 
> But the template test cases still fail, and I can't find any hook point in 
> `SemaStmtAttr.cpp` that will let me evaluate these checks at template 
> instantiation time.
I think there's a bit of an architectural mixup, but I'm curious if @rsmith 
agrees before anyone starts doing work to make changes.

When transforming declarations, `RebuildWhatever()` calls the `ActOnWhatever()` 
function which calls `ProcessDeclAttributeList()` so that attributes are 
processed. `RebuildAttributedStmt()` similarly calls `ActOnAttributedStmt()`. 
However, `ActOnAttributedStmt()` doesn't call `ProcessStmtAttributes()` -- the 
logic is reversed so that `ProcessStmtAttributes()` is what calls 
`ActOnAttributedStmt()`.

I think the correct answer is to switch the logic so that 
`ActOnAttributedStmt()` calls `ProcessStmtAttributes()`, then the template 
logic should automatically work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

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

[PATCH] D99831: [HIP-Clang, test] Fix use of undef FileCheck var

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl accepted this revision.
yaxunl 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/D99831/new/

https://reviews.llvm.org/D99831

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

[PATCH] D99832: [HIP, test] Fix use of undef FileCheck var

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl accepted this revision.
yaxunl 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/D99832/new/

https://reviews.llvm.org/D99832

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

[PATCH] D99857: [OpenCL, test] Fix use of undef FileCheck var

[Thomas Preud'homme via Phabricator via cfe-commits]

thopre created this revision.
thopre added reviewers: hliao, craig.topper, neil.hickey, yaxunl, baldrick.
Herald added subscribers: ldrumm, Anastasia.
thopre requested review of this revision.
Herald added a project: clang.

Clang test CodeGenOpenCL/fpmath.cl uses a variable defined in an earlier
CHECK-NOT directive. However, by definition the pattern in that
directive is not supposed to occur so no variable will be defined. This
commit solves the issue by using a regex match with the same regex as in
the definition. It also changes the definition into a regex match since
no variable is going to be defined.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99857

Files:
  clang/test/CodeGenOpenCL/fpmath.cl


Index: clang/test/CodeGenOpenCL/fpmath.cl
===
--- clang/test/CodeGenOpenCL/fpmath.cl
+++ clang/test/CodeGenOpenCL/fpmath.cl
@@ -9,7 +9,7 @@
   // CHECK: @spscalardiv
   // CHECK: fdiv{{.*}},
   // NODIVOPT: !fpmath ![[MD:[0-9]+]]
-  // DIVOPT-NOT: !fpmath ![[MD:[0-9]+]]
+  // DIVOPT-NOT: !fpmath !{{[0-9]+}}
   return a / b;
 }
 
@@ -17,7 +17,7 @@
   // CHECK: @spvectordiv
   // CHECK: fdiv{{.*}},
   // NODIVOPT: !fpmath ![[MD]]
-  // DIVOPT-NOT: !fpmath ![[MD]]
+  // DIVOPT-NOT: !fpmath !{{[0-9]+}}
   return a / b;
 }
 


Index: clang/test/CodeGenOpenCL/fpmath.cl
===
--- clang/test/CodeGenOpenCL/fpmath.cl
+++ clang/test/CodeGenOpenCL/fpmath.cl
@@ -9,7 +9,7 @@
   // CHECK: @spscalardiv
   // CHECK: fdiv{{.*}},
   // NODIVOPT: !fpmath ![[MD:[0-9]+]]
-  // DIVOPT-NOT: !fpmath ![[MD:[0-9]+]]
+  // DIVOPT-NOT: !fpmath !{{[0-9]+}}
   return a / b;
 }
 
@@ -17,7 +17,7 @@
   // CHECK: @spvectordiv
   // CHECK: fdiv{{.*}},
   // NODIVOPT: !fpmath ![[MD]]
-  // DIVOPT-NOT: !fpmath ![[MD]]
+  // DIVOPT-NOT: !fpmath !{{[0-9]+}}
   return a / b;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99852: [Driver] Detect libstdc++ include paths for native gcc (-m32 and -m64) on Debian i386

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

From an upstream multiarch build of gcc, the libstdc++ search paths are

  
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1
  
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1/x86_64-pc-linux-gnu
  
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../include/c++/11.0.1/backward

(this is similar to cross gcc on Debian)

If you specify `--target=x86_64-linux-gnu` and install it to `/usr`, the paths 
will become.

  /usr/include/c++/11.0.1
  /usr/include/c++/11.0.1/x86_64-linux-gnu
  /usr/include/c++/11.0.1/backward

If Debian can drop the incdir patch for native gcc, clang driver can still 
detect the libstdc++ search paths.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99852

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