date:20221024

[PATCH] D136548: [clang][CodeGen] Consistently return nullptr Values for void builtins and scalar initalization

2022-10-24 Thread Markus Böck via Phabricator via cfe-commits

zero9178 updated this revision to Diff 470071.
zero9178 added a comment.

clang-format and specify target triple in test since mangling is target 
dependent


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

https://reviews.llvm.org/D136548

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/pr53127.cpp

Index: clang/test/CodeGen/pr53127.cpp
===
--- /dev/null
+++ clang/test/CodeGen/pr53127.cpp
@@ -0,0 +1,87 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -emit-llvm %s -o - -triple x86_64-unknown-linux-gnu | FileCheck %s
+
+bool e();
+
+void operator delete(void*);
+
+// CHECK-LABEL: @_Z1fPiz(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[P_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:[[L:%.*]] = alloca [1 x %struct.__va_list_tag], align 16
+// CHECK-NEXT:[[L2:%.*]] = alloca [1 x %struct.__va_list_tag], align 16
+// CHECK-NEXT:store ptr [[P:%.*]], ptr [[P_ADDR]], align 8
+// CHECK-NEXT:[[CALL:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL]], label [[COND_TRUE:%.*]], label [[COND_FALSE:%.*]]
+// CHECK:   cond.true:
+// CHECK-NEXT:call void @llvm.trap()
+// CHECK-NEXT:br label [[COND_END:%.*]]
+// CHECK:   cond.false:
+// CHECK-NEXT:br label [[COND_END]]
+// CHECK:   cond.end:
+// CHECK-NEXT:[[CALL1:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL1]], label [[COND_TRUE2:%.*]], label [[COND_FALSE3:%.*]]
+// CHECK:   cond.true2:
+// CHECK-NEXT:call void @llvm.debugtrap()
+// CHECK-NEXT:br label [[COND_END4:%.*]]
+// CHECK:   cond.false3:
+// CHECK-NEXT:br label [[COND_END4]]
+// CHECK:   cond.end4:
+// CHECK-NEXT:[[CALL5:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:[[TMP0:%.*]] = zext i1 [[CALL5]] to i64
+// CHECK-NEXT:call void @llvm.assume(i1 true)
+// CHECK-NEXT:[[CALL6:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL6]], label [[COND_TRUE7:%.*]], label [[COND_FALSE8:%.*]]
+// CHECK:   cond.true7:
+// CHECK-NEXT:[[ARRAYDECAY:%.*]] = getelementptr inbounds [1 x %struct.__va_list_tag], ptr [[L]], i64 0, i64 0
+// CHECK-NEXT:call void @llvm.va_start(ptr [[ARRAYDECAY]])
+// CHECK-NEXT:br label [[COND_END9:%.*]]
+// CHECK:   cond.false8:
+// CHECK-NEXT:br label [[COND_END9]]
+// CHECK:   cond.end9:
+// CHECK-NEXT:[[CALL10:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL10]], label [[COND_TRUE11:%.*]], label [[COND_FALSE14:%.*]]
+// CHECK:   cond.true11:
+// CHECK-NEXT:[[ARRAYDECAY12:%.*]] = getelementptr inbounds [1 x %struct.__va_list_tag], ptr [[L]], i64 0, i64 0
+// CHECK-NEXT:[[ARRAYDECAY13:%.*]] = getelementptr inbounds [1 x %struct.__va_list_tag], ptr [[L2]], i64 0, i64 0
+// CHECK-NEXT:call void @llvm.va_copy(ptr [[ARRAYDECAY12]], ptr [[ARRAYDECAY13]])
+// CHECK-NEXT:br label [[COND_END15:%.*]]
+// CHECK:   cond.false14:
+// CHECK-NEXT:br label [[COND_END15]]
+// CHECK:   cond.end15:
+// CHECK-NEXT:[[CALL16:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL16]], label [[COND_TRUE17:%.*]], label [[COND_FALSE18:%.*]]
+// CHECK:   cond.true17:
+// CHECK-NEXT:[[TMP1:%.*]] = load ptr, ptr [[P_ADDR]], align 8
+// CHECK-NEXT:call void @llvm.prefetch.p0(ptr [[TMP1]], i32 0, i32 3, i32 1)
+// CHECK-NEXT:br label [[COND_END19:%.*]]
+// CHECK:   cond.false18:
+// CHECK-NEXT:br label [[COND_END19]]
+// CHECK:   cond.end19:
+// CHECK-NEXT:[[CALL20:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:br i1 [[CALL20]], label [[COND_TRUE21:%.*]], label [[COND_FALSE22:%.*]]
+// CHECK:   cond.true21:
+// CHECK-NEXT:call void @llvm.eh.unwind.init()
+// CHECK-NEXT:br label [[COND_END23:%.*]]
+// CHECK:   cond.false22:
+// CHECK-NEXT:br label [[COND_END23]]
+// CHECK:   cond.end23:
+// CHECK-NEXT:[[CALL24:%.*]] = call noundef zeroext i1 @_Z1ev()
+// CHECK-NEXT:[[TMP2:%.*]] = zext i1 [[CALL24]] to i64
+// CHECK-NEXT:[[TMP3:%.*]] = load ptr, ptr [[P_ADDR]], align 8
+// CHECK-NEXT:call void @_ZdlPv(ptr noundef [[TMP3]]) #[[ATTR8:[0-9]+]]
+// CHECK-NEXT:ret void
+//
+void f(int* p, ...)
+{
+  e() ? __builtin_trap() : void();
+  e() ? __builtin_debugtrap() : void();
+  e() ? __builtin_assume(true) : void();
+  __builtin_va_list l;
+  e() ? __builtin_va_start(l, p) : void();
+  __builtin_va_list l2;
+  e() ? __builtin_va_copy(l, l2) : void();
+  e() ? __builtin_prefetch(p) : void();
+  e() ? __builtin_unwind_init() : void();
+  e() ? __builtin_operator_delete(p) : void();
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -467,6 +467,9 @@
 return

[PATCH] D112049: [ObjC] avoid crashing when emitting synthesized getter/setter and ptrdiff_t is smaller than long

2022-10-24 Thread Matt Jacobson via Phabricator via cfe-commits

mhjacobson added a comment.

Hello, and sorry for the delay.

The blocking bug was fixed by D112113 .  This 
is ready for review.  Please let me know if you have any feedback.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112049

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

[PATCH] D136162: [analyzer] Fix assertion failure with conflicting prototype calls

2022-10-24 Thread Balázs Benics via Phabricator via cfe-commits

steakhal marked 2 inline comments as done.
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:490
+// edge-cases.
+ArgVal = castArgToParamTypeIfNeeded(Call, Idx, ArgVal, SVB);
+

steakhal wrote:
> tomasz-kaminski-sonarsource wrote:
> > Previously we didng make bindings if `ArgVal` was unknown, and we may want 
> > to preserve this invariant.
> IDK what are the implications of not having a binding or having a binding to 
> unknown.
> I'll change this anyway. Thanks for noticing.
Hm, I tried to move the `unknown` check after the cast. It would result in a 
difference in the last example:
```lang=C++
void c(); // expected-warning {{a function declaration without a prototype is 
deprecated in all versions of C and is treated as a zero-parameter prototype in 
C2x, conflicting with a subsequent definition}}
void missingPrototypeCallsiteMismatchingArgsAndParams() {
  // expected-warning@+1 {{passing arguments to 'c' without a prototype is 
deprecated in all versions of C and is not supported in C2x}}
  c(&buffer, &buffer);
}
void c(int *c) { // expected-note {{conflicting prototype is here}}
  clang_analyzer_dump(c); // ???
  *c = 42; // no-crash
}
```
The `clang_analyzer_dump(c)` would result in `&SymRegion{reg_$0}` 
instead of `Unknown`.
Which is not exactly what I want. I want to bind `Unknown` in case the cast 
would result in `Unknown` or some weird parameter passing is detected, what we 
don't want to support/model, such as mismatching number of arguments & 
parameters, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136162

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

[clang] f8b8426 - [RISCV] Add Svnapot extension

2022-10-24 Thread Piyou Chen via cfe-commits


Author: Piyou Chen
Date: 2022-10-24T01:27:04-07:00
New Revision: f8b8426861a7a26ff60fe085800cc338591bee41

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

LOG: [RISCV] Add Svnapot extension

Reviewed By: kito-cheng

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

Added: 


Modified: 
clang/test/Preprocessor/riscv-target-features.c
llvm/lib/Support/RISCVISAInfo.cpp
llvm/lib/Target/RISCV/RISCV.td
llvm/lib/Target/RISCV/RISCVSubtarget.h
llvm/test/CodeGen/RISCV/attributes.ll

Removed: 




diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index c1c29da5e18b0..725d722bfc952 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -39,6 +39,7 @@
 // CHECK-NOT: __riscv_zk
 // CHECK-NOT: __riscv_zicbom
 // CHECK-NOT: __riscv_zicboz
+// CHECK-NOT: __riscv_svnapot
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32im -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-M-EXT %s
@@ -418,3 +419,9 @@
 // RUN: -march=rv64iztso0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZTSO-EXT %s
 // CHECK-ZTSO-EXT: __riscv_ztso 1000{{$}}
+
+// RUN: %clang -target riscv32 -march=rv32isvnapot -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SVNAPOT-EXT %s
+// RUN: %clang -target riscv64 -march=rv64isvnapot -x c -E -dM %s \
+// RUN: -o - | FileCheck --check-prefix=CHECK-SVNAPOT-EXT %s
+// CHECK-SVNAPOT-EXT: __riscv_svnapot 100{{$}}

diff  --git a/llvm/lib/Support/RISCVISAInfo.cpp 
b/llvm/lib/Support/RISCVISAInfo.cpp
index 9cf7e04713655..ff5f1d7475189 100644
--- a/llvm/lib/Support/RISCVISAInfo.cpp
+++ b/llvm/lib/Support/RISCVISAInfo.cpp
@@ -101,6 +101,8 @@ static const RISCVSupportedExtension SupportedExtensions[] 
= {
 {"zicbom", RISCVExtensionVersion{1, 0}},
 {"zicboz", RISCVExtensionVersion{1, 0}},
 {"zicbop", RISCVExtensionVersion{1, 0}},
+
+{"svnapot", RISCVExtensionVersion{1, 0}},
 };
 
 static const RISCVSupportedExtension SupportedExperimentalExtensions[] = {

diff  --git a/llvm/lib/Target/RISCV/RISCV.td b/llvm/lib/Target/RISCV/RISCV.td
index 822b2c44c2309..a5c9f97d68a34 100644
--- a/llvm/lib/Target/RISCV/RISCV.td
+++ b/llvm/lib/Target/RISCV/RISCV.td
@@ -388,6 +388,10 @@ def HasStdExtZicbop : 
Predicate<"Subtarget->hasStdExtZicbop()">,
 AssemblerPredicate<(all_of 
FeatureStdExtZicbop),
 "'Zicbop' (Cache-Block Prefetch 
Instructions)">;
 
+def FeatureStdExtSvnapot
+: SubtargetFeature<"svnapot", "HasStdExtSvnapot", "true",
+   "'Svnapot' (NAPOT Translation Contiguity)">;
+
 def FeatureStdExtZtso
 : SubtargetFeature<"experimental-ztso", "HasStdExtZtso", "true",
"'Ztso' (Memory Model - Total Store Order)">;

diff  --git a/llvm/lib/Target/RISCV/RISCVSubtarget.h 
b/llvm/lib/Target/RISCV/RISCVSubtarget.h
index 89fb7cb212a87..f0980ea08e081 100644
--- a/llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ b/llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -85,6 +85,7 @@ class RISCVSubtarget : public RISCVGenSubtargetInfo {
   bool HasStdExtZicbom = false;
   bool HasStdExtZicboz = false;
   bool HasStdExtZicbop = false;
+  bool HasStdExtSvnapot = false;
   bool HasStdExtZmmul = false;
   bool HasStdExtZawrs = false;
   bool HasStdExtZtso = false;
@@ -182,6 +183,7 @@ class RISCVSubtarget : public RISCVGenSubtargetInfo {
   bool hasStdExtZicbom() const { return HasStdExtZicbom; }
   bool hasStdExtZicboz() const { return HasStdExtZicboz; }
   bool hasStdExtZicbop() const { return HasStdExtZicbop; }
+  bool hasStdExtSvnapot() const { return HasStdExtSvnapot; }
   bool hasStdExtZawrs() const { return HasStdExtZawrs; }
   bool hasStdExtZmmul() const { return HasStdExtZmmul; }
   bool hasStdExtZtso() const { return HasStdExtZtso; }

diff  --git a/llvm/test/CodeGen/RISCV/attributes.ll 
b/llvm/test/CodeGen/RISCV/attributes.ll
index 4136c6f37a16e..45dd8679292d5 100644
--- a/llvm/test/CodeGen/RISCV/attributes.ll
+++ b/llvm/test/CodeGen/RISCV/attributes.ll
@@ -36,6 +36,7 @@
 ; RUN: llc -mtriple=riscv32 -mattr=+zicbom %s -o - | FileCheck 
--check-prefix=RV32ZICBOM %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zicboz %s -o - | FileCheck 
--check-prefix=RV32ZICBOZ %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zicbop %s -o - | FileCheck 
--check-prefix=RV32ZICBOP %s
+; RUN: llc -mtriple=riscv32 -mattr=+svnapot %s -o - | FileCheck 
--check-prefix=RV32SVNAPOT %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m %s -o - | FileCheck --check-prefix=RV64M 
%s
 ; RUN: llc -mtriple=riscv64 -mattr=+zmmul %s -o - | FileCheck 
--check-prefix=RV64ZMMUL %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m,+zmmul %s -o - | FileCheck 
--check-prefix=R

[PATCH] D136080: [flang] Add -ffp-contract option processing

2022-10-24 Thread Andrzej Warzynski via Phabricator via cfe-commits

awarzynski added inline comments.



Comment at: clang/include/clang/Driver/Options.td:1926
+  " Default is 'fast' for CUDA, 'fast-honor-pragmas' for HIP, 'off' for flang, 
and 'on' otherwise.">,
+  HelpText<"Form fused FP ops (e.g. FMAs): fast | off (clang, flang), on | 
fast-honor-pragmas (clang only)">,
   Values<"fast,on,off,fast-honor-pragmas">;

As far as users are concerned, `flang-new` is just a Fortran compiler. Once we 
start adding references to Clang in `flang-new --help`, we might be confusing 
users (i.e. where's the boundary between Clang and Flang?) and exposing 
implementation details (i.e. that `flang-new` is implemented using 
`clangDriver`). Ideally we should avoid that.



Comment at: flang/include/flang/Frontend/LangOptions.h:29
+
+// Enable the floating point pragma
+FPM_On,

tblah wrote:
> vzakhari wrote:
> > tblah wrote:
> > > vzakhari wrote:
> > > > tblah wrote:
> > > > > awarzynski wrote:
> > > > > > What are these pragmas? Perhaps you can add a test that would 
> > > > > > include them?
> > > > > I copied this comment from clang. I believe the pragma is 
> > > > > ```
> > > > > #pragma clang fp contract(fast)
> > > > > ```
> > > > > 
> > > > > See 
> > > > > https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags
> > > > > 
> > > > > This patch only adds support for argument processing, so I can't test 
> > > > > for the pragmas.
> > > > I do not think we should blindly copy this from clang.  I believe 
> > > > `-ffp-contract=on`  is there to do the contraction complying to the 
> > > > language standard - but Fortran standard says nothing about 
> > > > contraction.  I am also not aware about a Fortran compiler that 
> > > > supports directives related to contraction, so `fast-honor-pragmas` 
> > > > does not seem to be applicable as well.  Basically, we end up with just 
> > > > `off` and `fast`.
> > > > 
> > > > Now, it may be reasonable to support the same `-ffp-contract=` 
> > > > arguments so that users can apply the same options sets for C/C++ and 
> > > > Fortran compilations.  If we want to do this, we need to map `on` and 
> > > > `fast-honor-pragmas` to something, e.g. `fast`.  A driver warning (not 
> > > > an error) may be useful to make the option's behavior clear when `on` 
> > > > and `fast-honor-pragmas` are passed.
> > > From the clang help text:
> > > ```
> > > Form fused FP ops (e.g. FMAs):
> > > fast (fuses across statements disregarding pragmas)
> > > | on (only fuses in the same statement unless dictated by pragmas)
> > > | off (never fuses)
> > > Default is 'on'
> > > ```
> > > 
> > > So if we removed `on` and set the default to `off` we would no longer 
> > > fuse within the same statement by default.
> > > 
> > > Classic-flang seems to support `on`, `off` and `fast`: 
> > > https://github.com/flang-compiler/flang/blob/master/test/llvm_ir_correct/fma.f90
> > Not talking about defaults just yet, I think Flang cannot currently support 
> > the `on` mode as documented.
> > 
> > I do not have the latest classic flang readily availalbe, but I am curious 
> > what it will generate for this example:
> > ```
> > function fn(x,y,z)
> >   real :: x,y,z
> >   fn = x * y
> >   fn = fn + z
> > end function
> > ```
> > 
> > With a very old classic flang I get just `fast` math flags on the multiple 
> > and add instructions, which is obviously not what `on` is supposed to do:
> > ```
> > $ flang -target aarch64-linux-gnu -O1 -c -S -emit-llvm -ffp-contract=on 
> > fma.f90
> > $ cat fma.ll
> >   %4 = fmul fast float %3, %1, !dbg !10
> >   %5 = bitcast i64* %z to float*, !dbg !11
> >   %6 = load float, float* %5, align 4, !dbg !11
> >   %7 = fadd fast float %6, %4, !dbg !11
> > ```
> > 
> > Maybe the latest classic flang does support it properly, e.g. it only 
> > contracts operations from the same statement.  But I do not see a way to 
> > support this in Flang right now, so documenting the `on` mode as it is in 
> > clang seems confusing.
> > 
> > We can still support `on` in the Flang option, but I think we need to issue 
> > a warning saying that it defaults to something else, e.g. to `fast`.  If 
> > mapping `on` to `fast` is not appropriate to some users, then they will 
> > have to explicitly specify `-ffp-contract=off` for Fortran compilations in 
> > their build system.
> > 
> > I am also curious what `fuses in the same statement` means for Fortran.  
> > For example:
> > ```
> >   x1 = DOT_PRODUCT(x2, x3)+x4*x5+x6
> > ```
> > 
> > If Fortran processor decides to implement `DOT_PRODUCT` as inline 
> > multiply+add loop, does `-ffp-contract=on` apply to them or it only applies 
> > to `x4*x5+x6`?
> Thanks for your feedback.
> 
> I've updated my patch. Now flang only supports `off` and `fast`. The other 
> two map to `fast` and we default to `off`.
> 
> gfortran seems to default to `fast`:
> ```
> -ffp-contract=style
> 
> -ffp-contract=off disables flo

[PATCH] D136570: [RISCV] Add Svnapot extension

2022-10-24 Thread Piyou Chen via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf8b8426861a7: [RISCV] Add Svnapot extension (authored by 
BeMg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136570

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

Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -36,6 +36,7 @@
 ; RUN: llc -mtriple=riscv32 -mattr=+zicbom %s -o - | FileCheck --check-prefix=RV32ZICBOM %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zicboz %s -o - | FileCheck --check-prefix=RV32ZICBOZ %s
 ; RUN: llc -mtriple=riscv32 -mattr=+zicbop %s -o - | FileCheck --check-prefix=RV32ZICBOP %s
+; RUN: llc -mtriple=riscv32 -mattr=+svnapot %s -o - | FileCheck --check-prefix=RV32SVNAPOT %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m %s -o - | FileCheck --check-prefix=RV64M %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zmmul %s -o - | FileCheck --check-prefix=RV64ZMMUL %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m,+zmmul %s -o - | FileCheck --check-prefix=RV64MZMMUL %s
@@ -72,6 +73,7 @@
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbom %s -o - | FileCheck --check-prefix=RV64ZICBOM %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicboz %s -o - | FileCheck --check-prefix=RV64ZICBOZ %s
 ; RUN: llc -mtriple=riscv64 -mattr=+zicbop %s -o - | FileCheck --check-prefix=RV64ZICBOP %s
+; RUN: llc -mtriple=riscv64 -mattr=+svnapot %s -o - | FileCheck --check-prefix=RV64SVNAPOT %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zawrs %s -o - | FileCheck --check-prefix=RV64ZAWRS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-ztso %s -o - | FileCheck --check-prefix=RV64ZTSO %s
 
@@ -111,6 +113,7 @@
 ; RV32ZICBOM: .attribute 5, "rv32i2p0_zicbom1p0"
 ; RV32ZICBOZ: .attribute 5, "rv32i2p0_zicboz1p0"
 ; RV32ZICBOP: .attribute 5, "rv32i2p0_zicbop1p0"
+; RV32SVNAPOT: .attribute 5, "rv32i2p0_svnapot1p0"
 
 ; RV64M: .attribute 5, "rv64i2p0_m2p0"
 ; RV64ZMMUL: .attribute 5, "rv64i2p0_zmmul1p0"
@@ -149,6 +152,7 @@
 ; RV64ZICBOZ: .attribute 5, "rv64i2p0_zicboz1p0"
 ; RV64ZAWRS: .attribute 5, "rv64i2p0_zawrs1p0"
 ; RV64ZICBOP: .attribute 5, "rv64i2p0_zicbop1p0"
+; RV64SVNAPOT: .attribute 5, "rv64i2p0_svnapot1p0"
 ; RV64ZTSO: .attribute 5, "rv64i2p0_ztso0p1"
 
 define i32 @addi(i32 %a) {
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -85,6 +85,7 @@
   bool HasStdExtZicbom = false;
   bool HasStdExtZicboz = false;
   bool HasStdExtZicbop = false;
+  bool HasStdExtSvnapot = false;
   bool HasStdExtZmmul = false;
   bool HasStdExtZawrs = false;
   bool HasStdExtZtso = false;
@@ -182,6 +183,7 @@
   bool hasStdExtZicbom() const { return HasStdExtZicbom; }
   bool hasStdExtZicboz() const { return HasStdExtZicboz; }
   bool hasStdExtZicbop() const { return HasStdExtZicbop; }
+  bool hasStdExtSvnapot() const { return HasStdExtSvnapot; }
   bool hasStdExtZawrs() const { return HasStdExtZawrs; }
   bool hasStdExtZmmul() const { return HasStdExtZmmul; }
   bool hasStdExtZtso() const { return HasStdExtZtso; }
Index: llvm/lib/Target/RISCV/RISCV.td
===
--- llvm/lib/Target/RISCV/RISCV.td
+++ llvm/lib/Target/RISCV/RISCV.td
@@ -388,6 +388,10 @@
 AssemblerPredicate<(all_of FeatureStdExtZicbop),
 "'Zicbop' (Cache-Block Prefetch Instructions)">;
 
+def FeatureStdExtSvnapot
+: SubtargetFeature<"svnapot", "HasStdExtSvnapot", "true",
+   "'Svnapot' (NAPOT Translation Contiguity)">;
+
 def FeatureStdExtZtso
 : SubtargetFeature<"experimental-ztso", "HasStdExtZtso", "true",
"'Ztso' (Memory Model - Total Store Order)">;
Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISCVISAInfo.cpp
@@ -101,6 +101,8 @@
 {"zicbom", RISCVExtensionVersion{1, 0}},
 {"zicboz", RISCVExtensionVersion{1, 0}},
 {"zicbop", RISCVExtensionVersion{1, 0}},
+
+{"svnapot", RISCVExtensionVersion{1, 0}},
 };
 
 static const RISCVSupportedExtension SupportedExperimentalExtensions[] = {
Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -39,6 +39,7 @@
 // CHECK-NOT: __riscv_zk
 // CHECK-NOT: __riscv_zicbom
 // CHECK-NOT: __riscv_zicboz
+// CHECK-NOT: __riscv_svnapot
 
 // RUN: %clang -targe

[PATCH] D136533: Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

2022-10-24 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov added a comment.

@philnik it seems that didn't work. It seems those pipelines are already 
running clang-16, according to the cmake logs, they are just not bootstrapping 
with this patch.

So gating this on clang version will not work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D135933: [X86] Add CMPCCXADD instructions.

2022-10-24 Thread Kan Shengchen via Phabricator via cfe-commits

skan added inline comments.



Comment at: llvm/lib/Target/X86/MCTargetDesc/X86InstPrinterCommon.cpp:32
   int64_t Imm = MI->getOperand(Op).getImm();
+  bool flavor = MI->getOpcode() == X86::CMPCCXADDmr32 || X86::CMPCCXADDmr64;
   switch (Imm) {

Capitalize 1st char



Comment at: llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1453-1455
+emitMemModRMByte(MI, CurOp + 1, getX86RegNum(MI.getOperand(0)), TSFlags,
+ HasREX, StartByte, OS, Fixups, STI, false);
+CurOp = SrcRegNum + 3; // skip VEX_V4 and CC

Minor suggestion

```
emitMemModRMByte(MI, ++CurOp, getX86RegNum(MI.getOperand(0)), TSFlags,
 HasREX, StartByte, OS, Fixups, STI, false);
CurOp = SrcRegNum + 2; // skip VEX_V4 and CC
```
would be more clear b/c you use "skip VEX_V4 and CC" in the comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135933

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

[PATCH] D135933: [X86] Add CMPCCXADD instructions.

2022-10-24 Thread Phoebe Wang via Phabricator via cfe-commits

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

LGTM.




Comment at: llvm/lib/Target/X86/X86InstrInfo.td:3024
+//
+let Predicates = [HasCMPCCXADD, In64BitMode], Defs = [EFLAGS],
+Constraints = "$dstsrc2 = $dst" in {

skan wrote:
> Should we set isCodeGenOnly =1 here?
Should also set `mayLoad` and `mayStore`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135933

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

[PATCH] D135933: [X86] Add CMPCCXADD instructions.

2022-10-24 Thread Kan Shengchen via Phabricator via cfe-commits

skan added inline comments.



Comment at: llvm/lib/Target/X86/X86InstrInfo.td:3027
+def CMPCCXADDmr32 : I<0xe0, MRMDestMem4VOp3CC, (outs GR32:$dst),
+  (ins GR32:$dstsrc2, i32mem:$dstsrc1, GR32:$src3, ccode:$cond),
+  "cmp${cond}xadd\t{$src3, $dst, $dstsrc1|$dstsrc1, $dst, $src3}",

Could you use "GR32:$dstsrc1, i32mem:$dstsrc2" instead?



Comment at: llvm/lib/Target/X86/X86InstrInfo.td:3024
+//
+let Predicates = [HasCMPCCXADD, In64BitMode], Defs = [EFLAGS],
+Constraints = "$dstsrc2 = $dst" in {

pengfei wrote:
> skan wrote:
> > Should we set isCodeGenOnly =1 here?
> Should also set `mayLoad` and `mayStore`?
Yeah, I think so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135933

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

[PATCH] D133756: [clangd] Introduce CompileCommandsAdjuster

2022-10-24 Thread Nathan Ridge via Phabricator via cfe-commits

nridge updated this revision to Diff 470083.
nridge marked 4 inline comments as done.
nridge added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133756

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/CompileCommands.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/indexer/IndexerMain.cpp
  clang-tools-extra/clangd/tool/Check.cpp
  clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
  clang-tools-extra/clangd/unittests/ClangdTests.cpp
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
  clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
  clang-tools-extra/clangd/unittests/TestTU.cpp

Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -64,7 +64,7 @@
   Argv.push_back(FullFilename);
 
   auto Mangler = CommandMangler::forTests();
-  Mangler.adjust(Inputs.CompileCommand.CommandLine, FullFilename);
+  Mangler(Inputs.CompileCommand, FullFilename);
   Inputs.CompileCommand.Filename = FullFilename;
   Inputs.CompileCommand.Directory = testRoot();
   Inputs.Contents = Code;
Index: clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
===
--- clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
+++ clang-tools-extra/clangd/unittests/GlobalCompilationDatabaseTests.cpp
@@ -138,11 +138,9 @@
 
 TEST_F(OverlayCDBTest, Adjustments) {
   OverlayCDB CDB(Base.get(), {"-DFallback"},
- [](const std::vector &Cmd, llvm::StringRef File) {
-   auto Ret = Cmd;
-   Ret.push_back(
+ [](tooling::CompileCommand &Cmd, llvm::StringRef File) {
+   Cmd.CommandLine.push_back(
("-DAdjust_" + llvm::sys::path::filename(File)).str());
-   return Ret;
  });
   // Command from underlying gets adjusted.
   auto Cmd = *CDB.getCompileCommand(testPath("foo.cc"));
Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -45,41 +45,47 @@
   Mangler.ClangPath = testPath("fake/clang");
   Mangler.ResourceDir = testPath("fake/resources");
   Mangler.Sysroot = testPath("fake/sysroot");
-  std::vector Cmd = {"clang++", "--", "foo.cc", "bar.cc"};
-  Mangler.adjust(Cmd, "foo.cc");
-  EXPECT_THAT(Cmd, ElementsAre(testPath("fake/clang++"),
-   "-resource-dir=" + testPath("fake/resources"),
-   "-isysroot", testPath("fake/sysroot"), "--",
-   "foo.cc"));
+  tooling::CompileCommand Cmd;
+  Cmd.CommandLine = {"clang++", "--", "foo.cc", "bar.cc"};
+  Mangler(Cmd, "foo.cc");
+  EXPECT_THAT(Cmd.CommandLine,
+  ElementsAre(testPath("fake/clang++"),
+  "-resource-dir=" + testPath("fake/resources"),
+  "-isysroot", testPath("fake/sysroot"), "--",
+  "foo.cc"));
 }
 
 TEST(CommandMangler, FilenameMismatch) {
   auto Mangler = CommandMangler::forTests();
   Mangler.ClangPath = testPath("clang");
   // Our compile flags refer to foo.cc...
-  std::vector Cmd = {"clang", "foo.cc"};
+  tooling::CompileCommand Cmd;
+  Cmd.CommandLine = {"clang", "foo.cc"};
   // but we're applying it to foo.h...
-  Mangler.adjust(Cmd, "foo.h");
+  Mangler(Cmd, "foo.h");
   // so transferCompileCommand should add -x c++-header to preserve semantics.
-  EXPECT_THAT(
-  Cmd, ElementsAre(testPath("clang"), "-x", "c++-header", "--", "foo.h"));
+  EXPECT_THAT(Cmd.CommandLine, ElementsAre(testPath("clang"), "-x",
+   "c++-header", "--", "foo.h"));
 }
 
 TEST(CommandMangler, ResourceDir) {
   auto Mangler = CommandMangler::forTests();
   Mangler.ResourceDir = testPath("fake/resources");
-  std::vector Cmd = {"clang++", "foo.cc"};
-  Mangler.adjust(Cmd, "foo.cc");
-  EXPECT_THAT(Cmd, Contains("-resource-dir=" + testPath("fake/resources")));
+  tooling::CompileCommand Cmd;
+  Cmd.CommandLine = {"clang++", "foo.cc"};
+  Mangler(Cmd, "foo.cc");
+  EXPECT_THAT(Cmd.CommandLine,
+  Contains("-resource-dir=" + testPath("fake/resources")));
 }
 
 TEST(CommandMangler, Sysroot) {
   auto Mangler = CommandMangler::forTests();
   Mangler.Sysroot = testPath("fake/sysroot");
 
-  std::vector Cmd = {"clang++", "foo.cc"};
-  Mangler.adjust(Cmd, "foo.cc");
-  EXPECT_

[PATCH] D133756: [clangd] Introduce CompileCommandsAdjuster

2022-10-24 Thread Nathan Ridge via Phabricator via cfe-commits

nridge added a comment.

(apologies, I'm also very tardy in getting back to this...)




Comment at: clang-tools-extra/clangd/GlobalCompilationDatabase.h:165
+// process a file (possibly different from the one in the command).
+class CompileCommandsAdjuster {
+public:

sammccall wrote:
> nridge wrote:
> > nridge wrote:
> > > sammccall wrote:
> > > > I have a couple of concerns with this interface:
> > > >  - we seem to be stretching to cover {mangler, querydriver} with one 
> > > > interface, but there's no particular reason to - we never use it 
> > > > polymorphically.
> > > >  - the contract is very vague. If it's just "mutate flags" then some 
> > > > sort of generic `function` seems sufficient
> > > >  - `File` feels out-of-place - it's purely an input for the mangler. If 
> > > > query-driver needs an extra input, will we add that too?
> > > >  - either `CompileCommand` or filename+argv seems reasonable, providing 
> > > > CompileCommand+argv is confusing. 
> > > >  - the name is hard to distinguish from tooling::ArgumentsAdjuster 
> > > > (which is a bad interface)
> > > > 
> > > > The immediate problem being solved is the type of 
> > > > CommandMangler::SystemIncludeExtractor, right?
> > > > Can that just be `unique_function&, StringRef)>` or 
> > > > so? Possibly behind `using SystemIncludeExtractor = ...`.
> > > It's more that `QueryDriverDatabase` 
> > > [uses](https://searchfox.org/llvm/rev/f213128b292da85f68eeebbb68cba1541e1c39e2/clang-tools-extra/clangd/QueryDriverDatabase.cpp#354)
> > >  the `Directory` field of `tooling::CompileCommand` in addition to the 
> > > arguments.
> > > 
> > > We could add the directory as another argument to the function, but at 
> > > that point why not group the arguments into `tooling::CompileCommand` 
> > > which is more semantically meaningful?
> > > 
> > > As for polymorphism vs. `unique_function`, I don't feel strongly about 
> > > that, happy to change that up. (I do find `function` more annoying to 
> > > debug because `step into` at a call site in the debugger steps into some 
> > > hard-to-read library code, but that's probably better solved at the 
> > > debugger tooling level.)
> > Forgot to mention one other subtlety here: because `QueryDriverDatabase` 
> > needs to operate on a `tooling::CompileCommand`, the interface between 
> > `CommandMangler` and `OverlayCDB` needs to be widened to accommodate 
> > passing a `tooling::CompileCommand`, i.e. it can't be `ArgumentsAdjuster` 
> > any more.
> > 
> > This is why I reused `CompileCommandsAdjuster` as the type used to pass 
> > `CommandMangler` to `OverlayCDB`, and the type used to pass 
> > `SystemIncludeExtractor` to `CommandMangler`. It's not used 
> > //polymorphically//, we just need an interface that can accept a 
> > `CompileCommand` in both places; they could be two different types if we 
> > prefer.
> > It's more that QueryDriverDatabase uses the Directory field of 
> > tooling::CompileCommand in addition to the arguments.
> 
> Yes, that makes sense - my concern is providing **two** filenames the query 
> driver database, which needs none. The first one is semantically clear and 
> the function could potentially use it. The second one is completely 
> meaningless though.
> 
> > the interface between CommandMangler and OverlayCDB needs to be widened to 
> > accommodate passing a tooling::CompileCommand
> 
> Right. IIUC the reason we're using these abstract types (as opposed to 
> directly using CommandMangler and some concrete SystemIncludeExtractor) is 
> dependency injection: we don't want OverlayCDB to depend on CommandMangler, 
> or CommandMangler to depend on SystemIncludeExtractor.
> 
> For DI, I think we should specify these types independently where they're 
> consumed, i.e.
> ```
> class OverlayCDB {
>   using CommandMangler = unique_function NewFilename)>;
>   OverlayCDB(..., CommandMangler M = nullptr);
> }
> ```
> This avoids spurious dependencies in the *other* direction (e.g. 
> CommandMangler should not have to depend on OverlayCDB).
> We don't give readers the impression that mangler & extractor are 
> interchangeable somehow.
> And things needed by one (e.g if CommandMangler needs 6 more filename 
> params!) needn't affect the other.
> 
> (I violated all these ideas in reusing tooling::ArgumentsAdjuster here, it 
> was a mistake)
> 
> Ack on the debugger/stacktrace problems with type-erased functions though, I 
> wish I had a good answer.
> my concern is providing two filenames the query driver database, which needs 
> none

QueryDriverDatabase does in fact use "TargetFile", 
[here](https://searchfox.org/llvm/rev/016c83047f6ffdca8e83176733e5777176702e79/clang-tools-extra/clangd/QueryDriverDatabase.cpp#340).

Based on the 
[usage](https://searchfox.org/llvm/rev/016c83047f6ffdca8e83176733e5777176702e79/clang-tools-extra/clangd/GlobalCompilationDatabase.cpp#757,761)
 in `OverlayCDB::getCompileCommands()`, I don't think we can assume that the 
`File

[PATCH] D136336: [clang-format] Mark pragma region lines as StringLiterals

2022-10-24 Thread Tobias Hieta via Phabricator via cfe-commits

thieta updated this revision to Diff 470092.
thieta added a comment.

Added TokenAnnotatorTest and removed reduntant FormatTests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136336

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


Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -6,6 +6,7 @@
 //
 
//===--===//
 
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Format/Format.h"
 
 #include "FormatTestUtils.h"
@@ -649,6 +650,23 @@
   EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_RequiresExpressionLBrace);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsPragmaRegion) {
+  // Everything after #pragma region should be ImplicitStringLiteral
+  auto Tokens = annotate("#pragma region Foo(Bar: Hello)");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[5], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[6], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[7], tok::identifier, TT_ImplicitStringLiteral);
+
+  // Make sure it's annotated correctly inside a function as well
+  Tokens = annotate("void test(){\n#pragma region Foo(Bar: Hello)\n}");
+  ASSERT_EQ(Tokens.size(), 16u) << Tokens;
+  EXPECT_TOKEN(Tokens[10], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[11], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[12], tok::identifier, TT_ImplicitStringLiteral);
+
+}
+
 TEST_F(TokenAnnotatorTest, RequiresDoesNotChangeParsingOfTheRest) {
   const char *BaseCode = nullptr;
   const char *ConstrainedCode = nullptr;
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -19965,9 +19965,7 @@
 TEST_F(FormatTest, UnderstandPragmaRegion) {
   auto Style = getLLVMStyleWithColumns(0);
   verifyFormat("#pragma region TEST(FOO : BAR)", Style);
-
-  EXPECT_EQ("#pragma region TEST(FOO : BAR)",
-format("#pragma region TEST(FOO : BAR)", Style));
+  verifyFormat("#pragma region TEST(FOO: NOSPACE)", Style);
 }
 
 TEST_F(FormatTest, OptimizeBreakPenaltyVsExcess) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1337,11 +1337,11 @@
 if (CurrentToken &&
 CurrentToken->isOneOf(Keywords.kw_mark, Keywords.kw_option,
   Keywords.kw_region)) {
-  bool IsMark = CurrentToken->is(Keywords.kw_mark);
+  bool IsMarkOrRegion = CurrentToken->isOneOf(Keywords.kw_mark, 
Keywords.kw_region);
   next();
   next(); // Consume first token (so we fix leading whitespace).
   while (CurrentToken) {
-if (IsMark || CurrentToken->Previous->is(TT_BinaryOperator))
+if (IsMarkOrRegion || CurrentToken->Previous->is(TT_BinaryOperator))
   CurrentToken->setType(TT_ImplicitStringLiteral);
 next();
   }


Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -6,6 +6,7 @@
 //
 //===--===//
 
+#include "clang/Basic/TokenKinds.h"
 #include "clang/Format/Format.h"
 
 #include "FormatTestUtils.h"
@@ -649,6 +650,23 @@
   EXPECT_TOKEN(Tokens[14], tok::l_brace, TT_RequiresExpressionLBrace);
 }
 
+TEST_F(TokenAnnotatorTest, UnderstandsPragmaRegion) {
+  // Everything after #pragma region should be ImplicitStringLiteral
+  auto Tokens = annotate("#pragma region Foo(Bar: Hello)");
+  ASSERT_EQ(Tokens.size(), 10u) << Tokens;
+  EXPECT_TOKEN(Tokens[5], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[6], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[7], tok::identifier, TT_ImplicitStringLiteral);
+
+  // Make sure it's annotated correctly inside a function as well
+  Tokens = annotate("void test(){\n#pragma region Foo(Bar: Hello)\n}");
+  ASSERT_EQ(Tokens.size(), 16u) << Tokens;
+  EXPECT_TOKEN(Tokens[10], tok::identifier, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[11], tok::colon, TT_ImplicitStringLiteral);
+  EXPECT_TOKEN(Tokens[12], tok::identifier, TT_ImplicitStringLiteral);
+
+}
+
 TEST_F(TokenAnnotatorTest, RequiresDoesNotChangeParsingOfTheRest) {
   const char *BaseCode = nullptr;
   const char *ConstrainedCode = nullptr;
Index: clang/unittests/Format/FormatTest.cpp
==

[PATCH] D136336: [clang-format] Mark pragma region lines as StringLiterals

2022-10-24 Thread Tobias Hieta via Phabricator via cfe-commits

thieta added a comment.

In D136336#3877238 , @owenpan wrote:

> Can you add a test to `TokenAnnotatorTest.cpp`?

Thanks for the review. Fixed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136336

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

[PATCH] D136337: [clang-format] Discard pre-processor statements in parseBracedList()

2022-10-24 Thread Tobias Hieta via Phabricator via cfe-commits

thieta added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136337

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

[PATCH] D116735: [RISCV] Adjust RISCV data layout by using n32:64 in layout string

2022-10-24 Thread Fraser Cormack via Phabricator via cfe-commits

frasercrmck added a comment.

I agree with @reames, though I do think the patch description could use a 
rewrite.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116735

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

[PATCH] D135932: [X86] Add AVX-IFMA instructions.

2022-10-24 Thread Phoebe Wang via Phabricator via cfe-commits

pengfei added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsX86.def:1335-1338
 TARGET_BUILTIN(__builtin_ia32_vpmadd52huq128, "V2OiV2OiV2OiV2Oi", "ncV:128:", 
"avx512ifma,avx512vl")
 TARGET_BUILTIN(__builtin_ia32_vpmadd52huq256, "V4OiV4OiV4OiV4Oi", "ncV:256:", 
"avx512ifma,avx512vl")
 TARGET_BUILTIN(__builtin_ia32_vpmadd52luq128, "V2OiV2OiV2OiV2Oi", "ncV:128:", 
"avx512ifma,avx512vl")
 TARGET_BUILTIN(__builtin_ia32_vpmadd52luq256, "V4OiV4OiV4OiV4Oi", "ncV:256:", 
"avx512ifma,avx512vl")

Can we unify the builtins like AVXVNNI? e.g., change it to 
`vx512ifma,avx512vl|avxifma`



Comment at: clang/lib/Headers/avxifmaintrin.h:36
+/// __m128i
+/// _mm_madd52hi_avx_epu64 (__m128i __X, __m128i __Y, __m128i __Z)
+/// \endcode

Should we provide unified intrinsic `_mm_madd52hi_epu64` like AVXVNNI?



Comment at: llvm/test/CodeGen/X86/avx-ifma-intrinsics.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+avxifma 
--show-mc-encoding | FileCheck %s --check-prefixes=AVX-X86
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+avxifma 
--show-mc-encoding | FileCheck %s --check-prefixes=AVX-X64

Use `AVX,AVX-X86` etc. to reduce the duplicated check.



Comment at: llvm/test/CodeGen/X86/avx-ifma-intrinsics.ll:22
+; AVX512-X86:   # %bb.0:
+; AVX512-X86-NEXT:vpmadd52huq %xmm2, %xmm1, %xmm0 # encoding: 
[0x62,0xf2,0xf5,0x08,0xb5,0xc2]
+; AVX512-X86-NEXT:retl # encoding: [0xc3]

I think we should expect VEX encoding here with comment `EVEX TO VEX 
Compression encoding`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135932

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

[PATCH] D135953: [IncludeCleaner] Introduce decl to location mapping

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added a comment.

In D135953#3861180 , @tschuett wrote:

> We support Apple Clang 9.3, but `std:variant` ships with Apple Clang 10.0. :-(

Hi @tschuett, there are other pieces of LLVM that use `` today 
already, some big components include TableGen, DenseMap, CodeGen, flang, 
pseudo, MLIR. so i guess LLVM is already non-compilable today on apple clang 
9.3 and someone needs to do a cleanup (i am happy to drop the usage here and in 
my other patches, but it won't prevent others from introducing more usage, so I 
don't see how useful my changes here would be)

I've brought this up in 
https://discourse.llvm.org/t/important-new-toolchain-requirements-to-build-llvm-will-most-likely-be-landing-within-a-week-prepare-your-buildbots/61447/12?u=kadircet.
 Please pile up on that thread if you're a maintainer for that particular 
toolchain, rather than just a concerned citizen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135953

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

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

2022-10-24 Thread Victor Campos via Phabricator via cfe-commits

vhscampos created this revision.
Herald added subscribers: hiraditya, kristof.beyls.
Herald added a project: All.
vhscampos requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Cortex-X3 is an Armv9-A AArch64 CPU.

This patch introduces support for Cortex-X3.

Technical Reference Manual: 
https://developer.arm.com/documentation/101593/latest


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136589

Files:
  clang/docs/ReleaseNotes.rst
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/ReleaseNotes.rst
  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
@@ -1073,6 +1073,18 @@
  AArch64::AEK_SVE2BITPERM | AArch64::AEK_SSBS |
  AArch64::AEK_SB | AArch64::AEK_FP16FML,
  "9-A"),
+ARMCPUTestParams("cortex-x3", "armv9-a", "crypto-neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_FP | AArch64::AEK_BF16 |
+ AArch64::AEK_SIMD | AArch64::AEK_RAS |
+ AArch64::AEK_LSE | AArch64::AEK_RDM |
+ AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+ AArch64::AEK_MTE | AArch64::AEK_PAUTH |
+ AArch64::AEK_SVE | AArch64::AEK_SVE2 |
+ AArch64::AEK_SVE2BITPERM | AArch64::AEK_SB |
+ AArch64::AEK_PROFILE | AArch64::AEK_PERFMON |
+ AArch64::AEK_I8MM | AArch64::AEK_FP16 |
+ AArch64::AEK_FP16FML | AArch64::AEK_PREDRES,
+ "9-A"),
 ARMCPUTestParams("cyclone", "armv8-a", "crypto-neon-fp-armv8",
  AArch64::AEK_NONE | AArch64::AEK_CRYPTO |
  AArch64::AEK_FP | AArch64::AEK_SIMD,
@@ -1295,7 +1307,7 @@
  AArch64::AEK_LSE | AArch64::AEK_RDM,
  "8.2-A")));
 
-static constexpr unsigned NumAArch64CPUArchs = 58;
+static constexpr unsigned NumAArch64CPUArchs = 59;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/lib/Target/AArch64/AArch64Subtarget.h
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.h
+++ llvm/lib/Target/AArch64/AArch64Subtarget.h
@@ -68,6 +68,7 @@
 CortexX1,
 CortexX1C,
 CortexX2,
+CortexX3,
 ExynosM3,
 Falkor,
 Kryo,
Index: llvm/lib/Target/AArch64/AArch64Subtarget.cpp
===
--- llvm/lib/Target/AArch64/AArch64Subtarget.cpp
+++ llvm/lib/Target/AArch64/AArch64Subtarget.cpp
@@ -143,6 +143,7 @@
 break;
   case CortexA710:
   case CortexX2:
+  case CortexX3:
 PrefFunctionLogAlignment = 4;
 VScaleForTuning = 1;
 PrefLoopLogAlignment = 5;
Index: llvm/lib/Target/AArch64/AArch64.td
===
--- llvm/lib/Target/AArch64/AArch64.td
+++ llvm/lib/Target/AArch64/AArch64.td
@@ -785,6 +785,11 @@
   FeatureLSLFast,
   FeaturePostRAScheduler]>;
 
+def TuneX3 : SubtargetFeature<"cortex-x3", "ARMProcFamily", "CortexX3",
+  "Cortex-X3 ARM processors", [
+   FeaturePostRAScheduler,
+   FeatureFuseAES]>;
+
 def TuneA64FX : SubtargetFeature<"a64fx", "ARMProcFamily", "A64FX",
  "Fujitsu A64FX processors", [
  FeaturePostRAScheduler,
@@ -1109,6 +1114,11 @@
  FeatureMatMulInt8, FeatureBF16, FeatureAM,
  FeatureMTE, FeatureETE, FeatureSVE2BitPerm,
  FeatureFP16FML];
+  list X3 =   [HasV9_0aOps, FeatureSVE, FeatureNEON,
+ FeaturePerfMon, FeatureETE, FeatureTRBE,
+ FeatureSPE, FeatureBF16, FeatureMatMulInt8,
+ FeatureMTE, FeatureSVE2BitPerm, FeatureFullFP16,
+ FeatureFP16FML];
   list A64FX= [HasV8_2aOps, FeatureFPARMv8, FeatureNEON,
  FeatureSHA2, FeaturePerfMon, FeatureFullFP16,
  FeatureSVE, FeatureComplxNum];
@@ -1239,6 +1249,8 @@
  [TuneX1]>;
 def : ProcessorModel<"cortex-x2", NeoverseN2Model, ProcessorFeatures.X2,

[clang] 6f1e430 - [AArch64] Alter v8.5a FRINT neon intrinsics to be target-based, not preprocessor based

2022-10-24 Thread David Green via cfe-commits


Author: David Green
Date: 2022-10-24T11:22:06+01:00
New Revision: 6f1e430360591e22fb163ec77b78efd2de4c1d95

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

LOG: [AArch64] Alter v8.5a FRINT neon intrinsics to be target-based, not 
preprocessor based

This switches the v8.5-a FRINT intrinsics over to be target-gated,
behind preprocessor defines. This one is pretty simple, being AArch64
only.

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

Added: 


Modified: 
clang/include/clang/Basic/arm_neon.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/test/Sema/aarch64-neon-target.c

Removed: 




diff  --git a/clang/include/clang/Basic/arm_neon.td 
b/clang/include/clang/Basic/arm_neon.td
index a5e9dc2f16390..a7737a5f81e06 100644
--- a/clang/include/clang/Basic/arm_neon.td
+++ b/clang/include/clang/Basic/arm_neon.td
@@ -1225,7 +1225,7 @@ def FRINTZ_S64 : SInst<"vrnd", "..", "dQd">;
 def FRINTI_S64 : SInst<"vrndi", "..", "dQd">;
 }
 
-let ArchGuard = "defined(__aarch64__) && defined(__ARM_FEATURE_FRINT)" in {
+let ArchGuard = "defined(__aarch64__)", TargetGuard = "v8.5a" in {
 def FRINT32X_S32 : SInst<"vrnd32x", "..", "fQf">;
 def FRINT32Z_S32 : SInst<"vrnd32z", "..", "fQf">;
 def FRINT64X_S32 : SInst<"vrnd64x", "..", "fQf">;

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 2a3da01febe2b..fbb6e85e37d6e 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -6122,14 +6122,14 @@ static const ARMVectorIntrinsicInfo 
AArch64SIMDIntrinsicMap[] = {
   NEONMAP1(vrecpsq_v, aarch64_neon_frecps, Add1ArgType),
   NEONMAP2(vrhadd_v, aarch64_neon_urhadd, aarch64_neon_srhadd, Add1ArgType | 
UnsignedAlts),
   NEONMAP2(vrhaddq_v, aarch64_neon_urhadd, aarch64_neon_srhadd, Add1ArgType | 
UnsignedAlts),
-  NEONMAP1(vrnd32x_v, aarch64_neon_frint32x, Add1ArgType),
-  NEONMAP1(vrnd32xq_v, aarch64_neon_frint32x, Add1ArgType),
-  NEONMAP1(vrnd32z_v, aarch64_neon_frint32z, Add1ArgType),
-  NEONMAP1(vrnd32zq_v, aarch64_neon_frint32z, Add1ArgType),
-  NEONMAP1(vrnd64x_v, aarch64_neon_frint64x, Add1ArgType),
-  NEONMAP1(vrnd64xq_v, aarch64_neon_frint64x, Add1ArgType),
-  NEONMAP1(vrnd64z_v, aarch64_neon_frint64z, Add1ArgType),
-  NEONMAP1(vrnd64zq_v, aarch64_neon_frint64z, Add1ArgType),
+  NEONMAP1(vrnd32x_f32, aarch64_neon_frint32x, Add1ArgType),
+  NEONMAP1(vrnd32xq_f32, aarch64_neon_frint32x, Add1ArgType),
+  NEONMAP1(vrnd32z_f32, aarch64_neon_frint32z, Add1ArgType),
+  NEONMAP1(vrnd32zq_f32, aarch64_neon_frint32z, Add1ArgType),
+  NEONMAP1(vrnd64x_f32, aarch64_neon_frint64x, Add1ArgType),
+  NEONMAP1(vrnd64xq_f32, aarch64_neon_frint64x, Add1ArgType),
+  NEONMAP1(vrnd64z_f32, aarch64_neon_frint64z, Add1ArgType),
+  NEONMAP1(vrnd64zq_f32, aarch64_neon_frint64z, Add1ArgType),
   NEONMAP0(vrndi_v),
   NEONMAP0(vrndiq_v),
   NEONMAP2(vrshl_v, aarch64_neon_urshl, aarch64_neon_srshl, Add1ArgType | 
UnsignedAlts),
@@ -11313,26 +11313,26 @@ Value 
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
   : Intrinsic::trunc;
 return EmitNeonCall(CGM.getIntrinsic(Int, HalfTy), Ops, "vrndz");
   }
-  case NEON::BI__builtin_neon_vrnd32x_v:
-  case NEON::BI__builtin_neon_vrnd32xq_v: {
+  case NEON::BI__builtin_neon_vrnd32x_f32:
+  case NEON::BI__builtin_neon_vrnd32xq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint32x;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd32x");
   }
-  case NEON::BI__builtin_neon_vrnd32z_v:
-  case NEON::BI__builtin_neon_vrnd32zq_v: {
+  case NEON::BI__builtin_neon_vrnd32z_f32:
+  case NEON::BI__builtin_neon_vrnd32zq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint32z;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd32z");
   }
-  case NEON::BI__builtin_neon_vrnd64x_v:
-  case NEON::BI__builtin_neon_vrnd64xq_v: {
+  case NEON::BI__builtin_neon_vrnd64x_f32:
+  case NEON::BI__builtin_neon_vrnd64xq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint64x;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd64x");
   }
-  case NEON::BI__builtin_neon_vrnd64z_v:
-  case NEON::BI__builtin_neon_vrnd64zq_v: {
+  case NEON::BI__builtin_neon_vrnd64z_f32:
+  case NEON::BI__builtin_neon_vrnd64zq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint64z;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd64z");

diff  --git a/clang/test/Sema/aarch64-neon-target.c 
b/clang/test/Sema/aarch64-neon-target.c
index 5007f8f7dfae9..8b0f7f6006502 100644
--- a/clang/test/Sema/aarch64-neon-target.c
+++ b/clang/test/Sema/aarch64-neon-target.c
@@ -41,6 +41,11 @@ void bf16(uint32x2_t v2i32, uint32

[PATCH] D135646: [AArch64] Alter v8.5a FRINT neon intrinsics to be target-based, not preprocessor based

2022-10-24 Thread Dave Green 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 rG6f1e43036059: [AArch64] Alter v8.5a FRINT neon intrinsics to 
be target-based, not… (authored by dmgreen).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D135646?vs=466714&id=470104#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135646

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/Sema/aarch64-neon-target.c


Index: clang/test/Sema/aarch64-neon-target.c
===
--- clang/test/Sema/aarch64-neon-target.c
+++ clang/test/Sema/aarch64-neon-target.c
@@ -41,6 +41,11 @@
   vcvt_bf16_f32(v4f32);
 }
 
+__attribute__((target("arch=armv8.5-a")))
+void test_v85(float32x4_t v4f32) {
+  vrnd32xq_f32(v4f32);
+}
+
 void undefined(uint32x2_t v2i32, uint32x4_t v4i32, uint16x8_t v8i16, 
uint8x16_t v16i8, uint8x8_t v8i8, float32x2_t v2f32, float32x4_t v4f32, 
float16x4_t v4f16, bfloat16x4_t v4bf16, __bf16 bf16) {
   // dotprod
   vdot_u32(v2i32, v8i8, v8i8); // expected-error {{always_inline function 
'vdot_u32' requires target feature 'dotprod'}}
@@ -63,4 +68,6 @@
   vld1_bf16(0); // expected-error {{'__builtin_neon_vld1_bf16' needs target 
feature bf16}}
   vcvt_f32_bf16(v4bf16); // expected-error {{always_inline function 
'vcvt_f32_bf16' requires target feature 'bf16'}}
   vcvt_bf16_f32(v4f32); // expected-error {{always_inline function 
'vcvt_bf16_f32' requires target feature 'bf16'}}
+  // 8.5 - frint
+  vrnd32xq_f32(v4f32); // expected-error {{always_inline function 
'vrnd32xq_f32' requires target feature 'v8.5a'}}
 }
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -6122,14 +6122,14 @@
   NEONMAP1(vrecpsq_v, aarch64_neon_frecps, Add1ArgType),
   NEONMAP2(vrhadd_v, aarch64_neon_urhadd, aarch64_neon_srhadd, Add1ArgType | 
UnsignedAlts),
   NEONMAP2(vrhaddq_v, aarch64_neon_urhadd, aarch64_neon_srhadd, Add1ArgType | 
UnsignedAlts),
-  NEONMAP1(vrnd32x_v, aarch64_neon_frint32x, Add1ArgType),
-  NEONMAP1(vrnd32xq_v, aarch64_neon_frint32x, Add1ArgType),
-  NEONMAP1(vrnd32z_v, aarch64_neon_frint32z, Add1ArgType),
-  NEONMAP1(vrnd32zq_v, aarch64_neon_frint32z, Add1ArgType),
-  NEONMAP1(vrnd64x_v, aarch64_neon_frint64x, Add1ArgType),
-  NEONMAP1(vrnd64xq_v, aarch64_neon_frint64x, Add1ArgType),
-  NEONMAP1(vrnd64z_v, aarch64_neon_frint64z, Add1ArgType),
-  NEONMAP1(vrnd64zq_v, aarch64_neon_frint64z, Add1ArgType),
+  NEONMAP1(vrnd32x_f32, aarch64_neon_frint32x, Add1ArgType),
+  NEONMAP1(vrnd32xq_f32, aarch64_neon_frint32x, Add1ArgType),
+  NEONMAP1(vrnd32z_f32, aarch64_neon_frint32z, Add1ArgType),
+  NEONMAP1(vrnd32zq_f32, aarch64_neon_frint32z, Add1ArgType),
+  NEONMAP1(vrnd64x_f32, aarch64_neon_frint64x, Add1ArgType),
+  NEONMAP1(vrnd64xq_f32, aarch64_neon_frint64x, Add1ArgType),
+  NEONMAP1(vrnd64z_f32, aarch64_neon_frint64z, Add1ArgType),
+  NEONMAP1(vrnd64zq_f32, aarch64_neon_frint64z, Add1ArgType),
   NEONMAP0(vrndi_v),
   NEONMAP0(vrndiq_v),
   NEONMAP2(vrshl_v, aarch64_neon_urshl, aarch64_neon_srshl, Add1ArgType | 
UnsignedAlts),
@@ -11313,26 +11313,26 @@
   : Intrinsic::trunc;
 return EmitNeonCall(CGM.getIntrinsic(Int, HalfTy), Ops, "vrndz");
   }
-  case NEON::BI__builtin_neon_vrnd32x_v:
-  case NEON::BI__builtin_neon_vrnd32xq_v: {
+  case NEON::BI__builtin_neon_vrnd32x_f32:
+  case NEON::BI__builtin_neon_vrnd32xq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint32x;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd32x");
   }
-  case NEON::BI__builtin_neon_vrnd32z_v:
-  case NEON::BI__builtin_neon_vrnd32zq_v: {
+  case NEON::BI__builtin_neon_vrnd32z_f32:
+  case NEON::BI__builtin_neon_vrnd32zq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint32z;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd32z");
   }
-  case NEON::BI__builtin_neon_vrnd64x_v:
-  case NEON::BI__builtin_neon_vrnd64xq_v: {
+  case NEON::BI__builtin_neon_vrnd64x_f32:
+  case NEON::BI__builtin_neon_vrnd64xq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint64x;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd64x");
   }
-  case NEON::BI__builtin_neon_vrnd64z_v:
-  case NEON::BI__builtin_neon_vrnd64zq_v: {
+  case NEON::BI__builtin_neon_vrnd64z_f32:
+  case NEON::BI__builtin_neon_vrnd64zq_f32: {
 Ops.push_back(EmitScalarExpr(E->getArg(0)));
 Int = Intrinsic::aarch64_neon_frint64z;
 return EmitNeonCall(CGM.getIntrinsic(Int, Ty), Ops, "vrnd64z");
Index: clang/include/clang/Basic/arm_neon.td

[PATCH] D136293: [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet marked 13 inline comments as done.
kadircet added inline comments.



Comment at: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h:14
+#include "llvm/ADT/STLFunctionalExtras.h"
+#include 
+

sammccall wrote:
> This is awful but: as mentioned on another patch, we can't actually use 
> variant. AFAIK all C++17 *language* features are available, but LLVM supports 
> apple clang 9.3, which doesn't provide  at all.
> 
> There's an IntrusiveVariant in review somewhere but seems stalled (and 
> honestly the Intrusive part makes it pretty ugly to use).
> 
> I think for now our best option is a Kind enum and some kind of uintptr_t 
> storage :-(
right, i've seen that comment as well and wanted to pile up there. there are 
already uses of `` in LLVM today, TableGen, DenseMap, CodeGen, flang, 
pseudo, MLIR and lldb are some examples of big components. I don't see what 
they're doing to compile those today.



Comment at: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp:125
 
+TEST(WalkUsed, Basic) {
+  llvm::Annotations HeaderCode(R"cpp(

sammccall wrote:
> signal-to-noise in this test is a bit low, and there'll be a bunch more tests 
> as the features get extended.
> 
> I think adding a `TEST_F` fixture and splitting the stdlib out into its own 
> test, trying to maximize the shared code, may lead to cleaner tests.
> 
> Feel free to defer this, just watch out for incremental inertia giving you a 
> 1000 line monster before you know it!
yup, that's definitely something i've in pending patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136293

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

[PATCH] D136293: [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet marked 2 inline comments as done.
kadircet added inline comments.



Comment at: clang-tools-extra/include-cleaner/lib/WalkAST.cpp:67
+llvm::errs() << "returning stdlib\n";
+return CB(Loc, Symbol(*SS), toHeader(SS->headers()));
+  }

sammccall wrote:
> (I think the patch is fine, but could use some extra docs/fixmes depending on 
> what the choices are here).
> 
> In general we want a forward declaration in the main file to suppress any 
> include insertion.
> Two obvious ways to achieve that:
> A) walkUsed doesn't report refs of symbols that have a decl in the main file
> B) walkUsed reports the refs, the header list includes the main file, the 
> caller recognizes it when checking if the ref is satisfied
> 
> A) feels more ad-hoc, but seems to work and *does* naturally achieve the nice 
> effect that `#include "foo.h"` is marked as unused if the only used symbols 
> are also forward-declared locally. In this case, maybe add a FIXME for this 
> filtering? Also A seems surprising enough to be worth documenting.
> 
> B) falls more naturally out of the implementation. It looks like  we have a 
> bug here: by bailing out early, we'll omit any forward declarations from the 
> main file. For symbols in `namespace std` we're arguably [within our rights 
> as such decls are UB](http://eel.is/c++draft/namespace.std#1). However such 
> forward decls are legal in C, so maybe we should care after all? In any case, 
> this subtlety deserves some sort of comment.
thanks, i think the conclusion is `B)` here, but definitely didn't notice the 
implications of early bailout here. adding some comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136293

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

[PATCH] D136293: [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet updated this revision to Diff 470106.
kadircet marked an inline comment as done.
kadircet added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136293

Files:
  clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/lib/CMakeLists.txt
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
  clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -1,15 +1,28 @@
+//===--- WalkASTTest.cpp --- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
 #include "AnalysisInternal.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Frontend/TextDiagnostic.h"
 #include "clang/Testing/TestAST.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Annotations.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
+#include 
 
-namespace clang {
-namespace include_cleaner {
+namespace clang::include_cleaner {
 namespace {
+using testing::Pair;
+using testing::UnorderedElementsAre;
 
 // Specifies a test of which symbols are referenced by a piece of code.
 //
@@ -106,5 +119,4 @@
 }
 
 } // namespace
-} // namespace include_cleaner
-} // namespace clang
+} // namespace clang::include_cleaner
Index: clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
===
--- clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
+++ clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
@@ -5,6 +5,7 @@
 
 add_custom_target(ClangIncludeCleanerUnitTests)
 add_unittest(ClangIncludeCleanerUnitTests ClangIncludeCleanerTests
+  AnalysisTest.cpp
   RecordTest.cpp
   WalkASTTest.cpp
 )
@@ -18,6 +19,7 @@
   clangAST
   clangBasic
   clangFrontend
+  clangToolingInclusionsStdlib
   )
 
 target_link_libraries(ClangIncludeCleanerTests
Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- /dev/null
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -0,0 +1,69 @@
+//===--- AnalysisTest.cpp -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang-include-cleaner/Analysis.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Testing/TestAST.h"
+#include "clang/Tooling/Inclusions/StandardLibrary.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/Testing/Support/Annotations.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+namespace clang::include_cleaner {
+namespace {
+using testing::Pair;
+using testing::UnorderedElementsAre;
+
+TEST(WalkUsed, Basic) {
+  // FIXME: Have a fixture for setting up tests.
+  llvm::Annotations HeaderCode(R"cpp(
+  void foo();
+  namespace std { class vector {}; })cpp");
+  llvm::Annotations Code(R"cpp(
+  void bar() {
+$foo^foo();
+std::$vector^vector v;
+  }
+  )cpp");
+  TestInputs Inputs(Code.code());
+  Inputs.ExtraFiles["header.h"] = HeaderCode.code().str();
+  Inputs.ExtraArgs.push_back("-include");
+  Inputs.ExtraArgs.push_back("header.h");
+  TestAST AST(Inputs);
+
+  llvm::SmallVector TopLevelDecls;
+  for (Decl *D : AST.context().getTranslationUnitDecl()->decls()) {
+TopLevelDecls.emplace_back(D);
+  }
+
+  auto &SM = AST.sourceManager();
+  llvm::DenseMap> OffsetToProviders;
+  walkUsed(TopLevelDecls, [&](SourceLocation RefLoc, Symbol S,
+  llvm::ArrayRef Providers) {
+auto [FID, Offset] = SM.getDecomposedLoc(RefLoc);
+EXPECT_EQ(FID, SM.getMainFileID());
+OffsetToProviders.try_emplace(Offset, Providers.vec());
+  });
+  auto HeaderFile = AST.fileManager().getFile("header.h")

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

2022-10-24 Thread Dave Green via Phabricator via cfe-commits

dmgreen added reviewers: lenary, dmgreen.
dmgreen added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:397
   configuration files.
+- Support has been added for the following processors (-mcpu identifiers in 
parentheses):
+

This should be in the "Arm and AArch64 Support in Clang" section.



Comment at: llvm/docs/ReleaseNotes.rst:84
 
+* Added support for the Cortex-X3 CPU.
+

Can you add a reference to neoverse-v2 too.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:220
   AArch64::AEK_FP16FML))
+AARCH64_CPU_NAME("cortex-x3",   ARMV9A, FK_CRYPTO_NEON_FP_ARMV8, false,
+ (AArch64::AEK_SVE | AArch64::AEK_PERFMON | 
AArch64::AEK_PROFILE |

Remove this space
I believe Crypto should be removed.



Comment at: llvm/lib/Target/AArch64/AArch64.td:791
+   FeaturePostRAScheduler,
+   FeatureFuseAES]>;
+

Please add FeatureFuseAdrpAdd and FeatureLSLFast.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136589

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

[PATCH] D136589: [AArch64] Add support for the Cortex-X3 CPU

2022-10-24 Thread Dave Green via Phabricator via cfe-commits

dmgreen added a comment.

Can you also add a test to clang/test/Driver/aarch64-mcpu.c and the right code 
to llvm/lib/Support/Host.cpp if you can find it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136589

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

[PATCH] D136574: [clang] Copy cmake_policy() to silence CMake warnings in standalone builds

2022-10-24 Thread Michał Górny via Phabricator via cfe-commits

mgorny abandoned this revision.
mgorny added a comment.

I'll make one patch for all relevant projects instead.


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

https://reviews.llvm.org/D136574

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

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

2022-10-24 Thread Michał Górny via Phabricator via cfe-commits

mgorny updated this revision to Diff 470108.
mgorny retitled this revision from "[lld] Copy cmake_policy() to silence CMake 
warnings in standalone builds" to "Harmonize cmake_policy() across standalone 
builds of all projects".
mgorny edited the summary of this revision.
mgorny added reviewers: mehdi_amini, labath.
mgorny added subscribers: cfe-commits, lldb-commits.
mgorny added a comment.
Herald added subscribers: zero9178, bzcheeseman, sdasgup3, wenzhicui, wrengr, 
cota, teijeong, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, 
Joonsoo, stephenneuendorffer, liufengdb, aartbik, mgester, arpith-jacob, 
nicolasvasilache, antiagainst, shauheen, rriddle, kristof.beyls.
Herald added a reviewer: sscalpone.
Herald added a project: MLIR.

Replace with one patch for all the projects.


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

https://reviews.llvm.org/D136572

Files:
  clang/CMakeLists.txt
  flang/CMakeLists.txt
  lld/CMakeLists.txt
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake
  mlir/CMakeLists.txt

Index: mlir/CMakeLists.txt
===
--- mlir/CMakeLists.txt
+++ mlir/CMakeLists.txt
@@ -1,7 +1,16 @@
 # MLIR project.
 
+cmake_minimum_required(VERSION 3.13.4)
+
 # Check if MLIR is built as a standalone project.
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)
+cmake_policy(SET CMP0114 OLD)
+  endif()
+  if(POLICY CMP0116)
+cmake_policy(SET CMP0116 OLD)
+  endif()
   project(mlir)
   set(MLIR_STANDALONE_BUILD TRUE)
 endif()
@@ -10,8 +19,6 @@
 include(GNUInstallDirs)
 
 if(MLIR_STANDALONE_BUILD)
-  cmake_minimum_required(VERSION 3.13.4)
-
   find_package(LLVM CONFIG REQUIRED)
   set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${LLVM_CMAKE_DIR})
   include(HandleLLVMOptions)
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,9 +1,3 @@
-# CMP0116: Ninja generators transform `DEPFILE`s from `add_custom_command()`
-# New in CMake 3.20. https://cmake.org/cmake/help/latest/policy/CMP0116.html
-if(POLICY CMP0116)
-  cmake_policy(SET CMP0116 OLD)
-endif()
-
 if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
   set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
 endif()
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -1,19 +1,26 @@
 cmake_minimum_required(VERSION 3.13.4)
 
-# Add path for custom modules.
-set(CMAKE_MODULE_PATH
-  ${CMAKE_MODULE_PATH}
-  "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
-  "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
-  )
-
 # If we are not building as part of LLVM, build LLDB as a standalone project,
 # using LLVM as an external library.
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)
+cmake_policy(SET CMP0114 OLD)
+  endif()
+  if(POLICY CMP0116)
+cmake_policy(SET CMP0116 OLD)
+  endif()
   project(lldb)
   set(LLDB_BUILT_STANDALONE TRUE)
 endif()
 
+# Add path for custom modules.
+set(CMAKE_MODULE_PATH
+  ${CMAKE_MODULE_PATH}
+  "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
+  "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
+  )
+
 # Must go below project(..)
 include(GNUInstallDirs)
 
Index: lld/CMakeLists.txt
===
--- lld/CMakeLists.txt
+++ lld/CMakeLists.txt
@@ -3,6 +3,13 @@
 # If we are not building as a part of LLVM, build LLD as an
 # standalone project, using LLVM as an external library:
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)
+cmake_policy(SET CMP0114 OLD)
+  endif()
+  if(POLICY CMP0116)
+cmake_policy(SET CMP0116 OLD)
+  endif()
   project(lld)
   set(LLD_BUILT_STANDALONE TRUE)
 endif()
Index: flang/CMakeLists.txt
===
--- flang/CMakeLists.txt
+++ flang/CMakeLists.txt
@@ -1,5 +1,22 @@
 cmake_minimum_required(VERSION 3.13.4)
 
+# Check for a standalone build and configure as appropriate from
+# there.
+if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)
+cmake_policy(SET CMP0114 OLD)
+  endif()
+  if(POLICY CMP0116)
+cmake_policy(SET CMP0116 OLD)
+  endif()
+  message("Building Flang as a standalone project.")
+  project(Flang)
+  set(FLANG_STANDALONE_BUILD ON)
+else()
+  set(FLANG_STANDALONE_BUILD OFF)
+endif()
+
 set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
 # Flang requires C++17.
@@ -19,16 +36,6 @@
 
 option(FLANG_ENABLE_WERROR "Fail and stop building flang if a warning is triggered." OFF)
 
-# Check for a standalone build and co

[PATCH] D118743: [clang-tidy] Add `modernize-use-inline-const-variables-in-headers` check

2022-10-24 Thread Evgeny Shulgin via Phabricator via cfe-commits

Izaron added a comment.

A friendly ping 🙂


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118743

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

[PATCH] D135933: [X86] Add CMPCCXADD instructions.

2022-10-24 Thread Freddy, Ye via Phabricator via cfe-commits

FreddyYe added inline comments.



Comment at: llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1453-1455
+emitMemModRMByte(MI, CurOp + 1, getX86RegNum(MI.getOperand(0)), TSFlags,
+ HasREX, StartByte, OS, Fixups, STI, false);
+CurOp = SrcRegNum + 3; // skip VEX_V4 and CC

skan wrote:
> Minor suggestion
> 
> ```
> emitMemModRMByte(MI, ++CurOp, getX86RegNum(MI.getOperand(0)), TSFlags,
>  HasREX, StartByte, OS, Fixups, STI, false);
> CurOp = SrcRegNum + 2; // skip VEX_V4 and CC
> ```
> would be more clear b/c you use "skip VEX_V4 and CC" in the comments.
We cannot do `++` before emitMemModRMByte, so there is a implicit +1 for that, 
like other cases.



Comment at: llvm/lib/Target/X86/X86InstrInfo.td:3027
+def CMPCCXADDmr32 : I<0xe0, MRMDestMem4VOp3CC, (outs GR32:$dst),
+  (ins GR32:$dstsrc2, i32mem:$dstsrc1, GR32:$src3, ccode:$cond),
+  "cmp${cond}xadd\t{$src3, $dst, $dstsrc1|$dstsrc1, $dst, $src3}",

skan wrote:
> Could you use "GR32:$dstsrc1, i32mem:$dstsrc2" instead?
OK, I'm ok to either. Then line below should do an reversion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135933

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

[clang] 9ec7448 - [Clang][AArch64] Add support for -mcpu=grace

2022-10-24 Thread Sjoerd Meijer via cfe-commits


Author: Sjoerd Meijer
Date: 2022-10-24T17:36:24+05:30
New Revision: 9ec7448857c1bcbc9878e9912167d9453d3be673

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

LOG: [Clang][AArch64] Add support for -mcpu=grace

This adds Clang command line support for the NVIDIA Grace CPU [1], which
we would like to target with -mcpu=grace.

Grace is based on the Arm Neoverse V2 CPU [1], which is why, in the
driver, we pass neoverse-v2 to the compiler when grace is requested.
Thus, for now, it's an alias to Neoverse V2.

This adds support for grace in user-facing tool Clang, but not yet the
developer tools like opt and llc, so we probably want to follow up on
this.

[1] https://www.nvidia.com/en-us/data-center/grace-cpu/

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/AArch64.cpp
clang/test/Driver/aarch64-mcpu.c
llvm/include/llvm/Support/AArch64TargetParser.h

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp 
b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index cf7e201b4972c..7956a0be46280 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -38,6 +38,8 @@ std::string aarch64::getAArch64TargetCPU(const ArgList &Args,
 CPU = Mcpu.split("+").first.lower();
   }
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   // Handle CPU name is 'native'.
   if (CPU == "native")
 return std::string(llvm::sys::getHostCPUName());
@@ -121,6 +123,8 @@ static bool DecodeAArch64Mcpu(const Driver &D, StringRef 
Mcpu, StringRef &CPU,
   CPU = Split.first;
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::ArchKind::ARMV8A;
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
 

diff  --git a/clang/test/Driver/aarch64-mcpu.c 
b/clang/test/Driver/aarch64-mcpu.c
index 8b2701f27a9eb..0433f6a5b3d3f 100644
--- a/clang/test/Driver/aarch64-mcpu.c
+++ b/clang/test/Driver/aarch64-mcpu.c
@@ -61,6 +61,9 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-r82  -### -c %s 2>&1 | FileCheck 
-check-prefix=CORTEXR82 %s
 // CORTEXR82: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-r82"
 
+// RUN: %clang -target aarch64 -mcpu=grace -### -c %s 2>&1 | FileCheck 
-check-prefix=GRACE %s
+// GRACE: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "neoverse-v2"
+
 // == Check whether -mcpu and -mtune accept mixed-case values.
 // RUN: %clang -target aarch64 -mcpu=Cortex-a53 -### -c %s 2>&1 | FileCheck 
-check-prefix=CASE-INSENSITIVE-CA53 %s
 // RUN: %clang -target aarch64 -mtune=Cortex-a53 -### -c %s 2>&1 | FileCheck 
-check-prefix=CASE-INSENSITIVE-CA53-TUNE %s

diff  --git a/llvm/include/llvm/Support/AArch64TargetParser.h 
b/llvm/include/llvm/Support/AArch64TargetParser.h
index f4e157cf80562..3f0981d27427b 100644
--- a/llvm/include/llvm/Support/AArch64TargetParser.h
+++ b/llvm/include/llvm/Support/AArch64TargetParser.h
@@ -139,6 +139,13 @@ StringRef getArchExtName(unsigned ArchExtKind);
 StringRef getArchExtFeature(StringRef ArchExt);
 ArchKind convertV9toV8(ArchKind AK);
 
+// FIXME: We should be able to define CPU aliases in TargetParser.
+inline StringRef resolveCPUAlias(StringRef CPU) {
+  if (CPU == "grace")
+return "neoverse-v2";
+  return CPU;
+}
+
 // Information by Name
 unsigned getDefaultFPU(StringRef CPU, ArchKind AK);
 uint64_t getDefaultExtensions(StringRef CPU, ArchKind AK);



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

[PATCH] D136425: [Clang][AArch64] Add support for -mcpu=grace

2022-10-24 Thread Sjoerd Meijer via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9ec7448857c1: [Clang][AArch64] Add support for -mcpu=grace 
(authored by SjoerdMeijer).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136425

Files:
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/test/Driver/aarch64-mcpu.c
  llvm/include/llvm/Support/AArch64TargetParser.h


Index: llvm/include/llvm/Support/AArch64TargetParser.h
===
--- llvm/include/llvm/Support/AArch64TargetParser.h
+++ llvm/include/llvm/Support/AArch64TargetParser.h
@@ -139,6 +139,13 @@
 StringRef getArchExtFeature(StringRef ArchExt);
 ArchKind convertV9toV8(ArchKind AK);
 
+// FIXME: We should be able to define CPU aliases in TargetParser.
+inline StringRef resolveCPUAlias(StringRef CPU) {
+  if (CPU == "grace")
+return "neoverse-v2";
+  return CPU;
+}
+
 // Information by Name
 unsigned getDefaultFPU(StringRef CPU, ArchKind AK);
 uint64_t getDefaultExtensions(StringRef CPU, ArchKind AK);
Index: clang/test/Driver/aarch64-mcpu.c
===
--- clang/test/Driver/aarch64-mcpu.c
+++ clang/test/Driver/aarch64-mcpu.c
@@ -61,6 +61,9 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-r82  -### -c %s 2>&1 | FileCheck 
-check-prefix=CORTEXR82 %s
 // CORTEXR82: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-r82"
 
+// RUN: %clang -target aarch64 -mcpu=grace -### -c %s 2>&1 | FileCheck 
-check-prefix=GRACE %s
+// GRACE: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "neoverse-v2"
+
 // == Check whether -mcpu and -mtune accept mixed-case values.
 // RUN: %clang -target aarch64 -mcpu=Cortex-a53 -### -c %s 2>&1 | FileCheck 
-check-prefix=CASE-INSENSITIVE-CA53 %s
 // RUN: %clang -target aarch64 -mtune=Cortex-a53 -### -c %s 2>&1 | FileCheck 
-check-prefix=CASE-INSENSITIVE-CA53-TUNE %s
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -38,6 +38,8 @@
 CPU = Mcpu.split("+").first.lower();
   }
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   // Handle CPU name is 'native'.
   if (CPU == "native")
 return std::string(llvm::sys::getHostCPUName());
@@ -121,6 +123,8 @@
   CPU = Split.first;
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::ArchKind::ARMV8A;
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
 


Index: llvm/include/llvm/Support/AArch64TargetParser.h
===
--- llvm/include/llvm/Support/AArch64TargetParser.h
+++ llvm/include/llvm/Support/AArch64TargetParser.h
@@ -139,6 +139,13 @@
 StringRef getArchExtFeature(StringRef ArchExt);
 ArchKind convertV9toV8(ArchKind AK);
 
+// FIXME: We should be able to define CPU aliases in TargetParser.
+inline StringRef resolveCPUAlias(StringRef CPU) {
+  if (CPU == "grace")
+return "neoverse-v2";
+  return CPU;
+}
+
 // Information by Name
 unsigned getDefaultFPU(StringRef CPU, ArchKind AK);
 uint64_t getDefaultExtensions(StringRef CPU, ArchKind AK);
Index: clang/test/Driver/aarch64-mcpu.c
===
--- clang/test/Driver/aarch64-mcpu.c
+++ clang/test/Driver/aarch64-mcpu.c
@@ -61,6 +61,9 @@
 // RUN: %clang -target aarch64 -mcpu=cortex-r82  -### -c %s 2>&1 | FileCheck -check-prefix=CORTEXR82 %s
 // CORTEXR82: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "cortex-r82"
 
+// RUN: %clang -target aarch64 -mcpu=grace -### -c %s 2>&1 | FileCheck -check-prefix=GRACE %s
+// GRACE: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "neoverse-v2"
+
 // == Check whether -mcpu and -mtune accept mixed-case values.
 // RUN: %clang -target aarch64 -mcpu=Cortex-a53 -### -c %s 2>&1 | FileCheck -check-prefix=CASE-INSENSITIVE-CA53 %s
 // RUN: %clang -target aarch64 -mtune=Cortex-a53 -### -c %s 2>&1 | FileCheck -check-prefix=CASE-INSENSITIVE-CA53-TUNE %s
Index: clang/lib/Driver/ToolChains/Arch/AArch64.cpp
===
--- clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -38,6 +38,8 @@
 CPU = Mcpu.split("+").first.lower();
   }
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   // Handle CPU name is 'native'.
   if (CPU == "native")
 return std::string(llvm::sys::getHostCPUName());
@@ -121,6 +123,8 @@
   CPU = Split.first;
   llvm::AArch64::ArchKind ArchKind = llvm::AArch64::ArchKind::ARMV8A;
 
+  CPU = llvm::AArch64::resolveCPUAlias(CPU);
+
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
 
_

[clang] 1534b04 - Fix caret position to be on the non null parameter

2022-10-24 Thread Aaron Ballman via cfe-commits


Author: Arthur Grillo
Date: 2022-10-24T08:38:21-04:00
New Revision: 1534b048d6fdd7cf5f7dd5d3b8c6876b7cdad184

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

LOG: Fix caret position to be on the non null parameter

When checking for non null arguments the wrong SourceLocation was given,
this fix to pass the proper argument's location.

Fixes #58273

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/non-null-warning.c

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 0dec5de56d38f..68cee534513a5 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -325,6 +325,9 @@ Improvements to Clang's diagnostics
   pointers is improved to include the type of the array and whether it's cast
   to another type. This should improve comprehension for why an index is
   out-of-bounds.
+- Clang now correctly point to the problematic parameter for the ``-Wnonnull``
+  warning.
+  This fixes `Issue 58273 
`_.
 
 Non-comprehensive list of changes in this release
 -

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 0727433fbc43c..fe0d1af25b32c 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -5639,7 +5639,7 @@ static void CheckNonNullArguments(Sema &S,
   for (unsigned ArgIndex = 0, ArgIndexEnd = NonNullArgs.size();
ArgIndex != ArgIndexEnd; ++ArgIndex) {
 if (NonNullArgs[ArgIndex])
-  CheckNonNullArgument(S, Args[ArgIndex], CallSiteLoc);
+  CheckNonNullArgument(S, Args[ArgIndex], Args[ArgIndex]->getExprLoc());
   }
 }
 

diff  --git a/clang/test/Sema/non-null-warning.c 
b/clang/test/Sema/non-null-warning.c
index 1e99dee25067e..d8369a5fee217 100644
--- a/clang/test/Sema/non-null-warning.c
+++ b/clang/test/Sema/non-null-warning.c
@@ -37,9 +37,16 @@ int * ret_nonnull(void) {
   return 0; // expected-warning {{null returned from function that requires a 
non-null return value}}
 }
 
+int foo4(int * _Nonnull x, int * y) {
+  return 0;
+}
+
 #define SAFE_CALL(X) if (X) foo(X)
 int main (void) {
   foo(0); // expected-warning {{null passed to a callee that requires a 
non-null argument}}
   (void)sizeof(foo(0)); // expect no diagnostic in unevaluated context.
   SAFE_CALL(0); // expect no diagnostic for unreachable code.
+  foo4(
+   0, // expected-warning {{null passed to a callee that requires a 
non-null argument}}
+   0);
 }



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

[PATCH] D136355: [clang][Sema] Fix caret position to be on the non null parameter

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1534b048d6fd: Fix caret position to be on the non null 
parameter (authored by Grillo, committed by aaron.ballman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136355

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/non-null-warning.c


Index: clang/test/Sema/non-null-warning.c
===
--- clang/test/Sema/non-null-warning.c
+++ clang/test/Sema/non-null-warning.c
@@ -37,9 +37,16 @@
   return 0; // expected-warning {{null returned from function that requires a 
non-null return value}}
 }
 
+int foo4(int * _Nonnull x, int * y) {
+  return 0;
+}
+
 #define SAFE_CALL(X) if (X) foo(X)
 int main (void) {
   foo(0); // expected-warning {{null passed to a callee that requires a 
non-null argument}}
   (void)sizeof(foo(0)); // expect no diagnostic in unevaluated context.
   SAFE_CALL(0); // expect no diagnostic for unreachable code.
+  foo4(
+   0, // expected-warning {{null passed to a callee that requires a 
non-null argument}}
+   0);
 }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -5639,7 +5639,7 @@
   for (unsigned ArgIndex = 0, ArgIndexEnd = NonNullArgs.size();
ArgIndex != ArgIndexEnd; ++ArgIndex) {
 if (NonNullArgs[ArgIndex])
-  CheckNonNullArgument(S, Args[ArgIndex], CallSiteLoc);
+  CheckNonNullArgument(S, Args[ArgIndex], Args[ArgIndex]->getExprLoc());
   }
 }
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -325,6 +325,9 @@
   pointers is improved to include the type of the array and whether it's cast
   to another type. This should improve comprehension for why an index is
   out-of-bounds.
+- Clang now correctly point to the problematic parameter for the ``-Wnonnull``
+  warning.
+  This fixes `Issue 58273 
`_.
 
 Non-comprehensive list of changes in this release
 -


Index: clang/test/Sema/non-null-warning.c
===
--- clang/test/Sema/non-null-warning.c
+++ clang/test/Sema/non-null-warning.c
@@ -37,9 +37,16 @@
   return 0; // expected-warning {{null returned from function that requires a non-null return value}}
 }
 
+int foo4(int * _Nonnull x, int * y) {
+  return 0;
+}
+
 #define SAFE_CALL(X) if (X) foo(X)
 int main (void) {
   foo(0); // expected-warning {{null passed to a callee that requires a non-null argument}}
   (void)sizeof(foo(0)); // expect no diagnostic in unevaluated context.
   SAFE_CALL(0); // expect no diagnostic for unreachable code.
+  foo4(
+   0, // expected-warning {{null passed to a callee that requires a non-null argument}}
+   0);
 }
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -5639,7 +5639,7 @@
   for (unsigned ArgIndex = 0, ArgIndexEnd = NonNullArgs.size();
ArgIndex != ArgIndexEnd; ++ArgIndex) {
 if (NonNullArgs[ArgIndex])
-  CheckNonNullArgument(S, Args[ArgIndex], CallSiteLoc);
+  CheckNonNullArgument(S, Args[ArgIndex], Args[ArgIndex]->getExprLoc());
   }
 }
 
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -325,6 +325,9 @@
   pointers is improved to include the type of the array and whether it's cast
   to another type. This should improve comprehension for why an index is
   out-of-bounds.
+- Clang now correctly point to the problematic parameter for the ``-Wnonnull``
+  warning.
+  This fixes `Issue 58273 `_.
 
 Non-comprehensive list of changes in this release
 -
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136449: [Clang] Implement P2513

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from a missing full stop in a comment. Tom's on vacation most of 
this week, so if he has any concerns, they can be address post-commit unless 
you want to wait for him (which is also totally fine by me).




Comment at: clang/lib/Sema/SemaInit.cpp:94
+//   Additionally, an array of char or unsigned char may be initialized
+//   by a UTF-8 string literal
+if (ElemTy->isChar8Type() ||




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136449

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

[PATCH] D136594: [clangd] Add support for semantic token type "operator"

2022-10-24 Thread Christian Kandeler via Phabricator via cfe-commits

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

Also add new modifier for differentiating between built-in and user-
provided operators.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136594

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -113,9 +113,9 @@
   void $Function_def[[foo]](int $Parameter_def[[A]], $Class[[AS]] $Parameter_def[[As]]) {
 $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $LocalVariable_def[[AA]];
-$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
+$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] $Operator[[+]] $Parameter[[A]];
 auto $LocalVariable_def[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_def[[A]]) -> void {};
-$LocalVariable[[FN]](12312);
+$LocalVariable[[FN]]$Operator_userProvided[[(]]12312$Operator_userProvided[[)]];
   }
 )cpp",
   R"cpp(
@@ -144,7 +144,7 @@
   struct $Class_def[[B]] {
 $Class_decl_constrDestr[[B]]();
 ~$Class_decl_constrDestr[[B]]();
-void operator<<($Class[[B]]);
+void operator$Operator_decl[[<<]]($Class[[B]]);
 $Class[[AAA]] $Field_decl[[AA]];
   };
   $Class[[B]]::$Class_def_constrDestr[[B]]() {}
@@ -203,20 +203,20 @@
 static double $StaticField_decl_static[[S]];
 static void $StaticMethod_def_static[[bar]]() {}
 void $Method_def[[foo]]() {
-  $Field[[B]] = 123;
-  this->$Field[[B]] = 156;
+  $Field[[B]] $Operator[[=]] 123;
+  this->$Field[[B]] $Operator[[=]] 156;
   this->$Method[[foo]]();
   $Method[[foo]]();
   $StaticMethod_static[[bar]]();
-  $StaticField_static[[S]] = 90.1;
+  $StaticField_static[[S]] $Operator[[=]] 90.1;
 }
   };
   void $Function_def[[foo]]() {
 $Class[[A]] $LocalVariable_def[[AA]];
-$LocalVariable[[AA]].$Field[[B]] += 2;
+$LocalVariable[[AA]].$Field[[B]] $Operator[[+=]] 2;
 $LocalVariable[[AA]].$Method[[foo]]();
 $LocalVariable[[AA]].$Field[[E]].$Field[[C]];
-$Class[[A]]::$StaticField_static[[S]] = 90;
+$Class[[A]]::$StaticField_static[[S]] $Operator[[=]] 90;
   }
 )cpp",
   R"cpp(
@@ -295,10 +295,10 @@
   struct $Class_def[[B]] {};
   struct $Class_def[[A]] {
 $Class[[B]] $Field_decl[[BB]];
-$Class[[A]] &operator=($Class[[A]] &&$Parameter_def[[O]]);
+$Class[[A]] &operator$Operator_decl[[=]]($Class[[A]] &&$Parameter_def[[O]]);
   };
 
-  $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Parameter_def[[O]]) = default;
+  $Class[[A]] &$Class[[A]]::operator$Operator_def[[=]]($Class[[A]] &&$Parameter_def[[O]]) = default;
 )cpp",
   R"cpp(
   enum $Enum_decl[[En]] {
@@ -327,9 +327,9 @@
   $Enum_deduced[[auto]] $Variable_def[[AE]] = $Enum[[E]]::$EnumConstant_readonly[[E]];
   $Class_deduced[[auto]] $Variable_def[[AF]] = $Class[[Foo]]();
   $Class_deduced[[decltype]](auto) $Variable_def[[AF2]] = $Class[[Foo]]();
-  $Class_deduced[[auto]] *$Variable_def[[AFP]] = &$Variable[[AF]];
+  $Class_deduced[[auto]] *$Variable_def[[AFP]] = $Operator[[&]]$Variable[[AF]];
   $Enum_deduced[[auto]] &$Variable_def[[AER]] = $Variable[[AE]];
-  $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 + 2 * 4;
+  $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 $Operator[[+]] 2 $Operator[[*]] 4;
   $Primitive_deduced_defaultLibrary[[decltype]]($Variable[[Form]]) $Variable_def[[F]] = 10;
   auto $Variable_def[[Fun]] = []()->void{};
 )cpp",
@@ -342,21 +342,21 @@
   template
   class $Class_def[[IP]] {
 void $Method_def[[f]]() {
-  *$TemplateParameter_readonly[[U]] += 5;
+  $Operator[[*]]$TemplateParameter_readonly[[U]] $Operator[[+=]] 5;
 }
   };
   template
   class $Class_def[[Foo]] {
 void $Method_def[[f]]() {
   for(int $LocalVariable_def[[I]] = 0;
-$LocalVariable[

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

2022-10-24 Thread Zahira Ammarguellat via Phabricator via cfe-commits

zahiraam added a comment.

In D109239#3878422 , @ArcsinX wrote:

> It seems for x86_32 case (e.g. with -m32 in command line) there is a 
> difference between clang and GCC:
> clang: `__FLT_EVAL_METHOD__` == 0
> GCC: `__FLT_EVAL_METHOD__` == 2
>
> Example:
> https://godbolt.org/z/EbY8rPYGn
>
> I am not sure, is it a correct behavior from clang?

For 32-bit x86 targets, GCC defaults to -mfpmath=387 (no SSE). Passing 
-mfpmath=sse to GCC will use source precision. 
Clang’s 32-bit x86 targets defaults to using SSE instructions and evaluating at 
source precision. Clang doesn’t allow -mfpmath=387 
unless it’s passed along with -mno-sse which is redundant. Using -m32 (or 
-mfpmath=387) in combination with
-mno-sse will give you GCC’s default behavior. See 
https://godbolt.org/z/4d8fqzqEs


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

https://reviews.llvm.org/D109239

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

[PATCH] D136451: GH58368: Correct concept checking in a lambda defined in concept

2022-10-24 Thread 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.

It looks like precommit CI caught a failing test case that should be fixed 
before landing, but otherwise this LGTM.


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

https://reviews.llvm.org/D136451

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

[PATCH] D136545: [Clang] use non-template function declaration for constraints partial ordering

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane accepted this revision.
erichkeane added inline comments.



Comment at: clang/test/CXX/over/over.match/over.match.best/p2.cpp:10
   };
-  bool k1 = A() < A(); // not ordered by constraints: prefer 
non-rewritten form
-  bool k2 = A() < A(); // prefer more-constrained 'operator<=>'

ychen wrote:
> Remove this case because it compiles by accident. 
> https://eel.is/c++draft/over.match#best.general-2.6 take precedence over 
> https://eel.is/c++draft/over.match#best.general-2.8.
Could you instead replace it with a better comment + a 'fixme' or something if 
we need to fix it in the future?  I don't want to lose the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136545

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

[PATCH] D136545: [Clang] use non-template function declaration for constraints partial ordering

2022-10-24 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov accepted this revision.
mizvekov added a comment.

LGTM as well!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136545

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

[PATCH] D136533: Fix missing diagnostic of declaration use when accessing TypeDecls through typename access

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane accepted this revision.
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:176
+  auto *FoundRD = dyn_cast(TD);
+  if (DCK != DiagCtorKind::None && LookupRD && FoundRD &&
+  FoundRD->isInjectedClassName() &&

So I know our coding standard is a little awkward here, but I'd prefer curley 
braces here.  I think the 'size' of the Diag line here qualifies as 'multiple 
lines'.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136533

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

[PATCH] D136566: [clang] Instantiate concepts with sugared template arguments

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

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

This is an improvement, thanks!




Comment at: clang/lib/Sema/SemaConcept.cpp:1079
   MultiLevelTemplateArgumentList MLTAL = S.getTemplateInstantiationArgs(
-  CSE->getNamedConcept(), /*Final=*/false, &TAL,
+  CSE->getNamedConcept(), /*Final=*/true, &TAL,
   /*RelativeToPrimary=*/true,

Comment here should be "RelativeToPrimary=" I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136566

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

[clang] b7c9226 - GH58368: Correct concept checking in a lambda defined in concept

2022-10-24 Thread Erich Keane via cfe-commits


Author: Erich Keane
Date: 2022-10-24T06:32:18-07:00
New Revision: b7c922607c5ba93db8b893d4ba461052af8317b5

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

LOG: GH58368: Correct concept checking in a lambda defined in concept

As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
template arguments from the concept.  SO, we failed to get the correct
template arguments in SemaTemplateInstantiate.

However, a Concept Specialization is NOT a decl, its an expression, so
we weren't able to put the concept in the decl tree like we needed.
This patch introduces a ConceptSpecializationDecl, which is the smallest
type possible to use for this purpose, containing only the template
arguments.

The net memory impliciation of this is turning a
trailing-objects into a pointer to a type with trailing-objects,  so it
should be minor.

As future work, we may consider giving this type more responsibility, or
figuring out how to better merge duplicates, but as this is just a
template-argument collection at the moment, there isn't much value to
it.

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

Added: 


Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/ExprConcepts.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Basic/DeclNodes.td
clang/include/clang/Serialization/ASTBitCodes.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/DeclBase.cpp
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/ExprConcepts.cpp
clang/lib/CodeGen/CGDecl.cpp
clang/lib/Sema/SemaConcept.cpp
clang/lib/Sema/SemaLambda.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTCommon.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/test/AST/ast-dump-concepts.cpp
clang/test/SemaTemplate/concepts-lambda.cpp
clang/tools/libclang/CIndex.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index 44dc52b419af5..6df3a83b6404a 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -623,7 +623,14 @@ class ASTNodeTraverser
 Visit(D->getConstraintExpr());
   }
 
+  void VisitImplicitConceptSpecializationDecl(
+  const ImplicitConceptSpecializationDecl *CSD) {
+for (const TemplateArgument &Arg : CSD->getTemplateArguments())
+  Visit(Arg);
+  }
+
   void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *CSE) {
+Visit(CSE->getSpecializationDecl());
 if (CSE->hasExplicitTemplateArgs())
   for (const auto &ArgLoc : CSE->getTemplateArgsAsWritten()->arguments())
 dumpTemplateArgumentLoc(ArgLoc);

diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index ae10744383559..d1dfe73a51182 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -3259,7 +3259,7 @@ class VarTemplateDecl : public RedeclarableTemplateDecl {
   static bool classofKind(Kind K) { return K == VarTemplate; }
 };
 
-/// Declaration of a C++2a concept.
+/// Declaration of a C++20 concept.
 class ConceptDecl : public TemplateDecl, public Mergeable {
 protected:
   Expr *ConstraintExpr;
@@ -3304,6 +3304,40 @@ class ConceptDecl : public TemplateDecl, public 
Mergeable {
   friend class ASTDeclWriter;
 };
 
+// An implementation detail of ConceptSpecialicationExpr that holds the 
template
+// arguments, so we can later use this to reconstitute the template arguments
+// during constraint checking.
+class ImplicitConceptSpecializationDecl final
+: public Decl,
+  private llvm::TrailingObjects {
+  unsigned NumTemplateArgs;
+
+  ImplicitConceptSpecializationDecl(DeclContext *DC, SourceLocation SL,
+ArrayRef ConvertedArgs);
+  ImplicitConceptSpecializationDecl(EmptyShell Empty, unsigned 
NumTemplateArgs);
+
+public:
+  static ImplicitConceptSpecializationDecl *
+  Create(const ASTContext &C, DeclContext *DC, SourceLocation SL,
+ ArrayRef ConvertedArgs);
+  static ImplicitConceptSpecializationDecl *
+  CreateDeserialized(const ASTContext &C, unsigned ID,
+ unsigned NumTemplateArgs);
+
+  ArrayRef getTemplateArguments() const {
+return ArrayRef(getTrailingObjects(),
+  NumTemplateArgs);
+  }
+  void setTemplateArguments(Arr

[PATCH] D136451: GH58368: Correct concept checking in a lambda defined in concept

2022-10-24 Thread Erich Keane 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 rGb7c922607c5b: GH58368: Correct concept checking in a lambda 
defined in concept (authored by erichkeane).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D136451?vs=469696&id=470128#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136451

Files:
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/ExprConcepts.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/ExprConcepts.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/AST/ast-dump-concepts.cpp
  clang/test/SemaTemplate/concepts-lambda.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -6700,6 +6700,7 @@
   case Decl::PragmaDetectMismatch:
   case Decl::UsingPack:
   case Decl::Concept:
+  case Decl::ImplicitConceptSpecialization:
   case Decl::LifetimeExtendedTemporary:
   case Decl::RequiresExprBody:
   case Decl::UnresolvedUsingIfExists:
Index: clang/test/SemaTemplate/concepts-lambda.cpp
===
--- clang/test/SemaTemplate/concepts-lambda.cpp
+++ clang/test/SemaTemplate/concepts-lambda.cpp
@@ -55,3 +55,39 @@
   using function_ptr = void(*)(int);
   function_ptr ptr = f;
 }
+
+// GH58368: A lambda defined in a concept requires we store
+// the concept as a part of the lambda context.
+namespace LambdaInConcept {
+using size_t = unsigned long;
+
+template
+struct IdxSeq{};
+
+template 
+concept NotLike = true;
+
+template 
+struct AnyExcept {
+  template  T> operator T&() const;
+  template  T> operator T&&() const;
+};
+
+template 
+  concept ConstructibleWithN = (requires {
+[]
+(IdxSeq)
+requires requires { T{AnyExcept{}}; }
+{ }
+(IdxSeq<1,2,3>{});
+});
+
+struct Foo {
+  int i;
+  double j;
+  char k;
+};
+
+static_assert(ConstructibleWithN);
+
+}
Index: clang/test/AST/ast-dump-concepts.cpp
===
--- clang/test/AST/ast-dump-concepts.cpp
+++ clang/test/AST/ast-dump-concepts.cpp
@@ -19,6 +19,11 @@
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-ConceptSpecializationExpr {{.*}}  'bool' Concept {{.*}} 'binary_concept'
+  // CHECK-NEXT:   |-ImplicitConceptSpecializationDecl {{.*}}  col:9
+  // CHECK-NEXT:   | |-TemplateArgument type 'type-parameter-1-0'  
+  // CHECK-NEXT:   | | `-TemplateTypeParmType {{.*}} 'type-parameter-1-0' dependent {{.*}}depth 1 index 0
+  // CHECK-NEXT:   | `-TemplateArgument type 'int'
+  // CHECK-NEXT:   |   `-BuiltinType {{.*}} 'int'
   // CHECK-NEXT:   |-TemplateArgument {{.*}} type 'R'
   // CHECK-NEXT:   | `-TemplateTypeParmType {{.*}} 'R'
   // CHECK-NEXT:   |   `-TemplateTypeParm {{.*}} 'R'
@@ -29,6 +34,9 @@
 
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 'unary_concept'
   // CHECK-NEXT: `-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT:   |-ImplicitConceptSpecializationDecl {{.*}}  col:9
+  // CHECK-NEXT:   | `-TemplateArgument type 'type-parameter-1-0'
+  // CHECK-NEXT:   |   `-TemplateTypeParmType {{.*}} 'type-parameter-1-0' dependent {{.*}}depth 1 index 0
   template 
   Foo(R);
 
Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -433,16 +433,13 @@
 void ASTStmtWriter::VisitConceptSpecializationExpr(
 ConceptSpecializationExpr *E) {
   VisitExpr(E);
-  ArrayRef TemplateArgs = E->getTemplateArguments();
-  Record.push_back(TemplateArgs.size());
   Record.AddNestedNameSpecifierLoc(E->getNestedNameSpecifierLoc());
   Record.AddSourceLocation(E->getTemplateKWLoc());
   Record.AddDeclarationNameInfo(E->getConceptNameInfo());
   Record.AddDeclRef

[PATCH] D136566: [clang] Instantiate concepts with sugared template arguments

2022-10-24 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1079
   MultiLevelTemplateArgumentList MLTAL = S.getTemplateInstantiationArgs(
-  CSE->getNamedConcept(), /*Final=*/false, &TAL,
+  CSE->getNamedConcept(), /*Final=*/true, &TAL,
   /*RelativeToPrimary=*/true,

erichkeane wrote:
> Comment here should be "RelativeToPrimary=" I think.
This is a new parameter introduced in D134604, you would have to read that 
dependency first to figure that out :)
I forgot to mention that on the description of this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136566

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

[PATCH] D136566: [clang] Instantiate concepts with sugared template arguments

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaConcept.cpp:1079
   MultiLevelTemplateArgumentList MLTAL = S.getTemplateInstantiationArgs(
-  CSE->getNamedConcept(), /*Final=*/false, &TAL,
+  CSE->getNamedConcept(), /*Final=*/true, &TAL,
   /*RelativeToPrimary=*/true,

mizvekov wrote:
> erichkeane wrote:
> > Comment here should be "RelativeToPrimary=" I think.
> This is a new parameter introduced in D134604, you would have to read that 
> dependency first to figure that out :)
> I forgot to mention that on the description of this patch.
Ah!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136566

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

[PATCH] D134604: [clang] Implement sugared substitution changes to infrastructure

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane accepted this revision.
erichkeane added a comment.

A couple of nits, otherwise I don't have to see this again.




Comment at: clang/include/clang/AST/TemplateName.h:158
+  // When true the substitution will be finalized (subst node won't be placed).
+  bool getFinal() const;
+

Based on this comment, should this be 'Finalize' instead of 'Final'?  Or 
something like "ShouldFinalize"?



Comment at: clang/include/clang/Sema/Template.h:104
 /// Construct a single-level template argument list.
-MultiLevelTemplateArgumentList(Decl *D, ArgList Args) {
-  addOuterTemplateArguments(D, Args);
+MultiLevelTemplateArgumentList(Decl *D, ArgList Args, bool Final) {
+  addOuterTemplateArguments(D, Args, Final);

Hrmph, this additional flag likely requires rebasing/rebuilding on a patch I 
just committed, which uses this MLTAL again.  Hopefully not too bad to 
propagate.



Comment at: clang/lib/AST/ASTContext.cpp:3045
+static bool
+getCanonicalTemplateArguments(const ASTContext &C,
+  ArrayRef OrigArgs,

typically we name these sorts of things based on their return type, so this 
would be more `hasCanonicalTemplateArguments`.  BUT the modifying nature of it 
makes this an awkward function all the same.

I think I'd suggest putting both of the 'output's here on the same side of the 
function, either both a return, or both an out-param, so the name isn't 
ambiguous/confusing like this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134604

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

[PATCH] D136528: [clang][Interp] Implement add and sub compound assign operators

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:412
+
+  constexpr int getTwo() {
+int i = 1;

I'd also like some test cases where the result of the operation is discarded. 
e.g.,
```
constexpr int func() {
  int i = 12;
  i += 10;
  return i;
}
static_assert(func() == 22);
```
and a test with a float-point type (okay for it to fail for the moment):
```
constexpr float func() {
  float f = 1.0f;
  f += 10.0f;
  return f;
}
static_assert(func() == 11.0f);
```



Comment at: clang/test/AST/Interp/literals.cpp:426
+  }
+  static_assert(subAll(213) == 0);
+

We also need tests for failure situations:
```
constexpr int func() {
  int i = __INT_MAX__;
  i += 1; // oops
  return i;
}

constexpr int another() {
  int i = __INT_MIN__;
  i -= 1; // oops
  return i;
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136528

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

[PATCH] D136528: [clang][Interp] Implement add and sub compound assign operators

2022-10-24 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 470138.
tbaeder marked 2 inline comments as done.

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

https://reviews.llvm.org/D136528

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/test/AST/Interp/literals.cpp

Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -420,5 +420,46 @@
  // expected-note {{in call to 'UnderFlow()'}} \
  // ref-error {{not an integral constant expression}} \
  // ref-note {{in call to 'UnderFlow()'}}
+
+  constexpr int getTwo() {
+int i = 1;
+return (i += 1);
+  }
+  static_assert(getTwo() == 2, "");
+
+  constexpr int sub(int a) {
+return (a -= 2);
+  }
+  static_assert(sub(7) == 5, "");
+
+  constexpr int add(int a, int b) {
+a += b; // expected-note {{is outside the range of representable values}} \
+// ref-note {{is outside the range of representable values}} 
+return a;
+  }
+  static_assert(add(1, 2) == 3, "");
+  static_assert(add(INT_MAX, 1) == 0, ""); // expected-error {{not an integral constant expression}} \
+   // expected-note {{in call to 'add}} \
+   // ref-error {{not an integral constant expression}} \
+   // ref-note {{in call to 'add}}
+
+  constexpr int sub(int a, int b) {
+a -= b; // expected-note {{is outside the range of representable values}} \
+// ref-note {{is outside the range of representable values}} 
+return a;
+  }
+  static_assert(sub(10, 20) == -10, "");
+  static_assert(sub(INT_MIN, 1) == 0, ""); // expected-error {{not an integral constant expression}} \
+   // expected-note {{in call to 'sub}} \
+   // ref-error {{not an integral constant expression}} \
+   // ref-note {{in call to 'sub}}
+
+
+
+
+  constexpr int subAll(int a) {
+return (a -= a);
+  }
+  static_assert(subAll(213) == 0, "");
 };
 #endif
Index: clang/lib/AST/Interp/ByteCodeExprGen.h
===
--- clang/lib/AST/Interp/ByteCodeExprGen.h
+++ clang/lib/AST/Interp/ByteCodeExprGen.h
@@ -89,6 +89,7 @@
   bool VisitCharacterLiteral(const CharacterLiteral *E);
   bool VisitExprWithCleanups(const ExprWithCleanups *E);
   bool VisitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *E);
+  bool VisitCompoundAssignOperator(const CompoundAssignOperator *E);
 
 protected:
   bool visitExpr(const Expr *E) override;
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -564,6 +564,57 @@
   return false;
 }
 
+template 
+bool ByteCodeExprGen::VisitCompoundAssignOperator(
+const CompoundAssignOperator *E) {
+  const Expr *LHS = E->getLHS();
+  const Expr *RHS = E->getRHS();
+  Optional LT = classify(E->getLHS()->getType());
+  Optional RT = classify(E->getRHS()->getType());
+
+  if (!LT || !RT)
+return false;
+
+  assert(!E->getType()->isPointerType() &&
+ "Support pointer arithmethic in compound assignment operators");
+
+  // Get LHS pointer, load its value and get RHS value.
+  if (!visit(LHS))
+return false;
+  if (!this->emitLoad(*LT, E))
+return false;
+  if (!visit(RHS))
+return false;
+
+  // Perform operation.
+  switch (E->getOpcode()) {
+  case BO_AddAssign:
+if (!this->emitAdd(*LT, E))
+  return false;
+break;
+  case BO_SubAssign:
+if (!this->emitSub(*LT, E))
+  return false;
+break;
+
+  case BO_MulAssign:
+  case BO_DivAssign:
+  case BO_RemAssign:
+  case BO_ShlAssign:
+  case BO_ShrAssign:
+  case BO_AndAssign:
+  case BO_XorAssign:
+  case BO_OrAssign:
+  default:
+llvm_unreachable("Unimplemented compound assign operator");
+  }
+
+  // And store the result in LHS.
+  if (DiscardResult)
+return this->emitStorePop(*LT, E);
+  return this->emitStore(*LT, E);
+}
+
 template  bool ByteCodeExprGen::discard(const Expr *E) {
   OptionScope Scope(this, /*NewDiscardResult=*/true);
   return this->Visit(E);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136528: [clang][Interp] Implement add and sub compound assign operators

2022-10-24 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:426
+  }
+  static_assert(subAll(213) == 0);
+

aaron.ballman wrote:
> We also need tests for failure situations:
> ```
> constexpr int func() {
>   int i = __INT_MAX__;
>   i += 1; // oops
>   return i;
> }
> 
> constexpr int another() {
>   int i = __INT_MIN__;
>   i -= 1; // oops
>   return i;
> }
> ```
woops, I was sure I added this but it was for the `++`/`--` patch it seems.


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

https://reviews.llvm.org/D136528

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

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1237-1240
+if (DiscardResult)
+  return this->emitIncPop(*T, E);
+
+return this->emitInc(*T, E);

Style question: should we prefer doing something like: `return DiscardResult ? 
this->emitIncPop(*T, E) : this->emitInc(*T, E);` to discourage accidentally 
adding code between the two increment operations? (And applying this style more 
generally for discarded results?)

Alternatively, do we want to add a helper function to `ByteCodeExprGen` called 
`doEmitInc()` that hides the discarded result behavior so the `Visit*` 
functions don't have to keep doing that dance?



Comment at: clang/lib/AST/Interp/Interp.h:331
 
+template 
+bool IncDecHelper(InterpState &S, CodePtr OpPC, const Pointer &Ptr) {

Do we want to use enums for `IsInc` and `PushVal` so that call sites use 
`IncDeclHelper` for clarity?



Comment at: clang/lib/AST/Interp/Interp.h:370-373
+  } else {
+S.CCEDiag(E, diag::note_constexpr_overflow) << APResult << Type;
+return S.noteUndefinedBehavior();
+  }





Comment at: clang/test/AST/Interp/literals.cpp:376
+  static_assert(zero() == 0, "");
+
+  constexpr int three() {

I'd like some tests that the computed values are correct.
```
constexpr int zero() {
  int a = 0;
  return a++;
}
static_assert(zero() == 0);

constexpr int one() {
  int a = 0;
  return ++a;
}
static_assert(one() == 1);

constexpr int zero_again() {
  int a = 0;
  return a--;
}
static_assert(zero_again() == 0);

constexpr int neg_one() {
  int a = 0;
  return --a;
}
static_assert(neg_one() == -1);
```


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

https://reviews.llvm.org/D136423

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

[PATCH] D136528: [clang][Interp] Implement add and sub compound assign operators

2022-10-24 Thread 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!


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

https://reviews.llvm.org/D136528

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

[PATCH] D134128: Resubmit an implemention for constrained template template parameters [P0857R0 Part B]

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

I'm reasonably OK with this, I'm disappointed the 'skip for specialization' is 
what was required, but I don't think I know of a better way.  I'll hold off 
approving this until I've confirmed that libcxx tests + libcxx-modules-tests 
are properly passing as a result of this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134128

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

[PATCH] D134128: Resubmit an implemention for constrained template template parameters [P0857R0 Part B]

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

ALSO; this is missing the cxx_status.html and release-notes, so please re-add 
those!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134128

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

[PATCH] D135557: Add needsImplicitDefaultConstructor and friends

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D135557#3872324 , @dblaikie wrote:

> In D135557#3871803 , @aaron.ballman 
> wrote:
>
>> In D135557#3871716 , @dblaikie 
>> wrote:
>>
>>> (I'm still sort of curious how the AST matchers deal with all this - I 
>>> guess they must have Sema available, because I'd assume they make all sorts 
>>> of queries like "is this constructible from that" - since they're often 
>>> trying to generate new code and want to know what constructs will be valid, 
>>> which is different from the indexing use case, admittedly)
>>
>> Nope, AST matchers don't have Sema available, so they don't have a way to 
>> query "is this constructible from that". You've got the AST itself (and the 
>> `ASTContext`) and not a whole lot else beyond that.
>
> Huh, that quite surprises me as to how some transformations are implemented 
> in that situation. I guess maybe the more syntactically interesting ones are 
> actual clang warnings with fixits, exposed via clang-tidy, so they have sema 
> and all.

Yup! That's how clang-tidy can appear to have sema-related diagnostics.

In D135557#3872411 , @royjacobson 
wrote:

> I would be more comfortable with exposing something like 
> `clang_CXXRecord_hasAnyNonDeletedDefaultConstructor`. It's better than the 
> confusing `clang_CXXRecord_needsImplicitDefaultConstructor` but it would 
> still be different from the usual type traits in a subtle way. For the other 
> special member functions that would be enough, we can use 
> `!CXXMethod::isIneligibleOrNotSelected()` to know if their constraints are 
> satisfied and there's no SFINAE problems because except for default 
> constructors they're not allowed to be templates.

I would be comfortable with such an API as that's no longer an implementation 
detail of our AST.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135557

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

[PATCH] D136602: NFC: [clang] Template argument cleanups.

2022-10-24 Thread Matheus Izvekov via Phabricator via cfe-commits

mizvekov created this revision.
Herald added subscribers: carlosgalvezp, kadircet, arphaman, martong.
Herald added a reviewer: shafik.
Herald added a project: All.
mizvekov requested review of this revision.
Herald added projects: clang, clang-tools-extra.
Herald added a subscriber: cfe-commits.

Removes a bunch of obsolete methods in favor of a single one returning
an ArrayRef of TemplateArgument.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136602

Files:
  clang-tools-extra/clang-tidy/modernize/UseTransparentFunctorsCheck.cpp
  clang-tools-extra/clang-tidy/mpi/TypeMismatchCheck.cpp
  clang-tools-extra/clangd/HeuristicResolver.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TemplateBase.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTDiagnostic.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/ODRHash.cpp
  clang/lib/AST/QualTypeNames.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp

Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -463,8 +463,9 @@
 addSourceLocation(TL.getLAngleLoc());
 addSourceLocation(TL.getRAngleLoc());
 for (unsigned I = 0; I < TL.getNumArgs(); ++I)
-  Record.AddTemplateArgumentLocInfo(TL.getTypePtr()->getArg(I).getKind(),
-TL.getArgLocInfo(I));
+  Record.AddTemplateArgumentLocInfo(
+  TL.getTypePtr()->getTypeConstraintArguments()[I].getKind(),
+  TL.getArgLocInfo(I));
   }
   Record.push_back(TL.isDecltypeAuto());
   if (TL.isDecltypeAuto())
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -6690,8 +6690,9 @@
 TL.setLAngleLoc(readSourceLocation());
 TL.setRAngleLoc(readSourceLocation());
 for (unsigned i = 0, e = TL.getNumArgs(); i != e; ++i)
-  TL.setArgLocInfo(i, Reader.readTemplateArgumentLocInfo(
-  TL.getTypePtr()->getArg(i).getKind()));
+  TL.setArgLocInfo(
+  i, Reader.readTemplateArgumentLocInfo(
+ TL.getTypePtr()->getTypeConstraintArguments()[i].getKind()));
   }
   if (Reader.readBool())
 TL.setRParenLoc(readSourceLocation());
@@ -6739,10 +6740,9 @@
   TL.setLAngleLoc(readSourceLocation());
   TL.setRAngleLoc(readSourceLocation());
   for (unsigned i = 0, e = TL.getNumArgs(); i != e; ++i)
-TL.setArgLocInfo(
-i,
-Reader.readTemplateArgumentLocInfo(
-  TL.getTypePtr()->getArg(i).getKind()));
+TL.setArgLocInfo(i,
+ Reader.readTemplateArgumentLocInfo(
+ TL.getTypePtr()->template_arguments()[i].getKind()));
 }
 
 void TypeLocReader::VisitParenTypeLoc(ParenTypeLoc TL) {
@@ -6774,10 +6774,9 @@
   TL.setLAngleLoc(readSourceLocation());
   TL.setRAngleLoc(readSourceLocation());
   for (unsigned I = 0, E = TL.getNumArgs(); I != E; ++I)
-TL.setArgLocInfo(
-I,
-Reader.readTemplateArgumentLocInfo(
-TL.getTypePtr()->getArg(I).getKind()));
+TL.setArgLocInfo(I,
+ Reader.readTemplateArgumentLocInfo(
+ TL.getTypePtr()->template_arguments()[I].getKind()));
 }
 
 void TypeLocReader::VisitPackExpansionTypeLoc(PackExpansionTypeLoc TL) {
Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -1106,10 +1106,9 @@
 
 // If it's still dependent, make a dependent specialization.
 if (InstName.getAsDependentTemplateName())
-  return SemaRef.Context.getDependentTemplateSpecializationType(Keyword,
-  QualifierLoc.getNestedNameSpecifier(),
-Name,
-Args);
+  return SemaRef.Context.getDependentTemplateSpecializationType(
+  Keyword, QualifierLoc.getNestedNameSpecifier(), Name,
+  Args.arguments());
 
 // Otherwise, make an elaborated type

[PATCH] D136570: [RISCV] Add Svnapot extension

2022-10-24 Thread Philip Reames via Phabricator via cfe-commits

reames added a comment.

https://llvm.org/docs/RISCVUsage.html#extensions needs to updated after this 
change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136570

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

[PATCH] D136603: [analyzer] Model cast after LValueToRValueBitCasts

2022-10-24 Thread Balázs Benics via Phabricator via cfe-commits

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

Casting a pointer to a suitably large integral type by reinterpret-cast
should result in the same value as by using the `__builtin_bit_cast()`.
The compiler exploits this: https://godbolt.org/z/zMP3sG683

However, the analyzer does not bind the same symbolic value to these
expressions, resulting in weird situations, such as failing equality
checks and even results in crashes: https://godbolt.org/z/oeMP7cj8q

Previously, the `&SymRegion` were not cast to `NonLoc`, which later in
the `evalBinOpLN()` caused a crash when the engine wanted to calculate
the offset at the BinaryOperator expression.
So, in this patch, I'm proposing to add an explicit cast when evaluating
an `LValueToRValueBitCast` cast expression. Other than casting the
resulting value to the given type before binding it to the expression it
does the same thing that we do for `LValueToRValue` casts.

Here is a snippet of code, annotated by the previous and new dump values.
`LocAsInteger` wraps the `SymRegion` in only two cases:

  void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) {
clang_analyzer_dump(p); // remained: &SymRegion{reg_$0}
clang_analyzer_dump(array); // remained: {{&SymRegion{reg_$1}
clang_analyzer_dump((unsigned long)p);
// remained: {{&SymRegion{reg_$0} [as 64 bit integer]}}
clang_analyzer_dump(__builtin_bit_cast(unsigned long, p)); <- 
change #1
// previously: {{&SymRegion{reg_$0}}}
// now:{{&SymRegion{reg_$0} [as 64 bit integer]}}
clang_analyzer_dump((unsigned long)array); // remained: 
{{&SymRegion{reg_$1} [as 64 bit integer]}}
clang_analyzer_dump(__builtin_bit_cast(unsigned long, array)); <- 
change #2
// previously: {{&SymRegion{reg_$1}}}
// now:{{&SymRegion{reg_$1} [as 64 bit integer]}}
  }

PS: I'm not sure how/when we should get rid of the `LocAsInteger` and
represent this by a `SymbolCast`.
Maybe @ASDenysPetrov or @martong could help me review this.

This is a follow-up of D105017 , where I 
thought it should be enough to
model `LValueToRValueBitCast` the same way as we do with `LValueToRValueCast`.
I still think the same, but we really should have some `NonLoc` value here, IMO.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136603

Files:
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/Analysis/ptr-arith.cpp


Index: clang/test/Analysis/ptr-arith.cpp
===
--- clang/test/Analysis/ptr-arith.cpp
+++ clang/test/Analysis/ptr-arith.cpp
@@ -1,4 +1,5 @@
-// RUN: %clang_analyze_cc1 -Wno-unused-value -std=c++14 
-analyzer-checker=core,debug.ExprInspection,alpha.core.PointerArithm -verify %s
+// RUN: %clang_analyze_cc1 -Wno-unused-value -std=c++14 -verify %s -triple 
x86_64-pc-linux-gnu \
+// RUN:-analyzer-checker=core,debug.ExprInspection,alpha.core.PointerArithm
 
 template  void clang_analyzer_dump(T);
 
@@ -141,3 +142,22 @@
   return bits->b; // no-warning
 }
 } // namespace Bug_55934
+
+void LValueToRValueBitCast_dumps(void *p, char (*array)[8]) {
+  clang_analyzer_dump(p);
+  clang_analyzer_dump(array);
+  // expected-warning@-2 {{&SymRegion{reg_$0}}}
+  // expected-warning@-2 {{&SymRegion{reg_$1}}}
+  clang_analyzer_dump((unsigned long)p);
+  clang_analyzer_dump(__builtin_bit_cast(unsigned long, p));
+  // expected-warning@-2 {{&SymRegion{reg_$0} [as 64 bit integer]}}
+  // expected-warning@-2 {{&SymRegion{reg_$0} [as 64 bit integer]}}
+  clang_analyzer_dump((unsigned long)array);
+  clang_analyzer_dump(__builtin_bit_cast(unsigned long, array));
+  // expected-warning@-2 {{&SymRegion{reg_$1} [as 64 bit 
integer]}}
+  // expected-warning@-2 {{&SymRegion{reg_$1} [as 64 bit 
integer]}}
+}
+
+unsigned long ptr_arithmetic(void *p) {
+  return __builtin_bit_cast(unsigned long, p) + 1; // no-crash
+}
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -288,8 +288,36 @@
   ExplodedNodeSet dstPreStmt;
   getCheckerManager().runCheckersForPreStmt(dstPreStmt, Pred, CastE, *this);
 
-  if (CastE->getCastKind() == CK_LValueToRValue ||
-  CastE->getCastKind() == CK_LValueToRValueBitCast) {
+  if (CastE->getCastKind() == CK_LValueToRValueBitCast) {
+// Do the same as for 'CK_LValueToRValue' but cast the resulting value to
+// the appropriate type before binding.
+for (ExplodedNode *subExprNode : dstPreStmt) {
+  ProgramStateRef state = subExprNode->getState();
+

[PATCH] D136604: Add clang_CXXMethod_isCopyAssignmentOperator to libclang

2022-10-24 Thread Luca Di sera via Phabricator via cfe-commits

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

The new method is a wrapper of `CXXMethodDecl::isCopyAssignmentOperator` and
can be used to recognized copy-assignment operators in libclang.

An export for the method, together with its documentation, was added to
"clang/include/clang-c/Index.h" with an implementation provided in
"clang/tools/libclang/CIndex.cpp". The implementation was based on
similar `clang_CXXMethod.*` implementations, following the same
structure but calling `CXXMethodDecl::isCopyAssignmentOperator` for its
main logic.

The new symbol was further added to "clang/tools/libclang/libclang.map"
to be exported, under the LLVM16 tag.

"clang/tools/c-index-test/c-index-test.c" was modified to print a
specific tag, "(copy-assignment operator)", for cursors that are
recognized by `clang_CXXMethod_isCopyAssignmentOperator`.
A new regression test file,
"clang/test/Index/copy-assignment-operator.cpp", was added to ensure
that the correct constructs were recognized or not by the new function.

The "clang/test/Index/get-cursor.cpp" regression test file was updated
as it was affected by the new "(copy-assignment operator)" tag.

A binding for the new function was added to libclang's python's
bindings, in "clang/bindings/python/clang/cindex.py", adding a new
method for `Cursor`, `is_copy_assignment_operator_method`.

The current release note, `clang/docs/ReleaseNotes.rst`, was modified to
report the new addition under the "libclang" section.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136604

Files:
  clang/bindings/python/clang/cindex.py
  clang/docs/ReleaseNotes.rst
  clang/include/clang-c/Index.h
  clang/test/Index/copy-assignment-operator.cpp
  clang/test/Index/get-cursor.cpp
  clang/tools/c-index-test/c-index-test.c
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/libclang.map

Index: clang/tools/libclang/libclang.map
===
--- clang/tools/libclang/libclang.map
+++ clang/tools/libclang/libclang.map
@@ -410,6 +410,7 @@
 clang_getUnqualifiedType;
 clang_getNonReferenceType;
 clang_CXXMethod_isDeleted;
+clang_CXXMethod_isCopyAssignmentOperator;
 };
 
 # Example of how to add a new symbol version entry.  If you do add a new symbol
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -8898,6 +8898,17 @@
   return (Method && Method->isVirtual()) ? 1 : 0;
 }
 
+unsigned clang_CXXMethod_isCopyAssignmentOperator(CXCursor C) {
+  if (!clang_isDeclaration(C.kind))
+return 0;
+
+  const Decl *D = cxcursor::getCursorDecl(C);
+  const CXXMethodDecl *Method =
+  D ? dyn_cast_or_null(D->getAsFunction()) : nullptr;
+
+  return (Method && Method->isCopyAssignmentOperator()) ? 1 : 0;
+}
+
 unsigned clang_CXXRecord_isAbstract(CXCursor C) {
   if (!clang_isDeclaration(C.kind))
 return 0;
Index: clang/tools/c-index-test/c-index-test.c
===
--- clang/tools/c-index-test/c-index-test.c
+++ clang/tools/c-index-test/c-index-test.c
@@ -910,6 +910,8 @@
   printf(" (const)");
 if (clang_CXXMethod_isPureVirtual(Cursor))
   printf(" (pure)");
+if (clang_CXXMethod_isCopyAssignmentOperator(Cursor))
+  printf(" (copy-assignment operator)");
 if (clang_CXXRecord_isAbstract(Cursor))
   printf(" (abstract)");
 if (clang_EnumDecl_isScoped(Cursor))
Index: clang/test/Index/get-cursor.cpp
===
--- clang/test/Index/get-cursor.cpp
+++ clang/test/Index/get-cursor.cpp
@@ -226,7 +226,7 @@
 // RUN: c-index-test -cursor-at=%s:69:3 -cursor-at=%s:70:11 -cursor-at=%s:73:6 -cursor-at=%s:74:6 -cursor-at=%s:77:8 -cursor-at=%s:78:8 -cursor-at=%s:79:8 -cursor-at=%s:80:8 -cursor-at=%s:81:8 -cursor-at=%s:82:8 -cursor-at=%s:85:6 -cursor-at=%s:86:6 -cursor-at=%s:87:6 -cursor-at=%s:88:6 -cursor-at=%s:91:5 -cursor-at=%s:92:5 -cursor-at=%s:93:5 -cursor-at=%s:94:5 -cursor-at=%s:95:5 -cursor-at=%s:96:5 -cursor-at=%s:97:5 -cursor-at=%s:98:5 -cursor-at=%s:100:5 -cursor-at=%s:101:5 -cursor-at=%s:104:6 -cursor-at=%s:105:6 -cursor-at=%s:106:6 -cursor-at=%s:107:6 -cursor-at=%s:108:6 -cursor-at=%s:109:6 -cursor-at=%s:110:6 -cursor-at=%s:111:6 -cursor-at=%s:113:6 -cursor-at=%s:114:6 -cursor-at=%s:117:8 -cursor-at=%s:118:8 -cursor-at=%s:120:8 -cursor-at=%s:121:8 -cursor-at=%s:122:8 -cursor-at=%s:123:8 -cursor-at=%s:124:8 -cursor-at=%s:125:8 -cursor-at=%s:128:6 -cursor-at=%s:129:6 -cursor-at=%s:130:6 -cursor-at=%s:132:3 -cursor-at=%s:146:15 -cursor-at=%s:149:6 -cursor-at=%s:150:25 -cursor-at=%s:151:6 -cursor-at=%s:152:6 -cursor-at=%s:153:6 -cursor-at=%s:154:6 -c

[PATCH] D136571: [RISCV] add svinval extension

2022-10-24 Thread Philip Reames via Phabricator via cfe-commits

reames added a comment.

Please update https://llvm.org/docs/RISCVUsage.html#extensions

It seems like we'd previously accept these instruction without the extension 
being explicitly named?  If so, this is probably worth a release note to 
document the change in user behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136571

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

[PATCH] D136554: [WIP] Implement CWG2631

2022-10-24 Thread Corentin Jabot via Phabricator via cfe-commits

cor3ntin updated this revision to Diff 470154.
cor3ntin added a comment.

Complete implementation for default member initializers,
tests, cleaups, docs, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136554

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/CXX/class/class.local/p1-0x.cpp
  clang/test/SemaCXX/cxx2a-consteval-default-params.cpp

Index: clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx2a-consteval-default-params.cpp
@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++2b %s
+
+
+consteval int undefined();  // expected-note 4{{declared here}}
+
+void check_lambdas_unused(
+int a = []
+{
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}(),
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) {
+return defaulted;
+}()
+) {}
+
+int check_lambdas_used(
+int b = [](int no_error = undefined()) {
+return no_error;
+}(0),
+int c = [](int defaulted = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return defaulted;
+}()  // expected-note {{in the default initalizer of 'defaulted'}}
+) {
+return 0;
+}
+
+int test_check_lambdas_used = check_lambdas_used();
+
+struct UnusedInitWithLambda {
+int a = [] {
+return undefined();  // expected-error {{not a constant expression}} \
+ // expected-note  {{undefined function 'undefined'}}
+}();
+int b = [](int no_error = undefined()) {
+return no_error;
+}();
+};
+
+struct InitWithLambda {
+int b = [](int error = undefined()) { // expected-error {{not a constant expression}} \
+  // expected-note  {{declared here}} \
+  // expected-note  {{undefined function 'undefined'}}
+return error;
+}(); // expected-note {{in the default initalizer of 'error'}}
+} i; // expected-note {{in implicit default constructor}}
Index: clang/test/CXX/class/class.local/p1-0x.cpp
===
--- clang/test/CXX/class/class.local/p1-0x.cpp
+++ clang/test/CXX/class/class.local/p1-0x.cpp
@@ -11,8 +11,8 @@
 int x = 3; // expected-note{{'x' declared here}}
 struct C {
   int& x2 = x; // expected-error{{reference to local variable 'x' declared in enclosing lambda expression}}
-};
+}c; // expected-note {{required here}}
   };
-  C();
+  C(); // expected-note {{required here}}
 }
 
Index: clang/lib/Serialization/ASTWriterStmt.cpp
===
--- clang/lib/Serialization/ASTWriterStmt.cpp
+++ clang/lib/Serialization/ASTWriterStmt.cpp
@@ -1748,6 +1748,9 @@
   Record.AddDeclRef(E->getParam());
   Record.AddDeclRef(cast_or_null(E->getUsedContext()));
   Record.AddSourceLocation(E->getUsedLocation());
+  Record.push_back(E->hasRewrittenInit());
+  if (E->hasRewrittenInit())
+Record.AddStmt(E->getRewrittenExpr());
   Code = serialization::EXPR_CXX_DEFAULT_ARG;
 }
 
@@ -1756,6 +1759,9 @@
   Record.AddDeclRef(E->getField());
   Record.AddDeclRef(cast_or_null(E->getUsedContext()));
   Record.AddSourceLocation(E->getExprLoc());
+  Record.push_back(E->hasRewrittenInit());
+  if (E->hasRewrittenInit())
+Record.AddStmt(E->getRewrittenExpr());
   Code = serialization::EXPR_CXX_DEFAULT_INIT;
 }
 
Index: clang/lib/Serialization/ASTReaderStmt.cpp
===
--- clang/lib/Serialization/ASTReaderStmt.cpp
+++ clang/lib/Serialization/ASTReaderStmt.cpp
@@ -1828,6 +1828,9 @@
   E->Param = readDeclAs();
   E->UsedContext = readDeclAs();
   E->CXXDefaultArgExprBits.Loc = readSourceLocation();
+  E->CXXDefaultArgExprBits.HasRewrittenInit = Record.readInt();
+  if (E->CXXDefaultArgExprBits.HasRewrittenInit)
+*E->getTrailingObjects() = Record.readSubExpr();
 }
 
 void ASTStmtReader::VisitCXXDefaultInitExpr(CXXDefa

[PATCH] D136511: [RISCV][clang] Support RISC-V vectors in UninitializedValues.

2022-10-24 Thread Philip Reames via Phabricator via cfe-commits

reames accepted this revision.
reames 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/D136511/new/

https://reviews.llvm.org/D136511

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

[PATCH] D136293: [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

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



Comment at: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h:14
+#include "llvm/ADT/STLFunctionalExtras.h"
+#include 
+

kadircet wrote:
> sammccall wrote:
> > This is awful but: as mentioned on another patch, we can't actually use 
> > variant. AFAIK all C++17 *language* features are available, but LLVM 
> > supports apple clang 9.3, which doesn't provide  at all.
> > 
> > There's an IntrusiveVariant in review somewhere but seems stalled (and 
> > honestly the Intrusive part makes it pretty ugly to use).
> > 
> > I think for now our best option is a Kind enum and some kind of uintptr_t 
> > storage :-(
> right, i've seen that comment as well and wanted to pile up there. there are 
> already uses of `` in LLVM today, TableGen, DenseMap, CodeGen, 
> flang, pseudo, MLIR and lldb are some examples of big components. I don't see 
> what they're doing to compile those today.
as mentioned in 
https://discourse.llvm.org/t/rfc-bump-minimal-requirements-apple-clang-9-3-10-0-0-before-4th-tue-in-january/66156/7?u=kadircet,
 LLVM is already enforcing apple clang 10.0.0 effectively (and hopefully 
documentation will also change soon).

hence i am moving forward with this change. in the unlikely event of community 
taking a different approach (like downgrading the minimum requirements), i am 
more than happy to get rid of the std::variant usage here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136293

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

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 470159.
tbaeder marked 3 inline comments as done.

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

https://reviews.llvm.org/D136423

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/Opcodes.td
  clang/test/AST/Interp/arrays.cpp
  clang/test/AST/Interp/literals.cpp

Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -361,3 +361,88 @@
   constexpr double db = true;
   static_assert(db == 1.0, "");
 };
+
+#if __cplusplus > 201402L
+namespace IncDec {
+  constexpr int zero() {
+int a = 0;
+a++;
+++a;
+a--;
+--a;
+return a;
+  }
+  static_assert(zero() == 0, "");
+
+  constexpr int preInc() {
+int a = 0;
+return ++a;
+  }
+  static_assert(preInc() == 1, "");
+
+  constexpr int postInc() {
+int a = 0;
+return a++;
+  }
+  static_assert(postInc() == 0, "");
+
+  constexpr int preDec() {
+int a = 0;
+return --a;
+  }
+  static_assert(preDec() == -1, "");
+
+  constexpr int postDec() {
+int a = 0;
+return a--;
+  }
+  static_assert(postDec() == 0, "");
+
+  constexpr int three() {
+int a = 0;
+return ++a + ++a; // expected-warning {{multiple unsequenced modifications to 'a'}} \
+  // ref-warning {{multiple unsequenced modifications to 'a'}} \
+
+  }
+  static_assert(three() == 3, "");
+
+  constexpr bool incBool() {
+bool b = false;
+return ++b; // expected-error {{ISO C++17 does not allow incrementing expression of type bool}} \
+// ref-error {{ISO C++17 does not allow incrementing expression of type bool}}
+  }
+  static_assert(incBool(), "");
+
+  constexpr int uninit() {
+int a;
+++a; // ref-note {{increment of uninitialized}} \
+ // FIXME: Should also be rejected by new interpreter
+return 1;
+  }
+  static_assert(uninit(), ""); // ref-error {{not an integral constant expression}} \
+   // ref-note {{in call to 'uninit()'}}
+
+  constexpr int OverFlow() { // ref-error {{never produces a constant expression}}
+int a = INT_MAX;
+++a; // ref-note 2{{is outside the range}} \
+ // expected-note {{is outside the range}}
+return -1;
+  }
+  static_assert(OverFlow() == -1, "");  // expected-error {{not an integral constant expression}} \
+// expected-note {{in call to 'OverFlow()'}} \
+// ref-error {{not an integral constant expression}} \
+// ref-note {{in call to 'OverFlow()'}}
+
+
+  constexpr int UnderFlow() { // ref-error {{never produces a constant expression}}
+int a = INT_MIN;
+--a; // ref-note 2{{is outside the range}} \
+ // expected-note {{is outside the range}}
+return -1;
+  }
+  static_assert(UnderFlow() == -1, "");  // expected-error {{not an integral constant expression}} \
+ // expected-note {{in call to 'UnderFlow()'}} \
+ // ref-error {{not an integral constant expression}} \
+ // ref-note {{in call to 'UnderFlow()'}}
+};
+#endif
Index: clang/test/AST/Interp/arrays.cpp
===
--- clang/test/AST/Interp/arrays.cpp
+++ clang/test/AST/Interp/arrays.cpp
@@ -180,3 +180,18 @@
  constexpr int x = arr.a[0];
   }
 };
+
+namespace IncDec {
+  // FIXME: Pointer arithmethic needs to be supported in inc/dec
+  //   unary operators
+#if 0
+  constexpr int getNextElem(const int *A, int I) {
+const int *B = (A + I);
+++B;
+return *B;
+  }
+  constexpr int E[] = {1,2,3,4};
+
+  static_assert(getNextElem(E, 1) == 3);
+#endif
+};
Index: clang/lib/AST/Interp/Opcodes.td
===
--- clang/lib/AST/Interp/Opcodes.td
+++ clang/lib/AST/Interp/Opcodes.td
@@ -446,6 +446,11 @@
   let HasGroup = 1;
 }
 
+def Inc: IntegerOpcode;
+def IncPop : IntegerOpcode;
+def Dec: IntegerOpcode;
+def DecPop: IntegerOpcode;
+
 // [Real] -> [Real]
 def Neg: Opcode {
   let Types = [NonPtrTypeClass];
Index: clang/lib/AST/Interp/Interp.h
===
--- clang/lib/AST/Interp/Interp.h
+++ clang/lib/AST/Interp/Interp.h
@@ -328,6 +328,105 @@
   return true;
 }
 
+enum class PushVal : bool {
+  No,
+  Yes,
+};
+enum class IncDecOp {
+  Inc,
+  Dec,
+};
+
+template 
+bool IncDecHelper(InterpState &S, CodePtr OpPC, const Pointer &Ptr) {
+  T Value = Ptr.deref();
+  T Result;
+
+  if constexpr (DoPush == PushVal::Yes)
+S.Stk.push(Result);
+
+  if constexpr (Op == IncDecOp::Inc) {
+if (!T::increment(Value, &Result)) {
+  Ptr.deref() = Result;
+  return true;
+}
+  } else {

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1237-1240
+if (DiscardResult)
+  return this->emitIncPop(*T, E);
+
+return this->emitInc(*T, E);

aaron.ballman wrote:
> Style question: should we prefer doing something like: `return DiscardResult 
> ? this->emitIncPop(*T, E) : this->emitInc(*T, E);` to discourage accidentally 
> adding code between the two increment operations? (And applying this style 
> more generally for discarded results?)
> 
> Alternatively, do we want to add a helper function to `ByteCodeExprGen` 
> called `doEmitInc()` that hides the discarded result behavior so the `Visit*` 
> functions don't have to keep doing that dance?
Yeah I think the ternary makes sense here, like it's done in the `Discard()` 
function in `VisitBinaryOperator()`.

For a function, I'll hold off for now, but it might make sense later (there's 
still a TODO comment for array initialization, which compiles to tons of code 
right now and we should use a loop there).


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

https://reviews.llvm.org/D136423

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

[clang-tools-extra] ce286ec - [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via cfe-commits


Author: Kadir Cetinkaya
Date: 2022-10-24T17:06:15+02:00
New Revision: ce286eccacd660f2b71cba15d9b83fe2217e36b8

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

LOG: [IncludeCleaner] Add public API

Introduces walkUsed, a very simple version of the public API to enable
incremental development on rest of the pieces.

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

Added: 
clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h
clang-tools-extra/include-cleaner/lib/Analysis.cpp
clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp

Modified: 
clang-tools-extra/include-cleaner/lib/CMakeLists.txt
clang-tools-extra/include-cleaner/lib/WalkAST.cpp
clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Removed: 




diff  --git 
a/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h 
b/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h
new file mode 100644
index 0..0c28119831988
--- /dev/null
+++ b/clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h
@@ -0,0 +1,75 @@
+//===--- Analysis.h - Analyze symbol references in AST - 
C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+/// A library that provides usage analysis for symbols based on AST analysis.
+//===--===//
+
+#ifndef CLANG_INCLUDE_CLEANER_ANALYSIS_H
+#define CLANG_INCLUDE_CLEANER_ANALYSIS_H
+
+#include "clang/Tooling/Inclusions/StandardLibrary.h"
+#include "llvm/ADT/STLFunctionalExtras.h"
+#include 
+
+namespace clang {
+class SourceLocation;
+class Decl;
+class FileEntry;
+namespace include_cleaner {
+
+/// An entity that can be referenced in the code.
+struct Symbol {
+  Symbol(Decl &D) : Storage(&D) {}
+  Symbol(tooling::stdlib::Symbol S) : Storage(S) {}
+
+private:
+  // FIXME: Add support for macros.
+  std::variant Storage;
+};
+
+/// Represents a file that provides some symbol. Might not be includeable, e.g.
+/// built-in or main-file itself.
+struct Header {
+  /// A physical (or logical, in case of a builtin) file.
+  Header(const FileEntry *FE) : Storage(FE) {}
+  /// A logical file representing a stdlib header.
+  Header(tooling::stdlib::Header H) : Storage(H) {}
+
+  bool operator==(const Header &RHS) const { return Storage == RHS.Storage; }
+
+private:
+  // FIXME: Handle verbatim spellings.
+  std::variant Storage;
+};
+/// A UsedSymbolCB is a callback invoked for each symbol reference seen.
+///
+/// References occur at a particular location, refer to a single symbol, and
+/// that symbol may be provided by several headers.
+/// FIXME: Provide signals about the reference type and providing headers so 
the
+/// caller can filter and rank the results.
+using UsedSymbolCB = llvm::function_ref Providers)>;
+
+/// Find and report all references to symbols in a region of code.
+///
+/// The AST traversal is rooted at ASTRoots - typically top-level declarations
+/// of a single source file.
+/// FIXME: Handle macro uses.
+///
+/// This is the main entrypoint of the include-cleaner library, and can be 
used:
+///  - to diagnose missing includes: a referenced symbol is provided by
+///headers which don't match any #include in the main file
+///  - to diagnose unused includes: an #include in the main file does not match
+///the headers for any referenced symbol
+/// FIXME: Take in an include structure to improve location to header mappings
+/// (e.g. IWYU pragmas).
+void walkUsed(llvm::ArrayRef ASTRoots, UsedSymbolCB CB);
+
+} // namespace include_cleaner
+} // namespace clang
+
+#endif

diff  --git a/clang-tools-extra/include-cleaner/lib/Analysis.cpp 
b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
new file mode 100644
index 0..72fac3c9c0084
--- /dev/null
+++ b/clang-tools-extra/include-cleaner/lib/Analysis.cpp
@@ -0,0 +1,50 @@
+//===--- Analysis.cpp 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang-include-cleaner/Analysis.h"
+#include "AnalysisInternal.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Too

[PATCH] D136293: [IncludeCleaner] Add public API

2022-10-24 Thread Kadir Cetinkaya via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGce286eccacd6: [IncludeCleaner] Add public API (authored by 
kadircet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136293

Files:
  clang-tools-extra/include-cleaner/include/clang-include-cleaner/Analysis.h
  clang-tools-extra/include-cleaner/lib/Analysis.cpp
  clang-tools-extra/include-cleaner/lib/CMakeLists.txt
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
  clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -1,15 +1,28 @@
+//===--- WalkASTTest.cpp --- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
 #include "AnalysisInternal.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/Basic/FileManager.h"
+#include "clang/Basic/SourceLocation.h"
 #include "clang/Frontend/TextDiagnostic.h"
 #include "clang/Testing/TestAST.h"
+#include "llvm/ADT/ArrayRef.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Annotations.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
+#include 
 
-namespace clang {
-namespace include_cleaner {
+namespace clang::include_cleaner {
 namespace {
+using testing::Pair;
+using testing::UnorderedElementsAre;
 
 // Specifies a test of which symbols are referenced by a piece of code.
 //
@@ -106,5 +119,4 @@
 }
 
 } // namespace
-} // namespace include_cleaner
-} // namespace clang
+} // namespace clang::include_cleaner
Index: clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
===
--- clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
+++ clang-tools-extra/include-cleaner/unittests/CMakeLists.txt
@@ -5,6 +5,7 @@
 
 add_custom_target(ClangIncludeCleanerUnitTests)
 add_unittest(ClangIncludeCleanerUnitTests ClangIncludeCleanerTests
+  AnalysisTest.cpp
   RecordTest.cpp
   WalkASTTest.cpp
 )
@@ -18,6 +19,7 @@
   clangAST
   clangBasic
   clangFrontend
+  clangToolingInclusionsStdlib
   )
 
 target_link_libraries(ClangIncludeCleanerTests
Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- /dev/null
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -0,0 +1,69 @@
+//===--- AnalysisTest.cpp -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang-include-cleaner/Analysis.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Testing/TestAST.h"
+#include "clang/Tooling/Inclusions/StandardLibrary.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/Testing/Support/Annotations.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+namespace clang::include_cleaner {
+namespace {
+using testing::Pair;
+using testing::UnorderedElementsAre;
+
+TEST(WalkUsed, Basic) {
+  // FIXME: Have a fixture for setting up tests.
+  llvm::Annotations HeaderCode(R"cpp(
+  void foo();
+  namespace std { class vector {}; })cpp");
+  llvm::Annotations Code(R"cpp(
+  void bar() {
+$foo^foo();
+std::$vector^vector v;
+  }
+  )cpp");
+  TestInputs Inputs(Code.code());
+  Inputs.ExtraFiles["header.h"] = HeaderCode.code().str();
+  Inputs.ExtraArgs.push_back("-include");
+  Inputs.ExtraArgs.push_back("header.h");
+  TestAST AST(Inputs);
+
+  llvm::SmallVector TopLevelDecls;
+  for (Decl *D : AST.context().getTranslationUnitDecl()->decls()) {
+TopLevelDecls.emplace_back(D);
+  }
+
+  auto &SM = AST.sourceManager();
+  llvm::DenseMap> OffsetToProviders;
+  walkUsed(TopLevelDecls, [&](SourceLocation RefLoc, Symbol S,
+  llvm::ArrayRef Providers) {
+auto [FID, Offset] = SM.getDecomposedLoc(RefLoc);
+EXPECT_EQ(FID, SM.getMainFileID());
+OffsetToProviders.try_emplace(Offset, Providers.vec());
+  });
+  auto HeaderFile = AST.fileMa

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Timm Bäder via Phabricator via cfe-commits

tbaeder updated this revision to Diff 470163.

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

https://reviews.llvm.org/D136423

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/Opcodes.td
  clang/test/AST/Interp/arrays.cpp
  clang/test/AST/Interp/literals.cpp

Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -361,3 +361,88 @@
   constexpr double db = true;
   static_assert(db == 1.0, "");
 };
+
+#if __cplusplus > 201402L
+namespace IncDec {
+  constexpr int zero() {
+int a = 0;
+a++;
+++a;
+a--;
+--a;
+return a;
+  }
+  static_assert(zero() == 0, "");
+
+  constexpr int preInc() {
+int a = 0;
+return ++a;
+  }
+  static_assert(preInc() == 1, "");
+
+  constexpr int postInc() {
+int a = 0;
+return a++;
+  }
+  static_assert(postInc() == 0, "");
+
+  constexpr int preDec() {
+int a = 0;
+return --a;
+  }
+  static_assert(preDec() == -1, "");
+
+  constexpr int postDec() {
+int a = 0;
+return a--;
+  }
+  static_assert(postDec() == 0, "");
+
+  constexpr int three() {
+int a = 0;
+return ++a + ++a; // expected-warning {{multiple unsequenced modifications to 'a'}} \
+  // ref-warning {{multiple unsequenced modifications to 'a'}} \
+
+  }
+  static_assert(three() == 3, "");
+
+  constexpr bool incBool() {
+bool b = false;
+return ++b; // expected-error {{ISO C++17 does not allow incrementing expression of type bool}} \
+// ref-error {{ISO C++17 does not allow incrementing expression of type bool}}
+  }
+  static_assert(incBool(), "");
+
+  constexpr int uninit() {
+int a;
+++a; // ref-note {{increment of uninitialized}} \
+ // FIXME: Should also be rejected by new interpreter
+return 1;
+  }
+  static_assert(uninit(), ""); // ref-error {{not an integral constant expression}} \
+   // ref-note {{in call to 'uninit()'}}
+
+  constexpr int OverFlow() { // ref-error {{never produces a constant expression}}
+int a = INT_MAX;
+++a; // ref-note 2{{is outside the range}} \
+ // expected-note {{is outside the range}}
+return -1;
+  }
+  static_assert(OverFlow() == -1, "");  // expected-error {{not an integral constant expression}} \
+// expected-note {{in call to 'OverFlow()'}} \
+// ref-error {{not an integral constant expression}} \
+// ref-note {{in call to 'OverFlow()'}}
+
+
+  constexpr int UnderFlow() { // ref-error {{never produces a constant expression}}
+int a = INT_MIN;
+--a; // ref-note 2{{is outside the range}} \
+ // expected-note {{is outside the range}}
+return -1;
+  }
+  static_assert(UnderFlow() == -1, "");  // expected-error {{not an integral constant expression}} \
+ // expected-note {{in call to 'UnderFlow()'}} \
+ // ref-error {{not an integral constant expression}} \
+ // ref-note {{in call to 'UnderFlow()'}}
+};
+#endif
Index: clang/test/AST/Interp/arrays.cpp
===
--- clang/test/AST/Interp/arrays.cpp
+++ clang/test/AST/Interp/arrays.cpp
@@ -180,3 +180,18 @@
  constexpr int x = arr.a[0];
   }
 };
+
+namespace IncDec {
+  // FIXME: Pointer arithmethic needs to be supported in inc/dec
+  //   unary operators
+#if 0
+  constexpr int getNextElem(const int *A, int I) {
+const int *B = (A + I);
+++B;
+return *B;
+  }
+  constexpr int E[] = {1,2,3,4};
+
+  static_assert(getNextElem(E, 1) == 3);
+#endif
+};
Index: clang/lib/AST/Interp/Opcodes.td
===
--- clang/lib/AST/Interp/Opcodes.td
+++ clang/lib/AST/Interp/Opcodes.td
@@ -446,6 +446,11 @@
   let HasGroup = 1;
 }
 
+def Inc: IntegerOpcode;
+def IncPop : IntegerOpcode;
+def Dec: IntegerOpcode;
+def DecPop: IntegerOpcode;
+
 // [Real] -> [Real]
 def Neg: Opcode {
   let Types = [NonPtrTypeClass];
Index: clang/lib/AST/Interp/Interp.h
===
--- clang/lib/AST/Interp/Interp.h
+++ clang/lib/AST/Interp/Interp.h
@@ -328,6 +328,105 @@
   return true;
 }
 
+enum class PushVal : bool {
+  No,
+  Yes,
+};
+enum class IncDecOp {
+  Inc,
+  Dec,
+};
+
+template 
+bool IncDecHelper(InterpState &S, CodePtr OpPC, const Pointer &Ptr) {
+  T Value = Ptr.deref();
+  T Result;
+
+  if constexpr (DoPush == PushVal::Yes)
+S.Stk.push(Result);
+
+  if constexpr (Op == IncDecOp::Inc) {
+if (!T::increment(Value, &Result)) {
+  Ptr.deref() = Result;
+  return true;
+}
+  } else {
+if (!T::decrement(Value, &Result)) {

[PATCH] D136532: [clang][Interp] Implement left and right shifts

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/Interp.h:1236-1237
 inline bool ShiftRight(InterpState &S, CodePtr OpPC, const T &V, unsigned RHS) 
{
   if (RHS >= V.bitWidth()) {
 S.Stk.push(T::from(0, V.bitWidth()));
   } else {

This doesn't seem to match: https://eel.is/c++draft/expr.shift#1.sentence-4



Comment at: clang/lib/AST/Interp/Interp.h:1246-1256
   if (V.isSigned() && !S.getLangOpts().CPlusPlus20) {
 // C++11 [expr.shift]p2: A signed left shift must have a non-negative
 // operand, and must not overflow the corresponding unsigned type.
 // C++2a [expr.shift]p2: E1 << E2 is the unique value congruent to
 // E1 x 2^E2 module 2^N.
 if (V.isNegative()) {
   const Expr *E = S.Current->getExpr(OpPC);

Why do `Shr` and `Shl` check for a negative shift amount to issue a diagnostic 
but we check for signed in `ShiftLeft` to issue a diagnostic? (I would have 
expected the checks to all live in the same place.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136532

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

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from nits.




Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1275-1277
+if (DiscardResult)
+  return this->emitPop(*T, E);
 return this->emitInvBool(E);





Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1281-1283
+if (DiscardResult)
+  return this->emitPop(*T, E);
+return this->emitNeg(*T, E);





Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1287-1289
+if (DiscardResult)
+  return this->emitPop(*T, E);
+return true;





Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1294-1296
+if (DiscardResult)
+  return this->emitPop(*T, E);
+return true;





Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1310-1312
+if (DiscardResult)
+  return this->emitPop(*T, E);
+return this->emitComp(*T, E);




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

https://reviews.llvm.org/D136423

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

[PATCH] D136440: [clang] Do not hide base member using-decls with different template head.

2022-10-24 Thread Utkarsh Saxena via Phabricator via cfe-commits

usaxena95 marked 4 inline comments as done.
usaxena95 added a comment.

I have switched to a version where we matched template heads only when they are 
constraints. This is for the moment to unblock the existing bugs and not break 
existing code prior to C++20.
Let us continue the discussion over the possibility of introducing an ambiguity 
in  https://github.com/llvm/llvm-project/issues/58571




Comment at: clang/lib/Sema/SemaOverload.cpp:1307
+// C++ [namespace.udecl]p4:
+//   The member from the base class is hidden or overridden by the
+//   implicitly-declared copy/move constructor or assignment operator of 
the

ilya-biryukov wrote:
> How is this related to checking whether the template parameter lists check?
> I seems to be missing the logical connection that goes from the standard 
> wording to the code. Could you explain?
> 
> An example that I have in mind is:
> ```
> struct A {
> template  A(T);
> template  int foo(T);
> };
> struct B : A {
> using A::A;
> template  B(T);
> 
> using A::foo;
> template  int foo(T);
> };
> 
> namespace detail {
> template  int bar(T);
> }
> using detail::bar;
> template  int bar(T);
> 
> int a = bar(10); // this is definitely ambiguous.
> 
> B b(10); // should this be ambiguous?
> int c = b.foo(10); // should this be ambiguous?
> // Should constructors and functions behave differently? Why?
> ```
> 
> I [see](https://gcc.godbolt.org/z/z4Ko1ehPe) that both Clang and GCC treat 
> member declarations differently, but I don't see why they should given that 
> they are supposed to use the same "corresponds" terminology from the 
> standard. What am I missing?
I have filed https://github.com/llvm/llvm-project/issues/58571 to discuss the 
interpretation of the standard.



Comment at: clang/test/SemaTemplate/concepts-using-decl.cpp:110
+  expect<1>(bar2{}.foo());
+  // FIXME: Candidates from using-decls should be dropped in case of ambiguity.
+  expect<1>(baz{}.foo()); // expected-error {{call to member function 
'foo' is ambiguous}}

ilya-biryukov wrote:
> Why should they be dropped? Could you provide pointers from the standard?
I think I misunderstood that using decls should not be introducing ambiguities. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136440

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

[PATCH] D136440: [clang] Do not hide base member using-decls with different template head.

2022-10-24 Thread Utkarsh Saxena via Phabricator via cfe-commits

usaxena95 updated this revision to Diff 470174.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136440

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaTemplate/concepts-using-decl.cpp

Index: clang/test/SemaTemplate/concepts-using-decl.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-using-decl.cpp
@@ -0,0 +1,114 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+namespace heads_without_concepts {
+struct base {
+  template 
+  int foo() { return 1; };
+};
+
+struct bar : public base {
+  using base::foo;
+  template  
+  int foo() { return 2; }; // expected-note {{candidate template ignored: substitution failure: too many template arguments for function template 'foo'}}
+};
+
+void func() {
+  bar f;
+  f.foo<10>();
+  // FIXME(GH58571): bar::foo should not hide base::foo.
+  f.foo<10, 10>(); // expected-error {{no matching member function for call to 'foo'}}
+}
+}
+
+namespace static_methods {
+template concept False = false;
+
+struct Base {
+static void foo(auto);
+};
+struct Derived : public Base {
+using Base::foo;
+static void foo(False auto);
+};
+void func() {
+Derived::foo(42);
+}
+}
+
+namespace constrained_members {
+template  struct Opaque {};
+template  void expect(Opaque _) {}
+
+struct Empty{};
+constexpr int EmptySize = sizeof(Empty);
+
+template concept IsEmpty = sizeof(T) == EmptySize;
+
+namespace base_members_not_hidden {
+struct base {
+  template 
+  Opaque<0> foo() { return Opaque<0>(); };
+};
+
+struct bar1 : public base {
+  using base::foo;
+  template  requires IsEmpty 
+  Opaque<1> foo() { return Opaque<1>(); };
+};
+
+struct bar2 : public base {
+  using base::foo;
+  template 
+  Opaque<1> foo() { return Opaque<1>(); };
+};
+
+struct bar3 : public base {
+  using base::foo;
+  template 
+  Opaque<1> foo() requires IsEmpty { return Opaque<1>(); };
+};
+
+void func() {
+  expect<0>(base{}.foo());
+  expect<0>(base{}.foo());
+  expect<1>(bar1{}.foo());
+  expect<0>(bar1{}.foo());
+  expect<1>(bar2{}.foo());
+  expect<0>(bar2{}.foo());
+  expect<1>(bar3{}.foo());
+  expect<0>(bar3{}.foo());
+}
+}
+namespace base_members_hidden {
+struct base1 {
+  template  requires IsEmpty
+  Opaque<0> foo() { return Opaque<0>(); }; // expected-note {{candidate function [with T = constrained_members::Empty]}}
+};
+struct bar1 : public base1 {
+  using base1::foo;
+  template  requires IsEmpty
+  Opaque<1> foo() { return Opaque<1>(); };
+};
+struct base2 {
+  template 
+  Opaque<0> foo() { return Opaque<0>(); };
+};
+struct bar2 : public base2 {
+  using base2::foo;
+  template 
+  Opaque<1> foo() { return Opaque<1>(); };
+};
+struct baz : public base1 {
+  using base1::foo;
+  template  requires IsEmpty && IsEmpty
+  Opaque<1> foo() { return Opaque<1>(); };  // expected-note {{candidate function [with T = constrained_members::Empty]}}
+};
+void func() { 
+  expect<0>(base1{}.foo());
+  expect<1>(bar1{}.foo());
+  expect<0>(base2{}.foo());
+  expect<1>(bar2{}.foo());
+  expect<1>(baz{}.foo()); // expected-error {{call to member function 'foo' is ambiguous}}
+}
+}
+}
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -1280,26 +1280,42 @@
!FunctionParamTypesAreEqual(OldType, NewType)))
 return true;
 
-  // C++ [temp.over.link]p4:
-  //   The signature of a function template consists of its function
-  //   signature, its return type and its template parameter list. The names
-  //   of the template parameters are significant only for establishing the
-  //   relationship between the template parameters and the rest of the
-  //   signature.
-  //
-  // We check the return type and template parameter lists for function
-  // templates first; the remaining checks follow.
-  //
-  // However, we don't consider either of these when deciding whether
-  // a member introduced by a shadow declaration is hidden.
-  if (!UseMemberUsingDeclRules && NewTemplate &&
-  (!TemplateParameterListsAreEqual(NewTemplate->getTemplateParameters(),
-   OldTemplate->getTemplateParameters(),
-   false, TPL_TemplateMatch) ||
-   !Context.hasSameType(Old->getDeclaredReturnType(),
-New->getDeclaredReturnType(
-return true;
-
+  if (NewTemplate) {
+// C++ [temp.over.link]p4:
+//   The signature of a function template consists of its function
+//   signature, its return type and its template parameter list. The names
+//   of the template parameters are significant only for establishing the
+//   relationship between the template parameters and the

[clang] d0d2772 - [Clang] Implement P2513

2022-10-24 Thread Corentin Jabot via cfe-commits


Author: Corentin Jabot
Date: 2022-10-24T18:10:43+02:00
New Revision: d0d2772379bd89f1dce3c456520272678cf4b966

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

LOG: [Clang] Implement P2513

Implement P2513

This change allows initializing an array of unsigned char,
or char from u8 string literals.
This was done both to support legacy code and for compatibility
with C where char8_t will be typedef to unsigned char.

This is backported to C++20 as per WG21 guidance.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Frontend/InitPreprocessor.cpp
clang/lib/Sema/SemaInit.cpp
clang/test/Lexer/cxx-features.cpp
clang/test/SemaCXX/char8_t.cpp
clang/test/SemaCXX/cxx2a-compat.cpp
clang/www/cxx_status.html

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 68cee534513a..49ef53f33877 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -557,6 +557,8 @@ C++2b Feature Support
 
 - Support label at end of compound statement (`P2324 
`_).
 - Implemented `P1169R4: static operator() `_.
+- Implemented "char8_t Compatibility and Portability Fix" (`P2513R3 
`_).
+  This Change was applied to C++20 as a Defect Report.
 
 CUDA/HIP Language Changes in Clang
 --
@@ -654,8 +656,8 @@ libclang
   the behavior of ``QualType::getNonReferenceType`` for ``CXType``.
 - Introduced the new function ``clang_CXXMethod_isDeleted``, which queries
   whether the method is declared ``= delete``.
-- ``clang_Cursor_getNumTemplateArguments``, 
``clang_Cursor_getTemplateArgumentKind``, 
-  ``clang_Cursor_getTemplateArgumentType``, 
``clang_Cursor_getTemplateArgumentValue`` and 
+- ``clang_Cursor_getNumTemplateArguments``, 
``clang_Cursor_getTemplateArgumentKind``,
+  ``clang_Cursor_getTemplateArgumentType``, 
``clang_Cursor_getTemplateArgumentValue`` and
   ``clang_Cursor_getTemplateArgumentUnsignedValue`` now work on struct, class,
   and partial template specialization cursors in addition to function cursors.
 

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index b1d475772502..8cf73784d97b 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6868,8 +6868,8 @@ def err_array_init_plain_string_into_char8_t : Error<
 def note_array_init_plain_string_into_char8_t : Note<
   "add 'u8' prefix to form a 'char8_t' string literal">;
 def err_array_init_utf8_string_into_char : Error<
-  "%select{|ISO C++20 does not permit }0initialization of char array with "
-  "UTF-8 string literal%select{ is not permitted by '-fchar8_t'|}0">;
+  "initialization of %select{|signed }0char array with "
+  "UTF-8 string literal is not permitted by %select{'-fchar8_t'|C++20}1">;
 def warn_cxx20_compat_utf8_string : Warning<
   "type of UTF-8 string literal will change from array of const char to "
   "array of const char8_t in C++20">, InGroup, DefaultIgnore;

diff  --git a/clang/lib/Frontend/InitPreprocessor.cpp 
b/clang/lib/Frontend/InitPreprocessor.cpp
index 2273fb113fb2..96b93dcdf044 100644
--- a/clang/lib/Frontend/InitPreprocessor.cpp
+++ b/clang/lib/Frontend/InitPreprocessor.cpp
@@ -705,7 +705,7 @@ static void InitializeCPlusPlusFeatureTestMacros(const 
LangOptions &LangOpts,
   Builder.defineMacro("__cpp_named_character_escapes", "202207L");
 
   if (LangOpts.Char8)
-Builder.defineMacro("__cpp_char8_t", "201811L");
+Builder.defineMacro("__cpp_char8_t", "202207L");
   Builder.defineMacro("__cpp_impl_destroying_delete", "201806L");
 
   // TS features.

diff  --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index db5580c9e55c..7ebf6997e27e 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -81,10 +81,20 @@ static StringInitFailureKind IsStringInit(Expr *Init, const 
ArrayType *AT,
   const QualType ElemTy =
   Context.getCanonicalType(AT->getElementType()).getUnqualifiedType();
 
+  auto IsCharOrUnsignedChar = [](const QualType &T) {
+const BuiltinType *BT = dyn_cast(T.getTypePtr());
+return BT && BT->isCharType() && BT->getKind() != BuiltinType::SChar;
+  };
+
   switch (SL->getKind()) {
   case StringLiteral::UTF8:
 // char8_t array can be initialized with a UTF-8 string.
-if (ElemTy->isChar8Type())
+// - C++20 [dcl.init.string] (DR)
+//   Additionally, an array of char or unsigned char may be initialized
+//   by a UTF-8 string literal.
+if (ElemTy->isChar8Type() ||
+

[PATCH] D136449: [Clang] Implement P2513

2022-10-24 Thread Corentin Jabot via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd0d2772379bd: [Clang] Implement P2513 (authored by cor3ntin).

Changed prior to commit:
  https://reviews.llvm.org/D136449?vs=469715&id=470179#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136449

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/SemaCXX/char8_t.cpp
  clang/test/SemaCXX/cxx2a-compat.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1502,7 +1502,7 @@
 
   char8_t Compatibility and Portability Fix
   https://wg21.link/P2513R3";>P2513R3
-  No
+  Clang 16
 
 
   Relax requirements on wchar_t to match existing practices
Index: clang/test/SemaCXX/cxx2a-compat.cpp
===
--- clang/test/SemaCXX/cxx2a-compat.cpp
+++ clang/test/SemaCXX/cxx2a-compat.cpp
@@ -33,9 +33,8 @@
 // expected-warning@-4 {{type of UTF-8 string literal will change}} expected-note@-4 {{remove 'u8' prefix}}
 // expected-warning@-4 {{type of UTF-8 string literal will change}} expected-note@-4 {{remove 'u8' prefix}}
 #else
-// expected-error@-8 {{ISO C++20 does not permit initialization of char array with UTF-8 string literal}}
-// expected-error@-8 {{cannot initialize a variable of type 'const char *' with an lvalue of type 'const char8_t[6]'}}
-// expected-error@-8 {{no viable conversion from 'const char8_t[9]' to 'string'}}
+// expected-error@-7 {{cannot initialize a variable of type 'const char *' with an lvalue of type 'const char8_t[6]'}}
+// expected-error@-7 {{no viable conversion from 'const char8_t[9]' to 'string'}}
 #endif
 
 template
Index: clang/test/SemaCXX/char8_t.cpp
===
--- clang/test/SemaCXX/char8_t.cpp
+++ clang/test/SemaCXX/char8_t.cpp
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -fchar8_t -std=c++17 -verify %s
-// RUN: %clang_cc1 -std=c++2a -verify %s
+// RUN: %clang_cc1 -std=c++2a -verify=expected %s
+// RUN: %clang_cc1 -std=c++2a -verify=expected -fno-signed-char %s
+
 
 char8_t a = u8'a';
 char8_t b[] = u8"foo";
@@ -7,15 +9,35 @@
 char8_t d[] = "foo"; // expected-error {{initializing 'char8_t' array with plain string literal}} expected-note {{add 'u8' prefix}}
 
 char e = u8'a';
-char f[] = u8"foo";
-#if __cplusplus <= 201703L
-// expected-error@-2 {{initialization of char array with UTF-8 string literal is not permitted by '-fchar8_t'}}
-#else
-// expected-error@-4 {{ISO C++20 does not permit initialization of char array with UTF-8 string literal}}
-#endif
 char g = 'a';
 char h[] = "foo";
 
+unsigned char i[] = u8"foo";
+unsigned char j[] = { u8"foo" };
+char k[] = u8"foo";
+char l[] = { u8"foo" };
+signed char m[] = u8"foo"; // expected-error {{initialization of char array with UTF-8 string literal is not permitted}}
+signed char n[] = { u8"foo" }; // expected-error {{cannot initialize an array element of type 'signed char' with an lvalue of type 'const char8_t[4]'}}
+
+const unsigned char* uptr = u8"foo"; // expected-error {{cannot initialize}}
+const signed char* sptr = u8"foo"; // expected-error {{cannot initialize}}
+const char* ptr = u8"foo"; // expected-error {{cannot initialize}}
+
+template 
+void check_values() {
+  constexpr T c[] = {0, static_cast(0xFF), 0x42};
+  constexpr T a[] = u8"\x00\xFF\x42";
+
+  static_assert(a[0] == c[0]);
+  static_assert(a[1] == c[1]);
+  static_assert(a[2] == c[2]);
+}
+
+void call_check_values() {
+  check_values();
+  check_values();
+}
+
 void disambig() {
   char8_t (a) = u8'x';
 }
@@ -48,3 +70,21 @@
 static_assert(sizeof(char8_t) == 1);
 static_assert(char8_t(-1) > 0);
 static_assert(u8"\u0080"[0] > 0);
+
+namespace ambiguous {
+
+struct A {
+	char8_t s[10];
+};
+struct B {
+  char s[10];
+};
+
+void f(A); // expected-note {{candidate}}
+void f(B); // expected-note {{candidate}}
+
+int test() {
+  f({u8"foo"}); // expected-error {{call to 'f' is ambiguous}}
+}
+
+}
Index: clang/test/Lexer/cxx-features.cpp
===
--- clang/test/Lexer/cxx-features.cpp
+++ clang/test/Lexer/cxx-features.cpp
@@ -66,9 +66,9 @@
 #error "wrong value for __cpp_aggregate_paren_init"
 #endif
 
-#if defined(CHAR8_T) ? check(char8_t, 201811, 201811, 201811, 201811, 201811, 201811) : \
+#if defined(CHAR8_T) ? check(char8_t, 202207, 202207, 202207, 202207, 202207, 202207) : \
 defined(NO_CHAR8_T) ? check(char8_t, 0, 0, 0, 0, 0, 0) : \
-check(char8_t, 0, 0, 0, 0, 201811, 201811)
+check(char8_t, 0, 0, 0, 0, 202207, 202207)
 #error "wrong value for __cpp_char8_t"
 #endif
 
Index: clang/lib/Sema/S

[PATCH] D136449: [Clang] Implement P2513

2022-10-24 Thread Corentin Jabot via Phabricator via cfe-commits

cor3ntin added a comment.

Thanks Aaron!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136449

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

[PATCH] D136615: [Instrumentation] Remove legacy passes

2022-10-24 Thread Arthur Eubanks via Phabricator via cfe-commits

aeubanks created this revision.
aeubanks added a reviewer: asbirlea.
Herald added a reviewer: deadalnix.
Herald added subscribers: Enna1, hiraditya.
Herald added a reviewer: ctetreau.
Herald added a project: All.
aeubanks requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136615

Files:
  clang/tools/clang-fuzzer/fuzzer-initialize/fuzzer_initialize.cpp
  llvm/bindings/python/llvm/core.py
  llvm/include/llvm-c/Initialization.h
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/LinkAllPasses.h
  llvm/include/llvm/Transforms/Instrumentation.h
  llvm/include/llvm/Transforms/Instrumentation/BoundsChecking.h
  llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
  llvm/lib/Transforms/Instrumentation/MemProfiler.cpp
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp

Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -198,7 +198,6 @@
   initializeTransformUtils(Registry);
   initializeInstCombine(Registry);
   initializeAggressiveInstCombine(Registry);
-  initializeInstrumentation(Registry);
   initializeTarget(Registry);
 
   // Parse input options
Index: llvm/tools/bugpoint/bugpoint.cpp
===
--- llvm/tools/bugpoint/bugpoint.cpp
+++ llvm/tools/bugpoint/bugpoint.cpp
@@ -149,7 +149,6 @@
   initializeTransformUtils(Registry);
   initializeInstCombine(Registry);
   initializeAggressiveInstCombine(Registry);
-  initializeInstrumentation(Registry);
   initializeTarget(Registry);
 
   if (std::getenv("bar") == (char*) -1) {
Index: llvm/lib/Transforms/Instrumentation/MemProfiler.cpp
===
--- llvm/lib/Transforms/Instrumentation/MemProfiler.cpp
+++ llvm/lib/Transforms/Instrumentation/MemProfiler.cpp
@@ -204,22 +204,6 @@
   Value *DynamicShadowOffset = nullptr;
 };
 
-class MemProfilerLegacyPass : public FunctionPass {
-public:
-  static char ID;
-
-  explicit MemProfilerLegacyPass() : FunctionPass(ID) {
-initializeMemProfilerLegacyPassPass(*PassRegistry::getPassRegistry());
-  }
-
-  StringRef getPassName() const override { return "MemProfilerFunctionPass"; }
-
-  bool runOnFunction(Function &F) override {
-MemProfiler Profiler(*F.getParent());
-return Profiler.instrumentFunction(F);
-  }
-};
-
 class ModuleMemProfiler {
 public:
   ModuleMemProfiler(Module &M) { TargetTriple = Triple(M.getTargetTriple()); }
@@ -232,24 +216,6 @@
   Function *MemProfCtorFunction = nullptr;
 };
 
-class ModuleMemProfilerLegacyPass : public ModulePass {
-public:
-  static char ID;
-
-  explicit ModuleMemProfilerLegacyPass() : ModulePass(ID) {
-initializeModuleMemProfilerLegacyPassPass(*PassRegistry::getPassRegistry());
-  }
-
-  StringRef getPassName() const override { return "ModuleMemProfiler"; }
-
-  void getAnalysisUsage(AnalysisUsage &AU) const override {}
-
-  bool runOnModule(Module &M) override {
-ModuleMemProfiler MemProfiler(M);
-return MemProfiler.instrumentModule(M);
-  }
-};
-
 } // end anonymous namespace
 
 MemProfilerPass::MemProfilerPass() = default;
@@ -273,30 +239,6 @@
   return PreservedAnalyses::all();
 }
 
-char MemProfilerLegacyPass::ID = 0;
-
-INITIALIZE_PASS_BEGIN(MemProfilerLegacyPass, "memprof",
-  "MemProfiler: profile memory allocations and accesses.",
-  false, false)
-INITIALIZE_PASS_END(MemProfilerLegacyPass, "memprof",
-"MemProfiler: profile memory allocations and accesses.",
-false, false)
-
-FunctionPass *llvm::createMemProfilerFunctionPass() {
-  return new MemProfilerLegacyPass();
-}
-
-char ModuleMemProfilerLegacyPass::ID = 0;
-
-INITIALIZE_PASS(ModuleMemProfilerLegacyPass, "memprof-module",
-"MemProfiler: profile memory allocations and accesses."
-"ModulePass",
-false, false)
-
-ModulePass *llvm::createModuleMemProfilerLegacyPassPass() {
-  return new ModuleMemProfilerLegacyPass();
-}
-
 Value *MemProfiler::memToShadow(Value *Shadow, IRBuilder<> &IRB) {
   // (Shadow & mask) >> scale
   Shadow = IRB.CreateAnd(Shadow, Mapping.Mask);
Index: llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
===
--- llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
+++ llvm/lib/Transforms/Instrumentation/Instrumentation.cpp
@@ -88,17 +88,3 @@
   return C;
 }
 
-/// initializeInstrumentation - Initialize all passes in the TransformUtils
-/// library.
-void llvm::initializeInstrumentation(PassRegistry &Registry)

[PATCH] D136080: [flang] Add -ffp-contract option processing

2022-10-24 Thread Tom Eccles via Phabricator via cfe-commits

tblah updated this revision to Diff 470184.
tblah marked 2 inline comments as not done.
tblah edited the summary of this revision.
tblah added a comment.

Updated diff with a further reduced help text after discussions with @awarzynski


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

https://reviews.llvm.org/D136080

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/LangOptions.def
  flang/include/flang/Frontend/LangOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/LangOptions.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/flang_f_opts.f90
  flang/test/Driver/flang_fp_opts.f90
  flang/test/Driver/frontend-forwarding.f90

Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -8,6 +8,7 @@
 ! RUN: -fdefault-real-8 \
 ! RUN: -flarge-sizes \
 ! RUN: -fconvert=little-endian \
+! RUN: -ffp-contract=fast \
 ! RUN: -mllvm -print-before-all\
 ! RUN: -P \
 ! RUN:   | FileCheck %s
@@ -18,5 +19,6 @@
 ! CHECK: "-fdefault-integer-8"
 ! CHECK: "-fdefault-real-8"
 ! CHECK: "-flarge-sizes"
+! CHECK: "-ffp-contract=fast"
 ! CHECK: "-fconvert=little-endian"
 ! CHECK:  "-mllvm" "-print-before-all"
Index: flang/test/Driver/flang_fp_opts.f90
===
--- /dev/null
+++ flang/test/Driver/flang_fp_opts.f90
@@ -0,0 +1,4 @@
+! Test for handling of floating point options within the frontend driver
+
+! RUN: %flang_fc1 -ffp-contract=fast %s 2>&1 | FileCheck %s
+! CHECK: ffp-contract= is not currently implemented
Index: flang/test/Driver/flang_f_opts.f90
===
--- flang/test/Driver/flang_f_opts.f90
+++ flang/test/Driver/flang_f_opts.f90
@@ -1,8 +1,10 @@
 ! Test for warnings generated when parsing driver options. You can use this file for relatively small tests and to avoid creating
 ! new test files.
 
-! RUN: %flang -### -S -O4 %s 2>&1 | FileCheck %s
+! RUN: %flang -### -S -O4 -ffp-contract=on %s 2>&1 | FileCheck %s
 
+! CHECK: warning: the argument 'on' is not supported for option 'ffp-contract='. Mapping to 'ffp-contract=fast'
 ! CHECK: warning: -O4 is equivalent to -O3
 ! CHECK-LABEL: "-fc1"
+! CHECK: -ffp-contract=fast
 ! CHECK: -O3
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -31,6 +31,7 @@
 ! HELP-NEXT: -ffixed-form   Process source files in fixed form
 ! HELP-NEXT: -ffixed-line-length=
 ! HELP-NEXT: Use  as character line width in fixed mode
+! HELP-NEXT: -ffp-contract= Form fused FP ops (e.g. FMAs): fast | off (clang, flang), on | fast-honor-pragmas (clang only)
 ! HELP-NEXT: -ffree-formProcess source files in free form
 ! HELP-NEXT: -fimplicit-noneNo implicit typing allowed unless overridden by IMPLICIT statements
 ! HELP-NEXT: -finput-charset= Specify the default character set for source files
@@ -105,6 +106,7 @@
 ! HELP-FC1-NEXT: -ffixed-form   Process source files in fixed form
 ! HELP-FC1-NEXT: -ffixed-line-length=
 ! HELP-FC1-NEXT: Use  as character line width in fixed mode
+! HELP-FC1-NEXT: -ffp-contract= Form fused FP ops (e.g. FMAs): fast | off (clang, flang), on | fast-honor-pragmas (clang only)
 ! HELP-FC1-NEXT: -ffree-formProcess source files in free form
 ! HELP-FC1-NEXT: -fget-definition   
 ! HELP-FC1-NEXT:Get the symbol definition from   
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -31,6 +31,7 @@
 ! CHECK-NEXT: -ffixed-form   Process source files in fixed form
 ! CHECK-NEXT: -ffixed-line-length=
 ! CHECK-NEXT: Use  as character line width in fixed mode
+! CHECK-NEXT: -ffp-contract= Form fused FP ops (e.g. FMAs): fast | off (clang, flang), on | fast-honor-pragmas (clang only)
 ! CHECK-NEXT: -ffree-formProcess source files in free form
 ! CHECK-NEXT: -fimplicit-noneNo implicit typing allowed unless overridden by IMPLICIT statements
 ! CHECK-NEXT: -finput-charset= Specify the default character set for source files
Index: flang/lib/Frontend/LangOptions.cpp
===
--- /dev/null
+++ flang/lib/Frontend/LangOptions.cpp
@@ -0,0 +1,24 @@
+//===-- LangOptions.cpp ---===//
+//
+// Part of the LLVM Project, under the

[PATCH] D136156: [Clang][Diagnostic] Add hidden-reinterpret-cast diagnostic warning

2022-10-24 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

Thank you for the patch!

We don't typically add new diagnostics that are ignored by default because we 
have significant evidence that users don't enable them enough to warrant adding 
them.

In this case, I don't think we should enable this by default because it's 
effectively a "you're using the language feature" kind of diagnostic rather 
than pointing out inherently incorrect code. However, if there are situations 
where it points out undefined behavior were weren't diagnosing and we can limit 
the diagnostic to those cases, I think that would be great to enable by 
default. Alternatively, I think this would make sense as a clang-tidy check 
rather than part of the compiler itself as it feels more like a stylistic 
diagnostic than a correctness one.


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

https://reviews.llvm.org/D136156

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

[PATCH] D136156: [Clang][Diagnostic] Add hidden-reinterpret-cast diagnostic warning

2022-10-24 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

Looks like this and more is already being caught by clang-tidy's 
google-readability-casting check .


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

https://reviews.llvm.org/D136156

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

[PATCH] D132941: [DO NOT SUBMIT] [Sema] Delay evaluation of std::source_location::current() in default arguments

2022-10-24 Thread Corentin Jabot via Phabricator via cfe-commits

cor3ntin added a comment.

The PR for the more general approach (note that it does not solve source 
location, that will need more additional work) https://reviews.llvm.org/D136554


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132941

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

[PATCH] D136455: [clang][ExtractAPI] Add targetFallback to relationships in symbol graph

2022-10-24 Thread Zixu Wang via Phabricator via cfe-commits

zixuw added a comment.

Is it easy to/worth checking if the target is actually outside of the current 
module to keep the output smaller and concise?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136455

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

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

2022-10-24 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added inline comments.



Comment at: clang/CMakeLists.txt:6
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)

Seems error prone. Does cmake have an include system for including fragments 
from elsewhere? If so, that seems like a more concise and less error prone 
approach.

https://cmake.org/cmake/help/latest/command/include.html


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

https://reviews.llvm.org/D136572

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

[PATCH] D136423: [clang][Interp] Implement inc/dec postfix and prefix operators

2022-10-24 Thread Shafik Yaghmour via Phabricator via cfe-commits

shafik accepted this revision.
shafik added a comment.

LGTM




Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1258
+  }
+  case UO_PreDec: { // --x
+if (!this->visit(SubExpr))

You could combine this with `UO_PreInc` and just use a `bool` flag to determine 
whether to call `emitAdd` or `emitSub` . Although maybe that it too clever.



Comment at: clang/test/AST/Interp/literals.cpp:364
 };
+
+#if __cplusplus > 201402L

Fun tests

```
+[](){};
+'a';
```

The action will really be done by the casts but the `+` is still technically 
having that affect.


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

https://reviews.llvm.org/D136423

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

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

2022-10-24 Thread Michał Górny via Phabricator via cfe-commits

mgorny added inline comments.



Comment at: clang/CMakeLists.txt:6
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  # Please keep policies in sync with llvm/CMakeLists.txt.
+  if(POLICY CMP0114)

nickdesaulniers wrote:
> Seems error prone. Does cmake have an include system for including fragments 
> from elsewhere? If so, that seems like a more concise and less error prone 
> approach.
> 
> https://cmake.org/cmake/help/latest/command/include.html
I suppose that makes sense. I think that at this point all these components 
require the top-level `cmake` directory from monorepo anyway.


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

https://reviews.llvm.org/D136572

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

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2022-10-24 Thread Roland McGrath via Phabricator via cfe-commits

mcgrathr added a comment.

In D85802#3876106 , @dblaikie wrote:

>> The C++ ABI is not part of the Fuchsia system ABI, nor what we call the 
>> "Fuchsia compiler ABI". Different users of C++ are free to use whatever C++ 
>> ABI they like. Only the backend ABI independent of language-specific issues 
>> is necessary to interoperate with other code on Fuchsia.
>
> Sure enough - but I'm still sort of confused by why the Fuschia Clang 
> target/compiler needs more than one C++ ABI. What is it interoperating with? 
> (GCC doesn't have a Fuschia target implemented, does it? So what's it mean to 
> target the GCC C++ ABI? what is compiling the code that Fuschia is trying to 
> interoperate with when Clang targets Fuschia with a non-default C++ ABI?)

When we use GCC we're using the generic ELF targets. I think it's sufficient 
for us to tell you that indeed we do want the option of multiple C++ ABIs to 
select from without justifying everything about our work to a Clang reviewer 
before we can proceed with meeting the requirements of our system.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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

[PATCH] D136012: [clang][Interp] Fix record members of reference type

2022-10-24 Thread Shafik Yaghmour via Phabricator via cfe-commits

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

LGTM




Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:867
 
-  if (Optional T = classify(Init->getType())) {
+  if (Optional T = classify(Init)) {
 if (!this->visit(Init))

What is the effect here or is this just stylistic?


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

https://reviews.llvm.org/D136012

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

[PATCH] D134687: [clang] Ensure correct metadata for relative vtables

2022-10-24 Thread Leonard Chan via Phabricator via cfe-commits

leonardchan added a comment.

*ping*


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134687

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

[PATCH] D136604: Add clang_CXXMethod_isCopyAssignmentOperator to libclang

2022-10-24 Thread 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!

Would you like to obtain commit access to land this one on your own 
(https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access)? If not, 
that's fine, I can also land it on your behalf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136604

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

[clang] 5293016 - Revert "GH58368: Correct concept checking in a lambda defined in concept"

2022-10-24 Thread Erich Keane via cfe-commits


Author: Erich Keane
Date: 2022-10-24T10:21:22-07:00
New Revision: 52930162870fee52d0d9c07c5d66e5dce32b08e8

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

LOG: Revert "GH58368: Correct concept checking in a lambda defined in concept"

This reverts commit b7c922607c5ba93db8b893d4ba461052af8317b5.

This seems to cause some problems with some modules related things,
which makes me think I should have updated the version-major in
ast-bit-codes?  Going to revert to confirm this was a problem, then
change that and re-try a commit.

Added: 


Modified: 
clang/include/clang/AST/ASTNodeTraverser.h
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/ExprConcepts.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Basic/DeclNodes.td
clang/include/clang/Serialization/ASTBitCodes.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/DeclBase.cpp
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/ExprConcepts.cpp
clang/lib/CodeGen/CGDecl.cpp
clang/lib/Sema/SemaConcept.cpp
clang/lib/Sema/SemaLambda.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTCommon.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/test/AST/ast-dump-concepts.cpp
clang/test/SemaTemplate/concepts-lambda.cpp
clang/tools/libclang/CIndex.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTNodeTraverser.h 
b/clang/include/clang/AST/ASTNodeTraverser.h
index 6df3a83b6404a..44dc52b419af5 100644
--- a/clang/include/clang/AST/ASTNodeTraverser.h
+++ b/clang/include/clang/AST/ASTNodeTraverser.h
@@ -623,14 +623,7 @@ class ASTNodeTraverser
 Visit(D->getConstraintExpr());
   }
 
-  void VisitImplicitConceptSpecializationDecl(
-  const ImplicitConceptSpecializationDecl *CSD) {
-for (const TemplateArgument &Arg : CSD->getTemplateArguments())
-  Visit(Arg);
-  }
-
   void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *CSE) {
-Visit(CSE->getSpecializationDecl());
 if (CSE->hasExplicitTemplateArgs())
   for (const auto &ArgLoc : CSE->getTemplateArgsAsWritten()->arguments())
 dumpTemplateArgumentLoc(ArgLoc);

diff  --git a/clang/include/clang/AST/DeclTemplate.h 
b/clang/include/clang/AST/DeclTemplate.h
index d1dfe73a51182..ae10744383559 100644
--- a/clang/include/clang/AST/DeclTemplate.h
+++ b/clang/include/clang/AST/DeclTemplate.h
@@ -3259,7 +3259,7 @@ class VarTemplateDecl : public RedeclarableTemplateDecl {
   static bool classofKind(Kind K) { return K == VarTemplate; }
 };
 
-/// Declaration of a C++20 concept.
+/// Declaration of a C++2a concept.
 class ConceptDecl : public TemplateDecl, public Mergeable {
 protected:
   Expr *ConstraintExpr;
@@ -3304,40 +3304,6 @@ class ConceptDecl : public TemplateDecl, public 
Mergeable {
   friend class ASTDeclWriter;
 };
 
-// An implementation detail of ConceptSpecialicationExpr that holds the 
template
-// arguments, so we can later use this to reconstitute the template arguments
-// during constraint checking.
-class ImplicitConceptSpecializationDecl final
-: public Decl,
-  private llvm::TrailingObjects {
-  unsigned NumTemplateArgs;
-
-  ImplicitConceptSpecializationDecl(DeclContext *DC, SourceLocation SL,
-ArrayRef ConvertedArgs);
-  ImplicitConceptSpecializationDecl(EmptyShell Empty, unsigned 
NumTemplateArgs);
-
-public:
-  static ImplicitConceptSpecializationDecl *
-  Create(const ASTContext &C, DeclContext *DC, SourceLocation SL,
- ArrayRef ConvertedArgs);
-  static ImplicitConceptSpecializationDecl *
-  CreateDeserialized(const ASTContext &C, unsigned ID,
- unsigned NumTemplateArgs);
-
-  ArrayRef getTemplateArguments() const {
-return ArrayRef(getTrailingObjects(),
-  NumTemplateArgs);
-  }
-  void setTemplateArguments(ArrayRef Converted);
-
-  static bool classofKind(Kind K) { return K == ImplicitConceptSpecialization; 
}
-  static bool classof(const Decl *D) { return classofKind(D->getKind()); }
-
-  friend TrailingObjects;
-  friend class ASTDeclReader;
-};
-
 /// A template parameter object.
 ///
 /// Template parameter objects represent values of class type used as template

diff  --git a/clang/include/clang/AST/ExprConcepts.h 
b/clang/include/clang/AST/ExprConcepts.h
index 6dedeb5c8ddfa..fd9cd31f3b90b 100644
--- a/clang/include/clang/AST/ExprConcepts.h
+++ b/clang/include/clang/AST/ExprConcepts.h
@@ -37,17 +37,18 @@ class ASTStmtWriter;
 ///
 ///

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2022-10-24 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D85802#3879888 , @mcgrathr wrote:

> In D85802#3876106 , @dblaikie wrote:
>
>>> The C++ ABI is not part of the Fuchsia system ABI, nor what we call the 
>>> "Fuchsia compiler ABI". Different users of C++ are free to use whatever C++ 
>>> ABI they like. Only the backend ABI independent of language-specific issues 
>>> is necessary to interoperate with other code on Fuchsia.
>>
>> Sure enough - but I'm still sort of confused by why the Fuschia Clang 
>> target/compiler needs more than one C++ ABI. What is it interoperating with? 
>> (GCC doesn't have a Fuschia target implemented, does it? So what's it mean 
>> to target the GCC C++ ABI? what is compiling the code that Fuschia is trying 
>> to interoperate with when Clang targets Fuschia with a non-default C++ ABI?)
>
> When we use GCC we're using the generic ELF targets. I think it's sufficient 
> for us to tell you that indeed we do want the option of multiple C++ ABIs to 
> select from without justifying everything about our work to a Clang reviewer 
> before we can proceed with meeting the requirements of our system.

Would the generic ELF target support in Clang be adequate to meet that 
requirement, then? (so Fuschia target could be the custom C++ ABI (& custom C 
ABI if you likee) and a generic ELF target could be used for GCC ELF 
compatibility) - then we wouldn't need any C++ ABI customizability?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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

[PATCH] D136624: [clang][modules] Account for non-affecting inputs in `ASTWriter`

2022-10-24 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 created this revision.
jansvoboda11 added reviewers: dexonsmith, Bigcheese, vsapsai, ilyakuteev.
Herald added subscribers: ributzka, mgrang.
Herald added a project: All.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

In D106876 , we stopped serializing module 
map files that didn't affect compilation of the current module.

However, since each `SourceLocation` is simply an offset into `SourceManager`'s 
global buffer of concatenated input files in, these need to be adjusted during 
serialization. Otherwise, they can incorrectly point after the buffer or into 
subsequent input file.

This patch starts adjusting `SourceLocation`s, `FileID`s and other 
`SourceManager` offsets in `ASTWriter`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136624

Files:
  clang/include/clang/Basic/SourceManager.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Modules/non-affecting-module-maps-source-locations.m

Index: clang/test/Modules/non-affecting-module-maps-source-locations.m
===
--- /dev/null
+++ clang/test/Modules/non-affecting-module-maps-source-locations.m
@@ -0,0 +1,32 @@
+// This patch tests that non-affecting files are serialized in such way that
+// does not break subsequent source locations (e.g. in serialized pragma
+// diagnostic mappings).
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- tu.m
+#include "first.h"
+
+//--- first/module.modulemap
+module first { header "first.h" }
+//--- first/first.h
+@import second;
+#pragma clang diagnostic ignored "-Wunreachable-code"
+
+//--- second/extra/module.modulemap
+module second_extra {}
+//--- second/module.modulemap
+module second { module sub { header "second_sub.h" } }
+//--- second/second_sub.h
+@import third;
+
+//--- third/module.modulemap
+module third { header "third.h" }
+//--- third/third.h
+#if __has_feature(nullability)
+#endif
+#if __has_feature(nullability)
+#endif
+
+// RUN: %clang_cc1 -I %t/first -I %t/second -I %t/third -fmodules -fimplicit-module-maps -fmodules-cache-path=%t/cache %t/tu.m -o %t/tu.o
Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2457,11 +2457,12 @@
   SourceLocation Loc = D->getLocation();
   unsigned Index = ID - FirstDeclID;
   if (DeclOffsets.size() == Index)
-DeclOffsets.emplace_back(Loc, Offset, DeclTypesBlockStartOffset);
+DeclOffsets.emplace_back(getAdjustedLocation(Loc), Offset,
+ DeclTypesBlockStartOffset);
   else if (DeclOffsets.size() < Index) {
 // FIXME: Can/should this happen?
 DeclOffsets.resize(Index+1);
-DeclOffsets[Index].setLocation(Loc);
+DeclOffsets[Index].setLocation(getAdjustedLocation(Loc));
 DeclOffsets[Index].setBitOffset(Offset, DeclTypesBlockStartOffset);
   } else {
 llvm_unreachable("declarations should be emitted in ID order");
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -161,8 +161,8 @@
 
 namespace {
 
-std::set GetAllModuleMaps(const HeaderSearch &HS,
- Module *RootModule) {
+std::set GetAffectingModuleMaps(const HeaderSearch &HS,
+   Module *RootModule) {
   std::set ModuleMaps{};
   std::set ProcessedModules;
   SmallVector ModulesToProcess{RootModule};
@@ -1468,23 +1468,16 @@
 
 Record.clear();
 Record.push_back(ORIGINAL_FILE);
-Record.push_back(SM.getMainFileID().getOpaqueValue());
+AddFileID(SM.getMainFileID(), Record);
 EmitRecordWithPath(FileAbbrevCode, Record, MainFile->getName());
   }
 
   Record.clear();
-  Record.push_back(SM.getMainFileID().getOpaqueValue());
+  AddFileID(SM.getMainFileID(), Record);
   Stream.EmitRecord(ORIGINAL_FILE_ID, Record);
 
-  std::set AffectingModuleMaps;
-  if (WritingModule) {
-AffectingModuleMaps =
-GetAllModuleMaps(PP.getHeaderSearchInfo(), WritingModule);
-  }
-
   WriteInputFiles(Context.SourceMgr,
-  PP.getHeaderSearchInfo().getHeaderSearchOpts(),
-  AffectingModuleMaps);
+  PP.getHeaderSearchInfo().getHeaderSearchOpts());
   Stream.ExitBlock();
 }
 
@@ -1502,9 +1495,8 @@
 
 } // namespace
 
-void ASTWriter::WriteInputFiles(
-SourceManager &SourceMgr, HeaderSearchOptions &HSOpts,
-std::set &AffectingModuleMaps) {
+void ASTWriter::WriteInputFiles(SourceManager &SourceMgr,
+HeaderSearchOptions &HSOpts) {
   using namespace llvm;
 
   Stream.EnterSubblock(INPUT_FILES_

[PATCH] D136602: NFC: [clang] Template argument cleanups.

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

I like this cleanup in general, just 2 questions.




Comment at: clang/include/clang/AST/TemplateBase.h:592
+  llvm::ArrayRef arguments() const { return Arguments; }
+  llvm::MutableArrayRef arguments() { return Arguments; }
 

Ooh, really?  Are the use cases ones where others are modifying this arguments 
list in place?  All the functions you removed seem to be 'const'.



Comment at: clang/include/clang/AST/Type.h:5298
 
-  void Profile(llvm::FoldingSetNodeID &ID, const ASTContext &Context) {
-Profile(ID, Context, getDeducedType(), getKeyword(), isDependentType(),

What is happening here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136602

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

[PATCH] D136455: [clang][ExtractAPI] Add targetFallback to relationships in symbol graph

2022-10-24 Thread Daniel Grumberg via Phabricator via cfe-commits

dang added a comment.

In D136455#3879849 , @zixuw wrote:

> Is it easy to/worth checking if the target is actually outside of the current 
> module to keep the output smaller and concise?

I think it can be done, since we ignore symbols that don't come from the 
headers provided on the command line, we could just check if the target symbol 
is something that is known to the APISet.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136455

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

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2022-10-24 Thread Roland McGrath via Phabricator via cfe-commits

mcgrathr added a comment.

In D85802#3879950 , @dblaikie wrote:

> In D85802#3879888 , @mcgrathr wrote:
>
>> In D85802#3876106 , @dblaikie wrote:
>>
 The C++ ABI is not part of the Fuchsia system ABI, nor what we call the 
 "Fuchsia compiler ABI". Different users of C++ are free to use whatever 
 C++ ABI they like. Only the backend ABI independent of language-specific 
 issues is necessary to interoperate with other code on Fuchsia.
>>>
>>> Sure enough - but I'm still sort of confused by why the Fuschia Clang 
>>> target/compiler needs more than one C++ ABI. What is it interoperating 
>>> with? (GCC doesn't have a Fuschia target implemented, does it? So what's it 
>>> mean to target the GCC C++ ABI? what is compiling the code that Fuschia is 
>>> trying to interoperate with when Clang targets Fuschia with a non-default 
>>> C++ ABI?)
>>
>> When we use GCC we're using the generic ELF targets. I think it's sufficient 
>> for us to tell you that indeed we do want the option of multiple C++ ABIs to 
>> select from without justifying everything about our work to a Clang reviewer 
>> before we can proceed with meeting the requirements of our system.
>
> Would the generic ELF target support in Clang be adequate to meet that 
> requirement, then? (so Fuschia target could be the custom C++ ABI (& custom C 
> ABI if you likee) and a generic ELF target could be used for GCC ELF 
> compatibility) - then we wouldn't need any C++ ABI customizability?

No. All the aspects of the Fuchsia target not specific to C++ we still want 
done the same way when interoperating with this code.  We're quite confident 
that what we want is a Fuchsia target with multiple options for the C++ ABI.  
If you don't want that flexibility to be available to other targets, then fine 
(though I think that's a poor choice, personally).  Second-guessing everything 
about how we're organized our system and build is not a very helpful tactic in 
compiler reviews.  It would be much appreciated if this review were constrained 
to how the compiler should work rather than what we should want to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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

[PATCH] D136548: [clang][CodeGen] Consistently return nullptr Values for void builtins and scalar initalization

2022-10-24 Thread Eli Friedman via Phabricator via cfe-commits

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

LGTM


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

https://reviews.llvm.org/D136548

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

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2022-10-24 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D85802#3880078 , @mcgrathr wrote:

> In D85802#3879950 , @dblaikie wrote:
>
>> In D85802#3879888 , @mcgrathr wrote:
>>
>>> In D85802#3876106 , @dblaikie 
>>> wrote:
>>>
> The C++ ABI is not part of the Fuchsia system ABI, nor what we call the 
> "Fuchsia compiler ABI". Different users of C++ are free to use whatever 
> C++ ABI they like. Only the backend ABI independent of language-specific 
> issues is necessary to interoperate with other code on Fuchsia.

 Sure enough - but I'm still sort of confused by why the Fuschia Clang 
 target/compiler needs more than one C++ ABI. What is it interoperating 
 with? (GCC doesn't have a Fuschia target implemented, does it? So what's 
 it mean to target the GCC C++ ABI? what is compiling the code that Fuschia 
 is trying to interoperate with when Clang targets Fuschia with a 
 non-default C++ ABI?)
>>>
>>> When we use GCC we're using the generic ELF targets. I think it's 
>>> sufficient for us to tell you that indeed we do want the option of multiple 
>>> C++ ABIs to select from without justifying everything about our work to a 
>>> Clang reviewer before we can proceed with meeting the requirements of our 
>>> system.
>>
>> Would the generic ELF target support in Clang be adequate to meet that 
>> requirement, then? (so Fuschia target could be the custom C++ ABI (& custom 
>> C ABI if you likee) and a generic ELF target could be used for GCC ELF 
>> compatibility) - then we wouldn't need any C++ ABI customizability?
>
> No. All the aspects of the Fuchsia target not specific to C++ we still want 
> done the same way when interoperating with this code.

What sort of aspects does that include? Those aspects wouldn't be respected by 
the other side of that ABI boundary, built with GCC, right?

> We're quite confident that what we want is a Fuchsia target with multiple 
> options for the C++ ABI.  If you don't want that flexibility to be available 
> to other targets, then fine (though I think that's a poor choice, 
> personally).  Second-guessing everything about how we're organized our system 
> and build is not a very helpful tactic in compiler reviews.  It would be much 
> appreciated if this review were constrained to how the compiler should work 
> rather than what we should want to do.

LLVM reviews do include design discussions about what's appropriate to include 
and support in the LLVM project. It's not about second guessing your choices, 
but about understanding them & discussing how they best fit (or don't) in the 
LLVM project.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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

[PATCH] D136572: Harmonize cmake_policy() across standalone builds of all projects

2022-10-24 Thread Michał Górny via Phabricator via cfe-commits

mgorny updated this revision to Diff 470225.
mgorny edited the summary of this revision.
mgorny added a comment.
Herald added a project: LLVM.

Use a shared policy file via `include()` instead.


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

https://reviews.llvm.org/D136572

Files:
  clang/CMakeLists.txt
  cmake/Modules/CMakePolicy.cmake
  flang/CMakeLists.txt
  lld/CMakeLists.txt
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake
  llvm/CMakeLists.txt
  mlir/CMakeLists.txt

Index: mlir/CMakeLists.txt
===
--- mlir/CMakeLists.txt
+++ mlir/CMakeLists.txt
@@ -1,4 +1,7 @@
 # MLIR project.
+cmake_minimum_required(VERSION 3.13.4)
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 # Check if MLIR is built as a standalone project.
 if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
@@ -10,8 +13,6 @@
 include(GNUInstallDirs)
 
 if(MLIR_STANDALONE_BUILD)
-  cmake_minimum_required(VERSION 3.13.4)
-
   find_package(LLVM CONFIG REQUIRED)
   set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${LLVM_CMAKE_DIR})
   include(HandleLLVMOptions)
Index: llvm/CMakeLists.txt
===
--- llvm/CMakeLists.txt
+++ llvm/CMakeLists.txt
@@ -1,17 +1,8 @@
 # See docs/CMake.html for instructions about how to build LLVM with CMake.
 
 cmake_minimum_required(VERSION 3.13.4)
-
-# CMP0114: ExternalProject step targets fully adopt their steps.
-# New in CMake 3.19: https://cmake.org/cmake/help/latest/policy/CMP0114.html
-if(POLICY CMP0114)
-  cmake_policy(SET CMP0114 OLD)
-endif()
-# CMP0116: Ninja generators transform `DEPFILE`s from `add_custom_command()`
-# New in CMake 3.20. https://cmake.org/cmake/help/latest/policy/CMP0116.html
-if(POLICY CMP0116)
-  cmake_policy(SET CMP0116 OLD)
-endif()
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,9 +1,3 @@
-# CMP0116: Ninja generators transform `DEPFILE`s from `add_custom_command()`
-# New in CMake 3.20. https://cmake.org/cmake/help/latest/policy/CMP0116.html
-if(POLICY CMP0116)
-  cmake_policy(SET CMP0116 OLD)
-endif()
-
 if(NOT DEFINED LLVM_COMMON_CMAKE_UTILS)
   set(LLVM_COMMON_CMAKE_UTILS ${CMAKE_CURRENT_SOURCE_DIR}/../cmake)
 endif()
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -1,4 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 # Add path for custom modules.
 set(CMAKE_MODULE_PATH
Index: lld/CMakeLists.txt
===
--- lld/CMakeLists.txt
+++ lld/CMakeLists.txt
@@ -1,4 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 # If we are not building as a part of LLVM, build LLD as an
 # standalone project, using LLVM as an external library:
Index: flang/CMakeLists.txt
===
--- flang/CMakeLists.txt
+++ flang/CMakeLists.txt
@@ -1,4 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 set(CMAKE_BUILD_WITH_INSTALL_NAME_DIR ON)
 
Index: cmake/Modules/CMakePolicy.cmake
===
--- /dev/null
+++ cmake/Modules/CMakePolicy.cmake
@@ -0,0 +1,12 @@
+# CMake policy settings shared between LLVM projects
+
+# CMP0114: ExternalProject step targets fully adopt their steps.
+# New in CMake 3.19: https://cmake.org/cmake/help/latest/policy/CMP0114.html
+if(POLICY CMP0114)
+  cmake_policy(SET CMP0114 OLD)
+endif()
+# CMP0116: Ninja generators transform `DEPFILE`s from `add_custom_command()`
+# New in CMake 3.20. https://cmake.org/cmake/help/latest/policy/CMP0116.html
+if(POLICY CMP0116)
+  cmake_policy(SET CMP0116 OLD)
+endif()
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -1,4 +1,6 @@
 cmake_minimum_required(VERSION 3.13.4)
+include(${CMAKE_CURRENT_SOURCE_DIR}/../cmake/Modules/CMakePolicy.cmake
+  NO_POLICY_SCOPE)
 
 # If we are not building as a part of LLVM, build Clang as an
 # standalone project, using LLVM as an external library:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D134902: [clang] Implement -fstrict-flex-arrays=3

2022-10-24 Thread Bill Wendling via Phabricator via cfe-commits

void added inline comments.



Comment at: clang/include/clang/Basic/LangOptions.h:60
 ///  static_asserts in Triple.cpp and in clang/Basic/HLSLRuntime.h.
 enum class ShaderStage {
   Pixel = 0,

serge-sans-paille wrote:
> Looks unrelated to this patch :-)
I don't see a change here.



Comment at: clang/include/clang/Basic/LangOptions.h:231
 ///   - Reverse the implementation for DR692, DR1395 and DR1432.
 ///   - pack non-POD members of packed structs.
 Ver15,

serge-sans-paille wrote:
> Looks unrelated to this patch.
Or here.



Comment at: clang/lib/AST/ExprConstant.cpp:14085
 return true;
   }
   }

serge-sans-paille wrote:
> fascinatingly off topic. But gives a good hint on what you're working on ;-) 
I'm not sure what you mean.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134902

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

[PATCH] D134128: Resubmit an implemention for constrained template template parameters [P0857R0 Part B]

2022-10-24 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

In D134128#3879295 , @erichkeane 
wrote:

> I'm reasonably OK with this, I'm disappointed the 'skip for specialization' 
> is what was required, but I don't think I know of a better way.  I'll hold 
> off approving this until I've confirmed that libcxx tests + 
> libcxx-modules-tests are properly passing as a result of this.

I wnated to test this config locally, but it doesnt seem to be working for me?  
But you can modify this patch modify the DELETEME file in libcxx (see how he 
did it here: https://reviews.llvm.org/D127695 put it in the review but didnt 
commit it), it will cause libcxx pre-commit, which I think we shoudl do.  Just 
don't commit the DELETEME file obviously.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134128

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

[clang] 7e8af2f - [ARM] Support -mexecute-only with -mlong-calls.

2022-10-24 Thread Eli Friedman via cfe-commits


Author: Zhiyao Ma
Date: 2022-10-24T11:41:24-07:00
New Revision: 7e8af2fc0c068de8bb47d8046b8483234fab3b13

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

LOG: [ARM] Support -mexecute-only with -mlong-calls.

Instead of using constant pools, use movw movt pair.

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

Added: 
llvm/test/CodeGen/Thumb2/thumb2-execute-only-long-calls.ll

Modified: 
clang/lib/Driver/ToolChains/Arch/ARM.cpp
clang/test/Driver/arm-execute-only.c
llvm/lib/Target/ARM/ARMISelLowering.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/ARM.cpp 
b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
index a64909d9a6e77..5b3f7c17c307e 100644
--- a/clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -776,21 +776,15 @@ void arm::getARMTargetFeatures(const Driver &D, const 
llvm::Triple &Triple,
   // This only makes sense for the compiler, not for the assembler.
   if (!ForAS) {
 // Supported only on ARMv6T2 and ARMv7 and above.
-// Cannot be combined with -mno-movt or -mlong-calls
+// Cannot be combined with -mno-movt.
 if (Arg *A = Args.getLastArg(options::OPT_mexecute_only, 
options::OPT_mno_execute_only)) {
   if (A->getOption().matches(options::OPT_mexecute_only)) {
 if (getARMSubArchVersionNumber(Triple) < 7 &&
 llvm::ARM::parseArch(Triple.getArchName()) != 
llvm::ARM::ArchKind::ARMV6T2)
   D.Diag(diag::err_target_unsupported_execute_only) << 
Triple.getArchName();
 else if (Arg *B = Args.getLastArg(options::OPT_mno_movt))
-  D.Diag(diag::err_opt_not_valid_with_opt) << A->getAsString(Args) << 
B->getAsString(Args);
-// Long calls create constant pool entries and have not yet been fixed 
up
-// to play nicely with execute-only. Hence, they cannot be used in
-// execute-only code for now
-else if (Arg *B = Args.getLastArg(options::OPT_mlong_calls, 
options::OPT_mno_long_calls)) {
-  if (B->getOption().matches(options::OPT_mlong_calls))
-D.Diag(diag::err_opt_not_valid_with_opt) << A->getAsString(Args) 
<< B->getAsString(Args);
-}
+  D.Diag(diag::err_opt_not_valid_with_opt)
+  << A->getAsString(Args) << B->getAsString(Args);
 Features.push_back("+execute-only");
   }
 }

diff  --git a/clang/test/Driver/arm-execute-only.c 
b/clang/test/Driver/arm-execute-only.c
index 81b822f1ac068..f69571de10c2a 100644
--- a/clang/test/Driver/arm-execute-only.c
+++ b/clang/test/Driver/arm-execute-only.c
@@ -6,10 +6,6 @@
 // RUN:| FileCheck %s -check-prefix CHECK-EXECUTE-ONLY-NO-MOVT
 // CHECK-EXECUTE-ONLY-NO-MOVT: error: option '-mexecute-only' cannot be 
specified with '-mno-movt'
 
-// RUN: not %clang -target armv8m.main-eabi -mexecute-only -mlong-calls %s 
2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-EXECUTE-ONLY-LONG-CALLS
-// CHECK-EXECUTE-ONLY-LONG-CALLS: error: option '-mexecute-only' cannot be 
specified with '-mlong-calls'
-
 // RUN: %clang -target armv7m-eabi -x assembler -mexecute-only %s -c -### 2>&1 
\
 // RUN:| FileCheck %s --check-prefix=CHECK-NO-EXECUTE-ONLY-ASM
 // CHECK-NO-EXECUTE-ONLY-ASM: warning: argument unused during compilation: 
'-mexecute-only'
@@ -21,7 +17,3 @@
 // RUN: not %clang -target armv8m.main-eabi -mpure-code -mno-movt %s 2>&1 \
 // RUN:| FileCheck %s -check-prefix CHECK-PURE-CODE-NO-MOVT
 // CHECK-PURE-CODE-NO-MOVT: error: option '-mpure-code' cannot be specified 
with '-mno-movt'
-
-// RUN: not %clang -target armv8m.main-eabi -mpure-code -mlong-calls %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-PURE-CODE-LONG-CALLS
-// CHECK-PURE-CODE-LONG-CALLS: error: option '-mpure-code' cannot be specified 
with '-mlong-calls'

diff  --git a/llvm/lib/Target/ARM/ARMISelLowering.cpp 
b/llvm/lib/Target/ARM/ARMISelLowering.cpp
index ccfcd89a64403..c84fe4d661974 100644
--- a/llvm/lib/Target/ARM/ARMISelLowering.cpp
+++ b/llvm/lib/Target/ARM/ARMISelLowering.cpp
@@ -2630,11 +2630,11 @@ 
ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI,
 
   const TargetMachine &TM = getTargetMachine();
   const Module *Mod = MF.getFunction().getParent();
-  const GlobalValue *GV = nullptr;
+  const GlobalValue *GVal = nullptr;
   if (GlobalAddressSDNode *G = dyn_cast(Callee))
-GV = G->getGlobal();
+GVal = G->getGlobal();
   bool isStub =
-  !TM.shouldAssumeDSOLocal(*Mod, GV) && Subtarget->isTargetMachO();
+  !TM.shouldAssumeDSOLocal(*Mod, GVal) && Subtarget->isTargetMachO();
 
   bool isARMFunc = !Subtarget->isThumb() || (isStub && !Subtarget->isMClass());
   bool isLocalARMFunc = false;
@@ -2647,36 +2647,58 @@ 
ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI,
 // those, the tar

1 2 3 >

1 - 100 of 211 matches

Mail list logo