[PATCH] D111228: [clang-tidy] Add options to bugprone-unused-return-value.

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

balazske added a comment.

I think a configuration option that depends on configuration of another check 
causes too many problems. It causes dependencies between checks, possible 
circular dependency (that is an error). What if the other check is not enabled 
(if a check configuration depends on other it may mean that these two belong 
together and should both be enabled, or not)? It becomes less clear from where 
a value comes.

A probably better way: Define configuration values like "variables" that can be 
used at any check, probably with manipulation of the original value. But not 
reuse configuration of another check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111228

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

[PATCH] D111316: [CFE][Codegen][In-progress] Remove CodeGenFunction::InitTempAlloca()

[John McCall via Phabricator via cfe-commits]

rjmccall added a reviewer: ABataev.
rjmccall added a comment.

This mostly looks good, but I'd like Alexey Bataev to sign off, since he 
authored the OpenMP support.




Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:2124
  /*Name=*/".bound.zero.addr");
-CGF.InitTempAlloca(ZeroAddrBound, CGF.Builder.getInt32(/*C*/ 0));
+CGF.Builder.CreateStore(CGF.Builder.getInt32(/*C*/ 0), ZeroAddrBound);
 llvm::SmallVector OutlinedFnArgs;

This seems innocuous since `ZeroAddrBound` does not otherwise change in the 
function, assuming the runtime call doesn't modify it.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:4784
+  CGF.Builder.CreateStore(llvm::ConstantInt::get(CGF.IntPtrTy, 0),
+  NumLVal.getAddress(CGF));
   llvm::Value *PrevVal = CGF.EmitLoadOfScalar(NumLVal, E->getExprLoc());

The original generated code here is very strange:

```
%depobj.size.addr = alloca i64
...  
store i64 0, i64* %depobj.size.addr// currently in prologue
...
%numdeps = load // from the size field of the struct kmp_depend_info which 
precedes all dependent objects
...
%tmp = load i64, i64* %depobj.size.addr
%sum = add nuw i64 %tmp, i64 %numdeps
store i64 %sum, %i64* %depobj.size.addr
...
// and then in the one place we actually call this function, we
// immediately sum up all the %sums for all the dependent objects
```

The funny thing about this code is that, because the zeroing of 
`%depobj.size.addr` is only done in the prologue, it increases by the current 
element count of the depend object every time if this code is run multiple 
times, which I think cannot possibly be correct.  Notably, the code to actually 
copy dependency data does not seem to have this bug because `PosLVal` is zeroed 
immediately.

So I'm pretty sure this change is actually a bug fix in the treatment of 
`depend(depobj : ...)`.  However, I'd really like Alexey to review and approve, 
because if `%depobj.size.addr` is *not* supposed to accumulate values in a 
loop, then I really don't understand why it exists at all.





Comment at: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp:1503
   /*Name=*/".zero.addr");
-  CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
+  CGF.Builder.CreateStore(CGF.Builder.getInt32(/*C*/ 0), ZeroAddr);
   llvm::SmallVector OutlinedFnArgs;

This seems innocuous since `ZeroAddr` does not otherwise change in the 
function, assuming the runtime call doesn't modify it.



Comment at: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp:3491
   /*Name=*/".zero.addr");
-  CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
+  CGF.Builder.CreateStore(CGF.Builder.getInt32(/*C*/ 0), ZeroAddr);
   // Get the array of arguments.

This seems innocuous since `ZeroAddr` does not otherwise change in the 
function, assuming the runtime call doesn't modify it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111316

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

[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

[John McCall via Phabricator via cfe-commits]

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

Thanks, LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109950

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

[PATCH] D111521: [DebugInfo] Mark OpenMP generated functions as artificial

[Djordje Todorovic via Phabricator via cfe-commits]

djtodoro added a comment.

This looks reasonable to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111521

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

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/docs/BitIntABI.rst:17
+This is only intended as a generic specification. The actual details for any
+particular platform should be codified in that platform's ABI specification.
+

I think you should recommend that ABIs codify that by reference to your 
specification.  Perhaps:

> This document provides a generic ABI specification for the C23 `_BitInt` 
> feature, expressed in terms of concepts common to low-level platform ABIs.  
> This document does not directly constrain any platform, as the ABI used for 
> `_BitInt` on a platform is determined by that platform's ABI specification.  
> It is expected that platform ABIs will codify the ABI for the `_BitInt` 
> feature on their platform using this specification, either by reference or by 
> copying the text of this specification into the platform ABI specification.

Now, I am assuming that this specification will be complex enough that ABI 
maintainers won't want to just copy into their specifications.  Maybe I'm wrong 
about that, but I think it will be fairly long by the time it's finished — not, 
like, Itanium C++ ABI long, but it might be 3-4 pages.  If we want to support 
including this by reference, we need to think about what that reference looks 
like.  I think there are two key parts of that: first, it should explicitly 
name a version of this document, and second, it should give  the parameters 
that we've listed out below.  Basically, someone should be able to see that and 
have no doubt about what the ABI is.

I would suggest this recommended reference:

> Platform ABIs which include this specification by reference should explicitly 
> give a version and the parameters listed below.  For example: "The ABI for 
> `_BitInt` types is specified by version 1 of the specification found at 
> https://clang.llvm.org/docs/BitIntABI.html, using 64 as the maximum 
> fundamental width and `long` as the chunk  type."

To make versioning work, the version history should (1) explicitly say what 
version this is and (2) be limited to major semantic versions, where you 
actually change the intended ABI rather than just making editorial changes.  
(If you never need to do that, great, but you should set up to make it 
possible.)



Comment at: clang/docs/BitIntABI.rst:42
+``sizeof(Array) / sizeof(__BitInt(N))`` must have the usual semantics for
+determining the number of elements in an array.
+

On first read, I thought this paragraph was telling me that `sizeof` behaves 
differently for `_BitInt` objects.  On second read, I think you're trying to 
tell me that it *doesn't* behave differently and that arrays of `_BitInt` might 
contain padding between elements.  However, that's true of all objects of 
`_BitInt` that aren't bit-fields, so I think this paragraph is a little 
misleading.

Perhaps:

> `_BitInt` types are ordinary object types and may be used anywhere an object 
> type can be, such as a struct field, union field, or array element.  In 
> addition, they are integer types and may be used as the type of a bit-field.  
> Like any other type, a `_BitInt` object may require more memory than its 
> stated bit width in order to satisfy the requirements of byte (or higher) 
> alignment.  In other words, the width of a `_BitInt` affects the semantics of 
> operations on the value; it is not a guarantee that the value will be 
> "packed" into exactly that many bits in memory.



Comment at: clang/docs/BitIntABI.rst:47
+The ABI of ``_BitInt`` is expected to vary between architectures, but the
+following is a general ABI outline.
+

In general, this section is a good start, but I think you should split it into 
three sections:
- one section describing how `_BitInt` is laid out as a non-bit-field object;
- one section describing how a `_BitInt` is laid out as a bit-field, which I 
think needs to be much clearer than you've given below; and
- one section describing how a `_BitInt` is passed and returned from a function.



Comment at: clang/docs/BitIntABI.rst:71
+the original width. e.g., a ``signed _BitField(7)`` whose representation width
+is ``8`` bits cannot store values less than ``-64`` or greater than ``63``.
+

Oh, is sign/zero extension the ABI you want to recommend?  I wasn't trying to 
lead you in either direction on this point; I just wanted to make sure this was 
thought through.

There should be a non-normative rationale / alternatives considered section at 
the end that makes an argument for the ABI's recommendations here.



Comment at: clang/docs/BitIntABI.rst:90
+``_BitInt`` should not be packed together with an adjacent bit-field of a non-
+``_BitInt`` type. ``_BitInt(N)`` and ``_BitInt(M)`` types should pack together
+when ``N != M``.

BitInts not packing with non-BitInts is a surprising rule.

How does this packing work when allocatio

[PATCH] D109506: [clangd] Print current request context along with the stack trace

[Sam McCall via Phabricator via cfe-commits]

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

Looks great, thanks!
Happy to commit this for you if you don't have access.




Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1327
+llvm::errs() << "Signalled during AST worker action: "
+ << (CurrentRequest ? CurrentRequest->Name : "") << "\n";
+crashDumpParseInputs(llvm::errs(), FileInputs);

nit: this copies CurrentRequest->Name, which seems like a very avoidable 
allocation in a crash handler... just use `if`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

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

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D108643#3027473 , @erichkeane 
wrote:

> In D108643#3026550 , @rjmccall 
> wrote:
>
>> I think it would be better to provide a generic ABI specification that is 
>> designed to "lower" `_BitInt` types into more basic concepts that ABIs 
>> typically already have rules for.  It would be appropriate to note at the 
>> top that this is only a generic specification and that the rules for any 
>> particular platform should be codified in a platform-specific ABI.  But we 
>> should make that easy so that platform owners who don't have strong opinions 
>> about the ABI can just say "as described in version 1.4 of the generic ABI 
>> at https://clang.llvm.org/...";
>>
>> Now, that is all independent of what we actually decide the ABI should be.  
>> But I do think that if we're going to make this available on all targets, we 
>> should strongly consider doing a "legalizing" lowering in the frontend: at 
>> ABI-exposed points (call arguments/parameters and memory accesses), 
>> `_BitInt` types should be translated into types that a naive backend can be 
>> trusted to handle in a way that matches the documented ABI.  Individual 
>> targets can then opt in to using the natural lowerings if they promise to 
>> match the ABI, but that becomes a decision that they make to enable better 
>> optimization and code generation, not something that's necessary for 
>> correctness.
>
> Don't we already have that?  We work the same way a 'bool' does, that is, we 
> zero/sign extend for parameters and return values?  The backends then 
> reliably up-scale these to the power-of-two/multiple-of-pointer.

There's two levels of a "legalizing" lowering.

On the specification level, we'd be formally saying that the ABI matches the 
ABI of some other C construct.  For example, we might say that a `signed 
_BitInt(14)` argument is treated exactly as if the argument type was instead 
`signed short` (with whatever restriction we do or do not impose on the range). 
 This is very nice on this level because, first, it's a rule that works 
generically for all targets without needing to care about the details of how 
arguments are assigned to registers or stack slots or whatever; and second, it 
means you're never adding new cases to the ABI that e.g. libffi would need to 
care about; and third, you can reliably match the ABI with manually-lowered C 
code from a compiler that doesn't even support `_BitInt`s.

On the implementation level, we'd have to actually emit IR which will turn into 
code which matches that ABI.  I think you are right that small integers already 
reliably work that way in LLVM, so that if you pass an `i11 sext` it'll get 
sign-extended to some width — what width exactly, I don't know, but probably 
the same width that `i16 sext` would be.  Larger integers, I'm not sure.  A 
legalizing lowering of big `_BitInt` argument would presumably say either that 
it's exactly the same as a struct containing all the chunks or that it's 
exactly the same as a series of arguments for each of the chunks.  Those are 
two very different rules!  Most ABIs won't "straddle" a single argument between 
registers and the stack, so e.g. if you'd need two registers and you only have 
one left then you exhaust the registers and go fully on the stack; but 
obviously you can get straddling if the lowering expands the sequence.  
Similarly, some ABIs will go indirect if the struct gets big enough, but you 
won't get that if the lowering expands.  But on the other hand, if the rule is 
really that it's like a struct, well, some ABIs don't pass small structs in 
registers.  Anyway, my point is that what exactly LLVM targets do if you give 
them an `i117` might not match either of these possibilities reliably across 
targets.  In any case, since we currently have to count registers in the 
frontend for the register-passing ABIs, we'll need to actually know what the 
targets do.


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

https://reviews.llvm.org/D108643

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

[clang] d11ec6f - [Clang] Enable IC/IF mode for __ibm128

[Qiu Chaofan via cfe-commits]

Author: Qiu Chaofan
Date: 2021-10-11T17:38:04+08:00
New Revision: d11ec6f67e45c630ab87bfb6010dcc93e89542fc

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

LOG: [Clang] Enable IC/IF mode for __ibm128

As for 128-bit floating points on PowerPC, compiler should have three
machine modes:

- IFmode, always IBM extended double
- KFmode, always IEEE 754R 128-bit floating point
- TFmode, matches the semantics for long double

This commit adds support for IF mode with its complex variant, IC mode.

Reviewed By: rjmccall

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

Added: 


Modified: 
clang/lib/Basic/TargetInfo.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/CodeGenCXX/ibm128-declarations.cpp
clang/test/Sema/attr-mode.c

Removed: 




diff  --git a/clang/lib/Basic/TargetInfo.cpp b/clang/lib/Basic/TargetInfo.cpp
index 2d9110a5fc447..514893b47b4f4 100644
--- a/clang/lib/Basic/TargetInfo.cpp
+++ b/clang/lib/Basic/TargetInfo.cpp
@@ -297,11 +297,11 @@ FloatModeKind TargetInfo::getRealTypeByWidth(unsigned 
BitWidth,
 if (ExplicitType == FloatModeKind::Float128)
   return hasFloat128Type() ? FloatModeKind::Float128
: FloatModeKind::NoFloat;
-if (&getLongDoubleFormat() == &llvm::APFloat::PPCDoubleDouble() ||
-&getLongDoubleFormat() == &llvm::APFloat::IEEEquad())
-  return FloatModeKind::LongDouble;
-if (hasFloat128Type())
-  return FloatModeKind::Float128;
+if (ExplicitType == FloatModeKind::Ibm128)
+  return hasIbm128Type() ? FloatModeKind::Ibm128
+ : FloatModeKind::NoFloat;
+if (ExplicitType == FloatModeKind::LongDouble)
+  return ExplicitType;
 break;
   }
 

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 1b9a63c15e71e..cd50818d10638 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -4233,6 +4233,10 @@ static void parseModeAttrArg(Sema &S, StringRef Str, 
unsigned &DestWidth,
   ExplicitType = FloatModeKind::LongDouble;
   DestWidth = 128;
   break;
+case 'I':
+  ExplicitType = FloatModeKind::Ibm128;
+  DestWidth = Str[1] == 'I' ? 0 : 128;
+  break;
 }
 if (Str[1] == 'F') {
   IntegerMode = false;

diff  --git a/clang/test/CodeGenCXX/ibm128-declarations.cpp 
b/clang/test/CodeGenCXX/ibm128-declarations.cpp
index 7ff23aa1e0f85..6d2c6d2544879 100644
--- a/clang/test/CodeGenCXX/ibm128-declarations.cpp
+++ b/clang/test/CodeGenCXX/ibm128-declarations.cpp
@@ -59,6 +59,12 @@ template <__ibm128 Q> struct T2 {
   constexpr static __ibm128 mem = Q;
 };
 
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float w128ibm_c __attribute__((mode(IC)));
+
+w128ibm icmode_self(w128ibm x) { return x; }
+w128ibm_c icmode_self_complex(w128ibm_c x) { return x; }
+
 int main(void) {
   __ibm128 lf;
   CTest ct(lf);
@@ -115,6 +121,9 @@ int main(void) {
 // CHECK:   ret ppc_fp128 %2
 // CHECK: }
 
+// CHECK: define dso_local ppc_fp128 @_Z11icmode_selfg(ppc_fp128 %x)
+// CHECK: define dso_local { ppc_fp128, ppc_fp128 } 
@_Z19icmode_self_complexCg(ppc_fp128 %x.coerce0, ppc_fp128 %x.coerce1)
+
 // CHECK: define dso_local signext i32 @main()
 // CHECK: entry:
 // CHECK:   %0 = load ppc_fp128, ppc_fp128* %lf, align 16

diff  --git a/clang/test/Sema/attr-mode.c b/clang/test/Sema/attr-mode.c
index a4bac90b99fb8..c89738a9d7969 100644
--- a/clang/test/Sema/attr-mode.c
+++ b/clang/test/Sema/attr-mode.c
@@ -92,6 +92,12 @@ void f_ft128_arg(long double *x);
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float cw128ibm __attribute__((mode(IC)));
+void f_ibm128_arg(__ibm128 *x);
+void f_ibm128_complex_arg(_Complex __ibm128 *x);
+void test_IFtype(w128ibm *a) { f_ibm128_arg(a); }
+void test_ICtype(cw128ibm *a) { f_ibm128_complex_arg(a); }
 #elif TEST_F128_PPC64
 typedef int invalid_7 __attribute((mode(KF))); // expected-error{{type of 
machine mode does not match type of base type}}
 typedef int invalid_8 __attribute((mode(KI))); // expected-error{{unknown 
machine mode}}



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

[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

[Qiu Chaofan 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 rGd11ec6f67e45: [Clang] Enable IC/IF mode for __ibm128 
(authored by qiucf).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109950

Files:
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGenCXX/ibm128-declarations.cpp
  clang/test/Sema/attr-mode.c


Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -92,6 +92,12 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float cw128ibm __attribute__((mode(IC)));
+void f_ibm128_arg(__ibm128 *x);
+void f_ibm128_complex_arg(_Complex __ibm128 *x);
+void test_IFtype(w128ibm *a) { f_ibm128_arg(a); }
+void test_ICtype(cw128ibm *a) { f_ibm128_complex_arg(a); }
 #elif TEST_F128_PPC64
 typedef int invalid_7 __attribute((mode(KF))); // expected-error{{type of 
machine mode does not match type of base type}}
 typedef int invalid_8 __attribute((mode(KI))); // expected-error{{unknown 
machine mode}}
Index: clang/test/CodeGenCXX/ibm128-declarations.cpp
===
--- clang/test/CodeGenCXX/ibm128-declarations.cpp
+++ clang/test/CodeGenCXX/ibm128-declarations.cpp
@@ -59,6 +59,12 @@
   constexpr static __ibm128 mem = Q;
 };
 
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float w128ibm_c __attribute__((mode(IC)));
+
+w128ibm icmode_self(w128ibm x) { return x; }
+w128ibm_c icmode_self_complex(w128ibm_c x) { return x; }
+
 int main(void) {
   __ibm128 lf;
   CTest ct(lf);
@@ -115,6 +121,9 @@
 // CHECK:   ret ppc_fp128 %2
 // CHECK: }
 
+// CHECK: define dso_local ppc_fp128 @_Z11icmode_selfg(ppc_fp128 %x)
+// CHECK: define dso_local { ppc_fp128, ppc_fp128 } 
@_Z19icmode_self_complexCg(ppc_fp128 %x.coerce0, ppc_fp128 %x.coerce1)
+
 // CHECK: define dso_local signext i32 @main()
 // CHECK: entry:
 // CHECK:   %0 = load ppc_fp128, ppc_fp128* %lf, align 16
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -4233,6 +4233,10 @@
   ExplicitType = FloatModeKind::LongDouble;
   DestWidth = 128;
   break;
+case 'I':
+  ExplicitType = FloatModeKind::Ibm128;
+  DestWidth = Str[1] == 'I' ? 0 : 128;
+  break;
 }
 if (Str[1] == 'F') {
   IntegerMode = false;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -297,11 +297,11 @@
 if (ExplicitType == FloatModeKind::Float128)
   return hasFloat128Type() ? FloatModeKind::Float128
: FloatModeKind::NoFloat;
-if (&getLongDoubleFormat() == &llvm::APFloat::PPCDoubleDouble() ||
-&getLongDoubleFormat() == &llvm::APFloat::IEEEquad())
-  return FloatModeKind::LongDouble;
-if (hasFloat128Type())
-  return FloatModeKind::Float128;
+if (ExplicitType == FloatModeKind::Ibm128)
+  return hasIbm128Type() ? FloatModeKind::Ibm128
+ : FloatModeKind::NoFloat;
+if (ExplicitType == FloatModeKind::LongDouble)
+  return ExplicitType;
 break;
   }
 


Index: clang/test/Sema/attr-mode.c
===
--- clang/test/Sema/attr-mode.c
+++ clang/test/Sema/attr-mode.c
@@ -92,6 +92,12 @@
 void f_ft128_complex_arg(_Complex long double *x);
 void test_TFtype(f128ibm *a) { f_ft128_arg (a); }
 void test_TCtype(c128ibm *a) { f_ft128_complex_arg (a); }
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float cw128ibm __attribute__((mode(IC)));
+void f_ibm128_arg(__ibm128 *x);
+void f_ibm128_complex_arg(_Complex __ibm128 *x);
+void test_IFtype(w128ibm *a) { f_ibm128_arg(a); }
+void test_ICtype(cw128ibm *a) { f_ibm128_complex_arg(a); }
 #elif TEST_F128_PPC64
 typedef int invalid_7 __attribute((mode(KF))); // expected-error{{type of machine mode does not match type of base type}}
 typedef int invalid_8 __attribute((mode(KI))); // expected-error{{unknown machine mode}}
Index: clang/test/CodeGenCXX/ibm128-declarations.cpp
===
--- clang/test/CodeGenCXX/ibm128-declarations.cpp
+++ clang/test/CodeGenCXX/ibm128-declarations.cpp
@@ -59,6 +59,12 @@
   constexpr static __ibm128 mem = Q;
 };
 
+typedef float w128ibm __attribute__((mode(IF)));
+typedef _Complex float w128ibm_c __attribute__((mode(IC)));
+
+w128ibm icmode_self(w128ibm x

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 378600.
mizvekov added a comment.

- Handle different top level qualifiers in function parameters.
- More test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/sugared-auto.cpp

Index: clang/test/SemaCXX/sugared-auto.cpp
===
--- clang/test/SemaCXX/sugared-auto.cpp
+++ clang/test/SemaCXX/sugared-auto.cpp
@@ -1,31 +1,175 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fblocks -fenable-matrix -Wno-dynamic-exception-spec
 
 enum class N {};
 
-using T1 = int;
-auto x1 = T1();
-N t1 = x1;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-using T2 = T1 *;
-auto x2 = T2();
-N t2 = x2;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T2' (aka 'int *')}}
-
-auto *x3 = T2();
-N t3 = x3;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1 *' (aka 'int *')}}
-
-auto f1() { return T1(); }
-auto x4 = f1();
-N t4 = x4;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-decltype(auto) f2() { return T1(); }
-auto x5 = f2();
-N t5 = x5;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-auto x6 = [a = T1()] { return a; }();
-N t6 = x6;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
+using Animal = int;
+
+using AnimalPtr = Animal *;
+
+using Man = Animal;
+using Dog = Animal;
+
+using ManPtr = Man *;
+using DogPtr = Dog *;
+
+using SocratesPtr = ManPtr;
+
+using ConstMan = const Man;
+using ConstDog = const Dog;
+
+using Virus = void;
+using SARS = Virus;
+using Ebola = Virus;
+
+using Bacteria = float;
+using Bacilli = Bacteria;
+using Vibrio = Bacteria;
+
+struct Plant;
+using Gymnosperm = Plant;
+using Angiosperm = Plant;
+
+namespace variable {
+
+auto x1 = Animal();
+N t1 = x1; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+auto x2 = AnimalPtr();
+N t2 = x2; // expected-error {{lvalue of type 'AnimalPtr' (aka 'int *')}}
+
+auto *x3 = AnimalPtr();
+N t3 = x3; // expected-error {{lvalue of type 'Animal *' (aka 'int *')}}
+
+// Each variable deduces separately.
+auto x4 = Man(), x5 = Dog();
+N t4 = x4; // expected-error {{lvalue of type 'Man' (aka 'int')}}
+N t5 = x5; // expected-error {{lvalue of type 'Dog' (aka 'int')}}
+
+} // namespace variable
+
+namespace function_basic {
+
+auto f1() { return Animal(); }
+auto x1 = f1();
+N t1 = x1; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+decltype(auto) f2() { return Animal(); }
+auto x2 = f2();
+N t2 = x2; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+auto x3 = [a = Animal()] { return a; }();
+N t3 = x3; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+} // namespace function_basic
+
+namespace function_multiple_basic {
+
+N t1 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t2 = []() -> decltype(auto) { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t3 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Dog();
+  auto x = Man();
+  return x;
+}();
+
+N t4 = [] { // expected-error {{rvalue of type 'int'}}
+  if (true)
+return Dog();
+  return 1;
+}();
+
+N t5 = [] { // expected-error {{rvalue of type 'Virus' (aka 'void')}}
+  if (true)
+return Ebola();
+  return SARS();
+}();
+
+N t6 = [] { // expected-error {{rvalue of type 'void'}}
+  if (true)
+return SARS();
+  return;
+}();
+
+} // namespace function_multiple_basic
+
+#define TEST_AUTO(X, A, B) \
+  auto X(A a, B b) {   \
+if (0) \
+  return a;\
+if (0) \
+  return b;\
+return N();\
+  }
+#define TEST_DAUTO(X, A, B) \
+  decltype(auto) X(A a, B b) {  \
+if (0)  \
+  return static_cast(a); \
+if (0)  \
+  return static_cast(b); \
+return N(); \
+  }
+
+namespace misc {
+
+TEST_AUTO(t1, ManPtr, DogPtr)  // expected-error {{but deduced as 'Animal *' (aka 'int *')}}
+TEST_AUTO(t2, ManPtr, int *)   // expected-error {{but deduced as 'int *'}}
+TEST_AUTO(t3, SocratesPtr, ManPtr) // expected-err

[PATCH] D111529: Specify Clang vector builtins.

[Florian Hahn via Phabricator via cfe-commits]

fhahn created this revision.
fhahn added reviewers: scanon, erichkeane, rjmccall, aaron.ballman, dexonsmith, 
rsmith, craig.topper.
fhahn requested review of this revision.
Herald added a project: clang.

This patch specifies a set of vector builtins for Clang, as discussed on
cfe-dev:
https://lists.llvm.org/pipermail/cfe-dev/2021-September/068999.html
https://lists.llvm.org/pipermail/cfe-dev/2021-October/069070.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111529

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -506,6 +506,68 @@
   If it's an extension (OpenCL) vector, it's only available in C and OpenCL C.
   And it selects base on signedness of the condition operands (OpenCL v1.1 
s6.3.9).
 
+Vector Builtins
+---
+
+In addition to the operators mentioned above, Clang provides a set of builtins
+to perform additional operations on certain scalar and vector types.
+
+Let ``T`` be one of the following types:
+
+* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and 
_Bool
+* the standard floating types float or double
+* a half-precision floating point type, if one is supported on the target
+* a vector type.
+
+For scalar types, consider the operation applied to a vector with a single 
element.
+
+*Elementwise Builtins*
+
+Each builtin returns a vector equivalent to applying the specified operation
+elementwise to the input.
+
+Unless specified otherwise operation(±0) = ±0 and operation(±infinity) = 
±infinity
+
+=== 
 
==
+ NameOperation 
   Supported element types
+=== 
 
==
+ T __builtin_elementwise_abs(T x)   return the absolute value of a number 
x   integer and floating point types
+ T __builtin_elementwise_ceil(T x)  return the smallest integral value 
greater than or equal to x floating point types
+ T __builtin_elementwise_floor(T x) return the largest integral value less 
than or equal to x floating point types
+ T __builtin_elementwise_rint(T x)  return the integral value nearest to x 
(according to the  floating point types
+prevailing rounding mode) in 
floating-point format
+ T __builtin_elementwise_round(T x) return the integral value nearest to x 
rounding half-way casesfloating point types
+away from zero, regardless of the 
current rounding direction
+ T__builtin_elementwise_trunc(T x)  return the integral value nearest to 
but no larger in floating point types
+magnitude than x
+ T __builtin_elementwise_max(T x, T y)  return x or y, whichever is larger 
   integer and floating point types
+ T __builtin_elementwise_min(T x, T y)  return x or y, whichever is smaller
   integer and floating point types
+=== 
 
==
+
+
+*Reduction Builtins*
+
+Each builtin returns a scalar equivalent to applying the specified
+operation(x, y) as pairwise tree reduction to the input. The pairs are formed
+by concatenating both inputs and pairing adjacent elements.
+
+Let ``VT`` be a vector type and ``ET`` the element type of ``VT``.
+
+=== 
 
==
+ NameOperation 
   Supported element types
+=== 
 
==
+ ET __builtin_reduce_max(VT a)   return x or y, whichever is larger; 
If exactly one argument is   integer and floating point types
+ a NaN, return the other argument. If 
both arguments are NaNs,
+ fmax() return a NaN.
+ ET __builtin_reduce_min(VT a)   return x or y, whichever is smaller; 
If exactly one argument integer and floating point types
+ is a NaN, return the other argument. 
If both arguments are
+ NaNs, fmax() return a NaN.
+ ET __builtin_reduce_add(VT a)   \+

[PATCH] D111283: [clang] template / auto deduction deduces common sugar

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 378603.
mizvekov added a comment.

.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/SemaCXX/sugared-auto.cpp

Index: clang/test/SemaCXX/sugared-auto.cpp
===
--- clang/test/SemaCXX/sugared-auto.cpp
+++ clang/test/SemaCXX/sugared-auto.cpp
@@ -1,31 +1,175 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++14
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++20 -fblocks -fenable-matrix -Wno-dynamic-exception-spec
 
 enum class N {};
 
-using T1 = int;
-auto x1 = T1();
-N t1 = x1;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-using T2 = T1 *;
-auto x2 = T2();
-N t2 = x2;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T2' (aka 'int *')}}
-
-auto *x3 = T2();
-N t3 = x3;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1 *' (aka 'int *')}}
-
-auto f1() { return T1(); }
-auto x4 = f1();
-N t4 = x4;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-decltype(auto) f2() { return T1(); }
-auto x5 = f2();
-N t5 = x5;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
-
-auto x6 = [a = T1()] { return a; }();
-N t6 = x6;
-// expected-error@-1 {{cannot initialize a variable of type 'N' with an lvalue of type 'T1' (aka 'int')}}
+using Animal = int;
+
+using AnimalPtr = Animal *;
+
+using Man = Animal;
+using Dog = Animal;
+
+using ManPtr = Man *;
+using DogPtr = Dog *;
+
+using SocratesPtr = ManPtr;
+
+using ConstMan = const Man;
+using ConstDog = const Dog;
+
+using Virus = void;
+using SARS = Virus;
+using Ebola = Virus;
+
+using Bacteria = float;
+using Bacilli = Bacteria;
+using Vibrio = Bacteria;
+
+struct Plant;
+using Gymnosperm = Plant;
+using Angiosperm = Plant;
+
+namespace variable {
+
+auto x1 = Animal();
+N t1 = x1; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+auto x2 = AnimalPtr();
+N t2 = x2; // expected-error {{lvalue of type 'AnimalPtr' (aka 'int *')}}
+
+auto *x3 = AnimalPtr();
+N t3 = x3; // expected-error {{lvalue of type 'Animal *' (aka 'int *')}}
+
+// Each variable deduces separately.
+auto x4 = Man(), x5 = Dog();
+N t4 = x4; // expected-error {{lvalue of type 'Man' (aka 'int')}}
+N t5 = x5; // expected-error {{lvalue of type 'Dog' (aka 'int')}}
+
+} // namespace variable
+
+namespace function_basic {
+
+auto f1() { return Animal(); }
+auto x1 = f1();
+N t1 = x1; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+decltype(auto) f2() { return Animal(); }
+auto x2 = f2();
+N t2 = x2; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+auto x3 = [a = Animal()] { return a; }();
+N t3 = x3; // expected-error {{lvalue of type 'Animal' (aka 'int')}}
+
+} // namespace function_basic
+
+namespace function_multiple_basic {
+
+N t1 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t2 = []() -> decltype(auto) { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Man();
+  return Dog();
+}();
+
+N t3 = [] { // expected-error {{rvalue of type 'Animal' (aka 'int')}}
+  if (true)
+return Dog();
+  auto x = Man();
+  return x;
+}();
+
+N t4 = [] { // expected-error {{rvalue of type 'int'}}
+  if (true)
+return Dog();
+  return 1;
+}();
+
+N t5 = [] { // expected-error {{rvalue of type 'Virus' (aka 'void')}}
+  if (true)
+return Ebola();
+  return SARS();
+}();
+
+N t6 = [] { // expected-error {{rvalue of type 'void'}}
+  if (true)
+return SARS();
+  return;
+}();
+
+} // namespace function_multiple_basic
+
+#define TEST_AUTO(X, A, B) \
+  auto X(A a, B b) {   \
+if (0) \
+  return a;\
+if (0) \
+  return b;\
+return N();\
+  }
+#define TEST_DAUTO(X, A, B) \
+  decltype(auto) X(A a, B b) {  \
+if (0)  \
+  return static_cast(a); \
+if (0)  \
+  return static_cast(b); \
+return N(); \
+  }
+
+namespace misc {
+
+TEST_AUTO(t1, ManPtr, DogPtr)  // expected-error {{but deduced as 'Animal *' (aka 'int *')}}
+TEST_AUTO(t2, ManPtr, int *)   // expected-error {{but deduced as 'int *'}}
+TEST_AUTO(t3, SocratesPtr, ManPtr) // expected-error {{but deduced as 'ManPtr' (aka 'int *')}}
+
+TEST_AUTO(t4, _Atomic(Man), _Atom

[PATCH] D111081: [clang] [MinGW] Fix paths on Gentoo

[Michał Górny via Phabricator via cfe-commits]

mgorny added a comment.

In D111081#3043831 , @mstorsjo wrote:

> The change looks ok to me, but I think it'd be good to have a testcase for 
> finding these paths (IIRC there are a bunch of simulated sysroots under 
> clang/test/Driver).

Seconded. There are already some Gentoo trees there, so it shouldn't be hard to 
add one more.


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

https://reviews.llvm.org/D111081

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

[PATCH] D111316: [CFE][Codegen][In-progress] Remove CodeGenFunction::InitTempAlloca()

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntime.cpp:4784
+  CGF.Builder.CreateStore(llvm::ConstantInt::get(CGF.IntPtrTy, 0),
+  NumLVal.getAddress(CGF));
   llvm::Value *PrevVal = CGF.EmitLoadOfScalar(NumLVal, E->getExprLoc());

rjmccall wrote:
> The original generated code here is very strange:
> 
> ```
> %depobj.size.addr = alloca i64
> ...  
> store i64 0, i64* %depobj.size.addr// currently in prologue
> ...
> %numdeps = load // from the size field of the struct kmp_depend_info which 
> precedes all dependent objects
> ...
> %tmp = load i64, i64* %depobj.size.addr
> %sum = add nuw i64 %tmp, i64 %numdeps
> store i64 %sum, %i64* %depobj.size.addr
> ...
> // and then in the one place we actually call this function, we
> // immediately sum up all the %sums for all the dependent objects
> ```
> 
> The funny thing about this code is that, because the zeroing of 
> `%depobj.size.addr` is only done in the prologue, it increases by the current 
> element count of the depend object every time if this code is run multiple 
> times, which I think cannot possibly be correct.  Notably, the code to 
> actually copy dependency data does not seem to have this bug because 
> `PosLVal` is zeroed immediately.
> 
> So I'm pretty sure this change is actually a bug fix in the treatment of 
> `depend(depobj : ...)`.  However, I'd really like Alexey to review and 
> approve, because if `%depobj.size.addr` is *not* supposed to accumulate 
> values in a loop, then I really don't understand why it exists at all.
> 
> 
Ho John, you're right, a bugfix. The change looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111316

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

[PATCH] D111518: Add release note about `TypeLoc` matchers.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111518

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

[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam updated this revision to Diff 378630.
saiislam marked 4 inline comments as done.
saiislam added a comment.

1. Changed the option from path to nvlink-command.
2. Command line arguments are now parsed using proper API.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp

Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -25,6 +25,7 @@
 /// 2. nvlink -o a.out-openmp-nvptx64 /tmp/a.cubin /tmp/b.cubin
 //===-===//
 
+#include "clang/Basic/Version.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Errc.h"
@@ -41,6 +42,19 @@
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
+// Mark all our options with this category, everything else (except for -help)
+// will be hidden.
+static cl::OptionCategory
+ClangNvlinkWrapperCategory("clang-nvlink-wrapper options");
+
+static cl::opt NvlinkUserPath("nvlink-command",
+   cl::desc("path of nvlink binary"),
+   cl::cat(ClangNvlinkWrapperCategory));
+
+// Do not parse nvlink options
+static cl::list
+NVArgs(cl::Sink, cl::desc("..."));
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
@@ -119,8 +133,20 @@
   return Error::success();
 }
 
+static void PrintVersion(raw_ostream &OS) {
+  OS << clang::getClangToolFullVersion("clang-offload-bundler") << '\n';
+}
+
 int main(int argc, const char **argv) {
   sys::PrintStackTraceOnErrorSignal(argv[0]);
+  cl::SetVersionPrinter(PrintVersion);
+  cl::HideUnrelatedOptions(ClangNvlinkWrapperCategory);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A wrapper tool over nvlink program. It transparently passes every \n"
+  "input option and objects to nvlink except archive files and path of \n"
+  "nvlink binary. It reads each input archive file to extract archived \n"
+  "cubin files as temporary files.\n");
 
   if (Help) {
 cl::PrintHelpMessage();
@@ -132,12 +158,7 @@
 exit(1);
   };
 
-  ErrorOr NvlinkPath = sys::findProgramByName("nvlink");
-  if (!NvlinkPath) {
-reportError(createStringError(NvlinkPath.getError(),
-  "unable to find 'nvlink' in path"));
-  }
-
+  std::string NvlinkPath;
   SmallVector Argv(argv, argv + argc);
   SmallVector ArgvSubst;
   SmallVector TmpFiles;
@@ -145,8 +166,8 @@
   StringSaver Saver(Alloc);
   cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (size_t i = 0; i < NVArgs.size(); ++i) {
+std::string Arg = NVArgs[i];
 if (sys::path::extension(Arg) == ".a") {
   if (Error Err = extractArchiveFiles(Arg, ArgvSubst, TmpFiles))
 reportError(std::move(Err));
@@ -155,7 +176,19 @@
 }
   }
 
-  if (Error Err = runNVLink(NvlinkPath.get(), ArgvSubst))
+  NvlinkPath = NvlinkUserPath;
+
+  // If user hasn't specified nvlink binary then search it in PATH
+  if (NvlinkPath.empty()) {
+ErrorOr NvlinkPathErr = sys::findProgramByName("nvlink");
+if (!NvlinkPathErr) {
+  reportError(createStringError(NvlinkPathErr.getError(),
+"unable to find 'nvlink' in path"));
+}
+NvlinkPath = NvlinkPathErr.get();
+  }
+
+  if (Error Err = runNVLink(NvlinkPath, ArgvSubst))
 reportError(std::move(Err));
   if (Error Err = cleanupTmpFiles(TmpFiles))
 reportError(std::move(Err));
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -613,6 +613,12 @@
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "nvptx", GPUArch,
   false, false);
 
+  // Find nvlink and pass it as "--nvlink-command=" argument of clang-nvlink-wrapper.
+  auto NvlinkBin = getToolChain().GetProgramPath("nvlink");
+  const char *NvlinkPath =
+  Args.MakeArgString(Twine("--nvlink-command=" + NvlinkBin));
+  CmdArgs.push_back(NvlinkPath);
+
   const char *Exec =
   Args.MakeArgString(getToolChain().GetProgramPath("clang-nvlink-wrapper"));
   C.addCommand(std::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam updated this revision to Diff 378633.
saiislam added a comment.

Fixed typo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

Files:
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp

Index: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
===
--- clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
+++ clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp
@@ -25,6 +25,7 @@
 /// 2. nvlink -o a.out-openmp-nvptx64 /tmp/a.cubin /tmp/b.cubin
 //===-===//
 
+#include "clang/Basic/Version.h"
 #include "llvm/Object/Archive.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Errc.h"
@@ -41,6 +42,19 @@
 
 static cl::opt Help("h", cl::desc("Alias for -help"), cl::Hidden);
 
+// Mark all our options with this category, everything else (except for -help)
+// will be hidden.
+static cl::OptionCategory
+ClangNvlinkWrapperCategory("clang-nvlink-wrapper options");
+
+static cl::opt NvlinkUserPath("nvlink-command",
+   cl::desc("path of nvlink binary"),
+   cl::cat(ClangNvlinkWrapperCategory));
+
+// Do not parse nvlink options
+static cl::list
+NVArgs(cl::Sink, cl::desc("..."));
+
 static Error runNVLink(std::string NVLinkPath,
SmallVectorImpl &Args) {
   std::vector NVLArgs;
@@ -119,8 +133,20 @@
   return Error::success();
 }
 
+static void PrintVersion(raw_ostream &OS) {
+  OS << clang::getClangToolFullVersion("clang-nvlink-wrapper") << '\n';
+}
+
 int main(int argc, const char **argv) {
   sys::PrintStackTraceOnErrorSignal(argv[0]);
+  cl::SetVersionPrinter(PrintVersion);
+  cl::HideUnrelatedOptions(ClangNvlinkWrapperCategory);
+  cl::ParseCommandLineOptions(
+  argc, argv,
+  "A wrapper tool over nvlink program. It transparently passes every \n"
+  "input option and objects to nvlink except archive files and path of \n"
+  "nvlink binary. It reads each input archive file to extract archived \n"
+  "cubin files as temporary files.\n");
 
   if (Help) {
 cl::PrintHelpMessage();
@@ -132,12 +158,7 @@
 exit(1);
   };
 
-  ErrorOr NvlinkPath = sys::findProgramByName("nvlink");
-  if (!NvlinkPath) {
-reportError(createStringError(NvlinkPath.getError(),
-  "unable to find 'nvlink' in path"));
-  }
-
+  std::string NvlinkPath;
   SmallVector Argv(argv, argv + argc);
   SmallVector ArgvSubst;
   SmallVector TmpFiles;
@@ -145,8 +166,8 @@
   StringSaver Saver(Alloc);
   cl::ExpandResponseFiles(Saver, cl::TokenizeGNUCommandLine, Argv);
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (size_t i = 0; i < NVArgs.size(); ++i) {
+std::string Arg = NVArgs[i];
 if (sys::path::extension(Arg) == ".a") {
   if (Error Err = extractArchiveFiles(Arg, ArgvSubst, TmpFiles))
 reportError(std::move(Err));
@@ -155,7 +176,19 @@
 }
   }
 
-  if (Error Err = runNVLink(NvlinkPath.get(), ArgvSubst))
+  NvlinkPath = NvlinkUserPath;
+
+  // If user hasn't specified nvlink binary then search it in PATH
+  if (NvlinkPath.empty()) {
+ErrorOr NvlinkPathErr = sys::findProgramByName("nvlink");
+if (!NvlinkPathErr) {
+  reportError(createStringError(NvlinkPathErr.getError(),
+"unable to find 'nvlink' in path"));
+}
+NvlinkPath = NvlinkPathErr.get();
+  }
+
+  if (Error Err = runNVLink(NvlinkPath, ArgvSubst))
 reportError(std::move(Err));
   if (Error Err = cleanupTmpFiles(TmpFiles))
 reportError(std::move(Err));
Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -613,6 +613,12 @@
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "nvptx", GPUArch,
   false, false);
 
+  // Find nvlink and pass it as "--nvlink-command=" argument of clang-nvlink-wrapper.
+  auto NvlinkBin = getToolChain().GetProgramPath("nvlink");
+  const char *NvlinkPath =
+  Args.MakeArgString(Twine("--nvlink-command=" + NvlinkBin));
+  CmdArgs.push_back(NvlinkPath);
+
   const char *Exec =
   Args.MakeArgString(getToolChain().GetProgramPath("clang-nvlink-wrapper"));
   C.addCommand(std::make_unique(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111529: Specify Clang vector builtins.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:552
+operation(x, y) as pairwise tree reduction to the input. The pairs are formed
+by concatenating both inputs and pairing adjacent elements.
+

I'm not sure I understand what is being concatenated here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Nico Weber via Phabricator via cfe-commits]

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

Very cool.




Comment at: clang/lib/Parse/ParsePragma.cpp:276
+
+tok::OnOffSwitch OOS;
+Token Tok;

Move down 10 lines until you need it?



Comment at: clang/lib/Parse/ParsePragma.cpp:280
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_access);
+  return;

Is it important that this is a warning?

Independently if we have access to `Parser` here (not sure), there's 
`Parser::ExpectAndConsume`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111440

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

[PATCH] D111542: [analyzer] Retrieve VLA extent from its redeclaration.

[Denys Petrov via Phabricator via cfe-commits]

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

Fix a case when the extent can not be retrieved correctly from VLA declaration. 
Use redeclaration to get the array extent.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111542

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/initialization.c

Index: clang/test/Analysis/initialization.c
===
--- clang/test/Analysis/initialization.c
+++ clang/test/Analysis/initialization.c
@@ -97,3 +97,22 @@
   // FIXME: Should warn {{garbage or undefined}}.
   int res = glob_arr2[x][y]; // no-warning
 }
+
+const int glob_arr3[]; // VLA
+const int glob_arr3[4] = {1, 2, 3};
+void foo() {
+  clang_analyzer_eval(glob_arr3[0] == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[1] == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[2] == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[3] == 0); // expected-warning{{TRUE}}
+}
+
+void glob_invalid_index5() {
+  int x = 42;
+  int res = glob_arr3[x]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_invalid_index6() {
+  int x = -42;
+  int res = glob_arr3[x]; // expected-warning{{garbage or undefined}}
+}
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1660,7 +1660,7 @@
   } else if (const VarRegion *VR = dyn_cast(superR)) {
 // Check if the containing array has an initialized value that we can trust.
 // We can trust a const value or a value of a global initializer in main().
-const VarDecl *VD = VR->getDecl();
+const VarDecl *VD = VR->getDecl()->getMostRecentDecl();
 if (VD->getType().isConstQualified() ||
 R->getElementType().isConstQualified() ||
 (B.isMainAnalysis() && VD->hasGlobalStorage())) {
@@ -1669,48 +1669,47 @@
   // The array index has to be known.
   if (auto CI = R->getIndex().getAs()) {
 // If it is not an array, return Undef.
-QualType T = VD->getType();
-const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T);
-if (!CAT)
-  return UndefinedVal();
-
-// Support one-dimensional array.
-// C++20 [expr.add] 7.6.6.4 (excerpt):
-//   If P points to an array element i of an array object x with n
-//   elements, where i < 0 or i > n, the behavior is undefined.
-//   Dereferencing is not allowed on the "one past the last
-//   element", when i == n.
-// Example:
-//   const int arr[4] = {1, 2};
-//   const int *ptr = arr;
-//   int x0 = ptr[0]; // 1
-//   int x1 = ptr[1]; // 2
-//   int x2 = ptr[2]; // 0
-//   int x3 = ptr[3]; // 0
-//   int x4 = ptr[4]; // UB
-// TODO: Support multidimensional array.
-if (!isa(CAT->getElementType())) {
-  // One-dimensional array.
-  const llvm::APSInt &Idx = CI->getValue();
-  const auto I = static_cast(Idx.getExtValue());
-  // Use `getZExtValue` because array extent can not be negative.
-  const uint64_t Extent = CAT->getSize().getZExtValue();
-  // Check for `Idx < 0`, NOT for `I < 0`, because `Idx` CAN be
-  // negative, but `I` can NOT.
-  if (Idx < 0 || I >= Extent)
-return UndefinedVal();
-
-  // C++20 [expr.add] 9.4.17.5 (excerpt):
-  //   i-th array element is value-initialized for each k < i ≤ n,
-  //   where k is an expression-list size and n is an array extent.
-  if (I >= InitList->getNumInits())
-return svalBuilder.makeZeroVal(R->getElementType());
-
-  // Return a constant value, if it is presented.
-  // FIXME: Support other SVals.
-  const Expr *E = InitList->getInit(I);
-  if (Optional V = svalBuilder.getConstantVal(E))
-return *V;
+const QualType T = VD->getType();
+if (const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T)) {
+  // Support one-dimensional array.
+  // C++20 [expr.add] 7.6.6.4 (excerpt):
+  //   If P points to an array element i of an array object x with n
+  //   elements, where i < 0 or i > n, the behavior is undefined.
+  //   Dereferencing is not allowed on the "one past the l

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Mubashar Ahmad via Phabricator via cfe-commits]

mubashar_ updated this revision to Diff 378645.
mubashar_ added a comment.

Added files that were missing from previous diff.


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

https://reviews.llvm.org/D109825

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Driver/aarch64-cpus.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -898,6 +898,17 @@
  AArch64::AEK_RDM | AArch64::AEK_FP16 |
  AArch64::AEK_DOTPROD | AArch64::AEK_RCPC,
  "8.2-A"),
+ARMCPUTestParams("cortex-a510", "armv9-a", "neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_FP |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_RDM |
+ AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+ AArch64::AEK_SVE2 | AArch64::AEK_BF16 |
+ AArch64::AEK_I8MM | AArch64::AEK_SVE2BITPERM |
+ AArch64::AEK_PAUTH | AArch64::AEK_MTE |
+ AArch64::AEK_SSBS | AArch64::AEK_FP16FML |
+ AArch64::AEK_SB,
+ "9-A"),
 ARMCPUTestParams("cortex-a57", "armv8-a", "crypto-neon-fp-armv8",
  AArch64::AEK_CRC | AArch64::AEK_CRYPTO |
  AArch64::AEK_FP | AArch64::AEK_SIMD,
@@ -1178,7 +1189,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 48;
+static constexpr unsigned NumAArch64CPUArchs = 49;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -50,6 +50,7 @@
 CortexA35,
 CortexA53,
 CortexA55,
+CortexA510,
 CortexA57,
 CortexA65,
 CortexA72,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -78,6 +78,7 @@
 break;
   case CortexA53:
   case CortexA55:
+  case CortexA510:
 PrefFunctionLogAlignment = 4;
 break;
   case CortexA57:
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -630,6 +630,22 @@
FeatureFuseAddress,
]>;
 
+def ProcA510: SubtargetFeature<"a510", "ARMProcFamily", "CortexA510",
+   "Cortex-A510 ARM processors", [
+   HasV9_0aOps,
+   FeatureNEON,
+   FeaturePerfMon,
+   FeatureMatMulInt8,
+   FeatureBF16,
+   FeatureAM,
+   FeatureMTE,
+   FeatureETE,
+   FeatureSVE2BitPerm,
+   FeatureFP16FML,
+   FeatureFuseAES,
+   FeaturePostRAScheduler
+   ]>;
+
 def ProcA57 : SubtargetFeature<"a57", "ARMProcFamily", "CortexA57",
"Cortex-A57 ARM processors", [
FeatureBalanceFPOps,
@@ -1186,6 +1202,7 @@
 def : ProcessorModel<"cortex-a34", CortexA53Model, [ProcA35]>;
 def : ProcessorModel<"cortex-a53", CortexA53Model, [ProcA53]>;
 def : ProcessorModel<"cortex-a55", CortexA55Model, [ProcA55]>;
+def : ProcessorModel<"cortex-a510", CortexA55Model, [ProcA510]>;
 def : ProcessorModel<"cortex-a57", CortexA57Model, [ProcA57]>;
 def : ProcessorModel<"cortex-a65", CortexA53Model, [ProcA65]>;
 def : ProcessorModel<"cortex-a65ae", CortexA53Model, [ProcA65]>;
Index: llvm/include/llvm/Support/AArch64TargetParser.def
===
--- llvm/include/llvm/Support/AArch64TargetParser.def
+++ llvm/include/llvm/Support/AArch64TargetParser.def
@@ -144,6 +144,10 @@
  (AArch64::AEK_CRC))
 AARCH64_CPU_NAME("cortex-a55", ARMV8_2A, F

[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, rsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When using explicit Clang modules, some declarations might unexpectedly become 
invisible.

This was noticed in the following scenario:

- module named `Interface` contains an ObjC interface declaration of the same 
name, and its PCM is passed to Clang via the `-fmodule-file=` argument,
- another module referring to `Interface` within an attribute (`objc_bridge`) 
is passed to Clang (also via the `-fmodule-file=` argument),
- the Clang invocation then can't find the `Interface` interface declaration.

This seems to be caused by the mechanism that loads PCM files passed via 
`-fmodule-file=` which creates an `IdentifierInfo` for the module name. 
I'm not sure why exactly that trips up name resolution, but using `StringRef` 
for the module name resolves the error. Creating an `IdentifierInfo` with some 
prefix (e.g. `CI.getPreprocessor().getIdentifierInfo("LoadModuleCacheKey_" + 
ModuleName)`) also resolves the issue.

Note that the `-fmodule-file==` form of the argument doesn't suffer 
from this issue, since it doesn't create `IdentifierInfo` for the module name.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111543

Files:
  clang/include/clang/Lex/ModuleMap.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/test/Modules/Inputs/interface-visibility-2/Interface.h
  clang/test/Modules/Inputs/interface-visibility-2/InterfaceBridge.h
  clang/test/Modules/Inputs/interface-visibility-2/module.modulemap
  clang/test/Modules/interface-visibility-2.m

Index: clang/test/Modules/interface-visibility-2.m
===
--- /dev/null
+++ clang/test/Modules/interface-visibility-2.m
@@ -0,0 +1,25 @@
+// RUN: rm -rf %t && mkdir %t
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=InterfaceBridge \
+// RUN:   %S/Inputs/interface-visibility-2/module.modulemap -o %t/InterfaceBridge.pcm
+
+// RUN: %clang_cc1 -fmodules -x objective-c -emit-module -fmodule-name=Interface \
+// RUN:   %S/Inputs/interface-visibility-2/module.modulemap -o %t/Interface.pcm
+
+// Check that the `-fmodule-file==` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/Interface-visibility-2 \
+// RUN:   -fmodule-file=InterfaceBridge=%t/InterfaceBridge.pcm -fmodule-file=Interface=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/interface-visibility-2/module.modulemap -verify
+
+// Check that the `-fmodule-file=` form succeeds:
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -I %S/Inputs/Interface-visibility-2 \
+// RUN:   -fmodule-file=%t/InterfaceBridge.pcm -fmodule-file=%t/Interface.pcm \
+// RUN:   -fmodule-map-file=%S/Inputs/interface-visibility-2/module.modulemap -verify
+
+#import "InterfaceBridge.h"
+#import "Interface.h"
+
+@interface Interface (User)
+@end
+
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/interface-visibility-2/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/interface-visibility-2/module.modulemap
@@ -0,0 +1,7 @@
+module InterfaceBridge {
+  header "InterfaceBridge.h"
+}
+
+module Interface {
+  header "Interface.h"
+}
Index: clang/test/Modules/Inputs/interface-visibility-2/InterfaceBridge.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/interface-visibility-2/InterfaceBridge.h
@@ -0,0 +1 @@
+typedef struct __attribute__((objc_bridge(Interface))) Foo *Bar;
Index: clang/test/Modules/Inputs/interface-visibility-2/Interface.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/interface-visibility-2/Interface.h
@@ -0,0 +1,2 @@
+@interface Interface
+@end
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -1617,28 +1617,27 @@
   // the files we were handed.
   struct ReadModuleNames : ASTReaderListener {
 CompilerInstance &CI;
-llvm::SmallVector LoadedModules;
+llvm::SmallVector LoadedModules;
 
 ReadModuleNames(CompilerInstance &CI) : CI(CI) {}
 
 void ReadModuleName(StringRef ModuleName) override {
-  LoadedModules.push_back(
-  CI.getPreprocessor().getIdentifierInfo(ModuleName));
+  LoadedModules.push_back(ModuleName);
 }
 
 void registerAll() {
   ModuleMap &MM = CI.getPreprocessor().getHeaderSearchInfo().getModuleMap();
-  for (auto *II : LoadedModules)
-MM.cacheModuleLoad(*II, MM.findModule(II->getName()));
+  for (StringRef LoadedModule : LoadedModules)
+MM.cacheModuleLoad(LoadedModule, MM.findModule(LoadedModule));
   LoadedModules.clear();

[PATCH] D111542: [analyzer] Retrieve VLA extent from its redeclaration.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@NoQ @martong 
Guys, I've patched the bug. Could you check it? It works, but I have doubts 
using `VR->getDecl()->getMostRecentDecl();` as a correct way to get a right 
declaration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111542

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

[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

It'd be great if someone could clarify why the extra `IdentifierInfo` would 
trip up name resolution.

Suggestions on naming the test file are also welcome.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111543

___
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.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

Ping.


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] D111545: [Clang][NFC] Fix multiline comment prefixes in function headers

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam created this revision.
saiislam added a reviewer: MyDeveloperDay.
Herald added subscribers: kerbowa, nhaehnle, jvesely.
saiislam requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Cleanup of D105191  after latest clang-format 
changes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111545

Files:
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/Cuda.cpp


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -744,8 +744,8 @@
 
 addOpenMPDeviceRTL(getDriver(), DriverArgs, CC1Args, BitcodeSuffix,
getTriple());
-AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx", 
GpuArch,
-/* bitcode SDL?*/ true, /* PostClang Link? */ true);
+AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx",
+   GpuArch, true, true);
   }
 }
 
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -115,9 +115,7 @@
   }
 
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
-  SubArchName,
-  /* bitcode SDL?*/ true,
-  /* PostClang Link? */ false);
+ SubArchName, true, false);
   // Add an intermediate output file.
   CmdArgs.push_back("-o");
   const char *OutputFileName =


Index: clang/lib/Driver/ToolChains/Cuda.cpp
===
--- clang/lib/Driver/ToolChains/Cuda.cpp
+++ clang/lib/Driver/ToolChains/Cuda.cpp
@@ -744,8 +744,8 @@
 
 addOpenMPDeviceRTL(getDriver(), DriverArgs, CC1Args, BitcodeSuffix,
getTriple());
-AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx", GpuArch,
-/* bitcode SDL?*/ true, /* PostClang Link? */ true);
+AddStaticDeviceLibsPostLinking(getDriver(), DriverArgs, CC1Args, "nvptx",
+   GpuArch, true, true);
   }
 }
 
Index: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
+++ clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
@@ -115,9 +115,7 @@
   }
 
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
-  SubArchName,
-  /* bitcode SDL?*/ true,
-  /* PostClang Link? */ false);
+ SubArchName, true, false);
   // Add an intermediate output file.
   CmdArgs.push_back("-o");
   const char *OutputFileName =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[Saiyedul Islam via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp:120
+  /* bitcode SDL?*/ true,
+  /* PostClang Link? */ false);
   // Add an intermediate output file.

MyDeveloperDay wrote:
> This file now fails clang-format
Thanks for reporting. Fixed it in D111545. Please have a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

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

[PATCH] D111548: [Clang] Add the `annotate_type` attribute

[Martin Böhme via Phabricator via cfe-commits]

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

This is an analog to the `annotate` attribute but for types. The intent is to 
allow adding arbitrary annotations to types for use in static analysis tools.

DO NOT REVIEW YET

I'm uploading this for discussion on cfe-dev. Will remove this note once the 
change is ready for review.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111548

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Sema/annotate-type.c

Index: clang/test/Sema/annotate-type.c
===
--- /dev/null
+++ clang/test/Sema/annotate-type.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -fsyntax-only -fdouble-square-bracket-attributes -verify
+
+void foo(float *__attribute__((annotate_type("foo"))) a) {
+  // Only the GNU spelling of the attribute can be applied to decl specifiers.
+  int __attribute__((annotate_type("bar"))) w;
+  int [[clang::annotate_type("bar")]] w2; // expected-error {{'annotate_type' attribute cannot be applied to types}}
+
+  int *__attribute__((annotate_type("bar"))) x;
+  int *[[clang::annotate_type("bar")]] x2;
+
+  int *__attribute__((annotate_type(1))) y; // expected-error {{'annotate_type' attribute requires a string}}
+  int *[[clang::annotate_type(1)]] y2;  // expected-error {{'annotate_type' attribute requires a string}}
+
+  int *__attribute__((annotate_type("bar", 1))) z;
+  int *[[clang::annotate_type("bar", 1)]] z2;
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -8036,6 +8036,30 @@
 CurType = T;
 }
 
+static void HandleAnnotateTypeAttr(TypeProcessingState &State,
+   QualType &CurType, const ParsedAttr &Attr) {
+  Sema &S = State.getSema();
+
+  // Make sure that there is a string literal as the annotation's first
+  // argument.
+  StringRef Str;
+  if (!S.checkStringLiteralArgumentAttr(Attr, 0, Str))
+return;
+
+  llvm::SmallVector Args;
+  Args.reserve(Attr.getNumArgs() - 1);
+  for (unsigned Idx = 1; Idx < Attr.getNumArgs(); Idx++) {
+assert(!Attr.isArgIdent(Idx));
+Args.push_back(Attr.getArgAsExpr(Idx));
+  }
+  if (!S.ConstantFoldAttrArgs(Attr, Args)) {
+return;
+  }
+  auto *AnnotateTypeAttr =
+  AnnotateTypeAttr::Create(S.Context, Str, Args.data(), Args.size(), Attr);
+  CurType = State.getAttributedType(AnnotateTypeAttr, CurType, CurType);
+}
+
 static void HandleLifetimeBoundAttr(TypeProcessingState &State,
 QualType &CurType,
 ParsedAttr &Attr) {
@@ -8298,6 +8322,11 @@
   attr.setUsedAsTypeAttr();
   break;
 }
+case ParsedAttr::AT_AnnotateType: {
+  HandleAnnotateTypeAttr(state, type, attr);
+  attr.setUsedAsTypeAttr();
+  break;
+}
 }
 
 // Handle attributes that are defined in a macro. We do not want this to be
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3863,48 +3863,10 @@
 void Sema::AddAnnotationAttr(Decl *D, const AttributeCommonInfo &CI,
  StringRef Str, MutableArrayRef Args) {
   auto *Attr = AnnotateAttr::Create(Context, Str, Args.data(), Args.size(), CI);
-  llvm::SmallVector Notes;
-  for (unsigned Idx = 0; Idx < Attr->args_size(); Idx++) {
-Expr *&E = Attr->args_begin()[Idx];
-assert(E && "error are handled before");
-if (E->isValueDependent() || E->isTypeDependent())
-  continue;
-
-if (E->getType()->isArrayType())
-  E = ImpCastExprToType(E, Context.getPointerType(E->getType()),
-clang::CK_ArrayToPointerDecay)
-  .get();
-if (E->getType()->isFunctionType())
-  E = ImplicitCastExpr::Create(Context,
-   Context.getPointerType(E->getType()),
-   clang::CK_FunctionToPointerDecay, E, nullptr,
-   VK_PRValue, FPOptionsOverride());
-if (E->isLValue())
-  E = ImplicitCastExpr::Create(Context, E->getType().getNonReferenceType(),
-   clang::CK_LValueToRValue, E, nullptr,
-   VK_PRValue, FPOptionsOverride());
-
-Expr::EvalResult Eval;
-Notes.clear();
-Eval.Diag = &Notes;
-
-bool Result =
-E->EvaluateAsConstantExpr(Eval, Context);
-
-/// Result means the expression can be folded to a constant.
-/// Note.empty() means the expression is a valid constant expr

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Hans Wennborg via Phabricator via cfe-commits]

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



Comment at: clang/lib/Parse/ParsePragma.cpp:280
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_access);
+  return;

thakis wrote:
> Is it important that this is a warning?
> 
> Independently if we have access to `Parser` here (not sure), there's 
> `Parser::ExpectAndConsume`.
> Is it important that this is a warning?

You mean as opposed to an error? Or as opposed to accepting slightly 
alternative spellings? I don't think we want to accept any other syntax than 
MSVC. And the custom seems to be to warn and ignore when we can't parse a 
pragma so I'm following that pattern.

> Independently if we have access to Parser here (not sure), there's 
> Parser::ExpectAndConsume.

Sadly the PragmaHandler classes don't have access to it. It might be possible 
to plumb it through, but I'm not sure whether it would be worth it.

While looking at it, I did switch to more specific diags for the parens though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111440

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

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Hans Wennborg via Phabricator via cfe-commits]

hans updated this revision to Diff 378660.
hans added a comment.

Slightly better diags, try to appease clang-format.


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

https://reviews.llvm.org/D111440

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/CodeGen/pragma-fenv_access.c
  clang/test/Parser/pragma-fenv_access-ms.c

Index: clang/test/Parser/pragma-fenv_access-ms.c
===
--- /dev/null
+++ clang/test/Parser/pragma-fenv_access-ms.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple i686-pc-win32 -fms-extensions -fsyntax-only -verify %s
+
+#pragma fenv_access (on)
+#pragma fenv_access (off)
+
+#pragma fenv_access // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access foo // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access on // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access ( // expected-warning{{incorrect use of '#pragma fenv_access}}
+#pragma fenv_access (on // expected-warning{{missing ')' after '#pragma fenv_access'}}
+#pragma fenv_access (on) foo // expected-warning{{extra tokens at end of '#pragma fenv_access'}}
+
+void f() {
+  (void)0;
+  #pragma fenv_access (on) // expected-error{{'#pragma fenv_access' can only appear at file scope or at the start of a compound statement}}
+}
Index: clang/test/CodeGen/pragma-fenv_access.c
===
--- clang/test/CodeGen/pragma-fenv_access.c
+++ clang/test/CodeGen/pragma-fenv_access.c
@@ -1,6 +1,11 @@
 // RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - -fms-extensions -DMS | FileCheck %s
 
+#ifdef MS
+#pragma fenv_access (on)
+#else
 #pragma STDC FENV_ACCESS ON
+#endif
 
 float func_01(float x, float y) {
   return x + y;
@@ -25,7 +30,11 @@
 // CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
 
 
+#ifdef MS
+#pragma fenv_access (off)
+#else
 #pragma STDC FENV_ACCESS OFF
+#endif
 
 float func_04(float x, float y) {
   #pragma float_control(except, off)
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -785,6 +785,7 @@
 HandlePragmaFPContract();
 return nullptr;
   case tok::annot_pragma_fenv_access:
+  case tok::annot_pragma_fenv_access_ms:
 HandlePragmaFEnvAccess();
 return nullptr;
   case tok::annot_pragma_fenv_round:
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt.cpp
+++ clang/lib/Parse/ParseStmt.cpp
@@ -374,8 +374,11 @@
 return StmtError();
 
   case tok::annot_pragma_fenv_access:
+  case tok::annot_pragma_fenv_access_ms:
 ProhibitAttributes(Attrs);
-Diag(Tok, diag::err_pragma_stdc_fenv_access_scope);
+Diag(Tok, diag::err_pragma_file_or_compound_scope)
+<< (Kind == tok::annot_pragma_fenv_access ? "STDC FENV_ACCESS"
+: "fenv_access");
 ConsumeAnnotationToken();
 return StmtEmpty();
 
@@ -955,6 +958,7 @@
   HandlePragmaFP();
   break;
 case tok::annot_pragma_fenv_access:
+case tok::annot_pragma_fenv_access_ms:
   HandlePragmaFEnvAccess();
   break;
 case tok::annot_pragma_fenv_round:
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -261,6 +261,68 @@
 Token &FirstToken) override;
 };
 
+// "\#pragma fenv_access (on)".
+struct PragmaMSFenvAccessHandler : public PragmaHandler {
+  PragmaMSFenvAccessHandler() : PragmaHandler("fenv_access") {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducer Introducer,
+Token &FirstToken) override {
+StringRef PragmaName = FirstToken.getIdentifierInfo()->getName();
+if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+  PP.Diag(FirstToken.getLocation(), diag::warn_pragma_fp_ignored)
+  << PragmaName;
+  return;
+}
+
+Token Tok;
+PP.Lex(Tok);
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_expected_lparen)
+  << PragmaName;
+  return;
+}
+PP.Lex(Tok); // Consume the l_paren.
+if (Tok.isNot(tok::identifier)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_ac

[PATCH] D111542: [analyzer] Retrieve VLA extent from its redeclaration.

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

steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1663
 // We can trust a const value or a value of a global initializer in main().
-const VarDecl *VD = VR->getDecl();
+const VarDecl *VD = VR->getDecl()->getMostRecentDecl();
 if (VD->getType().isConstQualified() ||

I think you supposed to use the `getCanonicalDecl()` instead.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1673
+const QualType T = VD->getType();
+if (const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T)) {
+  // Support one-dimensional array.

What does the function return if this branch is not taken?
Shouldn't you handle `IncompleteArrayType` as well?



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1718
 }
   }
 

I would favor not adding another level of indentation xD



Comment at: clang/test/Analysis/initialization.c:101
+
+const int glob_arr3[]; // VLA
+const int glob_arr3[4] = {1, 2, 3};

Why is this a VLA? I thought it's just an `IncompleteArrayType`.
Could you please make sure that this is actually a VLA?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111542

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

[PATCH] D111529: Specify Clang vector builtins.

[Steve Canon via Phabricator via cfe-commits]

scanon added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:538
+ T __builtin_elementwise_rint(T x)  return the integral value nearest to x 
(according to the  floating point types
+prevailing rounding mode) in 
floating-point format
+ T __builtin_elementwise_round(T x) return the integral value nearest to x 
rounding half-way casesfloating point types

"Prevailing rounding mode" is not super-useful, other than as a spelling for 
round-to-nearest-ties-to-even (IEEE 754 default rounding). Outside of a 
`FENV_ACCESS ON` context, there's not even really a notion of "prevailing 
rounding mode" to appeal to. I assume the intent is for this to lower to e.g. 
x86 ROUND* with the dynamic rounding-mode immediate.

I would recommend adding `__builtin_elementwise_roundeven(T x)` instead, which 
would statically bind IEEE default rounding (following TS 18661-1 naming) 
without having to appeal to prevailing rounding mode, and can still lower to 
ROUND* on x86 outside of FENV_ACCESS ON contexts, which is the norm for vector 
code  (and FRINTN unconditionally on armv8). I think we can punt on 
rint/nearbyint for now, and add them in the future if there's a need.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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

[PATCH] D111529: Specify Clang vector builtins.

[Steve Canon via Phabricator via cfe-commits]

scanon added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:565
+ NaNs, fmax() return a NaN.
+ ET __builtin_reduce_add(VT a)   \+
   integer and floating point types
+ ET __builtin_reduce_and(VT a)   & 
   integer types

Should be restricted to integer types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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

[PATCH] D111529: Specify Clang vector builtins.

[Steve Canon via Phabricator via cfe-commits]

scanon added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:565
+ NaNs, fmax() return a NaN.
+ ET __builtin_reduce_add(VT a)   \+
   integer and floating point types
+ ET __builtin_reduce_and(VT a)   & 
   integer types

scanon wrote:
> Should be restricted to integer types.
(Never mind, somehow read this as `&` instead of `\+`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111529

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

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:280
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_access);
+  return;

hans wrote:
> thakis wrote:
> > Is it important that this is a warning?
> > 
> > Independently if we have access to `Parser` here (not sure), there's 
> > `Parser::ExpectAndConsume`.
> > Is it important that this is a warning?
> 
> You mean as opposed to an error? Or as opposed to accepting slightly 
> alternative spellings? I don't think we want to accept any other syntax than 
> MSVC. And the custom seems to be to warn and ignore when we can't parse a 
> pragma so I'm following that pattern.
> 
> > Independently if we have access to Parser here (not sure), there's 
> > Parser::ExpectAndConsume.
> 
> Sadly the PragmaHandler classes don't have access to it. It might be possible 
> to plumb it through, but I'm not sure whether it would be worth it.
> 
> While looking at it, I did switch to more specific diags for the parens 
> though.
Yes, as opposed to an error. If cl.exe errs on this, we should probably err too.


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

https://reviews.llvm.org/D111440

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

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Hans Wennborg via Phabricator via cfe-commits]

hans added inline comments.



Comment at: clang/lib/Parse/ParsePragma.cpp:280
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_access);
+  return;

thakis wrote:
> hans wrote:
> > thakis wrote:
> > > Is it important that this is a warning?
> > > 
> > > Independently if we have access to `Parser` here (not sure), there's 
> > > `Parser::ExpectAndConsume`.
> > > Is it important that this is a warning?
> > 
> > You mean as opposed to an error? Or as opposed to accepting slightly 
> > alternative spellings? I don't think we want to accept any other syntax 
> > than MSVC. And the custom seems to be to warn and ignore when we can't 
> > parse a pragma so I'm following that pattern.
> > 
> > > Independently if we have access to Parser here (not sure), there's 
> > > Parser::ExpectAndConsume.
> > 
> > Sadly the PragmaHandler classes don't have access to it. It might be 
> > possible to plumb it through, but I'm not sure whether it would be worth it.
> > 
> > While looking at it, I did switch to more specific diags for the parens 
> > though.
> Yes, as opposed to an error. If cl.exe errs on this, we should probably err 
> too.
They also just warn: https://godbolt.org/z/P3j5Wc78E


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

https://reviews.llvm.org/D111440

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Shivam Gupta via Phabricator via cfe-commits]

xgupta added a comment.

It misses llvm/test/CodeGen/AArch64 and llvm/test/MC/AArch64 testcases changes, 
see for example https://reviews.llvm.org/D36667 (Cortex-A55 support).


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

https://reviews.llvm.org/D109825

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

[PATCH] D111542: [analyzer] Retrieve VLA extent from its redeclaration.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@steakhal 
Thank you for your comments.




Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1663
 // We can trust a const value or a value of a global initializer in main().
-const VarDecl *VD = VR->getDecl();
+const VarDecl *VD = VR->getDecl()->getMostRecentDecl();
 if (VD->getType().isConstQualified() ||

steakhal wrote:
> I think you supposed to use the `getCanonicalDecl()` instead.
Using `getCanonicalDecl` does not fix the issue. I've checked.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1673
+const QualType T = VD->getType();
+if (const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T)) {
+  // Support one-dimensional array.

steakhal wrote:
> What does the function return if this branch is not taken?
> Shouldn't you handle `IncompleteArrayType` as well?
> What does the function return if this branch is not taken?
In case of a //false// branch it goes down the code to 
`getBindingForFieldOrElementCommon`.
> Shouldn't you handle `IncompleteArrayType` as well?
Only `ConstantArrayType` has `getSize()` method. And `getMostRecentDecl` give 
us an `ConstantArrayType` even if it is declared as `IncompleteArrayType`, but 
`getCanonicalDecl` does not.



Comment at: clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1718
 }
   }
 

steakhal wrote:
> I would favor not adding another level of indentation xD
It annoys me as well. I could use `goto` but I suppose you won't like it even 
more.  :-) 



Comment at: clang/test/Analysis/initialization.c:101
+
+const int glob_arr3[]; // VLA
+const int glob_arr3[4] = {1, 2, 3};

steakhal wrote:
> Why is this a VLA? I thought it's just an `IncompleteArrayType`.
> Could you please make sure that this is actually a VLA?
I mixed up in terminilogy. I'll fix it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111542

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

[clang] 7743882 - [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Hans Wennborg via cfe-commits]

Author: Hans Wennborg
Date: 2021-10-11T17:07:26+02:00
New Revision: 774388241e25529308c8bbac6012a20b62b82f29

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

LOG: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS 
(PR50694)

This adds support for the MSVC spelling of the pragma in -fms-extensions
mode.

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

Added: 
clang/test/Parser/pragma-fenv_access-ms.c

Modified: 
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/TokenKinds.def
clang/include/clang/Parse/Parser.h
clang/lib/Parse/ParsePragma.cpp
clang/lib/Parse/ParseStmt.cpp
clang/lib/Parse/Parser.cpp
clang/test/CodeGen/pragma-fenv_access.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index 8ae264caddcbf..f42c55be63f93 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1116,6 +1116,9 @@ def warn_pragma_expected_integer : Warning<
 def warn_pragma_ms_struct : Warning<
   "incorrect use of '#pragma ms_struct on|off' - ignored">,
   InGroup;
+def warn_pragma_ms_fenv_access : Warning<
+  "incorrect use of '#pragma fenv_access (on|off)' - ignored">,
+  InGroup;
 def warn_pragma_extra_tokens_at_eol : Warning<
   "extra tokens at end of '#pragma %0' - ignored">,
   InGroup;
@@ -1181,9 +1184,6 @@ def ext_stdc_pragma_ignored : ExtWarn<"unknown pragma in 
STDC namespace">,
 // The C standard 7.6.1p2 says "The [FENV_ACCESS] pragma shall occur either
 // outside external declarations or preceding all explicit declarations and
 // statements inside a compound statement.
-def err_pragma_stdc_fenv_access_scope : Error<
-  "'#pragma STDC FENV_ACCESS' can only appear at file scope or at the start of"
-  " a compound statement">;
 def warn_stdc_fenv_round_not_supported :
Warning<"pragma STDC FENV_ROUND is not supported">,
InGroup;

diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 2b3dfedd020c0..0dd5936aa3e66 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -828,10 +828,11 @@ PRAGMA_ANNOTATION(pragma_redefine_extname)
 // handles them.
 PRAGMA_ANNOTATION(pragma_fp_contract)
 
-// Annotation for #pragma STDC FENV_ACCESS
+// Annotations for #pragma STDC FENV_ACCESS and #pragma fenv_access (MS compat)
 // The lexer produces these so that they only take effect when the parser
 // handles them.
 PRAGMA_ANNOTATION(pragma_fenv_access)
+PRAGMA_ANNOTATION(pragma_fenv_access_ms)
 
 // Annotation for #pragma STDC FENV_ROUND
 // The lexer produces these so that they only take effect when the parser

diff  --git a/clang/include/clang/Parse/Parser.h 
b/clang/include/clang/Parse/Parser.h
index de25760017b56..62c0a0d4c0a80 100644
--- a/clang/include/clang/Parse/Parser.h
+++ b/clang/include/clang/Parse/Parser.h
@@ -196,6 +196,7 @@ class Parser : public CodeCompletionHandler {
   std::unique_ptr MSRuntimeChecks;
   std::unique_ptr MSIntrinsic;
   std::unique_ptr MSOptimize;
+  std::unique_ptr MSFenvAccess;
   std::unique_ptr CUDAForceHostDeviceHandler;
   std::unique_ptr OptimizeHandler;
   std::unique_ptr LoopHintHandler;

diff  --git a/clang/lib/Parse/ParsePragma.cpp b/clang/lib/Parse/ParsePragma.cpp
index c33605ef90251..27e8501278626 100644
--- a/clang/lib/Parse/ParsePragma.cpp
+++ b/clang/lib/Parse/ParsePragma.cpp
@@ -261,6 +261,68 @@ struct PragmaMSOptimizeHandler : public PragmaHandler {
 Token &FirstToken) override;
 };
 
+// "\#pragma fenv_access (on)".
+struct PragmaMSFenvAccessHandler : public PragmaHandler {
+  PragmaMSFenvAccessHandler() : PragmaHandler("fenv_access") {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducer Introducer,
+Token &FirstToken) override {
+StringRef PragmaName = FirstToken.getIdentifierInfo()->getName();
+if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+  PP.Diag(FirstToken.getLocation(), diag::warn_pragma_fp_ignored)
+  << PragmaName;
+  return;
+}
+
+Token Tok;
+PP.Lex(Tok);
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_expected_lparen)
+  << PragmaName;
+  return;
+}
+PP.Lex(Tok); // Consume the l_paren.
+if (Tok.isNot(tok::identifier)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_ms_fenv_access);
+  return;
+}
+const IdentifierInfo *II = Tok.getIdentifierInfo();
+tok::OnOffSwitch OOS;
+if (II->isStr("on")) {
+  OOS = tok::OOS_ON;
+  PP.Lex(Tok);
+} else if (II->isStr("off")) {
+  OOS = tok::OOS_OFF;
+  PP.Lex(T

[PATCH] D111440: [MS compat] Handle #pragma fenv_access like #pragma STDC FENV_ACCESS (PR50694)

[Hans Wennborg 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 rG774388241e25: [MS compat] Handle #pragma fenv_access like 
#pragma STDC FENV_ACCESS (PR50694) (authored by hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111440

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/CodeGen/pragma-fenv_access.c
  clang/test/Parser/pragma-fenv_access-ms.c

Index: clang/test/Parser/pragma-fenv_access-ms.c
===
--- /dev/null
+++ clang/test/Parser/pragma-fenv_access-ms.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple i686-pc-win32 -fms-extensions -fsyntax-only -verify %s
+
+#pragma fenv_access (on)
+#pragma fenv_access (off)
+
+#pragma fenv_access // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access foo // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access on // expected-warning{{missing '(' after '#pragma fenv_access'}}
+#pragma fenv_access ( // expected-warning{{incorrect use of '#pragma fenv_access}}
+#pragma fenv_access (on // expected-warning{{missing ')' after '#pragma fenv_access'}}
+#pragma fenv_access (on) foo // expected-warning{{extra tokens at end of '#pragma fenv_access'}}
+
+void f() {
+  (void)0;
+  #pragma fenv_access (on) // expected-error{{'#pragma fenv_access' can only appear at file scope or at the start of a compound statement}}
+}
Index: clang/test/CodeGen/pragma-fenv_access.c
===
--- clang/test/CodeGen/pragma-fenv_access.c
+++ clang/test/CodeGen/pragma-fenv_access.c
@@ -1,6 +1,11 @@
 // RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fexperimental-strict-floating-point -ffp-exception-behavior=strict -triple %itanium_abi_triple -emit-llvm %s -o - -fms-extensions -DMS | FileCheck %s
 
+#ifdef MS
+#pragma fenv_access (on)
+#else
 #pragma STDC FENV_ACCESS ON
+#endif
 
 float func_01(float x, float y) {
   return x + y;
@@ -25,7 +30,11 @@
 // CHECK: call float @llvm.experimental.constrained.fadd.f32(float {{.*}}, float {{.*}}, metadata !"round.dynamic", metadata !"fpexcept.strict")
 
 
+#ifdef MS
+#pragma fenv_access (off)
+#else
 #pragma STDC FENV_ACCESS OFF
+#endif
 
 float func_04(float x, float y) {
   #pragma float_control(except, off)
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -785,6 +785,7 @@
 HandlePragmaFPContract();
 return nullptr;
   case tok::annot_pragma_fenv_access:
+  case tok::annot_pragma_fenv_access_ms:
 HandlePragmaFEnvAccess();
 return nullptr;
   case tok::annot_pragma_fenv_round:
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt.cpp
+++ clang/lib/Parse/ParseStmt.cpp
@@ -374,8 +374,11 @@
 return StmtError();
 
   case tok::annot_pragma_fenv_access:
+  case tok::annot_pragma_fenv_access_ms:
 ProhibitAttributes(Attrs);
-Diag(Tok, diag::err_pragma_stdc_fenv_access_scope);
+Diag(Tok, diag::err_pragma_file_or_compound_scope)
+<< (Kind == tok::annot_pragma_fenv_access ? "STDC FENV_ACCESS"
+: "fenv_access");
 ConsumeAnnotationToken();
 return StmtEmpty();
 
@@ -955,6 +958,7 @@
   HandlePragmaFP();
   break;
 case tok::annot_pragma_fenv_access:
+case tok::annot_pragma_fenv_access_ms:
   HandlePragmaFEnvAccess();
   break;
 case tok::annot_pragma_fenv_round:
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -261,6 +261,68 @@
 Token &FirstToken) override;
 };
 
+// "\#pragma fenv_access (on)".
+struct PragmaMSFenvAccessHandler : public PragmaHandler {
+  PragmaMSFenvAccessHandler() : PragmaHandler("fenv_access") {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducer Introducer,
+Token &FirstToken) override {
+StringRef PragmaName = FirstToken.getIdentifierInfo()->getName();
+if (!PP.getTargetInfo().hasStrictFP() && !PP.getLangOpts().ExpStrictFP) {
+  PP.Diag(FirstToken.getLocation(), diag::warn_pragma_fp_ignored)
+  << PragmaName;
+  return;
+}
+
+Token Tok;
+PP.Lex(Tok);
+if (Tok.isNot(tok::l_paren)) {
+  PP.Diag(Tok.getLocation(), diag::warn_pragma_expected_lparen)
+   

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

>> ! In D108643#3054443 , @rjmccall 
>> wrote:
>>
>>> ! In D108643#3027473 , 
>>> @erichkeane wrote:
>>>
 ! In D108643#3026550 , @rjmccall 
 wrote:
>>>
>>> I think it would be better to provide a generic ABI specification that is 
>>> designed to "lower" `_BitInt` types into more basic concepts that ABIs 
>>> typically already have rules for.  It would be appropriate to note at the 
>>> top that this is only a generic specification and that the rules for any 
>>> particular platform should be codified in a platform-specific ABI.  But we 
>>> should make that easy so that platform owners who don't have strong 
>>> opinions about the ABI can just say "as described in version 1.4 of the 
>>> generic ABI at https://clang.llvm.org/...";
>>>
>>> Now, that is all independent of what we actually decide the ABI should be.  
>>> But I do think that if we're going to make this available on all targets, 
>>> we should strongly consider doing a "legalizing" lowering in the frontend: 
>>> at ABI-exposed points (call arguments/parameters and memory accesses), 
>>> `_BitInt` types should be translated into types that a naive backend can be 
>>> trusted to handle in a way that matches the documented ABI.  Individual 
>>> targets can then opt in to using the natural lowerings if they promise to 
>>> match the ABI, but that becomes a decision that they make to enable better 
>>> optimization and code generation, not something that's necessary for 
>>> correctness.
>>
>> Don't we already have that?  We work the same way a 'bool' does, that is, we 
>> zero/sign extend for parameters and return values?  The backends then 
>> reliably up-scale these to the power-of-two/multiple-of-pointer.
>
> There's two levels of a "legalizing" lowering.
>
> On the specification level, we'd be formally saying that the ABI matches the 
> ABI of some other C construct.  For example, we might say that a `signed 
> _BitInt(14)` argument is treated exactly as if the argument type was instead 
> `signed short` (with whatever restriction we do or do not impose on the 
> range).  This is very nice on this level because, first, it's a rule that 
> works generically for all targets without needing to care about the details 
> of how arguments are assigned to registers or stack slots or whatever; and 
> second, it means you're never adding new cases to the ABI that e.g. libffi 
> would need to care about; and third, you can reliably match the ABI with 
> manually-lowered C code from a compiler that doesn't even support `_BitInt`s.
>
> On the implementation level, we'd have to actually emit IR which will turn 
> into code which matches that ABI.  I think you are right that small integers 
> already reliably work that way in LLVM, so that if you pass an `i11 sext` 
> it'll get sign-extended to some width — what width exactly, I don't know, but 
> probably the same width that `i16 sext` would be.  Larger integers, I'm not 
> sure.  A legalizing lowering of big `_BitInt` argument would presumably say 
> either that it's exactly the same as a struct containing all the chunks or 
> that it's exactly the same as a series of arguments for each of the chunks.  
> Those are two very different rules!  Most ABIs won't "straddle" a single 
> argument between registers and the stack, so e.g. if you'd need two registers 
> and you only have one left then you exhaust the registers and go fully on the 
> stack; but obviously you can get straddling if the lowering expands the 
> sequence.  Similarly, some ABIs will go indirect if the struct gets big 
> enough, but you won't get that if the lowering expands.  But on the other 
> hand, if the rule is really that it's like a struct, well, some ABIs don't 
> pass small structs in registers.  Anyway, my point is that what exactly LLVM 
> targets do if you give them an `i117` might not match either of these 
> possibilities reliably across targets.  In any case, since we currently have 
> to count registers in the frontend for the register-passing ABIs, we'll need 
> to actually know what the targets do.

Hmm... now that I think I understand the concern, I'm not sure we're able to 
take on this level of commitment. The Clang ABI code is a bit of a mess in 
general, plus each target has its own code, right (In CodeGen/TargetInfo.cpp)?  
Additionally, that would require breaking the Microsoft ABI again, and I 
thought we'd discussed trying not to make changes until Microsoft defined that 
ABI, right?

I would like us to be able to find a way forward, and hope you can help make a 
suggestion on how to do so.  We'd love to get Clang to support this C23 feature 
at least on some targets as there are a good amount of users of this feature 
already as `_ExtInt`, and we would really want to get them to the standards 
version ASAP.  Do you have any suggestions on how we can mo

[PATCH] D111542: [analyzer] Retrieve incomplete array extent from its redeclaration.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 378684.
ASDenysPetrov retitled this revision from "[analyzer] Retrieve VLA extent from 
its redeclaration." to "[analyzer] Retrieve incomplete array extent from its 
redeclaration.".
ASDenysPetrov edited the summary of this revision.

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

https://reviews.llvm.org/D111542

Files:
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/test/Analysis/initialization.c

Index: clang/test/Analysis/initialization.c
===
--- clang/test/Analysis/initialization.c
+++ clang/test/Analysis/initialization.c
@@ -97,3 +97,22 @@
   // FIXME: Should warn {{garbage or undefined}}.
   int res = glob_arr2[x][y]; // no-warning
 }
+
+const int glob_arr3[];  // Incomplete array declaration
+const int glob_arr3[4] = {1, 2, 3}; // Incomplete Array redeclaration
+void foo() {
+  clang_analyzer_eval(glob_arr3[0] == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[1] == 2); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[2] == 3); // expected-warning{{TRUE}}
+  clang_analyzer_eval(glob_arr3[3] == 0); // expected-warning{{TRUE}}
+}
+
+void glob_invalid_index5() {
+  int x = 42;
+  int res = glob_arr3[x]; // expected-warning{{garbage or undefined}}
+}
+
+void glob_invalid_index6() {
+  int x = -42;
+  int res = glob_arr3[x]; // expected-warning{{garbage or undefined}}
+}
Index: clang/lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- clang/lib/StaticAnalyzer/Core/RegionStore.cpp
+++ clang/lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -1660,7 +1660,7 @@
   } else if (const VarRegion *VR = dyn_cast(superR)) {
 // Check if the containing array has an initialized value that we can trust.
 // We can trust a const value or a value of a global initializer in main().
-const VarDecl *VD = VR->getDecl();
+const VarDecl *VD = VR->getDecl()->getMostRecentDecl();
 if (VD->getType().isConstQualified() ||
 R->getElementType().isConstQualified() ||
 (B.isMainAnalysis() && VD->hasGlobalStorage())) {
@@ -1668,49 +1668,48 @@
 if (const auto *InitList = dyn_cast(Init)) {
   // The array index has to be known.
   if (auto CI = R->getIndex().getAs()) {
-// If it is not an array, return Undef.
-QualType T = VD->getType();
-const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T);
-if (!CAT)
-  return UndefinedVal();
-
-// Support one-dimensional array.
-// C++20 [expr.add] 7.6.6.4 (excerpt):
-//   If P points to an array element i of an array object x with n
-//   elements, where i < 0 or i > n, the behavior is undefined.
-//   Dereferencing is not allowed on the "one past the last
-//   element", when i == n.
-// Example:
-//   const int arr[4] = {1, 2};
-//   const int *ptr = arr;
-//   int x0 = ptr[0]; // 1
-//   int x1 = ptr[1]; // 2
-//   int x2 = ptr[2]; // 0
-//   int x3 = ptr[3]; // 0
-//   int x4 = ptr[4]; // UB
-// TODO: Support multidimensional array.
-if (!isa(CAT->getElementType())) {
-  // One-dimensional array.
-  const llvm::APSInt &Idx = CI->getValue();
-  const auto I = static_cast(Idx.getExtValue());
-  // Use `getZExtValue` because array extent can not be negative.
-  const uint64_t Extent = CAT->getSize().getZExtValue();
-  // Check for `Idx < 0`, NOT for `I < 0`, because `Idx` CAN be
-  // negative, but `I` can NOT.
-  if (Idx < 0 || I >= Extent)
-return UndefinedVal();
-
-  // C++20 [expr.add] 9.4.17.5 (excerpt):
-  //   i-th array element is value-initialized for each k < i ≤ n,
-  //   where k is an expression-list size and n is an array extent.
-  if (I >= InitList->getNumInits())
-return svalBuilder.makeZeroVal(R->getElementType());
-
-  // Return a constant value, if it is presented.
-  // FIXME: Support other SVals.
-  const Expr *E = InitList->getInit(I);
-  if (Optional V = svalBuilder.getConstantVal(E))
-return *V;
+// We treat only ConstantArrayType.
+const QualType T = VD->getType();
+if (const ConstantArrayType *CAT = Ctx.getAsConstantArrayType(T)) {
+  // Support one-dimensional array.
+  // C++20 [expr.add] 7.6.6.4 (excerpt):
+  //   If P points to an array element i of an array object x with n
+  //   elements, where i < 0 or i > n, the behavior is undefined.
+  //   Dereferencing is not allowed on the "one past the 

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Sam Elliott via Phabricator via cfe-commits]

lenary added a comment.

In D109825#3055142 , @xgupta wrote:

> It misses llvm/test/CodeGen/AArch64 and llvm/test/MC/AArch64 testcases 
> changes, see for example https://reviews.llvm.org/D36667 (Cortex-A55 support).

I'm not convinced this is required - those tests are to ensure that the 
extensions (rcpc, dotprod) can be enabled either from a `-march`, or from a 
`-mcpu=` with a cpu that contains that extension -- they are not testing 
that the extension is enabled from *all* cpus that contain said extension.


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

https://reviews.llvm.org/D109825

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Shivam Gupta via Phabricator via cfe-commits]

xgupta added a comment.

oh thanks for the clarification, I am not aware of it.


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

https://reviews.llvm.org/D109825

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

[PATCH] D111457: [clang][test] Add lit helper for windows paths

[Richard Howell via Phabricator via cfe-commits]

rmaz added inline comments.



Comment at: clang/test/lit.cfg.py:60
+if platform.system() == 'Windows':
+root_sep = 'C:\\'
+else:

keith wrote:
> rmaz wrote:
> > `c:\`?
> Do you mean lowercase or a single slash? I see ~2x the number of uppercase vs 
> lowercase in this codebase now, and the second is just because of escaping
I meant the single slash, yes, wasn't sure if it needed to be escaped or not


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111457

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

[PATCH] D109825: [AArch64]Enabling Cortex-A510 Support

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

Thanks for the updates.

In D109825#3055264 , @lenary wrote:

> In D109825#3055142 , @xgupta wrote:
>
>> It misses llvm/test/CodeGen/AArch64 and llvm/test/MC/AArch64 testcases 
>> changes, see for example https://reviews.llvm.org/D36667 (Cortex-A55 
>> support).
>
> I'm not convinced this is required - those tests are to ensure that the 
> extensions (rcpc, dotprod) can be enabled either from a `-march`, or from a 
> `-mcpu=` with a cpu that contains that extension -- they are not testing 
> that the extension is enabled from *all* cpus that contain said extension.

Yeah I agree. It would be useful to add some tests for -mcpu=cortex-a510+crypto 
and -mcpu=cortex-a510+nocrypto, to make sure they do what is expected.




Comment at: clang/docs/ReleaseNotes.rst:86
 
+- Support has been added for the following processors (command-line 
identifiers in parentheses):
+  - Arm Cortex-A510 (cortex-a510)

Can you add an Arm section below and move this to it.


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

https://reviews.llvm.org/D109825

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

[PATCH] D111557: [clang][modules] NFC: Propagate import `SourceLocation` into `HeaderSearch::lookupModule`

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch propagates the import `SourceLocation` into 
`HeaderSearch::lookupModule`. This enables remarks on search path usage 
(implemented in D102923 ) to point to the 
source code that initiated header search.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111557

Files:
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/GeneratePCH.cpp

Index: clang/lib/Serialization/GeneratePCH.cpp
===
--- clang/lib/Serialization/GeneratePCH.cpp
+++ clang/lib/Serialization/GeneratePCH.cpp
@@ -50,7 +50,8 @@
   Module *Module = nullptr;
   if (PP.getLangOpts().isCompilingModule()) {
 Module = PP.getHeaderSearchInfo().lookupModule(
-PP.getLangOpts().CurrentModule, /*AllowSearch*/ false);
+PP.getLangOpts().CurrentModule, SourceLocation(),
+/*AllowSearch*/ false);
 if (!Module) {
   assert(hasErrors && "emitting module but current module doesn't exist");
   return;
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -556,7 +556,8 @@
   StringRef ModuleName = TopImport->ModuleName;
   assert(!ModuleName.empty() && "diagnostic options read before module name");
 
-  Module *M = PP.getHeaderSearchInfo().lookupModule(ModuleName);
+  Module *M =
+  PP.getHeaderSearchInfo().lookupModule(ModuleName, TopImport->ImportLoc);
   assert(M && "missing module");
   return M;
 }
@@ -2923,7 +2924,7 @@
   // If we've already loaded a module map file covering this module, we may
   // have a better path for it (relative to the current build).
   Module *M = PP.getHeaderSearchInfo().lookupModule(
-  F.ModuleName, /*AllowSearch*/ true,
+  F.ModuleName, F.ImportLoc, /*AllowSearch*/ true,
   /*AllowExtraModuleMapSearch*/ true);
   if (M && M->Directory) {
 // If we're implicitly loading a module, the base directory can't
@@ -3909,7 +3910,8 @@
   if (F.Kind == MK_ImplicitModule && ModuleMgr.begin()->Kind != MK_MainFile) {
 // An implicitly-loaded module file should have its module listed in some
 // module map file that we've already loaded.
-Module *M = PP.getHeaderSearchInfo().lookupModule(F.ModuleName);
+Module *M =
+PP.getHeaderSearchInfo().lookupModule(F.ModuleName, F.ImportLoc);
 auto &Map = PP.getHeaderSearchInfo().getModuleMap();
 const FileEntry *ModMap = M ? Map.getModuleMapFileForUniquing(M) : nullptr;
 // Don't emit module relocation error if we have -fno-validate-pch
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -518,7 +518,8 @@
   if (!getLangOpts().isCompilingModule())
 return nullptr;
 
-  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule);
+  return getHeaderSearchInfo().lookupModule(getLangOpts().CurrentModule,
+SourceLocation());
 }
 
 //===--===//
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -1752,7 +1752,7 @@
 // Find the module we're entering. We require that a module map for it
 // be loaded or implicitly loadable.
 auto &HSI = PP.getHeaderSearchInfo();
-Module *M = HSI.lookupModule(Current);
+Module *M = HSI.lookupModule(Current, ModuleName.front().second);
 if (!M) {
   PP.Diag(ModuleName.front().second,
   diag::err_pp_module_begin_no_module_map) << Current;
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -745,7 +745,7 @@
   // to the current module, if there is one.
   return getLangOpts().CurrentModule.empty()
  ? nullptr
- : HeaderInfo.lookupModule(getLangOpts().CurrentModule);
+ : HeaderInfo.lookupModule(getLangOpts().CurrentModule, Loc);
 }
 
 const FileEntry *
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -229,7 +229,8 @@
   return Result.str().str();

[PATCH] D102923: [clang][lex] Remark on search path usage

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 378702.
jansvoboda11 added a comment.

Add `SourceLocation` to remarks and test with `-verify`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102923

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Lex/HeaderSearch.cpp
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Headers/FrameworkA.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwA/FrameworkA.framework/Modules/module.modulemap
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Headers/FrameworkB.h
  
clang/test/Preprocessor/Inputs/search-path-usage/FwB/FrameworkB.framework/Modules/module.modulemap
  clang/test/Preprocessor/Inputs/search-path-usage/a/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/a_next/a.h
  clang/test/Preprocessor/Inputs/search-path-usage/b.hmap.json.template
  clang/test/Preprocessor/Inputs/search-path-usage/b/b.h
  clang/test/Preprocessor/Inputs/search-path-usage/d/d.h
  
clang/test/Preprocessor/Inputs/search-path-usage/modulemap_abs/module.modulemap.template
  clang/test/Preprocessor/search-path-usage-headers.m

Index: clang/test/Preprocessor/search-path-usage-headers.m
===
--- /dev/null
+++ clang/test/Preprocessor/search-path-usage-headers.m
@@ -0,0 +1,106 @@
+// RUN: rm -rf %t && mkdir %t
+
+// Check that search paths used by `#include` and `#include_next` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage   \
+// RUN:   -I%S/Inputs/search-path-usage/a  \
+// RUN:   -I%S/Inputs/search-path-usage/a_next \
+// RUN:   -I%S/Inputs/search-path-usage/b  \
+// RUN:   -I%S/Inputs/search-path-usage/c  \
+// RUN:   -I%S/Inputs/search-path-usage/d  \
+// RUN:   -DINCLUDE -verify
+#ifdef INCLUDE
+#include "a.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/a'}} \
+// expected-remark-re@#a-include-next {{search path used: '{{.*}}/search-path-usage/a_next'}}
+#include "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that framework search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -F%S/Inputs/search-path-usage/FwA  \
+// RUN:   -F%S/Inputs/search-path-usage/FwB  \
+// RUN:   -DFRAMEWORK -verify
+#ifdef FRAMEWORK
+#include "FrameworkA/FrameworkA.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/FwA'}}
+#endif
+
+// Check that system search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isystem %S/Inputs/search-path-usage/b \
+// RUN:   -isystem %S/Inputs/search-path-usage/d \
+// RUN:   -DSYSTEM -verify
+#ifdef SYSTEM
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+
+// Check that sysroot-based search paths are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -isysroot %S/Inputs/search-path-usage  \
+// RUN:   -iwithsysroot /b   \
+// RUN:   -iwithsysroot /d   \
+// RUN:   -DSYSROOT -verify
+#ifdef SYSROOT
+#include "d.h" // \
+// expected-remark {{search path used: '/d'}}
+#endif
+
+// Check that search paths used by `__has_include()` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DHAS_INCLUDE -verify
+#ifdef HAS_INCLUDE
+#if __has_include("b.h") // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/b'}}
+#endif
+#if __has_include("x.h")
+#endif
+#endif
+
+// Check that search paths used by `#import` are reported.
+//
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I%S/Inputs/search-path-usage/b\
+// RUN:   -I%S/Inputs/search-path-usage/d\
+// RUN:   -DIMPORT -verify
+#ifdef IMPORT
+#import "d.h" // \
+// expected-remark-re {{search path used: '{{.*}}/search-path-usage/d'}}
+#endif
+
+// Check that header maps are reported.
+//
+// RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g" %S/Inputs/search-path-usage/b.hmap.json.template > %t/b.hmap.json
+// RUN: %hmaptool write %t/b.hmap.json %t/b.hmap
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I %t/b.hmap   \
+// RUN:   -I b   \
+// RUN:   -DHMAP -verify
+#ifdef HMAP
+#include "b.h" // \
+// expected-remark-re {{search path used: '{{.*}}/b.hmap'}}
+#endif
+
+// Check that search paths with module maps are reported.
+//
+// RUN: mkdir %t/modulemap_abs
+// RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g"\
+// RUN:   %S/Inputs/search-pa

[PATCH] D111542: [analyzer] Retrieve incomplete array extent from its redeclaration.

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

balazske added inline comments.



Comment at: clang/test/Analysis/initialization.c:102
+const int glob_arr3[];  // Incomplete array declaration
+const int glob_arr3[4] = {1, 2, 3}; // Incomplete Array redeclaration
+void foo() {

It is possible to add a line `const int glob_arr3[];` again and then it may not 
work?


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

https://reviews.llvm.org/D111542

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

[PATCH] D108643: Introduce _BitInt, deprecate _ExtInt

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman marked 4 inline comments as done.
aaron.ballman added inline comments.



Comment at: clang/docs/BitIntABI.rst:17
+This is only intended as a generic specification. The actual details for any
+particular platform should be codified in that platform's ABI specification.
+

rjmccall wrote:
> I think you should recommend that ABIs codify that by reference to your 
> specification.  Perhaps:
> 
> > This document provides a generic ABI specification for the C23 `_BitInt` 
> > feature, expressed in terms of concepts common to low-level platform ABIs.  
> > This document does not directly constrain any platform, as the ABI used for 
> > `_BitInt` on a platform is determined by that platform's ABI specification. 
> >  It is expected that platform ABIs will codify the ABI for the `_BitInt` 
> > feature on their platform using this specification, either by reference or 
> > by copying the text of this specification into the platform ABI 
> > specification.
> 
> Now, I am assuming that this specification will be complex enough that ABI 
> maintainers won't want to just copy into their specifications.  Maybe I'm 
> wrong about that, but I think it will be fairly long by the time it's 
> finished — not, like, Itanium C++ ABI long, but it might be 3-4 pages.  If we 
> want to support including this by reference, we need to think about what that 
> reference looks like.  I think there are two key parts of that: first, it 
> should explicitly name a version of this document, and second, it should give 
>  the parameters that we've listed out below.  Basically, someone should be 
> able to see that and have no doubt about what the ABI is.
> 
> I would suggest this recommended reference:
> 
> > Platform ABIs which include this specification by reference should 
> > explicitly give a version and the parameters listed below.  For example: 
> > "The ABI for `_BitInt` types is specified by version 1 of the specification 
> > found at https://clang.llvm.org/docs/BitIntABI.html, using 64 as the 
> > maximum fundamental width and `long` as the chunk  type."
> 
> To make versioning work, the version history should (1) explicitly say what 
> version this is and (2) be limited to major semantic versions, where you 
> actually change the intended ABI rather than just making editorial changes.  
> (If you never need to do that, great, but you should set up to make it 
> possible.)
Thanks, these are good suggestions; I've applied them.



Comment at: clang/docs/BitIntABI.rst:42
+``sizeof(Array) / sizeof(__BitInt(N))`` must have the usual semantics for
+determining the number of elements in an array.
+

rjmccall wrote:
> On first read, I thought this paragraph was telling me that `sizeof` behaves 
> differently for `_BitInt` objects.  On second read, I think you're trying to 
> tell me that it *doesn't* behave differently and that arrays of `_BitInt` 
> might contain padding between elements.  However, that's true of all objects 
> of `_BitInt` that aren't bit-fields, so I think this paragraph is a little 
> misleading.
> 
> Perhaps:
> 
> > `_BitInt` types are ordinary object types and may be used anywhere an 
> > object type can be, such as a struct field, union field, or array element.  
> > In addition, they are integer types and may be used as the type of a 
> > bit-field.  Like any other type, a `_BitInt` object may require more memory 
> > than its stated bit width in order to satisfy the requirements of byte (or 
> > higher) alignment.  In other words, the width of a `_BitInt` affects the 
> > semantics of operations on the value; it is not a guarantee that the value 
> > will be "packed" into exactly that many bits in memory.
You're correct -- thanks, your new words are far more clear than my old ones.



Comment at: clang/docs/BitIntABI.rst:71
+the original width. e.g., a ``signed _BitField(7)`` whose representation width
+is ``8`` bits cannot store values less than ``-64`` or greater than ``63``.
+

rjmccall wrote:
> Oh, is sign/zero extension the ABI you want to recommend?  I wasn't trying to 
> lead you in either direction on this point; I just wanted to make sure this 
> was thought through.
> 
> There should be a non-normative rationale / alternatives considered section 
> at the end that makes an argument for the ABI's recommendations here.
> Oh, is sign/zero extension the ABI you want to recommend? I wasn't trying to 
> lead you in either direction on this point; I just wanted to make sure this 
> was thought through.

We're still nailing this bit down. I personally do not care what the answer is, 
and I have no idea how we would ever measure to determine what the "right" 
answer is because. My understanding of the usage pattern for this type is 
people expect to use it similar to `int`, so it'll be used for basically all of 
the operations roughly equally. Based on that, I don't think there is a right 
answer. So

[clang] 3550e24 - [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

[Victor Campos via cfe-commits]

Author: Victor Campos
Date: 2021-10-11T17:44:09+01:00
New Revision: 3550e242fad672696da361f7ddadf53a41114dfd

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

LOG: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

armv9-a, armv9.1-a and armv9.2-a can be targeted using the -march option
both in ARM and AArch64.

 - Armv9-A maps to Armv8.5-A.
 - Armv9.1-A maps to Armv8.6-A.
 - Armv9.2-A maps to Armv8.7-A.
 - The SVE2 extension is enabled by default on these architectures.
 - The cryptographic extensions are disabled by default on these
 architectures.

The Armv9-A architecture is described in the Arm® Architecture Reference
Manual Supplement Armv9, for Armv9-A architecture profile
(https://developer.arm.com/documentation/ddi0608/latest).

Reviewed By: SjoerdMeijer

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

Added: 


Modified: 
clang/lib/Basic/Targets/AArch64.cpp
clang/lib/Basic/Targets/AArch64.h
clang/lib/Basic/Targets/ARM.cpp
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/aarch64-cpus.c
clang/test/Driver/arm-cortex-cpus.c
clang/test/Preprocessor/aarch64-target-features.c
clang/test/Preprocessor/arm-target-features.c
llvm/include/llvm/ADT/Triple.h
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/include/llvm/Support/ARMTargetParser.def
llvm/lib/Support/AArch64TargetParser.cpp
llvm/lib/Support/ARMTargetParser.cpp
llvm/lib/Support/Triple.cpp
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/AArch64/AArch64Subtarget.h
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
llvm/lib/Target/ARM/ARM.td
llvm/lib/Target/ARM/ARMSubtarget.h
llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
llvm/test/MC/AArch64/SME/directives-negative.s
llvm/test/MC/AArch64/SME/directives.s
llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
llvm/test/MC/AArch64/SVE2/directive-arch.s
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/AArch64.cpp 
b/clang/lib/Basic/Targets/AArch64.cpp
index 2b5bf34a7b23f..c11608d9b06a8 100644
--- a/clang/lib/Basic/Targets/AArch64.cpp
+++ b/clang/lib/Basic/Targets/AArch64.cpp
@@ -40,6 +40,17 @@ const Builtin::Info AArch64TargetInfo::BuiltinInfo[] = {
 #include "clang/Basic/BuiltinsAArch64.def"
 };
 
+static StringRef getArchVersionString(llvm::AArch64::ArchKind Kind) {
+  switch (Kind) {
+  case llvm::AArch64::ArchKind::ARMV9A:
+  case llvm::AArch64::ArchKind::ARMV9_1A:
+  case llvm::AArch64::ArchKind::ARMV9_2A:
+return "9";
+  default:
+return "8";
+  }
+}
+
 AArch64TargetInfo::AArch64TargetInfo(const llvm::Triple &Triple,
  const TargetOptions &Opts)
 : TargetInfo(Triple), ABI("aapcs") {
@@ -203,6 +214,24 @@ void AArch64TargetInfo::getTargetDefinesARMV87A(const 
LangOptions &Opts,
   getTargetDefinesARMV86A(Opts, Builder);
 }
 
+void AArch64TargetInfo::getTargetDefinesARMV9A(const LangOptions &Opts,
+   MacroBuilder &Builder) const {
+  // Armv9-A maps to Armv8.5-A
+  getTargetDefinesARMV85A(Opts, Builder);
+}
+
+void AArch64TargetInfo::getTargetDefinesARMV91A(const LangOptions &Opts,
+MacroBuilder &Builder) const {
+  // Armv9.1-A maps to Armv8.6-A
+  getTargetDefinesARMV86A(Opts, Builder);
+}
+
+void AArch64TargetInfo::getTargetDefinesARMV92A(const LangOptions &Opts,
+MacroBuilder &Builder) const {
+  // Armv9.2-A maps to Armv8.7-A
+  getTargetDefinesARMV87A(Opts, Builder);
+}
+
 void AArch64TargetInfo::getTargetDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
   // Target identification.
@@ -227,7 +256,7 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
 
   // ACLE predefines. Many can only have one possible value on v8 AArch64.
   Builder.defineMacro("__ARM_ACLE", "200");
-  Builder.defineMacro("__ARM_ARCH", "8");
+  Builder.defineMacro("__ARM_ARCH", getArchVersionString(ArchKind));
   Builder.defineMacro("__ARM_ARCH_PROFILE", "'A'");
 
   Builder.defineMacro("__ARM_64BIT_STATE", "1");
@@ -405,6 +434,15 @@ void AArch64TargetInfo::getTargetDefines(const LangOptions 
&Opts,
   case llvm::AArch64::ArchKind::ARMV8_7A:
 getTargetDefinesARMV87A(Opts, Builder);
 break;
+  case llvm::AArch64::ArchKind::ARMV9A:
+getTargetDefinesARMV9A(Opts, Builder);
+break;
+  case llvm::AArch64::ArchKind::ARMV9_1A:
+getTargetDefinesARMV91A(Opts, Builder);
+break;
+  case llvm::AArch64::ArchKind::ARMV9_2A:
+getTargetDefinesARMV92A(Opts, Builder);
+break;
 

[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

[Victor Campos 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 rG3550e242fad6: [Clang][ARM][AArch64] Add support for Armv9-A, 
Armv9.1-A and Armv9.2-A (authored by vhscampos).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109517

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-cortex-cpus.c
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm-target-features.c
  llvm/include/llvm/ADT/Triple.h
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/lib/Support/ARMTargetParser.cpp
  llvm/lib/Support/Triple.cpp
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
  llvm/test/MC/AArch64/SME/directives-negative.s
  llvm/test/MC/AArch64/SME/directives.s
  llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
  llvm/test/MC/AArch64/SVE2/directive-arch.s
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -31,6 +31,8 @@
 "armv8.5a","armv8.6-a","armv8.6a","armv8.7-a","armv8.7a",
 "armv8-r", "armv8r",   "armv8-m.base","armv8m.base",  "armv8-m.main",
 "armv8m.main", "iwmmxt",   "iwmmxt2", "xscale",   "armv8.1-m.main",
+"armv9-a", "armv9","armv9a",  "armv9.1-a","armv9.1a",
+"armv9.2-a",   "armv9.2a",
 };
 
 template 
@@ -492,6 +494,15 @@
   EXPECT_TRUE(
   testARMArch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(
+  testARMArch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(
   testARMArch("armv8-r", "cortex-r52", "v8r",
   ARMBuildAttrs::CPUArch::v8_R));
@@ -821,6 +832,9 @@
 case ARM::ArchKind::ARMV8_5A:
 case ARM::ArchKind::ARMV8_6A:
 case ARM::ArchKind::ARMV8_7A:
+case ARM::ArchKind::ARMV9A:
+case ARM::ArchKind::ARMV9_1A:
+case ARM::ArchKind::ARMV9_2A:
   EXPECT_EQ(ARM::ProfileKind::A, ARM::parseArchProfile(ARMArch[i]));
   break;
 default:
@@ -1204,6 +1218,12 @@
   ARMBuildAttrs::CPUArch::v8_A));
   EXPECT_TRUE(testAArch64Arch("armv8.7-a", "generic", "v8.7a",
   ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9-a", "generic", "v9a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.1-a", "generic", "v9.1a",
+  ARMBuildAttrs::CPUArch::v8_A));
+  EXPECT_TRUE(testAArch64Arch("armv9.2-a", "generic", "v9.2a",
+  ARMBuildAttrs::CPUArch::v8_A));
 }
 
 bool testAArch64Extension(StringRef CPUName, AArch64::ArchKind AK,
Index: llvm/test/MC/AArch64/SVE2/directive-arch.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch.s
@@ -1,21 +1,21 @@
 // RUN: llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
+.arch armv9-a+sve2
 tbx z0.b, z1.b, z2.b
 // CHECK: tbx z0.b, z1.b, z2.b
 
-.arch armv8-a+sve2-aes
+.arch armv9-a+sve2-aes
 aesd z23.b, z23.b, z13.b
 // CHECK: aesd z23.b, z23.b, z13.b
 
-.arch armv8-a+sve2-sm4
+.arch armv9-a+sve2-sm4
 sm4e z0.s, z0.s, z0.s
 // CHECK: sm4e z0.s, z0.s, z0.s
 
-.arch armv8-a+sve2-sha3
+.arch armv9-a+sve2-sha3
 rax1 z0.d, z0.d, z0.d
 // CHECK: rax1 z0.d, z0.d, z0.d
 
-.arch armv8-a+sve2-bitperm
+.arch armv9-a+sve2-bitperm
 bgrp z21.s, z10.s, z21.s
 // CHECK: bgrp z21.s, z10.s, z21.s
Index: llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
===
--- llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
+++ llvm/test/MC/AArch64/SVE2/directive-arch-negative.s
@@ -1,31 +1,31 @@
 // RUN: not llvm-mc -triple aarch64 -filetype asm -o - %s 2>&1 | FileCheck %s
 
-.arch armv8-a+sve2
-.arch armv8-a+nosve2

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

[Dave Green via Phabricator via cfe-commits]

dmgreen added a comment.

If D111551  was folded into this patch, would 
it be possible to add tests for -tune-cpu enabling/disabling features at the 
correct times?




Comment at: clang/test/Driver/aarch64-mtune.c:3
+
+// There shouldn't be a default -mtune.
+// RUN: %clang -target aarch64-unknown-unknown -c -### %s 2>&1 \

Why do we not want to add a default tune-cpu?



Comment at: clang/test/Driver/aarch64-mtune.c:34
+
+// RUN: %clang -target aarch64-unknown-unknown -c -### %s -mcpu=thunderx 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=mcputhunderx

My understanding is that -mcpu=cpu is the same as -march=something + 
-mtune=cpu. Why would this case not add a -tune-cpu too? Is it because that 
gets handled in llvm?


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

https://reviews.llvm.org/D110258

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

[clang] a5c3508 - [RISCV] Require tail policy argument to builtins to be an integer constant expression

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-10-11T09:55:04-07:00
New Revision: a5c3508ac71bf30a6d2da35f438e90cc153d8d84

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

LOG: [RISCV] Require tail policy argument to builtins to be an integer constant 
expression

The IR intrinsics use ImmArg for the policy operand so this needs to be 
enforced as a constant in the frontend.

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

Added: 


Modified: 
clang/utils/TableGen/RISCVVEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/RISCVVEmitter.cpp 
b/clang/utils/TableGen/RISCVVEmitter.cpp
index 152500610a293..f71df8b3063a3 100644
--- a/clang/utils/TableGen/RISCVVEmitter.cpp
+++ b/clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1184,7 +1184,7 @@ void RVVEmitter::createRVVIntrinsics(
 }
 
 if (HasPolicy) {
-  ProtoMaskSeq.push_back("z");
+  ProtoMaskSeq.push_back("Kz");
 }
 
 // Create Intrinsics for each type and LMUL.



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

[PATCH] D110779: [RISCV] Require tail policy argument to builtins to be an integer constant expression

[Craig Topper 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 rGa5c3508ac71b: [RISCV] Require tail policy argument to 
builtins to be an integer constant… (authored by craig.topper).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110779

Files:
  clang/utils/TableGen/RISCVVEmitter.cpp


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1184,7 +1184,7 @@
 }
 
 if (HasPolicy) {
-  ProtoMaskSeq.push_back("z");
+  ProtoMaskSeq.push_back("Kz");
 }
 
 // Create Intrinsics for each type and LMUL.


Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1184,7 +1184,7 @@
 }
 
 if (HasPolicy) {
-  ProtoMaskSeq.push_back("z");
+  ProtoMaskSeq.push_back("Kz");
 }
 
 // Create Intrinsics for each type and LMUL.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111228: [clang-tidy] Add options to bugprone-unused-return-value.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D111228#3054263 , @balazske wrote:

> I think a configuration option that depends on configuration of another check 
> causes too many problems. It causes dependencies between checks, possible 
> circular dependency (that is an error). What if the other check is not 
> enabled (if a check configuration depends on other it may mean that these two 
> belong together and should both be enabled, or not)? It becomes less clear 
> from where a value comes.

Okay, that make sense to me, thanks!

> A probably better way: Define configuration values like "variables" that can 
> be used at any check, probably with manipulation of the original value. But 
> not reuse configuration of another check.

That might make more sense. Are we agreed that it would be better to solve the 
larger issue instead of just for this check?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111228

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

[PATCH] D111443: [Driver] Fix ToolChain::getSanitizerArgs

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

Don't we want to diagnose the problems in the job's command line? What kind of 
changes can the driver do there that would affect SanitizerArgs?

I wonder if diagnostics should still be performed on the job args, but 
presented to the user differently, mainly because we can no longer refer to the 
user-provided command line?


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

https://reviews.llvm.org/D111443

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

[PATCH] D111109: AddGlobalAnnotations for function with or without function body.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D09

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

[PATCH] D110127: [Clang] Support typedef with btf_tag attributes

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added a comment.

@aaron.ballman ping. To address your concerns, I intend to create another type 
attribute btf_type_tag (https://reviews.llvm.org/D99), could you comment on 
this new approach?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110127

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

[PATCH] D111521: [DebugInfo] Mark OpenMP generated functions as artificial

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Might not hurt to have some negative test cases too - like something that is a 
VarDecl but has NoStub DynamicInitKind?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111521

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

[PATCH] D111560: [clang][modules] Cache loads of explicit modules imported by PCH

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, rsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

During modular build, PCM files are typically specified via the 
`-fmodule-file=` command-line option. Early during the compilation, Clang 
uses the `ASTReader` to read their contents and caches the result so that the 
module isn't loaded implicitly later on. A listener is attached to the 
`ASTReader` to collect names of the modules read from the PCM files. However, 
if the PCM has already been loaded previously via PCH:

1. the `ASTReader` doesn't do anything for the second time,
2. the listener is not invoked at all,
3. the module load result is not cached,
4. the compilation fails when attempting to load the module implicitly later on.

This patch solves this problem by asking the `ModuleManager` for the module 
instead of relying on the `ASTReader` listener. If the modules were loaded as 
part of loading the PCH, `ModuleManager` will know about them even though 
`ASTReader` didn't read them for the second time.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D111560

Files:
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Serialization/ModuleFile.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/test/ClangScanDeps/modules-pch.c
  clang/test/Modules/Inputs/pch-shared-module/mod.h
  clang/test/Modules/Inputs/pch-shared-module/module.modulemap
  clang/test/Modules/Inputs/pch-shared-module/pch.h
  clang/test/Modules/pch-shared-module.c

Index: clang/test/Modules/pch-shared-module.c
===
--- /dev/null
+++ clang/test/Modules/pch-shared-module.c
@@ -0,0 +1,14 @@
+// rm -rf %t && mkdir %t
+
+// RUN: %clang_cc1 -fmodules -emit-module -fmodule-name=mod %S/Inputs/pch-shared-module/module.modulemap -o %t/mod.pcm
+
+// RUN: %clang_cc1 -fmodules -emit-pch %S/Inputs/pch-shared-module/pch.h -o %t/pch.h.gch \
+// RUN:   -fmodule-file=%t/mod.pcm -fmodule-map-file=%S/Inputs/pch-shared-module/module.modulemap
+
+// Check that `mod.pcm` is loaded correctly, even though it's imported by the PCH as well.
+// RUN: %clang_cc1 -fmodules -fsyntax-only %s -include-pch %t/pch.h.gch -I %S/Inputs/pch-shared-module \
+// RUN:   -fmodule-file=%t/mod.pcm -fmodule-map-file=%S/Inputs/pch-shared-module/module.modulemap -verify
+
+#include "mod.h"
+
+// expected-no-diagnostics
Index: clang/test/Modules/Inputs/pch-shared-module/pch.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/pch-shared-module/pch.h
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/Modules/Inputs/pch-shared-module/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/pch-shared-module/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/modules-pch.c
===
--- clang/test/ClangScanDeps/modules-pch.c
+++ clang/test/ClangScanDeps/modules-pch.c
@@ -229,8 +229,7 @@
 // CHECK-TU-WITH-COMMON-NEXT:   "command-line": [
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-modules",
 // CHECK-TU-WITH-COMMON-NEXT: "-fno-implicit-module-maps",
-// FIXME: Figure out why we need `=ModCommon2` here for Clang to pick up the PCM.
-// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=ModCommon2=[[PREFIX]]/build/{{.*}}/ModCommon2-{{.*}}.pcm",
+// CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/{{.*}}/ModCommon2-{{.*}}.pcm",
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_TU_WITH_COMMON]]/ModTUWithCommon-{{.*}}.pcm",
 // CHECK-TU-WITH-COMMON-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -38,7 +38,7 @@
   };
 
   for (const PrebuiltModuleDep &PMD : PrebuiltModuleDeps) {
-Args.push_back("-fmodule-file=" + PMD.ModuleName + "=" + PMD.PCMFile);
+Args.push_back("-fmodule-file=" + PMD.PCMFile);
 Args.push_back("-fmodule-map-file=" + PMD.ModuleMapFile);
   }
 
Index: clang/lib/Serialization/ModuleFile.cpp
===
--- clang/lib/Serialization/ModuleFile.cpp
+++ clang/lib/Serialization/ModuleFile.cpp
@@ -28,6 +28,15 @@
   delete static_cast(SelectorLookupTable);
 }
 
+void ModuleFile::collectTransitiveImports(std::vector &Files) {
+  SmallVector Stack{this};
+  while (!Stack.empty(

[PATCH] D111560: [clang][modules] Cache loads of explicit modules imported by PCH

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

Note: Another approach to fixing this might be to cache the module load results 
while loading the PCH too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111560

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

[PATCH] D111472: [docs] Mention in release notes that we now support 2^32 alignment

[Arthur Eubanks via Phabricator via cfe-commits]

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

mention in Clang release notes as well


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111472

Files:
  clang/docs/ReleaseNotes.rst
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -60,6 +60,7 @@
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -709,7 +709,7 @@
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
@@ -9736,7 +9736,7 @@
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of the
 allocation is guaranteed to be aligned to at least that boundary. The
-alignment may not be greater than ``1 << 29``. If not specified, or if
+alignment may not be greater than ``1 << 32``. If not specified, or if
 zero, the target can choose to align the allocation on any convenient
 boundary compatible with the type.
 
@@ -9826,7 +9826,7 @@
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the alignment
 may produce less efficient code. An alignment of 1 is always safe. The
-maximum possible alignment is ``1 << 29``. An alignment value higher
+maximum possible alignment is ``1 << 32``. An alignment value higher
 than the size of the loaded type implies memory up to the alignment
 value bytes can be safely loaded without trapping in the default
 address space. Access of the high bytes can interfere with debugging
@@ -9961,7 +9961,7 @@
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the
 alignment may produce less efficient code. An alignment of 1 is always
-safe. The maximum possible alignment is ``1 << 29``. An alignment
+safe. The maximum possible alignment is ``1 << 32``. An alignment
 value higher than the size of the stored type implies memory up to the
 alignment value bytes can be stored to without trapping in the default
 address space. Storing to the higher bytes however may result in data
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -121,6 +121,7 @@
   `P2362 `_.
 - Support for ``__attribute__((error("")))`` and
   ``__attribute__((warning("")))`` function attributes have been added.
+- The maximum allowed alignment has been increased from 2^29 to 2^32.
 
 C++ Language Changes in Clang
 -


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -60,6 +60,7 @@
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -709,7 +709,7 @@
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
@@ -9736,7 +9736,7 @@
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of 

[clang] b41cfbf - [docs] Mention in release notes that we now support 2^32 alignment

[Arthur Eubanks via cfe-commits]

Author: Arthur Eubanks
Date: 2021-10-11T10:23:15-07:00
New Revision: b41cfbfcbbe27d519171b5847a8d44ca8a5a0f13

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

LOG: [docs] Mention in release notes that we now support 2^32 alignment

Missed in D110451.

Reviewed By: hans

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
llvm/docs/LangRef.rst
llvm/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f32ea39a77182..70dbc58030d0d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -121,6 +121,7 @@ C Language Changes in Clang
   `P2362 `_.
 - Support for ``__attribute__((error("")))`` and
   ``__attribute__((warning("")))`` function attributes have been added.
+- The maximum allowed alignment has been increased from 2^29 to 2^32.
 
 C++ Language Changes in Clang
 -

diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 587f694519c91..3f6349bb8afb2 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -709,7 +709,7 @@ to over-align the global if the global has an assigned 
section. In this
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
@@ -9736,7 +9736,7 @@ appropriate type to the program. If "NumElements" is 
specified, it is
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of the
 allocation is guaranteed to be aligned to at least that boundary. The
-alignment may not be greater than ``1 << 29``. If not specified, or if
+alignment may not be greater than ``1 << 32``. If not specified, or if
 zero, the target can choose to align the allocation on any convenient
 boundary compatible with the type.
 
@@ -9826,7 +9826,7 @@ alignment for the target. It is the responsibility of the 
code emitter
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the alignment
 may produce less efficient code. An alignment of 1 is always safe. The
-maximum possible alignment is ``1 << 29``. An alignment value higher
+maximum possible alignment is ``1 << 32``. An alignment value higher
 than the size of the loaded type implies memory up to the alignment
 value bytes can be safely loaded without trapping in the default
 address space. Access of the high bytes can interfere with debugging
@@ -9961,7 +9961,7 @@ alignment for the target. It is the responsibility of the 
code emitter
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the
 alignment may produce less efficient code. An alignment of 1 is always
-safe. The maximum possible alignment is ``1 << 29``. An alignment
+safe. The maximum possible alignment is ``1 << 32``. An alignment
 value higher than the size of the stored type implies memory up to the
 alignment value bytes can be stored to without trapping in the default
 address space. Storing to the higher bytes however may result in data

diff  --git a/llvm/docs/ReleaseNotes.rst b/llvm/docs/ReleaseNotes.rst
index fa0adbbeb6a1e..46627c2000679 100644
--- a/llvm/docs/ReleaseNotes.rst
+++ b/llvm/docs/ReleaseNotes.rst
@@ -60,6 +60,7 @@ Changes to the LLVM IR
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 



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

[PATCH] D111472: [docs] Mention in release notes that we now support 2^32 alignment

[Arthur Eubanks 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 rGb41cfbfcbbe2: [docs] Mention in release notes that we now 
support 2^32 alignment (authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111472

Files:
  clang/docs/ReleaseNotes.rst
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -60,6 +60,7 @@
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -709,7 +709,7 @@
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
@@ -9736,7 +9736,7 @@
 the number of elements allocated, otherwise "NumElements" is defaulted
 to be one. If a constant alignment is specified, the value result of the
 allocation is guaranteed to be aligned to at least that boundary. The
-alignment may not be greater than ``1 << 29``. If not specified, or if
+alignment may not be greater than ``1 << 32``. If not specified, or if
 zero, the target can choose to align the allocation on any convenient
 boundary compatible with the type.
 
@@ -9826,7 +9826,7 @@
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the alignment
 may produce less efficient code. An alignment of 1 is always safe. The
-maximum possible alignment is ``1 << 29``. An alignment value higher
+maximum possible alignment is ``1 << 32``. An alignment value higher
 than the size of the loaded type implies memory up to the alignment
 value bytes can be safely loaded without trapping in the default
 address space. Access of the high bytes can interfere with debugging
@@ -9961,7 +9961,7 @@
 to ensure that the alignment information is correct. Overestimating the
 alignment results in undefined behavior. Underestimating the
 alignment may produce less efficient code. An alignment of 1 is always
-safe. The maximum possible alignment is ``1 << 29``. An alignment
+safe. The maximum possible alignment is ``1 << 32``. An alignment
 value higher than the size of the stored type implies memory up to the
 alignment value bytes can be stored to without trapping in the default
 address space. Storing to the higher bytes however may result in data
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -121,6 +121,7 @@
   `P2362 `_.
 - Support for ``__attribute__((error("")))`` and
   ``__attribute__((warning("")))`` function attributes have been added.
+- The maximum allowed alignment has been increased from 2^29 to 2^32.
 
 C++ Language Changes in Clang
 -


Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -60,6 +60,7 @@
   will be removed after LLVM 14. In the meantime, only minimal effort will be
   made to maintain the legacy pass manager for the optimization pipeline.
 * Max allowed integer type was reduced from 2^24-1 bits to 2^23 bits.
+* Max allowed alignment was increased from 2^29 to 2^32.
 
 Changes to building LLVM
 
Index: llvm/docs/LangRef.rst
===
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -709,7 +709,7 @@
 case, the extra alignment could be observable: for example, code could
 assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
-iteration. The maximum alignment is ``1 << 29``.
+iteration. The maximum alignment is ``1 << 32``.
 
 For global variables declarations, as well as definitions that may be
 replaced at link time (``linkonce``, ``weak``, ``extern_weak`` and ``common``
@@ -9736,7 +9736,7 @@
 the number of elements allocated, otherwise "NumElements" is defaulted

[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

[Michael Kruse via Phabricator via cfe-commits]

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

Some nitpicks, but it fixes the build, so LGTM.




Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:617
+  // Find nvlink and pass it as "--nvlink-command=" argument of 
clang-nvlink-wrapper.
+  auto NvlinkBin = getToolChain().GetProgramPath("nvlink");
+  const char *NvlinkPath =

[style] [[ 
https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
 | LLVM's coding standard does not use almost-always-auto ]].

It's not immediately obvious here, does `GetProgramPath` look into the BinPath 
detected by CudaInstallationDetector? I applied the patch locally to 
http://meinersbur.de:8011/#/builders/1 and it actually does work.



Comment at: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp:169-170
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (size_t i = 0; i < NVArgs.size(); ++i) {
+std::string Arg = NVArgs[i];
 if (sys::path::extension(Arg) == ".a") {




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

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

[PATCH] D111457: [clang][test] Add lit helper for windows paths

[Keith Smiley via Phabricator via cfe-commits]

keith updated this revision to Diff 378725.
keith marked 2 inline comments as done.
keith added a comment.

Allow empty leading on windows

This behavior is currently broken, the directory should never be `/` or `C:\` 
but the logic is broken and only handles `/`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111457

Files:
  clang/test/CodeGen/debug-prefix-map.c
  clang/test/lit.cfg.py


Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -56,6 +56,16 @@
 config.substitutions.append(('%PATH%', config.environment['PATH']))
 
 
+if platform.system() == 'Windows':
+root_sep = 'C:\\'
+else:
+root_sep = os.path.sep
+
+config.substitutions.extend([
+('%{rootsep}', root_sep),
+('%{sep}', os.path.sep),
+])
+
 # For each occurrence of a clang tool name, replace it with the full path to
 # the build directory holding that tool.  We explicitly specify the directories
 # to search to ensure that we get the tools just built and not some random
Index: clang/test/CodeGen/debug-prefix-map.c
===
--- clang/test/CodeGen/debug-prefix-map.c
+++ clang/test/CodeGen/debug-prefix-map.c
@@ -1,10 +1,10 @@
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - | FileCheck %s 
-check-prefix CHECK-NO-MAIN-FILE-NAME
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH=empty %s -emit-llvm -o - | FileCheck %s 
-check-prefix CHECK-EVIL
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -main-file-name 
debug-prefix-map.c | FileCheck %s
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - 
-fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
-// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=/UNLIKELY_PATH/empty %s -emit-llvm -o - -isysroot %p 
-debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
-// RUN: %clang -g -fdebug-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
-// RUN: %clang -g -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -S -c %s 
-emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty %s -emit-llvm -o - | 
FileCheck %s -check-prefix CHECK-NO-MAIN-FILE-NAME
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH=empty %s -emit-llvm -o - | 
FileCheck %s -check-prefix CHECK-EVIL
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty %s -emit-llvm -o - 
-main-file-name debug-prefix-map.c | FileCheck %s
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty %s -emit-llvm -o - 
-fdebug-compilation-dir %p | FileCheck %s -check-prefix CHECK-COMPILATION-DIR
+// RUN: %clang_cc1 -debug-info-kind=standalone 
-fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty %s -emit-llvm -o - 
-isysroot %p -debugger-tuning=lldb | FileCheck %s -check-prefix CHECK-SYSROOT
+// RUN: %clang -g -fdebug-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty -S 
-c %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang -g -ffile-prefix-map=%p=%{rootsep}UNLIKELY_PATH%{sep}empty -S 
-c %s -emit-llvm -o - | FileCheck %s
 
 #include "Inputs/stdio.h"
 
@@ -19,26 +19,26 @@
   vprintf("string", argp);
 }
 
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}"
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}{{.*}}",
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:|()}}UNLIKELY_PATH{{/|}}empty{{/|}}"
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:|()}}UNLIKELY_PATH{{/|}}empty{{/|}}{{.*}}",
 // On POSIX systems "Dir" should actually be empty, but on Windows we
 // can't recognize "/UNLIKELY_PATH" as being an absolute path.
 // CHECK-NO-MAIN-FILE-NAME-SAME:directory: "{{()|(.*:.*)}}")
-// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"/UNLIKELY_PATH/empty{{/|}}Inputs/stdio.h",
+// CHECK-NO-MAIN-FILE-NAME: !DIFile(filename: 
"{{/|C:|()}}UNLIKELY_PATH{{/|}}empty{{/|}}Inputs{{/|}}stdio.h",
 // CHECK-NO-MAIN-FILE-NAME-SAME:directory: "{{()|(.*:.*)}}")
 // CHECK-NO-MAIN-FILE-NAME-NOT: !DIFile(filename:
 
-// CHECK-EVIL: !DIFile(filename: "/UNLIKELY_PATH=empty{{/|}}{{.*}}"
-// CHECK-EVIL: !DIFile(filename: 
"/UNLIKELY_PATH=empty{{/|}}{{.*}}Inputs/stdio.h",
+// CHECK-EVIL: !DIFile(filename: 
"{{/|C:|()}}UNLIKELY_PATH=empty{{/|}}{{.*}}"
+// CHECK-EVIL: !DIFile(filename: 
"{{/|C:|()}}UNLIKELY_PATH=empty{{/|}}{{.*}}Inputs{{/|}}stdio.h",
 // CHECK-EVIL-SAME:directory: "{{()

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Kito Cheng via Phabricator via cfe-commits]

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

Changes:

- Rebase to main
- Remove b and zbproposedc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c
  clang/test/Driver/riscv-features.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/CMakeLists.txt
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/attribute-with-insts.s
  llvm/test/MC/RISCV/invalid-attribute.s

Index: llvm/test/MC/RISCV/invalid-attribute.s
===
--- llvm/test/MC/RISCV/invalid-attribute.s
+++ llvm/test/MC/RISCV/invalid-attribute.s
@@ -7,10 +7,10 @@
 # RUN: not llvm-mc %s -triple=riscv64 -filetype=asm 2>&1 | FileCheck %s
 
 .attribute arch, "foo"
-# CHECK: [[@LINE-1]]:18: error: bad arch string foo
+# CHECK: [[@LINE-1]]:18: error: invalid arch name 'foo', string must begin with rv32{i,e,g} or rv64{i,g}
 
 .attribute arch, "rv32i2p0_y2p0"
-# CHECK: [[@LINE-1]]:18: error: bad arch string y2p0
+# CHECK: [[@LINE-1]]:18: error: invalid arch name 'rv32i2p0_y2p0', invalid standard user-level extension 'y'
 
 .attribute stack_align, "16"
 # CHECK: [[@LINE-1]]:25: error: expected numeric constant
Index: llvm/test/MC/RISCV/attribute-with-insts.s
===
--- llvm/test/MC/RISCV/attribute-with-insts.s
+++ llvm/test/MC/RISCV/attribute-with-insts.s
@@ -10,7 +10,7 @@
 # RUN:   | llvm-objdump --triple=riscv64 -d -M no-aliases - \
 # RUN:   | FileCheck -check-prefix=CHECK-INST %s
 
-.attribute arch, "rv64i2p0_m2p0_a2p0_d2p0_c2p0"
+.attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
 # CHECK-INST: lr.w t0, (t1)
 lr.w t0, (t1)
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -9,9 +9,6 @@
 .attribute arch, "rv32i2"
 # CHECK: attribute  5, "rv32i2p0"
 
-.attribute arch, "rv32i2p"
-# CHECK: attribute  5, "rv32i2p0"
-
 .attribute arch, "rv32i2p0"
 # CHECK: attribute  5, "rv32i2p0"
 
@@ -33,11 +30,11 @@
 .attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
-.attribute arch, "rv32ima2p_fdc"
+.attribute arch, "rv32ima2p0_fdc"
 # CHECK: attribute  5, "rv32i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
 
 .attribute arch, "rv32iv"
-# CHECK: attribute  5, "rv32i2p0_v0p10"
+# CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
 
 .attribute arch, "rv32izba"
 # CHECK: attribute  5, "rv32i2p0_zba0p93"
Index: llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
===
--- llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
+++ llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
@@ -11,9 +11,11 @@
 //===--===//
 
 #include "RISCVTargetStreamer.h"
+#include "RISCVBaseInfo.h"
 #include "RISCVMCTargetDesc.h"
 #include "llvm/Support/FormattedStream.h"
 #include "llvm/Support/RISCVAttributes.h"
+#include "llvm/Support/RISCVISAInfo.h"
 
 using namespace llvm;
 
@@ -43,53 +45,19 @@
   else
 emitAttribute(RISCVAttrs::STACK_ALIGN, RISCVAttrs::ALIGN_16);
 
-  std::string Arch = "rv32";
-  if (STI.hasFeature(RISCV::Feature64Bit))
-Arch = "rv64";
-  if (STI.hasFeature(RISCV::FeatureRV32E))
-Arch += "e1p9";
-  else
-Arch += "i2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtM))
-Arch += "_m2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtA))
-Arch += "_a2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtF))
-Arch += "_f2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtD))
-Arch += "_d2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtC))
-Arch += "_c2p0";
-  if (STI.hasFeature(RISCV::FeatureStdExtV))
-Arch += "_v0p10";
-  if (STI.hasFeature(RISCV::FeatureStdExtZfh))
-Arch += "_zfh0p1";
-  if (STI.hasFeature(RISCV::FeatureStdExtZba))
-Arch += "_zba0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtZbb))
-Arch += "_zbb0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtZbc))
-Arch += "_zbc0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtZbe))
-Arch += "_zbe0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtZbf))
-Arch += "_zbf0p93";
-  if (STI.hasFeature(RISCV::FeatureStdExtZbm))
-Arch += "_zbm0p93";
-  if (STI.hasFeature(RISCV::FeatureStd

[PATCH] D111488: [Clang][clang-nvlink-wrapper] Pass nvlink path to the wrapper

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:620
+  Args.MakeArgString(Twine("--nvlink-command=" + NvlinkBin));
+  CmdArgs.push_back(NvlinkPath);
+

Nit: the variables above are used only once. It would be fine to just 
`push_back(MakeArgString(GetProgramPath()))`.




Comment at: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp:50
+
+static cl::opt NvlinkUserPath("nvlink-command",
+   cl::desc("path of nvlink binary"),

Nit. Clang already has `--ptxas-path=` option. It may be worth using `-path` 
suffix here for consistency, too.



Comment at: clang/tools/clang-nvlink-wrapper/ClangNvlinkWrapper.cpp:169-170
 
-  for (size_t i = 1; i < Argv.size(); ++i) {
-std::string Arg = Argv[i];
+  for (size_t i = 0; i < NVArgs.size(); ++i) {
+std::string Arg = NVArgs[i];
 if (sys::path::extension(Arg) == ".a") {

Meinersbur wrote:
> 
Nit: `for (const std::string &Arg : NVArgs)` to avoid unnecessary copies.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111488

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

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

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

Ping:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D111566: [SYCL] Fix function pointer address space

[Elizabeth Andrews via Phabricator via cfe-commits]

eandrews created this revision.
eandrews added reviewers: vlastik, dylanmckay, bader.
Herald added subscribers: Naghasan, Anastasia, ebevhan, yaxunl.
eandrews requested review of this revision.

Functions pointers should be created with program address space. This patch 
fixes a crash on lvalue reference to function pointer (in device code) when 
using oneAPI DPC++ compiler.


https://reviews.llvm.org/D111566

Files:
  clang/lib/CodeGen/CodeGenTypes.cpp


Index: clang/lib/CodeGen/CodeGenTypes.cpp
===
--- clang/lib/CodeGen/CodeGenTypes.cpp
+++ clang/lib/CodeGen/CodeGenTypes.cpp
@@ -633,7 +633,9 @@
 const ReferenceType *RTy = cast(Ty);
 QualType ETy = RTy->getPointeeType();
 llvm::Type *PointeeType = ConvertTypeForMem(ETy);
-unsigned AS = Context.getTargetAddressSpace(ETy);
+unsigned AS = PointeeType->isFunctionTy()
+  ? getDataLayout().getProgramAddressSpace()
+  : Context.getTargetAddressSpace(ETy);
 ResultType = llvm::PointerType::get(PointeeType, AS);
 break;
   }


Index: clang/lib/CodeGen/CodeGenTypes.cpp
===
--- clang/lib/CodeGen/CodeGenTypes.cpp
+++ clang/lib/CodeGen/CodeGenTypes.cpp
@@ -633,7 +633,9 @@
 const ReferenceType *RTy = cast(Ty);
 QualType ETy = RTy->getPointeeType();
 llvm::Type *PointeeType = ConvertTypeForMem(ETy);
-unsigned AS = Context.getTargetAddressSpace(ETy);
+unsigned AS = PointeeType->isFunctionTy()
+  ? getDataLayout().getProgramAddressSpace()
+  : Context.getTargetAddressSpace(ETy);
 ResultType = llvm::PointerType::get(PointeeType, AS);
 break;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111517: [X86] Remove little support we had for MPX

[Fangrui Song via Phabricator via cfe-commits]

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

fix tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111517

Files:
  clang/test/CodeGen/ms-inline-asm.c
  llvm/lib/Target/X86/Disassembler/X86Disassembler.cpp
  llvm/lib/Target/X86/Disassembler/X86DisassemblerDecoder.h
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrMPX.td
  llvm/lib/Target/X86/X86RegisterInfo.td
  llvm/test/CodeGen/X86/ipra-reg-usage.ll
  llvm/test/MC/X86/mpx-encodings.s
  llvm/unittests/tools/llvm-exegesis/X86/SnippetGeneratorTest.cpp

Index: llvm/unittests/tools/llvm-exegesis/X86/SnippetGeneratorTest.cpp
===
--- llvm/unittests/tools/llvm-exegesis/X86/SnippetGeneratorTest.cpp
+++ llvm/unittests/tools/llvm-exegesis/X86/SnippetGeneratorTest.cpp
@@ -213,26 +213,6 @@
   ASSERT_TRUE(BC.Key.Instructions[0].getOperand(3).isImm());
 }
 
-TEST_F(X86ParallelSnippetGeneratorTest, ParallelInstruction) {
-  // - BNDCL32rr
-  // - Op0 Explicit Use RegClass(BNDR)
-  // - Op1 Explicit Use RegClass(GR32)
-  // - Var0 [Op0]
-  // - Var1 [Op1]
-  const unsigned Opcode = X86::BNDCL32rr;
-  const auto CodeTemplates = checkAndGetCodeTemplates(Opcode);
-  ASSERT_THAT(CodeTemplates, SizeIs(1));
-  const auto &CT = CodeTemplates[0];
-  EXPECT_THAT(CT.Info, HasSubstr("parallel"));
-  EXPECT_THAT(CT.Execution, ExecutionMode::UNKNOWN);
-  ASSERT_THAT(CT.Instructions, SizeIs(1));
-  const InstructionTemplate &IT = CT.Instructions[0];
-  EXPECT_THAT(IT.getOpcode(), Opcode);
-  ASSERT_THAT(IT.getVariableValues(), SizeIs(2));
-  EXPECT_THAT(IT.getVariableValues()[0], IsInvalid());
-  EXPECT_THAT(IT.getVariableValues()[1], IsInvalid());
-}
-
 TEST_F(X86ParallelSnippetGeneratorTest, SerialInstruction) {
   // - CDQ
   // - Op0 Implicit Def Reg(EAX)
Index: llvm/test/MC/X86/mpx-encodings.s
===
--- llvm/test/MC/X86/mpx-encodings.s
+++ /dev/null
@@ -1,41 +0,0 @@
-// RUN: llvm-mc -triple x86_64-- --show-encoding %s |\
-// RUN:   FileCheck %s --check-prefixes=CHECK,ENCODING
-
-// RUN: llvm-mc -triple x86_64-- -filetype=obj %s |\
-// RUN:   llvm-objdump -d - | FileCheck %s
-
-// CHECK: bndmk (%rax), %bnd0
-// ENCODING:  encoding: [0xf3,0x0f,0x1b,0x00]
-bndmk (%rax), %bnd0
-
-// CHECK: bndmk 1024(%rax), %bnd1
-// ENCODING:  encoding: [0xf3,0x0f,0x1b,0x88,0x00,0x04,0x00,0x00]
-bndmk 1024(%rax), %bnd1
-
-// CHECK: bndmov  %bnd2, %bnd1
-// ENCODING:  encoding: [0x66,0x0f,0x1a,0xca]
-bndmov %bnd2, %bnd1
-
-// CHECK: bndmov %bnd1, 1024(%r9)
-// ENCODING:  encoding: [0x66,0x41,0x0f,0x1b,0x89,0x00,0x04,0x00,0x00]
-bndmov %bnd1, 1024(%r9)
-
-// CHECK: bndstx %bnd1, 1024(%rax)
-// ENCODING:  encoding: [0x0f,0x1b,0x88,0x00,0x04,0x00,0x00]
-bndstx %bnd1, 1024(%rax)
-
-// CHECK: bndldx 1024(%r8), %bnd1
-// ENCODING:  encoding: [0x41,0x0f,0x1a,0x88,0x00,0x04,0x00,0x00]
-bndldx 1024(%r8), %bnd1
-
-// CHECK: bndcl 121(%r10), %bnd1
-// ENCODING:  encoding: [0xf3,0x41,0x0f,0x1a,0x4a,0x79]
-bndcl 121(%r10), %bnd1
-
-// CHECK: bndcn 121(%rcx), %bnd3
-// ENCODING:  encoding: [0xf2,0x0f,0x1b,0x59,0x79]
-bndcn 121(%rcx), %bnd3
-
-// CHECK: bndcu %rdx, %bnd3
-// ENCODING:  encoding: [0xf2,0x0f,0x1a,0xda]
-bndcu %rdx, %bnd3
Index: llvm/test/CodeGen/X86/ipra-reg-usage.ll
===
--- llvm/test/CodeGen/X86/ipra-reg-usage.ll
+++ llvm/test/CodeGen/X86/ipra-reg-usage.ll
@@ -3,7 +3,7 @@
 target triple = "x86_64-unknown-unknown"
 declare void @bar1()
 define preserve_allcc void @foo()#0 {
-; CHECK: foo Clobbered Registers: $cs $df $ds $eflags $eip $eiz $es $esp $fpcw $fpsw $fs $gs $hip $hsp $ip $mxcsr $rip $riz $rsp $sp $sph $spl $ss $ssp $tmmcfg $bnd0 $bnd1 $bnd2 $bnd3 $cr0 $cr1 $cr2 $cr3 $cr4 $cr5 $cr6 $cr7 $cr8 $cr9 $cr10 $cr11 $cr12 $cr13 $cr14 $cr15 $dr0 $dr1 $dr2 $dr3 $dr4 $dr5 $dr6 $dr7 $dr8 $dr9 $dr10 $dr11 $dr12 $dr13 $dr14 $dr15 $fp0 $fp1 $fp2 $fp3 $fp4 $fp5 $fp6 $fp7 $k0 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $mm0 $mm1 $mm2 $mm3 $mm4 $mm5 $mm6 $mm7 $r11 $st0 $st1 $st2 $st3 $st4 $st5 $st6 $st7 $tmm0 $tmm1 $tmm2 $tmm3 $tmm4 $tmm5 $tmm6 $tmm7 $xmm16 $xmm17 $xmm18 $xmm19 $xmm20 $xmm21 $xmm22 $xmm23 $xmm24 $xmm25 $xmm26 $xmm27 $xmm28 $xmm29 $xmm30 $xmm31 $ymm0 $ymm1 $ymm2 $ymm3 $ymm4 $ymm5 $ymm6 $ymm7 $ymm8 $ymm9 $ymm10 $ymm11 $ymm12 $ymm13 $ymm14 $ymm15 $ymm16 $ymm17 $ymm18 $ymm19 $ymm20 $ymm21 $ymm22 $ymm23 $ymm24 $ymm25 $ymm26 $ymm27 $ymm28 $ymm29 $ymm30 $ymm31 $zmm0 $zmm1 $zmm2 $zmm3 $zmm4 $zmm5 $zmm6 $zmm7 $zmm8 $zmm9 $zmm10 $zmm11 $zmm12 $zmm13 $zmm14 $zmm15 $zmm16 $zmm17 $zmm18 $zmm19 $zmm20 $zmm21 $zmm22 $zmm23 $zmm24 $zmm25 $zmm26 $zmm27 $zmm28 $zmm29 $zmm30 $zmm31 $r11b $r11bh $r11d $r11w $r11wh $k0_k1 $k2_k3 $k4_k5 $k6_k7
+; CHECK: foo Clobbered Registers: $cs $df $ds $eflags $eip 

[clang] d409048 - [Sema] Use llvm::is_contained (NFC)

[Kazu Hirata via cfe-commits]

Author: Kazu Hirata
Date: 2021-10-11T11:06:44-07:00
New Revision: d4090482013599b1c246f3553717e2a88d6b24a5

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

LOG: [Sema] Use llvm::is_contained (NFC)

Added: 


Modified: 
clang/lib/Sema/AnalysisBasedWarnings.cpp
clang/lib/Sema/SemaAccess.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaInit.cpp
clang/lib/Sema/SemaLookup.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp

Removed: 




diff  --git a/clang/lib/Sema/AnalysisBasedWarnings.cpp 
b/clang/lib/Sema/AnalysisBasedWarnings.cpp
index 99ce143d3559d..30bceb085bb98 100644
--- a/clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ b/clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -497,8 +497,7 @@ static ControlFlowKind CheckFallThrough(AnalysisDeclContext 
&AC) {
   HasAbnormalEdge = true;
   continue;
 }
-if (std::find(B.succ_begin(), B.succ_end(), &cfg->getExit())
-== B.succ_end()) {
+if (!llvm::is_contained(B.succs(), &cfg->getExit())) {
   HasAbnormalEdge = true;
   continue;
 }

diff  --git a/clang/lib/Sema/SemaAccess.cpp b/clang/lib/Sema/SemaAccess.cpp
index 580305c1110bc..3f7b387ec9250 100644
--- a/clang/lib/Sema/SemaAccess.cpp
+++ b/clang/lib/Sema/SemaAccess.cpp
@@ -140,7 +140,7 @@ struct EffectiveContext {
 
   bool includesClass(const CXXRecordDecl *R) const {
 R = R->getCanonicalDecl();
-return llvm::find(Records, R) != Records.end();
+return llvm::is_contained(Records, R);
   }
 
   /// Retrieves the innermost "useful" context.  Can be null if we're

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 48f298f2ce823..1a8d7cc67a8f8 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2962,8 +2962,7 @@ void Sema::mergeDeclAttributes(NamedDecl *New, Decl *Old,
   if (const auto *NewAbiTagAttr = New->getAttr()) {
 if (const auto *OldAbiTagAttr = Old->getAttr()) {
   for (const auto &NewTag : NewAbiTagAttr->tags()) {
-if (std::find(OldAbiTagAttr->tags_begin(), OldAbiTagAttr->tags_end(),
-  NewTag) == OldAbiTagAttr->tags_end()) {
+if (!llvm::is_contained(OldAbiTagAttr->tags(), NewTag)) {
   Diag(NewAbiTagAttr->getLocation(),
diag::err_new_abi_tag_on_redeclaration)
   << NewTag;

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index cd50818d10638..07e80901e2193 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -1796,7 +1796,7 @@ static void handleOwnershipAttr(Sema &S, Decl *D, const 
ParsedAttr &AL) {
  I->getOwnKind() == OwnershipAttr::Returns) {
 // A returns attribute conflicts with any other returns attribute using
 // a 
diff erent index.
-if (std::find(I->args_begin(), I->args_end(), Idx) == I->args_end()) {
+if (!llvm::is_contained(I->args(), Idx)) {
   S.Diag(I->getLocation(), diag::err_ownership_returns_index_mismatch)
   << I->args_begin()->getSourceIndex();
   if (I->args_size())

diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index d72cb43549fb5..dc2455e0afbcd 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -12946,7 +12946,7 @@ static void DiagnoseRecursiveConstFields(Sema &S, const 
ValueDecl *VD,
   // Then we append it to the list to check next in order.
   FieldTy = FieldTy.getCanonicalType();
   if (const auto *FieldRecTy = FieldTy->getAs()) {
-if (llvm::find(RecordTypeList, FieldRecTy) == RecordTypeList.end())
+if (!llvm::is_contained(RecordTypeList, FieldRecTy))
   RecordTypeList.push_back(FieldRecTy);
   }
 }

diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index efbdd187cbe1d..75686e2947041 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -9915,8 +9915,7 @@ Sema::PerformCopyInitialization(const InitializedEntity 
&Entity,
   const bool ShouldTrackCopy =
   Entity.isParameterKind() && Seq.isConstructorInitialization();
   if (ShouldTrackCopy) {
-if (llvm::find(CurrentParameterCopyTypes, Entity.getType()) !=
-CurrentParameterCopyTypes.end()) {
+if (llvm::is_contained(CurrentParameterCopyTypes, Entity.getType())) {
   Seq.SetOverloadFailure(
   InitializationSequence::FK_ConstructorOverloadFailed,
   OR_No_Viable_Function);

diff  --git a/clang/lib/Sema/SemaLookup.cpp b/clang/lib/Sema/SemaLookup.cpp
index f0ab50f0acddc..e4e5f57745c61 100644
--- a/clang/lib/Sema/SemaLookup.cpp
+++ b/clang/lib/Sema/SemaLookup.cpp
@@ -4596,9 +4596,7 @@ void 
Ty

[PATCH] D111208: [clang-tidy] Support globbing in NOLINT* expressions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added reviewers: njames93, hokein, whisperity.
aaron.ballman added a comment.
Herald added a subscriber: rnkovacs.

In D111208#3054246 , @carlosgalvezp 
wrote:

> Awesome, thanks a lot for the review, I really improved my understanding of 
> the tool :)
>
> @aaron.ballman Could you review? Otherwise could you point me to who should 
> review? I tagged @alexfh as owner of clang-tidy but haven't really seen him 
> around... Shouldn't there be multiple owners, so that there's not a "single 
> point of failure"?

I'm happy to review (I'll add a few more folks to the list though). Just an 
FYI, but we usually only ping when there's been about a week of no traffic on 
the review. Reviewers have a fairly heavy workload and we've settled on a week 
between pings as being the happy medium.

In D111208#3053370 , @carlosgalvezp 
wrote:

> Thanks for the clarification, makes a lot of sense now! I'll see what I can 
> do with that.
>
> By the way, is `NOLINTBEGIN/END` expected to work/give errors when the check 
> name is something else than a real check name? See for example:
>
> https://godbolt.org/z/b6cbTeezs
>
> I would expect to get a warning that an `END` was found that didn't match a 
> `BEGIN`.

If the tags don't match (so there's an open for a check but never a close for 
the check), then we should diagnose. However, we should *not* diagnose unknown 
check names (because the user may be suppressing checks that clang-tidy doesn't 
know about, such as ones in another static analysis tool run over the same 
code). However, given that we don't run the NOLINT pass unless there are 
diagnostics to emit, I think it's fine to not diagnose a mismatch between 
unknown tags.




Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:349
+  // Allow specifying a few checks with a glob expression.
+  GlobList Globs(ChecksStr);
+  if (!Globs.contains(CheckName))

carlosgalvezp wrote:
> salman-javed-nz wrote:
> > What happens when `CheckStr` is empty?
> > How has Clang-Tidy treated `// NOLINT()` in the past? Does this patch 
> > change the behaviour? What //should // be the "right" behaviour?
> Very good question! Currently on master `// NOLINT()` will *not* suppress 
> warnings. However `// NOLINT(` will. My patch shouldn't change existing 
> behavior - an empty list of globs will return false when calling `contains`.
> 
> I'll add a unit test to cover this case!
(All of this is a bit orthogonal to this patch, so no changes requested here.)

Naively, I would expect `NOLINT()` to be an error because it expects an 
argument and none was given. (I'd expect `NOLINT(` to also be an error because 
the syntax is malformed.)



Comment at: clang-tools-extra/docs/clang-tidy/index.rst:347
+// No warnings are suppressed, due to double negation
+Foo(bool param);  // NOLINT(-google*)
   };

salman-javed-nz wrote:
> carlosgalvezp wrote:
> > salman-javed-nz wrote:
> > > salman-javed-nz wrote:
> > > > carlosgalvezp wrote:
> > > > > salman-javed-nz wrote:
> > > > > > Would anyone do this on purpose, or is this a user error?
> > > > > I don't see any use case here, no. I just thought to document it to 
> > > > > clarify the double negation that's happening, in case a user gets 
> > > > > confused and doesn't see the warning being suppressed.
> > > > > 
> > > > > Do you think it brings value or does more harm than good?
> > > > 
> > > > I don't see any use case here, no. I just thought to document it to 
> > > > clarify the double negation that's happening, in case a user gets 
> > > > confused and doesn't see the warning being suppressed.
> > > > 
> > > > Do you think it brings value or does more harm than good?
> > > 
> > > I'd be happy with just the basic `+` glob functionality. The first thing 
> > > I'd use it on is to suppress checks that are an alias of another check, 
> > > e.g. `NOLINT(*no-malloc)` to cover both `hicpp-no-malloc` and 
> > > `cppcoreguidelines-no-malloc`.
> > > 
> > > As for glob expressions that begin with a `-`... you get the 
> > > functionality for free thanks to the `GlobList` class but it's not a 
> > > feature I think I will need. I speak only for myself though. Maybe 
> > > someone else here has a strong need for this?
> > > 
> > > Is `NOLINTBEGIN(-check)` equivalent to `NOLINTEND(check)`? It hursts my 
> > > head even thinking about it.
> > > 
> > > Your unit test where you test `NOLINT(google*,-google*,google*)`, 
> > > Clang-Tidy does the right thing in that situation, but I have to wonder 
> > > why any user would want to add, remove, then add the same check group in 
> > > the one expression in the first place? Should we even be entertaining 
> > > this kind of use?
> > > Is NOLINTBEGIN(-check) equivalent to NOLINTEND(check)?
> > 
> > To me it's clear that it's not. Any NOLINTBEGIN(X) must have a matching 
> 

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

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

I'm still worried that this solution as implemented is going to break existing 
users, including major one like Rust.

I'm not also not a fan of special casing individual targets like Fuchsia 
directly inside `Driver`, I believe that any per-target logic should live in 
the corresponding `ToolChain` subclass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

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

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D110663#3055813 , @phosek wrote:

> I'm still worried that this solution as implemented is going to break 
> existing users, including major one like Rust.
>
> I'm not also not a fan of special casing individual targets like Fuchsia 
> directly inside `Driver`, I believe that any per-target logic should live in 
> the corresponding `ToolChain` subclass.

Given the potential wide ranging impact of this change, it might be also worth 
starting a thread on llvm-dev to reach a broader audience.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added reviewers: hans, aaron.ballman.
thakis requested review of this revision.

`[[clang::fallthrough]]` has meaning for the CFG, but all other
StmtAttrs we currently have don't. So omit them, as AttributedStatements
with children cause several issues and there's no benefit in including
them.

Fixes PR52103 and PR49454. See PR52103 for details.


https://reviews.llvm.org/D111568

Files:
  clang/lib/Analysis/CFG.cpp
  clang/test/SemaCXX/switch-implicit-fallthrough.cpp
  clang/test/SemaCXX/unreachable-code.cpp

Index: clang/test/SemaCXX/unreachable-code.cpp
===
--- clang/test/SemaCXX/unreachable-code.cpp
+++ clang/test/SemaCXX/unreachable-code.cpp
@@ -77,3 +77,25 @@
 return;
   bar(); // no-warning
 }
+
+namespace pr52103 {
+
+void g(int a);
+
+void f(int a) {
+  if (a > 4) [[ likely ]] { // no-warning
+return;
+  }
+
+  if (a > 4) [[ unlikely ]] { // no-warning
+return;
+
+return; // expected-warning {{will never be executed}}
+  }
+
+  [[clang::musttail]] return g(a); // no-warning
+
+  [[clang::musttail]] return g(a); // expected-warning {{will never be executed}}
+}
+
+}
Index: clang/test/SemaCXX/switch-implicit-fallthrough.cpp
===
--- clang/test/SemaCXX/switch-implicit-fallthrough.cpp
+++ clang/test/SemaCXX/switch-implicit-fallthrough.cpp
@@ -50,6 +50,8 @@
   break;
   }
   switch (n / 20) {
+[[likely]] case 6:
+  [[clang::fallthrough]];
 case 7:
   n += 400;
   [[clang::fallthrough]];
@@ -73,6 +75,8 @@
   n += 800;
   }
   switch (n / 30) {
+case 6:
+  [[unlikely, clang::fallthrough]];
 case 11:
 case 12:  // no warning here, intended fall-through, no statement between labels
   n += 1600;
Index: clang/lib/Analysis/CFG.cpp
===
--- clang/lib/Analysis/CFG.cpp
+++ clang/lib/Analysis/CFG.cpp
@@ -542,6 +542,7 @@
   // Visitors to walk an AST and construct the CFG.
   CFGBlock *VisitInitListExpr(InitListExpr *ILE, AddStmtChoice asc);
   CFGBlock *VisitAddrLabelExpr(AddrLabelExpr *A, AddStmtChoice asc);
+  CFGBlock *VisitAttributedStmt(AttributedStmt *C, AddStmtChoice asc);
   CFGBlock *VisitBinaryOperator(BinaryOperator *B, AddStmtChoice asc);
   CFGBlock *VisitBreakStmt(BreakStmt *B);
   CFGBlock *VisitCallExpr(CallExpr *C, AddStmtChoice asc);
@@ -2149,6 +2150,9 @@
 case Stmt::InitListExprClass:
   return VisitInitListExpr(cast(S), asc);
 
+case Stmt::AttributedStmtClass:
+  return VisitAttributedStmt(cast(S), asc);
+
 case Stmt::AddrLabelExprClass:
   return VisitAddrLabelExpr(cast(S), asc);
 
@@ -2398,8 +2402,30 @@
   return Block;
 }
 
-CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U,
-   AddStmtChoice asc) {
+static bool isFallthroughStatement(const AttributedStmt *A) {
+  return hasSpecificAttr(A->getAttrs()) &&
+ isa(A->getSubStmt());
+}
+
+CFGBlock *CFGBuilder::VisitAttributedStmt(AttributedStmt *A,
+  AddStmtChoice asc) {
+  // AttributedStmts for [[likely]] can have arbitrary statements as children,
+  // and the current visitation order here would add the AttributedStmts
+  // for [[likely]] after the child nodes, which is undesirable: For example,
+  // if the child contains an unconditional return, the [[likely]] would be
+  // considered unreachable.
+  // So only add the AttributedStmt for FallThrough, which has CFG effects and
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {
+autoCreateBlock();
+appendStmt(Block, A);
+  }
+
+  return VisitChildren(A);
+}
+
+CFGBlock *CFGBuilder::VisitUnaryOperator(UnaryOperator *U, AddStmtChoice asc) {
   if (asc.alwaysAdd(*this, U)) {
 autoCreateBlock();
 appendStmt(Block, U);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 144f851 - [clang/CFG] Rewrap a line to 80 columns

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-10-11T14:23:51-04:00
New Revision: 144f851f6f5203969ef8b8052060ad56fcaab934

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

LOG: [clang/CFG] Rewrap a line to 80 columns

Added: 


Modified: 
clang/lib/Analysis/CFG.cpp

Removed: 




diff  --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index 05ac8d00c10fc..b1afbbc7a14df 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -2711,7 +2711,8 @@ CFGBlock *CFGBuilder::VisitChooseExpr(ChooseExpr *C,
   return addStmt(C->getCond());
 }
 
-CFGBlock *CFGBuilder::VisitCompoundStmt(CompoundStmt *C, bool 
ExternallyDestructed) {
+CFGBlock *CFGBuilder::VisitCompoundStmt(CompoundStmt *C,
+bool ExternallyDestructed) {
   LocalScope::const_iterator scopeBeginPos = ScopePos;
   addLocalScopeForStmt(C);
 



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

[clang] 00ca004 - [clang] Convert a few loops to for-each

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-10-11T14:24:32-04:00
New Revision: 00ca004dda3215dce98cf081cd6b1ee8b7a8b3d6

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

LOG: [clang] Convert a few loops to for-each

Added: 


Modified: 
clang/lib/Analysis/CFG.cpp
clang/lib/Sema/AnalysisBasedWarnings.cpp
clang/lib/Sema/SemaAvailability.cpp

Removed: 




diff  --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index b1afbbc7a14d..306da631d34a 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -2724,11 +2724,10 @@ CFGBlock *CFGBuilder::VisitCompoundStmt(CompoundStmt *C,
 
   CFGBlock *LastBlock = Block;
 
-  for (CompoundStmt::reverse_body_iterator I=C->body_rbegin(), 
E=C->body_rend();
-   I != E; ++I ) {
+  for (Stmt *S : llvm::reverse(C->body())) {
 // If we hit a segment of code just containing ';' (NullStmts), we can
 // get a null block back.  In such cases, just use the LastBlock
-CFGBlock *newBlock = Visit(*I, AddStmtChoice::AlwaysAdd,
+CFGBlock *newBlock = Visit(S, AddStmtChoice::AlwaysAdd,
ExternallyDestructed);
 
 if (newBlock)

diff  --git a/clang/lib/Sema/AnalysisBasedWarnings.cpp 
b/clang/lib/Sema/AnalysisBasedWarnings.cpp
index 30bceb085bb9..2b089ff084ca 100644
--- a/clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ b/clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -1079,11 +1079,9 @@ namespace {
   while (!BlockQueue.empty()) {
 const CFGBlock *P = BlockQueue.front();
 BlockQueue.pop_front();
-for (CFGBlock::const_succ_iterator I = P->succ_begin(),
-   E = P->succ_end();
- I != E; ++I) {
-  if (*I && ReachableBlocks.insert(*I).second)
-BlockQueue.push_back(*I);
+for (const CFGBlock *B : P->succs()) {
+  if (B && ReachableBlocks.insert(B).second)
+BlockQueue.push_back(B);
 }
   }
 }

diff  --git a/clang/lib/Sema/SemaAvailability.cpp 
b/clang/lib/Sema/SemaAvailability.cpp
index d1c3d25b089d..dc15c87cb717 100644
--- a/clang/lib/Sema/SemaAvailability.cpp
+++ b/clang/lib/Sema/SemaAvailability.cpp
@@ -630,8 +630,7 @@ class LastDeclUSEFinder : public 
RecursiveASTVisitor {
   const CompoundStmt *Scope) {
 LastDeclUSEFinder Visitor;
 Visitor.D = D;
-for (auto I = Scope->body_rbegin(), E = Scope->body_rend(); I != E; ++I) {
-  const Stmt *S = *I;
+for (const Stmt *S : llvm::reverse(Scope->body())) {
   if (!Visitor.TraverseStmt(const_cast(S)))
 return S;
 }



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

[clang] 5ab2a95 - [clang] Remove an else-after-return

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2021-10-11T14:24:58-04:00
New Revision: 5ab2a95edb62e67478095e4e5619a07efc95ee21

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

LOG: [clang] Remove an else-after-return

Added: 


Modified: 
clang/lib/Analysis/CFG.cpp

Removed: 




diff  --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index 306da631d34a..50adc8c75bb5 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -3124,9 +3124,9 @@ CFGBlock *CFGBuilder::VisitReturnStmt(Stmt *S) {
 if (Expr *O = RS->getRetValue())
   return Visit(O, AddStmtChoice::AlwaysAdd, /*ExternallyDestructed=*/true);
 return Block;
-  } else { // co_return
-return VisitChildren(S);
   }
+  // co_return
+  return VisitChildren(S);
 }
 
 CFGBlock *CFGBuilder::VisitSEHExceptStmt(SEHExceptStmt *ES) {



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

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

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D110663#3055813 , @phosek wrote:

> I'm still worried that this solution as implemented is going to break 
> existing users, including major one like Rust.

Well, it's better than calling the Project build deprecated (in favor of 
Runtime build) and making the situation unfortunate for major distributions 
like Debian/Ubuntu.

For downstream packages like Rust, there is currently no evidence for the 
breakage.

Moreover, llvm-project has always had the attitude: "downstream projects are on 
their own".
In reality we seldom exercise this right but if there are quirky things we 
reserve the right to ask them to fix.
(I have patched packages like Julia/Rust/ldc, so I understand that for each 
major version, some adaptation is unavoidable.)

> I'm not also not a fan of special casing individual targets like Fuchsia 
> directly inside `Driver`, I believe that any per-target logic should live in 
> the corresponding `ToolChain` subclass.

I add the code more as a workaround. I hope Fuchsia can move away from the mix 
of `x86_64-unknown-fuchsia` and `x86_64-fuchsia`.
At the point when the mix is fixed, we can simply remove the special case.
The special case is for providing a transition period. Using subclasses adds 
more complexity to the driver code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663

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

[PATCH] D111570: [clang/CFG] Don't explicitly add AttributedStmtClass to AlwaysAddList

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added a reviewer: hans.
thakis requested review of this revision.

CFGBuilder::addStmt() implicitly passes AddStmtChoice::AlwaysAdd
to Visit() already, so this should have no behavior change.


https://reviews.llvm.org/D111570

Files:
  clang/lib/Sema/AnalysisBasedWarnings.cpp


Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -2272,8 +2272,7 @@
   .setAlwaysAdd(Stmt::CStyleCastExprClass)
   .setAlwaysAdd(Stmt::DeclRefExprClass)
   .setAlwaysAdd(Stmt::ImplicitCastExprClass)
-  .setAlwaysAdd(Stmt::UnaryOperatorClass)
-  .setAlwaysAdd(Stmt::AttributedStmtClass);
+  .setAlwaysAdd(Stmt::UnaryOperatorClass);
   }
 
   // Install the logical handler.


Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -2272,8 +2272,7 @@
   .setAlwaysAdd(Stmt::CStyleCastExprClass)
   .setAlwaysAdd(Stmt::DeclRefExprClass)
   .setAlwaysAdd(Stmt::ImplicitCastExprClass)
-  .setAlwaysAdd(Stmt::UnaryOperatorClass)
-  .setAlwaysAdd(Stmt::AttributedStmtClass);
+  .setAlwaysAdd(Stmt::UnaryOperatorClass);
   }
 
   // Install the logical handler.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/lib/Analysis/CFG.cpp:2410
+
+CFGBlock *CFGBuilder::VisitAttributedStmt(AttributedStmt *A,
+  AddStmtChoice asc) {

(Compare this function to `CFGBuilder::VisitStmt` in this file, which is the 
default function that's called for Stmts and which is what was called for 
AttributedStmt before this patch added a dedicated handler for AttributedStmt.)


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

https://reviews.llvm.org/D111568

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

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:194
 
-  if (MArch.startswith_insensitive("rv32")) {
-// FIXME: parse `March` to find `D` extension properly
-if (MArch.substr(4).contains_insensitive("d") ||
-MArch.startswith_insensitive("rv32g"))
-  return "ilp32d";
-else if (MArch.startswith_insensitive("rv32e"))
-  return "ilp32e";
-else
-  return "ilp32";
-  } else if (MArch.startswith_insensitive("rv64")) {
-// FIXME: parse `March` to find `D` extension properly
-if (MArch.substr(4).contains_insensitive("d") ||
-MArch.startswith_insensitive("rv64g"))
-  return "lp64d";
-else
-  return "lp64";
+  auto ParseResult = llvm::RISCVISAInfo::parseArchString(Arch, true);
+  if (!ParseResult) {

Please add an inline comment for what "true" represents.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:206
+return "ilp32d";
+  else if (HasE)
+return "ilp32e";

Drop else after return



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:208
+return "ilp32e";
+  else
+return "ilp32";

here too



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:213
+return "lp64d";
+  else
+return "lp64";

Here too



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:216
+}
   }
 

Should we have an llvm_unreachable here for unknown values of XLen?



Comment at: llvm/include/llvm/Support/RISCVISAInfo.h:43
+
+  /// OrderedExtensionMap is a StringMap-like container, but specialized to
+  /// keep entries in canonical order of extension.

I'm not sure the comparison to StringMap is helpful here. StringMap is an 
unordered map that stores strings in the same allocation as the value. This 
std::map is ordered and doesn't store the strings in the same allocation.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:286
+ bool ExperimentalExtensionVersionCheck) {
+  std::string MajorStr, MinorStr;
+  Major = 0;

Do MajorStr and MinorStr need to be std::strings or can they be StringRefs? 
Looks like they are either empty or a subset of In. So there shouldn't be a 
lifetime issue?



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:352
+Error += "." + MinorStr;
+  Error += " for experimental extension (this compiler supports " +
+   utostr(SupportedVers.Major) + "." + utostr(SupportedVers.Minor) 
+

Should this message say which extension the error applies to?



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:388
+const std::vector &Features) {
+  std::unique_ptr ISAInfo(new RISCVISAInfo());
+  assert(XLen == 32 || XLen == 64);

Use

```
auto ISAInfo = std::make_unique()
```



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:390
+  assert(XLen == 32 || XLen == 64);
+  ISAInfo->XLen = XLen;
+

Can we make XLen part of the RISCVISAInfo constructor? Seems like we know that 
early enough.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:440
+  bool ExperimentalExtensionVersionCheck) {
+  std::unique_ptr ISAInfo(new RISCVISAInfo());
+  // RISC-V ISA strings must be lowercase.

Can we delay constructing this until after the first 2 error checks? Then we 
could pass XLen to the constructor.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:709
+
+  if (XLen == 32)
+Arch << "rv32";

Would this better as

```
Arch << "rv" << XLen;
```

That makes it future proof to a hypothetical rv128 someday.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

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

[PATCH] D111199: [POC][BTF] support btf_type_tag attribute

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D99#3054126 , @yonghong-song 
wrote:

> @aaron.ballman Ping. This is to address your concern in D110127 
> , could you take a look whether my proposal 
> for a new attribute btf_type_tag will be okay for you or not? Thanks!

Thank you for the new approach! On the whole, I think this seems like the 
better way to go. One thing that's not clear to me is whether we expect to give 
this type attribute any semantics beyond passing further information to debug 
info or not. e.g., do we have to worry about things like:

  #define __tag1 __attribute__((btf_type_tag("tag1")))
  #define __tag2 __attribute__((btf_type_tag("tag2")))
  
  int * __tag1 t1;
  int * __tag2 t2 = t1; // Diagnose a type mismatch?

(I know you don't intend to support that sort of thing right now, but I'm 
wondering about the future -- basically, I'm worried about the situation where 
we accept code like that without a diagnostic now, but want to diagnose it in 
the future and will force a breaking change on users.)

You should definitely fix up the clang-format issues and fix identifiers to 
meet the usual naming conventions, etc.




Comment at: clang/include/clang/AST/Type.h:4768
+private:
+  std::string BTFTypeTag;
+

I think we should be able to use a `StringRef` instead, rather than have to 
worry about allocations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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

[PATCH] D111041: [clang-tidy] Remove 'IgnoreDestructors = true' from cppcoreguidelines-explicit-virtual-functions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/modernize-use-override.cpp:56
   virtual ~SimpleCases();
-  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual'
   // CHECK-FIXES: {{^}}  ~SimpleCases() override;

This isn't quite what I was after; now it looks like we expect to always get 
the diagnostic (in fact, I'm a bit worried that this test is passing). I'd 
rather see:
```
// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: prefer using 'override' or 
(rarely) 'final' instead of 'virtual' [modernize-use-override]
// CHECK-CPPCOREGUIDELINES-NOT: :[[@LINE-2]]:11: warning: prefer using 
'override' or (rarely) 'final' instead of 'virtual'
```
So that we check explicitly we see the diagnostic for modernize and explicitly 
that we don't see the diagnostic for C++ Core Guidelines.

You'll need to change the second RUN line to not use `check_clang_tidy` but 
instead execute clang-tidy manually so you can pass 
`-check-prefix=CHECK-CPPCOREGUIDELINES` to it (as done in 
https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/test/clang-tidy/checkers/cert-static-object-exception.cpp#L4).


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

https://reviews.llvm.org/D111041

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

[PATCH] D111545: [Clang][NFC] Fix multiline comment prefixes in function headers

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp:118
   AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
-  SubArchName,
-  /* bitcode SDL?*/ true,
-  /* PostClang Link? */ false);
+ SubArchName, true, false);
   // Add an intermediate output file.

The usual style for "named parameters" in LLVm is

```
 AddStaticDeviceLibsLinking(C, *this, JA, Inputs, Args, CmdArgs, "amdgcn",
SubArchName, /*isBitCodeSDL=*/true, 
/*postClangLink=*/false);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111545

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

[PATCH] D100810: Use `GNUInstallDirs` to support custom installation dirs. -- LLVM

[John Ericson via Phabricator via cfe-commits]

Ericson2314 marked 2 inline comments as done.
Ericson2314 added a comment.

Removed extraneous StringRef conversion after previous D111322 
 was landed.




Comment at: llvm/tools/llvm-config/llvm-config.cpp:361
+{
+  SmallString<256> Path(StringRef(LLVM_INSTALL_INCLUDEDIR));
+  sys::fs::make_absolute(ActivePrefix, Path);

Ericson2314 wrote:
> Ericson2314 wrote:
> > Ericson2314 wrote:
> > > compnerd wrote:
> > > > Why the temporary `StringRef`?  Can you not just initialize `Path` with 
> > > > the literal?
> > > I'm not sure. I would think so too, but the old code was also using 
> > > `StringRef` so I just followed cargo culted and went with it.
> > Should I, say, submit a separate patch trying to remove the existing one?
> I opened D111322  for this. If that passes CI and lands, I have the next 
> version of this without `StringRef` ready to go.
Fix issue now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100810

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

[PATCH] D111560: [clang][modules] Cache loads of explicit modules imported by PCH

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D111560#3055578 , @jansvoboda11 
wrote:

> Note: Another approach to fixing this might be to cache the module load 
> results while loading the PCH too.

Can you share why you chose this approach instead, and which do you think makes 
sense long term?




Comment at: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp:41
   for (const PrebuiltModuleDep &PMD : PrebuiltModuleDeps) {
-Args.push_back("-fmodule-file=" + PMD.ModuleName + "=" + PMD.PCMFile);
+Args.push_back("-fmodule-file=" + PMD.PCMFile);
 Args.push_back("-fmodule-map-file=" + PMD.ModuleMapFile);

Why drop the `=` argument? Isn't it better to keep that information, 
rather than forcing the reader to crack open the file to know what's inside?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111560

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

[PATCH] D111568: [clang] Omit most AttributedStatements from the CFG

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for the fix to this!




Comment at: clang/lib/Analysis/CFG.cpp:2418-2420
+  // also no children, and omit the others. None of the other current StmtAttrs
+  // have semantic meaning for the CFG.
+  if (isFallthroughStatement(A) && asc.alwaysAdd(*this, A)) {

What about `OpenCLUnrollHintAttr`, `NoMergeAttr`, and `MustTailAttr`? These all 
have some semantic effect as statement attributes in terms of changing codegen, 
but perhaps they don't need modelling in the CFG?

(I'm trying to decide whether we may want to tablegen this functionality and so 
we might want something more general than `isFallthroughStatement()`.)


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

https://reviews.llvm.org/D111568

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

[PATCH] D111545: [Clang][NFC] Fix multiline comment prefixes in function headers

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

what @thakis said, this isn't normally my area but this is one of the files 
that has reverted its "clang-format clean" status with recent commits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111545

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

[PATCH] D102923: [clang][lex] Remark on search path usage

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

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

Thanks; I think this was worth it. I like how clean it looks with `-verify` in 
place.

LGTM if you add a couple more header map tests, explained inline.




Comment at: clang/test/Preprocessor/search-path-usage-headers.m:78-91
+
+// Check that header maps are reported.
+//
+// RUN: sed "s|DIR|%/S/Inputs/search-path-usage|g" 
%S/Inputs/search-path-usage/b.hmap.json.template > %t/b.hmap.json
+// RUN: %hmaptool write %t/b.hmap.json %t/b.hmap
+// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
+// RUN:   -I %t/b.hmap   \

This is a good positive test, but I don't see a negative test or the "matched 
but not ultimately found" case I mentioned before.

You can add a RUN like this for the negative test:
```
// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
//  -I%t/b.hmap  \
//  -I%S/Inputs/search-path-usage/d  \
//  -DHMAP_NO_MATCH -verify
#ifdef HMAP_NO_MATCH
#include "d.h" // expected-remark {{search path used: ../d'}}
#endif
```
(same hmap, but not found in the headermap)

and like this for the "matched in header map but not ultimately found" case 
(different hmap, pointing at a file that won't be found):
```
// RUN: sed "s|DIR|%/S/Inputs/search-path-usage/missing-subdir|g" \
// RUN: %S/Inputs/search-path-usage/b.hmap.json.template > 
%t/b-missing.hmap.json
// RUN: %hmaptool write %t/b-missing.hmap.json %t/b-missing.hmap
// RUN: %clang_cc1 -Eonly %s -Rsearch-path-usage \
// RUN:   -I %t/b-missing.hmap   \
// RUN:   -I b   \
// RUN:   -DHMAP_MATCHED_BUT_MISSING -verify
#ifdef HMAP_MATCHED_BUT_MISSING
#include "b.h" // \
  // expected-remark {{search path used: ../b-missing.hmap}} \
  // expected-error {{file not found: "b.h" [or whatever it is in the end]}}
#endif
```
(Maybe would be good to have a `__has_include`-matched-but-missing test as 
well? I'll leave it up to you.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102923

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

[PATCH] D111557: [clang][modules] NFC: Propagate import `SourceLocation` into `HeaderSearch::lookupModule`

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith accepted this revision.
dexonsmith 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/D111557/new/

https://reviews.llvm.org/D111557

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

[clang] 121b225 - AddGlobalAnnotations for function with or without function body.

[Chris Bieneman via cfe-commits]

Author: Chris Bieneman
Date: 2021-10-11T14:50:34-05:00
New Revision: 121b2252de0eed68f2ddf5f09e924a6c35423d47

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

LOG: AddGlobalAnnotations for function with or without function body.

When AnnotateAttr is on a function, AddGlobalAnnotations is only called
in CodeGenModule::EmitGlobalFunctionDefinition which means AnnotateAttr
on function declaration without function body will be ignored.
The patch will move AddGlobalAnnotations  to
CodeGenModule::SetFunctionAttributes, so with or without function body,
the AnnotateAttr will get code gen for a function.

It'll help case when AnnotateAttr is on external function, and the
AnnotateAttr will be consumed in IR level.

For example, a pass to collect num of uses for functions with
__attribute((annotate("count_use"))) after optimizations,
As long as there's __attribute((annotate("count_use"))), function with
or without function body should be counted.

Reviewed By: aaron.ballman

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

Patch by:  python3kgae (Xiang Li)

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/CodeGen/annotations-global.c
clang/test/CodeGenCXX/attr-annotate.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index d4e3186c10a53..9fa5e9cf1b79c 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -2195,6 +2195,9 @@ void CodeGenModule::SetFunctionAttributes(GlobalDecl GD, 
llvm::Function *F,
CalleeIdx, PayloadIndices,
/* VarArgsArePassed */ 
false)}));
   }
+
+  if (FD->hasAttr())
+AddGlobalAnnotations(FD, F);
 }
 
 void CodeGenModule::addUsedGlobal(llvm::GlobalValue *GV) {
@@ -4893,8 +4896,6 @@ void 
CodeGenModule::EmitGlobalFunctionDefinition(GlobalDecl GD,
 AddGlobalCtor(Fn, CA->getPriority());
   if (const DestructorAttr *DA = D->getAttr())
 AddGlobalDtor(Fn, DA->getPriority(), true);
-  if (D->hasAttr())
-AddGlobalAnnotations(D, Fn);
 }
 
 void CodeGenModule::EmitAliasDefinition(GlobalDecl GD) {

diff  --git a/clang/test/CodeGen/annotations-global.c 
b/clang/test/CodeGen/annotations-global.c
index 2a5c847fd9602..454680fa57d66 100644
--- a/clang/test/CodeGen/annotations-global.c
+++ b/clang/test/CodeGen/annotations-global.c
@@ -4,15 +4,19 @@
 // RUN: FileCheck --check-prefix=BAR %s < %t1
 // RUN: FileCheck --check-prefix=FOOS %s < %t1
 // RUN: FileCheck --check-prefix=ADDRSPACE %s < %t1
+// RUN: FileCheck --check-prefix=DECL %s < %t1
 // RUN: %clang_cc1 %s -triple r600 -emit-llvm -o - | FileCheck %s 
--check-prefix AS1-GLOBALS
 // END.
 
 static __attribute((annotate("sfoo_0"))) __attribute((annotate("sfoo_1"))) 
char sfoo;
 __attribute((annotate("foo_0"))) __attribute((annotate("foo_1"))) char foo;
 
+void __attribute((annotate("ann_decl_0"))) 
__attribute((annotate("ann_decl_1")))  decl(char *a);
+
 void __attribute((annotate("ann_a_0"))) __attribute((annotate("ann_a_1"))) 
__attribute((annotate("ann_a_2"))) __attribute((annotate("ann_a_3"))) a(char 
*a);
 void __attribute((annotate("ann_a_0"))) __attribute((annotate("ann_a_1"))) 
a(char *a) {
   __attribute__((annotate("bar_0"))) __attribute__((annotate("bar_1"))) static 
char bar;
+  decl(a);
   sfoo = 0;
 }
 
@@ -22,13 +26,13 @@ __attribute((address_space(1))) 
__attribute__((annotate("addrspace1_ann"))) char
 // FOOS: private unnamed_addr constant [7 x i8] c"sfoo_{{.}}\00", section 
"llvm.metadata"
 // FOOS: private unnamed_addr constant [7 x i8] c"sfoo_{{.}}\00", section 
"llvm.metadata"
 // FOOS-NOT: sfoo_
-// FOOS: @llvm.global.annotations = appending global [11 x { i8*, i8*, i8*, 
i32, i8* }] {{.*}}i8* @sfoo{{.*}}i8* @sfoo{{.*}}, section "llvm.metadata"
+// FOOS: @llvm.global.annotations = appending global [13 x { i8*, i8*, i8*, 
i32, i8* }] {{.*}}i8* @sfoo{{.*}}i8* @sfoo{{.*}}, section "llvm.metadata"
 
 // FOO: target triple
 // FOO: private unnamed_addr constant [6 x i8] c"foo_{{.}}\00", section 
"llvm.metadata"
 // FOO: private unnamed_addr constant [6 x i8] c"foo_{{.}}\00", section 
"llvm.metadata"
 // FOO-NOT: foo_
-// FOO: @llvm.global.annotations = appending global [11 x { i8*, i8*, i8*, 
i32, i8* }] {{.*}}i8* @foo{{.*}}i8* @foo{{.*}}, section "llvm.metadata"
+// FOO: @llvm.global.annotations = appending global [13 x { i8*, i8*, i8*, 
i32, i8* }] {{.*}}i8* @foo{{.*}}i8* @foo{{.*}}, section "llvm.metadata"
 
 // A: target triple
 // A: private unnamed_addr constant [8 x i8] c"ann_a_{{.}}\00", section 
"llvm.metadata"
@@ -36,18 +40,24 @@ __attribute((address_space(1))) 
__attribute__((annotate("addrspace1_ann"))) char
 // A: private unnamed_addr constant [8 x i8] c"an

[PATCH] D111109: AddGlobalAnnotations for function with or without function body.

[Chris Bieneman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG121b2252de0e: AddGlobalAnnotations for function with or 
without function body. (authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D09

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/annotations-global.c
  clang/test/CodeGenCXX/attr-annotate.cpp

Index: clang/test/CodeGenCXX/attr-annotate.cpp
===
--- clang/test/CodeGenCXX/attr-annotate.cpp
+++ clang/test/CodeGenCXX/attr-annotate.cpp
@@ -1,11 +1,16 @@
 // RUN: %clang_cc1 %s -S -emit-llvm -triple x86_64-unknown-linux-gnu -o - | FileCheck %s
 
+//CHECK: @[[STR:.*]] = private unnamed_addr constant [5 x i8] c"test\00", section "llvm.metadata"
 //CHECK: @[[STR1:.*]] = private unnamed_addr constant [{{.*}} x i8] c"{{.*}}attr-annotate.cpp\00", section "llvm.metadata"
 //CHECK: @[[STR2:.*]] = private unnamed_addr constant [4 x i8] c"abc\00", align 1
-//CHECK: @[[STR:.*]] = private unnamed_addr constant [5 x i8] c"test\00", section "llvm.metadata"
 //CHECK: @[[ARGS:.*]] = private unnamed_addr constant { i32, i8*, i32 } { i32 9, i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[STR2:.*]], i32 0, i32 0), i32 8 }, section "llvm.metadata"
 //CHECK: @[[ARGS2:.*]] = private unnamed_addr constant { %struct.Struct } { %struct.Struct { i32* getelementptr inbounds ([2 x i32], [2 x i32]* @_ZN1AIjLj9EE2SVE, i32 0, i32 0), i32* bitcast (i8* getelementptr (i8, i8* bitcast ([2 x i32]* @_ZN1AIjLj9EE2SVE to i8*), i64 4) to i32*) } }, section "llvm.metadata"
-//CHECK: @llvm.global.annotations = appending global [2 x { i8*, i8*, i8*, i32, i8* }] [{ i8*, i8*, i8*, i32, i8* } { i8* bitcast (void (%struct.A*)* @_ZN1AIjLj9EE4testILi8EEEvv to i8*), i8* getelementptr inbounds ([5 x i8], [5 x i8]* @[[STR:.*]], i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @[[STR1:.*]], i32 0, i32 0), i32 {{.*}}, i8* bitcast ({ i32, i8*, i32 }* @[[ARGS:.*]] to i8*) }, { i8*, i8*, i8*, i32, i8* } { i8* bitcast (void (%struct.A*)* @_ZN1AIjLj9EE5test2Ev to i8*), i8* getelementptr inbounds ([5 x i8], [5 x i8]* @.str.6, i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @.str.1, i32 0, i32 0), i32 24, i8* bitcast ({ %struct.Struct }* @[[ARGS2]] to i8*) }]
+//CHECK: @[[VANN0:.*]] = private unnamed_addr constant [8 x i8] c"v_ann_0\00", section "llvm.metadata"
+//CHECK: @[[B_ARG_IMM_7:.*]] = private unnamed_addr constant { i8*, i32, i32 } { i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[STR2]], i32 0, i32 0), i32 90, i32 7 }, section "llvm.metadata"
+//CHECK: @[[VANN1:.*]] = private unnamed_addr constant [8 x i8] c"v_ann_1\00", section "llvm.metadata"
+//CHECK: @[[VAAN1_ARG_IMM9:.*]] = private unnamed_addr constant { i32 } { i32 9 }, section "llvm.metadata"
+//CHECK: @[[B_ARG_IMM_NEG1:.*]] = private unnamed_addr constant { i8*, i32, i64 } { i8* getelementptr inbounds ([4 x i8], [4 x i8]* @[[STR2]], i32 0, i32 0), i32 90, i64 -1 }, section "llvm.metadata"
+//CHECK: @llvm.global.annotations = appending global [2 x { i8*, i8*, i8*, i32, i8* }] [{ i8*, i8*, i8*, i32, i8* } { i8* bitcast (void (%struct.A*)* @_ZN1AIjLj9EE4testILi8EEEvv to i8*), i8* getelementptr inbounds ([5 x i8], [5 x i8]* @[[STR]], i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @[[STR1]], i32 0, i32 0), i32 {{.*}}, i8* bitcast ({ i32, i8*, i32 }* @[[ARGS]] to i8*) }, { i8*, i8*, i8*, i32, i8* } { i8* bitcast (void (%struct.A*)* @_ZN1AIjLj9EE5test2Ev to i8*), i8* getelementptr inbounds ([5 x i8], [5 x i8]* @[[STR]], i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @[[STR1]], i32 0, i32 0), i32 {{.*}}, i8* bitcast ({ %struct.Struct }* @[[ARGS2]] to i8*) }]
 
 constexpr const char* str() {
   return "abc";
@@ -52,17 +57,17 @@
 // CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[ARGC_ADDR]], align 4
 // CHECK-NEXT:[[V:%.*]] = getelementptr inbounds %"struct.B::foo", %"struct.B::foo"* [[F]], i32 0, i32 0
 // CHECK-NEXT:[[TMP1:%.*]] = bitcast i32* [[V]] to i8*
-// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.ptr.annotation.p0i8(i8* [[TMP1]], i8* getelementptr inbounds ([8 x i8], [8 x i8]* @.str, i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @.str.1, i32 0, i32 0), i32 {{.*}}, i8* bitcast ({ i8*, i32, i32 }* @.args to i8*))
+// CHECK-NEXT:[[TMP2:%.*]] = call i8* @llvm.ptr.annotation.p0i8(i8* [[TMP1]], i8* getelementptr inbounds ([8 x i8], [8 x i8]* @[[VANN0]], i32 0, i32 0), i8* getelementptr inbounds ([{{.*}} x i8], [{{.*}} x i8]* @.str.1, i32 0, i32 0), i32 {{.*}}, i8* bitcast ({ i8*, i32, i32 }* @[[B_ARG_IMM_7]] to i8*))
 // CHECK-NEXT:[[TMP3:%.*]] = bitcast i8* [[TMP2]] to i32*
 // CHECK-NEXT:[[TMP4:%.*]] = bitcast i32* [[TMP3]] to i8*
-// CHECK-NEXT:[[TMP5:%.*]] = call i8* @llvm.ptr.annotation.p0i8(i8* [[TMP4]], i8* getelementpt

[clang] 25fabc4 - Add release note about `TypeLoc` matchers.

[Yitzhak Mandelbaum via cfe-commits]

Author: James King
Date: 2021-10-11T19:57:32Z
New Revision: 25fabc434ad5d1d7edd994b1fafb87e70ee2cda1

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

LOG: Add release note about `TypeLoc` matchers.

Reviewed By: ymandel, aaron.ballman

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 70dbc58030d0d..0ebbf1eb63636 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -184,7 +184,11 @@ Build System Changes
 AST Matchers
 
 
-- ...
+- ``TypeLoc`` AST Matchers are now available. These matchers provide helpful
+  utilities for matching ``TypeLoc`` nodes, such as the ``pointerTypeLoc``
+  matcher or the ``hasReturnTypeLoc`` matcher. The addition of these matchers
+  was made possible by changes to the handling of ``TypeLoc`` nodes that
+  allows them to enjoy the same static type checking as other AST node kinds.
 
 clang-format
 



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

[PATCH] D111518: Add release note about `TypeLoc` matchers.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG25fabc434ad5: Add release note about `TypeLoc` matchers. 
(authored by jcking1034, committed by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111518

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -184,7 +184,11 @@
 AST Matchers
 
 
-- ...
+- ``TypeLoc`` AST Matchers are now available. These matchers provide helpful
+  utilities for matching ``TypeLoc`` nodes, such as the ``pointerTypeLoc``
+  matcher or the ``hasReturnTypeLoc`` matcher. The addition of these matchers
+  was made possible by changes to the handling of ``TypeLoc`` nodes that
+  allows them to enjoy the same static type checking as other AST node kinds.
 
 clang-format
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -184,7 +184,11 @@
 AST Matchers
 
 
-- ...
+- ``TypeLoc`` AST Matchers are now available. These matchers provide helpful
+  utilities for matching ``TypeLoc`` nodes, such as the ``pointerTypeLoc``
+  matcher or the ``hasReturnTypeLoc`` matcher. The addition of these matchers
+  was made possible by changes to the handling of ``TypeLoc`` nodes that
+  allows them to enjoy the same static type checking as other AST node kinds.
 
 clang-format
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111199: [POC][BTF] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added a comment.

In D99#3055928 , @aaron.ballman 
wrote:

> In D99#3054126 , @yonghong-song 
> wrote:
>
>> @aaron.ballman Ping. This is to address your concern in D110127 
>> , could you take a look whether my 
>> proposal for a new attribute btf_type_tag will be okay for you or not? 
>> Thanks!
>
> Thank you for the new approach! On the whole, I think this seems like the 
> better way to go.

Great. I will go with this approach then.

> One thing that's not clear to me is whether we expect to give this type 
> attribute any semantics beyond passing further information to debug info or 
> not. e.g., do we have to worry about things like:
>
>   #define __tag1 __attribute__((btf_type_tag("tag1")))
>   #define __tag2 __attribute__((btf_type_tag("tag2")))
>   
>   int * __tag1 t1;
>   int * __tag2 t2 = t1; // Diagnose a type mismatch?
>
> (I know you don't intend to support that sort of thing right now, but I'm 
> wondering about the future -- basically, I'm worried about the situation 
> where we accept code like that without a diagnostic now, but want to diagnose 
> it in the future and will force a breaking change on users.)

This is a good question. These type attributes are mostly for type checking. In 
linux kernel, they are used by sparse 
(https://www.kernel.org/doc/html/v4.11/dev-tools/sparse.html) for type 
checking. We could implement a clang phase to utilize such information for type 
checking as well. But this is not the goal so far. Even if we indeed 
implemented type checking based on btf_type_tag in the future, it is likely to 
issue as a warning instead of a hard error. The attribute is mostly used to 
compile linux kernel, so we should be okay, e.g., to fix all issues in the 
kernel before turning on type checking feature in clang, etc.

> You should definitely fix up the clang-format issues and fix identifiers to 
> meet the usual naming conventions, etc.

Yes, this is true. This is a RFC patch so I didn't do clang-format at all. Will 
make sure all clang-format issues fixed, naming conventions followed with the 
formal patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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

[PATCH] D111199: [POC][BTF] support btf_type_tag attribute

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added inline comments.



Comment at: clang/include/clang/AST/Type.h:4768
+private:
+  std::string BTFTypeTag;
+

aaron.ballman wrote:
> I think we should be able to use a `StringRef` instead, rather than have to 
> worry about allocations.
StringRef indeed works as a type. Previously, I used StringRef directly passed 
by the caller but later the underlying string is somehow freed so I got a "" 
string for tag. I will revisit this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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

[PATCH] D111543: [clang][modules] Stop creating `IdentifierInfo` for names of explicit modules

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

It seems like using `CachedModuleLoads` wasn't quite right in the first place. 
I wonder if `-fmodule-file=` could/should use a different map (maybe one 
that doesn't exist yet), instead of replacing the key in CachedModuleLoads.

In D111543#3054922 , @jansvoboda11 
wrote:

> It'd be great if someone could clarify why the extra `IdentifierInfo` would 
> trip up name resolution.

My guess would be that the attribute parsing does a lookup of "Identifier" and 
finds the entity introduced by `-fmodule-file` instead of the one that's part 
of the declaration. Not sure though.

Are you sure this is only for Objective-C interfaces? Doesn't also happen if 
you name a module after a C++ class or something, and reference it from an 
attribute?

> Suggestions on naming the test file are also welcome.

Doesn't really seem to be about visibility. Maybe 
`module-name-used-by-objc-bridge`?




Comment at: clang/include/clang/Lex/ModuleMap.h:101-102
 
   /// The top-level modules that are known.
   llvm::StringMap Modules;
 

I wonder, could `-fmodule-file=...` be using this map instead (already a 
StringMap), and the map below reserved for "real" identifiers?




Comment at: clang/include/clang/Lex/ModuleMap.h:104-106
+  /// Module loading cache that includes submodules, indexed by module names.
   /// nullptr is stored for modules that are known to fail to load.
+  llvm::StringMap CachedModuleLoads;

In builds with lots of fine-grained submodules, this will add many tiny 
allocations (one for each map entry). Maybe use 
`StringMap` to group them together?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111543

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