[clang] fcf8827 - [Sema][RISCV][SVE] Allow ?: to select Typedef BuiltinType in C

[ShihPo Hung via cfe-commits]

Author: ShihPo Hung
Date: 2021-06-04T15:33:14+08:00
New Revision: fcf8827a98beb1f8baea883451508d9cd91f57bc

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

LOG: [Sema][RISCV][SVE] Allow ?: to select Typedef BuiltinType in C

This patch solves an error such as:
  incompatible operand types ('vbool4_t' (aka '__rvv_bool4_t') and 
'__rvv_bool4_t')
when one of the value is a TypedefType of the other value in ?:.

Reviewed By: rjmccall

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

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/riscv-types.c
clang/test/Sema/sizeless-1.c

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index ba38b1089413f..422eddce86cd8 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -8393,7 +8393,7 @@ QualType Sema::CheckConditionalOperands(ExprResult &Cond, 
ExprResult &LHS,
 
   // Allow ?: operations in which both operands have the same
   // built-in sizeless type.
-  if (LHSTy->isSizelessBuiltinType() && LHSTy == RHSTy)
+  if (LHSTy->isSizelessBuiltinType() && Context.hasSameType(LHSTy, RHSTy))
 return LHSTy;
 
   // Emit a better diagnostic if one of the expressions is a null pointer

diff  --git a/clang/test/Sema/riscv-types.c b/clang/test/Sema/riscv-types.c
index f1bf2e6afecde..0d09546603b66 100644
--- a/clang/test/Sema/riscv-types.c
+++ b/clang/test/Sema/riscv-types.c
@@ -134,3 +134,12 @@ void bar(void) {
   // CHECK: __rvv_int8mf2_t x43;
   __rvv_int8mf2_t x43;
 }
+
+typedef __rvv_bool4_t vbool4_t;
+__rvv_bool4_t get_rvv_bool4();
+vbool4_t get_vbool4_t();
+
+void func1(int sel) {
+  // CHECK: vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+  vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+}

diff  --git a/clang/test/Sema/sizeless-1.c b/clang/test/Sema/sizeless-1.c
index e1d9265448947..a8c08731d53e6 100644
--- a/clang/test/Sema/sizeless-1.c
+++ b/clang/test/Sema/sizeless-1.c
@@ -57,6 +57,7 @@ void func(int sel) {
   static svint8_t static_int8; // expected-error {{non-local variable with 
sizeless type 'svint8_t'}}
 
   svint8_t local_int8;
+  int8_typedef typedef_int8;
   svint16_t local_int16;
 
   svint8_t __attribute__((aligned)) aligned_int8_1;// expected-error 
{{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
@@ -137,6 +138,7 @@ void func(int sel) {
   const_volatile_int8 = local_int8; // expected-error {{cannot assign to 
variable 'const_volatile_int8' with const-qualified type 'const volatile 
svint8_t'}}
 
   init_int8 = sel ? init_int8 : local_int8;
+  init_int8 = sel ? init_int8 : typedef_int8;
   init_int8 = sel ? init_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_volatile_int8;



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

[PATCH] D103603: [Sema][RISCV][SVE] Allow ?: to select Typedef BuiltinType in C

[ShihPo Hung via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfcf8827a98be: [Sema][RISCV][SVE] Allow ?: to select Typedef 
BuiltinType in C (authored by arcbbb).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103603

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/riscv-types.c
  clang/test/Sema/sizeless-1.c


Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -57,6 +57,7 @@
   static svint8_t static_int8; // expected-error {{non-local variable with 
sizeless type 'svint8_t'}}
 
   svint8_t local_int8;
+  int8_typedef typedef_int8;
   svint16_t local_int16;
 
   svint8_t __attribute__((aligned)) aligned_int8_1;// expected-error 
{{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
@@ -137,6 +138,7 @@
   const_volatile_int8 = local_int8; // expected-error {{cannot assign to 
variable 'const_volatile_int8' with const-qualified type 'const volatile 
svint8_t'}}
 
   init_int8 = sel ? init_int8 : local_int8;
+  init_int8 = sel ? init_int8 : typedef_int8;
   init_int8 = sel ? init_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_volatile_int8;
Index: clang/test/Sema/riscv-types.c
===
--- clang/test/Sema/riscv-types.c
+++ clang/test/Sema/riscv-types.c
@@ -134,3 +134,12 @@
   // CHECK: __rvv_int8mf2_t x43;
   __rvv_int8mf2_t x43;
 }
+
+typedef __rvv_bool4_t vbool4_t;
+__rvv_bool4_t get_rvv_bool4();
+vbool4_t get_vbool4_t();
+
+void func1(int sel) {
+  // CHECK: vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+  vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -8393,7 +8393,7 @@
 
   // Allow ?: operations in which both operands have the same
   // built-in sizeless type.
-  if (LHSTy->isSizelessBuiltinType() && LHSTy == RHSTy)
+  if (LHSTy->isSizelessBuiltinType() && Context.hasSameType(LHSTy, RHSTy))
 return LHSTy;
 
   // Emit a better diagnostic if one of the expressions is a null pointer


Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -57,6 +57,7 @@
   static svint8_t static_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
 
   svint8_t local_int8;
+  int8_typedef typedef_int8;
   svint16_t local_int16;
 
   svint8_t __attribute__((aligned)) aligned_int8_1;// expected-error {{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
@@ -137,6 +138,7 @@
   const_volatile_int8 = local_int8; // expected-error {{cannot assign to variable 'const_volatile_int8' with const-qualified type 'const volatile svint8_t'}}
 
   init_int8 = sel ? init_int8 : local_int8;
+  init_int8 = sel ? init_int8 : typedef_int8;
   init_int8 = sel ? init_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_int8;
   init_int8 = sel ? volatile_int8 : const_volatile_int8;
Index: clang/test/Sema/riscv-types.c
===
--- clang/test/Sema/riscv-types.c
+++ clang/test/Sema/riscv-types.c
@@ -134,3 +134,12 @@
   // CHECK: __rvv_int8mf2_t x43;
   __rvv_int8mf2_t x43;
 }
+
+typedef __rvv_bool4_t vbool4_t;
+__rvv_bool4_t get_rvv_bool4();
+vbool4_t get_vbool4_t();
+
+void func1(int sel) {
+  // CHECK: vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+  vbool4_t t0 = sel ? get_rvv_bool4() : get_vbool4_t();
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -8393,7 +8393,7 @@
 
   // Allow ?: operations in which both operands have the same
   // built-in sizeless type.
-  if (LHSTy->isSizelessBuiltinType() && LHSTy == RHSTy)
+  if (LHSTy->isSizelessBuiltinType() && Context.hasSameType(LHSTy, RHSTy))
 return LHSTy;
 
   // Emit a better diagnostic if one of the expressions is a null pointer
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 21c18d5 - [Format] Fix incorrect pointer detection

[Marek Kurdej via cfe-commits]

Author: Yilong Guo
Date: 2021-06-04T09:39:23+02:00
New Revision: 21c18d5a04316891110cecc2bf37ce51533decba

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

LOG: [Format] Fix incorrect pointer detection

https://llvm.org/PR50429

Before:
void f() { f(float(1), a *a); }

After:
void f() { f(float(1), a * a); }

Signed-off-by: Yilong Guo 

Reviewed By: HazardyKnusperkeks, curdeius

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

Added: 


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

Removed: 




diff  --git a/clang/lib/Format/TokenAnnotator.cpp 
b/clang/lib/Format/TokenAnnotator.cpp
index 4bd9311ebadd4..d08c991daf43f 100755
--- a/clang/lib/Format/TokenAnnotator.cpp
+++ b/clang/lib/Format/TokenAnnotator.cpp
@@ -399,7 +399,7 @@ class AnnotatingParser {
 HasMultipleParametersOnALine = true;
   if ((CurrentToken->Previous->isOneOf(tok::kw_const, tok::kw_auto) ||
CurrentToken->Previous->isSimpleTypeSpecifier()) &&
-  !CurrentToken->is(tok::l_brace))
+  !CurrentToken->isOneOf(tok::l_brace, tok::l_paren))
 Contexts.back().IsExpression = false;
   if (CurrentToken->isOneOf(tok::semi, tok::colon)) {
 MightBeObjCForRangeLoop = false;

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index a2583aecf5a9f..5ea4fcc9ffe36 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -8706,6 +8706,7 @@ TEST_F(FormatTest, UnderstandsUsesOfStarAndAmp) {
 
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
+  verifyFormat("void f() { f(float(1), a * a); }");
   // FIXME: Is there a way to make this work?
   // verifyIndependentOfContext("MACRO(A *a);");
   verifyFormat("MACRO(A &B);");



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

[PATCH] D103589: [Format] Fix incorrect pointer detection

[Marek Kurdej via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG21c18d5a0431: [Format] Fix incorrect pointer detection 
(authored by Nuu, committed by curdeius).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103589

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
@@ -8706,6 +8706,7 @@
 
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
+  verifyFormat("void f() { f(float(1), a * a); }");
   // FIXME: Is there a way to make this work?
   // verifyIndependentOfContext("MACRO(A *a);");
   verifyFormat("MACRO(A &B);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -399,7 +399,7 @@
 HasMultipleParametersOnALine = true;
   if ((CurrentToken->Previous->isOneOf(tok::kw_const, tok::kw_auto) ||
CurrentToken->Previous->isSimpleTypeSpecifier()) &&
-  !CurrentToken->is(tok::l_brace))
+  !CurrentToken->isOneOf(tok::l_brace, tok::l_paren))
 Contexts.back().IsExpression = false;
   if (CurrentToken->isOneOf(tok::semi, tok::colon)) {
 MightBeObjCForRangeLoop = false;


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8706,6 +8706,7 @@
 
   verifyIndependentOfContext("MACRO('0' <= c && c <= '9');");
   verifyFormat("void f() { f(float{1}, a * a); }");
+  verifyFormat("void f() { f(float(1), a * a); }");
   // FIXME: Is there a way to make this work?
   // verifyIndependentOfContext("MACRO(A *a);");
   verifyFormat("MACRO(A &B);");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -399,7 +399,7 @@
 HasMultipleParametersOnALine = true;
   if ((CurrentToken->Previous->isOneOf(tok::kw_const, tok::kw_auto) ||
CurrentToken->Previous->isSimpleTypeSpecifier()) &&
-  !CurrentToken->is(tok::l_brace))
+  !CurrentToken->isOneOf(tok::l_brace, tok::l_paren))
 Contexts.back().IsExpression = false;
   if (CurrentToken->isOneOf(tok::semi, tok::colon)) {
 MightBeObjCForRangeLoop = false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

There is so much fancy stuff going on upstream. Awesome to see.
I'm trying to catch up ASAP, I'm finally done with my master's thesis.

In D103096#2798238 , @NoQ wrote:

> Additionally, presence of cast symbols is extremely valuable for z3 runs in 
> which our concerns for increased complexity are eliminated.

You are probably referring to D85528 . 
(Without that patch, Z3 refutation crashes all over the place due to the 
//not// modeled widening/narrowing casts.)

>>> But this still requires //massive// testing, a lot more than a typical 
>>> constraint solver patch; extraordinary claims require extraordinary 
>>> evidence.
>>
>> What kind of tests do you think we need?
>
> Test on a lot of real-world code. Like, seriously, *A LOT* of real-world 
> code. Say, 20x the amount of code we have in docker and csa-testbench, from a 
> large variety of projects. Investigate newly appeared reports carefully to 
> understand the impact. I'll be happy to help with this at some point.

The CSA-testbench is capable of using the Conan package manager.
By cloning the https://github.com/conan-io/conan-center-index you can get a 
bunch of Conan package recipes, with tests actually using the given library.
Running their tests would ensure that header-only libraries get analyzed as 
well as //normal// libraries. However, frequently used packages would be 
analyzed over and over again, similarly to how headers suffer from this.

We planned to make use of this in the future to make CTU analysis and Z3 
refutation more and more robust.
As soon as we have the infrastructure and scale, we plan to enable a small set 
of contributors of initiating such measurements, but don't expect it in the 
close future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103096

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

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

In D98726#2719100 , @RedDocMD wrote:

> Judging by this line 
> 
>  in the `LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor()` method, 
> it seems that the bug report is squelched when the visitor encounters an  
> `ExplodedNode` which corresponds to a `LocationContext`, whose associated 
> `Decl` lies in **std** namespace. I guess, by default, the option to suppress 
> warnings from the std library is enabled. Which makes sense, except in this 
> case since `unique_ptr` is in std and it is being used in that function, the 
> bug report is suppressed.

This is what causes the false suppression. To be more specific, the analyzer 
tries to follow the logic of the //destructor// of `unique_ptr` into the 
standard library. And since that is in the `std` namespace, it causes 
`LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor()`  to squelch the 
report. Now there are two problems here:

- Why does the analyzer try to follow the logic into the standard library? Is 
it because we haven't explicitly modeled it? (Then, as you said, modelling this 
method will solve the issue).
- Why is there a bug in `unique_ptr.h`? (This is the worse of the two, IMO). I 
am going to take a look at the standard library code (sigh) and see if that's 
an actual bug or another false positive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98726

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

[PATCH] D103228: [PoC][RISCV] Using pragma to register vector intrinsic

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng updated this revision to Diff 349784.
kito-cheng added a comment.

Changes:

- Using less invasive way to add intrinsic functions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103228

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -235,9 +235,6 @@
   ArrayRef PrototypeSeq);
   Optional computeType(BasicType BT, int Log2LMUL, StringRef 
Proto);
 
-  // Emit the architecture preprocessor definitions. Return true when emits
-  // non-empty string.
-  bool emitExtDefStr(uint8_t Extensions, raw_ostream &o);
   // Slice Prototypes string into sub prototype string and process each sub
   // prototype string individually in the Handler.
   void parsePrototypes(StringRef Prototypes,
@@ -1118,23 +1115,6 @@
   return llvm::None;
 }
 
-bool RVVEmitter::emitExtDefStr(uint8_t Extents, raw_ostream &OS) {
-  if (Extents == RISCVExtension::Basic)
-return false;
-  OS << "#if ";
-  ListSeparator LS(" && ");
-  if (Extents & RISCVExtension::F)
-OS << LS << "defined(__riscv_f)";
-  if (Extents & RISCVExtension::D)
-OS << LS << "defined(__riscv_d)";
-  if (Extents & RISCVExtension::Zfh)
-OS << LS << "defined(__riscv_zfh)";
-  if (Extents & RISCVExtension::Zvamo)
-OS << LS << "defined(__riscv_zvamo)";
-  OS << "\n";
-  return true;
-}
-
 static void emitFeatureCheckStr(uint8_t Extents, raw_ostream &OS) {
   if (Extents == RISCVExtension::Basic) {
 OS << 0;


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -235,9 +235,6 @@
   ArrayRef PrototypeSeq);
   Optional computeType(BasicType BT, int Log2LMUL, StringRef Proto);
 
-  // Emit the architecture preprocessor definitions. Return true when emits
-  // non-empty string.
-  bool emitExtDefStr(uint8_t Extensions, raw_ostream &o);
   // Slice Prototypes string into sub prototype string and process each sub
   // prototype string individually in the Handler.
   void parsePrototypes(StringRef Prototypes,
@@ -1118,23 +1115,6 @@
   return llvm::None;
 }
 
-bool RVVEmitter::emitExtDefStr(uint8_t Extents, raw_ostream &OS) {
-  if (Extents == RISCVExtension::Basic)
-return false;
-  OS << "#if ";
-  ListSeparator LS(" && ");
-  if (Extents & RISCVExtension::F)
-OS << LS << "defined(__riscv_f)";
-  if (Extents & RISCVExtension::D)
-OS << LS << "defined(__riscv_d)";
-  if (Extents & RISCVExtension::Zfh)
-OS << LS << "defined(__riscv_zfh)";
-  if (Extents & RISCVExtension::Zvamo)
-OS << LS << "defined(__riscv_zvamo)";
-  OS << "\n";
-  return true;
-}
-
 static void emitFeatureCheckStr(uint8_t Extents, raw_ostream &OS) {
   if (Extents == RISCVExtension::Basic) {
 OS << 0;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103228: [PoC][RISCV] Using pragma to register vector intrinsic

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng updated this revision to Diff 349785.
kito-cheng added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Reupload.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103228

Files:
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/CMakeLists.txt
  clang/lib/Sema/SemaRISCV.cpp
  clang/utils/TableGen/RISCVVEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h
  llvm/docs/CommandGuide/tblgen.rst

Index: llvm/docs/CommandGuide/tblgen.rst
===
--- llvm/docs/CommandGuide/tblgen.rst
+++ llvm/docs/CommandGuide/tblgen.rst
@@ -348,6 +348,14 @@
 
   Generate ``riscv_vector_builtin_cg.inc`` for Clang.
 
+.. option:: -gen-riscv-vector-intrinsic-info
+
+  Generate ``riscv_vector_intrinsic_info.inc`` for Clang.
+
+.. option:: -gen-riscv-vector-intrinsic-overload-info
+
+  Generate ``riscv_vector_intrinsic_overload_info.inc`` for Clang.
+
 .. option:: -gen-attr-docs
 
   Generate attribute documentation.
Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -109,6 +109,9 @@
 void EmitRVVHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitRVVBuiltins(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitRVVBuiltinCG(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitRVVIntrinsicInfo(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitRVVIntrinsicOverloadInfo(llvm::RecordKeeper &Records,
+  llvm::raw_ostream &OS);
 
 void EmitCdeHeader(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitCdeBuiltinDef(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -86,6 +86,8 @@
   GenRISCVVectorHeader,
   GenRISCVVectorBuiltins,
   GenRISCVVectorBuiltinCG,
+  GenRISCVVectorIntrinsicInfo,
+  GenRISCVVectorIntrinsicOverloadInfo,
   GenAttrDocs,
   GenDiagDocs,
   GenOptDocs,
@@ -237,6 +239,13 @@
"Generate riscv_vector_builtins.inc for clang"),
 clEnumValN(GenRISCVVectorBuiltinCG, "gen-riscv-vector-builtin-codegen",
"Generate riscv_vector_builtin_cg.inc for clang"),
+clEnumValN(GenRISCVVectorIntrinsicInfo,
+   "gen-riscv-vector-intrinsic-info",
+   "Generate riscv_vector_intrinsic_info.inc for clang."),
+clEnumValN(
+GenRISCVVectorIntrinsicOverloadInfo,
+"gen-riscv-vector-intrinsic-overload-info",
+"Generate riscv_vector_intrinsic_overload_info.inc for clang."),
 clEnumValN(GenAttrDocs, "gen-attr-docs",
"Generate attribute documentation"),
 clEnumValN(GenDiagDocs, "gen-diag-docs",
@@ -446,6 +455,12 @@
   case GenRISCVVectorBuiltinCG:
 EmitRVVBuiltinCG(Records, OS);
 break;
+  case GenRISCVVectorIntrinsicInfo:
+EmitRVVIntrinsicInfo(Records, OS);
+break;
+  case GenRISCVVectorIntrinsicOverloadInfo:
+EmitRVVIntrinsicOverloadInfo(Records, OS);
+break;
   case GenAttrDocs:
 EmitClangAttrDocs(Records, OS);
 break;
Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -194,12 +194,6 @@
   // Emit the code block for switch body in EmitRISCVBuiltinExpr, it should
   // init the RVVIntrinsic ID and IntrinsicTypes.
   void emitCodeGenSwitchBody(raw_ostream &o) const;
-
-  // Emit the macros for mapping C/C++ intrinsic function to builtin functions.
-  void emitIntrinsicMacro(raw_ostream &o) const;
-
-  // Emit the mangled function definition.
-  void emitMangledFuncDef(raw_ostream &o) const;
 };
 
 class RVVEmitter {
@@ -222,6 +216,12 @@
   /// Emit all the information needed to map builtin -> LLVM IR intrinsic.
   void createCodeGen(raw_ostream &o);
 
+  /// Emit all the intrinsic info for `#pragma riscv vector intrinsic`.
+  void createIntrinsicInfo(raw_ostream &o);
+
+  /// Emit all the intrinsic overload info for `#pragma riscv vector intrinsic`.
+  void createIntrinsicOverloadInfo(raw_ostream &o);
+
   std::string getSuffixStr(char Type, int Log2LMUL, StringRef Prototypes);
 
 private:
@@ -235,15 +235,6 @@
   ArrayRef PrototypeSeq);
   Optional computeType(BasicType BT, int Log2LMUL, StringRef Proto);
 
-  /// Emit Acrh predecessor definitions and body, assume the elem

[PATCH] D97699: [analyzer] Add InvalidPtrChecker

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Overall I think it's a useful checker not only for checking the `getenv()` but 
a bunch of other functions as well, which might return a pointer to a 
statically allocated buffer.
The implementation could be polished a bit but it's ok I think.

About the produced reports, they were all useful and clear.
It is triggered only if it sees evidence(*) of the use of the invalidated 
pointer and highlights where it was produced and later invalidated.

(*) escaping via a conservatively evaluated function call also counts as such. 
There are pros and cons to this, but in this case, it seems like it's a good 
choice.




Comment at: clang/docs/analyzer/checkers.rst:2056
 
+
 .. _alpha-security-cert-pos-checkers:

?



Comment at: clang/test/Analysis/cert/env34-c-cert-examples.c:26-27
+
+  if (strcmp(tmpvar, tempvar) == 0) { // body of strcmp is unknown
+// expected-warning@-1{{use of invalidated pointer 'tmpvar' in a function 
call}}
+  }

I just want to highlight the capabilities of this checker.
Here we are using the invalid `tmpvar` pointer in a conservatively evaluated 
function call, and we still have a warning. Which is awesome.

Just imagine that `getenv()` would return a pointer to the same static buffer, 
then the `strcmp()` would always succeed, which is likely a bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97699

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

[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:282
+
+if (c >= -20 && d >= -40) {
+  clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}

manas wrote:
> vsavchenko wrote:
> > Great, it's good to check negative numbers.
> > I have one note here.  The fact that we don't have a testing framework and 
> > use this approach of inspecting the actual analysis has an interesting 
> > implication.
> > 
> > ```
> > if (a == 10) { // here we split path into 2 paths: one where a == 10, and 
> > one where a != 10;
> >// one goes inside of if, one doesn't
> >   . . .
> > }
> > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and a in [5, 
> > 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> >   // 1 path was infeasible: a == 10 and a < 5
> >   // Two of these paths go inside of the if, one doesn't
> >   . . .
> >   clang_analyzer_eval(a == 10); // it will produce two results: TRUE and 
> > FALSE
> > }
> > clang_analyzer_eval(a == 10); // it will produce three results: TRUE, 
> > FALSE, and FALSE
> > ```
> > 
> > We don't want to test how path splitting works in these particular tests 
> > (they are about solver and constant folding after all), that's why we try 
> > to have only one path going through each `clang_analyzer_eval(...)`
> > 
> > In this example, you still have residual paths where `c != INT_MIN`, `c == 
> > INT_MIN and d != INT_MIN`, and `c == INT_MIN and d == INT_MIN`.
> I should add tests for these paths as well so that these can be checked. For 
> further cases, I will enforce single path evaluation in test cases (which 
> will make it easier to handle here).
In these tests we should really avoid having multiple feasible paths going 
through one `clang_analyzer_eval`.  We can add `// expected-warning` to it 
multiple times, but it's harder to understand as a reader of these tests 
because you need to split all the paths in your mind just like the analyzer 
does.  It can be useful when testing other features of the analyzer, but here 
it's not essential.

And I don't think that you fully understood me.  When multiple paths go through 
`clang_analyzer_eval`, each of them produces a separate "warning".
That's why if you want to account for residual paths, you shouldn't add more 
`if` statements, but add something like:
```
clang_analyzer_eval(a == 10); // expected-warning{{TRUE}}
  // expected-warning@-1{{TRUE}}
  // expected-warning@-2{{FALSE}}
```

So, please, instead of writing tests like this, rewrite your test, so that we 
don't have residual paths.



Comment at: clang/test/Analysis/constant-folding.c:304-305
+  if (c > 0 && d > 0) {
+clang_analyzer_eval((c + d) > 1); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}
+  }

manas wrote:
> vsavchenko wrote:
> > How can these two statements be TRUE at the same time?
> Right, my bad. They both should be `UNKNOWN`.
> 
> As, `c` and `d` are signed 32-bit positive integers, hence their respective 
> values will be in `[1, INT_MAX]`.
> 
> When `c == d == 1` then `c + d == 2`, and when `c == d == INT_MAX` then `c + 
> d == -2` (overflow). Only possible values which `c + d` **cannot** attain are 
> `{-1, 0, 1}`.
> 
> As a simple proof:
> 
> Dividing this range into 
>   R1 = [1, INT_MAX/2] and R2 = [(INT_MAX/2) + 1, INT_MAX]
> 
> Now, `c + d` will have 4 combination of ranges to be solved:
> - `R1 + R1` : this will never overflow as the maximum value it can attain 
> will be `INT_MAX - 1` (when `c == d  == INT_MAX/2`)
> - while in `R1 + R2`, `R2 + R1`, and `R2 + R2` expressions will overflow, 
> leading value of `c + d` from `INT_MIN` to `-2`, except for case `INT_MAX/2 + 
> (INT_MAX/2 + 1)`, where `c + d == INT_MAX`.
> 
> Hence, only possible values which can never be attained by `c + d` will be 
> `{-1, 0, 1}`. So, the range for our purposes will be `[INT_MIN, -2] U [2, 
> INT_MAX]`.
> 
> I think I should write tests for `c + d != {-1, 0, 1}` which will make more 
> sense here.
I see, that's a good test!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

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

[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103440#2797991 , @manas wrote:

>> I also would like to see tests where the ranges are not going all the way to 
>> either INT_MIN or INT_MAX (if we talk about int), but overflow still might 
>> happen, and cases where overflow might happen, but we still can identify the 
>> overflowing results precisely (e.g. the result is `[INT_MIN, INT_MIN + 10] 
>> and [INT_MAX - 5, INT_MAX]`)
>
> If I understood correctly, does a case like: `c, d in [INT_MAX/2 - 10, 
> INT_MAX/2 + 10]` works? It will produce an overflowing range of `[INT_MIN, 
> INT_MIN + 18] U [INT_MAX - 21, INT_MAX]`. I will add that to the test-set, if 
> that is so.

Yes, exactly!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

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

[PATCH] D102273: [analyzer] LoopUnrolling: fix crash when a loop counter is captured in a lambda by reference

[Abbas Sabra via Phabricator via cfe-commits]

AbbasSabra added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102273

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

[PATCH] D102822: [Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable types.

[Sander de Smalen via Phabricator via cfe-commits]

sdesmalen added inline comments.



Comment at: clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp:17
+// CHECK-NEXT:[[TMP1:%.*]] = bitcast * [[REF_TMP]] to i8*
+// CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 -1, i8* [[TMP1]]) 
#[[ATTR3]]
+// CHECK-NEXT:[[CALL:%.*]] = call  @_Z3Bazv()

nit: I'm not sure if there is any policy on this, but for this test you can 
just as well have 6 CHECK lines, instead of auto-generating all of them, which 
makes the test a bit easier to read.

  // CHECK-LABEL: @_Z4Testv
  // CHECK-NEXT:[[ALLOCA:%.*]] = alloca , align 4
  // CHECK-NEXT:[[BC1:%.*]] = bitcast * [[ALLOCA]] to i8*
  // CHECK-NEXT:call void @llvm.lifetime.start.p0i8(i64 -1, i8* [[BC1]])
  // CHECK-NEXT:[[BC2:%.*]] = bitcast * [[ALLOCA]] to i8*
  // CHECK-NEXT:call void @llvm.lifetime.end.p0i8(i64 -1, i8* [[BC2]])



Comment at: clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp:3
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -std=c++11 -triple riscv64 -target-feature +experimental-v \
+// RUN:   -emit-llvm -O1 -o - %s | FileCheck %s

craig.topper wrote:
> Probably best to add -disable-llvm-passes so we don't run the optimizer.
nit: Does `-O1` still have any effect if `-disable-llvm-passes` is also set?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102822

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[David Spickett via Phabricator via cfe-commits]

DavidSpickett accepted this revision.
DavidSpickett added a comment.

> LGTM; any additional thoughts @DavidSpickett ?

A couple of additional tests just to be safe but otherwise LGTM.




Comment at: clang/test/Driver/aarch64-target-as-march.s:29
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a

Add a test with `-Wa,-march=armv8.2-a,-march=armv8.1-a` (one -Wa with multiple 
values attached), then repeat the two tests but with `-Xassembler` instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103677: [analyzer] Extract ControlDependencyHandler

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko created this revision.
vsavchenko added reviewers: NoQ, xazax.hun, martong, steakhal, Szelethus, 
manas, RedDocMD.
Herald added subscribers: ASDenysPetrov, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, rnkovacs, szepet, baloghadamsoftware.
vsavchenko requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103677

Files:
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp


Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -2090,17 +2090,14 @@
   }
 };
 
-class DefaultExpressionHandler final : public ExpressionHandler {
+class ControlDependencyHandler final : public ExpressionHandler {
 public:
   using ExpressionHandler::ExpressionHandler;
 
   Tracker::Result handle(const Expr *Inner, const ExplodedNode *InputNode,
  const ExplodedNode *LVNode,
  TrackingOptions Opts) override {
-ProgramStateRef LVState = LVNode->getState();
-const StackFrameContext *SFC = LVNode->getStackFrame();
 PathSensitiveBugReport &Report = getParentTracker().getReport();
-Tracker::Result Result;
 
 // We only track expressions if we believe that they are important. Chances
 // are good that control dependencies to the tracking point are also
@@ -2108,14 +2105,31 @@
 // this point.
 // TODO: Shouldn't we track control dependencies of every bug location,
 // rather than only tracked expressions?
-if (LVState->getAnalysisManager()
+if (LVNode->getState()
+->getAnalysisManager()
 .getAnalyzerOptions()
 .ShouldTrackConditions) {
   Report.addVisitor(
   &getParentTracker(), InputNode);
-  Result.FoundSomethingToTrack = true;
+  return {true};
 }
 
+return {};
+  }
+};
+
+class DefaultExpressionHandler final : public ExpressionHandler {
+public:
+  using ExpressionHandler::ExpressionHandler;
+
+  Tracker::Result handle(const Expr *Inner, const ExplodedNode *InputNode,
+ const ExplodedNode *LVNode,
+ TrackingOptions Opts) override {
+ProgramStateRef LVState = LVNode->getState();
+const StackFrameContext *SFC = LVNode->getStackFrame();
+PathSensitiveBugReport &Report = getParentTracker().getReport();
+Tracker::Result Result;
+
 // The message send could be nil due to the receiver being nil.
 // At this point in the path, the receiver should be live since we are at
 // the message send expr. If it is nil, start tracking it.
@@ -2297,7 +2311,8 @@
 
 Tracker::Tracker(PathSensitiveBugReport &Report) : Report(Report) {
   // Default expression handlers.
-  addHighPriorityHandler();
+  addLowPriorityHandler();
+  addLowPriorityHandler();
   addLowPriorityHandler();
   // Default store handlers.
   addHighPriorityHandler();


Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -2090,17 +2090,14 @@
   }
 };
 
-class DefaultExpressionHandler final : public ExpressionHandler {
+class ControlDependencyHandler final : public ExpressionHandler {
 public:
   using ExpressionHandler::ExpressionHandler;
 
   Tracker::Result handle(const Expr *Inner, const ExplodedNode *InputNode,
  const ExplodedNode *LVNode,
  TrackingOptions Opts) override {
-ProgramStateRef LVState = LVNode->getState();
-const StackFrameContext *SFC = LVNode->getStackFrame();
 PathSensitiveBugReport &Report = getParentTracker().getReport();
-Tracker::Result Result;
 
 // We only track expressions if we believe that they are important. Chances
 // are good that control dependencies to the tracking point are also
@@ -2108,14 +2105,31 @@
 // this point.
 // TODO: Shouldn't we track control dependencies of every bug location,
 // rather than only tracked expressions?
-if (LVState->getAnalysisManager()
+if (LVNode->getState()
+->getAnalysisManager()
 .getAnalyzerOptions()
 .ShouldTrackConditions) {
   Report.addVisitor(
   &getParentTracker(), InputNode);
-  Result.FoundSomethingToTrack = true;
+  return {true};
 }
 
+return {};
+  }
+};
+
+class DefaultExpressionHandler final : public ExpressionHandler {
+public:
+  using ExpressionHandler::ExpressionHandler;
+
+  Tracker::Result handle(const Expr *Inner, const ExplodedNode *InputNode,
+ const ExplodedNode *LVNode,
+ TrackingOptions Opts) override {
+ProgramStateRef LVState = LVNode->getSt

[PATCH] D103452: [clang] Fix reading long doubles with va_arg on x86_64 mingw

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added inline comments.



Comment at: clang/test/CodeGen/mingw-long-double.c:56-58
+  // GNU32: bitcast i8* %argp.cur to x86_fp80*
+  // GNU64: bitcast i8* %argp.cur to x86_fp80**
+  // MSC64: bitcast i8* %argp.cur to double*

rnk wrote:
> These tests will stop working after opaque pointers happens, which I hope 
> comes in the next year. If you look for a load of the pointer type, that 
> should be resilient to opaque pointers.
Hmm, good point, but the test feels more brittle to me in that form:

```
  // GNU32: load x86_fp80, x86_fp80*
  // GNU64: load x86_fp80*, x86_fp80**
  // GNU64: load x86_fp80, x86_fp80*
  // MSC64: load double, double*
```

That wouldn't notice if GNU32 also used an indirect pointer for this case (as 
it would still match the second load - but it would notice if GNU64 stopped 
using an indirect pointer as the first load wouldn't be matched). I guess it'd 
be safer if I'd use more named regex patterns in the test to follow the chain 
from the argp, but then we end up with a pattern covering the bits that change 
due to opaque pointers too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103452

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

[PATCH] D102853: [OpenCL] Align definition of __IMAGE_SUPPORT__ feature macro with OpenCL version and __opencl_c_images feature macro definition

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov added a comment.

In D102853#2773890 , @Anastasia wrote:

> LGTM! Although I think it would be better if we set `__IMAGE_SUPPORT__` 
> conditionally also for earlier OpenCL versions.

It has always been defined for SPIR target only. Should we wait for spec fix 
before merging this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102853

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

[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Manas Gupta via Phabricator via cfe-commits]

manas added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:282
+
+if (c >= -20 && d >= -40) {
+  clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}

vsavchenko wrote:
> manas wrote:
> > vsavchenko wrote:
> > > Great, it's good to check negative numbers.
> > > I have one note here.  The fact that we don't have a testing framework 
> > > and use this approach of inspecting the actual analysis has an 
> > > interesting implication.
> > > 
> > > ```
> > > if (a == 10) { // here we split path into 2 paths: one where a == 10, and 
> > > one where a != 10;
> > >// one goes inside of if, one doesn't
> > >   . . .
> > > }
> > > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and a in [5, 
> > > 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> > >   // 1 path was infeasible: a == 10 and a < 5
> > >   // Two of these paths go inside of the if, one doesn't
> > >   . . .
> > >   clang_analyzer_eval(a == 10); // it will produce two results: TRUE and 
> > > FALSE
> > > }
> > > clang_analyzer_eval(a == 10); // it will produce three results: TRUE, 
> > > FALSE, and FALSE
> > > ```
> > > 
> > > We don't want to test how path splitting works in these particular tests 
> > > (they are about solver and constant folding after all), that's why we try 
> > > to have only one path going through each `clang_analyzer_eval(...)`
> > > 
> > > In this example, you still have residual paths where `c != INT_MIN`, `c 
> > > == INT_MIN and d != INT_MIN`, and `c == INT_MIN and d == INT_MIN`.
> > I should add tests for these paths as well so that these can be checked. 
> > For further cases, I will enforce single path evaluation in test cases 
> > (which will make it easier to handle here).
> In these tests we should really avoid having multiple feasible paths going 
> through one `clang_analyzer_eval`.  We can add `// expected-warning` to it 
> multiple times, but it's harder to understand as a reader of these tests 
> because you need to split all the paths in your mind just like the analyzer 
> does.  It can be useful when testing other features of the analyzer, but here 
> it's not essential.
> 
> And I don't think that you fully understood me.  When multiple paths go 
> through `clang_analyzer_eval`, each of them produces a separate "warning".
> That's why if you want to account for residual paths, you shouldn't add more 
> `if` statements, but add something like:
> ```
> clang_analyzer_eval(a == 10); // expected-warning{{TRUE}}
>   // expected-warning@-1{{TRUE}}
>   // expected-warning@-2{{FALSE}}
> ```
> 
> So, please, instead of writing tests like this, rewrite your test, so that we 
> don't have residual paths.
Understood. I am changing those for single path evaluation accordingly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

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

[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

[Manas Gupta via Phabricator via cfe-commits]

manas updated this revision to Diff 349796.
manas added a comment.

Fix for cases involving residual paths and add case for overflowing range near 
extremum of a type


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

Files:
  clang/test/Analysis/constant-folding.c


Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -251,3 +251,83 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testAdditionRules(unsigned int a, unsigned int b, int c, int d) {
+  if (a == 0) {
+clang_analyzer_eval((a + 0) == 0); // expected-warning{{TRUE}}
+  }
+
+  // Checks for unsigned operands
+  clang_analyzer_eval((a + b) < 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((a + b) <= UINT_MAX); // expected-warning{{TRUE}}
+
+  if (a == UINT_MAX && b == UINT_MAX) {
+clang_analyzer_eval((a + b) == UINT_MAX - 1); // expected-warning{{TRUE}}
+  }
+
+  // Checks for inclusive ranges for unsigned integers
+  if (a >= 0 && a <= 10 && b >= 0 && b <= 20) {
+clang_analyzer_eval((a + b) >= 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((a + b) > 30); // expected-warning{{FALSE}}
+  }
+
+  // Checks for negative signed integers
+  if (c < 0 && d < 0) {
+clang_analyzer_eval((c + d) < 0); // expected-warning{{UNKNOWN}}
+  }
+
+  if (c < 0 && c != INT_MIN && d < 0) {
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) <= -2); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= 1); // expected-warning{{UNKNOWN}}
+  }
+
+  if (c == INT_MIN && d == INT_MIN) {
+clang_analyzer_eval((c + d) == 0); // expected-warning{{TRUE}}
+  }
+
+  if (c == INT_MIN && d < 0 && d != INT_MIN) {
+clang_analyzer_eval((c + d) > 0); // expected-warning{{TRUE}}
+  }
+
+  if (c < 0 && c >= -20 && d < 0 && d >= -40) {
+clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) >= -60); // expected-warning{{TRUE}}
+  }
+
+  // Checks for integers with different sign bits
+  if (c < 0 && d > 0) {
+if (c >= -20 && d <= 10) {
+  clang_analyzer_eval((c + d) > -20); // expected-warning{{TRUE}}
+  clang_analyzer_eval((c + d) < 10); // expected-warning{{TRUE}}
+}
+  }
+
+  // Checks for overlapping signed integers ranges
+  if (c >= -20 && c <= 20 && d >= -10 && d <= 10) {
+clang_analyzer_eval((c + d) >= -30); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) <= 30); // expected-warning{{TRUE}}
+  }
+
+  // Checks for positive signed integers
+  if (c > 0 && d > 0) {
+clang_analyzer_eval((c + d) == 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) > 1); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) < -1); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks producing overflowing range with different signs
+  int HALF_INT_MAX = INT_MAX / 2;
+  if (c >= HALF_INT_MAX - 10 && c <= HALF_INT_MAX + 10 &&
+  d >= HALF_INT_MAX - 10 && d <= HALF_INT_MAX + 10) {
+// The resulting range for (c + d) will be:
+//   [INT_MIN, INT_MIN + 18] U [INT_MAX - 21, INT_MAX]
+clang_analyzer_eval((c + d) <= INT_MIN + 18); // 
expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= INT_MAX - 21); // 
expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) == INT_MIN + 19); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == INT_MAX - 22); // expected-warning{{FALSE}}
+  }
+}


Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -251,3 +251,83 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testAdditionRules(unsigned int a, unsigned int b, int c, int d) {
+  if (a == 0) {
+clang_analyzer_eval((a + 0) == 0); // expected-warning{{TRUE}}
+  }
+
+  // Checks for unsigned operands
+  clang_analyzer_eval((a + b) < 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((a + b) <= UINT_MAX); // expected-warning{{TRUE}}
+
+  if (a == UINT_MAX && b == UINT_MAX) {
+clang_analyzer_eval((a + b) == UINT_MAX - 1); // expected-warning{{TRUE}}
+  }
+
+  // Checks for inclusive ranges for unsigned integers
+  if (a >= 0 && a <= 10 && b >= 0 && b <= 20) {
+clang_analyzer_eval((a + b) >= 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((a + b) > 30); // expected-warning{{FALSE}}
+  }
+
+  // Checks for negative signed integers
+  if (c < 0 && d < 0) {
+clang_analyzer_eval((c + d) <

[PATCH] D103317: [Analyzer][engine][solver] Simplify complex constraints

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D103317#2794099 , @ASDenysPetrov 
wrote:

>> ! In D103317#2793797 , @vsavchenko 
>> wrote:
>
>
>
>> I replied to you earlier that assignments are not producing constraints.  
>> The analyzer has some sort of SSA (not really, but anyways), so every time 
>> we reassign the variable it actually becomes a different symbol. So, from 
>> this perspective `DeclRefExpr` `x` and symbol `x` are two different things:
>>
>>   int x = foo(); // after this DeclRefExpr and VarDecl x are associated with 
>> conjured symbol #1 (aka conj#1)
>>   int c = x + 10; // c is associated with `$conj#1 + 10`
>>   x = a + 1; // DeclRefExpr x is now associated with `$a + 1`
>>   x = c + x; // and now it is `conj#1 + 11`
>>
>> There is no symbolic assignment in the static analyzer.  Symbols are values, 
>> values don't change.  We can only obtain more information of what particular 
>> symbolic value represents.
>>
>> I hope it makes it more clear.
>>
>> As for equality, we already track equivalence classes of symbols and they 
>> can have more than 2 symbols in them.  Actually, this whole data structure 
>> mostly makes sense for cases when the class has more than 2 elements in it.
>
> Thanks for the clarifications.
>
> I'm trying to say that we need to keep our attention on 
> assignments/initializations as well if we want to solve this problem 
> efficiently. I didn't say that assignments produce constraints. Of course 
> they do not :-). I want we produce more //bindings(associations)// on 
> //assignments// to use them as mapping for further substitutions and 
> traversing to get the right range.
>
> As for the equivalence classes. I think we should go away from special cases. 
> I mean what about lower-then classes or greater-or-equal classes. I think you 
> got what I mean. I'm trying to find a general approach which can cover almost 
> all individual improvements around CSA codebase(about ranges).
>
> I started working on this when saw your discussion. Just what you also 
> consider the direction I'm moving. A lot of corner-examples, like you gave 
> me, are welcome. Thank you for the feedbacks!

Thank you for your comments Denys! It's great to see that some else is also 
bothered by these problems, and the more approaches we have the deeper the 
overall understanding is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103317

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

[PATCH] D103678: [Format] Fix incorrect pointer/reference detection

[Yilong Guo via Phabricator via cfe-commits]

Nuu created this revision.
Nuu added reviewers: djasper, HazardyKnusperkeks, curdeius, MyDeveloperDay.
Nuu added a project: clang-format.
Nuu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

https://llvm.org/PR50568

When an overloaded operator is called, its argument must be an
expression.

Before:

  void f() { a.operator()(a *a); }

After:

  void f() { a.operator()(a * a); }

Signed-off-by: Yilong Guo 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103678

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
@@ -8761,6 +8761,11 @@
"operator()() && {}");
   verifyGoogleFormat("template \n"
  "auto x() & -> int {}");
+
+  // Should be binary operators when used as an argument expression (overloaded
+  // operator invoked as a member function)
+  verifyFormat("void f() { a.operator()(a * a); }");
+  verifyFormat("void f() { a->operator()(a & a); }");
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -229,7 +229,19 @@
 }
 
 if (Left->is(TT_OverloadedOperatorLParen)) {
-  Contexts.back().IsExpression = false;
+  // Find the previous kw_operator token
+  FormatToken *Prev = Left;
+  while (!Prev->is(tok::kw_operator)) {
+Prev = Prev->Previous;
+assert(Prev);
+  }
+
+  // If faced with "a.operator*(argument)" or "a->operator*(argument)"
+  // i.e. the operator is called as a member function
+  // then the argument must be an expression
+  bool OperatorCalledAsMemberFunction =
+  Prev->Previous && Prev->Previous->isOneOf(tok::period, tok::arrow);
+  Contexts.back().IsExpression = OperatorCalledAsMemberFunction;
 } else if (Style.Language == FormatStyle::LK_JavaScript &&
(Line.startsWith(Keywords.kw_type, tok::identifier) ||
 Line.startsWith(tok::kw_export, Keywords.kw_type,


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8761,6 +8761,11 @@
"operator()() && {}");
   verifyGoogleFormat("template \n"
  "auto x() & -> int {}");
+
+  // Should be binary operators when used as an argument expression (overloaded
+  // operator invoked as a member function)
+  verifyFormat("void f() { a.operator()(a * a); }");
+  verifyFormat("void f() { a->operator()(a & a); }");
 }
 
 TEST_F(FormatTest, UnderstandsAttributes) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -229,7 +229,19 @@
 }
 
 if (Left->is(TT_OverloadedOperatorLParen)) {
-  Contexts.back().IsExpression = false;
+  // Find the previous kw_operator token
+  FormatToken *Prev = Left;
+  while (!Prev->is(tok::kw_operator)) {
+Prev = Prev->Previous;
+assert(Prev);
+  }
+
+  // If faced with "a.operator*(argument)" or "a->operator*(argument)"
+  // i.e. the operator is called as a member function
+  // then the argument must be an expression
+  bool OperatorCalledAsMemberFunction =
+  Prev->Previous && Prev->Previous->isOneOf(tok::period, tok::arrow);
+  Contexts.back().IsExpression = OperatorCalledAsMemberFunction;
 } else if (Style.Language == FormatStyle::LK_JavaScript &&
(Line.startsWith(Keywords.kw_type, tok::identifier) ||
 Line.startsWith(tok::kw_export, Keywords.kw_type,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103317: [Analyzer][engine][solver] Simplify complex constraints

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103317#2794099 , @ASDenysPetrov 
wrote:

>> ! In D103317#2793797 , @vsavchenko 
>> wrote:
>
>
>
>> I replied to you earlier that assignments are not producing constraints.  
>> The analyzer has some sort of SSA (not really, but anyways), so every time 
>> we reassign the variable it actually becomes a different symbol. So, from 
>> this perspective `DeclRefExpr` `x` and symbol `x` are two different things:
>>
>>   int x = foo(); // after this DeclRefExpr and VarDecl x are associated with 
>> conjured symbol #1 (aka conj#1)
>>   int c = x + 10; // c is associated with `$conj#1 + 10`
>>   x = a + 1; // DeclRefExpr x is now associated with `$a + 1`
>>   x = c + x; // and now it is `conj#1 + 11`
>>
>> There is no symbolic assignment in the static analyzer.  Symbols are values, 
>> values don't change.  We can only obtain more information of what particular 
>> symbolic value represents.
>>
>> I hope it makes it more clear.
>>
>> As for equality, we already track equivalence classes of symbols and they 
>> can have more than 2 symbols in them.  Actually, this whole data structure 
>> mostly makes sense for cases when the class has more than 2 elements in it.
>
> Thanks for the clarifications.
>
> I'm trying to say that we need to keep our attention on 
> assignments/initializations as well if we want to solve this problem 
> efficiently. I didn't say that assignments produce constraints. Of course 
> they do not :-). I want we produce more //bindings(associations)// on 
> //assignments// to use them as mapping for further substitutions and 
> traversing to get the right range.
>
> As for the equivalence classes. I think we should go away from special cases. 
> I mean what about lower-then classes or greater-or-equal classes. I think you 
> got what I mean. I'm trying to find a general approach which can cover almost 
> all individual improvements around CSA codebase(about ranges).
>
> I started working on this when saw your discussion. Just what you also 
> consider the direction I'm moving. A lot of corner-examples, like you gave 
> me, are welcome. Thank you for the feedbacks!

Assignments and initializations don't affect anything, we shouldn't care about 
them at all because they don't affect symbolic values in any way.  You keep 
bringing up assignments/initializations when I repeatedly tell you that these 
are orthogonal to symbolic values, they simply associate certain symbolic 
values/expressions with memory regions (aka bind them).

I want to make sure you understand that there is no silver bullet here.  There 
is no one magic method that will resolve everything in polynomial let alone 
linear time (unless someone proves that NP = P).  This problem is inherently 
exponential.  We try to avoid it at all costs (and, thus, suck sometimes).
In general, when SMT-solvers need to solve a set of bit-vector equations, they 
use a technique called **bit blasting** - just turning each n-bit integer into 
n-separate boolean variables, and using SAT solver after that.  More advanced 
solvers use special theories before to reduce dimensionality of the problem, 
one of them is equality theory.  These theories are not limitations or "special 
cases", they are pieces of fundamental knowledge about the domain.  Those are 
as generic as you can go.  One symbolic expression can be equal to multiple 
symbolic expressions at the same time, it is the fact, not a special case.

I'm sorry for being too harsh here, but this problem IS harder than you think.  
If you want to approach it correctly, and not waste your time, you should get 
these fundamentals straight.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103317

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

[PATCH] D103605: [analyzer] Introduce a new interface for tracking

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103605#2798171 , @NoQ wrote:

> Ok. Oof. Whoa. That's amazing.
>
> Let me re-iterate to make sure that my understanding of this patchset is 
> correct.
>
> **Chapter 1.** //"A is correlated with B (ρ = 0.56), given C, assuming D and 
> under E conditions"//
>
> - Two new entities are introduced: trackers and handlers.

Correct.

> - Trackers are attached to bug reports. A single bug report may have multiple 
> trackers.
>   - Why not have only one tracker per report?

That's a good question, we can actually even make it a part of `BugReport` for 
that matter.  I can though think of one exotic case, where you wait till you 
encounter certain weird condition, where you need to spawn a very specific 
customized tracker only starting from that point.

> - Handlers are attached to trackers. Each tracker can have multiple handlers 
> with a priority system.
>   - Do you envision it growing into a dependency system later?

Yes, I think in order to correctly split some parts of the logic that already 
exists in `trackExpressionValue`

> - A subclass of visitors known as "tracking visitors" are connected to 
> trackers. One tracker may have multiple visitors attached to it.

Correct.

> - Trackers are a tiny, almost uncustomizable class. It contains is a method 
> called `track()` that is invoked when attention of handlers is required.

Correct.  If you really want to, you can change the default behavior of those 
track functions.

> - Each tracker comes with a default set of handlers.

Correct.  This is how we migrate existing functionality into the new interface.

> - The only way to customize a tracker is to add extra handlers to it.

It's not the only one, you can subclass it and add completely different logic.  
But the main way for the majority of use cases is indeed through handlers.

> - Handlers implement a `handle()` method invoked by the tracker every time 
> their attention is required in `track()`.

Correct.

> - Handlers may return a note from their `handle()` method. If a handler 
> returns a note, this note is attached to the bug report and lower-priority 
> handlers are not invoked at all.

Not entirely correct, this is correct for store handlers, these are intended to 
customize messages for events of symbolic value being stored into the region.
Expression handlers return `Tracker::Result` that simply tells if some visitor 
was added or not (backward compatibility with `trackExpressionValue`) and if we 
should prevent all other handlers from running here.

> - There are two major classes of handlers: expression handlers and store 
> handlers. Expression handlers pay attention to Environment entries, store 
> handlers pay attention to Region Store bindings.

I would say that expression handler is a way to externally extend 
`trackExpressionValue` functionality.  Add new supported type of expression 
that we can track or add checker-specific visitor recursively.

> **Chapter 2.** //"For immediate release: Scientists find potential link 
> between A and B"//
>
> - Bug visitors are still responsible for discovering connections across 
> exploded nodes. On the contrary, `track()`/`handle()` workflow is 
> instantaneous.

It is tricky because `track` can add visitors and they can call it back from 
`VisitNode`, and so on to infinity.  This is a pattern that we had between 
`trackExpressionValue` and `FindLastBRVisitor` (and `ReturnVisitor`) and every 
checker can create their own recursive tracking.

> - It sounds like this whole patchset is orthogonal to reimplementing value 
> tracking visitors with note tags, as long as we can pass a reference to the 
> appropriate tracker into the tag(?)

Correct, it just makes existing back-slicing tracking easier to customize.

> - Tracking starts when a checker creates a tracker and invokes `track()` on 
> it, which instantly causes the respective `handle()` to be invoked.
> - `handle()` may attach visitors. These visitors may in turn call `track()` 
> as they reach a different exploded node.

Exactly.

> - The termination condition is as usual: no further visitors attached.
>   - It sounds like this patchset is orthogonal to the problem of detecting 
> the tracking termination point(?) It does make it easier to implement 
> customized reactions to such termination though.

Actually, tracker dies when this happens.  But hey, can you provide a use case 
when the checker really needs to know when this happens?

> **Chapter 3.** //"A causes B all the time. What will this means for Obama?"//
>
> - `trackExpressionValue()` now boils down to creation of a single tracker and 
> an initial invocation of `track()` on the expression which in turn causes 
> expression handlers to immediately react.

Correct.

> - Most of the old body of `trackExpressionValue()` is transformed into a 
> default expression handler. So it's still part of an immediate reaction, just 
> a bit more generalized.

Correct.

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Brendon Cahoon via Phabricator via cfe-commits]

bcahoon created this revision.
bcahoon added reviewers: rampitec, kzhuravl.
Herald added subscribers: foad, dexonsmith, kerbowa, rupprecht, jfb, hiraditya, 
t-tye, tpr, dstuttard, yaxunl, nhaehnle, jvesely, emaste, arsenm, jholewinski.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
bcahoon requested review of this revision.
Herald added subscribers: llvm-commits, openmp-commits, cfe-commits, wdng.
Herald added projects: clang, OpenMP, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103663

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/AMDGPU.td
  llvm/lib/Target/AMDGPU/AMDGPUSubtarget.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/GCNSubtarget.h
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
  llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
  llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll
  llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/CodeGen/AMDGPU/llvm.amdgcn.intersect_ray.ll
  llvm/test/MC/AMDGPU/dl-insts-err.s
  llvm/test/MC/AMDGPU/gfx10_unsupported.s
  llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
  llvm/tools/llvm-readobj/ELFDumper.cpp
  openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp

Index: openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
===
--- openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
+++ openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
@@ -39,6 +39,8 @@
 return "gfx1011";
   case EF_AMDGPU_MACH_AMDGCN_GFX1012:
 return "gfx1012";
+  case EF_AMDGPU_MACH_AMDGCN_GFX1013:
+return "gfx1013";
   case EF_AMDGPU_MACH_AMDGCN_GFX1030:
 return "gfx1030";
   case EF_AMDGPU_MACH_AMDGCN_GFX1031:
Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1482,6 +1482,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1010),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1011),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1012),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1013),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1030),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1031),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
@@ -1534,6 +1535,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1010),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1011),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1012),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1013),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1030),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1031),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -223,6 +223,15 @@
 # RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1012
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1012 -DFLAG_VALUE=0x35
 
+# RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1013
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1013 -DFLAG_VALUE=0x42
+
+# RUN: yaml2obj %s -o %t -DABI_VERSION=1 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1013
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=1 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1013 -DFLAG_VALUE=0x42
+
+# RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1013
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_

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

[Khem Raj via Phabricator via cfe-commits]

raj.khem added a comment.

http://sprunge.us/FJzZXL is a file from harfbuzz and it warns

  a.cc:28670:32: error: variable 'supp_size' set but not used 
[-Werror,-Wunused-but-set-variable]
  unsigned int size0, size1, supp_size = 0;

I do not have -Werror enabled but it still is reported as error. There is no 
way to disable this warning ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

___
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

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

In D100581#2798079 , @raj.khem wrote:

> http://sprunge.us/FJzZXL is a file from harfbuzz and it warns
>
>   a.cc:28670:32: error: variable 'supp_size' set but not used 
> [-Werror,-Wunused-but-set-variable]
>   unsigned int size0, size1, supp_size = 0;
>
> I do not have -Werror enabled but it still is reported as error. There is no 
> way to disable this warning ?

Well, you have

>> #pragma GCC diagnostic error "-Wunused"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

___
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

[Andi via Phabricator via cfe-commits]

Abpostelnicu added a comment.

In D100581#2798079 , @raj.khem wrote:

> http://sprunge.us/FJzZXL is a file from harfbuzz and it warns
>
>   a.cc:28670:32: error: variable 'supp_size' set but not used 
> [-Werror,-Wunused-but-set-variable]
>   unsigned int size0, size1, supp_size = 0;

You have, with pragma gcc error, look at hb.hh. The problem is that clang has 
an error dealing with cascading pragma when setting different levels.

> I do not have -Werror enabled but it still is reported as error. There is no 
> way to disable this warning ?

Go to the hb GitHub repo, I’ve fixed this in master branch, it will propagate 
soon to a new release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Jay Foad via Phabricator via cfe-commits]

foad added a comment.

Please also update `llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103663

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

[PATCH] D103663: [AMDGPU] Add gfx1013 target

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: llvm/docs/AMDGPUUsage.rst:389
 - xnack 
scratch   - *pal-amdpal*
+ ``gfx1013`` ``amdgcn``   dGPU  - cumode  - 
Absolute  - *rocm-amdhsa* *TBA*
+- wavefrontsize64   flat   
   - *pal-amdhsa*

Is it dGPU or APU?

Every other entry with `*TBA*` also has a `TODO::` message



Comment at: llvm/lib/Target/AMDGPU/AMDGPU.td:468
 
+def FeatureGFX10_AEncoding : SubtargetFeature<"gfx10_a-encoding",
+  "GFX10_AEncoding",

What is this new encoding? It doesn't seem to be used for anything.



Comment at: llvm/lib/Target/AMDGPU/GCNSubtarget.h:879
+  }
+  
   bool hasGFX10_BEncoding() const {

Stray whitespace on this line.



Comment at: llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp:1453
+}
+  
 bool isGFX10_BEncoding(const MCSubtargetInfo &STI) {

Stray whitespace.



Comment at: llvm/test/CodeGen/AMDGPU/GlobalISel/llvm.amdgcn.intersect_ray.ll:4
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
+; RUN: llc -global-isel -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s 
| FileCheck -check-prefix=GCN %s
 

This test surely should not pass for gfx1012, since it does not have these 
instructions. And with your patch as written it should fail for gfx1013 too, 
since they are predicated on HasGFX10_BEncoding.

@rampitec any idea what is wrong here? Apparently the backend will happily 
generate image_bvh_intersect_ray instructions even for gfx900!



Comment at: llvm/test/CodeGen/AMDGPU/llvm.amdgcn.intersect_ray.ll:3
+; RUN: llc -march=amdgcn -mcpu=gfx1013 -verify-machineinstrs < %s | FileCheck 
-check-prefix=GCN %s
+; RUN: llc -march=amdgcn -mcpu=gfx1012 -verify-machineinstrs < %s | FileCheck 
-check-prefix=GCN %s
 

Likewise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103663

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

[PATCH] D103685: [clangd] Drop TestTUs dependency on gtest

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

TestTU now prints errors to llvm::errs and aborts on failures via
llvm_unreachable, rather than executing ASSERT_FALSE.

We'd like to make use of these testing libraries in different test suits that
might be compiling with a different gtest version than LLVM has.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D103685

Files:
  clang-tools-extra/clangd/index/Symbol.cpp
  clang-tools-extra/clangd/index/Symbol.h
  clang-tools-extra/clangd/unittests/TestTU.cpp

Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -17,7 +17,9 @@
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/Utils.h"
 #include "llvm/ADT/ScopeExit.h"
-#include "gtest/gtest.h"
+#include "llvm/Support/ErrorHandling.h"
+#include "llvm/Support/ScopedPrinter.h"
+#include "llvm/Support/raw_ostream.h"
 
 namespace clang {
 namespace clangd {
@@ -69,14 +71,15 @@
 
 void initializeModuleCache(CompilerInvocation &CI) {
   llvm::SmallString<128> ModuleCachePath;
-  ASSERT_FALSE(
-  llvm::sys::fs::createUniqueDirectory("module-cache", ModuleCachePath));
+  if (llvm::sys::fs::createUniqueDirectory("module-cache", ModuleCachePath))
+llvm_unreachable("Failed to create temp directory for module-cache");
   CI.getHeaderSearchOpts().ModuleCachePath = ModuleCachePath.c_str();
 }
 
 void deleteModuleCache(const std::string ModuleCachePath) {
   if (!ModuleCachePath.empty()) {
-ASSERT_FALSE(llvm::sys::fs::remove_directories(ModuleCachePath));
+if (llvm::sys::fs::remove_directories(ModuleCachePath))
+  llvm_unreachable("Failed to delete temp directory for module-cache");
   }
 }
 
@@ -112,12 +115,12 @@
   auto AST = ParsedAST::build(testPath(Filename), Inputs, std::move(CI),
   Diags.take(), Preamble);
   if (!AST.hasValue()) {
-ADD_FAILURE() << "Failed to build code:\n" << Code;
+llvm::errs() << "Failed to build code:\n" << Code;
 llvm_unreachable("Failed to build TestTU!");
   }
   if (!AST->getDiagnostics()) {
-ADD_FAILURE() << "TestTU should always build an AST with a fresh Preamble"
-  << Code;
+llvm::errs() << "TestTU should always build an AST with a fresh Preamble"
+ << Code;
 return std::move(*AST);
   }
   // Check for error diagnostics and report gtest failures (unless expected).
@@ -138,7 +141,7 @@
 // We always build AST with a fresh preamble in TestTU.
 for (const auto &D : *AST->getDiagnostics())
   if (D.Severity >= DiagnosticsEngine::Error) {
-ADD_FAILURE()
+llvm::errs()
 << "TestTU failed to build (suppress with /*error-ok*/): \n"
 << D << "\n\nFor code:\n"
 << Code;
@@ -176,16 +179,16 @@
 if (QName != (S.Scope + S.Name).str())
   continue;
 if (Result) {
-  ADD_FAILURE() << "Multiple symbols named " << QName << ":\n"
-<< *Result << "\n---\n"
-<< S;
+  llvm::errs() << "Multiple symbols named " << QName << ":\n"
+   << *Result << "\n---\n"
+   << S;
   assert(false && "QName is not unique");
 }
 Result = &S;
   }
   if (!Result) {
-ADD_FAILURE() << "No symbol named " << QName << " in "
-  << ::testing::PrintToString(Slab);
+llvm::errs() << "No symbol named " << QName << " in "
+ << llvm::to_string(Slab);
 assert(false && "No symbol with QName");
   }
   return *Result;
@@ -225,7 +228,7 @@
   Visitor.F = Filter;
   Visitor.TraverseDecl(AST.getASTContext().getTranslationUnitDecl());
   if (Visitor.Decls.size() != 1) {
-ADD_FAILURE() << Visitor.Decls.size() << " symbols matched.";
+llvm::errs() << Visitor.Decls.size() << " symbols matched.";
 assert(Visitor.Decls.size() == 1);
   }
   return *Visitor.Decls.front();
Index: clang-tools-extra/clangd/index/Symbol.h
===
--- clang-tools-extra/clangd/index/Symbol.h
+++ clang-tools-extra/clangd/index/Symbol.h
@@ -233,6 +233,8 @@
   std::vector Symbols;  // Sorted by SymbolID to allow lookup.
 };
 
+llvm::raw_ostream &operator<<(llvm::raw_ostream &OS, const SymbolSlab &Slab);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/index/Symbol.cpp
===
--- clang-tools-extra/clangd/index/Symbol.cpp
+++ clang-tools-extra/clangd/index/Symbol.cpp
@@ -67,5 +67,15 @@
   return SymbolSlab(std::move(NewArena), std::move(SortedSymbols));
 }
 
+llvm::raw_ostream &operator<<(l

[PATCH] D103678: [Format] Fix incorrect pointer/reference detection

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:8768
+  verifyFormat("void f() { a.operator()(a * a); }");
+  verifyFormat("void f() { a->operator()(a & a); }");
 }

can you add

void f() { a.operator()(*a * *a); }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103678

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

[PATCH] D103678: [Format] Fix incorrect pointer/reference detection

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:243
+  bool OperatorCalledAsMemberFunction =
+  Prev->Previous && Prev->Previous->isOneOf(tok::period, tok::arrow);
+  Contexts.back().IsExpression = OperatorCalledAsMemberFunction;

feels like we are not testing this situation, please add those tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103678

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

[PATCH] D103665: [Clang][OpenMP] Add static version of getSingleClause. NFC.

[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/D103665/new/

https://reviews.llvm.org/D103665

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

[PATCH] D103666: [Clang][OpenMP] Refactor checking for mutually exclusive clauses. NFC.

[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/D103666/new/

https://reviews.llvm.org/D103666

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

[PATCH] D101696: [Matrix] Implement C-style explicit type conversions in CXX for matrix types

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

Perhaps for bonus points, update the Clang documentation in 
https://clang.llvm.org/docs/LanguageExtensions.html#matrix-types with some 
examples?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101696

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

[PATCH] D103664: [Windows SEH]: Fix -O2 crash for Windows -EHa

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

Thanks for the quick fix! Would you mind fixing the two failing tests please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103664

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

[PATCH] D103082: [AArch64][SVE] Improve codegen for dupq SVE ACLE intrinsics

[Bradley Smith via Phabricator via cfe-commits]

bsmith updated this revision to Diff 349827.
bsmith marked an inline comment as done.
bsmith added a comment.

- Remove unnecessary complexity when zero-extending dupq operands into a vector.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103082

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq-bfloat.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq_const.c
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
  llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll

Index: llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-cmpne.ll
@@ -0,0 +1,397 @@
+; RUN: opt -S -instcombine < %s | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
+
+; DUPQ b8
+
+define  @dupq_b_0() #0 {
+; CHECK-LABEL: @dupq_b_0(
+; CHECK: ret  zeroinitializer
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv16i8.v16i8( undef,
+<16 x i8> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv16i8( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv16i8( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_b_d() #0 {
+; CHECK-LABEL: @dupq_b_d(
+; CHECK: %1 = call  @llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
+; CHECK-NEXT: %2 = call  @llvm.aarch64.sve.convert.to.svbool.nxv2i1( %1)
+; CHECK-NEXT: ret  %2
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv16i8.v16i8( undef,
+<16 x i8> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv16i8( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv16i8( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_b_w() #0 {
+; CHECK-LABEL: @dupq_b_w(
+; CHECK: %1 = call  @llvm.aarch64.sve.ptrue.nxv4i1(i32 31)
+; CHECK-NEXT: %2 = call  @llvm.aarch64.sve.convert.to.svbool.nxv4i1( %1)
+; CHECK-NEXT: ret  %2
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv16i8.v16i8( undef,
+<16 x i8> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv16i8( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv16i8( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_b_h() #0 {
+; CHECK-LABEL: @dupq_b_h(
+; CHECK: %1 = call  @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
+; CHECK-NEXT: %2 = call  @llvm.aarch64.sve.convert.to.svbool.nxv8i1( %1)
+; CHECK-NEXT: ret  %2
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv16i8.v16i8( undef,
+<16 x i8> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv16i8( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv16i8( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_b_b() #0 {
+; CHECK-LABEL: @dupq_b_b(
+; CHECK: %1 = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+; CHECK-NEXT: ret  %1
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv16i8.v16i8( undef,
+<16 x i8> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv16i8( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv16i8( %1,  %3,  %4)
+  ret  %5
+}
+
+; DUPQ b16
+
+define  @dupq_h_0() #0 {
+; CHECK-LABEL: @dupq_h_0(
+; CHECK: ret  zeroinitializer
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv8i16.v8i16( undef,
+<8 x i16> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv8i16( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv8i16( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_h_d() #0 {
+; CHECK-LABEL: @dupq_h_d(
+; CHECK: %1 = call  @llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
+; CHECK-NEXT: %2 = call  @llvm.aarch64.sve.convert.to.svbool.nxv2i1( %1)
+; CHECK-NEXT: %3 = call  @llvm.aarch64.sve.convert.from.svbool.nxv8i1( %2)
+; CHECK-NEXT: ret  %3
+  %1 = tail call  @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
+  %2 = tail call  @llvm.experimental.vector.insert.nxv8i16.v8i16( undef,
+<8 x i16> , i64 0)
+  %3 = tail call  @llvm.aarch64.sve.dupq.lane.nxv8i16( %2 , i64 0)
+  %4 = tail call  @llvm.aarch64.sve.dup.x.nxv2i64(i64 0)
+  %5 = tail call  @llvm.aarch64.sve.cmpne.wide.nxv8i16( %1,  %3,  %4)
+  ret  %5
+}
+
+define  @dupq_h_w() #0 {
+; CHECK-LABEL: @dupq_h_w(
+; CHECK: %1 = call  @l

Re: [PATCH] D101696: [Matrix] Implement C-style explicit type conversions in CXX for matrix types

[Saurabh Jha via cfe-commits]

For sure, will do.

On Fri, Jun 4, 2021 at 12:59 PM Sjoerd Meijer via Phabricator <
revi...@reviews.llvm.org> wrote:

> SjoerdMeijer added a comment.
>
> Perhaps for bonus points, update the Clang documentation in
> https://clang.llvm.org/docs/LanguageExtensions.html#matrix-types with
> some examples?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D101696/new/
>
> https://reviews.llvm.org/D101696
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] ceb6238 - [clang][AST] Set correct DeclContext in ASTImporter lookup table for ParmVarDecl.

[Balázs Kéri via cfe-commits]

Author: Balázs Kéri
Date: 2021-06-04T14:24:44+02:00
New Revision: ceb62388f2d8bd8deed447ebfed77ac7d9be293d

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

LOG: [clang][AST] Set correct DeclContext in ASTImporter lookup table for 
ParmVarDecl.

ParmVarDecl is created with translation unit as the parent DeclContext
and later moved to the correct DeclContext. ASTImporterLookupTable
should be updated at this move.

Reviewed By: martong

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

Added: 


Modified: 
clang/include/clang/AST/ASTImporterLookupTable.h
clang/lib/AST/ASTImporter.cpp
clang/lib/AST/ASTImporterLookupTable.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTImporterLookupTable.h 
b/clang/include/clang/AST/ASTImporterLookupTable.h
index 407478a51058d..47dca20338393 100644
--- a/clang/include/clang/AST/ASTImporterLookupTable.h
+++ b/clang/include/clang/AST/ASTImporterLookupTable.h
@@ -63,8 +63,24 @@ class ASTImporterLookupTable {
   ASTImporterLookupTable(TranslationUnitDecl &TU);
   void add(NamedDecl *ND);
   void remove(NamedDecl *ND);
+  // Sometimes a declaration is created first with a temporarily value of decl
+  // context (often the translation unit) and later moved to the final context.
+  // This happens for declarations that are created before the final 
declaration
+  // context. In such cases the lookup table needs to be updated.
+  // (The declaration is in these cases not added to the temporary decl 
context,
+  // only its parent is set.)
+  // FIXME: It would be better to not add the declaration to the temporary
+  // context at all in the lookup table, but this requires big change in
+  // ASTImporter.
+  // The function should be called when the old context is definitely 
diff erent
+  // from the new.
+  void update(NamedDecl *ND, DeclContext *OldDC);
   using LookupResult = DeclList;
   LookupResult lookup(DeclContext *DC, DeclarationName Name) const;
+  // Check if the `ND` is within the lookup table (with its current name) in
+  // context `DC`. This is intended for debug purposes when the DeclContext of 
a
+  // NamedDecl is changed.
+  bool contains(DeclContext *DC, NamedDecl *ND) const;
   void dump(DeclContext *DC) const;
   void dump() const;
 };

diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index c0fc376157d2a..66f384ada1485 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3503,6 +3503,8 @@ ExpectedDecl 
ASTNodeImporter::VisitFunctionDecl(FunctionDecl *D) {
   for (auto *Param : Parameters) {
 Param->setOwningFunction(ToFunction);
 ToFunction->addDeclInternal(Param);
+if (ASTImporterLookupTable *LT = Importer.SharedState->getLookupTable())
+  LT->update(Param, Importer.getToContext().getTranslationUnitDecl());
   }
   ToFunction->setParams(Parameters);
 

diff  --git a/clang/lib/AST/ASTImporterLookupTable.cpp 
b/clang/lib/AST/ASTImporterLookupTable.cpp
index e17d6082dcdcc..b78cc0c053f60 100644
--- a/clang/lib/AST/ASTImporterLookupTable.cpp
+++ b/clang/lib/AST/ASTImporterLookupTable.cpp
@@ -117,6 +117,19 @@ void ASTImporterLookupTable::remove(NamedDecl *ND) {
 remove(ReDC, ND);
 }
 
+void ASTImporterLookupTable::update(NamedDecl *ND, DeclContext *OldDC) {
+  assert(OldDC != ND->getDeclContext() &&
+ "DeclContext should be changed before update");
+  if (contains(ND->getDeclContext(), ND)) {
+assert(!contains(OldDC, ND) &&
+   "Decl should not be found in the old context if already in the 
new");
+return;
+  }
+
+  remove(OldDC, ND);
+  add(ND);
+}
+
 ASTImporterLookupTable::LookupResult
 ASTImporterLookupTable::lookup(DeclContext *DC, DeclarationName Name) const {
   auto DCI = LookupTable.find(DC->getPrimaryContext());
@@ -131,6 +144,10 @@ ASTImporterLookupTable::lookup(DeclContext *DC, 
DeclarationName Name) const {
   return NamesI->second;
 }
 
+bool ASTImporterLookupTable::contains(DeclContext *DC, NamedDecl *ND) const {
+  return 0 < lookup(DC, ND->getDeclName()).count(ND);
+}
+
 void ASTImporterLookupTable::dump(DeclContext *DC) const {
   auto DCI = LookupTable.find(DC->getPrimaryContext());
   if (DCI == LookupTable.end())

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index db87b2ab5e9c0..4ed4a09b03b9a 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -5375,6 +5375,33 @@ TEST_P(ErrorHandlingTest, ImportOfOverriddenMethods) {
   CheckError(FromFooC);
 }
 
+TEST_P(ErrorHandlingTest, ODRViolationWithinParmVarDecls) {
+  // Importing of 'f' and parameter 'P' should cause an ODR error.
+  // The error happens after the ParmVarDecl for 'P' was already created.
+

[PATCH] D103231: [clang][AST] Set correct DeclContext in ASTImporter lookup table for ParmVarDecl.

[Balázs Kéri via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGceb62388f2d8: [clang][AST] Set correct DeclContext in 
ASTImporter lookup table for… (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103231

Files:
  clang/include/clang/AST/ASTImporterLookupTable.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTImporterLookupTable.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5375,6 +5375,33 @@
   CheckError(FromFooC);
 }
 
+TEST_P(ErrorHandlingTest, ODRViolationWithinParmVarDecls) {
+  // Importing of 'f' and parameter 'P' should cause an ODR error.
+  // The error happens after the ParmVarDecl for 'P' was already created.
+  // This is a special case because the ParmVarDecl has a temporary DeclContext.
+  // Expected is no crash at error handling of ASTImporter.
+  constexpr auto ToTUCode = R"(
+  struct X {
+char A;
+  };
+  )";
+  constexpr auto FromTUCode = R"(
+  struct X {
+enum Y { Z };
+  };
+  void f(int P = X::Z);
+  )";
+  Decl *ToTU = getToTuDecl(ToTUCode, Lang_CXX11);
+  static_cast(ToTU);
+  Decl *FromTU = getTuDecl(FromTUCode, Lang_CXX11);
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("f")));
+  ASSERT_TRUE(FromF);
+
+  auto *ImportedF = Import(FromF, Lang_CXX11);
+  EXPECT_FALSE(ImportedF);
+}
+
 TEST_P(ASTImporterOptionSpecificTestBase, LambdaInFunctionBody) {
   Decl *FromTU = getTuDecl(
   R"(
@@ -6192,6 +6219,21 @@
   ASSERT_TRUE(ToD);
 }
 
+TEST_P(ImportFunctions, ParmVarDeclDeclContext) {
+  constexpr auto FromTUCode = R"(
+  void f(int P);
+  )";
+  Decl *FromTU = getTuDecl(FromTUCode, Lang_CXX11);
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("f")));
+  ASSERT_TRUE(FromF);
+
+  auto *ImportedF = Import(FromF, Lang_CXX11);
+  EXPECT_TRUE(ImportedF);
+  EXPECT_TRUE(SharedStatePtr->getLookupTable()->contains(
+  ImportedF, ImportedF->getParamDecl(0)));
+}
+
 // FIXME Move these tests out of ASTImporterTest. For that we need to factor
 // out the ASTImporter specific pars from ASTImporterOptionSpecificTestBase
 // into a new test Fixture. Then we should lift up this Fixture to its own
Index: clang/lib/AST/ASTImporterLookupTable.cpp
===
--- clang/lib/AST/ASTImporterLookupTable.cpp
+++ clang/lib/AST/ASTImporterLookupTable.cpp
@@ -117,6 +117,19 @@
 remove(ReDC, ND);
 }
 
+void ASTImporterLookupTable::update(NamedDecl *ND, DeclContext *OldDC) {
+  assert(OldDC != ND->getDeclContext() &&
+ "DeclContext should be changed before update");
+  if (contains(ND->getDeclContext(), ND)) {
+assert(!contains(OldDC, ND) &&
+   "Decl should not be found in the old context if already in the new");
+return;
+  }
+
+  remove(OldDC, ND);
+  add(ND);
+}
+
 ASTImporterLookupTable::LookupResult
 ASTImporterLookupTable::lookup(DeclContext *DC, DeclarationName Name) const {
   auto DCI = LookupTable.find(DC->getPrimaryContext());
@@ -131,6 +144,10 @@
   return NamesI->second;
 }
 
+bool ASTImporterLookupTable::contains(DeclContext *DC, NamedDecl *ND) const {
+  return 0 < lookup(DC, ND->getDeclName()).count(ND);
+}
+
 void ASTImporterLookupTable::dump(DeclContext *DC) const {
   auto DCI = LookupTable.find(DC->getPrimaryContext());
   if (DCI == LookupTable.end())
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -3503,6 +3503,8 @@
   for (auto *Param : Parameters) {
 Param->setOwningFunction(ToFunction);
 ToFunction->addDeclInternal(Param);
+if (ASTImporterLookupTable *LT = Importer.SharedState->getLookupTable())
+  LT->update(Param, Importer.getToContext().getTranslationUnitDecl());
   }
   ToFunction->setParams(Parameters);
 
Index: clang/include/clang/AST/ASTImporterLookupTable.h
===
--- clang/include/clang/AST/ASTImporterLookupTable.h
+++ clang/include/clang/AST/ASTImporterLookupTable.h
@@ -63,8 +63,24 @@
   ASTImporterLookupTable(TranslationUnitDecl &TU);
   void add(NamedDecl *ND);
   void remove(NamedDecl *ND);
+  // Sometimes a declaration is created first with a temporarily value of decl
+  // context (often the translation unit) and later moved to the final context.
+  // This happens for declarations that are created before the final declaration
+  // context. In such cases the lookup table needs to be updated.
+  // (The declaration is in these cases not added to the temporary decl context,
+  // only its parent is set.)
+  // FIXME: It would

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 349833.
aaron.ballman added a comment.

Update based on review feedback.


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

https://reviews.llvm.org/D103611

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/SemaCXX/varargs.cpp


Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++03 -verify %s
+// RUN: %clang_cc1 -std=c++03 -Wno-c++11-extensions -verify %s
 // RUN: %clang_cc1 -std=c++11 -verify %s
 
 __builtin_va_list ap;
@@ -28,6 +28,30 @@
   };
 }
 
+// Ensure the correct behavior for promotable type UB checking.
+void promotable(int a, ...) {
+  enum Unscoped { One };
+  (void)__builtin_va_arg(ap, Unscoped); // ok
+
+  enum class Scoped { Two };
+  (void)__builtin_va_arg(ap, Scoped); // ok
+
+  enum Fixed : int { Three };
+  (void)__builtin_va_arg(ap, Fixed); // ok
+
+  enum FixedSmall : char { Four };
+  (void)__builtin_va_arg(ap, FixedSmall); // expected-warning {{second 
argument to 'va_arg' is of promotable type 'FixedSmall'; this va_arg has 
undefined behavior because arguments will be promoted to 'int'}}
+
+  enum FixedLarge : long long { Five };
+  (void)__builtin_va_arg(ap, FixedLarge); // ok
+
+  // Ensure that qualifiers are ignored.
+  (void)__builtin_va_arg(ap, const volatile int);  // ok
+
+  // Ensure that signed vs unsigned doesn't matter either.
+  (void)__builtin_va_arg(ap, unsigned int);
+}
+
 #if __cplusplus >= 201103L
 // We used to have bugs identifying the correct enclosing function scope in a
 // lambda.
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -15750,7 +15750,29 @@
 QualType PromoteType;
 if (TInfo->getType()->isPromotableIntegerType()) {
   PromoteType = Context.getPromotedIntegerType(TInfo->getType());
-  if (Context.typesAreCompatible(PromoteType, TInfo->getType()))
+  // [cstdarg.syn]p1 defers the C++ behavior to what the C standard says,
+  // and C2x 7.16.1.1p2 says, in part:
+  //   If type is not compatible with the type of the actual next argument
+  //   (as promoted according to the default argument promotions), the
+  //   behavior is undefined, except for the following cases:
+  // - both types are pointers to qualified or unqualified versions of
+  //   compatible types;
+  // - one type is a signed integer type, the other type is the
+  //   corresponding unsigned integer type, and the value is
+  //   representable in both types;
+  // - one type is pointer to qualified or unqualified void and the
+  //   other is a pointer to a qualified or unqualified character type.
+  // Given that type compatibility is the primary requirement (ignoring
+  // qualifications), you would think we could call typesAreCompatible()
+  // directly to test this. However, in C++, that checks for *same type*,
+  // which causes false positives when passing an enumeration type to
+  // va_arg. Instead, get the underlying type of the enumeration and pass
+  // that.
+  QualType UnderlyingType = TInfo->getType();
+  if (const auto *ET = UnderlyingType->getAs())
+UnderlyingType = ET->getDecl()->getIntegerType();
+  if (Context.typesAreCompatible(PromoteType, UnderlyingType,
+ /*CompareUnqualified*/ true))
 PromoteType = QualType();
 }
 if (TInfo->getType()->isSpecificBuiltinType(BuiltinType::Float))


Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++03 -verify %s
+// RUN: %clang_cc1 -std=c++03 -Wno-c++11-extensions -verify %s
 // RUN: %clang_cc1 -std=c++11 -verify %s
 
 __builtin_va_list ap;
@@ -28,6 +28,30 @@
   };
 }
 
+// Ensure the correct behavior for promotable type UB checking.
+void promotable(int a, ...) {
+  enum Unscoped { One };
+  (void)__builtin_va_arg(ap, Unscoped); // ok
+
+  enum class Scoped { Two };
+  (void)__builtin_va_arg(ap, Scoped); // ok
+
+  enum Fixed : int { Three };
+  (void)__builtin_va_arg(ap, Fixed); // ok
+
+  enum FixedSmall : char { Four };
+  (void)__builtin_va_arg(ap, FixedSmall); // expected-warning {{second argument to 'va_arg' is of promotable type 'FixedSmall'; this va_arg has undefined behavior because arguments will be promoted to 'int'}}
+
+  enum FixedLarge : long long { Five };
+  (void)__builtin_va_arg(ap, FixedLarge); // ok
+
+  // Ensure that qualifiers are ignored.
+  (void)__builtin_va_arg(ap, const volatile int);  // ok
+
+  // Ensure that signed vs unsigned doesn't matter either.
+  (void)__builtin_va_arg(ap, unsigned int);
+}
+
 #if

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D103611#2797044 , @efriedma wrote:

> I'm a little nervous about using C type merging in C++; it's not designed to 
> support C++ types, so it might end up crashing or something like that.  I 
> think I'd prefer to explicitly convert enum types to their underlying type.

I got lulled into thinking `mergeTypes()` worked for C++ because it handles 
references and cites the C++ standard first thing. But I see later that it also 
claims some C++ types are unreachable. So I switched to the underlying type for 
the enumeration, good suggestion!


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

https://reviews.llvm.org/D103611

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

[clang] 93a0581 - [clang][deps] Add argument for customizing PCM paths

[Jan Svoboda via cfe-commits]

Author: Jan Svoboda
Date: 2021-06-04T14:45:18+02:00
New Revision: 93a058190cc67c18bf4e0af9d871d56106b80a49

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

LOG: [clang][deps] Add argument for customizing PCM paths

Dependency scanning currently performs an implicit build. When testing that 
Clang can build modules with the command-lines generated by `clang-scan-deps`, 
the actual compilation would overwrite artifacts created during the scan, which 
makes debugging harder than it should be and can lead to errors in multi-step 
builds.

To prevent this, this patch adds new flag to `clang-scan-deps` that allows 
developers to customize the directory to use when generating module map paths, 
instead of always using the module cache. Moreover, the explicit context hash 
in now part of the PCM path, which will be useful in D102488, where the context 
hash can change due to command-line pruning.

Reviewed By: Bigcheese

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

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
clang/test/ClangScanDeps/modules-full.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h 
b/clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
index 7599a8bf45b9e..b8b7882e54bdb 100644
--- a/clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
+++ b/clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
@@ -42,6 +42,16 @@ struct ModuleID {
   /// Modules with the same name but a 
diff erent \c ContextHash should be
   /// treated as separate modules for the purpose of a build.
   std::string ContextHash;
+
+  bool operator==(const ModuleID &Other) const {
+return ModuleName == Other.ModuleName && ContextHash == Other.ContextHash;
+  }
+};
+
+struct ModuleIDHasher {
+  std::size_t operator()(const ModuleID &MID) const {
+return llvm::hash_combine(MID.ModuleName, MID.ContextHash);
+  }
 };
 
 struct ModuleDeps {

diff  --git a/clang/test/ClangScanDeps/modules-full.cpp 
b/clang/test/ClangScanDeps/modules-full.cpp
index a8d18abea41e6..df2821cbef635 100644
--- a/clang/test/ClangScanDeps/modules-full.cpp
+++ b/clang/test/ClangScanDeps/modules-full.cpp
@@ -20,6 +20,12 @@
 // RUN:   -generate-modules-path-args -mode preprocess-minimized-sources >> 
%t.result
 // RUN: cat %t.result | sed 's/\\/\//g' | FileCheck 
--check-prefixes=CHECK,CHECK-ABS %s
 //
+// RUN: echo %t.dir > %t.result
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format 
experimental-full \
+// RUN:   -generate-modules-path-args -module-files-dir %t.dir/custom \
+// RUN:   -mode preprocess-minimized-sources >> %t.result
+// RUN: cat %t.result | sed 's/\\/\//g' | FileCheck 
--check-prefixes=CHECK,CHECK-CUSTOM %s
+//
 // RUN: echo %t.dir > %t_clangcl.result
 // RUN: clang-scan-deps -compilation-database %t_clangcl.cdb -j 4 -format 
experimental-full \
 // RUN:   -mode preprocess-minimized-sources >> %t_clangcl.result
@@ -45,9 +51,11 @@
 // CHECK-NEXT: "-cc1"
 // CHECK-NO-ABS-NOT:   "-fmodule-map-file={{.*}}"
 // CHECK-ABS:  "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
+// CHECK-CUSTOM:   "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
 // CHECK:  "-emit-module"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}}"
 // CHECK-ABS:  
"-fmodule-file=[[PREFIX]]/module-cache{{(_clangcl)?}}/[[CONTEXT_HASH_H1]]/header2-{{[A-Z0-9]+}}.pcm"
+// CHECK-CUSTOM:   
"-fmodule-file=[[PREFIX]]/custom/[[CONTEXT_HASH_H1]]/header2-{{[A-Z0-9]+}}.pcm"
 // CHECK:  "-fmodule-name=header1"
 // CHECK:  "-fno-implicit-modules"
 // CHECK:],
@@ -105,8 +113,10 @@
 // CHECK-NEXT: "-fno-implicit-module-maps"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}}"
 // CHECK-ABS-NEXT: 
"-fmodule-file=[[PREFIX]]/module-cache{{(_clangcl)?}}/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0-9]+}}.pcm"
+// CHECK-CUSTOM-NEXT:  
"-fmodule-file=[[PREFIX]]/custom/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0-9]+}}.pcm"
 // CHECK-NO-ABS-NOT:   "-fmodule-map-file={{.*}}"
 // CHECK-ABS-NEXT: "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
+// CHECK-CUSTOM-NEXT:  "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
 // CHECK-NEXT:   ],
 // CHECK-NEXT:   "file-deps": [
 // CHECK-NEXT: "[[PREFIX]]/modules_cdb_input.cpp"
@@ -126,8 +136,10 @@
 // CHECK-NEXT: "-fno-implicit-module-maps"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}},
 // CHECK-ABS-NEXT: 
"-fmodule-file=[[PREFIX]]/module-cache{{(_clangcl)?}}/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0-9]+}}.pcm"
+// CHECK-CUSTOM-NEXT:  
"-fmodule-file=[[PREFIX]]/custom/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0

[PATCH] D103516: [clang][deps] Add argument for customizing PCM paths

[Jan Svoboda 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 rG93a058190cc6: [clang][deps] Add argument for customizing PCM 
paths (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D103516?vs=349238&id=349840#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103516

Files:
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/test/ClangScanDeps/modules-full.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -163,6 +163,13 @@
 "'-fmodule-file=', '-o', '-fmodule-map-file='."),
 llvm::cl::init(false), llvm::cl::cat(DependencyScannerCategory));
 
+static llvm::cl::opt ModuleFilesDir(
+"module-files-dir",
+llvm::cl::desc("With '-generate-modules-path-args', paths to module files "
+   "in the generated command lines will begin with the "
+   "specified directory instead the module cache directory."),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -357,7 +364,22 @@
 
 private:
   StringRef lookupPCMPath(ModuleID MID) {
-return Modules[IndexedModuleID{MID, 0}].ImplicitModulePCMPath;
+auto PCMPath = PCMPaths.insert({MID, ""});
+if (PCMPath.second)
+  PCMPath.first->second = constructPCMPath(lookupModuleDeps(MID));
+return PCMPath.first->second;
+  }
+
+  /// Construct a path for the explicitly built PCM.
+  std::string constructPCMPath(const ModuleDeps &MD) const {
+StringRef Filename = llvm::sys::path::filename(MD.ImplicitModulePCMPath);
+
+SmallString<256> ExplicitPCMPath(
+!ModuleFilesDir.empty()
+? ModuleFilesDir
+: MD.Invocation.getHeaderSearchOpts().ModuleCachePath);
+llvm::sys::path::append(ExplicitPCMPath, MD.ID.ContextHash, Filename);
+return std::string(ExplicitPCMPath);
   }
 
   const ModuleDeps &lookupModuleDeps(ModuleID MID) {
@@ -395,6 +417,7 @@
   std::mutex Lock;
   std::unordered_map
   Modules;
+  std::unordered_map PCMPaths;
   std::vector Inputs;
 };
 
Index: clang/test/ClangScanDeps/modules-full.cpp
===
--- clang/test/ClangScanDeps/modules-full.cpp
+++ clang/test/ClangScanDeps/modules-full.cpp
@@ -20,6 +20,12 @@
 // RUN:   -generate-modules-path-args -mode preprocess-minimized-sources >> %t.result
 // RUN: cat %t.result | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK,CHECK-ABS %s
 //
+// RUN: echo %t.dir > %t.result
+// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \
+// RUN:   -generate-modules-path-args -module-files-dir %t.dir/custom \
+// RUN:   -mode preprocess-minimized-sources >> %t.result
+// RUN: cat %t.result | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK,CHECK-CUSTOM %s
+//
 // RUN: echo %t.dir > %t_clangcl.result
 // RUN: clang-scan-deps -compilation-database %t_clangcl.cdb -j 4 -format experimental-full \
 // RUN:   -mode preprocess-minimized-sources >> %t_clangcl.result
@@ -45,9 +51,11 @@
 // CHECK-NEXT: "-cc1"
 // CHECK-NO-ABS-NOT:   "-fmodule-map-file={{.*}}"
 // CHECK-ABS:  "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
+// CHECK-CUSTOM:   "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
 // CHECK:  "-emit-module"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}}"
 // CHECK-ABS:  "-fmodule-file=[[PREFIX]]/module-cache{{(_clangcl)?}}/[[CONTEXT_HASH_H1]]/header2-{{[A-Z0-9]+}}.pcm"
+// CHECK-CUSTOM:   "-fmodule-file=[[PREFIX]]/custom/[[CONTEXT_HASH_H1]]/header2-{{[A-Z0-9]+}}.pcm"
 // CHECK:  "-fmodule-name=header1"
 // CHECK:  "-fno-implicit-modules"
 // CHECK:],
@@ -105,8 +113,10 @@
 // CHECK-NEXT: "-fno-implicit-module-maps"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}}"
 // CHECK-ABS-NEXT: "-fmodule-file=[[PREFIX]]/module-cache{{(_clangcl)?}}/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0-9]+}}.pcm"
+// CHECK-CUSTOM-NEXT:  "-fmodule-file=[[PREFIX]]/custom/[[CONTEXT_HASH_H2]]/header1-{{[A-Z0-9]+}}.pcm"
 // CHECK-NO-ABS-NOT:   "-fmodule-map-file={{.*}}"
 // CHECK-ABS-NEXT: "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
+// CHECK-CUSTOM-NEXT:  "-fmodule-map-file=[[PREFIX]]/Inputs/module.modulemap"
 // CHECK-NEXT:   ],
 // CHECK-NEXT:   "file-deps": [
 // CHECK-NEXT: "[[PREFIX]]/modules_cdb_input.cpp"
@@ -126,8 +136,10 @@
 // CHECK-NEXT: "-fno-implicit-module-maps"
 // CHECK-NO-ABS-NOT:   "-fmodule-file={{.*}},
 // CHECK-ABS-NEXT: "-fmod

[clang] 20bd214 - [flang][driver] Add support for `-module-suffix`

[Andrzej Warzynski via cfe-commits]

Author: Andrzej Warzynski
Date: 2021-06-04T13:58:04+01:00
New Revision: 20bd2142d46536f4ffd61f28a029d6bda68f1a7f

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

LOG: [flang][driver] Add support for `-module-suffix`

This option is supported in `f18`, but not yet available in `flang-new`.
It is required in order to call `flang-new` from the `flang` bash
script.

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

Added: 
flang/test/Driver/module-suffix.f90

Modified: 
clang/include/clang/Driver/Options.td
flang/include/flang/Frontend/CompilerInvocation.h
flang/lib/Frontend/CompilerInvocation.cpp
flang/test/Driver/driver-help.f90

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 4945538ec0f01..c2945fb0bf184 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -4522,6 +4522,9 @@ def fdebug_module_writer : 
Flag<["-"],"fdebug-module-writer">,
 def fget_symbols_sources : Flag<["-"], "fget-symbols-sources">, 
Group,
   HelpText<"Dump symbols and their source code locations">;
 
+def module_suffix : Separate<["-"], "module-suffix">,  Group, 
MetaVarName<"">,
+  HelpText<"Use  as the suffix for module files (the default value is 
`.mod`)">;
+
 }
 
 
//===--===//

diff  --git a/flang/include/flang/Frontend/CompilerInvocation.h 
b/flang/include/flang/Frontend/CompilerInvocation.h
index edd32917b175c..f449a69dfa8a0 100644
--- a/flang/include/flang/Frontend/CompilerInvocation.h
+++ b/flang/include/flang/Frontend/CompilerInvocation.h
@@ -69,6 +69,8 @@ class CompilerInvocation : public CompilerInvocationBase {
   // of options.
   std::string moduleDir_ = ".";
 
+  std::string moduleFileSuffix_ = ".mod";
+
   bool debugModuleDir_ = false;
 
   bool warnAsErr_ = false;
@@ -97,6 +99,9 @@ class CompilerInvocation : public CompilerInvocationBase {
   std::string &moduleDir() { return moduleDir_; }
   const std::string &moduleDir() const { return moduleDir_; }
 
+  std::string &moduleFileSuffix() { return moduleFileSuffix_; }
+  const std::string &moduleFileSuffix() const { return moduleFileSuffix_; }
+
   bool &debugModuleDir() { return debugModuleDir_; }
   const bool &debugModuleDir() const { return debugModuleDir_; }
 
@@ -129,6 +134,10 @@ class CompilerInvocation : public CompilerInvocationBase {
   /// Useful setters
   void SetModuleDir(std::string &moduleDir) { moduleDir_ = moduleDir; }
 
+  void SetModuleFileSuffix(const char *moduleFileSuffix) {
+moduleFileSuffix_ = std::string(moduleFileSuffix);
+  }
+
   void SetDebugModuleDir(bool flag) { debugModuleDir_ = flag; }
 
   void SetWarnAsErr(bool flag) { warnAsErr_ = flag; }

diff  --git a/flang/lib/Frontend/CompilerInvocation.cpp 
b/flang/lib/Frontend/CompilerInvocation.cpp
index 1f61e0e9ff305..1d18dda5e7eea 100644
--- a/flang/lib/Frontend/CompilerInvocation.cpp
+++ b/flang/lib/Frontend/CompilerInvocation.cpp
@@ -392,6 +392,12 @@ static bool parseSemaArgs(CompilerInvocation &res, 
llvm::opt::ArgList &args,
 res.SetDebugModuleDir(true);
   }
 
+  // -module-suffix
+  if (const auto *moduleSuffix =
+  args.getLastArg(clang::driver::options::OPT_module_suffix)) {
+res.SetModuleFileSuffix(moduleSuffix->getValue());
+  }
+
   return diags.getNumErrors() == numErrorsBefore;
 }
 
@@ -639,5 +645,6 @@ void CompilerInvocation::setSemanticsOpts(
   semanticsContext_->set_moduleDirectory(moduleDir())
   .set_searchDirectories(fortranOptions.searchDirectories)
   .set_warnOnNonstandardUsage(enableConformanceChecks())
-  .set_warningsAreErrors(warnAsErr());
+  .set_warningsAreErrors(warnAsErr())
+  .set_moduleFileSuffix(moduleFileSuffix());
 }

diff  --git a/flang/test/Driver/driver-help.f90 
b/flang/test/Driver/driver-help.f90
index 9783751a2c9e7..696c437a574b8 100644
--- a/flang/test/Driver/driver-help.f90
+++ b/flang/test/Driver/driver-help.f90
@@ -106,6 +106,7 @@
 ! HELP-FC1-NEXT: -help  Display available options
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list 
of include search paths
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
+! HELP-FC1-NEXT: -module-suffix  Use  as the suffix for module 
files (the default value is `.mod`)
 ! HELP-FC1-NEXT: -nocpp Disable predefined and command line 
preprocessor macros
 ! HELP-FC1-NEXT: -o   Write output to 
 ! HELP-FC1-NEXT: -pedantic  Warn on language extensions

diff  --git a/flang/test/Driver/module-suffix.f90 
b/flang/test/Driver/module-suffix.f90
new file mode 100644
index 0..151688492c932
--- /dev/null
+++ b/flang/test/Driver/module-suffix.f90
@@ -0,0 +1,16 @@
+! Tes

[clang] de07b1e - [clang][deps] Support object files

[Jan Svoboda via cfe-commits]

Author: Jan Svoboda
Date: 2021-06-04T14:58:42+02:00
New Revision: de07b1e84d8de948304766df602fee2b845e9532

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

LOG: [clang][deps] Support object files

When a project uses PCH with explicit modules, the build will look like this:

1. scan PCH dependencies
2. explicitly build PCH
3. scan TU dependencies
4. explicitly build TU

Step 2 produces an object file for the PCH, which the dependency scanner needs 
to read in step 3. This patch adds support for this.

The `clang-scan-deps` invocation in the attached test would fail without this 
change.

Depends on D103516.

Reviewed By: Bigcheese

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

Added: 
clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
clang/test/ClangScanDeps/Inputs/modules-pch/mod_tu.h
clang/test/ClangScanDeps/Inputs/modules-pch/module.modulemap
clang/test/ClangScanDeps/Inputs/modules-pch/pch.h
clang/test/ClangScanDeps/Inputs/modules-pch/tu.c
clang/test/ClangScanDeps/modules-pch.c

Modified: 
clang/lib/Tooling/DependencyScanning/CMakeLists.txt
clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DependencyScanning/CMakeLists.txt 
b/clang/lib/Tooling/DependencyScanning/CMakeLists.txt
index c6fe207ab2f27..ce455e518070b 100644
--- a/clang/lib/Tooling/DependencyScanning/CMakeLists.txt
+++ b/clang/lib/Tooling/DependencyScanning/CMakeLists.txt
@@ -1,4 +1,5 @@
 set(LLVM_LINK_COMPONENTS
+  ${LLVM_TARGETS_TO_BUILD}
   Core
   Support
   )
@@ -16,6 +17,7 @@ add_clang_library(clangDependencyScanning
   LINK_LIBS
   clangAST
   clangBasic
+  clangCodeGen
   clangDriver
   clangFrontend
   clangFrontendTool

diff  --git 
a/clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
index 93bb0cde439dc..4f3e574719d2b 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang;
 using namespace tooling;
@@ -16,4 +17,10 @@ DependencyScanningService::DependencyScanningService(
 ScanningMode Mode, ScanningOutputFormat Format, bool ReuseFileManager,
 bool SkipExcludedPPRanges)
 : Mode(Mode), Format(Format), ReuseFileManager(ReuseFileManager),
-  SkipExcludedPPRanges(SkipExcludedPPRanges) {}
+  SkipExcludedPPRanges(SkipExcludedPPRanges) {
+  // Initialize targets for object file support.
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+  llvm::InitializeAllAsmParsers();
+}

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index 63264b0dda2d5..ecaeeed1a061c 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
+#include "clang/CodeGen/ObjectFilePCHContainerOperations.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -153,7 +154,15 @@ DependencyScanningWorker::DependencyScanningWorker(
 DependencyScanningService &Service)
 : Format(Service.getFormat()) {
   DiagOpts = new DiagnosticOptions();
+
   PCHContainerOps = std::make_shared();
+  PCHContainerOps->registerReader(
+  std::make_unique());
+  // We don't need to write object files, but the current PCH implementation
+  // requires the writer to be registered as well.
+  PCHContainerOps->registerWriter(
+  std::make_unique());
+
   RealFS = llvm::vfs::createPhysicalFileSystem();
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =

diff  --git a/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json 
b/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
new file mode 100644
index 0..8aad2cc74023e
--- /dev/null
+++ b/clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "clang -fsyntax-only DIR/tu.c -fmodules -gmodules 
-fimplicit-module-maps -fmodules-cache-path=DIR/cache -include DIR/pch.h -o 
DIR/tu.o",
+"file": "DIR/tu.c"
+  }
+

[PATCH] D103613: [flang][driver] Add support for `-module-suffix`

[Andrzej Warzynski via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG20bd2142d465: [flang][driver] Add support for 
`-module-suffix` (authored by awarzynski).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103613

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Driver/module-suffix.f90

Index: flang/test/Driver/module-suffix.f90
===
--- /dev/null
+++ flang/test/Driver/module-suffix.f90
@@ -0,0 +1,16 @@
+! Tests `-module-suffix` frontend option
+
+!--
+! RUN lines
+!--
+! RUN: rm -rf %t && mkdir -p %t/dir-flang/
+! RUN: cd %t && %flang_fc1 -fsyntax-only -module-suffix .f18.mod -module-dir %t/dir-flang %s
+! RUN: ls %t/dir-flang/testmodule.f18.mod && not ls %t/dir-flang/testmodule.mod
+
+!--
+! INPUT
+!--
+module testmodule
+  type::t2
+  end type
+end
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -106,6 +106,7 @@
 ! HELP-FC1-NEXT: -help  Display available options
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
+! HELP-FC1-NEXT: -module-suffix  Use  as the suffix for module files (the default value is `.mod`)
 ! HELP-FC1-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! HELP-FC1-NEXT: -o   Write output to 
 ! HELP-FC1-NEXT: -pedantic  Warn on language extensions
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -392,6 +392,12 @@
 res.SetDebugModuleDir(true);
   }
 
+  // -module-suffix
+  if (const auto *moduleSuffix =
+  args.getLastArg(clang::driver::options::OPT_module_suffix)) {
+res.SetModuleFileSuffix(moduleSuffix->getValue());
+  }
+
   return diags.getNumErrors() == numErrorsBefore;
 }
 
@@ -639,5 +645,6 @@
   semanticsContext_->set_moduleDirectory(moduleDir())
   .set_searchDirectories(fortranOptions.searchDirectories)
   .set_warnOnNonstandardUsage(enableConformanceChecks())
-  .set_warningsAreErrors(warnAsErr());
+  .set_warningsAreErrors(warnAsErr())
+  .set_moduleFileSuffix(moduleFileSuffix());
 }
Index: flang/include/flang/Frontend/CompilerInvocation.h
===
--- flang/include/flang/Frontend/CompilerInvocation.h
+++ flang/include/flang/Frontend/CompilerInvocation.h
@@ -69,6 +69,8 @@
   // of options.
   std::string moduleDir_ = ".";
 
+  std::string moduleFileSuffix_ = ".mod";
+
   bool debugModuleDir_ = false;
 
   bool warnAsErr_ = false;
@@ -97,6 +99,9 @@
   std::string &moduleDir() { return moduleDir_; }
   const std::string &moduleDir() const { return moduleDir_; }
 
+  std::string &moduleFileSuffix() { return moduleFileSuffix_; }
+  const std::string &moduleFileSuffix() const { return moduleFileSuffix_; }
+
   bool &debugModuleDir() { return debugModuleDir_; }
   const bool &debugModuleDir() const { return debugModuleDir_; }
 
@@ -129,6 +134,10 @@
   /// Useful setters
   void SetModuleDir(std::string &moduleDir) { moduleDir_ = moduleDir; }
 
+  void SetModuleFileSuffix(const char *moduleFileSuffix) {
+moduleFileSuffix_ = std::string(moduleFileSuffix);
+  }
+
   void SetDebugModuleDir(bool flag) { debugModuleDir_ = flag; }
 
   void SetWarnAsErr(bool flag) { warnAsErr_ = flag; }
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4522,6 +4522,9 @@
 def fget_symbols_sources : Flag<["-"], "fget-symbols-sources">, Group,
   HelpText<"Dump symbols and their source code locations">;
 
+def module_suffix : Separate<["-"], "module-suffix">,  Group, MetaVarName<"">,
+  HelpText<"Use  as the suffix for module files (the default value is `.mod`)">;
+
 }
 
 //===--===//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103519: [clang][deps] Support object files

[Jan Svoboda 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 rGde07b1e84d8d: [clang][deps] Support object files (authored 
by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D103519?vs=349245&id=349847#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103519

Files:
  clang/lib/Tooling/DependencyScanning/CMakeLists.txt
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
  clang/test/ClangScanDeps/Inputs/modules-pch/mod_tu.h
  clang/test/ClangScanDeps/Inputs/modules-pch/module.modulemap
  clang/test/ClangScanDeps/Inputs/modules-pch/pch.h
  clang/test/ClangScanDeps/Inputs/modules-pch/tu.c
  clang/test/ClangScanDeps/modules-pch.c

Index: clang/test/ClangScanDeps/modules-pch.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-pch.c
@@ -0,0 +1,13 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/modules-pch/* %t
+
+// Explicitly build the PCH:
+//
+// RUN: %clang -x c-header %t/pch.h -fmodules -gmodules -fimplicit-module-maps \
+// RUN:   -fmodules-cache-path=%t/cache -o %t/pch.h.gch
+
+// Scan dependencies of the TU:
+//
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_tu.json > %t/cdb_tu.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_tu.json -format experimental-full \
+// RUN:   -generate-modules-path-args -module-files-dir %t/build
Index: clang/test/ClangScanDeps/Inputs/modules-pch/tu.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/modules-pch/tu.c
@@ -0,0 +1,3 @@
+// tu.c
+
+#include "mod_tu.h"
Index: clang/test/ClangScanDeps/Inputs/modules-pch/pch.h
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/modules-pch/pch.h
@@ -0,0 +1 @@
+// pch.h
Index: clang/test/ClangScanDeps/Inputs/modules-pch/module.modulemap
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/modules-pch/module.modulemap
@@ -0,0 +1,3 @@
+module ModTU {
+header "mod_tu.h"
+}
Index: clang/test/ClangScanDeps/Inputs/modules-pch/mod_tu.h
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/modules-pch/mod_tu.h
@@ -0,0 +1 @@
+// mod_tu.h
Index: clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/modules-pch/cdb_tu.json
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "clang -fsyntax-only DIR/tu.c -fmodules -gmodules -fimplicit-module-maps -fmodules-cache-path=DIR/cache -include DIR/pch.h -o DIR/tu.o",
+"file": "DIR/tu.c"
+  }
+]
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "clang/Tooling/DependencyScanning/DependencyScanningWorker.h"
+#include "clang/CodeGen/ObjectFilePCHContainerOperations.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -153,7 +154,15 @@
 DependencyScanningService &Service)
 : Format(Service.getFormat()) {
   DiagOpts = new DiagnosticOptions();
+
   PCHContainerOps = std::make_shared();
+  PCHContainerOps->registerReader(
+  std::make_unique());
+  // We don't need to write object files, but the current PCH implementation
+  // requires the writer to be registered as well.
+  PCHContainerOps->registerWriter(
+  std::make_unique());
+
   RealFS = llvm::vfs::createPhysicalFileSystem();
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
+#include "llvm/Support/TargetSelect.h"
 
 using namespace clang;
 using namespace tooling;
@@ -16,4 +17,10 @@
 ScanningMode Mode, ScanningOutputFormat Format, bool ReuseFileManager,
 bool SkipExcludedPPRanges)
 : Mode(Mode), Format(Format), ReuseFi

[clang] b5dea87 - [HIP] Fix spack HIP device lib detection

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2021-06-04T09:12:41-04:00
New Revision: b5dea8701ba98425991d4f1ec3d87bdb98789e04

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

LOG: [HIP] Fix spack HIP device lib detection

spack HIP device library is installed at amdgcn directory under llvm/clang
directory.

This patch fixes detection of HIP device library for spack.

Reviewed by: Artem Belevich, Harmen Stoppels

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

Added: 

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/asanrtl.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/ockl.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_daz_opt_off.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_daz_opt_on.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_finite_only_off.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_finite_only_on.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1010.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1011.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1012.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_803.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_900.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_908.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_unsafe_math_off.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_unsafe_math_on.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_wavefrontsize64_off.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_wavefrontsize64_on.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/ocml.bc

clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/opencl.bc

Modified: 
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/test/Driver/rocm-detect.hip

Removed: 

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/asanrtl.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/hip.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/ockl.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_daz_opt_off.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_daz_opt_on.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_finite_only_off.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_finite_only_on.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_1010.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_1011.bc

clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_

[PATCH] D103281: [HIP] Fix spack HIP device lib detection

[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 rGb5dea8701ba9: [HIP] Fix spack HIP device lib detection 
(authored by yaxunl).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103281

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/asanrtl.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/hip.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/ockl.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_daz_opt_off.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_daz_opt_on.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_finite_only_off.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_finite_only_on.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1010.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1011.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_1012.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_803.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_900.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_isa_version_908.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_unsafe_math_off.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_unsafe_math_on.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_wavefrontsize64_off.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/oclc_wavefrontsize64_on.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/ocml.bc
  
clang/test/Driver/Inputs/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/amdgcn/bitcode/opencl.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/asanrtl.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/hip.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/ockl.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_off.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_daz_opt_off.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_daz_opt_on.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_finite_only_off.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_finite_only_on.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_1010.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_1011.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_1012.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_803.bc
  
clang/test/Driver/Inputs/rocm-spack/rocm-device-libs-4.0.0-6wnyzz4hgl3hr7uswasnagt7j2adctbs/amdgcn/bitcode/oclc_isa_version_900.bc
  
clang/test/D

[PATCH] D103605: [analyzer] Introduce a new interface for tracking

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D103605#2798171 , @NoQ wrote:

> Ok. Oof. Whoa. That's amazing.
>
> Let me re-iterate to make sure that my understanding of this patchset is 
> correct.
>
> **Chapter 1.** //"A is correlated with B (ρ = 0.56), given C, assuming D and 
> under E conditions"//
>
> - Two new entities are introduced: trackers and handlers.
> - Trackers are attached to bug reports. A single bug report may have multiple 
> trackers.
>   - Why not have only one tracker per report?
> - Handlers are attached to trackers. Each tracker can have multiple handlers 
> with a priority system.
>   - Do you envision it growing into a dependency system later?
> - A subclass of visitors known as "tracking visitors" are connected to 
> trackers. One tracker may have multiple visitors attached to it.
> - Trackers are a tiny, almost uncustomizable class. It contains is a method 
> called `track()` that is invoked when attention of handlers is required.
> - Each tracker comes with a default set of handlers.
> - The only way to customize a tracker is to add extra handlers to it.
> - Handlers implement a `handle()` method invoked by the tracker every time 
> their attention is required in `track()`.
> - Handlers may return a note from their `handle()` method. If a handler 
> returns a note, this note is attached to the bug report and lower-priority 
> handlers are not invoked at all.
> - There are two major classes of handlers: expression handlers and store 
> handlers. Expression handlers pay attention to Environment entries, store 
> handlers pay attention to Region Store bindings.
>
> **Chapter 2.** //"For immediate release: Scientists find potential link 
> between A and B"//
>
> - Bug visitors are still responsible for discovering connections across 
> exploded nodes. On the contrary, `track()`/`handle()` workflow is 
> instantaneous.
>   - It sounds like this whole patchset is orthogonal to reimplementing value 
> tracking visitors with note tags, as long as we can pass a reference to the 
> appropriate tracker into the tag(?)
> - Tracking starts when a checker creates a tracker and invokes `track()` on 
> it, which instantly causes the respective `handle()` to be invoked.
> - `handle()` may attach visitors. These visitors may in turn call `track()` 
> as they reach a different exploded node.
> - The termination condition is as usual: no further visitors attached.
>   - It sounds like this patchset is orthogonal to the problem of detecting 
> the tracking termination point(?) It does make it easier to implement 
> customized reactions to such termination though.
>
> **Chapter 3.** //"A causes B all the time. What will this means for Obama?"//
>
> - `trackExpressionValue()` now boils down to creation of a single tracker and 
> an initial invocation of `track()` on the expression which in turn causes 
> expression handlers to immediately react.
> - Most of the old body of `trackExpressionValue()` is transformed into a 
> default expression handler. So it's still part of an immediate reaction, just 
> a bit more generalized.
> - Most of the visitors that previously composed `trackExpressionValue()` are 
> still part of the process; they're attached by the default expression handler.
> - However, instead of adding notes directly, they simply invoke `track()`. 
> All note-attaching work is moved into additional default handlers.
>
> **Chapter 4.** //"I'm wearing this to ward off A!"//
>
> - Basic usage in checkers is basically unchanged. They still simply call 
> `trackExpressionValue()` and it just works.
> - Advanced usage - which is the whole point of this patchset - probably 
> implies adding custom handlers to the tracker created by 
> `trackExpressionValue()`.
> - Let's consider an example. Suppose you're implementing `evalCall` for 
> `llvm::dyn_cast`. You could have your expression handler detect a modeled 
> `dyn_cast` call and implement its `handle()` method to emit a 
> checker-specific note and start tracking the argument.
> - With this implementation such note will only be emitted if the value is 
> tracked back to `dyn_cast`. Not every modeled `dyn_cast` will receive a note 
> but only the one that, say, caused a null dereference on its return value 
> when it failed.
>   - Now, how does this interact with note tags? The idea behind note tags is 
> so that visitors didn't need to reverse-engineer the analysis.
>   - It sounds like the handler is a step back to the visitor world: it 
> doesn't know how exactly was `dyn_cast` modeled during analysis, so it has to 
> reverse-engineer what happened.
>   - For example, in order to find out whether `dyn_cast` succeeded or failed, 
> it has to explore the program state to find out which values are passed into 
> the cast and returned from the cast.
>   - Whereas a note tag would have this information accessible directly.
> - Hence a suggestion. Maybe instead of having a system of handlers, allow 
> visitors to //ask

[PATCH] D103314: [Analyzer][solver] Simplify existing constraints when a new constraint is added

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D103314#2790868 , @vsavchenko 
wrote:

> Awesome!
> I know, I said that we are ready to land, but I think I was too excited about 
> this change. We probably should have some data on how it performs on 
> real-life codebases.

Just some quick update on the status of this patch. I've done some measurements 
on smaller open source C projects (e.g tmux) and didn't see any noticeable 
slow-down. However, I've run into a bad-bad assertion failure in my favorite 
Checker (StdLibraryFu...). The assertion indicates that neither !State nor 
State is feasible, so this throws me back to the debugger for a while.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103314

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

[PATCH] D103587: [AIX] Transfer predefined macros

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 349854.
Jake-Egan marked 3 inline comments as done.
Jake-Egan added a comment.

Use LangStandard::isC11() and one C99 test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
@@ -723,6 +724,10 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,12 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+Builder.defineMacro("__TOS_AIX__");
+
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
@@ -723,6 +724,10 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu -fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,12 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+Builder.defineMacro("__TOS_AIX__");
+
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101630: [HIP] Fix device-only compilation

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D101630#2792160 , @tra wrote:

> In D101630#2792052 , @yaxunl wrote:
>
>> I think for intermediate outputs e.g. preprocessor expansion, IR, and 
>> assembly, probably it makes sense not to bundle by default.
>
> Agreed.
>
>> However, for default action (emitting object), we need to bundle by default 
>> since it was the old behavior and existing HIP apps depend on that.
>
> Existing use is a valid point.
> As a counterargument, I would suggest that in a compilation pipeline which 
> does include bundling, an object file for one GPU variant *is* an 
> intermediate output, similar to the ones you've listed above.
>
> The final product of device-side subcompilations is a bundle. The question is 
> `what does "-c" mean?`.  Is it `produce an object file` or `compile till the 
> end of the pipeline` ? 
> For CUDA and HIP compilation it's ambiguous. When we target just one GPU, it 
> would be closer to the former. In general, it would be closer to the latter. 
> NVCC side-steps the issue by using a different flags `-cubin/-fatbin` to 
> disambiguate between two cases and avoid bolting on CUDA-related semantics on 
> the compiler flags that were not designed for that.
>
>> Then we allow -fhip-bundle-device-output to override the default behavior.
>
> OK. Bundling objects for HIP by default looks like a reasonable compromise. 
> It would be useful to generalize the flag to `-fgpu-bundle...` as it would be 
> useful if/when we want to produce a fatbin during CUDA compilation. I'd still 
> keep no-bundling as the default for CUDA's objects.
>
> Now that we are in agreement of what we want, the next question is *how* we 
> want to do it.
>
> It appears that there's a fair bit of similarity between what the proposed 
> `-fgpu-bundle` flag does and the handful of `--emit-...` options clang has 
> now.
> If we were to use something like `--emit-gpu-object` and `--emit-gpu-bundle`, 
> it would be similar to NVCC's `-cubin/-fatbinary`, would decouple the default 
> behavior for `-c --cuda-device-only` from the user's ability to specify what 
> they want without burdening `-c` with additional flags that would have 
> different defaults under different circumstances.
>
> Compilation with "-c" would remain the "compile till the end", whatever it 
> happens to mean for particular language and `--emit-object/bundle` would tell 
> the compiler how far we want it to proceed and what kind of output we want. 
> This would probably be easier to explain to the users as they are already 
> familiar with flags like `-emit-llvm`, only now we are dealing with an extra 
> bundling step in the compilation pipeline. It would also behave consistently 
> across CUDA and HIP even though they have different defaults for bundling for 
> the device-side compilation. E.g. `-c --cuda-device-only --emit-gpu-bundle` 
> will always produce a bundle with the object files for both CUDA and HIP and 
> `-c --cuda-device-only --emit-gpu-object` will always require single '-o' 
> output.
>
> WDYT? Does it make sense?

For sure we will need -fgpu-bundle-device-output to control bundling of 
intermediate files. Then adding -emit-gpu-object and -emit-gpu-bundle may be 
redundant and can cause confusion. What if users specify `-c 
-fgpu-bundle-device-output -emit-gpu-object` or `-c 
-fno-gpu-bundle-device-output -emit-gpu-bundle`? To me a single option 
-fgpu-bundle-device-output to control all device output seems cleaner.


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

https://reviews.llvm.org/D101630

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

[PATCH] D103587: [AIX] Transfer predefined macros

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 349855.
Jake-Egan added a comment.

Use LangStandard::isC11() and one C99 test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
@@ -723,6 +724,25 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-ibm-aix7.1.0.0 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-AIX-NOTHREADSAFE %s
 // PPC-AIX-NOTHREADSAFE-NOT:#define _THREAD_SAFE 1
 
+// RUN: %clang_cc1 -x c -std=c11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c1x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=iso9899:2011 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.10.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu11 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=iso9899:2017 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c18 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=iso9899:2018 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu17 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu18 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=c2x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// RUN: %clang_cc1 -x c -std=gnu2x -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char  < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC %s
+// PPC-AIX-STDC:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC:#define __STDC_NO_THREADS__ 1
+
+// RUN: %clang_cc1 -x c -std=c99 -E -dM -ffreestanding 
-triple=powerpc-ibm-aix7.1.0.0 -fno-signed-char < /dev/null | FileCheck 
-match-full-lines -check-prefix PPC-AIX-STDC-N %s
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_ATOMICS__ 1
+// PPC-AIX-STDC-N-NOT:#define __STDC_NO_THREADS__ 1
+
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc-unknown-linux-gnu 
-fno-signed-char < /dev/null | FileCheck -match-full-lines -check-prefix 
PPC-LINUX %s
 //
 // PPC-LINUX:#define _ARCH_PPC 1
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,12 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+Builder.defineMacro("__TOS_AIX__");
+
+if (LangStandard::getLangStandardForKind(Opts.LangStd).isC11()) {
+  Builder.defineMacro("__STDC_NO_ATOMICS__");
+  Builder.defineMacro("__STDC_NO_THREADS__");
+}
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
@@ -723,6 +724,25 @@
 //

[clang] 86c2449 - [OpenCL][NFC] Test commit: tidy up whitespace in comment

[Stuart Brady via cfe-commits]

Author: Stuart Brady
Date: 2021-06-04T14:44:12+01:00
New Revision: 86c24493ea666a0ef91b7af884d616b0a181e849

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

LOG: [OpenCL][NFC] Test commit: tidy up whitespace in comment

Added: 


Modified: 
clang/lib/Headers/opencl-c.h

Removed: 




diff  --git a/clang/lib/Headers/opencl-c.h b/clang/lib/Headers/opencl-c.h
index dcd325528f38b..9531e534a61bc 100644
--- a/clang/lib/Headers/opencl-c.h
+++ b/clang/lib/Headers/opencl-c.h
@@ -6400,8 +6400,7 @@ size_t __ovld __cnfn get_local_id(uint dimindx);
  * Returns the number of work-groups that will execute a
  * kernel for dimension identified by dimindx.
  * Valid values of dimindx are 0 to get_work_dim() - 1.
- * For other values of dimindx, get_num_groups () returns
- * 1.
+ * For other values of dimindx, get_num_groups() returns 1.
  * For clEnqueueTask, this always returns 1.
  */
 size_t __ovld __cnfn get_num_groups(uint dimindx);



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

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:122
 
 #define FB(Name, K) MIX_##Name = (1ull << (K##ull - 1ull))
 

whisperity wrote:
> martong wrote:
> > FB stands for FunnyBitmask? Could you please either describe that in a 
> > comment or just spell it out?
> FlagBit. @alexfh suggested in the base check to use hexa literals. I'm not 
> too sold about that, but maybe we can cut the macro out and keep the bit 
> shift instructions in. Given that the check has more or less earned its final 
> form (for now), we know how many bits we need!
FlagBit, I like it, perhaps we should rename `FB` to `FlagBit`?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:182
+  /// The intermediate type after the first Standard Conversion Sequence.
+  QualType AfterPreStd;
+

whisperity wrote:
> martong wrote:
> > Maybe it's just me, but AfterPre sounds ambiguous and AfterPost seems 
> > redundant.
> Should I use "AfterFirstStandard" or "AfterFirstStd"?
> 
> AfterPost isn't redundant. An implicit conversion sequence might be of **3 
> steps**. Consider in a hypothetical `void f(Complex x, const double d)`.
> 
> `Complex` ---(PRE: std qual adjustment)--> `const Complex` ---(UD: user 
> defined conv)--> `double` ---(POST: std qual adjustment)--> `const double`
> 
> And because in case of many conversions a lot of combinations need to be 
> checked, we can't have `AfterPost` be the same as `End`. First, because of 
> the combinations, second, because of the //other// things the check is doing.
> 
> `void g(ComplexTypedef CT, ConstDoubleTypedef CDT);`
> 
> In this case, `Start` and `End` are the typedefs, and the inner sequence is 
> the same as before. And in order to generate the diagnostic, we also need to 
> have **both** pieces of information.
Thanks for this explanation, it makes clearer! However, this highlights that a 
way better description (in the form of comments) is needed for these `QualType` 
members. Especially this line could really increase the readability.
```
Complex ---(PRE: std qual adjustment)--> const Complex ---(UD: user defined 
conv)--> double ---(POST: std qual adjustment)--> const double
```

> In this case, Start and End are the typedefs, and the inner sequence is the 
> same as before. And in order to generate the diagnostic, we also need to have 
> both pieces of information.

I think it would be useful to document the cases with examples when `End` is 
not equal to `AfterPost` and such.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:210
+  /// the conversion sequence. This method does **NOT** return Begin and End.
+  SmallVector getInvolvedTypesInSequence() const {
+SmallVector Ret;

whisperity wrote:
> martong wrote:
> > So, we can never return with a vector with size > 4?
> `N` in `SmallVector` only specifies the pre-allocated smallness size. 
> AFAIK, if you have >N elements, it will just put the vector out onto the heap.
I meant the number 4, not SmallVector. So, is there a case when the conversion 
sequence is longer than 4? If it can be longer, then where do you store the 
types, you have 4 `QualType` members if I am not wrong. (Also, I am not an 
expert of conversions.) 

To be honest, it is so terrible that we cannot reuse [[ 
https://clang.llvm.org/doxygen/classclang_1_1StandardConversionSequence.html | 
clang::StandardConversionSequence ]]



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.h:42
 
-  /// Whether to consider an unqualified and a qualified type mixable.
+  /// Whether to consider differently qualified versions of the same type
+  /// mixable.

whisperity wrote:
> martong wrote:
> > "qualified"
> > Do you consider `volatile` here as well, or just `const`?
> Const, volatile, and in C mode, restrict, too.
Great!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

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

[PATCH] D103685: [clangd] Drop TestTUs dependency on gtest

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TestTU.cpp:75
+  if (llvm::sys::fs::createUniqueDirectory("module-cache", ModuleCachePath))
+llvm_unreachable("Failed to create temp directory for module-cache");
   CI.getHeaderSearchOpts().ModuleCachePath = ModuleCachePath.c_str();

I don't love using llvm_unreachable for error handling (esp environment 
sensitive kind like this), it compiles down to UB in ndebug mode.

Log + abort would be preferable I think, though it's one extra line.



Comment at: clang-tools-extra/clangd/unittests/TestTU.cpp:119
+llvm::errs() << "Failed to build code:\n" << Code;
 llvm_unreachable("Failed to build TestTU!");
   }

I think we should replace this one with abort() too now



Comment at: clang-tools-extra/clangd/unittests/TestTU.cpp:122
   if (!AST->getDiagnostics()) {
-ADD_FAILURE() << "TestTU should always build an AST with a fresh Preamble"
-  << Code;
+llvm::errs() << "TestTU should always build an AST with a fresh Preamble"
+ << Code;

this check is now a log message that could still let the test pass
Make it an assert instead?

(I think assert without any early return is appropriate per normal llvm style)



Comment at: clang-tools-extra/clangd/unittests/TestTU.cpp:148
 << Code;
 break; // Just report first error for simplicity.
   }

this needs to fail the test. abort()?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103685

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: rsmith, rjmccall.
aaron.ballman added inline comments.



Comment at: clang/docs/UsersManual.rst:1484
+   Where unsafe floating point optimizations are enabled, this option
+   determines whether the optimizer honors parentheses when floating-point
+   expressions are evaluated.  If unsafe floating point optimizations are

We may need to expound on what "honor parentheses" means. The summary for the 
patch mentions `(a + b) + c`, but does this also mean `(x + y) * z`  could be 
interpreted as `x + (y * z)`? What about for non-arithmetic expressions 
involving parentheses, like `(float1 == float2 && float1 == float3) || blah()`?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8480-8481
+def err_typecheck_expect_flt_or_vector : Error<
+  "operand of type %0 where floating, complex or "
+  "a vector of such types is required (%0 invalid)">;
 def err_cast_selector_expr : Error<





Comment at: clang/include/clang/Basic/TargetInfo.h:1427
 
+  /// Controls if __arithmetic_fence is supported in the targetted backend.
+  virtual bool checkArithmeticFenceSupported() const { return false; }





Comment at: clang/include/clang/Basic/TargetInfo.h:1162
   /// the language based on the target options where applicable.
-  virtual void adjust(LangOptions &Opts);
+  virtual void adjust(DiagnosticsEngine &Diags, LangOptions &Opts);
 

mibintc wrote:
> There's no good place to diagnose when LangOptions and TargetOptions 
> conflict, I see "conflict" diagnostics being emitted in clang/CodeGen when 
> creating the func or module, which seems wrong to me. On the other hand, the 
> "adjust" function makes a good place to do the reconciliation I think. This 
> is the change that could be pulled out in a refactoring and committed prior 
> to this patch. What do you think? 
I think this makes sense, but should be done as a separate patch.



Comment at: clang/include/clang/Driver/Options.td:1757
+  LangOpts<"ProtectParens">, DefaultFalse,
+  PosFlaggetArg(0);
+  if (Arg->isInstantiationDependent())
+return false;

What if there is no argument given?



Comment at: clang/lib/Sema/SemaChecking.cpp:6425
+
+  const QualType ArgTy = TheCall->getArg(0)->getType();
+  bool IsFloating = [&]() {





Comment at: clang/lib/Sema/SemaChecking.cpp:6427-6430
+if (const VectorType *VT = dyn_cast(ArgTy.getCanonicalType()))
+  return VT->getElementType().getTypePtr()->isFloatingType();
+if (const ComplexType *CT = 
dyn_cast(ArgTy.getCanonicalType()))
+  return CT->getElementType().getTypePtr()->isFloatingType();





Comment at: clang/lib/Sema/SemaChecking.cpp:6436-6437
+   << ArgTy;
+  if (checkArgCount(*this, TheCall, 1))
+return true;
+  TheCall->setType(ArgTy);

This looks like it should move up a bit.



Comment at: clang/lib/Sema/SemaCoroutine.cpp:387
   JustAddress = S.MaybeCreateExprWithCleanups(JustAddress);
-  return buildBuiltinCall(S, Loc, Builtin::BI__builtin_coro_resume,
-  JustAddress);
+  return S.BuildBuiltinCallExpr(Loc, Builtin::BI__builtin_coro_resume,
+JustAddress).get();

I am fine ignoring this clang-format issue; I think your formatting is far more 
readable.



Comment at: clang/lib/Sema/SemaExpr.cpp:4026
+  !E->isLValue() &&
+  (ExprTy->isFloatingType() || (ExprTy->isComplexType( {
+return BuildBuiltinCallExpr(R, Builtin::BI__arithmetic_fence, E);

Do you have to worry about vector types here as well?



Comment at: clang/lib/Sema/SemaExpr.cpp:4027
+  (ExprTy->isFloatingType() || (ExprTy->isComplexType( {
+return BuildBuiltinCallExpr(R, Builtin::BI__arithmetic_fence, E);
+  }

One worry I have about this is that the AST will be a bit mysterious for people 
writing AST matchers. The source code will have parens in it, but the AST will 
have a `ParenExpr` node or not only depending on the language options. This may 
also cause problems for other parts of the code that are checking for 
properly-parenthesized expressions (like && and || within the same expression), 
so we should probably have a test case like:
```
bool func(float f1, float f2, float f3) {
  return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
}
```



Comment at: clang/lib/Sema/SemaExpr.cpp:6535
+//  with the specified CallArgs
+ExprResult Sema::BuildBuiltinCallExpr(SourceLocation Loc, Builtin::ID Id,
+  MultiExprArg CallArgs) {

Because this cannot fail, is there a benefit to returning an `ExprResult` 
rather than an `Expr *` as before? Then you can remove a bunch of `ge

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

Perhaps all conversion related logic should go into their own implementation 
file? Seems like it adds up to roughly 1000 lines.




Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:1171
+   "conversion operator.\n");
+ImplicitSeq <<= ConversionOperatorResult.getValue();
+WorkType = ImplicitSeq.getTypeAfterUserDefinedConversion();

I think that these overloaded operators are not elevating the readability, 
since we are not dealing with mathematical classes.
IMHO, we could simply use `update` or something that is less crypto.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

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

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:550-551
+  if (isUselessSugar(LType.getTypePtr())) {
+LLVM_DEBUG(llvm::dbgs()
+   << "--- calculateMixability. LHS is useless sugar.\n");
 return calculateMixability(Check, LType.getSingleStepDesugaredType(Ctx),

Is this still WIP or do you use the DEBUG printouts in the tests? If not then 
could you please create a Diff without the DEBUG printouts, that could increase 
readability and ease the review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

question for @aaron.ballman




Comment at: clang/docs/UsersManual.rst:1484
+   Where unsafe floating point optimizations are enabled, this option
+   determines whether the optimizer honors parentheses when floating-point
+   expressions are evaluated.  If unsafe floating point optimizations are

aaron.ballman wrote:
> We may need to expound on what "honor parentheses" means. The summary for the 
> patch mentions `(a + b) + c`, but does this also mean `(x + y) * z`  could be 
> interpreted as `x + (y * z)`? What about for non-arithmetic expressions 
> involving parentheses, like `(float1 == float2 && float1 == float3) || 
> blah()`?
Thanks for your review. Just a quick first response, What do you mean "(x + y) 
* z could be reinterpreted as x + (y * z)" -- not following you here? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D75041: [clang-tidy] Extend 'bugprone-easily-swappable-parameters' with mixability because of implicit conversions

[Whisperity via Phabricator via cfe-commits]

whisperity marked 5 inline comments as done.
whisperity added a comment.

In D75041#2799023 , @martong wrote:

> Perhaps all conversion related logic should go into their own implementation 
> file? Seems like it adds up to roughly 1000 lines.

That's against the usual conventions of the project (1 TU for 1 check 
implementation). The methods are grouped by namespace, you can fold it up in 
your editor.




Comment at: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp:550-551
+  if (isUselessSugar(LType.getTypePtr())) {
+LLVM_DEBUG(llvm::dbgs()
+   << "--- calculateMixability. LHS is useless sugar.\n");
 return calculateMixability(Check, LType.getSingleStepDesugaredType(Ctx),

martong wrote:
> Is this still WIP or do you use the DEBUG printouts in the tests? If not then 
> could you please create a Diff without the DEBUG printouts, that could 
> increase readability and ease the review.
As discussed earlier (and perhaps in the previous patches), these debug 
printouts are needed and shall stay here. The output is not used //in 
automation//, but it's intended for people who might pick up on further 
developing the check later. The recursive descent is too complex to be 
handleable in your mind without the debug information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75041

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

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/docs/UsersManual.rst:1484
+   Where unsafe floating point optimizations are enabled, this option
+   determines whether the optimizer honors parentheses when floating-point
+   expressions are evaluated.  If unsafe floating point optimizations are

mibintc wrote:
> aaron.ballman wrote:
> > We may need to expound on what "honor parentheses" means. The summary for 
> > the patch mentions `(a + b) + c`, but does this also mean `(x + y) * z`  
> > could be interpreted as `x + (y * z)`? What about for non-arithmetic 
> > expressions involving parentheses, like `(float1 == float2 && float1 == 
> > float3) || blah()`?
> Thanks for your review. Just a quick first response, What do you mean "(x + 
> y) * z could be reinterpreted as x + (y * z)" -- not following you here? 
"whether the optimizer honors the parentheses" reads to me like `(x + y) * z` 
could either honor or not honor the parentheses, so that could either evaluate 
as `(x + y) * z` or `x + (y * z)` depending on whether the parens are honored 
or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D103587: [AIX] Transfer predefined macros

[Chris Bowler via Phabricator via cfe-commits]

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

I think it makes sense to split the __STDC macro changes and __TOS_AIX__ into 
different patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

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

[PATCH] D103612: [flang][driver] Add `-fno-unparse-typed-exprs`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 349868.
awarzynski added a comment.

Rebase on top of main, revert one small change uploaded accidentally


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/test/Driver/unparse-typed-exprs.f95
  flang/tools/f18/f18.cpp
  flang/tools/f18/flang

Index: flang/tools/f18/flang
===
--- flang/tools/f18/flang
+++ flang/tools/f18/flang
@@ -8,7 +8,7 @@
 #======#
 
 wd=$(cd $(dirname "$0")/.. && pwd)
-opts="-module-suffix .f18.mod "
+opts="-fno-unparse-typed-exprs -module-suffix .f18.mod "
 if ! $wd/bin/f18 $opts "$@"
 then status=$?
  echo flang: in $PWD, f18 failed with exit status $status: $wd/bin/f18 $opts "$@" >&2
Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -105,7 +105,7 @@
   bool debugModuleWriter{false};
   bool defaultReal8{false};
   bool measureTree{false};
-  bool unparseTypedExprsToF18_FC{false};
+  bool unparseTypedExprs{true};
   std::vector F18_FCArgs;
   const char *prefix{nullptr};
   bool getDefinition{false};
@@ -322,7 +322,8 @@
 Unparse(llvm::outs(), parseTree, driver.encoding, true /*capitalize*/,
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
-nullptr /* action before each statement */, &asFortran);
+nullptr /* action before each statement */,
+driver.unparseTypedExprs ? &asFortran : nullptr);
 return {};
   }
   if (driver.dumpPreFirTree) {
@@ -353,7 +354,7 @@
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
 nullptr /* action before each statement */,
-driver.unparseTypedExprsToF18_FC ? &asFortran : nullptr);
+driver.unparseTypedExprs ? &asFortran : nullptr);
   }
 
   RunOtherCompiler(driver, tmpSourcePath.data(), relo.data());
@@ -578,8 +579,8 @@
 } else if (arg == "-funparse-with-symbols" ||
 arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
-} else if (arg == "-funparse-typed-exprs-to-f18-fc") {
-  driver.unparseTypedExprsToF18_FC = true;
+} else if (arg == "-fno-unparse-typed-exprs") {
+  driver.unparseTypedExprs = false;
 } else if (arg == "-fparse-only" || arg == "-fsyntax-only") {
   driver.syntaxOnly = true;
 } else if (arg == "-c") {
Index: flang/test/Driver/unparse-typed-exprs.f95
===
--- /dev/null
+++ flang/test/Driver/unparse-typed-exprs.f95
@@ -0,0 +1,34 @@
+! Tests `-fno-unparse-typed-exprs-to-f18-fc` frontend option
+
+!--
+! RUN lines
+!--
+! RUN: %flang_fc1 -fdebug-unparse  %s | FileCheck %s --check-prefix=UNPARSED_TYPED_EXPR
+! RUN: %flang_fc1 -fdebug-unparse -fno-unparse-typed-exprs %s | FileCheck %s --check-prefix=AS_FORTRAN
+
+!--
+! EXPECTED OUTPUT: default
+!--
+! UNPARSED_TYPED_EXPR: PROGRAM test_allocated
+! UNPARSED_TYPED_EXPR-NEXT:  INTEGER :: i = 4_4
+! UNPARSED_TYPED_EXPR-NEXT:  REAL(KIND=4_4), ALLOCATABLE :: x(:)
+! UNPARSED_TYPED_EXPR-NEXT:  IF (.NOT.allocated(x)) ALLOCATE(x(i))
+! UNPARSED_TYPED_EXPR-NEXT: END PROGRAM test_allocated
+
+!-
+! EXPECTED OUTPUT: unparsed as Fortran
+!--
+! AS_FORTRAN: PROGRAM test_allocated
+! AS_FORTRAN-NEXT:  INTEGER :: i = 4
+! AS_FORTRAN-NEXT:  REAL(KIND=4), ALLOCATABLE :: x(:)
+! AS_FORTRAN-NEXT:  IF (.NOT.allocated(x)) ALLOCATE(x(i))
+! AS_FORTRAN-NEXT: END PROGRAM test_allocated
+
+!--
+! INPUT
+!--
+program test_allocated
+  integer :: i = 4
+  real(4), allocatable :: x(:)
+  if (.not. allocated(x)) allocate(x(i))
+end program test_allocated
Index: flang/lib/Frontend/FrontendOptions.cpp
===
--- flang/lib/Frontend/FrontendOptions.cpp
+++ flang/lib/Frontend/FrontendOptions.cpp
@@ -32,34 +32,6 @@
   suffix == "F03" || suffix == "F08" || suffix == "F18";
 }
 
-// TODO: This is a copy of `asFortran` from f18.cpp and is added here for
-// compatiblity. It doesn't really belong here, but I couldn't find a better
-// place. We should decide whether to add it to the Evaluate or Parse/Unparse
-// APIs or some dedicated utility library in the driver.
-Fortran::parser::AnalyzedObjectsAsFortran
-Fortran::frontend::getBasicAsFortran() {
-  return Fort

[clang] 827b5c2 - [OPENMP]Fix PR49790: Constexpr values not handled in `omp declare mapper` clause.

[Alexey Bataev via cfe-commits]

Author: Alexey Bataev
Date: 2021-06-04T07:32:14-07:00
New Revision: 827b5c21545aaa820403e9b5cced8c0181349ee2

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

LOG: [OPENMP]Fix PR49790: Constexpr values not handled in `omp declare mapper` 
clause.

Patch allows using of constexpr vars evaluatable to constant calue to be
used in declare mapper construct.

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

Added: 


Modified: 
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/declare_mapper_ast_print.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 2fcc3fb4317e7..514b3b9ed05fe 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -19681,8 +19681,13 @@ Sema::ActOnOpenMPDeclareMapperDirectiveVarDecl(Scope 
*S, QualType MapperType,
 bool Sema::isOpenMPDeclareMapperVarDeclAllowed(const VarDecl *VD) const {
   assert(LangOpts.OpenMP && "Expected OpenMP mode.");
   const Expr *Ref = DSAStack->getDeclareMapperVarRef();
-  if (const auto *DRE = cast_or_null(Ref))
-return VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl();
+  if (const auto *DRE = cast_or_null(Ref)) {
+if (VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl())
+  return true;
+if (VD->isUsableInConstantExpressions(Context))
+  return true;
+return false;
+  }
   return true;
 }
 

diff  --git a/clang/test/OpenMP/declare_mapper_ast_print.cpp 
b/clang/test/OpenMP/declare_mapper_ast_print.cpp
index 6462fa38d872d..b9445ca35a0ca 100644
--- a/clang/test/OpenMP/declare_mapper_ast_print.cpp
+++ b/clang/test/OpenMP/declare_mapper_ast_print.cpp
@@ -56,8 +56,9 @@ class dat {
 // CHECK: #pragma omp declare mapper (id : dat::datin v) map(tofrom: 
v.in){{$}}
 // CHECK: };
 
-#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:2])
-// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: 
kk.len) map(tofrom: kk.data[0:2]){{$}}
+constexpr int N = 2;
+#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:N])
+// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: 
kk.len) map(tofrom: kk.data[0:N]){{$}}
 #pragma omp declare mapper(dat d) map(to: d.d)
 // CHECK: #pragma omp declare mapper (default : dat d) map(to: 
d.d){{$}}
 



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

[PATCH] D103642: [OPENMP]Fix PR49790: Constexpr values not handled in `omp declare mapper` clause.

[Alexey Bataev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG827b5c21545a: [OPENMP]Fix PR49790: Constexpr values not 
handled in `omp declare mapper`… (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103642

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/declare_mapper_ast_print.cpp


Index: clang/test/OpenMP/declare_mapper_ast_print.cpp
===
--- clang/test/OpenMP/declare_mapper_ast_print.cpp
+++ clang/test/OpenMP/declare_mapper_ast_print.cpp
@@ -56,8 +56,9 @@
 // CHECK: #pragma omp declare mapper (id : dat::datin v) map(tofrom: 
v.in){{$}}
 // CHECK: };
 
-#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:2])
-// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: 
kk.len) map(tofrom: kk.data[0:2]){{$}}
+constexpr int N = 2;
+#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:N])
+// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: 
kk.len) map(tofrom: kk.data[0:N]){{$}}
 #pragma omp declare mapper(dat d) map(to: d.d)
 // CHECK: #pragma omp declare mapper (default : dat d) map(to: 
d.d){{$}}
 
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -19681,8 +19681,13 @@
 bool Sema::isOpenMPDeclareMapperVarDeclAllowed(const VarDecl *VD) const {
   assert(LangOpts.OpenMP && "Expected OpenMP mode.");
   const Expr *Ref = DSAStack->getDeclareMapperVarRef();
-  if (const auto *DRE = cast_or_null(Ref))
-return VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl();
+  if (const auto *DRE = cast_or_null(Ref)) {
+if (VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl())
+  return true;
+if (VD->isUsableInConstantExpressions(Context))
+  return true;
+return false;
+  }
   return true;
 }
 


Index: clang/test/OpenMP/declare_mapper_ast_print.cpp
===
--- clang/test/OpenMP/declare_mapper_ast_print.cpp
+++ clang/test/OpenMP/declare_mapper_ast_print.cpp
@@ -56,8 +56,9 @@
 // CHECK: #pragma omp declare mapper (id : dat::datin v) map(tofrom: v.in){{$}}
 // CHECK: };
 
-#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:2])
-// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: kk.len) map(tofrom: kk.data[0:2]){{$}}
+constexpr int N = 2;
+#pragma omp declare mapper(default : N1::vec kk) map(kk.len) map(kk.data[0:N])
+// CHECK: #pragma omp declare mapper (default : N1::vec kk) map(tofrom: kk.len) map(tofrom: kk.data[0:N]){{$}}
 #pragma omp declare mapper(dat d) map(to: d.d)
 // CHECK: #pragma omp declare mapper (default : dat d) map(to: d.d){{$}}
 
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -19681,8 +19681,13 @@
 bool Sema::isOpenMPDeclareMapperVarDeclAllowed(const VarDecl *VD) const {
   assert(LangOpts.OpenMP && "Expected OpenMP mode.");
   const Expr *Ref = DSAStack->getDeclareMapperVarRef();
-  if (const auto *DRE = cast_or_null(Ref))
-return VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl();
+  if (const auto *DRE = cast_or_null(Ref)) {
+if (VD->getCanonicalDecl() == DRE->getDecl()->getCanonicalDecl())
+  return true;
+if (VD->isUsableInConstantExpressions(Context))
+  return true;
+return false;
+  }
   return true;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103646: [OPENMP]Fix PR50129: omp cancel parallel not working as expected.

[Johannes Doerfert via Phabricator via cfe-commits]

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

LG, one nit below.




Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:538
+omp::Directive CanceledDirective,
+FinalizeCallbackTy ExitCB = {});
 

The documentation doesn't match the prototype.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103646

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

[clang] f917c5b - Revert test fixups after e9a9c850989e (which reverted a14fc74).

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-06-04T10:42:25-04:00
New Revision: f917c5b8d40b7894d52d56052bb18f8e989bad9e

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

LOG: Revert test fixups after e9a9c850989e (which reverted a14fc74).

This reverts commit da3ed58b97c1cc1356b7732d5dcbb6e4de3057da.
This reverts commit ba1fb0ff8c9f9ef7f9b7d1fe43cb95c8d1363f78.

Added: 


Modified: 
clang/test/Profile/c-linkage-available_externally.c
clang/test/Profile/c-linkage.c
clang/test/Profile/cxx-linkage.cpp

Removed: 




diff  --git a/clang/test/Profile/c-linkage-available_externally.c 
b/clang/test/Profile/c-linkage-available_externally.c
index c8dd9fc40a18a..5ac777b267ab8 100644
--- a/clang/test/Profile/c-linkage-available_externally.c
+++ b/clang/test/Profile/c-linkage-available_externally.c
@@ -3,7 +3,7 @@
 // RUN: %clang_cc1 -O2 -triple x86_64-apple-macosx10.9 -main-file-name 
c-linkage-available_externally.c %s -o - -emit-llvm -fprofile-instrument=clang 
| FileCheck %s
 
 // CHECK: @__profc_foo = linkonce_odr hidden global [1 x i64] zeroinitializer, 
section "__DATA,__llvm_prf_cnts", align 8
-// CHECK: @__profd_foo = private global {{.*}} i64* getelementptr inbounds ([1 
x i64], [1 x i64]* @__profc_foo, i32 0, i32 0){{.*}}, section 
"__DATA,__llvm_prf_data,regular,live_support", align 8
+// CHECK: @__profd_foo = linkonce_odr hidden global {{.*}} i64* getelementptr 
inbounds ([1 x i64], [1 x i64]* @__profc_foo, i32 0, i32 0){{.*}}, section 
"__DATA,__llvm_prf_data,regular,live_support", align 8
 inline int foo(void) { return 1; }
 
 int main(void) {

diff  --git a/clang/test/Profile/c-linkage.c b/clang/test/Profile/c-linkage.c
index 7a607e7237215..50ac558fb0761 100644
--- a/clang/test/Profile/c-linkage.c
+++ b/clang/test/Profile/c-linkage.c
@@ -4,7 +4,7 @@
 // CHECK: @__profc_foo = private global
 // CHECK: @__profd_foo = private global
 // CHECK: @__profc_foo_weak = weak hidden global
-// CHECK: @__profd_foo_weak = private global
+// CHECK: @__profd_foo_weak = weak hidden global
 // CHECK: @__profc_main = private global
 // CHECK: @__profd_main = private global
 // CHECK: @__profc_c_linkage.c_foo_internal = private global

diff  --git a/clang/test/Profile/cxx-linkage.cpp 
b/clang/test/Profile/cxx-linkage.cpp
index 99537c0e027ea..6f7b2b7128e9f 100644
--- a/clang/test/Profile/cxx-linkage.cpp
+++ b/clang/test/Profile/cxx-linkage.cpp
@@ -3,11 +3,11 @@
 // CHECK: @__profc__Z3foov = private global
 // CHECK: @__profd__Z3foov = private global
 // CHECK: @__profc__Z8foo_weakv = weak hidden global
-// CHECK: @__profd__Z8foo_weakv = private global
+// CHECK: @__profd__Z8foo_weakv = weak hidden global
 // CHECK: @__profc_main = private global
 // CHECK: @__profd_main = private global
 // CHECK: @__profc__Z10foo_inlinev = linkonce_odr hidden global
-// CHECK: @__profd__Z10foo_inlinev = private global
+// CHECK: @__profd__Z10foo_inlinev = linkonce_odr hidden global
 
 void foo(void) { }
 



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

[PATCH] D103538: [clangd] Run code completion on each token coverd by --check-lines

[Adam Czachorowski via Phabricator via cfe-commits]

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

I didn't put much thought into where --check-lines goes. It's an interesting 
thought.

I think having all the flags in one place is more valuable than trying to split 
them in some way. We contain all flags in the same place, close to main() and 
check() gets all it's data from arguments, rather than some side channel. It 
makes check() easier to re-use and/or test.  It also allows us to complain 
about flag misuse, such as specifying --check-lines without --check, etc.

I'm going to commit as-is, since you LGTMed this, but feel free to continue 
discussion here and if we decide to move the flags somewhere else I'll happily 
submit another change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103538

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

[PATCH] D103538: [clangd] Run code completion on each token coverd by --check-lines

[Adam Czachorowski via Phabricator via cfe-commits]

adamcz updated this revision to Diff 349878.
adamcz added a comment.

review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103538

Files:
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -62,7 +62,8 @@
 // Implemented in Check.cpp.
 bool check(const llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts);
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion);
 
 namespace {
 
@@ -929,7 +930,11 @@
   uint32_t Line = Pos.line + 1; // Position::line is 0-based.
   return Line >= Begin && Line <= End;
 };
-return check(Path, ShouldCheckLine, TFS, Opts)
+// For now code completion is enabled any time the range is limited via
+// --check-lines. If it turns out to be to slow, we can introduce a
+// dedicated flag for that instead.
+return check(Path, ShouldCheckLine, TFS, Opts,
+ /*EnableCodeCompletion=*/!CheckFileLines.empty())
? 0
: static_cast(ErrorResultCode::CheckFailed);
   }
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -193,10 +193,15 @@
 
   // Run AST-based features at each token in the file.
   void testLocationFeatures(
-  llvm::function_ref ShouldCheckLine) {
+  llvm::function_ref ShouldCheckLine,
+  const bool EnableCodeCompletion) {
 log("Testing features at each token (may be slow in large files)");
 auto &SM = AST->getSourceManager();
 auto SpelledTokens = AST->getTokens().spelledTokens(SM.getMainFileID());
+
+CodeCompleteOptions CCOpts = Opts.CodeComplete;
+CCOpts.Index = &Index;
+
 for (const auto &Tok : SpelledTokens) {
   unsigned Start = AST->getSourceManager().getFileOffset(Tok.location());
   unsigned End = Start + Tok.length();
@@ -228,8 +233,12 @@
   auto Hover = getHover(*AST, Pos, Style, &Index);
   vlog("hover: {0}", Hover.hasValue());
 
-  // FIXME: it'd be nice to include code completion, but it's too slow.
-  // Maybe in combination with a line restriction?
+  if (EnableCodeCompletion) {
+Position EndPos = offsetToPosition(Inputs.Contents, End);
+auto CC = codeComplete(File, EndPos, Preamble.get(), Inputs, CCOpts);
+vlog("code completion: {0}",
+ CC.Completions.empty() ? "" : CC.Completions[0].Name);
+  }
 }
   }
 };
@@ -238,7 +247,8 @@
 
 bool check(llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts) {
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion) {
   llvm::SmallString<0> FakeFile;
   llvm::Optional Contents;
   if (File.empty()) {
@@ -262,7 +272,7 @@
   if (!C.buildCommand(TFS) || !C.buildInvocation(TFS, Contents) ||
   !C.buildAST())
 return false;
-  C.testLocationFeatures(ShouldCheckLine);
+  C.testLocationFeatures(ShouldCheckLine, EnableCodeCompletion);
 
   log("All checks completed, {0} errors", C.ErrCount);
   return C.ErrCount == 0;


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -62,7 +62,8 @@
 // Implemented in Check.cpp.
 bool check(const llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts);
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion);
 
 namespace {
 
@@ -929,7 +930,11 @@
   uint32_t Line = Pos.line + 1; // Position::line is 0-based.
   return Line >= Begin && Line <= End;
 };
-return check(Path, ShouldCheckLine, TFS, Opts)
+// For now code completion is enabled any time the range is limited via
+// --check-lines. If it turns out to be to slow, we can introduce a
+// dedicated flag for that instead.
+return check(Path, ShouldCheckLine, TFS, Opts,
+ /*EnableCodeCompletion=*/!CheckFileLines.empty())
? 0
: static_cast(ErrorResultCode::CheckFailed);
   }
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Chec

[PATCH] D103664: [Windows SEH]: Fix -O2 crash for Windows -EHa

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added a comment.

wco




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:7155
-if (EH.Asynch)
-  CmdArgs.push_back("-fasync-exceptions");
   }

Not really sure I understand this change. Isn't the case that if I compile with 
-EHa, I want the -fasync-exceptions option to be added to my options?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103664

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

[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

[Jonathan Peyton via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D97085

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

[PATCH] D99540: [clangd] Preserve diags between tweak enumeration and execution

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

> Sorry I've lost my context - did we decide to move forward with this patch?

I don't think we've came to a conclusion, just decided to postpone until 
needed. I believe the `cases` design is really a good fit for making tweaks 
expose multiple code actions.

But we've actually missed one thing while discussing this patch. It actually 
allows data from `clang::Diagnostic` to be stashed into `clangd::Diag` for use 
later on. Modules can actually stash this info while the AST is being built, 
later on they can be retrieved directly from the `ParsedAST::getDiagnostics()`. 
But this creates the N*M problem again, and feels like a hack.
What we can do instead is during `enumerateTweak`, we can group `data` in 
diagnostics (making sure `data` stored in `diagnostic` is keyed by `tweak::id`) 
and pass an additional array of json objects in `tweak::prepare`.  This will 
make the problem N+M again and make the data passing explicit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99540

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

[PATCH] D103612: [flang][driver] Add `-fno-unparse-typed-exprs`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 349881.
awarzynski added a comment.

Fix build and test failure


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Driver/unparse-typed-exprs.f95
  flang/tools/f18/f18.cpp
  flang/tools/f18/flang

Index: flang/tools/f18/flang
===
--- flang/tools/f18/flang
+++ flang/tools/f18/flang
@@ -8,7 +8,7 @@
 #======#
 
 wd=$(cd $(dirname "$0")/.. && pwd)
-opts="-module-suffix .f18.mod "
+opts="-fno-unparse-typed-exprs -module-suffix .f18.mod "
 if ! $wd/bin/f18 $opts "$@"
 then status=$?
  echo flang: in $PWD, f18 failed with exit status $status: $wd/bin/f18 $opts "$@" >&2
Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -105,7 +105,7 @@
   bool debugModuleWriter{false};
   bool defaultReal8{false};
   bool measureTree{false};
-  bool unparseTypedExprsToF18_FC{false};
+  bool unparseTypedExprs{true};
   std::vector F18_FCArgs;
   const char *prefix{nullptr};
   bool getDefinition{false};
@@ -322,7 +322,8 @@
 Unparse(llvm::outs(), parseTree, driver.encoding, true /*capitalize*/,
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
-nullptr /* action before each statement */, &asFortran);
+nullptr /* action before each statement */,
+driver.unparseTypedExprs ? &asFortran : nullptr);
 return {};
   }
   if (driver.dumpPreFirTree) {
@@ -353,7 +354,7 @@
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
 nullptr /* action before each statement */,
-driver.unparseTypedExprsToF18_FC ? &asFortran : nullptr);
+driver.unparseTypedExprs ? &asFortran : nullptr);
   }
 
   RunOtherCompiler(driver, tmpSourcePath.data(), relo.data());
@@ -578,8 +579,8 @@
 } else if (arg == "-funparse-with-symbols" ||
 arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
-} else if (arg == "-funparse-typed-exprs-to-f18-fc") {
-  driver.unparseTypedExprsToF18_FC = true;
+} else if (arg == "-fno-unparse-typed-exprs") {
+  driver.unparseTypedExprs = false;
 } else if (arg == "-fparse-only" || arg == "-fsyntax-only") {
   driver.syntaxOnly = true;
 } else if (arg == "-c") {
Index: flang/test/Driver/unparse-typed-exprs.f95
===
--- /dev/null
+++ flang/test/Driver/unparse-typed-exprs.f95
@@ -0,0 +1,34 @@
+! Tests `-fno-unparse-typed-exprs-to-f18-fc` frontend option
+
+!--
+! RUN lines
+!--
+! RUN: %flang_fc1 -fdebug-unparse  %s | FileCheck %s --check-prefix=UNPARSED_TYPED_EXPR
+! RUN: %flang_fc1 -fdebug-unparse -fno-unparse-typed-exprs %s | FileCheck %s --check-prefix=AS_FORTRAN
+
+!--
+! EXPECTED OUTPUT: default
+!--
+! UNPARSED_TYPED_EXPR: PROGRAM test_allocated
+! UNPARSED_TYPED_EXPR-NEXT:  INTEGER :: i = 4_4
+! UNPARSED_TYPED_EXPR-NEXT:  REAL(KIND=4_4), ALLOCATABLE :: x(:)
+! UNPARSED_TYPED_EXPR-NEXT:  IF (.NOT.allocated(x)) ALLOCATE(x(i))
+! UNPARSED_TYPED_EXPR-NEXT: END PROGRAM test_allocated
+
+!-
+! EXPECTED OUTPUT: unparsed as Fortran
+!--
+! AS_FORTRAN: PROGRAM test_allocated
+! AS_FORTRAN-NEXT:  INTEGER :: i = 4
+! AS_FORTRAN-NEXT:  REAL(KIND=4), ALLOCATABLE :: x(:)
+! AS_FORTRAN-NEXT:  IF (.NOT.allocated(x)) ALLOCATE(x(i))
+! AS_FORTRAN-NEXT: END PROGRAM test_allocated
+
+!--
+! INPUT
+!--
+program test_allocated
+  integer :: i = 4
+  real(4), allocatable :: x(:)
+  if (.not. allocated(x)) allocate(x(i))
+end program test_allocated
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -100,6 +100,8 @@
 ! HELP-FC1-NEXT:Specify where to find the compiled intrinsic modules
 ! HELP-FC1-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type in size-related intrinsics
 ! HELP-FC1-NEXT: -flogical-abbreviations Enable logical abbreviations
+! HELP-FC1-NEXT: -fno-unparse-typed-exprs
+! HELP-FC1-NEXT:Don't unparse typed expressions
 ! HELP-FC1-NEXT: -fopenacc  Enable OpenACC
 ! HELP-FC1-NEXT: -fopenmp 

[PATCH] D99459: [OpenMP] Implement '#pragma omp unroll'.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:12821
+/// Determine whether an expression is constant without emitting diagnostic.
+static bool isConstantExpression(Sema &SemaRef, Expr *E) {
+  struct ConstTripcountDiagnoser : public Sema::VerifyICEDiagnoser {

Meinersbur wrote:
> ABataev wrote:
> > Can you use `VerifyPositiveIntegerConstantInClause` function instead?
> The reason for this new function is that 
> `VerifyPositiveIntegerConstantInClause` also emits a note on why it is not a 
> constant expression:
> ```
> note: read of non-const variable '.capture_expr.' is not allowed in a 
> constant expression
> ```
> Printing internal variable names is more confusing than helpful to the user.
Maybe expand `VerifyPositiveIntegerConstantInClause` to exclude this rather 
than add a new function?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99459

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

[PATCH] D103097: Add DWARF address spaces mapping for SPIR

[Stuart Brady via Phabricator via cfe-commits]

stuart added inline comments.



Comment at: clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl:22
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar5", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_GLOBAL]], 
isLocal: false, isDefinition: true)
+global int *global FileVar5;
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar6", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_CONSTANT]], 
isLocal: false, isDefinition: true)

Anastasia wrote:
> btw this variable is a duplicate of `FileVar0` for your change. In clang 
> parser:
> `global int *ptr;`
> is the same as 
> `global int *global ptr;`
> 
> 
> The same applies to local variables of `Type *` and `Type *private` as they 
> are equivalent on AST level too.
> 
> This is due to the address space inference rules if you are interested in 
> more details: 
> https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference
> 
> Perhaps you could reduce the test case a bit by removing the duplicate 
> testing?
> 
> Also I would suggest separating with empty lines every variable declaration 
> with its corresponding CHECK line to improve the readability.
> 
> 
> ```
> CHECK: <...>
> Type var1;
> 
> CHECK: <...>
> Type var2;
> ```
> 
In case this review feeds into changes made for other test files, it may be 
worth noting that the test in question uses OpenCL C 2.0 (`-cl-std=CL2.0`), and 
therefore the generic address space as the default in many contexts, rather 
than `private`. (This comment is made not for direct benefit for this review 
itself, but for the benefit of anyone who may be reading who is not already 
especially familiar with OpenCL address spaces.)

The duplicated testing has now been removed from the newly added test, though.


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

https://reviews.llvm.org/D103097

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

[PATCH] D97699: [analyzer] Add InvalidPtrChecker

[Balázs Kéri via Phabricator via cfe-commits]

balazske added a comment.

I have not too deep knowledge about checker development but still found 
(hopefully valid) issues, even if only a part of them.




Comment at: clang/docs/analyzer/checkers.rst:2117
+// envp may no longer point to the current environment
+// this program has unanticipated behavior, since envp
+// does not reflect changes made by setenv function.

From my understanding the "unanticipated behavior" here is clearly a bug: We do 
not know if the `envp` points to any valid location. It is not guaranteed that 
the original value is preserved (in this case it would have sense to use it). 
And it is not known if it will point to the new and correct array. Unless we 
know how the internal implementation exactly works.



Comment at: clang/include/clang/StaticAnalyzer/Checkers/Checkers.td:947
+
+} // end "alpha.cert.env"
+

I have multiple issues with the documentation texts but they look not final 
anyway. And the package and checker names could be better. There are already 
checkers for CERT rules that do not reside in the cert package, it is not good 
to have some checkers in a `cert` package and some not. It is likely that 
checkers will check for more rules or parts of the rules. Checker aliases are a 
better solution for the cert checker names. (And now the `cert` would contain 
checker with name not matching a rule: `InvalidPtr`.) The name `InvalidPtr` 
sounds too general, even if in an `env˙ package.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:28
+// pointer. These functions include: getenv, localeconv, asctime, setlocale,
+// strerror
+//===--===//

I think we do not need to repeat the documentation here.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:180
+// Note: This pointer has type 'const MemRegion *'
+REGISTER_TRAIT_WITH_PROGRAMSTATE(EnvPtrRegion, const void *)
+

Is it not possible to use `const MemRegion *` then?



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:192
+  return false;
+}
+

`evalCall` should be used only if the called function is exclusively modeled by 
this checker which is not the case here. The `checkPostCall` should be 
sufficient instead of `evalCall`.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:227
+  if (const auto *Reg =
+  State->get(FunctionName.data())) {
+const auto *PrevReg = *Reg;

`auto` is not to be used if the type is not clearly visible in the context. And 
this would be exactly `auto **` here. (But better is `const MemRegion **`.) 
Makes the later statement (assign to `PrevReg`) "messy" (and `auto` is bad 
there too).



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:227
+  if (const auto *Reg =
+  State->get(FunctionName.data())) {
+const auto *PrevReg = *Reg;

balazske wrote:
> `auto` is not to be used if the type is not clearly visible in the context. 
> And this would be exactly `auto **` here. (But better is `const MemRegion 
> **`.) Makes the later statement (assign to `PrevReg`) "messy" (and `auto` is 
> bad there too).
`.data` is unnecessary here?



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:319
+C.emitReport(std::move(Report));
+C.addTransition(State);
+  }

`addTransition` is not needed here, the state was not modified.
Save the error node returned by `generateNonFatalErrorNode` and pass it to the 
next call of `generateNonFatalErrorNode` as the `Pred` parameter.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:341
+  State = State->set(
+  reinterpret_cast(const_cast(EnvpReg)));
+  C.addTransition(State);

Are these casts really needed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97699

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

[clang-tools-extra] eba3ee0 - [clangd] Run code completion on each token coverd by --check-lines

[Adam Czachorowski via cfe-commits]

Author: Adam Czachorowski
Date: 2021-06-04T17:51:42+02:00
New Revision: eba3ee04d450230f7ac1f88b1abd7b09c600c82d

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

LOG: [clangd] Run code completion on each token coverd by --check-lines

In --check mode we do not run code completion because it is too slow,
especially on larger files. With the introducation of --check-lines we
can narrow down the scope and thus we can afford to do code completion.

We vlog() the top completion result, but that's not really the point.
The most value will come from being able to reproduce crashes that occur
during code completion and require preamble build or index (and thus are
more difficult to reproduce with -code-complete-at).

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

Added: 


Modified: 
clang-tools-extra/clangd/tool/Check.cpp
clang-tools-extra/clangd/tool/ClangdMain.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/tool/Check.cpp 
b/clang-tools-extra/clangd/tool/Check.cpp
index 89487bd8607f1..88eb945d20d43 100644
--- a/clang-tools-extra/clangd/tool/Check.cpp
+++ b/clang-tools-extra/clangd/tool/Check.cpp
@@ -193,10 +193,15 @@ class Checker {
 
   // Run AST-based features at each token in the file.
   void testLocationFeatures(
-  llvm::function_ref ShouldCheckLine) {
+  llvm::function_ref ShouldCheckLine,
+  const bool EnableCodeCompletion) {
 log("Testing features at each token (may be slow in large files)");
 auto &SM = AST->getSourceManager();
 auto SpelledTokens = AST->getTokens().spelledTokens(SM.getMainFileID());
+
+CodeCompleteOptions CCOpts = Opts.CodeComplete;
+CCOpts.Index = &Index;
+
 for (const auto &Tok : SpelledTokens) {
   unsigned Start = AST->getSourceManager().getFileOffset(Tok.location());
   unsigned End = Start + Tok.length();
@@ -233,8 +238,12 @@ class Checker {
   auto Hover = getHover(*AST, Pos, Style, &Index);
   vlog("hover: {0}", Hover.hasValue());
 
-  // FIXME: it'd be nice to include code completion, but it's too slow.
-  // Maybe in combination with a line restriction?
+  if (EnableCodeCompletion) {
+Position EndPos = offsetToPosition(Inputs.Contents, End);
+auto CC = codeComplete(File, EndPos, Preamble.get(), Inputs, CCOpts);
+vlog("code completion: {0}",
+ CC.Completions.empty() ? "" : CC.Completions[0].Name);
+  }
 }
   }
 };
@@ -243,7 +252,8 @@ class Checker {
 
 bool check(llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts) {
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion) {
   llvm::SmallString<0> FakeFile;
   llvm::Optional Contents;
   if (File.empty()) {
@@ -267,7 +277,7 @@ bool check(llvm::StringRef File,
   if (!C.buildCommand(TFS) || !C.buildInvocation(TFS, Contents) ||
   !C.buildAST())
 return false;
-  C.testLocationFeatures(ShouldCheckLine);
+  C.testLocationFeatures(ShouldCheckLine, EnableCodeCompletion);
 
   log("All checks completed, {0} errors", C.ErrCount);
   return C.ErrCount == 0;

diff  --git a/clang-tools-extra/clangd/tool/ClangdMain.cpp 
b/clang-tools-extra/clangd/tool/ClangdMain.cpp
index f0aa89b8091fb..0f9e5c89e42c8 100644
--- a/clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ b/clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -62,7 +62,8 @@ namespace clangd {
 // Implemented in Check.cpp.
 bool check(const llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts);
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion);
 
 namespace {
 
@@ -929,7 +930,11 @@ clangd accepts flags on the commandline, and in the 
CLANGD_FLAGS environment var
   uint32_t Line = Pos.line + 1; // Position::line is 0-based.
   return Line >= Begin && Line <= End;
 };
-return check(Path, ShouldCheckLine, TFS, Opts)
+// For now code completion is enabled any time the range is limited via
+// --check-lines. If it turns out to be to slow, we can introduce a
+// dedicated flag for that instead.
+return check(Path, ShouldCheckLine, TFS, Opts,
+ /*EnableCodeCompletion=*/!CheckFileLines.empty())
? 0
: static_cast(ErrorResultCode::CheckFailed);
   }



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

[PATCH] D103538: [clangd] Run code completion on each token coverd by --check-lines

[Adam Czachorowski via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGeba3ee04d450: [clangd] Run code completion on each token 
coverd by --check-lines (authored by adamcz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103538

Files:
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -62,7 +62,8 @@
 // Implemented in Check.cpp.
 bool check(const llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts);
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion);
 
 namespace {
 
@@ -929,7 +930,11 @@
   uint32_t Line = Pos.line + 1; // Position::line is 0-based.
   return Line >= Begin && Line <= End;
 };
-return check(Path, ShouldCheckLine, TFS, Opts)
+// For now code completion is enabled any time the range is limited via
+// --check-lines. If it turns out to be to slow, we can introduce a
+// dedicated flag for that instead.
+return check(Path, ShouldCheckLine, TFS, Opts,
+ /*EnableCodeCompletion=*/!CheckFileLines.empty())
? 0
: static_cast(ErrorResultCode::CheckFailed);
   }
Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -193,10 +193,15 @@
 
   // Run AST-based features at each token in the file.
   void testLocationFeatures(
-  llvm::function_ref ShouldCheckLine) {
+  llvm::function_ref ShouldCheckLine,
+  const bool EnableCodeCompletion) {
 log("Testing features at each token (may be slow in large files)");
 auto &SM = AST->getSourceManager();
 auto SpelledTokens = AST->getTokens().spelledTokens(SM.getMainFileID());
+
+CodeCompleteOptions CCOpts = Opts.CodeComplete;
+CCOpts.Index = &Index;
+
 for (const auto &Tok : SpelledTokens) {
   unsigned Start = AST->getSourceManager().getFileOffset(Tok.location());
   unsigned End = Start + Tok.length();
@@ -233,8 +238,12 @@
   auto Hover = getHover(*AST, Pos, Style, &Index);
   vlog("hover: {0}", Hover.hasValue());
 
-  // FIXME: it'd be nice to include code completion, but it's too slow.
-  // Maybe in combination with a line restriction?
+  if (EnableCodeCompletion) {
+Position EndPos = offsetToPosition(Inputs.Contents, End);
+auto CC = codeComplete(File, EndPos, Preamble.get(), Inputs, CCOpts);
+vlog("code completion: {0}",
+ CC.Completions.empty() ? "" : CC.Completions[0].Name);
+  }
 }
   }
 };
@@ -243,7 +252,8 @@
 
 bool check(llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts) {
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion) {
   llvm::SmallString<0> FakeFile;
   llvm::Optional Contents;
   if (File.empty()) {
@@ -267,7 +277,7 @@
   if (!C.buildCommand(TFS) || !C.buildInvocation(TFS, Contents) ||
   !C.buildAST())
 return false;
-  C.testLocationFeatures(ShouldCheckLine);
+  C.testLocationFeatures(ShouldCheckLine, EnableCodeCompletion);
 
   log("All checks completed, {0} errors", C.ErrCount);
   return C.ErrCount == 0;


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -62,7 +62,8 @@
 // Implemented in Check.cpp.
 bool check(const llvm::StringRef File,
llvm::function_ref ShouldCheckLine,
-   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts);
+   const ThreadsafeFS &TFS, const ClangdLSPServer::Options &Opts,
+   bool EnableCodeCompletion);
 
 namespace {
 
@@ -929,7 +930,11 @@
   uint32_t Line = Pos.line + 1; // Position::line is 0-based.
   return Line >= Begin && Line <= End;
 };
-return check(Path, ShouldCheckLine, TFS, Opts)
+// For now code completion is enabled any time the range is limited via
+// --check-lines. If it turns out to be to slow, we can introduce a
+// dedicated flag for that instead.
+return check(Path, ShouldCheckLine, TFS, Opts,
+ /*EnableCodeCompletion=*/!CheckFileLines.empty())
? 0
: static_cast(ErrorResultCode::CheckFailed);
   }
Index: clang-tools-extra/clangd/tool/Check.cpp

[clang] b109172 - [clang] use a different name for generated test cdb

[Mikhail Goncharov via cfe-commits]

Author: Mikhail Goncharov
Date: 2021-06-04T18:12:58+02:00
New Revision: b109172d993edacd9853a8bbb8128a94da014399

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

LOG: [clang] use a different name for generated test cdb

if build system copied source files as readonly, then override of db_tu.json
will fail

Added: 


Modified: 
clang/test/ClangScanDeps/modules-pch.c

Removed: 




diff  --git a/clang/test/ClangScanDeps/modules-pch.c 
b/clang/test/ClangScanDeps/modules-pch.c
index 44b1a0df764c..ddb6949f5e6f 100644
--- a/clang/test/ClangScanDeps/modules-pch.c
+++ b/clang/test/ClangScanDeps/modules-pch.c
@@ -8,6 +8,6 @@
 
 // Scan dependencies of the TU:
 //
-// RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_tu.json > %t/cdb_tu.json
-// RUN: clang-scan-deps -compilation-database %t/cdb_tu.json -format 
experimental-full \
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_tu.json > %t/cdb.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -format 
experimental-full \
 // RUN:   -generate-modules-path-args -module-files-dir %t/build



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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Thanks, Akira.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98799

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

[PATCH] D102822: [Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable types.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp:3
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -std=c++11 -triple riscv64 -target-feature +experimental-v \
+// RUN:   -emit-llvm -O1 -o - %s | FileCheck %s

sdesmalen wrote:
> craig.topper wrote:
> > Probably best to add -disable-llvm-passes so we don't run the optimizer.
> nit: Does `-O1` still have any effect if `-disable-llvm-passes` is also set?
Lifetime markers aren't emitted with -O0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102822

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

[PATCH] D103611: Correct the behavior of va_arg checking in C++

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D103611

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

[PATCH] D101630: [HIP] Fix device-only compilation

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D101630#2798975 , @yaxunl wrote:

> For sure we will need -fgpu-bundle-device-output to control bundling of 
> intermediate files. Then adding -emit-gpu-object and -emit-gpu-bundle may be 
> redundant and can cause confusion. What if users specify `-c 
> -fgpu-bundle-device-output -emit-gpu-object` or `-c 
> -fno-gpu-bundle-device-output -emit-gpu-bundle`? To me a single option 
> -fgpu-bundle-device-output to control all device output seems cleaner.

The idea is to use `-emit-gpu-object` and `-emit-gpu-bundle` instead of the  
`-f[no-]gpu-bundle-device-output`. Otherwise they'd do exactly the same thing.

I think `-emit-gpu-{object,bundle}` has a minor edge over 
`-f[no-]gpu-bundle-device-output` as it's similar to other -emit options for 
controlling clang compilation phases (and that's what we want to do here), 
while `-f` options are usually for tweaking code generation.


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

https://reviews.llvm.org/D101630

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

[PATCH] D103040: Print default template argument if manually specified in typedef declaration.

[John McCall via Phabricator via cfe-commits]

rjmccall accepted this revision.
rjmccall 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/D103040/new/

https://reviews.llvm.org/D103040

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

[PATCH] D101630: [HIP] Fix device-only compilation

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D101630#2799409 , @tra wrote:

> In D101630#2798975 , @yaxunl wrote:
>
>> For sure we will need -fgpu-bundle-device-output to control bundling of 
>> intermediate files. Then adding -emit-gpu-object and -emit-gpu-bundle may be 
>> redundant and can cause confusion. What if users specify `-c 
>> -fgpu-bundle-device-output -emit-gpu-object` or `-c 
>> -fno-gpu-bundle-device-output -emit-gpu-bundle`? To me a single option 
>> -fgpu-bundle-device-output to control all device output seems cleaner.
>
> The idea is to use `-emit-gpu-object` and `-emit-gpu-bundle` instead of the  
> `-f[no-]gpu-bundle-device-output`. Otherwise they'd do exactly the same thing.
>
> I think `-emit-gpu-{object,bundle}` has a minor edge over 
> `-f[no-]gpu-bundle-device-output` as it's similar to other -emit options for 
> controlling clang compilation phases (and that's what we want to do here), 
> while `-f` options are usually for tweaking code generation.

But how do we control emitting LLVM IR with or without bundle? `-emit-llvm 
-emit-gpu-object` or `-emit-llvm -emit-gpu-bundle`? `-emit-*` is usually for 
specifying a specific file type.


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

https://reviews.llvm.org/D101630

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

[clang] 4d9f852 - CUDA/HIP: Change device-use-host-var.cu's NOT "external" check to include variable name

[Konstantin Zhuravlyov via cfe-commits]

Author: Konstantin Zhuravlyov
Date: 2021-06-04T13:10:00-04:00
New Revision: 4d9f8527dbfbc998baf35eec868c9dec1f8d1224

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

LOG: CUDA/HIP: Change device-use-host-var.cu's NOT "external" check to include 
variable name

Otherwise it is causing one of our build jobs to fail,
it is using "external" as directory, and NOT is
failing because "external" is found in ModuleID.

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

Added: 


Modified: 
clang/test/CodeGenCUDA/device-use-host-var.cu

Removed: 




diff  --git a/clang/test/CodeGenCUDA/device-use-host-var.cu 
b/clang/test/CodeGenCUDA/device-use-host-var.cu
index 1a504280e8488..4d3f60c2e83c7 100644
--- a/clang/test/CodeGenCUDA/device-use-host-var.cu
+++ b/clang/test/CodeGenCUDA/device-use-host-var.cu
@@ -65,7 +65,7 @@ const int var_host_only = 7;
 // NEG-NOT: @_ZN1BIiE1yE
 // NEG-NOT: @_Z1bIdE
 // NEG-NOT: @_ZL13var_host_only
-// NEG-NOT: external
+// NEG-NOT: {{^}}@{{.*}} = external
 
 // CHECK-LABEL: define{{.*}}@_Z7dev_funPiPPKi
 // CHECK: store i32 1



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

[PATCH] D103658: CUDA/HIP: Change device-use-host-var.cu's NOT "external" check to include "addrspace"

[Konstantin Zhuravlyov via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4d9f8527dbfb: CUDA/HIP: Change device-use-host-var.cu's 
NOT "external" check to include… (authored by kzhuravl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103658

Files:
  clang/test/CodeGenCUDA/device-use-host-var.cu


Index: clang/test/CodeGenCUDA/device-use-host-var.cu
===
--- clang/test/CodeGenCUDA/device-use-host-var.cu
+++ clang/test/CodeGenCUDA/device-use-host-var.cu
@@ -65,7 +65,7 @@
 // NEG-NOT: @_ZN1BIiE1yE
 // NEG-NOT: @_Z1bIdE
 // NEG-NOT: @_ZL13var_host_only
-// NEG-NOT: external
+// NEG-NOT: {{^}}@{{.*}} = external
 
 // CHECK-LABEL: define{{.*}}@_Z7dev_funPiPPKi
 // CHECK: store i32 1


Index: clang/test/CodeGenCUDA/device-use-host-var.cu
===
--- clang/test/CodeGenCUDA/device-use-host-var.cu
+++ clang/test/CodeGenCUDA/device-use-host-var.cu
@@ -65,7 +65,7 @@
 // NEG-NOT: @_ZN1BIiE1yE
 // NEG-NOT: @_Z1bIdE
 // NEG-NOT: @_ZL13var_host_only
-// NEG-NOT: external
+// NEG-NOT: {{^}}@{{.*}} = external
 
 // CHECK-LABEL: define{{.*}}@_Z7dev_funPiPPKi
 // CHECK: store i32 1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 333987b - [OpenCL] Add DWARF address spaces mapping for SPIR

[Stuart Brady via cfe-commits]

Author: Jason Zheng
Date: 2021-06-04T18:10:54+01:00
New Revision: 333987b0458926332e9a1f96869ef47da25fa9b1

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

LOG: [OpenCL] Add DWARF address spaces mapping for SPIR

Extend debug info handling by adding DWARF address space mapping for
SPIR, with corresponding test case.

Reviewed By: Anastasia

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

Added: 
clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl

Modified: 
clang/lib/Basic/Targets/SPIR.h

Removed: 




diff  --git a/clang/lib/Basic/Targets/SPIR.h b/clang/lib/Basic/Targets/SPIR.h
index 638071d0cdce0..c429b27709ecb 100644
--- a/clang/lib/Basic/Targets/SPIR.h
+++ b/clang/lib/Basic/Targets/SPIR.h
@@ -117,6 +117,11 @@ class LLVM_LIBRARY_VISIBILITY SPIRTargetInfo : public 
TargetInfo {
 return TargetInfo::VoidPtrBuiltinVaList;
   }
 
+  Optional
+  getDWARFAddressSpace(unsigned AddressSpace) const override {
+return AddressSpace;
+  }
+
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{
 return (CC == CC_SpirFunction || CC == CC_OpenCLKernel) ? CCCR_OK
 : CCCR_Warning;

diff  --git a/clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl 
b/clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
new file mode 100644
index 0..28b6c674c8ffd
--- /dev/null
+++ b/clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 
-emit-llvm -O0 -triple spir-unknown-unknown -o - %s | FileCheck %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 
-emit-llvm -O0 -triple spir64-unknown-unknown -o - %s | FileCheck %s
+
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GLOBAL:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 1)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_CONSTANT:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 2)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_LOCAL:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 3)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_PRIVATE:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 0)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GENERIC:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 4)
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar0", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_GLOBAL]], 
isLocal: false, isDefinition: true)
+global int *FileVar0;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar1", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_CONSTANT]], 
isLocal: false, isDefinition: true)
+constant int *FileVar1;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar2", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_LOCAL]], 
isLocal: false, isDefinition: true)
+local int *FileVar2;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar3", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_PRIVATE]], 
isLocal: false, isDefinition: true)
+private int *FileVar3;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar4", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_GENERIC]], 
isLocal: false, isDefinition: true)
+int *FileVar4;



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

[PATCH] D103097: Add DWARF address spaces mapping for SPIR

[Stuart Brady via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG333987b04589: [OpenCL] Add DWARF address spaces mapping for 
SPIR (authored by jzzheng22, committed by stuart).

Changed prior to commit:
  https://reviews.llvm.org/D103097?vs=348910&id=349910#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103097

Files:
  clang/lib/Basic/Targets/SPIR.h
  clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl


Index: clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 
-emit-llvm -O0 -triple spir-unknown-unknown -o - %s | FileCheck %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 
-emit-llvm -O0 -triple spir64-unknown-unknown -o - %s | FileCheck %s
+
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GLOBAL:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 1)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_CONSTANT:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 2)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_LOCAL:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 3)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_PRIVATE:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 0)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GENERIC:[0-9]+]] = !DIDerivedType(tag: 
DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, 
dwarfAddressSpace: 4)
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar0", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_GLOBAL]], 
isLocal: false, isDefinition: true)
+global int *FileVar0;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar1", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_CONSTANT]], 
isLocal: false, isDefinition: true)
+constant int *FileVar1;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar2", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_LOCAL]], 
isLocal: false, isDefinition: true)
+local int *FileVar2;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar3", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_PRIVATE]], 
isLocal: false, isDefinition: true)
+private int *FileVar3;
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar4", scope: !{{[0-9]+}}, 
file: !{{[0-9]+}}, line: {{[0-9]+}}, type: ![[DWARF_ADDRESS_SPACE_GENERIC]], 
isLocal: false, isDefinition: true)
+int *FileVar4;
Index: clang/lib/Basic/Targets/SPIR.h
===
--- clang/lib/Basic/Targets/SPIR.h
+++ clang/lib/Basic/Targets/SPIR.h
@@ -117,6 +117,11 @@
 return TargetInfo::VoidPtrBuiltinVaList;
   }
 
+  Optional
+  getDWARFAddressSpace(unsigned AddressSpace) const override {
+return AddressSpace;
+  }
+
   CallingConvCheckResult checkCallingConvention(CallingConv CC) const override 
{
 return (CC == CC_SpirFunction || CC == CC_OpenCLKernel) ? CCCR_OK
 : CCCR_Warning;


Index: clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
===
--- /dev/null
+++ clang/test/CodeGenOpenCL/spir-debug-info-pointer-address-space.cl
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 -emit-llvm -O0 -triple spir-unknown-unknown -o - %s | FileCheck %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -debug-info-kind=limited -dwarf-version=5 -emit-llvm -O0 -triple spir64-unknown-unknown -o - %s | FileCheck %s
+
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GLOBAL:[0-9]+]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, dwarfAddressSpace: 1)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_CONSTANT:[0-9]+]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, dwarfAddressSpace: 2)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_LOCAL:[0-9]+]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, dwarfAddressSpace: 3)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_PRIVATE:[0-9]+]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, dwarfAddressSpace: 0)
+// CHECK-DAG: ![[DWARF_ADDRESS_SPACE_GENERIC:[0-9]+]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !{{[0-9]+}}, size: {{[0-9]+}}, dwarfAddressSpace: 4)
+
+// CHECK-DAG: distinct !DIGlobalVariable(name: "FileVar0", scope: !{{[0-9]+}}, file: !{{

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Jian Cai via Phabricator via cfe-commits]

jcai19 updated this revision to Diff 349912.
jcai19 added a comment.

Address the comments and add more tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aarch64-target-as-march.s

Index: clang/test/Driver/aarch64-target-as-march.s
===
--- /dev/null
+++ clang/test/Driver/aarch64-target-as-march.s
@@ -0,0 +1,48 @@
+/// These tests make sure that options passed to the assembler
+/// via -Wa or -Xassembler are applied correctly to assembler inputs.
+
+/// Does not apply to non assembly files
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.1-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-1 %s
+
+// TARGET-FEATURE-1-NOT: "-target-feature" "+v8.1a"
+
+/// Does apply to assembler input
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-2 %s
+
+// TARGET-FEATURE-2: "-target-feature" "+v8.2a"
+
+/// No unused argument warnings when there are multiple values
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.1-a -Wa,-march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.1-a -Xassembler -march=armv8.2-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Xassembler -march=armv8.2-a,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=UNUSED-WARNING %s
+
+// UNUSED-WARNING-NOT: warning: argument unused during compilation
+
+/// Last march to assembler wins
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.2-a -Wa,-march=armv8.1-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a
+// MULTIPLE-VALUES-NOT: "-target-feature" "+v8.2a
+
+/// march to compiler and assembler, we choose the one suited to the input file type
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a %s 2>&1 | \
+// RUN: FileCheck --check-prefix=TARGET-FEATURE-3 %s
+// RUN: %clang --target=aarch64-linux-gnueabi -### -c -Wa,-march=armv8.3-a -march=armv8.4-a \
+// RUN: %S/Inputs/wildcard1.c 2>&1 | FileCheck --check-prefix=TARGET-FEATURE-4 %s
+
+// TARGET-FEATURE-3: "-target-feature" "+v8.3a"
+// TARGET-FEATURE-3-NOT: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4: "-target-feature" "+v8.4a"
+// TARGET-FEATURE-4-NOT: "-target-feature" "+v8.3a"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -344,7 +344,7 @@
   case llvm::Triple::aarch64:
   case llvm::Triple::aarch64_32:
   case llvm::Triple::aarch64_be:
-aarch64::getAArch64TargetFeatures(D, Triple, Args, Features);
+aarch64::getAArch64TargetFeatures(D, Triple, Args, Features, ForAS);
 break;
   case llvm::Triple::x86:
   case llvm::Triple::x86_64:
Index: clang/lib/Driver/ToolChains/Arch/AArch64.h
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.h
+++ clang/lib/Driver/ToolChains/Arch/AArch64.h
@@ -22,7 +22,8 @@
 
 void getAArch64TargetFeatures(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args,
-  std::vector &Features);
+  std::vector &Features,
+  bool ForAS);
 
 std::string getAArch64TargetCPU(const llvm::opt::ArgList &Args,
 const llvm::Triple &Triple, llvm::opt::Arg *&A);
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -185,12 +185,20 @@
 void aarch64::getAArch64TargetFeatures(const Driver &D,
const llvm::Triple &Triple,
const ArgList &Args,
-   std::vector &Features) {
+  

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Jian Cai via Phabricator via cfe-commits]

jcai19 added a comment.

In D103184#2798398 , @DavidSpickett 
wrote:

>> LGTM; any additional thoughts @DavidSpickett ?
>
> A couple of additional tests just to be safe but otherwise LGTM.
>
> Also please include in the commit message the "rules" that we're using here 
> for parsing. Like I did for the arm change.

Thanks all!




Comment at: clang/test/Driver/aarch64-target-as-march.s:29
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a

DavidSpickett wrote:
> Add a test with `-Wa,-march=armv8.2-a,-march=armv8.1-a` (one -Wa with 
> multiple values attached), then repeat the two tests but with `-Xassembler` 
> instead.
I added a test case for -Xassembler -march=armv8.2-a,-march=armv8.1-a,  but it 
seems it does not support multiple values in one invocation?

clang --target=aarch64-linux-gnueabi -Xassembler 
-march=armv8.2-a,-march=armv8.1-a -c foo.s -o ias.o -###
...
clang-13: error: the clang compiler does not support '-Xassembler 
-march=armv8.2-a,-march=armv8.1-a'
...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103184: [AArch64] handle -Wa,-march=

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers requested changes to this revision.
nickdesaulniers added inline comments.
This revision now requires changes to proceed.



Comment at: clang/test/Driver/aarch64-target-as-march.s:29
+// RUN: FileCheck --check-prefix=MULTIPLE-VALUES %s
+
+// MULTIPLE-VALUES: "-target-feature" "+v8.1a

jcai19 wrote:
> DavidSpickett wrote:
> > Add a test with `-Wa,-march=armv8.2-a,-march=armv8.1-a` (one -Wa with 
> > multiple values attached), then repeat the two tests but with `-Xassembler` 
> > instead.
> I added a test case for -Xassembler -march=armv8.2-a,-march=armv8.1-a,  but 
> it seems it does not support multiple values in one invocation?
> 
> clang --target=aarch64-linux-gnueabi -Xassembler 
> -march=armv8.2-a,-march=armv8.1-a -c foo.s -o ias.o -###
> ...
> clang-13: error: the clang compiler does not support '-Xassembler 
> -march=armv8.2-a,-march=armv8.1-a'
> ...
I don't think @DavidSpickett meant more `UNUSED-WARNING` tests, but tests that 
check the actual chosen value.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103184

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

[PATCH] D103587: [AIX] Transfer __TOS_AIX__ predefined macro

[Jake Egan via Phabricator via cfe-commits]

Jake-Egan updated this revision to Diff 349913.
Jake-Egan added a comment.

Use this patch to target only __TOS_AIX__.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103587

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/Preprocessor/init-ppc.c


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,7 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+Builder.defineMacro("__TOS_AIX__");
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");


Index: clang/test/Preprocessor/init-ppc.c
===
--- clang/test/Preprocessor/init-ppc.c
+++ clang/test/Preprocessor/init-ppc.c
@@ -541,6 +541,7 @@
 // PPC-AIX:#define __SIZE_MAX__ 4294967295UL
 // PPC-AIX:#define __SIZE_TYPE__ long unsigned int
 // PPC-AIX:#define __SIZE_WIDTH__ 32
+// PPC-AIX:#define __TOS_AIX__ 1
 // PPC-AIX:#define __UINT16_C_SUFFIX__
 // PPC-AIX:#define __UINT16_MAX__ 65535
 // PPC-AIX:#define __UINT16_TYPE__ unsigned short
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -675,6 +675,7 @@
 Builder.defineMacro("_POWER");
 
 Builder.defineMacro("_AIX");
+Builder.defineMacro("__TOS_AIX__");
 
 if (Opts.EnableAIXExtendedAltivecABI)
   Builder.defineMacro("__EXTABI__");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101630: [HIP] Fix device-only compilation

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D101630#2799425 , @yaxunl wrote:

> But how do we control emitting LLVM IR with or without bundle? `-emit-llvm 
> -emit-gpu-object` or `-emit-llvm -emit-gpu-bundle`? `-emit-*` is usually for 
> specifying a specific file type.

Hmm. I forgot that HIP can bundle things other than objects. `-emit-llvm 
-emit-gpu-bundle` looks reasonable, but `-emit-llvm -emit-gpu-object` is indeed 
odd.
OK. Making it some sort of do/do-not bundle flag makes sense. How about just 
`--[no-]gpu-bundle-output`?


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

https://reviews.llvm.org/D101630

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

[PATCH] D103372: [InstrProfiling] If no value profiling, make data variable private and (for Windows) use one comdat

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 349915.
MaskRay added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Re-upload after revert


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103372

Files:
  clang/test/Profile/c-linkage-available_externally.c
  clang/test/Profile/c-linkage.c
  clang/test/Profile/cxx-linkage.cpp
  llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp
  llvm/test/Instrumentation/InstrProfiling/comdat.ll
  llvm/test/Instrumentation/InstrProfiling/icall.ll
  llvm/test/Instrumentation/InstrProfiling/linkage.ll
  llvm/test/Instrumentation/InstrProfiling/platform.ll
  llvm/test/Instrumentation/InstrProfiling/profiling.ll
  llvm/test/Transforms/PGOProfile/comdat_internal.ll

Index: llvm/test/Transforms/PGOProfile/comdat_internal.ll
===
--- llvm/test/Transforms/PGOProfile/comdat_internal.ll
+++ llvm/test/Transforms/PGOProfile/comdat_internal.ll
@@ -7,16 +7,16 @@
 ; CHECK: $foo = comdat any
 
 ; CHECK: $__llvm_profile_raw_version = comdat any
-; CHECK: $__profd__stdin__foo.[[FOO_HASH:[0-9]+]] = comdat any
+; CHECK: $__profc__stdin__foo.[[#FOO_HASH:]] = comdat any
 
 @bar = global i32 ()* @foo, align 8
 
 ; CHECK: @__llvm_profile_raw_version = constant i64 {{[0-9]+}}, comdat
 ; CHECK-NOT: __profn__stdin__foo
-; CHECK: @__profc__stdin__foo.[[FOO_HASH]] = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat($__profd__stdin__foo.[[FOO_HASH]]), align 8
-; CHECK: @__profd__stdin__foo.[[FOO_HASH]] = private global { i64, i64, i64*, i8*, i8*, i32, [2 x i16] } { i64 -5640069336071256030, i64 [[FOO_HASH]], i64* getelementptr inbounds ([1 x i64], [1 x i64]* @__profc__stdin__foo.[[FOO_HASH]], i32 0, i32 0), i8* null
+; CHECK: @__profc__stdin__foo.[[#FOO_HASH]] = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
+; CHECK: @__profd__stdin__foo.[[#FOO_HASH]] = private global { i64, i64, i64*, i8*, i8*, i32, [2 x i16] } { i64 -5640069336071256030, i64 [[#FOO_HASH]], i64* getelementptr inbounds ([1 x i64], [1 x i64]* @__profc__stdin__foo.[[#FOO_HASH]], i32 0, i32 0), i8* null
 ; CHECK-NOT: bitcast (i32 ()* @foo to i8*)
-; CHECK-SAME: , i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat, align 8
+; CHECK-SAME: , i8* null, i32 1, [2 x i16] zeroinitializer }, section "__llvm_prf_data", comdat($__profc__stdin__foo.[[#FOO_HASH]]), align 8
 ; CHECK: @__llvm_prf_nm
 ; CHECK: @llvm.compiler.used
 
Index: llvm/test/Instrumentation/InstrProfiling/profiling.ll
===
--- llvm/test/Instrumentation/InstrProfiling/profiling.ll
+++ llvm/test/Instrumentation/InstrProfiling/profiling.ll
@@ -17,8 +17,8 @@
 @__profn_baz = private constant [3 x i8] c"baz"
 ; CHECK-NOT: __profn_baz
 
-; ELF:   @__profc_foo = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat($__profd_foo), align 8
-; ELF:   @__profd_foo = private {{.*}}, section "__llvm_prf_data", comdat, align 8
+; ELF:   @__profc_foo = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
+; ELF:   @__profd_foo = private {{.*}}, section "__llvm_prf_data", comdat($__profc_foo), align 8
 ; MACHO: @__profc_foo = private global [1 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
 ; MACHO: @__profd_foo = private {{.*}}, section "__DATA,__llvm_prf_data,regular,live_support", align 8
 ; WIN:   @__profc_foo = private global [1 x i64] zeroinitializer, section ".lprfc$M", align 8
@@ -28,8 +28,8 @@
   ret void
 }
 
-; ELF:   @__profc_bar = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat($__profd_bar), align 8
-; ELF:   @__profd_bar = private {{.*}}, section "__llvm_prf_data", comdat, align 8
+; ELF:   @__profc_bar = private global [1 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
+; ELF:   @__profd_bar = private {{.*}}, section "__llvm_prf_data", comdat($__profc_bar), align 8
 ; MACHO: @__profc_bar = private global [1 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
 ; MACHO: @__profd_bar = private {{.*}}, section "__DATA,__llvm_prf_data,regular,live_support", align 8
 ; WIN:   @__profc_bar = private global [1 x i64] zeroinitializer, section ".lprfc$M", align 8
@@ -39,8 +39,8 @@
   ret void
 }
 
-; ELF:   @__profc_baz = private global [3 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat($__profd_baz), align 8
-; ELF:   @__profd_baz = private {{.*}}, section "__llvm_prf_data", comdat, align 8
+; ELF:   @__profc_baz = private global [3 x i64] zeroinitializer, section "__llvm_prf_cnts", comdat, align 8
+; ELF:   @__profd_baz = private {{.*}}, section "__llvm_prf_data", comdat($__profc_baz), align 8
 ; MACHO: @__profc_baz = private global [3 x i64] zeroinitializer, section "__DATA,__llvm_prf_cnts", align 8
 ; MACHO: @__prof

[PATCH] D103372: [InstrProfiling] If no value profiling, make data variable private and (for Windows) use one comdat

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

@vsk Do you mind investigating macOS `Posix/instrprof-dynamic-one-shared.test` 
and `Posix/instrprof-dynamic-two-shared.test` failures on 
https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8845381350758503248/+/steps/package_clang/0/stdout
 ? :) I don't have a macOS machine.

I think the only behavior change for macOS is this block:

  // Data variables can be private if not referenced by code.
  if (!DataReferencedByCode) {
Linkage = GlobalValue::PrivateLinkage;
Visibility = GlobalValue::DefaultVisibility;
  }

If not easy to fix, I'll just exclude isOSBinFormatMachO() for now...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103372

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

[PATCH] D101630: [HIP] Fix device-only compilation

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D101630#2799472 , @tra wrote:

> In D101630#2799425 , @yaxunl wrote:
>
>> But how do we control emitting LLVM IR with or without bundle? `-emit-llvm 
>> -emit-gpu-object` or `-emit-llvm -emit-gpu-bundle`? `-emit-*` is usually for 
>> specifying a specific file type.
>
> Hmm. I forgot that HIP can bundle things other than objects. `-emit-llvm 
> -emit-gpu-bundle` looks reasonable, but `-emit-llvm -emit-gpu-object` is 
> indeed odd.
> OK. Making it some sort of do/do-not bundle flag makes sense. How about just 
> `--[no-]gpu-bundle-output`?

--[no]gpu-bundle-output sounds good.


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

https://reviews.llvm.org/D101630

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