[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-02-23 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 411016.
MaskRay marked an inline comment as done.
MaskRay added a comment.

Explain pie


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120305

Files:
  clang/CMakeLists.txt
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/hexagon-toolchain-elf.c
  clang/test/Driver/hip-fpie-option.hip
  llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
  utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h


Index: utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
===
--- utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
+++ utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
@@ -23,7 +23,7 @@
 #define BUG_REPORT_URL "https://github.com/llvm/llvm-project/issues/;
 
 /* Default to -fPIE and -pie on Linux. */
-#define CLANG_DEFAULT_PIE_ON_LINUX 0
+#define CLANG_DEFAULT_PIE_ON_LINUX 1
 
 /* Default linker to use. */
 #define CLANG_DEFAULT_LINKER ""
Index: llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
+++ llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
@@ -9,7 +9,7 @@
   output = "$target_gen_dir/config.h"
   values = [
 "BUG_REPORT_URL=https://github.com/llvm/llvm-project/issues/;,
-"CLANG_DEFAULT_PIE_ON_LINUX=",
+"CLANG_DEFAULT_PIE_ON_LINUX=1",
 "CLANG_DEFAULT_LINKER=",
 "CLANG_DEFAULT_STD_C=",
 "CLANG_DEFAULT_STD_CXX=",
Index: clang/test/Driver/hip-fpie-option.hip
===
--- clang/test/Driver/hip-fpie-option.hip
+++ clang/test/Driver/hip-fpie-option.hip
@@ -1,15 +1,15 @@
-// REQUIRES: clang-driver, amdgpu-registered-target
+// REQUIRES: clang-driver, amdgpu-registered-target, default-pie-on-linux
 
 // -fPIC and -fPIE only affects host relocation model.
 // device compilation always uses PIC. 
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   --offload-arch=gfx906 %s -nogpulib -nogpuinc \
-// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-STATIC %s
+// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   -fgpu-rdc --offload-arch=gfx906 %s -nogpulib -nogpuinc \
-// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-STATIC %s
+// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   --offload-arch=gfx906 %s -nogpulib -nogpuinc \
@@ -32,7 +32,6 @@
 // RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
 
 // DEV-DAG: {{".*clang.*".* "-triple" "amdgcn-amd-amdhsa".* 
"-mrelocation-model" "pic" "-pic-level" "[1|2]".* "-mframe-pointer=all"}}
-// HOST-STATIC-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "static"}}
 // HOST-PIC-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "pic" "-pic-level" "2"}}
 // HOST-PIC-NOT: "-pic-is-pie"
 // HOST-PIE-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie"}}
Index: clang/test/Driver/hexagon-toolchain-elf.c
===
--- clang/test/Driver/hexagon-toolchain-elf.c
+++ clang/test/Driver/hexagon-toolchain-elf.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: default-pie-on-linux
 // 
-
 // Test standard include paths
 // 
-
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -183,6 +183,10 @@
 Build System Changes
 
 
+* CMake ``-DCLANG_DEFAULT_PIE_ON_LINUX=ON`` is now the default.
+  This matches GCC installations on many Linux distros: default to ``-fPIE 
-pie``.
+  When the variable is OFF, linux-gnu systems default to ``-fno-pic -no-pie``.
+
 AST Matchers
 
 
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -245,7 +245,7 @@
 set(CLANG_SPAWN_CC1 OFF CACHE BOOL
 "Whether clang should use a new process for the CC1 invocation")
 
-option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on Linux" OFF)
+option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on Linux" ON)
 
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING


Index: utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
===
--- 

[PATCH] D119530: [RISCV] Add combination crypto extensions in ISAInfo

2022-02-23 Thread Yueh-Ting Chen via Phabricator via cfe-commits
eopXD added a comment.

Friendly ping @VincentWu ;)
Any comments to the latest response?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119530

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


[PATCH] D119530: [RISCV] Add combination crypto extensions in ISAInfo

2022-02-23 Thread Yueh-Ting Chen via Phabricator via cfe-commits
eopXD updated this revision to Diff 411014.
eopXD added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add test for clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119530

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/test/CodeGen/RISCV/attributes.ll

Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -33,6 +33,9 @@
 ; RUN: llc -mtriple=riscv32 -mattr=+zks %s -o - | FileCheck --check-prefix=RV32ZKS %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zkt %s -o - | FileCheck --check-prefix=RV32ZKT %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zk %s -o - | FileCheck --check-prefix=RV32ZK %s
+; RUN: llc -mtriple=riscv32 -mattr=+zkn,+zkr,+zkt %s -o - | FileCheck --check-prefix=RV32COMBINEINTOZK %s
+; RUN: llc -mtriple=riscv32 -mattr=+zbkb,+zbkc,+zbkx,+zkne,+zknd,+zknh %s -o - | FileCheck --check-prefix=RV32COMBINEINTOZKN %s
+; RUN: llc -mtriple=riscv32 -mattr=+zbkb,+zbkc,+zbkx,+zksed,+zksh %s -o - | FileCheck --check-prefix=RV32COMBINEINTOZKS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m %s -o - | FileCheck --check-prefix=RV64M %s
 ; RUN: llc -mtriple=riscv64 -mattr=+a %s -o - | FileCheck --check-prefix=RV64A %s
 ; RUN: llc -mtriple=riscv64 -mattr=+f %s -o - | FileCheck --check-prefix=RV64F %s
@@ -66,6 +69,9 @@
 ; RUN: llc -mtriple=riscv64 -mattr=+zks %s -o - | FileCheck --check-prefix=RV64ZKS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zkt %s -o - | FileCheck --check-prefix=RV64ZKT %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zk %s -o - | FileCheck --check-prefix=RV64ZK %s
+; RUN: llc -mtriple=riscv64 -mattr=+zkn,+zkr,+zkt %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZK %s
+; RUN: llc -mtriple=riscv64 -mattr=+zbkb,+zbkc,+zbkx,+zkne,+zknd,+zknh %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZKN %s
+; RUN: llc -mtriple=riscv64 -mattr=+zbkb,+zbkc,+zbkx,+zksed,+zksh %s -o - | FileCheck --check-prefix=RV64COMBINEINTOZKS %s
 
 ; RV32M: .attribute 5, "rv32i2p0_m2p0"
 ; RV32A: .attribute 5, "rv32i2p0_a2p0"
@@ -100,6 +106,9 @@
 ; RV32ZKS: .attribute 5, "rv32i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 ; RV32ZKT: .attribute 5, "rv32i2p0_zkt1p0"
 ; RV32ZK: .attribute 5, "rv32i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
+; RV32COMBINEINTOZK: .attribute 5, "rv32i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
+; RV32COMBINEINTOZKN: .attribute 5, "rv32i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0"
+; RV32COMBINEINTOZKS: .attribute 5, "rv32i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 
 ; RV64M: .attribute 5, "rv64i2p0_m2p0"
 ; RV64A: .attribute 5, "rv64i2p0_a2p0"
@@ -134,6 +143,9 @@
 ; RV64ZKS: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 ; RV64ZKT: .attribute 5, "rv64i2p0_zkt1p0"
 ; RV64ZK: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
+; RV64COMBINEINTOZK: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zk1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0_zkr1p0_zkt1p0"
+; RV64COMBINEINTOZKN: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zkn1p0_zknd1p0_zkne1p0_zknh1p0"
+; RV64COMBINEINTOZKS: .attribute 5, "rv64i2p0_zbkb1p0_zbkc1p0_zbkx1p0_zks1p0_zksed1p0_zksh1p0"
 
 define i32 @addi(i32 %a) {
   %1 = add i32 %a, 1
Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -828,6 +828,38 @@
   }
 }
 
+struct CombinedExtsEntry {
+  StringLiteral CombineExt;
+  ArrayRef RequiredExts;
+};
+
+static constexpr CombinedExtsEntry CombineIntoExts[] = {
+{{"zk"}, {ImpliedExtsZk}},
+{{"zkn"}, {ImpliedExtsZkn}},
+{{"zks"}, {ImpliedExtsZks}},
+};
+
+void RISCVISAInfo::updateCombination() {
+  bool IsNewCombine = false;
+  do {
+IsNewCombine = false;
+for (CombinedExtsEntry CombineIntoExt : CombineIntoExts) {
+  auto CombineExt = CombineIntoExt.CombineExt;
+  auto RequiredExts = CombineIntoExt.RequiredExts;
+  if (hasExtension(CombineExt))
+continue;
+  bool IsAllRequiredFeatureExist = true;
+  for (const char *Ext : RequiredExts)
+IsAllRequiredFeatureExist &= hasExtension(Ext);
+  if (IsAllRequiredFeatureExist) {
+auto Version = findDefaultVersion(CombineExt);
+addExtension(CombineExt, Version->Major, Version->Minor);
+IsNewCombine = true;
+  }
+}
+  } while (IsNewCombine);
+}
+
 void RISCVISAInfo::updateFLen() {
   FLen = 0;
   // TODO: Handle q extension.
@@ -906,6 +938,7 @@
 llvm::Expected>
 RISCVISAInfo::postProcessAndChecking(std::unique_ptr &) {
   ISAInfo->updateImplication();
+  

[PATCH] D117989: [RISCV] Add the passthru operand for RVV nomask binary intrinsics.

2022-02-23 Thread Yueh-Ting Chen via Phabricator via cfe-commits
eopXD added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:180
 
+  // The nomask intrinsic IR have the passthru operand.
+  bit HasNoMaskPassThru = false;

eopXD wrote:
> Nit: V-spec prefers to call instructions without masking operands "unmasked 
> instructions"? Maybe a RFC patch later?
I mean an NFC patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117989

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


[PATCH] D117989: [RISCV] Add the passthru operand for RVV nomask binary intrinsics.

2022-02-23 Thread Yueh-Ting Chen via Phabricator via cfe-commits
eopXD added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:180
 
+  // The nomask intrinsic IR have the passthru operand.
+  bit HasNoMaskPassThru = false;

Nit: V-spec prefers to call instructions without masking operands "unmasked 
instructions"? Maybe a RFC patch later?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117989

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


[PATCH] D120297: [Driver][RISCV] Add missing rv64 test case

2022-02-23 Thread Yueh-Ting Chen via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8b62f19f27d4: [Driver][RISCV] Add missing rv64 test case 
(authored by eopXD).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120297

Files:
  clang/test/Driver/riscv-default-features.c


Index: clang/test/Driver/riscv-default-features.c
===
--- clang/test/Driver/riscv-default-features.c
+++ clang/test/Driver/riscv-default-features.c
@@ -1,4 +1,5 @@
 // RUN: %clang -target riscv32-unknown-elf -S -emit-llvm %s -o - | FileCheck 
%s -check-prefix=RV32
+// RUN: %clang -target riscv64-unknown-elf -S -emit-llvm %s -o - | FileCheck 
%s -check-prefix=RV64
 
 // RV32: "target-features"="+a,+c,+m,+relax,-save-restore"
 // RV64: "target-features"="+64bit,+a,+c,+m,+relax,-save-restore"


Index: clang/test/Driver/riscv-default-features.c
===
--- clang/test/Driver/riscv-default-features.c
+++ clang/test/Driver/riscv-default-features.c
@@ -1,4 +1,5 @@
 // RUN: %clang -target riscv32-unknown-elf -S -emit-llvm %s -o - | FileCheck %s -check-prefix=RV32
+// RUN: %clang -target riscv64-unknown-elf -S -emit-llvm %s -o - | FileCheck %s -check-prefix=RV64
 
 // RV32: "target-features"="+a,+c,+m,+relax,-save-restore"
 // RV64: "target-features"="+64bit,+a,+c,+m,+relax,-save-restore"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8b62f19 - [Driver][RISCV] Add missing rv64 test case

2022-02-23 Thread via cfe-commits

Author: eopXD
Date: 2022-02-23T22:53:42-08:00
New Revision: 8b62f19f27d4152e2ba0e329261fbe2a964f9950

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

LOG: [Driver][RISCV] Add missing rv64 test case

Add missing test case. Thanks @rogfer01 for spotting this out.

Reviewed By: asb

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

Added: 


Modified: 
clang/test/Driver/riscv-default-features.c

Removed: 




diff  --git a/clang/test/Driver/riscv-default-features.c 
b/clang/test/Driver/riscv-default-features.c
index 853e4dbb2fd4b..0bb65d2430d6b 100644
--- a/clang/test/Driver/riscv-default-features.c
+++ b/clang/test/Driver/riscv-default-features.c
@@ -1,4 +1,5 @@
 // RUN: %clang -target riscv32-unknown-elf -S -emit-llvm %s -o - | FileCheck 
%s -check-prefix=RV32
+// RUN: %clang -target riscv64-unknown-elf -S -emit-llvm %s -o - | FileCheck 
%s -check-prefix=RV64
 
 // RV32: "target-features"="+a,+c,+m,+relax,-save-restore"
 // RV64: "target-features"="+64bit,+a,+c,+m,+relax,-save-restore"



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


[PATCH] D117199: [RISCV] Add missing namespace (NFC)

2022-02-23 Thread Yeting Kuo via Phabricator via cfe-commits
fakepaper56 closed this revision.
fakepaper56 added a comment.
Herald added subscribers: pcwang-thead, eopXD.

The patch content is in D119727 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117199

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


[PATCH] D120454: clang/www: Add links to tracking issues for C++20 features

2022-02-23 Thread Tom Stellard via Phabricator via cfe-commits
tstellar created this revision.
tstellar requested review of this revision.
Herald added a project: clang.

Also add some javascript to automatically change that status to
"In Progress" when the issue is assigned to someone, and "Clang ToT"
when the issue is closed.

Note that the feature entries will still need to be manually updated
with the first version of clang that they appear in once they have
been completed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120454

Files:
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -58,7 +58,7 @@
 
  C++20
  -std=c++20
- Partial
+ Partial
 
 
  C++2b (tentatively C++23)
@@ -80,6 +80,36 @@
 the "c++" label, as well as mode-specific labels such as "c++11", "c++14",
 and so on, to track known bugs with Clang's language conformance.
 
+There should also be an issue created in the
+https://github.com/llvm/llvm-project/issues/;>LLVM bug tracker for
+each new C++ standard feature.  Please use this template when creating a new bug:
+
+
+Title:
+Clang C++20 Feature: paper id - paper title
+
+Body:
+optional description
+---
+id: paper id
+paper: link to paper
+
+
+
+Also be sure to add the issue to the appropriate milestone e.g. "Clang C++20"
+and add the relevant tags.
+
+
+Once you've created an issue for a new feature, add the link to the issue in the
+tables below.  Set the 'class' attribute on the 'a' tag equal to 'autoupdate' to
+automatically fetch status information from the issue in the tracker. For Example:
+a class='autoupdate' href='https://github.com/llvm/llvm-project/issues/54006'No/a
+
+
+Once the feature has been implemented, close the corresponding issue and update
+the table with first version of clang that will contain this feature.
+
+
 C++98 implementation status
 
 Clang implements all of the ISO C++ 1998 standard
@@ -927,7 +957,9 @@
   

 https://wg21.link/p0848r3;>P0848R3
-No
+
+  No
+
   
   
 https://wg21.link/p1616r1;>P1616R1
@@ -938,16 +970,27 @@
   

 https://wg21.link/p1972r0;>P1972R0
-No
+
+  No
+
   
   
 https://wg21.link/p1980r0;>P1980R0
+
+  No
+
   

 https://wg21.link/p2103r0;>P2103R0
+
+  No
+
   

 https://wg21.link/p2493r0;>P2493R0
+
+  No
+
   
   
 https://wg21.link/p2092r0;>P2092R0
@@ -959,7 +1002,9 @@
   
   
 https://wg21.link/p2113r0;>P2113R0
-No
+
+  No
+
   
 
 
@@ -1040,7 +1085,9 @@
 
   typename optional in more contexts
   https://wg21.link/p0634r3;>P0634R3
-  No
+  
+No
+  
 
 
   Pack expansion in lambda init-capture
@@ -1156,10 +1203,15 @@
 
   Parenthesized initialization of aggregates
   https://wg21.link/p0960r3;>P0960R3
-  No
+  
+No
+  
 

 https://wg21.link/p1975r0;>P1975R0
+
+  No
+
   
 
   Modules
@@ -1172,10 +1224,15 @@
   
   
 https://wg21.link/p1811r0;>P1811R0
-No
+
+  No
+
   
   
 https://wg21.link/p1703r1;>P1703R1
+
+  No
+
   

 https://wg21.link/p1874r1;>P1874R1
@@ -1183,13 +1240,21 @@
   

 https://wg21.link/p1979r0;>P1979R0
-No
+
+  No
+
   

 https://wg21.link/p1779r3;>P1779R3
+
+  No
+
   
   
 https://wg21.link/p1857r3;>P1857R3
+
+  No
+
   
   
 https://wg21.link/p2115r0;>P2115R0
@@ -1197,7 +1262,9 @@
   
   
 https://wg21.link/p1815r2;>P1815R2
-No
+
+  No
+
   
 
   Coroutines
@@ -1234,15 +1301,22 @@
 
   Class template argument deduction for aggregates
   https://wg21.link/p1816r0;>P1816R0
-  No
+  
+No
+  
 

 https://wg21.link/p2082r1;>P2082R1
+  
+No
+  
   
 
   Class template argument deduction for alias templates
   https://wg21.link/p1814r0;>P1814R0
-  No
+  
+No
+  
 
 
   Permit conversions to arrays of unknown bound
@@ -1542,5 +1616,52 @@
 
 
 
+
+async function getIssue(issueNumber) {
+  var response = await fetch('https://api.github.com/repos/llvm/llvm-project/issues/' + issueNumber);
+  return response.json();
+}
+
+async function updateIssueCell(element) {
+  var status = "No";
+  var className = "none";
+  var issueNumber = 

[PATCH] D120310: [clang][analyzer] Add modeling of 'errno' (work-in-progress).

2022-02-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h:767-768
s->getType()->isBlockPointerType());
-assert(isa(sreg) || isa(sreg));
+assert(isa(sreg) || isa(sreg) ||
+   isa(sreg));
   }

steakhal wrote:
> NoQ wrote:
> > steakhal wrote:
> > > At this point, I'm not even sure if we should assert any of these.
> > I mean, ideally this should be just `UnknownSpaceRegion`. For everything 
> > else we should have made a fresh `MemRegion` class. It is absurd that the 
> > same numeric address value (represented the symbol `s`) can correspond to 
> > two (now three) different locations in memory.
> From my perspective, a symbolic region is just a region that we don't know 
> what its parent region is - let it be part of an object or an entire memory 
> space.
> The memory space is what we use for communicating some constraints on where 
> that symbolic region.
> E.g. a symbolic region of a stack memory space should never alias with any 
> memory region of the heap memory space.
> 
> > It is absurd that the same numeric address value (represented the symbol s) 
> > can correspond to two (now three) different locations in memory.
> IMO a given `s` should indeed refer to a single location in memory, but 
> that's not a property we can enforce here in the constructor.
> And my guess is that by removing this assertion, we would still have this 
> invariant. What we should do instead, put an assertion into the 
> `SymbolManager`, to enforce that with the same `s` symbol, one cannot 
> construct two `SymbolicRegions` with different memory spaces.
> Alternatively, we could remove the memory space from the `Profile` to map to 
> the same entity in the Map; which would enforce this invariant on its own. 
> WDYT?
>  The memory space is what we use for communicating some constraints on where 
> that symbolic region.

I agree that it's a constraint. And as such, I believe it shouldn't be made 
part of the region's //identity//. Just like "$x < 5" is not a field inside 
symbol $x but a separate state trait. Similarly we can turn `SymbolicRegion`'s 
memory space constraint into a state trait. Then we can express more 
sophisticated constraints ("this symbolic region is either on the heap or a 
global variable but definitely not a local variable"), or we can have 
constraints become more precise over time ("this symbolic region was compared 
as "less than" another heap region, therefore it itself must be on the heap").

> What we should do instead, put an assertion into the `SymbolManager`, to 
> enforce that with the same `s` symbol, one cannot construct two 
> `SymbolicRegions` with different memory spaces.

This could be a nice temporary solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120310

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


[clang] 9d899d8 - [HIP] Support `-fgpu-default-stream`

2022-02-23 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-02-23T22:28:29-05:00
New Revision: 9d899d8f01872e91b9909a6ee5937a796a399276

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

LOG: [HIP] Support `-fgpu-default-stream`

Introduce -fgpu-default-stream={legacy|per-thread} option to
support per-thread default stream for HIP runtime.

When -fgpu-default-stream=per-thread, HIP kernels are
launched through hipLaunchKernel_spt instead of
hipLaunchKernel. Also HIP_API_PER_THREAD_DEFAULT_STREAM=1
is defined by the preprocessor to enable other per-thread stream
API's.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/CGCUDANV.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/InitPreprocessor.cpp
clang/test/CodeGenCUDA/Inputs/cuda.h
clang/test/CodeGenCUDA/kernel-call.cu
clang/test/Driver/hip-options.hip
clang/test/Preprocessor/predefined-macros.c

Removed: 




diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index 2e334e375950e..6aa24d2facc2a 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -309,6 +309,13 @@ class LangOptions : public LangOptionsBase {
 ExtendTo64
   };
 
+  enum class GPUDefaultStreamKind {
+/// Legacy default stream
+Legacy,
+/// Per-thread default stream
+PerThread,
+  };
+
 public:
   /// The used language standard.
   LangStandard::Kind LangStd;
@@ -402,6 +409,9 @@ class LangOptions : public LangOptionsBase {
   /// input is a header file (i.e. -x c-header).
   bool IsHeaderFile = false;
 
+  /// The default stream kind used for HIP kernel launching.
+  GPUDefaultStreamKind GPUDefaultStream;
+
   LangOptions();
 
   // Define accessors/mutators for language options of enumeration type.

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index f9d8e32169635..8dd16ca990a14 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -959,6 +959,13 @@ defm cuda_short_ptr : BoolFOption<"cuda-short-ptr",
   TargetOpts<"NVPTXUseShortPointers">, DefaultFalse,
   PosFlag,
   NegFlag>;
+def fgpu_default_stream_EQ : Joined<["-"], "fgpu-default-stream=">,
+  HelpText<"Specify default stream. Valid values are 'legacy' and 
'per-thread'. The default value is 'legacy'. (HIP only)">,
+  Flags<[CC1Option]>,
+  Values<"legacy,per-thread">,
+  NormalizedValuesScope<"LangOptions::GPUDefaultStreamKind">,
+  NormalizedValues<["Legacy", "PerThread"]>,
+  MarshallingInfoEnum, "Legacy">;
 def rocm_path_EQ : Joined<["--"], "rocm-path=">, Group,
   HelpText<"ROCm installation path, used for finding and automatically linking 
required bitcode libraries.">;
 def hip_path_EQ : Joined<["--"], "hip-path=">, Group,

diff  --git a/clang/lib/CodeGen/CGCUDANV.cpp b/clang/lib/CodeGen/CGCUDANV.cpp
index 293bdf99d272f..b832c686b8b69 100644
--- a/clang/lib/CodeGen/CGCUDANV.cpp
+++ b/clang/lib/CodeGen/CGCUDANV.cpp
@@ -332,15 +332,22 @@ void 
CGNVCUDARuntime::emitDeviceStubBodyNew(CodeGenFunction ,
   llvm::BasicBlock *EndBlock = CGF.createBasicBlock("setup.end");
 
   // Lookup cudaLaunchKernel/hipLaunchKernel function.
+  // HIP kernel launching API name depends on -fgpu-default-stream option. For
+  // the default value 'legacy', it is hipLaunchKernel. For 'per-thread',
+  // it is hipLaunchKernel_spt.
   // cudaError_t cudaLaunchKernel(const void *func, dim3 gridDim, dim3 
blockDim,
   //  void **args, size_t sharedMem,
   //  cudaStream_t stream);
-  // hipError_t hipLaunchKernel(const void *func, dim3 gridDim, dim3 blockDim,
-  //void **args, size_t sharedMem,
-  //hipStream_t stream);
+  // hipError_t hipLaunchKernel[_spt](const void *func, dim3 gridDim,
+  //  dim3 blockDim, void **args,
+  //  size_t sharedMem, hipStream_t stream);
   TranslationUnitDecl *TUDecl = CGM.getContext().getTranslationUnitDecl();
   DeclContext *DC = TranslationUnitDecl::castToDeclContext(TUDecl);
-  auto LaunchKernelName = addPrefixToName("LaunchKernel");
+  std::string KernelLaunchAPI = "LaunchKernel";
+  if (CGF.getLangOpts().HIP && CGF.getLangOpts().GPUDefaultStream ==
+   
LangOptions::GPUDefaultStreamKind::PerThread)
+KernelLaunchAPI = KernelLaunchAPI + "_spt";
+  auto LaunchKernelName = addPrefixToName(KernelLaunchAPI);
   IdentifierInfo  =
   CGM.getContext().Idents.get(LaunchKernelName);
   FunctionDecl *cudaLaunchKernelFD = 

[PATCH] D120298: [HIP] Support `-fgpu-default-stream`

2022-02-23 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9d899d8f0187: [HIP] Support `-fgpu-default-stream` (authored 
by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120298

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/test/CodeGenCUDA/Inputs/cuda.h
  clang/test/CodeGenCUDA/kernel-call.cu
  clang/test/Driver/hip-options.hip
  clang/test/Preprocessor/predefined-macros.c

Index: clang/test/Preprocessor/predefined-macros.c
===
--- clang/test/Preprocessor/predefined-macros.c
+++ clang/test/Preprocessor/predefined-macros.c
@@ -247,6 +247,7 @@
 // CHECK-HIP-NEG-NOT: #define __CUDA_ARCH__
 // CHECK-HIP-NEG-NOT: #define __HIP_DEVICE_COMPILE__ 1
 // CHECK-HIP-NEG-NOT: #define __CLANG_RDC__ 1
+// CHECK-HIP-NEG-NOT: #define HIP_API_PER_THREAD_DEFAULT_STREAM
 
 // RUN: %clang_cc1 %s -E -dM -o - -x hip -triple amdgcn-amd-amdhsa \
 // RUN:   -fcuda-is-device \
@@ -265,6 +266,7 @@
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-HIP-DEV-NEG
 // CHECK-HIP-DEV-NEG-NOT: #define __CUDA_ARCH__
 // CHECK-HIP-DEV-NEG-NOT: #define __CLANG_RDC__ 1
+// CHECK-HIP-DEV-NEG-NOT: #define HIP_API_PER_THREAD_DEFAULT_STREAM
 
 // RUN: %clang_cc1 %s -E -dM -o - -x cuda -triple x86_64-unknown-linux-gnu \
 // RUN:   -fgpu-rdc | FileCheck %s --check-prefix=CHECK-RDC
@@ -277,3 +279,11 @@
 // RUN:   -fgpu-rdc -fcuda-is-device \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-RDC
 // CHECK-RDC: #define __CLANG_RDC__ 1
+
+// RUN: %clang_cc1 %s -E -dM -o - -x hip -triple x86_64-unknown-linux-gnu \
+// RUN:   -fgpu-default-stream=per-thread \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-PTH
+// RUN: %clang_cc1 %s -E -dM -o - -x hip -triple amdgcn-amd-amdhsa \
+// RUN:   -fcuda-is-device -fgpu-default-stream=per-thread \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-PTH
+// CHECK-PTH: #define HIP_API_PER_THREAD_DEFAULT_STREAM 1
Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -14,6 +14,14 @@
 // DEVINIT: clang{{.*}}" "-cc1" {{.*}}"-fgpu-allow-device-init"
 // DEVINIT: clang{{.*}}" "-cc1" {{.*}}"-fgpu-allow-device-init"
 
+// Check -fgpu-default-stream=per-thread.
+// RUN: %clang -### -nogpuinc -nogpulib -fgpu-default-stream=per-thread \
+// RUN:   %s -save-temps 2>&1 | FileCheck -check-prefix=PTH %s
+// PTH: clang{{.*}}" "-cc1" {{.*}}"-E" {{.*}}"-fgpu-default-stream=per-thread"
+// PTH: clang{{.*}}" "-cc1" {{.*}}"-fgpu-default-stream=per-thread" {{.*}}"-x" "hip-cpp-output"
+// PTH: clang{{.*}}" "-cc1" {{.*}}"-E" {{.*}}"-fgpu-default-stream=per-thread"
+// PTH: clang{{.*}}" "-cc1" {{.*}}"-fgpu-default-stream=per-thread" {{.*}}"-x" "hip-cpp-output"
+
 // RUN: %clang -### -x hip -target x86_64-pc-windows-msvc -fms-extensions \
 // RUN:   -mllvm -amdgpu-early-inline-all=true  %s 2>&1 | \
 // RUN:   FileCheck -check-prefix=MLLVM %s
Index: clang/test/CodeGenCUDA/kernel-call.cu
===
--- clang/test/CodeGenCUDA/kernel-call.cu
+++ clang/test/CodeGenCUDA/kernel-call.cu
@@ -5,7 +5,13 @@
 // RUN: %clang_cc1 -x hip -emit-llvm %s -o - \
 // RUN: | FileCheck %s --check-prefixes=HIP-OLD,CHECK
 // RUN: %clang_cc1 -fhip-new-launch-api -x hip -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes=HIP-NEW,CHECK
+// RUN: | FileCheck %s --check-prefixes=HIP-NEW,LEGACY,CHECK
+// RUN: %clang_cc1 -fhip-new-launch-api -x hip -emit-llvm %s -o - \
+// RUN:   -fgpu-default-stream=legacy \
+// RUN:   | FileCheck %s --check-prefixes=HIP-NEW,LEGACY,CHECK
+// RUN: %clang_cc1 -fhip-new-launch-api -x hip -emit-llvm %s -o - \
+// RUN:   -fgpu-default-stream=per-thread -DHIP_API_PER_THREAD_DEFAULT_STREAM \
+// RUN:   | FileCheck %s --check-prefixes=HIP-NEW,PTH,CHECK
 
 #include "Inputs/cuda.h"
 
@@ -13,7 +19,8 @@
 // HIP-OLD: call{{.*}}hipSetupArgument
 // HIP-OLD: call{{.*}}hipLaunchByPtr
 // HIP-NEW: call{{.*}}__hipPopCallConfiguration
-// HIP-NEW: call{{.*}}hipLaunchKernel
+// LEGACY: call{{.*}}hipLaunchKernel
+// PTH: call{{.*}}hipLaunchKernel_spt
 // CUDA-OLD: call{{.*}}cudaSetupArgument
 // CUDA-OLD: call{{.*}}cudaLaunch
 // CUDA-NEW: call{{.*}}__cudaPopCallConfiguration
Index: clang/test/CodeGenCUDA/Inputs/cuda.h
===
--- clang/test/CodeGenCUDA/Inputs/cuda.h
+++ clang/test/CodeGenCUDA/Inputs/cuda.h
@@ -35,11 +35,18 @@
 extern "C" hipError_t __hipPushCallConfiguration(dim3 gridSize, dim3 blockSize,
 

[PATCH] D117740: [NFC][clang] Simplify `isOneOf` function

2022-02-23 Thread Shao-Ce SUN via Phabricator via cfe-commits
achieveartificialintelligence added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117740

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


[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

2022-02-23 Thread ShihPo Hung via Phabricator via cfe-commits
arcbbb created this revision.
arcbbb added reviewers: craig.topper, rogfer01, frasercrmck, kito-cheng, 
monkchiang, eopXD, khchen.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
vkmr, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, 
psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, edward-jones, zzheng, 
jrtc27, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, hiraditya.
arcbbb requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, MaskRay.
Herald added projects: clang, LLVM.

This patch adds a set of vector vfcvt intrinsics that have side effects:

  strict.vfcvt.xu.f,  strict.vfcvt.x.f,  strict.vfcvt.f.xu, strict.vfcvt.f.xu,
  strict.vfwcvt.xu.f,  strict.vfwcvt.x.f,  strict.vfwcvt.f.xu, 
strict.vfwcvt.f.xu, strict.vfwcvt.f.f
  strict.vfncvt.xu.f,  strict.vfncvt.x.f,  strict.vfncvt.f.xu, 
strict.vfncvt.f.xu,.strict.vfncvt.f.f

Clang can emit these based on getIsFPConstrained().

And the rest strict vector fp intrinsics will come in later patches:

  vfsqrt, vfrsqrt7, vfrec7, vfadd, vfsub, vfmul, vfdiv,
  vfredosum, vfredusum, vfmacc, vfmadd, vfmsac, vfmsub


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120449

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwcvt.c
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVISelLowering.h
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td
  llvm/test/CodeGen/RISCV/rvv/strict-vfcvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfcvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfcvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfcvt-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfncvt-f-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfncvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfncvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfncvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfncvt-xu-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfwcvt-f-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfwcvt-f-x.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfwcvt-f-xu.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfwcvt-x-f.ll
  llvm/test/CodeGen/RISCV/rvv/strict-vfwcvt-xu-f.ll

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


[PATCH] D120132: [HIP] Fix HIP include path

2022-02-23 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:531-532
+  DriverArgs.hasArg(options::OPT_nostdlibinc)) {
+CC1Args.push_back("-internal-isystem");
+CC1Args.push_back(HipIncludePath);
+  }

tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > yaxunl wrote:
> > > > tra wrote:
> > > > > My impression, after reading the problem description, is that the 
> > > > > actual issue is that we're using `-internal-isystem` for the HIP SDK 
> > > > > includes , not that we add the include path to them.
> > > > > 
> > > > > Instead of trying to guess whether we happen to match some hardcoded 
> > > > > path where we think the standard headers may live, I'd rather use 
> > > > > `-I` or its internal equivalent, if we have it. Hardcoded paths 
> > > > > *will* be wrong for someone. E.g. I'm pretty sure `/usr/anything` is 
> > > > > not going to work on windows. Of for our internal builds.
> > > > changing `-internal-isystem` to `-I` is a solution, as the same path 
> > > > showing up first with both `-I` then with `-internal-isystem` will be 
> > > > treated as `-internal-isystem` and placed in the latter position.
> > > > 
> > > > However, one drawback is that this may cause regression due to warnings 
> > > > emitted for HIP headers.
> > > > 
> > > > I think I may let AddHIPIncludeArgs return the HIP include path instead 
> > > > of adding it right away, then let clang add it after the system include 
> > > > paths. I may rename AddHIPIncludeArgs as 
> > > > AddHIPWrapperIncludeArgsAndGetHIPIncludePath. What do you think? 
> > > > Thanks. 
> > > > one drawback is that this may cause regression due to warnings emitted 
> > > > for HIP headers.
> > > 
> > > If I understand the patch description correctly, allowing these warnings 
> > > was the purpose. Is that not the case?
> > > 
> > > > [current state] prevents warnings related to things like reserved 
> > > > identifiers when including the HIP headers even when ROCm is installed 
> > > > in a non-system directory, such as /opt/rocm.
> > > 
> > > I'm fine with separating include paths of wrappers and the SDK headers. I 
> > > think we already do something similar for CUDA (though they are still 
> > > added with -isystem-include).
> > Some warnings are unnecessary for HIP header files e.g. warnings about 
> > macro definitions starting with `__`. Some applications use -Wpedantic 
> > -Werror, which can cause unnecessary errors in HIP header. Also we have 
> > customers who use the latest clang with older HIP runtime. If we switch to 
> > `-I`, we may get regressions.
> > 
> > AFAIK all language headers e.g. CUDA, OpenMP, are included by 
> > `-internal-isystem` by clang, therefore I think HIP better follow this 
> > convention.
> I may have misinterpreted the patch description. 
> 
> So `-include-isystem` is not the problem. The problem is that when HIP SDK 
> includes are installed under /usr, their inclusion along with the wrappers 
> messes with the standard c/c++ header inclusion order . Separating the 
> wrappers and HIP SDK include paths, and moving HIP includes towards the end 
> of the search path is the way to fix it. HIP SDK headers will still be still 
> included via `-isystem-include`.
> 
> Did I get that right?
> 
Right.

Since HIP headers does not use include_next, it does not matter whether HIP 
include path is before or after standard C++ include path. However, HIP include 
path may be the same as /usr or /usr/local, which need to be after standard C++ 
include path. Therefore moving HIP include path to be after system path solves 
the issue.


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

https://reviews.llvm.org/D120132

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


[PATCH] D117090: [clang-tidy] Fix `readability-non-const-parameter` for parameter referenced by an lvalue

2022-02-23 Thread liushuai wang via Phabricator via cfe-commits
MTC added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-non-const-parameter.cpp:293
+  // CHECK-MESSAGES-NOT: warning: pointer parameter 'p' can be
+  int  = *p;
+}

Sockke wrote:
> MTC wrote:
> > @Sockke  Could you please add the following tests?
> > 
> > ```
> > int  = std::ref(*p);
> > const int  = std::ref(*p);
> > const int  = std::cref(*p);
> > const int *ptr = std::as_const(p);
> > int *ptr = const_cast(std::as_const(p));
> > decltype(auto) ptr = p;
> > auto ptr = p;
> > ```
> These cases have been handled stably in another logic.
Sorry for my mistake, look good to me!


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

https://reviews.llvm.org/D117090

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


[PATCH] D117090: [clang-tidy] Fix `readability-non-const-parameter` for parameter referenced by an lvalue

2022-02-23 Thread gehry via Phabricator via cfe-commits
Sockke added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-non-const-parameter.cpp:293
+  // CHECK-MESSAGES-NOT: warning: pointer parameter 'p' can be
+  int  = *p;
+}

MTC wrote:
> @Sockke  Could you please add the following tests?
> 
> ```
> int  = std::ref(*p);
> const int  = std::ref(*p);
> const int  = std::cref(*p);
> const int *ptr = std::as_const(p);
> int *ptr = const_cast(std::as_const(p));
> decltype(auto) ptr = p;
> auto ptr = p;
> ```
These cases have been handled stably in another logic.


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

https://reviews.llvm.org/D117090

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


[PATCH] D117090: [clang-tidy] Fix `readability-non-const-parameter` for parameter referenced by an lvalue

2022-02-23 Thread liushuai wang via Phabricator via cfe-commits
MTC added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-non-const-parameter.cpp:293
+  // CHECK-MESSAGES-NOT: warning: pointer parameter 'p' can be
+  int  = *p;
+}

@Sockke  Could you please add the following tests?

```
int  = std::ref(*p);
const int  = std::ref(*p);
const int  = std::cref(*p);
const int *ptr = std::as_const(p);
int *ptr = const_cast(std::as_const(p));
decltype(auto) ptr = p;
auto ptr = p;
```


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

https://reviews.llvm.org/D117090

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


[PATCH] D120290: [Clang][OpenMP] Add the codegen support for `atomic compare capture`

2022-02-23 Thread Shilei Tian via Phabricator via cfe-commits
tianshilei1992 marked an inline comment as done.
tianshilei1992 added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6067
+  if (VPtr) {
+VOpVal = {VPtr, VPtr->getType()->getPointerElementType(),
+  V->getType().isVolatileQualified(),

nikic wrote:
> Please avoid adding new calls to getPointerElementType(). See 
> https://github.com/llvm/llvm-project/commit/b1863d82454b2905db8b492bea0ce8a260362645
>  for a way to avoid it in this context.
Got it. Thanks for the info.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120290

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


[PATCH] D120290: [Clang][OpenMP] Add the codegen support for `atomic compare capture`

2022-02-23 Thread Shilei Tian via Phabricator via cfe-commits
tianshilei1992 updated this revision to Diff 410986.
tianshilei1992 marked an inline comment as done.
tianshilei1992 added a comment.

rebase and fix comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120290

Files:
  clang/include/clang/AST/StmtOpenMP.h
  clang/lib/AST/StmtOpenMP.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/OpenMP/atomic_compare_codegen.cpp

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


[PATCH] D120445: [clang-format] Treat && followed by noexcept operator as a binary operator inside template arguments

2022-02-23 Thread Luis Penagos via Phabricator via cfe-commits
penagos created this revision.
penagos added reviewers: curdeius, MyDeveloperDay.
penagos published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fixes https://github.com/llvm/llvm-project/issues/44544.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120445

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9512,6 +9512,7 @@
   verifyFormat("f(aa\n"
"  .template operator()());",
getLLVMStyleWithColumns(35));
+  verifyFormat("bool_constant");
 
   // Not template parameters.
   verifyFormat("return a < b && c > d;");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2066,6 +2066,10 @@
   return TT_UnaryOperator;
 
 const FormatToken *NextToken = Tok.getNextNonComment();
+
+if (InTemplateArgument && NextToken && NextToken->is(tok::kw_noexcept))
+  return TT_BinaryOperator;
+
 if (!NextToken ||
 NextToken->isOneOf(tok::arrow, tok::equal, tok::kw_noexcept) ||
 NextToken->canBePointerOrReferenceQualifier() ||


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -9512,6 +9512,7 @@
   verifyFormat("f(aa\n"
"  .template operator()());",
getLLVMStyleWithColumns(35));
+  verifyFormat("bool_constant");
 
   // Not template parameters.
   verifyFormat("return a < b && c > d;");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2066,6 +2066,10 @@
   return TT_UnaryOperator;
 
 const FormatToken *NextToken = Tok.getNextNonComment();
+
+if (InTemplateArgument && NextToken && NextToken->is(tok::kw_noexcept))
+  return TT_BinaryOperator;
+
 if (!NextToken ||
 NextToken->isOneOf(tok::arrow, tok::equal, tok::kw_noexcept) ||
 NextToken->canBePointerOrReferenceQualifier() ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D34654: Allow passing a regex for headers to exclude from clang-tidy

2022-02-23 Thread Amin Yahyaabadi via Phabricator via cfe-commits
aminya added a comment.

Clang-tidy is very slow if you use it on a medium or large project. Something 
like this feature, even if it is not perfect, will definitely improve the 
experience with clang-tidy. The low performance of clang-tidy is one of the 
biggest frictions for using it.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D34654

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


[PATCH] D119004: [NFC][analyzer] Allow CallDescriptions to be matched with CallExprs

2022-02-23 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Looks great, thanks!


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

https://reviews.llvm.org/D119004

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


[PATCH] D120394: [asan] Allow -fsanitize-address-globals-dead-stripping with -fno-data-sections for ELF

2022-02-23 Thread Fangrui Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0477cac332d5: [asan] Allow 
-fsanitize-address-globals-dead-stripping with -fno-data-sections… (authored by 
MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D120394?vs=410739=410967#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120394

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/asan-globals-gc.cpp
  clang/test/CodeGen/asan-no-globals-no-comdat.cpp


Index: clang/test/CodeGen/asan-no-globals-no-comdat.cpp
===
--- clang/test/CodeGen/asan-no-globals-no-comdat.cpp
+++ clang/test/CodeGen/asan-no-globals-no-comdat.cpp
@@ -1,9 +1,7 @@
 // Test that on Linux asan constructor is placed in a comdat iff globals-gc is 
on.
 // Even if there are no globals in the module.
 
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITHOUT-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fdata-sections -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -fdata-sections 
-emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
+// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITH-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address -fdata-sections -emit-llvm -o - -triple 
x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 
Index: clang/test/CodeGen/asan-globals-gc.cpp
===
--- clang/test/CodeGen/asan-globals-gc.cpp
+++ clang/test/CodeGen/asan-globals-gc.cpp
@@ -1,6 +1,5 @@
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITHOUT-GC
+// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITH-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fdata-sections -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -fdata-sections 
-emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address -fdata-sections -emit-llvm -o - -triple 
x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -281,7 +281,7 @@
   case Triple::COFF:
 return true;
   case Triple::ELF:
-return CGOpts.DataSections && !CGOpts.DisableIntegratedAS;
+return !CGOpts.DisableIntegratedAS;
   case Triple::GOFF:
 llvm::report_fatal_error("ASan not implemented for GOFF");
   case Triple::XCOFF:


Index: clang/test/CodeGen/asan-no-globals-no-comdat.cpp
===
--- clang/test/CodeGen/asan-no-globals-no-comdat.cpp
+++ clang/test/CodeGen/asan-no-globals-no-comdat.cpp
@@ -1,9 +1,7 @@
 // Test that on Linux asan constructor is placed in a comdat iff globals-gc is on.
 // Even if there are no globals in the module.
 
-// RUN: %clang_cc1 -fsanitize=address -fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
-// RUN: %clang_cc1 -fsanitize=address -fsanitize-address-globals-dead-stripping -fdata-sections -emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
-// RUN: %clang_cc1 -fsanitize=address -fsanitize-address-globals-dead-stripping -fno-integrated-as -fdata-sections -emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
+// RUN: %clang_cc1 -fsanitize=address -fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
 // RUN: %clang_cc1 -fsanitize=address -fsanitize-address-globals-dead-stripping -fno-integrated-as -emit-llvm -o - -triple x86_64-linux %s | FileCheck %s 

[clang] 0477cac - [asan] Allow -fsanitize-address-globals-dead-stripping with -fno-data-sections for ELF

2022-02-23 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-02-23T16:08:25-08:00
New Revision: 0477cac332d5abf7b2b51b470370afcbb1e8d513

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

LOG: [asan] Allow -fsanitize-address-globals-dead-stripping with 
-fno-data-sections for ELF

-fdata-sections decides whether global variables go into different sections.
This is orthogonal to whether we place their metadata (`.data` or 
`asan_globals`) into different sections.

With -fno-data-sections, `-fsanitize-address-globals-dead-stripping` can still:

* deduplicate COMDAT `asan.module_ctor` and `asan.module_dtor`
* (with ld --gc-sections): for a data section (e.g. `.data`), if all global 
variables defined relative to it are unreferenced, discard them and associated 
`asan_globals` sections (rare but no need to exclude this case)

Similar to c7b90947bd0179d914fea56b52be545c8f60f20a for PE/COFF.

Reviewed By: #sanitizers, kstoimenov, vitalybuka

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
clang/test/CodeGen/asan-globals-gc.cpp
clang/test/CodeGen/asan-no-globals-no-comdat.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index f3026040ad216..ebfbe991881c6 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -281,7 +281,7 @@ static bool asanUseGlobalsGC(const Triple , const 
CodeGenOptions ) {
   case Triple::COFF:
 return true;
   case Triple::ELF:
-return CGOpts.DataSections && !CGOpts.DisableIntegratedAS;
+return !CGOpts.DisableIntegratedAS;
   case Triple::GOFF:
 llvm::report_fatal_error("ASan not implemented for GOFF");
   case Triple::XCOFF:

diff  --git a/clang/test/CodeGen/asan-globals-gc.cpp 
b/clang/test/CodeGen/asan-globals-gc.cpp
index 95702516d8a16..f2adbfb6eb36f 100644
--- a/clang/test/CodeGen/asan-globals-gc.cpp
+++ b/clang/test/CodeGen/asan-globals-gc.cpp
@@ -1,6 +1,5 @@
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITHOUT-GC
+// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITH-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fdata-sections -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -fdata-sections 
-emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address -fdata-sections -emit-llvm -o - -triple 
x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 

diff  --git a/clang/test/CodeGen/asan-no-globals-no-comdat.cpp 
b/clang/test/CodeGen/asan-no-globals-no-comdat.cpp
index b7a6b16159a5f..9c7a0d2ff53da 100644
--- a/clang/test/CodeGen/asan-no-globals-no-comdat.cpp
+++ b/clang/test/CodeGen/asan-no-globals-no-comdat.cpp
@@ -1,9 +1,7 @@
 // Test that on Linux asan constructor is placed in a comdat iff globals-gc is 
on.
 // Even if there are no globals in the module.
 
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITHOUT-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fdata-sections -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITH-GC
-// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -fdata-sections 
-emit-llvm -o - -triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
+// RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -emit-llvm -o - -triple x86_64-linux 
%s | FileCheck %s --check-prefix=WITH-GC
 // RUN: %clang_cc1 -fsanitize=address 
-fsanitize-address-globals-dead-stripping -fno-integrated-as -emit-llvm -o - 
-triple x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 // RUN: %clang_cc1 -fsanitize=address -fdata-sections -emit-llvm -o - -triple 
x86_64-linux %s | FileCheck %s --check-prefix=WITHOUT-GC
 



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


[PATCH] D120289: [clang][dataflow] Add SAT solver interface and implementation

2022-02-23 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

In D120289#3341008 , @sgatev wrote:

> it seems tailored to the Z3 API.

As far as I understand, there were downstream patches that used the same API 
with other SMT solvers. The authors did not upstream it because they did not 
see any major improvement on Z3 for any of the use cases.

> What do you think about this? Any other options we should consider?

After reading your analysis, I'm fine with the current approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120289

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


[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

2022-02-23 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Actually, I did it myself in 34285bcd5ac260246c9d59708a63ea3d5972f75c


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

https://reviews.llvm.org/D109239

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


[clang] 34285bc - Reland "unbreak Modules/cxx20-export-import.cpp with LLVM_APPEND_VC_REV after 32b73bc6ab82"

2022-02-23 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2022-02-23T18:41:20-05:00
New Revision: 34285bcd5ac260246c9d59708a63ea3d5972f75c

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

LOG: Reland "unbreak Modules/cxx20-export-import.cpp with LLVM_APPEND_VC_REV 
after 32b73bc6ab82"

This reverts commit 5086cff04eec4327acc22a90466854ad4d89d570.
32b73bc6ab82 relanded in 1592d88aa7bc.

Added: 


Modified: 
clang/include/clang/Serialization/ASTBitCodes.h

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index f98e173b158c1..c94274ff34b8f 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -41,7 +41,7 @@ namespace serialization {
 /// Version 4 of AST files also requires that the version control branch and
 /// revision match exactly, since there is no backward compatibility of
 /// AST files at this time.
-const unsigned VERSION_MAJOR = 15;
+const unsigned VERSION_MAJOR = 16;
 
 /// AST file minor version number supported by this version of
 /// Clang.



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


[PATCH] D120132: [HIP] Fix HIP include path

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:531-532
+  DriverArgs.hasArg(options::OPT_nostdlibinc)) {
+CC1Args.push_back("-internal-isystem");
+CC1Args.push_back(HipIncludePath);
+  }

yaxunl wrote:
> tra wrote:
> > yaxunl wrote:
> > > tra wrote:
> > > > My impression, after reading the problem description, is that the 
> > > > actual issue is that we're using `-internal-isystem` for the HIP SDK 
> > > > includes , not that we add the include path to them.
> > > > 
> > > > Instead of trying to guess whether we happen to match some hardcoded 
> > > > path where we think the standard headers may live, I'd rather use `-I` 
> > > > or its internal equivalent, if we have it. Hardcoded paths *will* be 
> > > > wrong for someone. E.g. I'm pretty sure `/usr/anything` is not going to 
> > > > work on windows. Of for our internal builds.
> > > changing `-internal-isystem` to `-I` is a solution, as the same path 
> > > showing up first with both `-I` then with `-internal-isystem` will be 
> > > treated as `-internal-isystem` and placed in the latter position.
> > > 
> > > However, one drawback is that this may cause regression due to warnings 
> > > emitted for HIP headers.
> > > 
> > > I think I may let AddHIPIncludeArgs return the HIP include path instead 
> > > of adding it right away, then let clang add it after the system include 
> > > paths. I may rename AddHIPIncludeArgs as 
> > > AddHIPWrapperIncludeArgsAndGetHIPIncludePath. What do you think? Thanks. 
> > > one drawback is that this may cause regression due to warnings emitted 
> > > for HIP headers.
> > 
> > If I understand the patch description correctly, allowing these warnings 
> > was the purpose. Is that not the case?
> > 
> > > [current state] prevents warnings related to things like reserved 
> > > identifiers when including the HIP headers even when ROCm is installed in 
> > > a non-system directory, such as /opt/rocm.
> > 
> > I'm fine with separating include paths of wrappers and the SDK headers. I 
> > think we already do something similar for CUDA (though they are still added 
> > with -isystem-include).
> Some warnings are unnecessary for HIP header files e.g. warnings about macro 
> definitions starting with `__`. Some applications use -Wpedantic -Werror, 
> which can cause unnecessary errors in HIP header. Also we have customers who 
> use the latest clang with older HIP runtime. If we switch to `-I`, we may get 
> regressions.
> 
> AFAIK all language headers e.g. CUDA, OpenMP, are included by 
> `-internal-isystem` by clang, therefore I think HIP better follow this 
> convention.
I may have misinterpreted the patch description. 

So `-include-isystem` is not the problem. The problem is that when HIP SDK 
includes are installed under /usr, their inclusion along with the wrappers 
messes with the standard c/c++ header inclusion order . Separating the wrappers 
and HIP SDK include paths, and moving HIP includes towards the end of the 
search path is the way to fix it. HIP SDK headers will still be still included 
via `-isystem-include`.

Did I get that right?



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

https://reviews.llvm.org/D120132

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


[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

2022-02-23 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

In D109239#3331917 , @zahiraam wrote:

> In D109239#3331914 , @thakis wrote:
>
>> Thank you for reverting my follow-up as well!
>>
>> zahiraam, for the reland please include that follow-up fix in your commit :)
>
> Yes. Will do that. Thanks.

I think you might have forgotten to do it. Tests are failing again: 
http://45.33.8.238/linux/69422/step_7.txt

Can you reland the follow-up please?


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

https://reviews.llvm.org/D109239

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


[PATCH] D120132: [HIP] Fix HIP include path

2022-02-23 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:531-532
+  DriverArgs.hasArg(options::OPT_nostdlibinc)) {
+CC1Args.push_back("-internal-isystem");
+CC1Args.push_back(HipIncludePath);
+  }

tra wrote:
> yaxunl wrote:
> > tra wrote:
> > > My impression, after reading the problem description, is that the actual 
> > > issue is that we're using `-internal-isystem` for the HIP SDK includes , 
> > > not that we add the include path to them.
> > > 
> > > Instead of trying to guess whether we happen to match some hardcoded path 
> > > where we think the standard headers may live, I'd rather use `-I` or its 
> > > internal equivalent, if we have it. Hardcoded paths *will* be wrong for 
> > > someone. E.g. I'm pretty sure `/usr/anything` is not going to work on 
> > > windows. Of for our internal builds.
> > changing `-internal-isystem` to `-I` is a solution, as the same path 
> > showing up first with both `-I` then with `-internal-isystem` will be 
> > treated as `-internal-isystem` and placed in the latter position.
> > 
> > However, one drawback is that this may cause regression due to warnings 
> > emitted for HIP headers.
> > 
> > I think I may let AddHIPIncludeArgs return the HIP include path instead of 
> > adding it right away, then let clang add it after the system include paths. 
> > I may rename AddHIPIncludeArgs as 
> > AddHIPWrapperIncludeArgsAndGetHIPIncludePath. What do you think? Thanks. 
> > one drawback is that this may cause regression due to warnings emitted for 
> > HIP headers.
> 
> If I understand the patch description correctly, allowing these warnings was 
> the purpose. Is that not the case?
> 
> > [current state] prevents warnings related to things like reserved 
> > identifiers when including the HIP headers even when ROCm is installed in a 
> > non-system directory, such as /opt/rocm.
> 
> I'm fine with separating include paths of wrappers and the SDK headers. I 
> think we already do something similar for CUDA (though they are still added 
> with -isystem-include).
Some warnings are unnecessary for HIP header files e.g. warnings about macro 
definitions starting with `__`. Some applications use -Wpedantic -Werror, which 
can cause unnecessary errors in HIP header. Also we have customers who use the 
latest clang with older HIP runtime. If we switch to `-I`, we may get 
regressions.

AFAIK all language headers e.g. CUDA, OpenMP, are included by 
`-internal-isystem` by clang, therefore I think HIP better follow this 
convention.


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

https://reviews.llvm.org/D120132

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


[PATCH] D120298: [HIP] Support `-fgpu-default-stream`

2022-02-23 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D120298#3341250 , @tra wrote:

> LGTM with a minor nit.
>
>> Also -DHIP_API_PER_THREAD_DEFAULT_STREAM is passed to clang -cc1 to enable 
>> other per-thread stream
>
> You may want to rephrase patch description it a bit to match the latest code. 
> "HIP_API_PER_THREAD_DEFAULT_STREAM macro is set if ..."

will fix commit message when committing. thanks


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

https://reviews.llvm.org/D120298

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


[PATCH] D120383: [CMake] Use CMAKE_SYSROOT to build libs for Win to ARM cross tooolchain. NFC.

2022-02-23 Thread Vlad Vereschaka via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG18fa0b15ccf6: [CMake] Use CMAKE_SYSROOT to build libs for 
Win to ARM cross tooolchain. NFC. (authored by vvereschaka).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120383

Files:
  clang/cmake/caches/CrossWinToARMLinux.cmake

Index: clang/cmake/caches/CrossWinToARMLinux.cmake
===
--- clang/cmake/caches/CrossWinToARMLinux.cmake
+++ clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -10,7 +10,7 @@
 #
 # Configure:
 #  cmake -G Ninja ^
-#   -DTARGET_TRIPLE=armv7-linux-gnueabihf ^
+#   -DTARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
 #   -DCMAKE_INSTALL_PREFIX=../install ^
 #   -DDEFAULT_SYSROOT= ^
 #   -DLLVM_AR=/bin/llvm-ar[.exe] ^
@@ -25,10 +25,10 @@
 #  cmake --build . --target check-llvm
 #  cmake --build . --target check-clang
 #  cmake --build . --target check-lld
-#  cmake --build . --target check-compiler-rt
-#  cmake --build . --target check-cxxabi
-#  cmake --build . --target check-unwind
-#  cmake --build . --target check-cxx
+#  cmake --build . --target check-compiler-rt-
+#  cmake --build . --target check-cxxabi-
+#  cmake --build . --target check-unwind-
+#  cmake --build . --target check-cxx-
 
 # LLVM_PROJECT_DIR is the path to the llvm-project directory.
 # The right way to compute it would probably be to use "${CMAKE_SOURCE_DIR}/../",
@@ -86,49 +86,20 @@
 set(CMAKE_CROSSCOMPILINGON CACHE BOOL "")
 set(CMAKE_CL_SHOWINCLUDES_PREFIX"Note: including file: " CACHE STRING "")
 # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON
-set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_CXX_COMPILER_TARGET   "${TARGET_TRIPLE}" CACHE STRING "")
 
-set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIRON CACHE BOOL "")
+set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR  ON CACHE BOOL "")
 set(LLVM_DEFAULT_TARGET_TRIPLE  "${TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_TARGET_ARCH"${TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_LIT_ARGS   "-vv ${LLVM_LIT_ARGS}" CACHE STRING "" FORCE)
 
 set(CLANG_DEFAULT_LINKER"lld" CACHE STRING "")
 
-set(COMPILER_RT_BUILD_BUILTINS  ON CACHE BOOL "")
-set(COMPILER_RT_BUILD_SANITIZERSOFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_XRAY  OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_PROFILE   OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_CRT   OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_ORC   OFF CACHE BOOL "")
-set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "")
-set(COMPILER_RT_INCLUDE_TESTS   ON CACHE BOOL "")
-
-set(LIBUNWIND_USE_COMPILER_RT   ON CACHE BOOL "")
-set(LIBUNWIND_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBUNWIND_SYSROOT   "${DEFAULT_SYSROOT}" CACHE STRING "")
-set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
-
-set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
-set(LIBCXXABI_ENABLE_STATIC_UNWINDERON CACHE BOOL "")
-set(LIBCXXABI_USE_COMPILER_RT   ON CACHE BOOL "")
-set(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
-set(LIBCXXABI_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBCXXABI_SYSROOT   "${DEFAULT_SYSROOT}" CACHE STRING "")
-set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI OFF CACHE BOOL "")
-set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXOFF CACHE BOOL "")
-set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXXABIOFF CACHE BOOL "")
-set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXX   OFF CACHE BOOL "")
-
-set(LIBCXX_USE_COMPILER_RT  ON CACHE BOOL "")
-set(LIBCXX_TARGET_TRIPLE"${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBCXX_SYSROOT  "${DEFAULT_SYSROOT}" CACHE STRING "")
-set(LIBCXX_ENABLE_SHAREDOFF CACHE BOOL "")
-set(LIBCXX_CXX_ABI  "libcxxabi" CACHE STRING "")
-set(LIBCXX_CXX_ABI_INCLUDE_PATHS"${LLVM_PROJECT_DIR}/libcxxabi/include" CACHE PATH "")
-set(LIBCXX_CXX_ABI_LIBRARY_PATH "${CMAKE_BINARY_DIR}/lib/${LIBCXX_TARGET_TRIPLE}" CACHE PATH "")
-set(LIBCXX_ENABLE_NEW_DELETE_DEFINITIONSON CACHE BOOL "")
+if(WIN32)
+  set(CMAKE_MSVC_RUNTIME_LIBRARY"MultiThreaded" CACHE STRING "")
+  set(LLVM_USE_CRT_RELEASE  "MT" CACHE STRING "")
+endif()
 
 # Set up RPATH for the target runtime/builtin libraries.
 # See some details here: https://reviews.llvm.org/D91099
@@ -136,44 +107,90 @@
   

[clang] 18fa0b1 - [CMake] Use CMAKE_SYSROOT to build libs for Win to ARM cross tooolchain. NFC.

2022-02-23 Thread Vladimir Vereschaka via cfe-commits

Author: Vladimir Vereschaka
Date: 2022-02-23T15:16:56-08:00
New Revision: 18fa0b15ccf610f34af1231440f89d20cb99e7a0

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

LOG: [CMake] Use CMAKE_SYSROOT to build libs for Win to ARM cross tooolchain. 
NFC.

Provide CMAKE_SYSROOT for the libc++/libc++abi/libunwind libraries
instead of specific _SYSROOT for each of them.

Fixed passing some CMake arguments for the runtimes.

Referenced Differentials:
 * https://reviews.llvm.org/D119836
 * https://reviews.llvm.org/D112155
 * https://reviews.llvm.org/D111672

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

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index dd03a37b4b8f9..5165992b7b923 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -10,7 +10,7 @@
 #
 # Configure:
 #  cmake -G Ninja ^
-#   -DTARGET_TRIPLE=armv7-linux-gnueabihf ^
+#   -DTARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
 #   -DCMAKE_INSTALL_PREFIX=../install ^
 #   -DDEFAULT_SYSROOT= ^
 #   -DLLVM_AR=/bin/llvm-ar[.exe] ^
@@ -25,10 +25,10 @@
 #  cmake --build . --target check-llvm
 #  cmake --build . --target check-clang
 #  cmake --build . --target check-lld
-#  cmake --build . --target check-compiler-rt
-#  cmake --build . --target check-cxxabi
-#  cmake --build . --target check-unwind
-#  cmake --build . --target check-cxx
+#  cmake --build . --target check-compiler-rt-
+#  cmake --build . --target check-cxxabi-
+#  cmake --build . --target check-unwind-
+#  cmake --build . --target check-cxx-
 
 # LLVM_PROJECT_DIR is the path to the llvm-project directory.
 # The right way to compute it would probably be to use 
"${CMAKE_SOURCE_DIR}/../",
@@ -86,49 +86,20 @@ message(STATUS "Toolchain target triple: ${TARGET_TRIPLE}")
 set(CMAKE_CROSSCOMPILINGON CACHE BOOL "")
 set(CMAKE_CL_SHOWINCLUDES_PREFIX"Note: including file: " CACHE 
STRING "")
 # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON
-set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_CXX_COMPILER_TARGET   "${TARGET_TRIPLE}" CACHE STRING "")
 
-set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIRON CACHE BOOL "")
+set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR  ON CACHE BOOL "")
 set(LLVM_DEFAULT_TARGET_TRIPLE  "${TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_TARGET_ARCH"${TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_LIT_ARGS   "-vv ${LLVM_LIT_ARGS}" CACHE 
STRING "" FORCE)
 
 set(CLANG_DEFAULT_LINKER"lld" CACHE STRING "")
 
-set(COMPILER_RT_BUILD_BUILTINS  ON CACHE BOOL "")
-set(COMPILER_RT_BUILD_SANITIZERSOFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_XRAY  OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_LIBFUZZER OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_PROFILE   OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_CRT   OFF CACHE BOOL "")
-set(COMPILER_RT_BUILD_ORC   OFF CACHE BOOL "")
-set(COMPILER_RT_DEFAULT_TARGET_ONLY ON CACHE BOOL "")
-set(COMPILER_RT_INCLUDE_TESTS   ON CACHE BOOL "")
-
-set(LIBUNWIND_USE_COMPILER_RT   ON CACHE BOOL "")
-set(LIBUNWIND_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBUNWIND_SYSROOT   "${DEFAULT_SYSROOT}" CACHE STRING 
"")
-set(LIBUNWIND_ENABLE_SHARED OFF CACHE BOOL "")
-
-set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
-set(LIBCXXABI_ENABLE_STATIC_UNWINDERON CACHE BOOL "")
-set(LIBCXXABI_USE_COMPILER_RT   ON CACHE BOOL "")
-set(LIBCXXABI_ENABLE_NEW_DELETE_DEFINITIONS OFF CACHE BOOL "")
-set(LIBCXXABI_TARGET_TRIPLE "${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBCXXABI_SYSROOT   "${DEFAULT_SYSROOT}" CACHE STRING 
"")
-set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXABI OFF CACHE BOOL "")
-set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXOFF CACHE BOOL "")
-set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXXABIOFF CACHE BOOL "")
-set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXX   OFF CACHE BOOL "")
-
-set(LIBCXX_USE_COMPILER_RT  ON CACHE BOOL "")
-set(LIBCXX_TARGET_TRIPLE"${TARGET_TRIPLE}" CACHE STRING "")
-set(LIBCXX_SYSROOT  "${DEFAULT_SYSROOT}" CACHE STRING 
"")
-set(LIBCXX_ENABLE_SHAREDOFF CACHE BOOL "")
-set(LIBCXX_CXX_ABI  "libcxxabi" CACHE STRING "")

[clang] 119d71c - [OpenMP][NFC] Address warnings and lint messages in CGOpenMPRuntime

2022-02-23 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-02-23T18:07:25-05:00
New Revision: 119d71cb73a888a57b368cb5c74ac8ac07fb5c32

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

LOG: [OpenMP][NFC] Address warnings and lint messages in CGOpenMPRuntime

Summary:
This patch addressed the warnings and linting messages for the
CGOpenMPRuntime.cpp file. This was causing some -Werror builds to fail.

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 3f4a78ddbf3c..c02641c4cba9 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -1349,7 +1349,7 @@ static void buildStructValue(ConstantStructBuilder 
, CodeGenModule ,
   llvm::StructType *StructTy = RL.getLLVMType();
   unsigned PrevIdx = 0;
   ConstantInitBuilder CIBuilder(CGM);
-  auto DI = Data.begin();
+  const auto *DI = Data.begin();
   for (const FieldDecl *FD : RD->fields()) {
 unsigned Idx = RL.getLLVMFieldNo(FD);
 // Fill the alignment.
@@ -3975,7 +3975,7 @@ static bool checkInitIsRequired(CodeGenFunction ,
   continue;
 const VarDecl *VD = Pair.second.PrivateCopy;
 const Expr *Init = VD->getAnyInitializer();
-InitRequired = InitRequired || (Init && isa(Init) &&
+InitRequired = InitRequired || (isa_and_nonnull(Init) &&
 !CGF.isTrivialInitializer(Init));
 if (InitRequired)
   break;
@@ -5476,7 +5476,7 @@ llvm::Function *CGOpenMPRuntime::emitReductionFunction(
   //  *(Type*)lhs[i] = RedOp(*(Type*)lhs[i], *(Type*)rhs[i]);
   //  ...
   CodeGenFunction::OMPPrivateScope Scope(CGF);
-  auto IPriv = Privates.begin();
+  const auto *IPriv = Privates.begin();
   unsigned Idx = 0;
   for (unsigned I = 0, E = ReductionOps.size(); I < E; ++I, ++IPriv, ++Idx) {
 const auto *RHSVar =
@@ -5505,8 +5505,8 @@ llvm::Function *CGOpenMPRuntime::emitReductionFunction(
   }
   Scope.Privatize();
   IPriv = Privates.begin();
-  auto ILHS = LHSExprs.begin();
-  auto IRHS = RHSExprs.begin();
+  const auto *ILHS = LHSExprs.begin();
+  const auto *IRHS = RHSExprs.begin();
   for (const Expr *E : ReductionOps) {
 if ((*IPriv)->getType()->isArrayType()) {
   // Emit reduction for array section.
@@ -5601,9 +5601,9 @@ void CGOpenMPRuntime::emitReduction(CodeGenFunction , 
SourceLocation Loc,
 
   if (SimpleReduction) {
 CodeGenFunction::RunCleanupsScope Scope(CGF);
-auto IPriv = Privates.begin();
-auto ILHS = LHSExprs.begin();
-auto IRHS = RHSExprs.begin();
+const auto *IPriv = Privates.begin();
+const auto *ILHS = LHSExprs.begin();
+const auto *IRHS = RHSExprs.begin();
 for (const Expr *E : ReductionOps) {
   emitSingleReductionCombiner(CGF, E, *IPriv, cast(*ILHS),
   cast(*IRHS));
@@ -5628,7 +5628,7 @@ void CGOpenMPRuntime::emitReduction(CodeGenFunction , 
SourceLocation Loc,
  /*IndexTypeQuals=*/0);
   Address ReductionList =
   CGF.CreateMemTemp(ReductionArrayTy, ".omp.reduction.red_list");
-  auto IPriv = Privates.begin();
+  const auto *IPriv = Privates.begin();
   unsigned Idx = 0;
   for (unsigned I = 0, E = RHSExprs.size(); I < E; ++I, ++IPriv, ++Idx) {
 Address Elem = CGF.Builder.CreateConstArrayGEP(ReductionList, Idx);
@@ -5705,9 +5705,9 @@ void CGOpenMPRuntime::emitReduction(CodeGenFunction , 
SourceLocation Loc,
   auto & = [Privates, LHSExprs, RHSExprs, ReductionOps](
CodeGenFunction , PrePostActionTy ) {
 CGOpenMPRuntime  = CGF.CGM.getOpenMPRuntime();
-auto IPriv = Privates.begin();
-auto ILHS = LHSExprs.begin();
-auto IRHS = RHSExprs.begin();
+const auto *IPriv = Privates.begin();
+const auto *ILHS = LHSExprs.begin();
+const auto *IRHS = RHSExprs.begin();
 for (const Expr *E : ReductionOps) {
   RT.emitSingleReductionCombiner(CGF, E, *IPriv, cast(*ILHS),
  cast(*IRHS));
@@ -5739,9 +5739,9 @@ void CGOpenMPRuntime::emitReduction(CodeGenFunction , 
SourceLocation Loc,
 
   auto & = [Loc, Privates, LHSExprs, RHSExprs, ReductionOps](
  CodeGenFunction , PrePostActionTy ) {
-auto ILHS = LHSExprs.begin();
-auto IRHS = RHSExprs.begin();
-auto IPriv = Privates.begin();
+const auto *ILHS = LHSExprs.begin();
+const auto *IRHS = RHSExprs.begin();
+const auto *IPriv = Privates.begin();
 for (const Expr *E : ReductionOps) {
   const Expr *XExpr = nullptr;
   const Expr *EExpr = nullptr;
@@ -8352,7 +8352,7 @@ class MappableExprsHandler {
 }
 
 // Skip the dummy dimension since we have already have its information.
-auto DI = DimSizes.begin() + 1;
+auto 

[PATCH] D117611: [Sema] Warn about printf %n on Android and Fuchsia

2022-02-23 Thread Elliott Hughes via Phabricator via cfe-commits
enh added a comment.

In D117611#3339137 , @glandium wrote:

> This doesn't leave much room to use `__attribute__((format(printf)))` on 
> custom printf implementations that do support `%n` on Android does it?

it would be pretty hard to get into that situation though? apps are clones of 
the zygote, so you don't have any choice over your libc on Android: it's all 
bionic, all the time. (our seccomp policies also mean "good luck trying to run 
a static musl/glibc binary".) clang's Android target already assumes bionic in 
other ways --- things like whether math functions set errno, or whatever, so 
this seems in keeping to me.

ah, you don't mean *printf* implementations, you mean "other functions that 
take printf arguments"? yeah, that's a more interesting case. though that one's 
already broken: there's already no way to say what subset of printf formats you 
do/don't support. (all the ones in the Android OS itself are all subsets of the 
bionic printf; many equal, but several *much* smaller. that would be a pretty 
cool thing to be able to specify, but that's a much bigger bug, and this change 
brings us closer to reality than we currently are, for the 99% case :-) )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117611

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


[clang] 1592d88 - Add support for floating-point option `ffp-eval-method` and for

2022-02-23 Thread Zahira Ammarguellat via cfe-commits

Author: Zahira Ammarguellat
Date: 2022-02-23T15:00:18-08:00
New Revision: 1592d88aa7bc13c9f53cf09d25b98e7318a57bfb

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

LOG: Add support for floating-point option `ffp-eval-method` and for
`pragma clang fp eval_method`.

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

Added: 
clang/test/CodeGen/X86/32bit-behavior-no-eval.c
clang/test/CodeGen/X86/32bit-behavior.c
clang/test/CodeGen/X86/fp-eval-method.c
clang/test/CodeGen/flt_eval_macro.cpp
clang/test/Preprocessor/flt_eval_macro.cpp
clang/test/Sema/fp-eval-pragma.cpp
clang/test/Sema/x86-eval-method.c
clang/test/Sema/x86_64-eval-method.c

Modified: 
clang/docs/LanguageExtensions.rst
clang/docs/UsersManual.rst
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/FPOptions.def
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Basic/LangOptions.h
clang/include/clang/Basic/TargetInfo.h
clang/include/clang/Driver/Options.td
clang/include/clang/Lex/Preprocessor.h
clang/include/clang/Parse/Parser.h
clang/include/clang/Sema/Sema.h
clang/lib/Basic/Targets/OSTargets.h
clang/lib/Basic/Targets/X86.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/InitPreprocessor.cpp
clang/lib/Lex/PPMacroExpansion.cpp
clang/lib/Lex/Preprocessor.cpp
clang/lib/Parse/ParsePragma.cpp
clang/lib/Parse/ParseStmt.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaAttr.cpp
clang/lib/Sema/SemaExpr.cpp
clang/test/CodeGen/fp-floatcontrol-pragma.cpp
clang/test/Preprocessor/init-aarch64.c
clang/test/Preprocessor/init-arm.c
clang/test/Preprocessor/init-mips.c
clang/test/Preprocessor/init-ppc.c
clang/test/Preprocessor/init-ppc64.c
clang/test/Preprocessor/init-s390x.c
clang/test/Preprocessor/init-v7k-compat.c
clang/test/Preprocessor/init-x86.c
clang/test/Preprocessor/init.c

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 865a877b02190..aefb09afc82bb 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3940,6 +3940,38 @@ A ``#pragma clang fp`` pragma may contain any number of 
options:
 ...
   }
 
+``#pragma clang fp eval_method`` allows floating-point behavior to be specified
+for a section of the source code. This pragma can appear at file or namespace
+scope, or at the start of a compound statement (excluding comments).
+The pragma is active within the scope of the compound statement.
+
+When ``pragma clang fp eval_method(source)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=source`` is enabled. Rounds intermediate results to
+source-defined precision.
+
+When ``pragma clang fp eval_method(double)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=double`` is enabled. Rounds intermediate results to
+``double`` precision.
+
+When ``pragma clang fp eval_method(extended)`` is enabled, the section of code
+governed by the pragma behaves as though the command-line option
+``-ffp-eval-method=extended`` is enabled. Rounds intermediate results to
+target-dependent ``long double`` precision. In Win32 programming, for instance,
+the long double data type maps to the double, 64-bit precision data type.
+
+The full syntax this pragma supports is
+``#pragma clang fp eval_method(source|double|extended)``.
+
+.. code-block:: c++
+
+  for(...) {
+// The compiler will use long double as the floating-point evaluation
+// method.
+#pragma clang fp eval_method(extended)
+a = b[i] * c[i] + e;
+  }
 
 The ``#pragma float_control`` pragma allows precise floating-point
 semantics and floating-point exception behavior to be specified

diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index 981909aa16eaf..4a776eb86775c 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1566,6 +1566,22 @@ Note that floating-point operations performed as part of 
constant initialization
* ``maytrap`` The compiler avoids transformations that may raise exceptions 
that would not have been raised by the original code. Constant folding 
performed by the compiler is exempt from this option.
* ``strict`` The compiler ensures that all transformations strictly 
preserve the floating point exception semantics of the original code.
 
+.. option:: -ffp-eval-method=
+
+   Specify the floating-point evaluation method for intermediate results within
+   a single expression of the code.
+
+   Valid values are: ``source``, 

[PATCH] D119061: [Clang] noinline call site attribute

2022-02-23 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

In D119061#3340884 , @kuhar wrote:

> LGTM but please get at least one additional approval before submitting

Thank you. Yeah, I would like to get lgtm from @aaron.ballman here :)


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

https://reviews.llvm.org/D119061

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


[clang] dcc4feb - Use function prototypes when appropriate; NFC

2022-02-23 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2022-02-23T17:12:25-05:00
New Revision: dcc4feb9a49ab88e892dd626ebb0a69ff5a8dc42

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

LOG: Use function prototypes when appropriate; NFC

Added: 


Modified: 
clang/test/Analysis/taint-generic.c
clang/test/Driver/riscv-default-features.c
clang/test/OpenMP/atomic_compare_codegen.cpp

Removed: 




diff  --git a/clang/test/Analysis/taint-generic.c 
b/clang/test/Analysis/taint-generic.c
index 0612e1b9f98bf..a2eac46cfa781 100644
--- a/clang/test/Analysis/taint-generic.c
+++ b/clang/test/Analysis/taint-generic.c
@@ -407,7 +407,7 @@ void testUnknownFunction(void (*foo)(void)) {
   foo(); // no-crash
 }
 
-void testProctitleFalseNegative() {
+void testProctitleFalseNegative(void) {
   char flag[80];
   fscanf(stdin, "%79s", flag);
   char *argv[] = {"myapp", flag};

diff  --git a/clang/test/Driver/riscv-default-features.c 
b/clang/test/Driver/riscv-default-features.c
index 07b0778cd9938..853e4dbb2fd4b 100644
--- a/clang/test/Driver/riscv-default-features.c
+++ b/clang/test/Driver/riscv-default-features.c
@@ -4,6 +4,6 @@
 // RV64: "target-features"="+64bit,+a,+c,+m,+relax,-save-restore"
 
 // Dummy function
-int foo(){
+int foo(void){
   return  3;
 }

diff  --git a/clang/test/OpenMP/atomic_compare_codegen.cpp 
b/clang/test/OpenMP/atomic_compare_codegen.cpp
index 9d3dcf0fee138..0645917ee9f79 100644
--- a/clang/test/OpenMP/atomic_compare_codegen.cpp
+++ b/clang/test/OpenMP/atomic_compare_codegen.cpp
@@ -12,7 +12,7 @@
 #ifndef HEADER
 #define HEADER
 
-void foo() {
+void foo(void) {
   char cx, ce, cd;
   unsigned char ucx, uce, ucd;
   short sx, se, sd;



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


[clang] 1d1b089 - Fix more unused lambda capture warnings, NFC

2022-02-23 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2022-02-23T14:07:04-08:00
New Revision: 1d1b089c5d503e2fc8697887411730105f66c774

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

LOG: Fix more unused lambda capture warnings, NFC

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index b4033da890c4..3f4a78ddbf3c 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -10358,8 +10358,8 @@ void CGOpenMPRuntime::emitTargetCall(
   llvm::Value *MapTypesArray = nullptr;
   llvm::Value *MapNamesArray = nullptr;
   // Generate code for the host fallback function.
-  auto & = [this, OutlinedFn, , , RequiresOuterTask,
-, OffloadingMandatory](CodeGenFunction ) {
+  auto & = [this, , OutlinedFn, , 
RequiresOuterTask, ,
+OffloadingMandatory](CodeGenFunction ) {
 if (OffloadingMandatory) {
   CGF.Builder.CreateUnreachable();
 } else {
@@ -10371,9 +10371,8 @@ void CGOpenMPRuntime::emitTargetCall(
 }
   };
   // Fill up the pointer arrays and transfer execution to the device.
-  auto & = [this, Device, OutlinedFn, OutlinedFnID, , ,
-, , , RequiresOuterTask,
-, SizeEmitter,
+  auto & = [this, Device, OutlinedFnID, , ,
+, , SizeEmitter,
 FallbackGen](CodeGenFunction , PrePostActionTy &) {
 if (Device.getInt() == OMPC_DEVICE_ancestor) {
   // Reverse offloading is not supported, so just execute on the host.
@@ -10392,6 +10391,7 @@ void CGOpenMPRuntime::emitTargetCall(
 
 // From this point on, we need to have an ID of the target region defined.
 assert(OutlinedFnID && "Invalid outlined function ID!");
+(void)OutlinedFnID;
 
 // Emit device ID if any.
 llvm::Value *DeviceID;
@@ -10529,8 +10529,7 @@ void CGOpenMPRuntime::emitTargetCall(
   };
 
   // Notify that the host version must be executed.
-  auto & = [this, , OutlinedFn, , , 
RequiresOuterTask,
-FallbackGen](CodeGenFunction , PrePostActionTy &) {
+  auto & = [FallbackGen](CodeGenFunction , PrePostActionTy &) {
 FallbackGen(CGF);
   };
 



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


[clang] cd37594 - Fix unused lambda capture warning, NFC

2022-02-23 Thread Reid Kleckner via cfe-commits

Author: Reid Kleckner
Date: 2022-02-23T14:01:01-08:00
New Revision: cd37594c0374f287318d47818cc6d55496d3e9c0

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

LOG: Fix unused lambda capture warning, NFC

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index b57495b042d2a..b4033da890c4c 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -10358,9 +10358,8 @@ void CGOpenMPRuntime::emitTargetCall(
   llvm::Value *MapTypesArray = nullptr;
   llvm::Value *MapNamesArray = nullptr;
   // Generate code for the host fallback function.
-  auto & = [this, OutlinedFn, OutlinedFnID, , ,
-RequiresOuterTask, ,
-OffloadingMandatory](CodeGenFunction ) {
+  auto & = [this, OutlinedFn, , , RequiresOuterTask,
+, OffloadingMandatory](CodeGenFunction ) {
 if (OffloadingMandatory) {
   CGF.Builder.CreateUnreachable();
 } else {



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


[PATCH] D119157: [NVPTX] Add ex2 f16 support

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG69a8350c232a: [NVPTX] Add ex2.approx.f16/f16x2 support 
(authored by npmiller, committed by tra).

Changed prior to commit:
  https://reviews.llvm.org/D119157?vs=406507=410932#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119157

Files:
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/test/CodeGen/NVPTX/f16-ex2.ll


Index: llvm/test/CodeGen/NVPTX/f16-ex2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/NVPTX/f16-ex2.ll
@@ -0,0 +1,20 @@
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_75 -mattr=+ptx70 | FileCheck %s
+
+declare half @llvm.nvvm.ex2.approx.f16(half)
+declare <2 x half> @llvm.nvvm.ex2.approx.f16x2(<2 x half>)
+
+; CHECK-LABEL: exp2_half
+define half @exp2_half(half %0) {
+  ; CHECK-NOT: call
+  ; CHECK: ex2.approx.f16
+  %res = call half @llvm.nvvm.ex2.approx.f16(half %0);
+  ret half %res
+}
+
+; CHECK-LABEL: exp2_2xhalf
+define <2 x half> @exp2_2xhalf(<2 x half> %0) {
+  ; CHECK-NOT: call
+  ; CHECK: ex2.approx.f16x2
+  %res = call <2 x half> @llvm.nvvm.ex2.approx.f16x2(<2 x half> %0);
+  ret <2 x half> %res
+}
Index: llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
===
--- llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
+++ llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
@@ -907,6 +907,10 @@
   Float32Regs, Float32Regs, int_nvvm_ex2_approx_f>;
 def INT_NVVM_EX2_APPROX_D : F_MATH_1<"ex2.approx.f64 \t$dst, $src0;",
   Float64Regs, Float64Regs, int_nvvm_ex2_approx_d>;
+def INT_NVVM_EX2_APPROX_F16 : F_MATH_1<"ex2.approx.f16 \t$dst, $src0;",
+  Float16Regs, Float16Regs, int_nvvm_ex2_approx_f16, [hasPTX70, hasSM75]>;
+def INT_NVVM_EX2_APPROX_F16X2 : F_MATH_1<"ex2.approx.f16x2 \t$dst, $src0;",
+  Float16x2Regs, Float16x2Regs, int_nvvm_ex2_approx_f16x2, [hasPTX70, 
hasSM75]>;
 
 def INT_NVVM_LG2_APPROX_FTZ_F : F_MATH_1<"lg2.approx.ftz.f32 \t$dst, $src0;",
   Float32Regs, Float32Regs, int_nvvm_lg2_approx_ftz_f>;
Index: llvm/include/llvm/IR/IntrinsicsNVVM.td
===
--- llvm/include/llvm/IR/IntrinsicsNVVM.td
+++ llvm/include/llvm/IR/IntrinsicsNVVM.td
@@ -828,6 +828,10 @@
   DefaultAttrsIntrinsic<[llvm_float_ty], [llvm_float_ty], [IntrNoMem]>;
   def int_nvvm_ex2_approx_d : GCCBuiltin<"__nvvm_ex2_approx_d">,
   DefaultAttrsIntrinsic<[llvm_double_ty], [llvm_double_ty], [IntrNoMem]>;
+  def int_nvvm_ex2_approx_f16 : GCCBuiltin<"__nvvm_ex2_approx_f16">,
+  DefaultAttrsIntrinsic<[llvm_half_ty], [llvm_half_ty], [IntrNoMem]>;
+  def int_nvvm_ex2_approx_f16x2 : GCCBuiltin<"__nvvm_ex2_approx_f16x2">,
+  DefaultAttrsIntrinsic<[llvm_v2f16_ty], [llvm_v2f16_ty], [IntrNoMem]>;
 
   def int_nvvm_lg2_approx_ftz_f : GCCBuiltin<"__nvvm_lg2_approx_ftz_f">,
   DefaultAttrsIntrinsic<[llvm_float_ty], [llvm_float_ty], [IntrNoMem]>;


Index: llvm/test/CodeGen/NVPTX/f16-ex2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/NVPTX/f16-ex2.ll
@@ -0,0 +1,20 @@
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_75 -mattr=+ptx70 | FileCheck %s
+
+declare half @llvm.nvvm.ex2.approx.f16(half)
+declare <2 x half> @llvm.nvvm.ex2.approx.f16x2(<2 x half>)
+
+; CHECK-LABEL: exp2_half
+define half @exp2_half(half %0) {
+  ; CHECK-NOT: call
+  ; CHECK: ex2.approx.f16
+  %res = call half @llvm.nvvm.ex2.approx.f16(half %0);
+  ret half %res
+}
+
+; CHECK-LABEL: exp2_2xhalf
+define <2 x half> @exp2_2xhalf(<2 x half> %0) {
+  ; CHECK-NOT: call
+  ; CHECK: ex2.approx.f16x2
+  %res = call <2 x half> @llvm.nvvm.ex2.approx.f16x2(<2 x half> %0);
+  ret <2 x half> %res
+}
Index: llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
===
--- llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
+++ llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
@@ -907,6 +907,10 @@
   Float32Regs, Float32Regs, int_nvvm_ex2_approx_f>;
 def INT_NVVM_EX2_APPROX_D : F_MATH_1<"ex2.approx.f64 \t$dst, $src0;",
   Float64Regs, Float64Regs, int_nvvm_ex2_approx_d>;
+def INT_NVVM_EX2_APPROX_F16 : F_MATH_1<"ex2.approx.f16 \t$dst, $src0;",
+  Float16Regs, Float16Regs, int_nvvm_ex2_approx_f16, [hasPTX70, hasSM75]>;
+def INT_NVVM_EX2_APPROX_F16X2 : F_MATH_1<"ex2.approx.f16x2 \t$dst, $src0;",
+  Float16x2Regs, Float16x2Regs, int_nvvm_ex2_approx_f16x2, [hasPTX70, hasSM75]>;
 
 def INT_NVVM_LG2_APPROX_FTZ_F : F_MATH_1<"lg2.approx.ftz.f32 \t$dst, $src0;",
   Float32Regs, Float32Regs, int_nvvm_lg2_approx_ftz_f>;
Index: llvm/include/llvm/IR/IntrinsicsNVVM.td
===
--- llvm/include/llvm/IR/IntrinsicsNVVM.td
+++ llvm/include/llvm/IR/IntrinsicsNVVM.td
@@ -828,6 +828,10 @@
   

[PATCH] D118977: [NVPTX] Add more FMA intriniscs/builtins

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe672934ff88: [NVPTX] Add more FMA intriniscs/builtins 
(authored by jchlanda, committed by tra).

Changed prior to commit:
  https://reviews.llvm.org/D118977?vs=407904=410931#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118977

Files:
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp
  llvm/test/CodeGen/NVPTX/math-intrins-sm53-ptx42.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70-instcombine.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll

Index: llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll
===
--- llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll
+++ llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll
@@ -36,6 +36,7 @@
 
 ; CHECK-LABEL: fmin_xorsign_abs_f16
 define half @fmin_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.xorsign.abs.f16
   %res = call half @llvm.nvvm.fmin.xorsign.abs.f16(half %0, half %1)
   ret half %res
@@ -43,6 +44,7 @@
 
 ; CHECK-LABEL: fmin_ftz_xorsign_abs_f16
 define half @fmin_ftz_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.ftz.xorsign.abs.f16
   %res = call half @llvm.nvvm.fmin.ftz.xorsign.abs.f16(half %0, half %1)
   ret half %res
@@ -50,6 +52,7 @@
 
 ; CHECK-LABEL: fmin_nan_xorsign_abs_f16
 define half @fmin_nan_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.NaN.xorsign.abs.f16
   %res = call half @llvm.nvvm.fmin.nan.xorsign.abs.f16(half %0, half %1)
   ret half %res
@@ -57,6 +60,7 @@
 
 ; CHECK-LABEL: fmin_ftz_nan_xorsign_abs_f16
 define half @fmin_ftz_nan_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.ftz.NaN.xorsign.abs.f16
   %res = call half @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f16(half %0, half %1)
   ret half %res
@@ -64,6 +68,7 @@
 
 ; CHECK-LABEL: fmin_xorsign_abs_f16x2
 define <2 x half> @fmin_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.xorsign.abs.f16x2
   %res = call <2 x half> @llvm.nvvm.fmin.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
   ret <2 x half> %res
@@ -71,6 +76,7 @@
 
 ; CHECK-LABEL: fmin_ftz_xorsign_abs_f16x2
 define <2 x half> @fmin_ftz_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.ftz.xorsign.abs.f16x2
   %res = call <2 x half> @llvm.nvvm.fmin.ftz.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
   ret <2 x half> %res
@@ -78,6 +84,7 @@
 
 ; CHECK-LABEL: fmin_nan_xorsign_abs_f16x2
 define <2 x half> @fmin_nan_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.NaN.xorsign.abs.f16x2
   %res = call <2 x half> @llvm.nvvm.fmin.nan.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
   ret <2 x half> %res
@@ -85,6 +92,7 @@
 
 ; CHECK-LABEL: fmin_ftz_nan_xorsign_abs_f16x2
 define <2 x half> @fmin_ftz_nan_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.ftz.NaN.xorsign.abs.f16x2
   %res = call <2 x half> @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
   ret <2 x half> %res
@@ -92,6 +100,7 @@
 
 ; CHECK-LABEL: fmin_xorsign_abs_bf16
 define i16 @fmin_xorsign_abs_bf16(i16 %0, i16 %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.xorsign.abs.bf16
   %res = call i16 @llvm.nvvm.fmin.xorsign.abs.bf16(i16 %0, i16 %1)
   ret i16 %res
@@ -99,6 +108,7 @@
 
 ; CHECK-LABEL: fmin_nan_xorsign_abs_bf16
 define i16 @fmin_nan_xorsign_abs_bf16(i16 %0, i16 %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.NaN.xorsign.abs.bf16
   %res = call i16 @llvm.nvvm.fmin.nan.xorsign.abs.bf16(i16 %0, i16 %1)
   ret i16 %res
@@ -106,6 +116,7 @@
 
 ; CHECK-LABEL: fmin_xorsign_abs_bf16x2
 define i32 @fmin_xorsign_abs_bf16x2(i32 %0, i32 %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.xorsign.abs.bf16x2
   %res = call i32 @llvm.nvvm.fmin.xorsign.abs.bf16x2(i32 %0, i32 %1)
   ret i32 %res
@@ -113,6 +124,7 @@
 
 ; CHECK-LABEL: fmin_nan_xorsign_abs_bf16x2
 define i32 @fmin_nan_xorsign_abs_bf16x2(i32 %0, i32 %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.NaN.xorsign.abs.bf16x2
   %res = call i32 @llvm.nvvm.fmin.nan.xorsign.abs.bf16x2(i32 %0, i32 %1)
   ret i32 %res
@@ -120,6 +132,7 @@
 
 ; CHECK-LABEL: fmin_xorsign_abs_f
 define float @fmin_xorsign_abs_f(float %0, float %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.xorsign.abs.f
   %res = call float @llvm.nvvm.fmin.xorsign.abs.f(float %0, float %1)
   ret float %res
@@ -127,6 +140,7 @@
 
 ; CHECK-LABEL: fmin_ftz_xorsign_abs_f
 define float @fmin_ftz_xorsign_abs_f(float %0, float %1) {
+  ; CHECK-NOT: call
   ; CHECK: min.ftz.xorsign.abs.f
   %res = call float 

[PATCH] D117887: [NVPTX] Expose float tys min, max, abs, neg as builtins

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe0dc4ac28f00: [NVPTX] Expose float tys min, max, abs, neg as 
builtins (authored by jchlanda, committed by tra).

Changed prior to commit:
  https://reviews.llvm.org/D117887?vs=405161=410930#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117887

Files:
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70-instcombine.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm80-ptx70.ll
  llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll

Index: llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll
===
--- /dev/null
+++ llvm/test/CodeGen/NVPTX/math-intrins-sm86-ptx72.ll
@@ -0,0 +1,259 @@
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_86 -mattr=+ptx72 | FileCheck %s
+
+declare half @llvm.nvvm.fmin.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmin.ftz.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmin.nan.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f16(half, half)
+declare <2 x half> @llvm.nvvm.fmin.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.ftz.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.nan.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare i16 @llvm.nvvm.fmin.xorsign.abs.bf16(i16, i16)
+declare i16 @llvm.nvvm.fmin.nan.xorsign.abs.bf16(i16, i16)
+declare i32 @llvm.nvvm.fmin.xorsign.abs.bf16x2(i32, i32)
+declare i32 @llvm.nvvm.fmin.nan.xorsign.abs.bf16x2(i32, i32)
+declare float @llvm.nvvm.fmin.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmin.ftz.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmin.nan.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f(float, float)
+
+declare half @llvm.nvvm.fmax.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmax.ftz.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmax.nan.xorsign.abs.f16(half, half)
+declare half @llvm.nvvm.fmax.ftz.nan.xorsign.abs.f16(half, half)
+declare <2 x half> @llvm.nvvm.fmax.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.ftz.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.nan.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare <2 x half> @llvm.nvvm.fmax.ftz.nan.xorsign.abs.f16x2(<2 x half> , <2 x half>)
+declare i16 @llvm.nvvm.fmax.xorsign.abs.bf16(i16, i16)
+declare i16 @llvm.nvvm.fmax.nan.xorsign.abs.bf16(i16, i16)
+declare i32 @llvm.nvvm.fmax.xorsign.abs.bf16x2(i32, i32)
+declare i32 @llvm.nvvm.fmax.nan.xorsign.abs.bf16x2(i32, i32)
+declare float @llvm.nvvm.fmax.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmax.ftz.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmax.nan.xorsign.abs.f(float, float)
+declare float @llvm.nvvm.fmax.ftz.nan.xorsign.abs.f(float, float)
+
+; CHECK-LABEL: fmin_xorsign_abs_f16
+define half @fmin_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK: min.xorsign.abs.f16
+  %res = call half @llvm.nvvm.fmin.xorsign.abs.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_ftz_xorsign_abs_f16
+define half @fmin_ftz_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK: min.ftz.xorsign.abs.f16
+  %res = call half @llvm.nvvm.fmin.ftz.xorsign.abs.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_nan_xorsign_abs_f16
+define half @fmin_nan_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK: min.NaN.xorsign.abs.f16
+  %res = call half @llvm.nvvm.fmin.nan.xorsign.abs.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_ftz_nan_xorsign_abs_f16
+define half @fmin_ftz_nan_xorsign_abs_f16(half %0, half %1) {
+  ; CHECK: min.ftz.NaN.xorsign.abs.f16
+  %res = call half @llvm.nvvm.fmin.ftz.nan.xorsign.abs.f16(half %0, half %1)
+  ret half %res
+}
+
+; CHECK-LABEL: fmin_xorsign_abs_f16x2
+define <2 x half> @fmin_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK: min.xorsign.abs.f16x2
+  %res = call <2 x half> @llvm.nvvm.fmin.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
+  ret <2 x half> %res
+}
+
+; CHECK-LABEL: fmin_ftz_xorsign_abs_f16x2
+define <2 x half> @fmin_ftz_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK: min.ftz.xorsign.abs.f16x2
+  %res = call <2 x half> @llvm.nvvm.fmin.ftz.xorsign.abs.f16x2(<2 x half> %0, <2 x half> %1)
+  ret <2 x half> %res
+}
+
+; CHECK-LABEL: fmin_nan_xorsign_abs_f16x2
+define <2 x half> @fmin_nan_xorsign_abs_f16x2(<2 x half> %0, <2 x half> %1) {
+  ; CHECK: min.NaN.xorsign.abs.f16x2
+  %res = call <2 x half> @llvm.nvvm.fmin.nan.xorsign.abs.f16x2(<2 x half> %0, <2 x half> 

[clang] 0c1fd90 - [Clang][Docs] Add '-fopenmp-offload-mandatory' to command line reference

2022-02-23 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-02-23T16:54:01-05:00
New Revision: 0c1fd90fe0828aa87518d9be542bd00d36d258d7

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

LOG: [Clang][Docs] Add '-fopenmp-offload-mandatory' to command line reference

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index c03a4c2bbc1e1..77c20d3646500 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -2097,6 +2097,10 @@ Enable debugging in the OpenMP offloading device RTL
 
 Use the new bitcode library for OpenMP offloading
 
+.. option:: -fopenmp-offload-mandatory
+
+Indicate that offloading to the device is mandatory and do not generate 
host-fallback code.
+
 .. option:: -fopenmp-version=
 
 Set OpenMP version (e.g. 45 for OpenMP 4.5, 50 for OpenMP 5.0). Default value 
is 50.



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


[PATCH] D120323: [clang][SVE] Add support for arithmetic operators on SVE types

2022-02-23 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Is there a corresponding ARM specification update for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120323

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2b97b16f294a: [OpenMP] Add option to make offloading 
mandatory (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_offload_mandatory_codegen.cpp

Index: clang/test/OpenMP/target_offload_mandatory_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_offload_mandatory_codegen.cpp
@@ -0,0 +1,90 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --include-generated-funcs --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -fopenmp-offload-mandatory -emit-llvm %s -o - | FileCheck %s --check-prefix=MANDATORY
+// expected-no-diagnostics
+
+void foo() {}
+#pragma omp declare target(foo)
+
+void bar() {}
+#pragma omp declare target device_type(nohost) to(bar)
+
+void host() {
+#pragma omp target
+  { bar(); }
+}
+
+void host_if(bool cond) {
+#pragma omp target if(cond)
+  { bar(); }
+}
+
+void host_dev(int device) {
+#pragma omp target device(device)
+  { bar(); }
+}
+// MANDATORY-LABEL: define {{[^@]+}}@_Z3foov
+// MANDATORY-SAME: () #[[ATTR0:[0-9]+]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z4hostv
+// MANDATORY-SAME: () #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[TMP0:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1:[0-9]+]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z4hostv_l12.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP1:%.*]] = icmp ne i32 [[TMP0]], 0
+// MANDATORY-NEXT:br i1 [[TMP1]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z7host_ifb
+// MANDATORY-SAME: (i1 noundef zeroext [[COND:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[COND_ADDR:%.*]] = alloca i8, align 1
+// MANDATORY-NEXT:[[FROMBOOL:%.*]] = zext i1 [[COND]] to i8
+// MANDATORY-NEXT:store i8 [[FROMBOOL]], i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i8, i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// MANDATORY-NEXT:br i1 [[TOBOOL]], label [[OMP_IF_THEN:%.*]], label [[OMP_IF_ELSE:%.*]]
+// MANDATORY:   omp_if.then:
+// MANDATORY-NEXT:[[TMP1:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z7host_ifb_l17.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP2:%.*]] = icmp ne i32 [[TMP1]], 0
+// MANDATORY-NEXT:br i1 [[TMP2]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:br label [[OMP_IF_END:%.*]]
+// MANDATORY:   omp_if.else:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_if.end:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z8host_devi
+// MANDATORY-SAME: (i32 noundef signext [[DEVICE:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[DEVICE_ADDR:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:[[DOTCAPTURE_EXPR_:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:store i32 [[DEVICE]], i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i32, i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:store i32 [[TMP0]], i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP1:%.*]] = load i32, i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP2:%.*]] = sext i32 [[TMP1]] to i64
+// MANDATORY-NEXT:[[TMP3:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 [[TMP2]], i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z8host_devi_l22.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP4:%.*]] = icmp ne i32 [[TMP3]], 0
+// MANDATORY-NEXT:br i1 [[TMP4]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:

[clang] 2b97b16 - [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2022-02-23T16:45:36-05:00
New Revision: 2b97b16f294af91281d8a138759f3f772952a902

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

LOG: [OpenMP] Add option to make offloading mandatory

Currently when we generate OpenMP offloading code we always make
fallback code for the CPU. This is necessary for implementing features
like conditional offloading and ensuring that unhandled pragmas don't
result in missing symbols. However, this is problematic for a few cases.
For offloading tests we can silently fail to the host without realizing
that offloading failed. Additionally, this makes it impossible to
provide interoperabiility to other offloading schemes like HIP or CUDA
because those methods do not provide any such host fallback guaruntee.
this patch adds the `-fopenmp-offload-mandatory` flag to prevent
generating the fallback symbol on the CPU and instead replaces the
function with a dummy global and the failed branch with 'unreachable'.

Reviewed By: ABataev

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

Added: 
clang/test/OpenMP/target_offload_mandatory_codegen.cpp

Modified: 
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Driver/Options.td
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Sema/SemaOpenMP.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index e21998860f217..6af474d613c98 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -247,6 +247,7 @@ LANGOPT(OpenMPOptimisticCollapse  , 1, 0, "Use at most 32 
bits to represent the
 LANGOPT(OpenMPThreadSubscription  , 1, 0, "Assume work-shared loops do not 
have more iterations than participating threads.")
 LANGOPT(OpenMPTeamSubscription  , 1, 0, "Assume distributed loops do not have 
more iterations than participating teams.")
 LANGOPT(OpenMPNoThreadState  , 1, 0, "Assume that no thread in a parallel 
region will modify an ICV.")
+LANGOPT(OpenMPOffloadMandatory  , 1, 0, "Assert that offloading is mandatory 
and do not create a host fallback.")
 LANGOPT(RenderScript  , 1, 0, "RenderScript")
 
 LANGOPT(CUDAIsDevice  , 1, 0, "compiling for CUDA device")

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index fcee066905703..6314f025e0585 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2479,6 +2479,10 @@ def fopenmp_assume_no_thread_state : Flag<["-"], 
"fopenmp-assume-no-thread-state
   Flags<[CC1Option, NoArgumentUnused, HelpHidden]>, 
   HelpText<"Assert no thread in a parallel region modifies an ICV">,
   MarshallingInfoFlag>;
+def fopenmp_offload_mandatory : Flag<["-"], "fopenmp-offload-mandatory">, 
Group, 
+  Flags<[CC1Option, NoArgumentUnused]>, 
+  HelpText<"Do not create a host fallback if offloading to the device fails.">,
+  MarshallingInfoFlag>;
 defm openmp_target_new_runtime: BoolFOption<"openmp-target-new-runtime",
   LangOpts<"OpenMPTargetNewRuntime">, DefaultTrue,
   PosFlag,

diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index a77658060be72..b57495b042d2a 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -6538,6 +6538,8 @@ void CGOpenMPRuntime::emitTargetOutlinedFunctionHelper(
   // mangled name of the function that encloses the target region and BB is the
   // line number of the target region.
 
+  const bool BuildOutlinedFn = CGM.getLangOpts().OpenMPIsDevice ||
+   !CGM.getLangOpts().OpenMPOffloadMandatory;
   unsigned DeviceID;
   unsigned FileID;
   unsigned Line;
@@ -6556,7 +6558,8 @@ void CGOpenMPRuntime::emitTargetOutlinedFunctionHelper(
   CGOpenMPTargetRegionInfo CGInfo(CS, CodeGen, EntryFnName);
   CodeGenFunction::CGCapturedStmtRAII CapInfoRAII(CGF, );
 
-  OutlinedFn = CGF.GenerateOpenMPCapturedStmtFunction(CS, D.getBeginLoc());
+  if (BuildOutlinedFn)
+OutlinedFn = CGF.GenerateOpenMPCapturedStmtFunction(CS, D.getBeginLoc());
 
   // If this target outline function is not an offload entry, we don't need to
   // register it.
@@ -6588,26 +6591,38 @@ void CGOpenMPRuntime::emitTargetOutlinedFunctionHelper(
 llvm::Constant::getNullValue(CGM.Int8Ty), Name);
   }
 
+  // If we do not allow host fallback we still need a named address to use.
+  llvm::Constant *TargetRegionEntryAddr = OutlinedFn;
+  if (!BuildOutlinedFn) {
+assert(!CGM.getModule().getGlobalVariable(EntryFnName, true) &&
+   "Named kernel already exists?");
+TargetRegionEntryAddr = new llvm::GlobalVariable(
+

[clang] 4cb24ef - [clang] Remove Address::deprecated() from CGClass.cpp

2022-02-23 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2022-02-23T13:31:56-08:00
New Revision: 4cb24ef90a691489f22a36976a1b33acd65901fa

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

LOG: [clang] Remove Address::deprecated() from CGClass.cpp

Added: 


Modified: 
clang/lib/CodeGen/CGClass.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/CodeGen/CGExprScalar.cpp
clang/lib/CodeGen/CodeGenFunction.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGClass.cpp b/clang/lib/CodeGen/CGClass.cpp
index 9a175d1f59d2b..4a49fc4a80c58 100644
--- a/clang/lib/CodeGen/CGClass.cpp
+++ b/clang/lib/CodeGen/CGClass.cpp
@@ -2691,8 +2691,7 @@ void CodeGenFunction::EmitVTablePtrCheckForCall(const 
CXXRecordDecl *RD,
   EmitVTablePtrCheck(RD, VTable, TCK, Loc);
 }
 
-void CodeGenFunction::EmitVTablePtrCheckForCast(QualType T,
-llvm::Value *Derived,
+void CodeGenFunction::EmitVTablePtrCheckForCast(QualType T, Address Derived,
 bool MayBeNull,
 CFITypeCheckKind TCK,
 SourceLocation Loc) {
@@ -2715,7 +2714,7 @@ void CodeGenFunction::EmitVTablePtrCheckForCast(QualType 
T,
 
   if (MayBeNull) {
 llvm::Value *DerivedNotNull =
-Builder.CreateIsNotNull(Derived, "cast.nonnull");
+Builder.CreateIsNotNull(Derived.getPointer(), "cast.nonnull");
 
 llvm::BasicBlock *CheckBlock = createBasicBlock("cast.check");
 ContBlock = createBasicBlock("cast.cont");
@@ -2726,8 +2725,8 @@ void CodeGenFunction::EmitVTablePtrCheckForCast(QualType 
T,
   }
 
   llvm::Value *VTable;
-  std::tie(VTable, ClassDecl) = CGM.getCXXABI().LoadVTablePtr(
-  *this, Address::deprecated(Derived, getPointerAlign()), ClassDecl);
+  std::tie(VTable, ClassDecl) =
+  CGM.getCXXABI().LoadVTablePtr(*this, Derived, ClassDecl);
 
   EmitVTablePtrCheck(ClassDecl, VTable, TCK, Loc);
 

diff  --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 37f9a79c71325..8f1e60805356e 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -1109,7 +1109,7 @@ Address CodeGenFunction::EmitPointerWithAlignment(const 
Expr *E,
 if (SanOpts.has(SanitizerKind::CFIUnrelatedCast) &&
 CE->getCastKind() == CK_BitCast) {
   if (auto PT = E->getType()->getAs())
-EmitVTablePtrCheckForCast(PT->getPointeeType(), Addr.getPointer(),
+EmitVTablePtrCheckForCast(PT->getPointeeType(), Addr,
   /*MayBeNull=*/true,
   CodeGenFunction::CFITCK_UnrelatedCast,
   CE->getBeginLoc());
@@ -4756,7 +4756,7 @@ LValue CodeGenFunction::EmitCastLValue(const CastExpr *E) 
{
 Derived.getPointer(), E->getType());
 
 if (SanOpts.has(SanitizerKind::CFIDerivedCast))
-  EmitVTablePtrCheckForCast(E->getType(), Derived.getPointer(),
+  EmitVTablePtrCheckForCast(E->getType(), Derived,
 /*MayBeNull=*/false, CFITCK_DerivedCast,
 E->getBeginLoc());
 
@@ -4774,7 +4774,7 @@ LValue CodeGenFunction::EmitCastLValue(const CastExpr *E) 
{
 ConvertTypeForMem(CE->getTypeAsWritten()->getPointeeType()));
 
 if (SanOpts.has(SanitizerKind::CFIUnrelatedCast))
-  EmitVTablePtrCheckForCast(E->getType(), V.getPointer(),
+  EmitVTablePtrCheckForCast(E->getType(), V,
 /*MayBeNull=*/false, CFITCK_UnrelatedCast,
 E->getBeginLoc());
 

diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index d3db63f9917fe..93fb7d37c3445 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -2039,11 +2039,16 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
 }
 
 if (CGF.SanOpts.has(SanitizerKind::CFIUnrelatedCast)) {
-  if (auto PT = DestTy->getAs())
-CGF.EmitVTablePtrCheckForCast(PT->getPointeeType(), Src,
-  /*MayBeNull=*/true,
-  CodeGenFunction::CFITCK_UnrelatedCast,
-  CE->getBeginLoc());
+  if (auto PT = DestTy->getAs()) {
+CGF.EmitVTablePtrCheckForCast(
+PT->getPointeeType(),
+Address(Src,
+CGF.ConvertTypeForMem(
+E->getType()->getAs()->getPointeeType()),
+CGF.getPointerAlign()),
+/*MayBeNull=*/true, CodeGenFunction::CFITCK_UnrelatedCast,
+CE->getBeginLoc());
+  }
 }
 
 if (CGF.CGM.getCodeGenOpts().StrictVTablePointers) {

[PATCH] D120266: [clang][CodeGen] Avoid emitting ifuncs with undefined resolvers

2022-02-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D120266#3341378 , @ibookstein 
wrote:

> Yeah, that's what happens with this patch; Reference binds against an 
> `llvm::Function` declaration, linker resolves it to the actual ifunc in 
> another translation unit and therefore emits IFUNC relocation.
>
> Thinking about it more, this is inelegant. I would have liked the reference 
> against the `cpu_specific` to bind against a plain "FOO" function declaration 
> and not "FOO.ifunc", and 'upgrade' it later once a cpu_dispatch is 
> encountered.
> To my understanding, this is actually the reason 
> https://reviews.llvm.org/D67058 added the plain-name alias.
>
> I'll try to see if I can rework that.

I was actually in favor of that... The problem is that the cpu-dispatch in a 
different TU should be what is found, and there is value to having the linker 
failure in that case.  I wouldn't want something like:

TU1:

  [[cpu_specific(generic)]]
  void foo(){}
  void caller() {
  foo();
  }

TU2:

  void foo() {
  some weirdo generic impl
  }

to work in this case.

The point of that other review was the inverse: someone who DIDN'T know about 
the multiversioning could get it.  We don't want this (not getting 
multiversioning even though you expect it!) to work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120266

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


[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-23 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray marked an inline comment as done.
lichray added a comment.

In D113393#3340878 , @aaron.ballman 
wrote:

> I spotted some test coverage that I think we should add:
>
>   static_cast(whatever);
>   reinterpret_cast(whatever);
>   const_cast(whatever);
>   dynamic_cast(whatever);
>   (auto)whatever;

Done.

> Are there changes needed for the AST printer for this new form of cast 
> notation?

Wow, I broke AST print. CTAD works in expressions and new because their 
specializations are valid type-ids...

> I suppose one other question worth asking: if we're allowing 
> `decltype(auto)(whatever)` as a Clang extension, should we be accepting 
> `__typeof__(auto)(whatever)` as well?

We don't allow `__typeof__(auto)` type-specifier at the moment, so not yet. I 
think it may be more reasonable to allow both `__typeof__(auto)` and 
`typeof(auto)` when implementing C23 `typeof`. Their expression forms should be 
useful in C++.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113393

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


[PATCH] D120266: [clang][CodeGen] Avoid emitting ifuncs with undefined resolvers

2022-02-23 Thread Itay Bookstein via Phabricator via cfe-commits
ibookstein added a comment.

Yeah, that's what happens with this patch; Reference binds against an 
`llvm::Function` declaration, linker resolves it to the actual ifunc in another 
translation unit and therefore emits IFUNC relocation.

Thinking about it more, this is inelegant. I would have liked the reference 
against the `cpu_specific` to bind against a plain "FOO" function declaration 
and not "FOO.ifunc", and 'upgrade' it later once a cpu_dispatch is encountered.
To my understanding, this is actually the reason 
https://reviews.llvm.org/D67058 added the plain-name alias.

I'll try to see if I can rework that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120266

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 410919.
jhuber6 added a comment.

Guarding where we set attrs in the case that it's not a valid function now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_offload_mandatory_codegen.cpp

Index: clang/test/OpenMP/target_offload_mandatory_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_offload_mandatory_codegen.cpp
@@ -0,0 +1,90 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --include-generated-funcs --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -fopenmp-offload-mandatory -emit-llvm %s -o - | FileCheck %s --check-prefix=MANDATORY
+// expected-no-diagnostics
+
+void foo() {}
+#pragma omp declare target(foo)
+
+void bar() {}
+#pragma omp declare target device_type(nohost) to(bar)
+
+void host() {
+#pragma omp target
+  { bar(); }
+}
+
+void host_if(bool cond) {
+#pragma omp target if(cond)
+  { bar(); }
+}
+
+void host_dev(int device) {
+#pragma omp target device(device)
+  { bar(); }
+}
+// MANDATORY-LABEL: define {{[^@]+}}@_Z3foov
+// MANDATORY-SAME: () #[[ATTR0:[0-9]+]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z4hostv
+// MANDATORY-SAME: () #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[TMP0:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1:[0-9]+]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z4hostv_l12.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP1:%.*]] = icmp ne i32 [[TMP0]], 0
+// MANDATORY-NEXT:br i1 [[TMP1]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z7host_ifb
+// MANDATORY-SAME: (i1 noundef zeroext [[COND:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[COND_ADDR:%.*]] = alloca i8, align 1
+// MANDATORY-NEXT:[[FROMBOOL:%.*]] = zext i1 [[COND]] to i8
+// MANDATORY-NEXT:store i8 [[FROMBOOL]], i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i8, i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// MANDATORY-NEXT:br i1 [[TOBOOL]], label [[OMP_IF_THEN:%.*]], label [[OMP_IF_ELSE:%.*]]
+// MANDATORY:   omp_if.then:
+// MANDATORY-NEXT:[[TMP1:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z7host_ifb_l17.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP2:%.*]] = icmp ne i32 [[TMP1]], 0
+// MANDATORY-NEXT:br i1 [[TMP2]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:br label [[OMP_IF_END:%.*]]
+// MANDATORY:   omp_if.else:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_if.end:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z8host_devi
+// MANDATORY-SAME: (i32 noundef signext [[DEVICE:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[DEVICE_ADDR:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:[[DOTCAPTURE_EXPR_:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:store i32 [[DEVICE]], i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i32, i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:store i32 [[TMP0]], i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP1:%.*]] = load i32, i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP2:%.*]] = sext i32 [[TMP1]] to i64
+// MANDATORY-NEXT:[[TMP3:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 [[TMP2]], i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z8host_devi_l22.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP4:%.*]] = icmp ne i32 [[TMP3]], 0
+// MANDATORY-NEXT:br i1 [[TMP4]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:ret void
+//
+//
+// 

[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-23 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray updated this revision to Diff 410915.
lichray added a comment.

- Add more tests to diagnose other forms of casts


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113393

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p5.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.auto.deduct/p2.cpp
  clang/test/CXX/expr/expr.post/expr.type.conv/p1-2b.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx14.cpp
  clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
  clang/test/Parser/cxx2b-auto-x.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1388,6 +1388,11 @@
   https://wg21.link/P2360R0;>P2360R0
   Clang 14
 
+
+  auto(x): decay-copy in the language
+  https://wg21.link/P0849R8;>P0849R8
+  Clang 15
+
 
 
   Attributes on Lambda-Expressions
Index: clang/test/SemaCXX/deduced-return-type-cxx14.cpp
===
--- clang/test/SemaCXX/deduced-return-type-cxx14.cpp
+++ clang/test/SemaCXX/deduced-return-type-cxx14.cpp
@@ -442,6 +442,15 @@
   B() : decltype(auto)() {} // expected-error {{'decltype(auto)' not allowed here}}
 };
   }
+
+  namespace Cast {
+void foo() {
+  (void)decltype(auto)(0); // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+  (void)decltype(auto){0}; // cxx14_20-error{{'decltype(auto)' not allowed here}} \
+  cxx2b-warning{{functional-style cast to 'decltype(auto)' is a Clang extension}}
+}
+  }
 }
 
 namespace CurrentInstantiation {
Index: clang/test/Parser/cxx2b-auto-x.cpp
===
--- /dev/null
+++ clang/test/Parser/cxx2b-auto-x.cpp
@@ -0,0 +1,24 @@
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx2b -std=c++2b -Wpre-c++2b-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,cxx20 -std=c++20 %s
+
+void looks_like_decltype_auto() {
+  decltype(auto(42)) b = 42; // cxx20-error {{'auto' not allowed here}} \
+cxx2b-warning {{'auto' as a functional-style cast is incompatible with C++ standards before C++2b}}
+  decltype(long *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto *) a = 42;   // expected-error {{expected '(' for function-style cast or type construction}} \
+expected-error {{expected expression}}
+  decltype(auto()) c = 42;   // cxx2b-error {{initializer for functional-style cast to 'auto' is empty}} \
+cxx20-error {{'auto' not allowed here}}
+}
+
+struct looks_like_declaration {
+  int n;
+} a;
+
+using T = looks_like_declaration *;
+void f() { T()->n = 1; }
+// FIXME: They should be deemed expressions without breaking function pointer
+//parameter declarations with trailing return types.
+// void g() { auto()->n = 0; }
+// void h() { auto{}->n = 0; }
Index: clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
===
--- clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
+++ clang/test/CXX/expr/expr.unary/expr.new/p2-cxx1z.cpp
@@ -1,11 +1,30 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
 // RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++17 -pedantic
 
+// [expr.new]p2 ... the invented declaration: T x init ;
+// C++2b [dcl.type.auto.deduct]p2.2
+// For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.
 void f() {
+  // - If the initializer is a parenthesized expression-list, the expression-list shall be a single assignmentexpression and E is the assignment-expression.
   new auto('a');
-  new auto {2};
-  new auto {1, 2}; // expected-error{{new expression for type 'auto' contains multiple constructor arguments}}
-  new auto {}; // expected-error{{new expression for type 'auto' requires a constructor argument}}
-  new decltype(auto)({1});
-  new decltype(auto)({1, 2}); // expected-error{{new expression for type 'decltype(auto)' contains multiple constructor arguments}}
+  new decltype(auto)('a');
+  // - If the initializer is a braced-init-list, it shall consist of a single 

[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp:119
+++End;
+  return llvm::makeArrayRef([Start], [End]);
+}

hokein wrote:
> aaron.ballman wrote:
> > This is causing an assertion with debug builds on Windows because 
> > `Actions[End]` is out of bounds (so the MSVC STL debug assertions catch the 
> > issue) for the test cases in this patch.
>  this should be `llvm::makeArrayRef([Start], End - Start)`. Fixed in 
> 302ca279cb83043ef7d60115eb5ba58f12064a4a.
I can confirm that the issue is now fixed for me, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118196

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


[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-02-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp:119
+++End;
+  return llvm::makeArrayRef([Start], [End]);
+}

aaron.ballman wrote:
> This is causing an assertion with debug builds on Windows because 
> `Actions[End]` is out of bounds (so the MSVC STL debug assertions catch the 
> issue) for the test cases in this patch.
 this should be `llvm::makeArrayRef([Start], End - Start)`. Fixed in 
302ca279cb83043ef7d60115eb5ba58f12064a4a.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118196

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


[clang] 302ca27 - [pseudo] fix an out-of-bound error in LRTable.

2022-02-23 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2022-02-23T21:34:54+01:00
New Revision: 302ca279cb83043ef7d60115eb5ba58f12064a4a

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

LOG: [pseudo] fix an out-of-bound error in LRTable.

Fix window debug build.

Added: 


Modified: 
clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp 
b/clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp
index 4a817a527f2fa..23c455941ff5b 100644
--- a/clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp
+++ b/clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp
@@ -117,7 +117,7 @@ llvm::ArrayRef LRTable::find(StateID Src, 
SymbolID ID) const {
   size_t Start = It - States.data(), End = Start;
   while (End < States.size() && States[End] == Src)
 ++End;
-  return llvm::makeArrayRef([Start], [End]);
+  return llvm::makeArrayRef([Start], End - Start);
 }
 
 } // namespace pseudo



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


[PATCH] D120360: [libTooling] Generalize string explanation as Any metadata

2022-02-23 Thread Eric Li via Phabricator via cfe-commits
li.zhe.hua marked an inline comment as done.
li.zhe.hua added a comment.

In D120360#3341118 , @ymandel wrote:

> High level question: why use `Any` rather than templating?

(Aside: Not sure how to "respond" to comments... just quote in a new comment?)

So, I had a version of this, but I ended up bifurcating the type into 
`RewriteRule` (with no metadata) and `RewriteRuleWith` (with `T` metadata). 
I wasn't sure if the cost of having two types here was worth it. For interfaces 
that didn't care about the metadata generation, there wasn't an easy way to 
accept a `RewriteRule`-like parameter.

Finally, there was a question of migration. All uses of `RewriteRule` with 
`TransformerClangTidyCheck` would need to switch over to 
`RewriteRuleWith`, and I wasn't sure how pervasive that might be. 
I'm not set on `Any`, but splitting the type does seem rather costly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120360

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


[PATCH] D120298: [HIP] Support `-fgpu-default-stream`

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

LGTM with a minor nit.

> Also -DHIP_API_PER_THREAD_DEFAULT_STREAM is passed to clang -cc1 to enable 
> other per-thread stream

You may want to rephrase patch description it a bit to match the latest code. 
"HIP_API_PER_THREAD_DEFAULT_STREAM macro is set if ..."


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

https://reviews.llvm.org/D120298

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


[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D118196#3341159 , @hokein wrote:

> In D118196#3341110 , @aaron.ballman 
> wrote:
>
>> Hi, this commit is causing runtime failures on Windows in debug builds. Can 
>> you please correct or revert? Thanks!
>
> sorry for the trouble. I'm mostly running out of time today, I will revert 
> this patch, and fix it tomorrow.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118196

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


[PATCH] D120159: [Clang] Implement __builtin_source_location.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Ah, one more thing I missed -- you should add a release note for this 
functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120159

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


[PATCH] D120159: [Clang] Implement __builtin_source_location.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thank you for this! I've got some initial comments on it.

Btw, I think there may be some functionality missing for AST dumping, so I'd 
like to see some additional tests for that.




Comment at: clang/docs/LanguageExtensions.rst:3343-3344
+defined, and must contain exactly four fields: ``const char *_M_file_name``,
+``const char *_M_function_name``, `` _M_line``, and
+`` _M_column``. The fields will be populated in the same
+manner as the above four builtins, except that ``_M_function_name`` is 
populated

Doesn't the type for `` matter though, due to layout 
differences based on the size of the integer type picked?

Also, a downside of requiring this type to be defined before the builtin can be 
used is that this builtin would otherwise be suitable in C, but there's no way 
to name that particular type. Is there anything we can do to keep this builtin 
generic enough to be used in C as well?



Comment at: clang/include/clang/AST/DeclCXX.h:4191
 
+/// An artificial decl, representing am global anonymous constant value which 
is
+/// uniquified by value within a compilation.





Comment at: clang/include/clang/AST/DeclCXX.h:4192
+/// An artificial decl, representing am global anonymous constant value which 
is
+/// uniquified by value within a compilation.
+///

I presume this is what was meant, right?



Comment at: clang/include/clang/AST/DeclCXX.h:4221
+  /// Print this in a human-readable format.
+  void printName(llvm::raw_ostream ) const override;
+

`printName()` in a class named `UnnamedGlobalConstantDecl` (which isn't a 
`NamedDecl`) seems a bit confusing as to what this actually prints.

Also, what is this overriding? `NamedDecl` has a virtual `printName()` 
function, but `ValueDecl` does not. I have the sneaking suspicion that this can 
be removed.



Comment at: clang/include/clang/AST/Expr.h:4709
 
-  bool isStringType() const {
+  bool isIntType() const {
 switch (getIdentKind()) {

Should this also be marked `LLVM_READONLY` as in the original interface?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11506-11509
+def err_std_source_location_impl_not_found : Error<
+  "std::source_location::__impl was not found; it must be defined before 
__builtin_source_location is called.">;
+def err_std_source_location_impl_malformed : Error<
+  "std::source_location::__impl must be standard-layout and have only two 
'const char *' fields _M_file_name and _M_function_name, and two integral 
fields _M_line and _M_column.">;





Comment at: clang/include/clang/Serialization/ASTBitCodes.h:44
 /// AST files at this time.
 const unsigned VERSION_MAJOR = 15;
 

Do we need to bump this value now that we have a new kind of AST node?



Comment at: clang/lib/AST/Expr.cpp:2270
+// __builtin_FUNCTION() above returns!
+const Decl *CurDecl = dyn_cast_or_null(Context);
+Value.getStructField(F->getFieldIndex()) = MakeStringLiteral(

Under what conditions can `Context` be null? (should this be a `dyn_cast` 
instead?)



Comment at: clang/lib/AST/ExprClassification.cpp:468-471
 islvalue = isa(D) || isa(D) ||
-   isa(D) ||
-   isa(D) ||
-   isa(D) ||
+   isa(D) || isa(D) ||
+   isa(D) || isa(D) ||
isa(D) ||

Plus fix the formatting that I'm sure I broke.



Comment at: clang/lib/AST/ExprClassification.cpp:473-474
(Ctx.getLangOpts().CPlusPlus &&
 (isa(D) || isa(D) ||
  isa(D)));
 





Comment at: clang/lib/AST/ExprConstant.cpp:1982-1983
+// ... the address of an unnamed global constant
+return isa(D) || isa(D) ||
+   isa(D);
   }





Comment at: clang/lib/AST/ExprConstant.cpp:8830-8832
+  // (GCC apparently doesn't diagnose casts from void* to T* in constant
+  // evaluation, regardless of the types of the object or pointer; a
+  // subsequent access through the wrong type is diagnosed, however).

Do we want to be even more restrictive here and tie it to libstdc++ (e.g., like 
we did in 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclCXX.cpp#L12352)



Comment at: clang/lib/Sema/SemaExpr.cpp:3257
 
-  // Enum constants are always r-values and never references.
+// Enum constants are always r-values and never references.
   // Unresolved using declarations are dependent.

Spurious indentation change?



Comment at: clang/lib/Sema/SemaExpr.cpp:3405
+  case Decl::UnnamedGlobalConstant:
+valueKind = VK_LValue;
+break;


[PATCH] D120360: [libTooling] Generalize string explanation as Any metadata

2022-02-23 Thread Eric Li via Phabricator via cfe-commits
li.zhe.hua updated this revision to Diff 410907.
li.zhe.hua added a comment.

Update alias


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120360

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Transformer.h
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Transformer.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -31,6 +31,7 @@
 using ::clang::transformer::member;
 using ::clang::transformer::name;
 using ::clang::transformer::node;
+using ::clang::transformer::noEdits;
 using ::clang::transformer::remove;
 using ::clang::transformer::rewriteDescendants;
 using ::clang::transformer::RewriteRule;
@@ -137,27 +138,59 @@
 };
   }
 
-  template 
-  void testRule(R Rule, StringRef Input, StringRef Expected) {
+  std::function>)>
+  consumerWithStringMetadata() {
+return [this](Expected> C) {
+  if (C) {
+Changes.insert(Changes.end(),
+   std::make_move_iterator(C->Changes.begin()),
+   std::make_move_iterator(C->Changes.end()));
+StringMetadata.push_back(std::move(C->Metadata));
+  } else {
+// FIXME: stash this error rather then printing.
+llvm::errs() << "Error generating changes: "
+ << llvm::toString(C.takeError()) << "\n";
+++ErrorCount;
+  }
+};
+  }
+
+  void testRule(RewriteRule Rule, StringRef Input, StringRef Expected) {
 Transformers.push_back(
 std::make_unique(std::move(Rule), consumer()));
 Transformers.back()->registerMatchers();
 compareSnippets(Expected, rewrite(Input));
   }
 
-  template  void testRuleFailure(R Rule, StringRef Input) {
+  void testRuleWithMetadata(RewriteRule Rule, StringRef Input,
+StringRef Expected) {
+Transformers.push_back(std::make_unique(
+std::move(Rule), consumerWithStringMetadata()));
+Transformers.back()->registerMatchers();
+compareSnippets(Expected, rewrite(Input));
+  }
+
+  void testRuleFailure(RewriteRule Rule, StringRef Input) {
 Transformers.push_back(
 std::make_unique(std::move(Rule), consumer()));
 Transformers.back()->registerMatchers();
 ASSERT_FALSE(rewrite(Input)) << "Expected failure to rewrite code";
   }
 
+  void testRuleFailureWithMetadata(RewriteRule Rule, StringRef Input) {
+Transformers.push_back(std::make_unique(
+std::move(Rule), consumerWithStringMetadata()));
+Transformers.back()->registerMatchers();
+ASSERT_FALSE(rewrite(Input)) << "Expected failure to rewrite code";
+  }
+
   // Transformers are referenced by MatchFinder.
   std::vector> Transformers;
   clang::ast_matchers::MatchFinder MatchFinder;
   // Records whether any errors occurred in individual changes.
   int ErrorCount = 0;
   AtomicChanges Changes;
+  std::vector StringMetadata;
 
 private:
   FileContentMappings FileContents = {{"header.h", ""}};
@@ -1682,4 +1715,40 @@
"./input.h";
 }
 
+TEST_F(TransformerTest, GeneratesMetadata) {
+  std::string Input = R"cc(int target = 0;)cc";
+  std::string Expected = R"cc(REPLACE)cc";
+  testRuleWithMetadata(makeRule(varDecl(hasName("target")),
+edit(changeTo(cat("REPLACE"))),
+cat("METADATA")),
+   Input, Expected);
+  EXPECT_EQ(ErrorCount, 0);
+  EXPECT_THAT(StringMetadata, UnorderedElementsAre("METADATA"));
+}
+
+TEST_F(TransformerTest, GeneratesMetadataWithNoEdits) {
+  std::string Input = R"cc(int target = 0;)cc";
+  testRuleWithMetadata(makeRule(varDecl(hasName("target")).bind("var"),
+noEdits(), cat("METADATA")),
+   Input, Input);
+  EXPECT_EQ(ErrorCount, 0);
+  EXPECT_THAT(StringMetadata, UnorderedElementsAre("METADATA"));
+}
+
+TEST_F(TransformerTest, PropagateMetadataErrors) {
+  class AlwaysFail : public transformer::MatchComputation {
+llvm::Error eval(const ast_matchers::MatchFinder::MatchResult &,
+ std::string *) const override {
+  return llvm::createStringError(llvm::errc::invalid_argument, "ERROR");
+}
+std::string toString() const override { return "AlwaysFail"; }
+  };
+  std::string Input = R"cc(int target = 0;)cc";
+  testRuleFailureWithMetadata(makeRule(varDecl(hasName("target")).bind("var"),
+   edit(changeTo(cat("REPLACE"))),
+   std::make_shared()),
+  Input);
+  EXPECT_EQ(ErrorCount, 1);
+}
+
 } // namespace
Index: 

[PATCH] D120132: [HIP] Fix HIP include path

2022-02-23 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:531-532
+  DriverArgs.hasArg(options::OPT_nostdlibinc)) {
+CC1Args.push_back("-internal-isystem");
+CC1Args.push_back(HipIncludePath);
+  }

yaxunl wrote:
> tra wrote:
> > My impression, after reading the problem description, is that the actual 
> > issue is that we're using `-internal-isystem` for the HIP SDK includes , 
> > not that we add the include path to them.
> > 
> > Instead of trying to guess whether we happen to match some hardcoded path 
> > where we think the standard headers may live, I'd rather use `-I` or its 
> > internal equivalent, if we have it. Hardcoded paths *will* be wrong for 
> > someone. E.g. I'm pretty sure `/usr/anything` is not going to work on 
> > windows. Of for our internal builds.
> changing `-internal-isystem` to `-I` is a solution, as the same path showing 
> up first with both `-I` then with `-internal-isystem` will be treated as 
> `-internal-isystem` and placed in the latter position.
> 
> However, one drawback is that this may cause regression due to warnings 
> emitted for HIP headers.
> 
> I think I may let AddHIPIncludeArgs return the HIP include path instead of 
> adding it right away, then let clang add it after the system include paths. I 
> may rename AddHIPIncludeArgs as AddHIPWrapperIncludeArgsAndGetHIPIncludePath. 
> What do you think? Thanks. 
> one drawback is that this may cause regression due to warnings emitted for 
> HIP headers.

If I understand the patch description correctly, allowing these warnings was 
the purpose. Is that not the case?

> [current state] prevents warnings related to things like reserved identifiers 
> when including the HIP headers even when ROCm is installed in a non-system 
> directory, such as /opt/rocm.

I'm fine with separating include paths of wrappers and the SDK headers. I think 
we already do something similar for CUDA (though they are still added with 
-isystem-include).


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

https://reviews.llvm.org/D120132

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


[PATCH] D120359: [clang-format][NFC] Remove redundant semi

2022-02-23 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks updated this revision to Diff 410904.
HazardyKnusperkeks added a comment.

Corrected diff.


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

https://reviews.llvm.org/D120359

Files:
  clang/unittests/Format/TokenAnnotatorTest.cpp


Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -42,7 +42,7 @@
   do { 
\
 EXPECT_TOKEN_KIND(FormatTok, Kind);
\
 EXPECT_TOKEN_TYPE(FormatTok, Type);
\
-  } while (false);
+  } while (false)
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmpInMacroDefinition) {
   // This is a regression test for mis-parsing the & after decltype as a binary


Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -42,7 +42,7 @@
   do { \
 EXPECT_TOKEN_KIND(FormatTok, Kind);\
 EXPECT_TOKEN_TYPE(FormatTok, Type);\
-  } while (false);
+  } while (false)
 
 TEST_F(TokenAnnotatorTest, UnderstandsUsesOfStarAndAmpInMacroDefinition) {
   // This is a regression test for mis-parsing the & after decltype as a binary
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120426: [Sema] Mark the referenced destructor during transformation of a `CXXBindTemporaryExpr`

2022-02-23 Thread Argyrios Kyrtzidis via Phabricator via cfe-commits
akyrtzi created this revision.
akyrtzi requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Otherwise we will fail to generate the definition of a defaulted destructor,
if the only reference was in a templated temporary.

rdar://89366678


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120426

Files:
  clang/lib/Sema/TreeTransform.h
  clang/test/SemaTemplate/defaulted-destructor-in-temporary.cpp


Index: clang/test/SemaTemplate/defaulted-destructor-in-temporary.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/defaulted-destructor-in-temporary.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -std=c++11 %s -emit-llvm -o - | FileCheck %s
+
+// CHECK: define linkonce_odr {{.*}} @_ZN3StrD1Ev
+
+class A {
+public:
+  ~A();
+};
+class Str {
+  A d;
+
+public:
+  ~Str() = default;
+};
+class E {
+  Str s;
+  template 
+  void h() {
+s = {};
+  }
+  void f();
+};
+void E::f() {
+  h();
+}
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -12748,6 +12748,9 @@
 template
 ExprResult
 TreeTransform::TransformCXXBindTemporaryExpr(CXXBindTemporaryExpr *E) 
{
+  SemaRef.MarkFunctionReferenced(
+  E->getBeginLoc(),
+  const_cast(E->getTemporary()->getDestructor()));
   return getDerived().TransformExpr(E->getSubExpr());
 }
 


Index: clang/test/SemaTemplate/defaulted-destructor-in-temporary.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/defaulted-destructor-in-temporary.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -std=c++11 %s -emit-llvm -o - | FileCheck %s
+
+// CHECK: define linkonce_odr {{.*}} @_ZN3StrD1Ev
+
+class A {
+public:
+  ~A();
+};
+class Str {
+  A d;
+
+public:
+  ~Str() = default;
+};
+class E {
+  Str s;
+  template 
+  void h() {
+s = {};
+  }
+  void f();
+};
+void E::f() {
+  h();
+}
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -12748,6 +12748,9 @@
 template
 ExprResult
 TreeTransform::TransformCXXBindTemporaryExpr(CXXBindTemporaryExpr *E) {
+  SemaRef.MarkFunctionReferenced(
+  E->getBeginLoc(),
+  const_cast(E->getTemporary()->getDestructor()));
   return getDerived().TransformExpr(E->getSubExpr());
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-02-23 Thread Haojian Wu via Phabricator via cfe-commits
hokein added a comment.

In D118196#3341110 , @aaron.ballman 
wrote:

> Hi, this commit is causing runtime failures on Windows in debug builds. Can 
> you please correct or revert? Thanks!

sorry for the trouble. I'm mostly running out of time today, I will revert this 
patch, and fix it tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118196

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


[PATCH] D119271: CGCall: also emit LLVM `allocalign` attribute when handling AllocAlign

2022-02-23 Thread Augie Fackler via Phabricator via cfe-commits
durin42 updated this revision to Diff 410896.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119271

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/alloc-align-attr.c
  clang/test/CodeGen/alloc-fns-alignment.c
  clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c
  
clang/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function-variable.cpp
  
clang/test/CodeGen/catch-alignment-assumption-attribute-alloc_align-on-function.cpp
  clang/test/CodeGen/non-power-of-2-alignment-assumptions.c
  clang/test/CodeGenCXX/builtin-operator-new-delete.cpp
  clang/test/CodeGenCXX/cxx1z-aligned-allocation.cpp

Index: clang/test/CodeGenCXX/cxx1z-aligned-allocation.cpp
===
--- clang/test/CodeGenCXX/cxx1z-aligned-allocation.cpp
+++ clang/test/CodeGenCXX/cxx1z-aligned-allocation.cpp
@@ -27,10 +27,10 @@
 struct OVERALIGNED A { A(); int n[128]; };
 
 // CHECK-LABEL: define {{.*}} @_Z2a0v()
-// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnwmSt11align_val_t(i64 noundef 512, i64 noundef 32)
+// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnwmSt11align_val_t(i64 noundef 512, i64 allocalign noundef 32)
 // CHECK: call void @_ZdlPvSt11align_val_t(i8* noundef %[[ALLOC]], i64 noundef 32)
 // CHECK-MS-LABEL: define {{.*}} @"?a0@@YAPEAXXZ"()
-// CHECK-MS: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @"??2@YAPEAX_KW4align_val_t@std@@@Z"(i64 noundef 512, i64 noundef 32)
+// CHECK-MS: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @"??2@YAPEAX_KW4align_val_t@std@@@Z"(i64 noundef 512, i64 allocalign noundef 32)
 // CHECK-MS: cleanuppad
 // CHECK-MS: call void @"??3@YAXPEAXW4align_val_t@std@@@Z"(i8* noundef %[[ALLOC]], i64 noundef 32)
 void *a0() { return new A; }
@@ -39,13 +39,13 @@
 // The size is known.
 //
 // CHECK-LABEL: define {{.*}} @_Z2a1l(
-// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnamSt11align_val_t(i64 noundef %{{.*}}, i64 noundef 32)
+// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnamSt11align_val_t(i64 noundef %{{.*}}, i64 allocalign noundef 32)
 // No array cookie.
 // CHECK-NOT: store
 // CHECK: invoke void @_ZN1AC1Ev(
 // CHECK: call void @_ZdaPvSt11align_val_t(i8* noundef %[[ALLOC]], i64 noundef 32)
 // CHECK-MS-LABEL: define {{.*}} @"?a1@@YAPEAXJ@Z"(
-// CHECK-MS: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @"??_U@YAPEAX_KW4align_val_t@std@@@Z"(i64 noundef %{{.*}}, i64 noundef 32)
+// CHECK-MS: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @"??_U@YAPEAX_KW4align_val_t@std@@@Z"(i64 noundef %{{.*}}, i64 allocalign noundef 32)
 // No array cookie.
 // CHECK-MS-NOT: store
 // CHECK-MS: invoke noundef %struct.A* @"??0A@@QEAA@XZ"(
@@ -84,7 +84,7 @@
 void *b0() { return new B; }
 
 // CHECK-LABEL: define {{.*}} @_Z2b1l(
-// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnamSt11align_val_t(i64 noundef %{{.*}}, i64 noundef 32)
+// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 32 i8* @_ZnamSt11align_val_t(i64 noundef %{{.*}}, i64 allocalign noundef 32)
 // No array cookie.
 // CHECK-NOT: store
 // CHECK: invoke void @_ZN1BC1Ev(
@@ -169,7 +169,7 @@
 
 #ifndef UNALIGNED
 // CHECK-LABEL: define {{.*}} @_Z2e0v(
-// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 4 i8* @_ZnwmSt11align_val_t(i64 noundef 512, i64 noundef 4)
+// CHECK: %[[ALLOC:.*]] = call noalias noundef nonnull align 4 i8* @_ZnwmSt11align_val_t(i64 noundef 512, i64 allocalign noundef 4)
 // CHECK: call void @_ZdlPvSt11align_val_t(i8* noundef %[[ALLOC]], i64 noundef 4)
 void *e0() { return new (std::align_val_t(4)) A; }
 
Index: clang/test/CodeGenCXX/builtin-operator-new-delete.cpp
===
--- clang/test/CodeGenCXX/builtin-operator-new-delete.cpp
+++ clang/test/CodeGenCXX/builtin-operator-new-delete.cpp
@@ -47,7 +47,7 @@
 
 // CHECK-LABEL: define{{.*}} void @test_aligned_alloc(
 extern "C" void test_aligned_alloc() {
-  // CHECK: call noalias noundef nonnull align 4 i8* @_ZnwmSt11align_val_t(i64 noundef 4, i64 noundef 4) [[ATTR_BUILTIN_NEW:#[^ ]*]]
+  // CHECK: call noalias noundef nonnull align 4 i8* @_ZnwmSt11align_val_t(i64 noundef 4, i64 allocalign noundef 4) [[ATTR_BUILTIN_NEW:#[^ ]*]]
   // CHECK: call void @_ZdlPvSt11align_val_t({{.*}}, i64 noundef 4) [[ATTR_BUILTIN_DELETE:#[^ ]*]]
   __builtin_operator_delete(__builtin_operator_new(4, std::align_val_t(4)), std::align_val_t(4));
 }
Index: clang/test/CodeGen/non-power-of-2-alignment-assumptions.c
===
--- clang/test/CodeGen/non-power-of-2-alignment-assumptions.c
+++ clang/test/CodeGen/non-power-of-2-alignment-assumptions.c
@@ -8,7 +8,7 @@
 // CHECK-NEXT:[[ALIGN_ADDR:%.*]] = alloca i32, align 4
 // CHECK-NEXT:store 

[PATCH] D120416: [clangd] Function return type hints: support lambdas, don't duplicate "->"

2022-02-23 Thread Trass3r via Phabricator via cfe-commits
Trass3r added inline comments.



Comment at: clang-tools-extra/clangd/unittests/InlayHintTests.cpp:626
+auto f4() -> auto* { return "foo"; }
+
 // `auto` conversion operator

Should there be a test for `void` too or does it just work?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120416

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


[PATCH] D120361: [clang-format] Extract doc for entire configuration structs

2022-02-23 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

Seems to be correct, but I have not enough knowledge about the python or rst 
stuff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120361

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


[PATCH] D120391: [Driver] Add -fno-sanitize-address-globals-dead-stripping

2022-02-23 Thread Fangrui Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe87c32e390bb: [Driver] Add 
-fno-sanitize-address-globals-dead-stripping (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120391

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/fsanitize.c


Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -242,6 +242,7 @@
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-NO-ASAN-GLOBALS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-address-globals-dead-stripping 
-fno-sanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address 
-fsanitize-address-globals-dead-stripping -### -- %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address -### -- %s 
2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-scei-ps4  -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -848,10 +848,11 @@
 // As a workaround for a bug in gold 2.26 and earlier, dead stripping of
 // globals in ASan is disabled by default on ELF targets.
 // See https://sourceware.org/bugzilla/show_bug.cgi?id=19002
-AsanGlobalsDeadStripping =
+AsanGlobalsDeadStripping = Args.hasFlag(
+options::OPT_fsanitize_address_globals_dead_stripping,
+options::OPT_fno_sanitize_address_globals_dead_stripping,
 !TC.getTriple().isOSBinFormatELF() || TC.getTriple().isOSFuchsia() ||
-TC.getTriple().isPS4() ||
-Args.hasArg(options::OPT_fsanitize_address_globals_dead_stripping);
+TC.getTriple().isPS4());
 
 AsanUseOdrIndicator =
 Args.hasFlag(options::OPT_fsanitize_address_use_odr_indicator,
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1662,9 +1662,11 @@
   PosFlag, NegFlag,
   BothFlags<[], " poisoning array cookies when using custom operator new[] in 
AddressSanitizer">>,
   Group;
-def fsanitize_address_globals_dead_stripping : Flag<["-"], 
"fsanitize-address-globals-dead-stripping">,
-  Group, HelpText<"Enable linker dead stripping of globals in 
AddressSanitizer">,
-  MarshallingInfoFlag, 
"false">;
+defm sanitize_address_globals_dead_stripping : BoolOption<"f", 
"sanitize-address-globals-dead-stripping",
+  CodeGenOpts<"SanitizeAddressGlobalsDeadStripping">, DefaultFalse,
+  PosFlag,
+  NegFlag>,
+  Group;
 defm sanitize_address_use_odr_indicator : BoolOption<"f", 
"sanitize-address-use-odr-indicator",
   CodeGenOpts<"SanitizeAddressUseOdrIndicator">, DefaultFalse,
   PosFlagIndex: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -242,6 +242,7 @@
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ASAN-GLOBALS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-globals-dead-stripping -fno-sanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address -fsanitize-address-globals-dead-stripping -### -- %s 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address -### -- %s 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-scei-ps4  -fsanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -848,10 +848,11 @@
 // As a workaround for a bug in gold 2.26 and earlier, dead stripping of
 // globals in ASan is 

[clang] e87c32e - [Driver] Add -fno-sanitize-address-globals-dead-stripping

2022-02-23 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2022-02-23T11:51:30-08:00
New Revision: e87c32e390bb812d9390d3df39357409d073ac3f

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

LOG: [Driver] Add -fno-sanitize-address-globals-dead-stripping

It's customary for these options to have the -fno- form which is sometimes
handy to work around issues. Using the supported driver option is preferred over
the internal cl::opt option `-mllvm -asan-globals-live-support=0`

Reviewed By: kstoimenov, vitalybuka

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/SanitizerArgs.cpp
clang/test/Driver/fsanitize.c

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index c377329e8f6f4..fcee066905703 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1662,9 +1662,11 @@ defm sanitize_address_poison_custom_array_cookie : 
BoolOption<"f", "sanitize-add
   PosFlag, NegFlag,
   BothFlags<[], " poisoning array cookies when using custom operator new[] in 
AddressSanitizer">>,
   Group;
-def fsanitize_address_globals_dead_stripping : Flag<["-"], 
"fsanitize-address-globals-dead-stripping">,
-  Group, HelpText<"Enable linker dead stripping of globals in 
AddressSanitizer">,
-  MarshallingInfoFlag, 
"false">;
+defm sanitize_address_globals_dead_stripping : BoolOption<"f", 
"sanitize-address-globals-dead-stripping",
+  CodeGenOpts<"SanitizeAddressGlobalsDeadStripping">, DefaultFalse,
+  PosFlag,
+  NegFlag>,
+  Group;
 defm sanitize_address_use_odr_indicator : BoolOption<"f", 
"sanitize-address-use-odr-indicator",
   CodeGenOpts<"SanitizeAddressUseOdrIndicator">, DefaultFalse,
   PosFlaghttps://sourceware.org/bugzilla/show_bug.cgi?id=19002
-AsanGlobalsDeadStripping =
+AsanGlobalsDeadStripping = Args.hasFlag(
+options::OPT_fsanitize_address_globals_dead_stripping,
+options::OPT_fno_sanitize_address_globals_dead_stripping,
 !TC.getTriple().isOSBinFormatELF() || TC.getTriple().isOSFuchsia() ||
-TC.getTriple().isPS4() ||
-Args.hasArg(options::OPT_fsanitize_address_globals_dead_stripping);
+TC.getTriple().isPS4());
 
 AsanUseOdrIndicator =
 Args.hasFlag(options::OPT_fsanitize_address_use_odr_indicator,

diff  --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index 7bcda5c33dc9e..c61726aaa3115 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -242,6 +242,7 @@
 
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-NO-ASAN-GLOBALS
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fsanitize-address-globals-dead-stripping 
-fno-sanitize-address-globals-dead-stripping %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-NO-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address 
-fsanitize-address-globals-dead-stripping -### -- %s 2>&1 | FileCheck %s 
--check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang_cl --target=x86_64-windows-msvc -fsanitize=address -### -- %s 
2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS
 // RUN: %clang -target x86_64-scei-ps4  -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN-GLOBALS



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


[PATCH] D120416: [clangd] Function return type hints: support lambdas, don't duplicate "->"

2022-02-23 Thread Nathan Ridge via Phabricator via cfe-commits
nridge accepted this revision.
nridge added a comment.
This revision is now accepted and ready to land.

Nice!




Comment at: clang-tools-extra/clangd/unittests/InlayHintTests.cpp:539
+  // Lambda return hint shown even if no param list.
+  assertTypeHints("auto $L[[x]] = <:$ret[[:>]]{return 42;};",
+  ExpectedHint{": (lambda)", "L"},

Maybe add a comment like "use digraphs to place a literal `]` in an annotation 
range"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120416

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


[PATCH] D120359: [clang-format][NFC] Remove redundant semi

2022-02-23 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

In D120359#3339638 , @curdeius wrote:

> I don't really understand this change. You say in the description that you 
> remove the semicolon, but you actually add it.
> Also, it's a common pattern not to add a semicolon and make all macro calls 
> look like a normal statement (with a semi at the call place).
> I'm not opposed but I don't see a reason for changing this.

Just a messed up git diff command. I had some unstaged and uncommited changes 
in the same file. It's the other way around. I will update the diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120359

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


[PATCH] D120360: [libTooling] Generalize string explanation as Any metadata

2022-02-23 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

High level question: why use `Any` rather than templating?




Comment at: clang/include/clang/Tooling/Transformer/RewriteRule.h:68
 
+using AnyGenerator2 = std::shared_ptr>;
+

li.zhe.hua wrote:
> Placeholder name; suggestions welcome.
hmm. How about MetadataGenerator? Less general, but to the point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120360

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


[PATCH] D118196: [syntax][pseudo] Implement LR parsing table.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Hi, this commit is causing runtime failures on Windows in debug builds. Can you 
please correct or revert? Thanks!




Comment at: clang/lib/Tooling/Syntax/Pseudo/LRTable.cpp:119
+++End;
+  return llvm::makeArrayRef([Start], [End]);
+}

This is causing an assertion with debug builds on Windows because 
`Actions[End]` is out of bounds (so the MSVC STL debug assertions catch the 
issue) for the test cases in this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118196

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


[PATCH] D120258: [clangd] Add inlay hints for auto-typed parameters with one instantiation.

2022-02-23 Thread Nathan Ridge via Phabricator via cfe-commits
nridge accepted this revision.
nridge 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/D120258/new/

https://reviews.llvm.org/D120258

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


[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Mostly small nits, but it looks like precommit CI is failing due to the changes:

  Failed Tests (2):
Clang Tools :: clang-tidy/checkers/bugprone-signal-handler-minimal.c
Clang Tools :: clang-tidy/checkers/bugprone-signal-handler-posix.c




Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:149
+// No need to show a call chain.
+// Without code body there is no more thing to check.
 return;





Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:173
+   const Expr *CallOrRef) {
+  const bool FunctionIsCalled = isa(CallOrRef);
+





Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:188
+  if (!FD->hasBody()) {
+diag(CallOrRef->getBeginLoc(), "can not verify if external function %0 is "
+   "asynchronous-safe; "





Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h:46
+  bool checkFunction(const FunctionDecl *FD, const Expr *CallOrRef);
+  /// Return if a system call function is considered as asynchronous-safe.
   bool isSystemCallAsyncSafe(const FunctionDecl *FD) const;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

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


[PATCH] D120289: [clang][dataflow] Add SAT solver interface and implementation

2022-02-23 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev added a comment.

In D120289#3338262 , @xazax.hun wrote:

> In D120289#3338244 , @sgatev wrote:
>
>>> I wonder if it would make sense to have a SAT base class for the SMT API 
>>> and reuse that here?
>>
>> I think that on a high level we can either 1) integrate the SMT API types 
>> deeply into the dataflow framework and use that solver interface directly or 
>> 2) have a layer that translates from the dataflow `BoolValue` types to the 
>> SMT API types. At this point I'm not convinced that we should go for 1).
>
> Could you elaborate on what would be the main disadvantage of using 1)? (The 
> advantage would be that we could very easily switch to Z3 any time.)

Let me clarify 1) because I see two options there as well:

1.a) We replace the `BoolValue` hierarchy in the dataflow framework with 
`SMTExprRef`.
This feels too committal. The dataflow interfaces are still not sufficiently 
developed and there isn't a clear benefit (e.g. performance) with this approach 
so I'd rather not couple them for now. There might also be benefits to having a 
structured representation (as opposed to using opaque values such as 
`SMTExprRef`) that we need to consider. I think this is a viable long-term 
option, though.

1.b) We add an `SMTExprRef` member to each boolean value (atom, conjunction, 
disjunction, and negation) in the dataflow framework.
I like this better than 1.a). The main disadvantage I see is that `SMTSolver` 
is a huge interface and on the surface it seems tailored to the Z3 API. From 
that perspective it also feels more committal than necessary, given that we can 
make do with a simple one-method interface for now. I think this is a good 
long-term option if we think the SMT API is the most appropriate solver 
interface.

I find 2) least committal as it keeps the dataflow framework and the solver 
separate. For a simple integration with Z3 I can provide an implementation of 
`clang::dataflow::Solver` using the SMT API. That should boil down to 
translating dataflow types to SMT types.

What do you think about this? Any other options we should consider?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120289

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


[PATCH] D120394: [asan] Allow -fsanitize-address-globals-dead-stripping with -fno-data-sections for ELF

2022-02-23 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov accepted this revision.
kstoimenov added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120394

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


[PATCH] D120395: [X86] Prohibit arithmatic operations on type `__bfloat16`

2022-02-23 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

In D120395#3340891 , @andrew.w.kaylor 
wrote:

> In D120395#3340496 , @pengfei wrote:
>
>> Update LangRef. We use `i16` type to represent bfloat16.
>
> Why are we using i16 to represent bfloat16? The bfloat type is better.

These intrinsics pre-date the existence of the bfloat type in LLVM. To use 
bfloat we have to make __bf16 a legal type in C. This means we need to support 
loads, stores, and arguments of that type. I think that would create bunch of 
backend complexity because we don't have could 16-bit load/store support to XMM 
registers. I think we only have load that inserts into a specific element. It's 
doable, but I'm not sure what we gain from it.




Comment at: clang/lib/Headers/avx512bf16intrin.h:22
+///format type. Define through structure to explicitly prohibit any
+///arithmatic operations.
+typedef struct __bfloat16_s {

arithmatic -> arithmetic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120395

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


[PATCH] D120372: [clang] 'unused-but-set-variable' warning should not apply to __attribute__((objc_precise_lifetime) Objective-C pointers

2022-02-23 Thread Michael Wyman via Phabricator via cfe-commits
mwyman updated this revision to Diff 410863.
mwyman added a comment.

Added new inner scope for test file.


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

https://reviews.llvm.org/D120372

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaObjC/objc-precise-lifetime-unused-variable.m


Index: clang/test/SemaObjC/objc-precise-lifetime-unused-variable.m
===
--- /dev/null
+++ clang/test/SemaObjC/objc-precise-lifetime-unused-variable.m
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos11 -fsyntax-only -fobjc-arc 
-fblocks -verify -Wunused-but-set-variable -Wno-objc-root-class %s
+
+id getFoo(void);
+
+void test() {
+  // no diagnostics for objects with precise lifetime semantics.
+  __attribute__((objc_precise_lifetime)) id x;
+  x = getFoo();
+
+  id x2; // expected-warning {{variable 'x2' set but not used}}
+  x2 = getFoo();
+
+  do {
+__attribute__((objc_precise_lifetime)) id y;
+y = getFoo();
+
+id y2; // expected-warning {{variable 'y2' set but not used}}
+y2 = getFoo();
+  } while(0);
+
+  x = ((void *)0);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -2008,6 +2008,12 @@
   if (VD->hasAttr() && Ty->isObjCObjectPointerType())
 return;
 
+  // Don't warn about Objective-C pointer variables with precise lifetime
+  // semantics; they can be used to ensure ARC releases the object at a known
+  // time, which may mean assignment but no other references.
+  if (VD->hasAttr() && Ty->isObjCObjectPointerType())
+return;
+
   auto iter = RefsMinusAssignments.find(VD);
   if (iter == RefsMinusAssignments.end())
 return;


Index: clang/test/SemaObjC/objc-precise-lifetime-unused-variable.m
===
--- /dev/null
+++ clang/test/SemaObjC/objc-precise-lifetime-unused-variable.m
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macos11 -fsyntax-only -fobjc-arc -fblocks -verify -Wunused-but-set-variable -Wno-objc-root-class %s
+
+id getFoo(void);
+
+void test() {
+  // no diagnostics for objects with precise lifetime semantics.
+  __attribute__((objc_precise_lifetime)) id x;
+  x = getFoo();
+
+  id x2; // expected-warning {{variable 'x2' set but not used}}
+  x2 = getFoo();
+
+  do {
+__attribute__((objc_precise_lifetime)) id y;
+y = getFoo();
+
+id y2; // expected-warning {{variable 'y2' set but not used}}
+y2 = getFoo();
+  } while(0);
+
+  x = ((void *)0);
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -2008,6 +2008,12 @@
   if (VD->hasAttr() && Ty->isObjCObjectPointerType())
 return;
 
+  // Don't warn about Objective-C pointer variables with precise lifetime
+  // semantics; they can be used to ensure ARC releases the object at a known
+  // time, which may mean assignment but no other references.
+  if (VD->hasAttr() && Ty->isObjCObjectPointerType())
+return;
+
   auto iter = RefsMinusAssignments.find(VD);
   if (iter == RefsMinusAssignments.end())
 return;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120395: [X86] Prohibit arithmatic operations on type `__bfloat16`

2022-02-23 Thread Andy Kaylor via Phabricator via cfe-commits
andrew.w.kaylor added a comment.

In D120395#3340496 , @pengfei wrote:

> Update LangRef. We use `i16` type to represent bfloat16.

Why are we using i16 to represent bfloat16? The bfloat type is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120395

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


[PATCH] D119061: [Clang] noinline call site attribute

2022-02-23 Thread Jakub Kuderski via Phabricator via cfe-commits
kuhar accepted this revision.
kuhar added a comment.
This revision is now accepted and ready to land.

LGTM put please get at least one additional approval before submitting


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

https://reviews.llvm.org/D119061

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


[PATCH] D113393: [c++2b] Implement P0849R8 auto(x)

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I spotted some test coverage that I think we should add:

  static_cast(whatever);
  reinterpret_cast(whatever);
  const_cast(whatever);
  dynamic_cast(whatever);
  (auto)whatever;

I believe all of those should be rejected because of 
https://eel.is/c++draft/dcl.spec.auto#general-5.sentence-2.

Are there changes needed for the AST printer for this new form of cast notation?

I suppose one other question worth asking: if we're allowing 
`decltype(auto)(whatever)` as a Clang extension, should we be accepting 
`__typeof__(auto)(whatever)` as well?




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2396
+def ext_decltype_auto_expr : ExtWarn<
+  "ISO C++23 DIS does not allow functional-style cast to 'decltype(auto)'">,
+  InGroup>;

lichray wrote:
> aaron.ballman wrote:
> > Is there a reason this one should be `ExtWarn` instead of `Extension`? (I 
> > think we typically only issue this kind of diagnostic when `-pedantic` is 
> > specified.)
> I took a look at other warnings. It seems that Clang believes that a portable 
> program can contain `Extension`s; if `ExtWarn` is issued, the program is not 
> likely to be portable.
> 
> I asked GCC folks yesterday to see if they want to implement this extension, 
> and they are not interested. So I guess `ExtWarn` is suitable for now.
Thanks! I think `ExtWarn` is fine based on that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113393

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


[PATCH] D109239: Add support for floating-option `-ffp-eval-method` and for new `pragma clang fp eval-method`

2022-02-23 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

@fhahn I think the last commit fixes the issue. I am currently testing it on 
MacOS  10.14 and it is still going (slow remote machine). I would like to get 
your permission to push this patch now. It will probably be faster to confirm 
that the patch fixes the issue running your buildbot?


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

https://reviews.llvm.org/D109239

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D120353#3340863 , @JonChesterfield 
wrote:

> Thanks! Seems a good thing to add to the offloading test runner, preferably 
> in a separate change to avoid reverting this in case of unforeseen problems

Could definitely do that, it doesn't seem like we test `if` anywhere in the 
OpenMP tests so it shouldn't break anything.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Thanks! Seems a good thing to add to the offloading test runner, preferably in 
a separate change to avoid reverting this in case of unforeseen problems


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


[PATCH] D120391: [Driver] Add -fno-sanitize-address-globals-dead-stripping

2022-02-23 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov accepted this revision.
kstoimenov added a comment.
This revision is now accepted and ready to land.

LGTM. But please wait for LTGM from vitalybuka@. Also there is internal 
asan-globals-live-support flag if you need it before this one lands.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120391

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


[PATCH] D119479: [clang][extract-api] Add global record support

2022-02-23 Thread Zixu Wang via Phabricator via cfe-commits
zixuw added a comment.

In D119479#3339220 , @MaskRay wrote:

> There is a circular dependency if you use `-DBUILD_SHARED_LIBS=on`:
>
>   CMake Error: The inter-target dependency graph contains the following 
> strongly connected component (cycle):
> "clangFrontend" of type SHARED_LIBRARY
>   depends on "clangIndex" (weak)
> "clangIndex" of type SHARED_LIBRARY
>   depends on "clangFrontend" (weak)
>   At least one of these targets is not a STATIC_LIBRARY.  Cyclic dependencies 
> are allowed only among static libraries.
>   CMake Generate step failed.  Build files cannot be regenerated correctly.
>   FAILED: build.ninja

Huh I pulled in clangIndex to generate USRs, but didn't try building shared 
libs. I'll see what I can do.
Good find! Thanks for taking a look!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119479

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


[PATCH] D120258: [clangd] Add inlay hints for auto-typed parameters with one instantiation.

2022-02-23 Thread Trass3r via Phabricator via cfe-commits
Trass3r added a comment.

In D120258#3340717 , @sammccall wrote:

> (I think this patch is good to go now, ready for a stamp if anyone agrees 
> :-)).

I agree. There's still D120258#3336114 
 but I don't have the time to reduce 
it atm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120258

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


[PATCH] D119361: [clang] Rename missing-declarations to useless-declarations

2022-02-23 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: rsmith, rjmccall, jyknight.
aaron.ballman added a subscriber: cfe-commits.
aaron.ballman added a comment.

Thank you for this, but I'd like to get a better understanding of the long-term 
goals here (and where we diverge from GCC in terms of some code examples). 
Also, this should probably be mentioned in the release notes somewhere so that 
people know what to expect about the changes.

(Adding a few more reviewers for visibility since this is touching an existing 
diagnostic group. Also, subscribing the mailing lists.)


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

https://reviews.llvm.org/D119361

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


[clang] 6eec483 - [clang] Remove getPointerElementType() in EmitVTableTypeCheckedLoad()

2022-02-23 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2022-02-23T09:38:33-08:00
New Revision: 6eec4835844439ab932515ff4ac857773c639171

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

LOG: [clang] Remove getPointerElementType() in EmitVTableTypeCheckedLoad()

Added: 


Modified: 
clang/lib/CodeGen/CGClass.cpp
clang/lib/CodeGen/CodeGenFunction.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/CodeGen/MicrosoftCXXABI.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGClass.cpp b/clang/lib/CodeGen/CGClass.cpp
index f6cacd07a66f2..9a175d1f59d2b 100644
--- a/clang/lib/CodeGen/CGClass.cpp
+++ b/clang/lib/CodeGen/CGClass.cpp
@@ -2829,7 +2829,8 @@ bool 
CodeGenFunction::ShouldEmitVTableTypeCheckedLoad(const CXXRecordDecl *RD) {
 }
 
 llvm::Value *CodeGenFunction::EmitVTableTypeCheckedLoad(
-const CXXRecordDecl *RD, llvm::Value *VTable, uint64_t VTableByteOffset) {
+const CXXRecordDecl *RD, llvm::Value *VTable, llvm::Type *VTableTy,
+uint64_t VTableByteOffset) {
   SanitizerScope SanScope(this);
 
   EmitSanitizerStatReport(llvm::SanStat_CFI_VCall);
@@ -2854,7 +2855,7 @@ llvm::Value *CodeGenFunction::EmitVTableTypeCheckedLoad(
   }
 
   return Builder.CreateBitCast(Builder.CreateExtractValue(CheckedLoad, 0),
-   VTable->getType()->getPointerElementType());
+   VTableTy);
 }
 
 void CodeGenFunction::EmitForwardingCallToLambda(

diff  --git a/clang/lib/CodeGen/CodeGenFunction.h 
b/clang/lib/CodeGen/CodeGenFunction.h
index df99cd9a1b790..f9932e4140813 100644
--- a/clang/lib/CodeGen/CodeGenFunction.h
+++ b/clang/lib/CodeGen/CodeGenFunction.h
@@ -2322,7 +2322,9 @@ class CodeGenFunction : public CodeGenTypeCache {
   bool ShouldEmitVTableTypeCheckedLoad(const CXXRecordDecl *RD);
 
   /// Emit a type checked load from the given vtable.
-  llvm::Value *EmitVTableTypeCheckedLoad(const CXXRecordDecl *RD, llvm::Value 
*VTable,
+  llvm::Value *EmitVTableTypeCheckedLoad(const CXXRecordDecl *RD,
+ llvm::Value *VTable,
+ llvm::Type *VTableTy,
  uint64_t VTableByteOffset);
 
   /// EnterDtorCleanups - Enter the cleanups necessary to complete the

diff  --git a/clang/lib/CodeGen/ItaniumCXXABI.cpp 
b/clang/lib/CodeGen/ItaniumCXXABI.cpp
index 5ec9d3289ee8b..c2213c6e0df37 100644
--- a/clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ b/clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -1925,7 +1925,7 @@ CGCallee 
ItaniumCXXABI::getVirtualFunctionPointer(CodeGenFunction ,
   llvm::Value *VFunc;
   if (CGF.ShouldEmitVTableTypeCheckedLoad(MethodDecl->getParent())) {
 VFunc = CGF.EmitVTableTypeCheckedLoad(
-MethodDecl->getParent(), VTable,
+MethodDecl->getParent(), VTable, TyPtr,
 VTableIndex * CGM.getContext().getTargetInfo().getPointerWidth(0) / 8);
   } else {
 CGF.EmitTypeMetadataCodeForVCall(MethodDecl->getParent(), VTable, Loc);

diff  --git a/clang/lib/CodeGen/MicrosoftCXXABI.cpp 
b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
index c1156d643e82d..14912c3a415a3 100644
--- a/clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ b/clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -1947,7 +1947,7 @@ CGCallee 
MicrosoftCXXABI::getVirtualFunctionPointer(CodeGenFunction ,
   llvm::Value *VFunc;
   if (CGF.ShouldEmitVTableTypeCheckedLoad(MethodDecl->getParent())) {
 VFunc = CGF.EmitVTableTypeCheckedLoad(
-getObjectWithVPtr(), VTable,
+getObjectWithVPtr(), VTable, Ty,
 ML.Index * CGM.getContext().getTargetInfo().getPointerWidth(0) / 8);
   } else {
 if (CGM.getCodeGenOpts().PrepareForLTO)



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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D120353#3340775 , @ABataev wrote:

> I assume it would be good to notify the user somehow about target regions, 
> which may require execution on the host. Maybe add a note during the codegen 
> phase?

Technically all of them may require execution on the host according to the 
documentation. We could emit a warning whenever we codegen a target region with 
an `if` clause, but I feel the user should have a good enough idea that `if` 
won't work if they specifically turn on the flag that removes host execution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

I assume it would be good to notify the user somehow about target regions, 
which may require execution on the host. Maybe add a note during the codegen 
phase?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


[PATCH] D120255: [Concepts] Check constraints for explicit template instantiations

2022-02-23 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Please add all the context (see https://llvm.org/docs/Phabricator.html).  Also, 
I'd like to see some level of negative tests.

Finally, I'll have to evaluate how this works with the delayed concepts build.

I don't see this as making it into Clang-14, we are pretty close to release, 
and I'm unsure of how it'll interact with other stuff just yet.


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

https://reviews.llvm.org/D120255

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 410851.
jhuber6 added a comment.

Adding test function with device clause


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/target_offload_mandatory_codegen.cpp

Index: clang/test/OpenMP/target_offload_mandatory_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_offload_mandatory_codegen.cpp
@@ -0,0 +1,90 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --include-generated-funcs --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+"
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -fopenmp-offload-mandatory -emit-llvm %s -o - | FileCheck %s --check-prefix=MANDATORY
+// expected-no-diagnostics
+
+void foo() {}
+#pragma omp declare target(foo)
+
+void bar() {}
+#pragma omp declare target device_type(nohost) to(bar)
+
+void host() {
+#pragma omp target
+  { bar(); }
+}
+
+void host_if(bool cond) {
+#pragma omp target if(cond)
+  { bar(); }
+}
+
+void host_dev(int device) {
+#pragma omp target device(device)
+  { bar(); }
+}
+// MANDATORY-LABEL: define {{[^@]+}}@_Z3foov
+// MANDATORY-SAME: () #[[ATTR0:[0-9]+]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z4hostv
+// MANDATORY-SAME: () #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[TMP0:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1:[0-9]+]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z4hostv_l12.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP1:%.*]] = icmp ne i32 [[TMP0]], 0
+// MANDATORY-NEXT:br i1 [[TMP1]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z7host_ifb
+// MANDATORY-SAME: (i1 noundef zeroext [[COND:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[COND_ADDR:%.*]] = alloca i8, align 1
+// MANDATORY-NEXT:[[FROMBOOL:%.*]] = zext i1 [[COND]] to i8
+// MANDATORY-NEXT:store i8 [[FROMBOOL]], i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i8, i8* [[COND_ADDR]], align 1
+// MANDATORY-NEXT:[[TOBOOL:%.*]] = trunc i8 [[TMP0]] to i1
+// MANDATORY-NEXT:br i1 [[TOBOOL]], label [[OMP_IF_THEN:%.*]], label [[OMP_IF_ELSE:%.*]]
+// MANDATORY:   omp_if.then:
+// MANDATORY-NEXT:[[TMP1:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 -1, i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z7host_ifb_l17.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP2:%.*]] = icmp ne i32 [[TMP1]], 0
+// MANDATORY-NEXT:br i1 [[TMP2]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:br label [[OMP_IF_END:%.*]]
+// MANDATORY:   omp_if.else:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_if.end:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define {{[^@]+}}@_Z8host_devi
+// MANDATORY-SAME: (i32 noundef signext [[DEVICE:%.*]]) #[[ATTR0]] {
+// MANDATORY-NEXT:  entry:
+// MANDATORY-NEXT:[[DEVICE_ADDR:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:[[DOTCAPTURE_EXPR_:%.*]] = alloca i32, align 4
+// MANDATORY-NEXT:store i32 [[DEVICE]], i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:[[TMP0:%.*]] = load i32, i32* [[DEVICE_ADDR]], align 4
+// MANDATORY-NEXT:store i32 [[TMP0]], i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP1:%.*]] = load i32, i32* [[DOTCAPTURE_EXPR_]], align 4
+// MANDATORY-NEXT:[[TMP2:%.*]] = sext i32 [[TMP1]] to i64
+// MANDATORY-NEXT:[[TMP3:%.*]] = call i32 @__tgt_target_mapper(%struct.ident_t* @[[GLOB1]], i64 [[TMP2]], i8* @.{{__omp_offloading_[0-9a-z]+_[0-9a-z]+}}__Z8host_devi_l22.region_id, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i8** null)
+// MANDATORY-NEXT:[[TMP4:%.*]] = icmp ne i32 [[TMP3]], 0
+// MANDATORY-NEXT:br i1 [[TMP4]], label [[OMP_OFFLOAD_FAILED:%.*]], label [[OMP_OFFLOAD_CONT:%.*]]
+// MANDATORY:   omp_offload.failed:
+// MANDATORY-NEXT:unreachable
+// MANDATORY:   omp_offload.cont:
+// MANDATORY-NEXT:ret void
+//
+//
+// MANDATORY-LABEL: define 

[PATCH] D120262: [OpenCL] Handle TypeExtensions in OpenCLBuiltinFileEmitter

2022-02-23 Thread Pedro Olsen Ferreira via Phabricator via cfe-commits
arkangath added inline comments.



Comment at: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp:1183
+  SmallVector ExtVec;
+  TypeExt.split(ExtVec, " ");
+  for (const auto Ext : ExtVec) {

svenvh wrote:
> arkangath wrote:
> > Just in case if relevant, your "KeepEmpty" will default to true here.
> > I don't know if it is possible or not (not enough context for me), but 
> > could the .td file have "Extension0  Extention1" (two spaces) that could 
> > lead to one empty StringRef here?
> That would lead to generation of `#if defined(Extension0) && defined()`, 
> which would cause a compilation error.  I think that's not unreasonable 
> behavior to keep, to enforce that extensions are separated by exactly one 
> space in the .td file for the sake of consistency.
Ok, that's fine with me. I just wondered if it'd be easier to just set 
KeepEmpty=false on the split() call.


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

https://reviews.llvm.org/D120262

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


[PATCH] D120353: [OpenMP] Add option to make offloading mandatory

2022-02-23 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D120353#3340749 , @jhuber6 wrote:

> In D120353#3340744 , @ABataev wrote:
>
>> Could you add a test with the device clause too?
>
> Which clause exactly?

`device(device_id)`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120353

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


  1   2   3   >