[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

[Jonathan Wakely via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

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

[PATCH] D97340: [HIP] Support Spack packages

[Harmen Stoppels via Phabricator via cfe-commits]

haampie added a comment.
Herald added a subscriber: ormris.

Hi @tra and @yaxunl, I'm commenting as a reviewer of the spack pull request for 
the rocm 4.2.0 ecosystem. First of all: thanks for caring about spack 
installations, that's highly appreciated.

However, this patch does not seem the right approach to me, for a couple 
reasons:

1. LLVM should not be aware of spack -- it doesn't make sense. Spack doesn't 
even have a stable 1.0 release, expect it to break and inconsistent between 
versions.
2. It's incorrect in multiple ways: (a) the directory structure name is 
configurable in spack, not everybody has this -- 
structure, so you shouldn't rely on it, (b) you are still not guaranteed to 
pick up the correct llvm-amdgpu because it may be installed in a chained repo 
on a shared HPC system, and it won't be in the same prefix folder at all (c) 
spack's main selling point is it supports multiple installs of one package (a 
hash also changes for the same llvm version if a downstream dep such as zlib is 
updated), this patch just bails when it detect multiple installations

Let's step back a bit. The problem you seem to be solving is the circular 
dependency between llvm and rocm-device-libs which are separate packages in 
spack; clang can't know where rocm-device-libs is at compile time because 
rocm-device-libs depends on llvm.

Clearly the solution is to build llvm together with rocm-device-libs, as 
explained in the readme of 
https://github.com/RadeonOpenCompute/ROCm-Device-Libs, we can fix that in spack 
by adding a `resource` in the llvm package to pull in more sources, and LLVM 
can happily live without knowing about spack.

Thanks,

Harmen


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97340

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

[Michael Benfield via Phabricator via cfe-commits]

mbenfield updated this revision to Diff 347111.
mbenfield added a comment.

Move fixes into a separate change https://reviews.llvm.org/D102942.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
  clang/test/CodeGen/2007-10-30-Volatile.c
  clang/test/CodeGen/X86/x86_32-xsave.c
  clang/test/CodeGen/X86/x86_64-xsave.c
  clang/test/CodeGen/builtins-arm.c
  clang/test/CodeGen/builtins-riscv.c
  clang/test/FixIt/fixit.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/shift.c
  clang/test/Sema/vector-gcc-compat.c
  clang/test/Sema/vector-gcc-compat.cpp
  clang/test/Sema/warn-unused-but-set-parameters.c
  clang/test/Sema/warn-unused-but-set-variables.c
  clang/test/SemaCXX/goto.cpp
  clang/test/SemaCXX/shift.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
  clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
  clang/test/SemaObjC/foreach.m

Index: clang/test/SemaObjC/foreach.m
===
--- clang/test/SemaObjC/foreach.m
+++ clang/test/SemaObjC/foreach.m
@@ -1,4 +1,4 @@
-/* RUN: %clang_cc1 -Wall -fsyntax-only -verify -std=c89 -pedantic %s
+/* RUN: %clang_cc1 -Wall -Wno-unused-but-set-variable -fsyntax-only -verify -std=c89 -pedantic %s
  */
 
 @class NSArray;
Index: clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -fblocks -fsyntax-only -Wunused-but-set-variable -verify %s
+
+struct S {
+  int i;
+};
+
+struct __attribute__((warn_unused)) SWarnUnused {
+  int j;
+};
+
+int f0() {
+  int y; // expected-warning{{variable 'y' set but not used}}
+  y = 0;
+
+  int z __attribute__((unused));
+  z = 0;
+
+  // In C++, don't warn for structs. (following gcc's behavior)
+  struct S s;
+  struct S t;
+  s = t;
+
+  // Unless it's marked with the warn_unused attribute.
+  struct SWarnUnused swu; // expected-warning{{variable 'swu' set but not used}}
+  struct SWarnUnused swu2;
+  swu = swu2;
+
+  int x;
+  x = 0;
+  return x + 5;
+}
+
+void f1(void) {
+  (void)^() {
+int y; // expected-warning{{variable 'y' set but not used}}
+y = 0;
+
+int x;
+x = 0;
+return x;
+  };
+}
+
+void f2() {
+  // Don't warn for either of these cases.
+  constexpr int x = 2;
+  const int y = 1;
+  char a[x];
+  char b[y];
+}
Index: clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
@@ -0,0 +1,38 @@
+// RUN: %clang_cc1 -fblocks -fsyntax-only -Wunused-but-set-parameter -verify %s
+
+int f0(int x,
+   int y, // expected-warning{{parameter 'y' set but not used}}
+   int z __attribute__((unused))) {
+  y = 0;
+  return x;
+}
+
+void f1(void) {
+  (void)^(int x,
+  int y, // expected-warning{{parameter 'y' set but not used}}
+  int z __attribute__((unused))) {
+y = 0;
+return x;
+  };
+}
+
+struct S {
+  int i;
+};
+
+// In C++, don't warn for a struct (following gcc).
+void f3(struct S s) {
+  struct S t;
+  s = t;
+}
+
+// Also don't warn for a reference.
+void f4(int &x) {
+  x = 0;
+}
+
+// Make sure this doesn't warn.
+struct A {
+  int i;
+  A(int j) : i(j) {}
+};
Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=gnu++17 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unu

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added a comment.

If gracefully lowering rvalue references to references needs knowledge about 
the Clang typesystem (or depends on LLVM IR type uniquing to be efficient, as 
@dblaikie points out) then we should do it in the Clang frontend. As much as we 
can we should avoid encoding debug info format specific knowledge in the Clang 
frontend, but that's not always possible. I'm fine with taking this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

[David Blaikie via Phabricator via cfe-commits]

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

In D100630#2775207 , @aprantl wrote:

> If gracefully lowering rvalue references to references needs knowledge about 
> the Clang typesystem (or depends on LLVM IR type uniquing to be efficient, as 
> @dblaikie points out) then we should do it in the Clang frontend. As much as 
> we can we should avoid encoding debug info format specific knowledge in the 
> Clang frontend, but that's not always possible. I'm fine with taking this 
> patch.

Fair enough then - thanks for chiming in!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D102906: [clang-tidy] Remark was added to clang tooling Diagnostic

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from the nit from @DmitryPolukhin




Comment at: clang/include/clang/Tooling/Core/Diagnostic.h:72
+Error = DiagnosticsEngine::Error,
+Remark = DiagnosticsEngine::Remark
   };

DmitryPolukhin wrote:
> nit, I would move remark first to have list by increasing severity. It looks 
> like this enum values is not used outside of the sources so I hope it is safe.
We have diagnostic notes as well and it's not clear to me how to order remark 
and note should we go that way in the future. So I'm not opposed to the 
suggestion, but the order likely doesn't matter all that much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102906

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

[clang] bf61245 - [HIP] support ThinLTO

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-05-22T10:48:34-04:00
New Revision: bf6124580dfba86b73d828851f03fb9eea1269bd

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

LOG: [HIP] support ThinLTO

Add options -[no-]offload-lto and -foffload-lto=[thin,full] for controlling
LTO for offload compilation. Allow LTO for AMDGPU target.

AMDGPU target does not support codegen of object files containing
call of external functions, therefore the LLVM module passed to
AMDGPU backend needs to contain definitions of all the callees.
An LLVM option is added to allow function importer to import
functions with noinline attribute.

HIP toolchain passes proper LLVM options to lld to make sure
function importer imports definitions of all the callees.

Reviewed by: Teresa Johnson, Artem Belevich

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

Added: 
llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
llvm/test/Transforms/FunctionImport/noinline.ll

Modified: 
clang/include/clang/Driver/Driver.h
clang/include/clang/Driver/Options.td
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/HIP.cpp
clang/test/Driver/hip-options.hip
llvm/lib/Transforms/IPO/FunctionImport.cpp
llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
llvm/test/Transforms/FunctionImport/funcimport.ll

Removed: 




diff  --git a/clang/include/clang/Driver/Driver.h 
b/clang/include/clang/Driver/Driver.h
index 469c000c952ca..85810f0b568b6 100644
--- a/clang/include/clang/Driver/Driver.h
+++ b/clang/include/clang/Driver/Driver.h
@@ -84,6 +84,9 @@ class Driver {
   /// LTO mode selected via -f(no-)?lto(=.*)? options.
   LTOKind LTOMode;
 
+  /// LTO mode selected via -f(no-offload-)?lto(=.*)? options.
+  LTOKind OffloadLTOMode;
+
 public:
   enum OpenMPRuntimeKind {
 /// An unknown OpenMP runtime. We can't generate effective OpenMP code
@@ -559,10 +562,14 @@ class Driver {
   bool ShouldEmitStaticLibrary(const llvm::opt::ArgList &Args) const;
 
   /// Returns true if we are performing any kind of LTO.
-  bool isUsingLTO() const { return LTOMode != LTOK_None; }
+  bool isUsingLTO(bool IsOffload = false) const {
+return getLTOMode(IsOffload) != LTOK_None;
+  }
 
   /// Get the specific kind of LTO being performed.
-  LTOKind getLTOMode() const { return LTOMode; }
+  LTOKind getLTOMode(bool IsOffload = false) const {
+return IsOffload ? OffloadLTOMode : LTOMode;
+  }
 
 private:
 

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b8cdc5f057b2e..b08aac7071dcc 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -1964,6 +1964,12 @@ def flto : Flag<["-"], "flto">, Flags<[CoreOption, 
CC1Option]>, Group,
   HelpText<"Enable LTO in 'full' mode">;
 def fno_lto : Flag<["-"], "fno-lto">, Flags<[CoreOption, CC1Option]>, 
Group,
   HelpText<"Disable LTO mode (default)">;
+def foffload_lto_EQ : Joined<["-"], "foffload-lto=">, Flags<[CoreOption]>, 
Group,
+  HelpText<"Set LTO mode to either 'full' or 'thin' for offload compilation">, 
Values<"thin,full">;
+def foffload_lto : Flag<["-"], "foffload-lto">, Flags<[CoreOption]>, 
Group,
+  HelpText<"Enable LTO in 'full' mode for offload compilation">;
+def fno_offload_lto : Flag<["-"], "fno-offload-lto">, Flags<[CoreOption]>, 
Group,
+  HelpText<"Disable LTO mode (default) for offload compilation">;
 def flto_jobs_EQ : Joined<["-"], "flto-jobs=">,
   Flags<[CC1Option]>, Group,
   HelpText<"Controls the backend parallelism of -flto=thin (default "

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 6a133771f8fd8..5f1553337fea3 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -594,19 +594,24 @@ static llvm::Triple computeTargetTriple(const Driver &D,
 }
 
 // Parse the LTO options and record the type of LTO compilation
-// based on which -f(no-)?lto(=.*)? option occurs last.
-void Driver::setLTOMode(const llvm::opt::ArgList &Args) {
-  LTOMode = LTOK_None;
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_flto_EQ,
-options::OPT_fno_lto, false) &&
-  !Args.hasFlag(options::OPT_flto_EQ_auto, options::OPT_fno_lto, false) &&
-  !Args.hasFlag(options::OPT_flto_EQ_jobserver, options::OPT_fno_lto,
-false))
-return;
+// based on which -f(no-)?lto(=.*)? or -f(no-)?offload-lto(=.*)?
+// option occurs last.
+static llvm::Optional
+parseLTOMode(Driver &D, const llvm::opt::ArgList &Args, OptSpecifier OptPos,
+ OptSpecifier OptNeg, OptSpecifier OptEq, bool IsOffload) {
+  driver::LTOKind LTOMode = LTOK_None;
+  // Non-offload LTO allows -flto=aut

[PATCH] D99683: [HIP] Support ThinLTO

[Yaxun Liu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbf6124580dfb: [HIP] support ThinLTO (authored by yaxunl).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D99683?vs=344949&id=347205#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99683

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/test/Driver/hip-options.hip
  llvm/lib/Transforms/IPO/FunctionImport.cpp
  llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
  llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
  llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
  llvm/test/Transforms/FunctionImport/funcimport.ll
  llvm/test/Transforms/FunctionImport/noinline.ll

Index: llvm/test/Transforms/FunctionImport/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/noinline.ll
@@ -0,0 +1,23 @@
+; Do setup work for all below tests: generate bitcode and combined index
+; RUN: opt -module-summary %s -o %t.main.bc
+; RUN: opt -module-summary %p/Inputs/noinline.ll -o %t.inputs.noinline.bc
+; RUN: llvm-lto -thinlto -o %t.summary %t.main.bc %t.inputs.noinline.bc
+
+; Attempt the import now, ensure below that file containing noinline
+; is not imported by default but imported with -force-import-all.
+
+; RUN: opt -function-import -summary-file %t.summary.thinlto.bc %t.main.bc -S 2>&1 \
+; RUN:   | FileCheck -check-prefix=NOIMPORT %s
+; RUN: opt -function-import -force-import-all -summary-file %t.summary.thinlto.bc \
+; RUN:   %t.main.bc -S 2>&1 | FileCheck -check-prefix=IMPORT %s
+
+define i32 @main() #0 {
+entry:
+  %f = alloca i64, align 8
+  call void @foo(i64* %f)
+  ret i32 0
+}
+
+; NOIMPORT: declare void @foo(i64*)
+; IMPORT: define available_externally void @foo
+declare void @foo(i64*) #1
Index: llvm/test/Transforms/FunctionImport/funcimport.ll
===
--- llvm/test/Transforms/FunctionImport/funcimport.ll
+++ llvm/test/Transforms/FunctionImport/funcimport.ll
@@ -1,3 +1,5 @@
+; REQUIRES: x86-registered-target
+
 ; Do setup work for all below tests: generate bitcode and combined index
 ; RUN: opt -module-summary %s -o %t.bc
 ; RUN: opt -module-summary %p/Inputs/funcimport.ll -o %t2.bc
@@ -15,6 +17,13 @@
 ; RUN: opt -function-import -enable-import-metadata  -summary-file %t3.thinlto.bc %t.bc -import-instr-limit=5 -S | FileCheck %s --check-prefix=CHECK --check-prefix=INSTLIM5
 ; INSTLIM5-NOT: @staticfunc.llvm.
 
+; Test force import all
+; RUN: llvm-lto -thinlto-action=run -force-import-all %t.bc %t2.bc 2>&1 \
+; RUN:  | FileCheck %s --check-prefix=IMPORTALL
+; IMPORTALL-DAG: Error importing module: Failed to import function weakalias due to InterposableLinkage
+
+target datalayout = "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-apple-macosx10.11.0"
 
 define i32 @main() #0 {
 entry:
Index: llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
===
--- llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
+++ llvm/test/Transforms/FunctionImport/adjustable_threshold.ll
@@ -11,7 +11,15 @@
 ; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc -import-instr-limit=10 -import-instr-evolution-factor=0.5 -S | FileCheck %s --check-prefix=INSTLIM-PROGRESSIVE
 ; INSTLIM-PROGRESSIVE-NOT: call void @staticfunc
 
-
+; Test force import all
+; RUN: opt -function-import -summary-file %t3.thinlto.bc %t.bc \
+; RUN:  -import-instr-limit=1 -force-import-all -S \
+; RUN:  | FileCheck %s --check-prefix=IMPORTALL
+; IMPORTALL-DAG: define available_externally void @globalfunc1()
+; IMPORTALL-DAG: define available_externally void @trampoline()
+; IMPORTALL-DAG: define available_externally void @largefunction()
+; IMPORTALL-DAG: define available_externally hidden void @staticfunc2.llvm.0()
+; IMPORTALL-DAG: define available_externally void @globalfunc2()
 
 declare void @globalfunc1()
 declare void @globalfunc2()
Index: llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
===
--- /dev/null
+++ llvm/test/Transforms/FunctionImport/Inputs/noinline.ll
@@ -0,0 +1,8 @@
+define void @foo(i64* %v) #0 {
+entry:
+  %v.addr = alloca i64*, align 8
+  store i64* %v, i64** %v.addr, align 8
+  ret void
+}
+
+attributes #0 = { noinline }
\ No newline at end of file
Index: llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
===
--- llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
+++ llvm/test/Transforms/FunctionImport/Inputs/funcimport.ll
@@ -1,3 +1,6 @@
+target

[PATCH] D102730: [clang-format] Support custom If macros

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added inline comments.



Comment at: clang/include/clang/Format/Format.h:2983
 /// \endcode
-SBPO_ControlStatementsExceptForEachMacros,
+SBPO_ControlStatementsExceptControlMacros,
 /// Put a space before opening parentheses only if the parentheses are not

Why did you change this?


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

https://reviews.llvm.org/D102730

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

[PATCH] D101777: [clang] p1099 1/5: [NFC] Break out BaseUsingDecl from UsingDecl

[David Rector via Phabricator via cfe-commits]

davrec accepted this revision.
davrec added a comment.

Sorry for the delay.
Richard should probably weigh in before absolutely committing to

1. BaseUsingDecl/UsingEnumDecl/UsingDecl (as implemented here) vs. single 
UsingDecl (Nathan's original approach) and
2. Renaming `getUsingDecl()` to `getIntroducer()` (if it is to return a 
`BaseUsingDecl`).

(Main rationale for separating UsingEnumDecl vs. UsingDecl: parallels the 
naming distinction in P1099  between a 
"using-declaration" and a "using-enum-declaration".  Cons: churn, adds to quite 
a collection of Using*-named AST nodes already.  Nonetheless I favor 
distinguishing them.)




Comment at: clang/include/clang/AST/DeclCXX.h:3390
   ConstructorUsingShadowDecl(ASTContext &C, DeclContext *DC, SourceLocation 
Loc,
- UsingDecl *Using, NamedDecl *Target,
+ BaseUsingDecl *Using, NamedDecl *Target,
  bool TargetInVirtualBase)

`BaseUsingDecl` here should remain `UsingDecl`.
Additionally, I would add a `UsingDecl *getIntroducer() { return 
cast(UsingShadowDecl::getIntroducer()); }` method here.



Comment at: clang/lib/AST/DeclCXX.cpp:3026
 CXXRecordDecl *ConstructorUsingShadowDecl::getNominatedBaseClass() const {
-  return getUsingDecl()->getQualifier()->getAsRecordDecl();
+  return cast(getIntroducer())->getQualifier()->getAsRecordDecl();
 }

With the additional `ConstructorUsingShadowDecl::getIntroducer()` method 
suggested elsewhere, the cast won't be necessary here.


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

https://reviews.llvm.org/D101777

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

[PATCH] D102730: [clang-format] Support custom If macros

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a subscriber: krasimir.
MyDeveloperDay added a comment.

This kind of looks ok to me, I'm not sure about the "lexer" part, I guess I 
don't know the impact but I'd expect it to be small because it's conditional on 
your IfMacro

I'd like @curdeius or @krasimir  to take a look.


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

https://reviews.llvm.org/D102730

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

[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I personally like to keep clang-format and clang-format tests clang formatted 
all the time so we have a reasonable set of "clang-format-clean" code we can 
sanity check any change against, the more of LLVM that can be clean the better 
our testing can be.




Comment at: clang/docs/ClangFormatStyleOptions.rst:2790
 
+**LambdaBodyIndentation** (``LambdaBodyIndentationKind``)
+  What is the lambda body indented relative to (default is ``Signature``).

vlovich wrote:
> MyDeveloperDay wrote:
> > Did you generate this by hand or using the clang/doc/tools/dump_style.py?
> By hand. `dump_format_style` generates other changes (although I wasn't aware 
> of it at the time). I'll regenerate just this section using that tool.
it shouldn't, that probably means someone has made a change without keeping 
them consistent..I'll take a look at that.


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

https://reviews.llvm.org/D102706

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

[PATCH] D98237: [clang-format] Option for empty lines after an access modifier.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

When you made this commit you didn't regenerate the ClangFormatStyleOptions.rst 
from the Format.h using clang/docs/tool/dump_format_style.py now anyone else 
using the tool hit issues with code which is incorrect, we need to update 
Format.h to match what you expect in ClangFormatStyleOptions.rst


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98237

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

[PATCH] D101344: [clang-format] Add `SpacesInAngles: Leave` option to keep spacing inside angle brackets as is.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Whoops, We forgot to regenerate ClangFormatStyleOptions.rst here following the 
change to Format.h


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101344

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

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

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis updated this revision to Diff 347206.
ggeorgakoudis added a comment.
Herald added a subscriber: jfb.

Add tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGenCXX/observe-noexcept.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/debug-info-complex-byval.cpp
  clang/test/OpenMP/debug-info-openmp-array.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/for_firstprivate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_private_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/openmp_win_codegen.cpp
  clang/test/OpenMP/ordered_codegen.cpp
  clang/test/OpenMP/parallel_codegen.cpp
  clang/test/OpenMP/parallel_copyin_codegen.cpp
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_for_codegen.cpp
  clang/test/OpenMP/parallel_for_lastprivate_conditional.cpp
  clang/test/OpenMP/parallel_for_linear_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_if_codegen.cpp
  clang/test/OpenMP/parallel_master_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_private_codegen.cpp
  clang/test/OpenMP/parallel_reduction_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/reduction_compound_op.cpp
  clang/test/OpenMP/remark

[PATCH] D102338: [Sema] Always search the full function scope context if a potential availability violation is encountered

[Logan Smith via Phabricator via cfe-commits]

logan-5 added a comment.

Thanks very much; I look forward to any feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102338

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

[PATCH] D102241: [clang] p1099 4/5: using enum EnumTag

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:520-523
+  /// Like InstantiatedFromUsingDecl, but for using-enum declarations. Maps
+  /// from the instantiated using-enum to the templated decl from whence it
+  /// came.
+  llvm::DenseMap InstantiatedFromUsingEnumDecl;

We need a detailed example in the documentation, since IIUC P1099 does not 
allow a using-enum-declaration to name "dependent" enums and thus is 
distinguished from using-declarations. Specifically the wording is:
> using-enum-declaration:
>  using elaborated-enum-specifier ;
> 1. The elaborated-enum-specifier shall not name a dependent type and the type 
> shall have a reachable enum-specifier.
> ...
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html)

Now I'm not 100% clear on what that wording permits, but we need an example of 
how a UsingEnumDecl can be an instantiation.  Something like this maybe?  
```
template
struct Foo {
  enum E { e = N };
};
template
struct Bar : Foo {
  using enum Foo::E; //Allowed per P1099?
};
Bar<1>;
```

We can also clarify the types here to
```
llvm::DenseMap
```
since there are no UnresolvedUsing*Decl` versions to account for, as there were 
with using decls.



Comment at: clang/include/clang/AST/ASTContext.h:906-907
 
   /// If the given using decl \p Inst is an instantiation of a
   /// (possibly unresolved) using decl from a template instantiation,
   /// return it.

```
  /// If the given using decl \p Inst is an instantiation of
  /// another (possibly unresolved) using decl, return it.
```



Comment at: clang/include/clang/AST/ASTContext.h:915-918
+  /// If the given using-enum decl \p Inst is an instantiation of a
+  /// (possibly unresolved) using decl from a template instantiation,
+  /// return it.
+  NamedDecl *getInstantiatedFromUsingEnumDecl(NamedDecl *Inst);

```
  /// If the given using-enum decl \p Inst is an instantiation of
  /// another using-enum decl, return it.
  UsingEnumDecl *getInstantiatedFromUsingEnumDecl(UsingEnumDecl *Inst);
```



Comment at: clang/include/clang/AST/ASTContext.h:922
+  /// of the using enum decl \p Pattern of a class template.
+  void setInstantiatedFromUsingEnumDecl(NamedDecl *Inst, NamedDecl *Pattern);
+

`UsingEnumDecl *Inst, UsingEnumDecl *Pattern`



Comment at: clang/lib/AST/ASTContext.cpp:1574
 
+NamedDecl *ASTContext::getInstantiatedFromUsingEnumDecl(NamedDecl *UUD) {
+  auto Pos = InstantiatedFromUsingEnumDecl.find(UUD);

NamedDecl -> UsingEnumDecl



Comment at: clang/lib/AST/ASTContext.cpp:1582-1583
+
+void ASTContext::setInstantiatedFromUsingEnumDecl(NamedDecl *Inst,
+  NamedDecl *Pattern) {
+  assert(isa(Pattern) &&

NamedDecl -> UsingEnumDecl


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

https://reviews.llvm.org/D102241

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 updated this revision to Diff 347208.
feg208 added a comment.

This reworks substantially this commit. I recognize there are lacking/broken
tests but I just would like to ensure that the general direction doesn't
seem likely to end in tears


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/ContinuationIndenter.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/TokenAnnotator.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16367,6 +16367,136 @@
getLLVMStyle());
 }
 
+TEST_F(FormatTest, CatchAlignArrayOfStructures) {
+  auto Style = getLLVMStyle();
+  Style.AlignArrayOfStructures = true;
+  Style.AlignConsecutiveAssignments =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[3] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[3] = {\n"
+   "{int{56},23, \"hello\" },\n"
+   "{int{-1}, 93463, \"world\" },\n"
+   "{ int{7}, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("demo = std::array{\n"
+   "test{56,23, \"hello\" },\n"
+   "test{-1, 93463, \"world\" },\n"
+   "test{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "#if X\n"
+   "{-1, 93463, \"world\" },\n"
+   "#endif\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+
+  verifyFormat("test demo[] = {\n"
+   "{ 7,23,\n"
+   "\"hello world i am a very long line that really, in any\"\n"
+   "\"just world, ought to be split over multiple lines\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{56, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+ /* FIXME Still broke
+  verifyFormat("return GradForUnaryCwise(g, {\n"
+   "{{\"sign\"}, \"Sign\",   "
+   "{\"x\", \"dy\"} },\n"
+   "{  {\"dx\"},  \"Mul\", {\"dy\""
+   ", \"sign\"} },\n"
+   "});\n", Style);*/
+
+  Style.ColumnLimit = 0;
+  EXPECT_EQ(
+  "test demo[] = {\n"
+  "{56,23, \"hello world i am a very long line that really, "
+  "in any just world, ought to be split over multiple lines\" },\n"
+  "{-1, 93463,  "
+  " \"world\" },\n"
+  "{ 7, 5,  "
+  "\"!!\" },\n"
+  "};",
+  format("test demo[] = {{56, 23, \"hello world i am a very long line "
+ "that really, in any just world, ought to be split over multiple "
+ "lines\"},{-1, 93463, \"world\"},{7, 5, \"!!\"},};",
+ Style));
+  Style.ColumnLimit = 20;
+  EXPECT_EQ(
+  "demo = std::array<\n"
+  "struct test, 3>{\n"
+  "test{56,23,\n"
+  "\"hello \"\n"
+  "\"world i \"\n"
+  "\"am a very \"\n"
+  "\"long line \"\n"
+  "\"that \"\n"
+

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 updated this revision to Diff 347209.
feg208 added a comment.

Forgot to alter the documentation to reflect right justified column alignment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/ContinuationIndenter.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/TokenAnnotator.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16367,6 +16367,136 @@
getLLVMStyle());
 }
 
+TEST_F(FormatTest, CatchAlignArrayOfStructures) {
+  auto Style = getLLVMStyle();
+  Style.AlignArrayOfStructures = true;
+  Style.AlignConsecutiveAssignments =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[3] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[3] = {\n"
+   "{int{56},23, \"hello\" },\n"
+   "{int{-1}, 93463, \"world\" },\n"
+   "{ int{7}, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("demo = std::array{\n"
+   "test{56,23, \"hello\" },\n"
+   "test{-1, 93463, \"world\" },\n"
+   "test{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "#if X\n"
+   "{-1, 93463, \"world\" },\n"
+   "#endif\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+
+  verifyFormat("test demo[] = {\n"
+   "{ 7,23,\n"
+   "\"hello world i am a very long line that really, in any\"\n"
+   "\"just world, ought to be split over multiple lines\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{56, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+ /* FIXME Still broke
+  verifyFormat("return GradForUnaryCwise(g, {\n"
+   "{{\"sign\"}, \"Sign\",   "
+   "{\"x\", \"dy\"} },\n"
+   "{  {\"dx\"},  \"Mul\", {\"dy\""
+   ", \"sign\"} },\n"
+   "});\n", Style);*/
+
+  Style.ColumnLimit = 0;
+  EXPECT_EQ(
+  "test demo[] = {\n"
+  "{56,23, \"hello world i am a very long line that really, "
+  "in any just world, ought to be split over multiple lines\" },\n"
+  "{-1, 93463,  "
+  " \"world\" },\n"
+  "{ 7, 5,  "
+  "\"!!\" },\n"
+  "};",
+  format("test demo[] = {{56, 23, \"hello world i am a very long line "
+ "that really, in any just world, ought to be split over multiple "
+ "lines\"},{-1, 93463, \"world\"},{7, 5, \"!!\"},};",
+ Style));
+  Style.ColumnLimit = 20;
+  EXPECT_EQ(
+  "demo = std::array<\n"
+  "struct test, 3>{\n"
+  "test{56,23,\n"
+  "\"hello \"\n"
+  "\"world i \"\n"
+  "\"am a very \"\n"
+  "\"long line \"\n"
+  "\"that \"\n"
+  "\"really, \"\n"
+  "\"in any \"\n"
+  "\"just \"\n"
+  " 

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 updated this revision to Diff 347211.
feg208 added a comment.

Adds some tests and fixes a broken test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/ContinuationIndenter.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/TokenAnnotator.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16367,6 +16367,153 @@
getLLVMStyle());
 }
 
+TEST_F(FormatTest, CatchAlignArrayOfStructures) {
+  auto Style = getLLVMStyle();
+  Style.AlignArrayOfStructures = true;
+  Style.AlignConsecutiveAssignments =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations =
+  FormatStyle::AlignConsecutiveStyle::ACS_Consecutive;
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" }, // first line\n"
+   "{-1, 93463, \"world\" }, // second line\n"
+   "{ 7, 5,\"!!\" }  // third line\n"
+   "};\n",
+   Style);
+
+  verifyFormat("struct test demo[4] = {\n"
+   "{ 56,23, 21,   \"oh\" }, // first line\n"
+   "{ -1, 93463, 22,   \"my\" }, // second line\n"
+   "{  7, 5,  1, \"goodness\" }  // third line\n"
+   "{234, 5,  1, \"gracious\" }  // fourth line\n"
+   "};\n",
+   Style);
+
+  verifyFormat("struct test demo[3] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[3] = {\n"
+   "{int{56},23, \"hello\" },\n"
+   "{int{-1}, 93463, \"world\" },\n"
+   "{ int{7}, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+  verifyFormat("struct test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("demo = std::array{\n"
+   "test{56,23, \"hello\" },\n"
+   "test{-1, 93463, \"world\" },\n"
+   "test{ 7, 5,\"!!\" },\n"
+   "};\n",
+   Style);
+  verifyFormat("test demo[] = {\n"
+   "{56,23, \"hello\" },\n"
+   "#if X\n"
+   "{-1, 93463, \"world\" },\n"
+   "#endif\n"
+   "{ 7, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+
+  verifyFormat("test demo[] = {\n"
+   "{ 7,23,\n"
+   "\"hello world i am a very long line that really, in any\"\n"
+   "\"just world, ought to be split over multiple lines\" },\n"
+   "{-1, 93463, \"world\" },\n"
+   "{56, 5,\"!!\" }\n"
+   "};\n",
+   Style);
+
+  verifyFormat("return GradForUnaryCwise(g, {\n"
+   "{{\"sign\"}, \"Sign\",  "
+   "{\"x\", \"dy\"} },\n"
+   "{  {\"dx\"},  \"Mul\", {\"dy\""
+   ", \"sign\"} },\n"
+   "});\n",
+   Style);
+
+  Style.ColumnLimit = 0;
+  EXPECT_EQ(
+  "test demo[] = {\n"
+  "{56,23, \"hello world i am a very long line that really, "
+  "in any just world, ought to be split over multiple lines\" },\n"
+  "{-1, 93463,  "
+  " \"world\" },\n"
+  "{ 7, 5,  "
+  "\"!!\" },\n"
+  "};",
+  format("test demo[] 

[PATCH] D102241: [clang] p1099 4/5: using enum EnumTag

[David Rector via Phabricator via cfe-commits]

davrec added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:520-523
+  /// Like InstantiatedFromUsingDecl, but for using-enum declarations. Maps
+  /// from the instantiated using-enum to the templated decl from whence it
+  /// came.
+  llvm::DenseMap InstantiatedFromUsingEnumDecl;

davrec wrote:
> We need a detailed example in the documentation, since IIUC P1099 does not 
> allow a using-enum-declaration to name "dependent" enums and thus is 
> distinguished from using-declarations. Specifically the wording is:
> > using-enum-declaration:
> >  using elaborated-enum-specifier ;
> > 1. The elaborated-enum-specifier shall not name a dependent type and the 
> > type shall have a reachable enum-specifier.
> > ...
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html)
> 
> Now I'm not 100% clear on what that wording permits, but we need an example 
> of how a UsingEnumDecl can be an instantiation.  Something like this maybe?  
> ```
> template
> struct Foo {
>   enum E { e = N };
> };
> template
> struct Bar : Foo {
>   using enum Foo::E; //Allowed per P1099?
> };
> Bar<1>;
> ```
> 
> We can also clarify the types here to
> ```
> llvm::DenseMap
> ```
> since there are no UnresolvedUsing*Decl` versions to account for, as there 
> were with using decls.
It occurs to me that, duh, non-dependent declarations in a template still need 
to be instantiated.
So in summary I would just change these lines to this:
```
  /// Like InstantiatedFromUsingDecl, but for using-enum-declarations. Maps
  /// from the instantiated using-enum to the templated decl from whence it
  /// came.
  /// Note that using-enum-declarations cannot be dependent and
  /// thus will never be instantiated from an "unresolved"
  /// version thereof (as with using-declarations), so each mapping is from
  /// a (resolved) UsingEnumDecl to a (resolved) UsingEnumDecl.
  llvm::DenseMap 
InstantiatedFromUsingEnumDecl;  
```


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

https://reviews.llvm.org/D102241

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

[clang] b604301 - [Driver] Support libc++ in MSVC

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2021-05-22T13:32:23-07:00
New Revision: b604301be3559fb85a11779db79fc9bda4b62bce

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

LOG: [Driver] Support libc++ in MSVC

This implements support for using libc++ headers and library in the MSVC
toolchain.  We only support libc++ that is a part of the toolchain, and
not headers installed elsewhere on the system.

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

Added: 
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep

clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep

clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
clang/test/Driver/msvc-libcxx.cpp

Modified: 
clang/lib/Driver/ToolChains/MSVC.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 2fddbd6829fad..1acd5f4dcf6c2 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,6 +435,11 @@ void visualstudio::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto &LibPath : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  // Add library directories for standard library shipped with the toolchain.
+  for (const auto &LibPath : TC.getFilePaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1323,7 +1328,36 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
  ArgStringList &CC1Args) const 
{
-  // FIXME: There should probably be logic here to find libc++ on Windows.
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx: {
+SmallString<128> P(getDriver().Dir);
+llvm::sys::path::append(P, "..", "include");
+
+std::string Version = detectLibcxxVersion(P);
+if (Version.empty())
+  return;
+
+// First add the per-target include path if it exists.
+SmallString<128> TargetDir(P);
+llvm::sys::path::append(TargetDir, getTripleString(), "c++", Version);
+if (getVFS().exists(TargetDir))
+  addSystemInclude(DriverArgs, CC1Args, TargetDir);
+
+// Second add the generic one.
+SmallString<128> Dir(P);
+llvm::sys::path::append(Dir, "c++", Version);
+addSystemInclude(DriverArgs, CC1Args, Dir);
+break;
+  }
+
+  default:
+// TODO: Shall we report an error for other C++ standard libraries?
+break;
+  }
 }
 
 VersionTuple MSVCToolChain::computeMSVCVersion(const Driver *D,

diff  --git a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
new file mode 100644
index 0..e69de29bb2d1d

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

diff  --git 
a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git 
a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/msvc-libcxx.cpp 
b/clang/test/Driver/msvc-libcxx.cpp
new file mode 100644
index 0..c209ec9aca24c
--- /dev/null
+++ b/clang/test/Driver/msvc-libcxx.cpp
@@ -0,0 +1,7 @@
+// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
+// RUN:   --target=x86_64-pc-windows-msvc \
+// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
+// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}c++{{/|}

[PATCH] D101479: [Driver] Support libc++ in MSVC

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb604301be355: [Driver] Support libc++ in MSVC (authored by 
phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101479

Files:
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep
  
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
  clang/test/Driver/msvc-libcxx.cpp


Index: clang/test/Driver/msvc-libcxx.cpp
===
--- /dev/null
+++ clang/test/Driver/msvc-libcxx.cpp
@@ -0,0 +1,7 @@
+// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
+// RUN:   --target=x86_64-pc-windows-msvc \
+// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
+// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: 
"-libpath:{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-pc-windows-msvc"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,6 +435,11 @@
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto &LibPath : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  // Add library directories for standard library shipped with the toolchain.
+  for (const auto &LibPath : TC.getFilePaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1323,7 +1328,36 @@
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
  ArgStringList &CC1Args) const 
{
-  // FIXME: There should probably be logic here to find libc++ on Windows.
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx: {
+SmallString<128> P(getDriver().Dir);
+llvm::sys::path::append(P, "..", "include");
+
+std::string Version = detectLibcxxVersion(P);
+if (Version.empty())
+  return;
+
+// First add the per-target include path if it exists.
+SmallString<128> TargetDir(P);
+llvm::sys::path::append(TargetDir, getTripleString(), "c++", Version);
+if (getVFS().exists(TargetDir))
+  addSystemInclude(DriverArgs, CC1Args, TargetDir);
+
+// Second add the generic one.
+SmallString<128> Dir(P);
+llvm::sys::path::append(Dir, "c++", Version);
+addSystemInclude(DriverArgs, CC1Args, Dir);
+break;
+  }
+
+  default:
+// TODO: Shall we report an error for other C++ standard libraries?
+break;
+  }
 }
 
 VersionTuple MSVCToolChain::computeMSVCVersion(const Driver *D,


Index: clang/test/Driver/msvc-libcxx.cpp
===
--- /dev/null
+++ clang/test/Driver/msvc-libcxx.cpp
@@ -0,0 +1,7 @@
+// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
+// RUN:   --target=x86_64-pc-windows-msvc \
+// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
+// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
+// MSVC-LIBCXX: "-internal-isystem" "{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-internal-isystem" "{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-libpath:{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-pc-windows-msvc"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,6 +435,11 @@
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto &LibPath : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  // Add library directories for standard library shipped with the toolchain.
+  for (const auto &LibPath : TC.getFilePaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1323,7 +1328,36 @@
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
  ArgStringList &CC1Args) const {
-  // FIXME: There

[PATCH] D97340: [HIP] Support Spack packages

[Harmen Stoppels via Phabricator via cfe-commits]

haampie reopened this revision.
haampie added a comment.
This revision is now accepted and ready to land.

I've created a pull request to spack here: 
https://github.com/spack/spack/pull/23859, hopefully that's enough to revert 
this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97340

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

[clang] 5ff79f0 - Revert "[Driver] Support libc++ in MSVC"

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2021-05-22T15:49:46-07:00
New Revision: 5ff79f001feb6584e87173348a24f3f317e35984

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

LOG: Revert "[Driver] Support libc++ in MSVC"

This reverts commit b604301be3559fb85a11779db79fc9bda4b62bce since
it caused compilation failure in sanitizer_unwind_win.cpp when using
the runtimes build.

Added: 


Modified: 
clang/lib/Driver/ToolChains/MSVC.cpp

Removed: 
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep

clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep

clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
clang/test/Driver/msvc-libcxx.cpp



diff  --git a/clang/lib/Driver/ToolChains/MSVC.cpp 
b/clang/lib/Driver/ToolChains/MSVC.cpp
index 1acd5f4dcf6c2..2fddbd6829fad 100644
--- a/clang/lib/Driver/ToolChains/MSVC.cpp
+++ b/clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,11 +435,6 @@ void visualstudio::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto &LibPath : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
-  // Add library directories for standard library shipped with the toolchain.
-  for (const auto &LibPath : TC.getFilePaths()) {
-if (TC.getVFS().exists(LibPath))
-  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
-  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1328,36 +1323,7 @@ void MSVCToolChain::AddClangSystemIncludeArgs(const 
ArgList &DriverArgs,
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
  ArgStringList &CC1Args) const 
{
-  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
-  DriverArgs.hasArg(options::OPT_nostdincxx))
-return;
-
-  switch (GetCXXStdlibType(DriverArgs)) {
-  case ToolChain::CST_Libcxx: {
-SmallString<128> P(getDriver().Dir);
-llvm::sys::path::append(P, "..", "include");
-
-std::string Version = detectLibcxxVersion(P);
-if (Version.empty())
-  return;
-
-// First add the per-target include path if it exists.
-SmallString<128> TargetDir(P);
-llvm::sys::path::append(TargetDir, getTripleString(), "c++", Version);
-if (getVFS().exists(TargetDir))
-  addSystemInclude(DriverArgs, CC1Args, TargetDir);
-
-// Second add the generic one.
-SmallString<128> Dir(P);
-llvm::sys::path::append(Dir, "c++", Version);
-addSystemInclude(DriverArgs, CC1Args, Dir);
-break;
-  }
-
-  default:
-// TODO: Shall we report an error for other C++ standard libraries?
-break;
-  }
+  // FIXME: There should probably be logic here to find libc++ on Windows.
 }
 
 VersionTuple MSVCToolChain::computeMSVCVersion(const Driver *D,

diff  --git a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
deleted file mode 100644
index e69de29bb2d1d..0

diff  --git 
a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep
deleted file mode 100644
index e69de29bb2d1d..0

diff  --git 
a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
deleted file mode 100644
index e69de29bb2d1d..0

diff  --git a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep
deleted file mode 100644
index e69de29bb2d1d..0

diff  --git 
a/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
 
b/clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
deleted file mode 100644
index e69de29bb2d1d..0

diff  --git a/clang/test/Driver/msvc-libcxx.cpp 
b/clang/test/Driver/msvc-libcxx.cpp
deleted file mode 100644
index c209ec9aca24c..0
--- a/clang/test/Driver/msvc-libcxx.cpp
+++ /dev/null
@@ -1,7 +0,0 @@
-// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
-// RUN:   --target=x86_64-pc-windows-msvc \
-// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
-// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
-// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
-// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
-// MSVC-LIBCXX: 
"-libpath:{{.*}}{{/|}}..{{/|}

[PATCH] D102970: [clang] [MinGW] Don't mark emutls variables as DSO local

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added reviewers: rnk, mati865.
mstorsjo requested review of this revision.
Herald added a project: clang.

These actually can be automatically imported from another DLL. (This
works properly as long as the actual implementation of emutls is
linked dynamically from e.g. libgcc; if the implementation comes from
compiler-rt or a statically linked libgcc, it doesn't work as intended.)

This fixes PR50146 and https://github.com/msys2/MINGW-packages/issues/8706
(fixing calling std::call_once in a dynamically linked libstdc++);
since f73183958482602c4588b0f4a1c3a096e7542947 
 the 
dso_local attribute
on the TLS variable affected the actual generated code for accessing
the emutls variable.

The dso_local attribute on the emutls variable made those accesses to
use 32 bit relative addressing in code, which requires runtime pseudo
relocations in the text section, and breaks entirely if the actual
other variable ends up loaded too far away in the virtual address
space.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102970

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/dso-local-executable.c


Index: clang/test/CodeGen/dso-local-executable.c
===
--- clang/test/CodeGen/dso-local-executable.c
+++ clang/test/CodeGen/dso-local-executable.c
@@ -9,13 +9,15 @@
 // COFF-DAG: define dso_local i32* @zed()
 // COFF-DAG: declare dllimport void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck 
--check-prefix=MINGW %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck 
--check-prefixes=MINGW,MINGW-NATIVE_TLS %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - 
-femulated-tls | FileCheck --check-prefixes=MINGW,MINGW-EMUTLS %s
 // MINGW:  @baz = dso_local global i32 42
 // MINGW-NEXT: @import_var = external dllimport global i32
 // MINGW-NEXT: @weak_bar = extern_weak global i32
 // MINGW-NEXT: @bar = external global i32
 // MINGW-NEXT: @local_thread_var = dso_local thread_local global i32 42
-// MINGW-NEXT: @thread_var = external dso_local thread_local global i32
+// MINGW-NATIVE_TLS-NEXT: @thread_var = external dso_local thread_local global 
i32
+// MINGW-EMUTLS-NEXT: @thread_var = external thread_local global i32
 // MINGW-DAG: declare dso_local void @foo()
 // MINGW-DAG: define dso_local i32* @zed()
 // MINGW-DAG: declare dllimport void @import_func()
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -986,8 +986,12 @@
 // In MinGW, variables without DLLImport can still be automatically
 // imported from a DLL by the linker; don't mark variables that
 // potentially could come from another DLL as DSO local.
+
+// With EmulatedTLS, TLS variables can be autoimported from other DLLs
+// (and this actually happens in the public interface of libstdc++), so
+// such variables can't be marked as DSO local.
 if (GV->isDeclarationForLinker() && isa(GV) &&
-!GV->isThreadLocal())
+(!GV->isThreadLocal() || CGM.getCodeGenOpts().EmulatedTLS))
   return false;
   }
 


Index: clang/test/CodeGen/dso-local-executable.c
===
--- clang/test/CodeGen/dso-local-executable.c
+++ clang/test/CodeGen/dso-local-executable.c
@@ -9,13 +9,15 @@
 // COFF-DAG: define dso_local i32* @zed()
 // COFF-DAG: declare dllimport void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck --check-prefix=MINGW %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck --check-prefixes=MINGW,MINGW-NATIVE_TLS %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - -femulated-tls | FileCheck --check-prefixes=MINGW,MINGW-EMUTLS %s
 // MINGW:  @baz = dso_local global i32 42
 // MINGW-NEXT: @import_var = external dllimport global i32
 // MINGW-NEXT: @weak_bar = extern_weak global i32
 // MINGW-NEXT: @bar = external global i32
 // MINGW-NEXT: @local_thread_var = dso_local thread_local global i32 42
-// MINGW-NEXT: @thread_var = external dso_local thread_local global i32
+// MINGW-NATIVE_TLS-NEXT: @thread_var = external dso_local thread_local global i32
+// MINGW-EMUTLS-NEXT: @thread_var = external thread_local global i32
 // MINGW-DAG: declare dso_local void @foo()
 // MINGW-DAG: define dso_local i32* @zed()
 // MINGW-DAG: declare dllimport void @import_func()
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -986,8 +986,12 @@
 // In MinGW, variables without DLLImport can still be automatically
 // impo

[PATCH] D102970: [clang] [MinGW] Don't mark emutls variables as DSO local

[Mateusz Mikuła via Phabricator via cfe-commits]

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

Wow, I haven't expected that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102970

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

[PATCH] D102940: [OpenMP] Remove OpenMP CUDA Target Parallel compiler flag

[Shilei Tian via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102940

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

[PATCH] D97680: [OpenMP] Simplify GPU memory globalization

[Shilei Tian via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97680

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

[PATCH] D102839: [RISCV][Clang] Add -mno-idiv option to disable hardware int division

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

Isn't the gcc name for this -mno-div? Should we be consistent?




Comment at: clang/lib/Basic/Targets/RISCV.cpp:154
+  if (DisableHardwareIntDiv) {
+Builder.defineMacro("__riscv_no_idiv");
   }

Does gcc also have this define? Why do we need this in addition to not defining 
__riscv_div. 



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:216
 if (Subtarget.is64Bit()) {
   setOperationAction(ISD::MUL, MVT::i32, Custom);
   setOperationAction(ISD::MUL, MVT::i128, Custom);

These MUL lines are affected by the disableHardwareIntDiv above. Please split 
mul and div handling apart.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102839

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

[PATCH] D102839: [RISCV][Clang] Add -mno-idiv option to disable hardware int division

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

I continue to believe this kind of thing is a bad idea (missing fsqrt for F is 
another one). M means mul and div, if your hardware lacks div then it's not 
compliant with the spec. M-mode is free to lie to S-mode and above as to what's 
supported by the hardware and emulate as needed, but if misa.M is 1 then div 
must work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102839

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

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

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis updated this revision to Diff 347230.
ggeorgakoudis added a comment.

Use non-aggregate captured args and outlining for ordered codegen


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGenCXX/observe-noexcept.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/debug-info-complex-byval.cpp
  clang/test/OpenMP/debug-info-openmp-array.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/for_firstprivate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_private_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/openmp_win_codegen.cpp
  clang/test/OpenMP/parallel_codegen.cpp
  clang/test/OpenMP/parallel_copyin_codegen.cpp
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_for_codegen.cpp
  clang/test/OpenMP/parallel_for_lastprivate_conditional.cpp
  clang/test/OpenMP/parallel_for_linear_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_if_codegen.cpp
  clang/test/OpenMP/parallel_master_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_private_codegen.cpp
  clang/test/OpenMP/parallel_reduction_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/reduction_compound_op.cpp
  clang/test/OpenMP/remarks_parallel_in_mu

[PATCH] D102975: [HIP] Check compatibility of -fgpu-sanitize with offload arch

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, b-sumner.
Herald added subscribers: kerbowa, nhaehnle, jvesely.
yaxunl requested review of this revision.

-fgpu-sanitize is incompatible with offload arch containing xnack-.

This patch checks that.


https://reviews.llvm.org/D102975

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/HIP.cpp
  clang/lib/Driver/ToolChains/HIP.h
  clang/test/Driver/hip-sanitize-options.hip

Index: clang/test/Driver/hip-sanitize-options.hip
===
--- clang/test/Driver/hip-sanitize-options.hip
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -25,6 +25,11 @@
 // RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm-invalid \
 // RUN:   %s 2>&1 | FileCheck -check-prefixes=FAIL %s
 
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx900:xnack- \
+// RUN:   -fsanitize=address -fgpu-sanitize \
+// RUN:   -nogpuinc --rocm-path=%S/Inputs/rocm \
+// RUN:   %s 2>&1 | FileCheck -check-prefix=XNACK %s
+
 // CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
 // CHECK-NOT: {{"[^"]*lld(\.exe){0,1}".* ".*hip.bc"}}
 // CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* "-fsanitize=address"}}
@@ -38,3 +43,5 @@
 // RDC: {{"[^"]*lld(\.exe){0,1}".*}} "[[OUT]]" {{".*asanrtl.bc" ".*hip.bc"}}
 
 // FAIL: AMDGPU address sanitizer runtime library (asanrtl) is not found. Please install ROCm device library which supports address sanitizer
+
+// XNACK: error: '-fgpu-sanitize' is not compatible with offload arch 'gfx900:xnack-'. Use an offload arch without 'xnack-' instead
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -95,6 +95,7 @@
   unsigned GetDefaultDwarfVersion() const override { return 4; }
 
   const ToolChain &HostTC;
+  void checkTargetID(const llvm::opt::ArgList &DriverArgs) const override;
 
 protected:
   Tool *buildLinker() const override;
Index: clang/lib/Driver/ToolChains/HIP.cpp
===
--- clang/lib/Driver/ToolChains/HIP.cpp
+++ clang/lib/Driver/ToolChains/HIP.cpp
@@ -459,3 +459,29 @@
 
   return BCLibs;
 }
+
+void HIPToolChain::checkTargetID(const llvm::opt::ArgList &DriverArgs) const {
+  auto ParsedTargetID = getParsedTargetID(DriverArgs);
+  auto &OptionalTargetID = std::get<0>(ParsedTargetID);
+  auto &OptionalGPU = std::get<1>(ParsedTargetID);
+  if (OptionalTargetID && !OptionalGPU) {
+getDriver().Diag(clang::diag::err_drv_bad_target_id)
+<< OptionalTargetID.getValue();
+return;
+  }
+
+  auto &FeatureMap = std::get<2>(ParsedTargetID).getValue();
+  // Sanitizer is not supported with xnack-.
+  if (DriverArgs.hasFlag(options::OPT_fgpu_sanitize,
+ options::OPT_fno_gpu_sanitize, false)) {
+auto Loc = FeatureMap.find("xnack");
+if (Loc != FeatureMap.end() && !Loc->second) {
+  auto &Diags = getDriver().getDiags();
+  auto DiagID = Diags.getCustomDiagID(
+  DiagnosticsEngine::Error,
+  "'-fgpu-sanitize' is not compatible with offload arch '%0'. "
+  "Use an offload arch without 'xnack-' instead");
+  Diags.Report(DiagID) << OptionalTargetID.getValue();
+}
+  }
+}
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -107,7 +107,13 @@
 
 protected:
   /// Check and diagnose invalid target ID specified by -mcpu.
-  void checkTargetID(const llvm::opt::ArgList &DriverArgs) const;
+  virtual void checkTargetID(const llvm::opt::ArgList &DriverArgs) const;
+
+  /// Get target ID, GPU arch, and target ID features if the target ID is
+  /// specified and valid.
+  std::tuple, Optional,
+ Optional>>
+  getParsedTargetID(const llvm::opt::ArgList &DriverArgs) const;
 
   /// Get GPU arch from -mcpu without checking.
   StringRef getGPUArch(const llvm::opt::ArgList &DriverArgs) const;
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -707,16 +707,35 @@
   getTriple(), DriverArgs.getLastArgValue(options::OPT_mcpu_EQ));
 }
 
-void AMDGPUToolChain::checkTargetID(
-const llvm::opt::ArgList &DriverArgs) const {
+std::tuple, Optional,
+   Optional>>
+AMDGPUToolChain::getParsedTargetID(const llvm::opt::ArgList &DriverArgs) const {
+  auto MakeTuple = [](auto TargetID, auto GPU, auto Feature) {
+return std::make_tuple, Optional,
+   Optional>>(TargetID, GPU,
+Feature);
+  };
   StringRef TargetID = DriverArgs.getLastArgValue(o

[PATCH] D102839: [RISCV][Clang] Add -mno-idiv option to disable hardware int division

[ksyx via Phabricator via cfe-commits]

ksyx added a comment.

In D102839#2775732 , @craig.topper 
wrote:

> Isn't the gcc name for this -mno-div? Should we be consistent?

I am not sure whether using `-mno-div` might bring in some confusion since from 
the name `no-div` itself it expresses a sense of excluding all hardware 
division instructions, both float ones and integral ones, from my personal 
understanding. However, as in the documentation 
, it only affects the 
integral ones and float one was controlled by another. Thus for the clearance I 
used this naming.

I have not much understanding about what compatibility with GCC we need to 
achieve but I am okay with both kinds of naming and changing this is totally ok 
if required.




Comment at: clang/lib/Basic/Targets/RISCV.cpp:154
+  if (DisableHardwareIntDiv) {
+Builder.defineMacro("__riscv_no_idiv");
   }

craig.topper wrote:
> Does gcc also have this define? Why do we need this in addition to not 
> defining __riscv_div. 
Ok. I will remove it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102839

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