[PATCH] D99487: [CodeGen] Port basic block sections from ELF to COFF

[TaoPan via Phabricator via cfe-commits]

TaoPan added a comment.

I reported bugs of using clang-cl and lld to test 
https://github.com/microsoft/compiler-tests/tree/master/seh

2. clang-cl.exe + lld linker

  a. x4ptcu.c: build error  https://bugs.llvm.org/show_bug.cgi?id=50859

  b. seh0015.c, seh0017.c: build crash  
https://bugs.llvm.org/show_bug.cgi?id=50854

  c. seh0034.c, seh0036.c, seh0041~0043.c, seh0048~0050.c, another build crash  
https://bugs.llvm.org/show_bug.cgi?id=50855

  d. seh0020.c, seh0025, seh0026: build error  
https://bugs.llvm.org/show_bug.cgi?id=50856

  e. sehframes.cpp: build pass, run dead loop  
https://bugs.llvm.org/show_bug.cgi?id=50858


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99487

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

[PATCH] D104896: [DFSan] Change shadow and origin memory layouts to match MSan.

[Andrew via Phabricator via cfe-commits]

browneee created this revision.
browneee added reviewers: stephan.yichao.zhao, gbalats.
Herald added subscribers: pengfei, hiraditya.
browneee requested review of this revision.
Herald added projects: clang, Sanitizers, LLVM.
Herald added subscribers: llvm-commits, Sanitizers, cfe-commits.

Previously on x86_64:

  ++ 0x8000 (top of memory)
  | application memory |
  ++ 0x70008000 (kAppAddr)
  ||
  |   unused   |
  ||
  ++ 0x3000 (kUnusedAddr)
  |   origin   |
  ++ 0x20008000 (kOriginAddr)
  |   unused   |
  ++ 0x2000
  |   shadow memory|
  ++ 0x10008000 (kShadowAddr)
  |   unused   |
  ++ 0x0001
  | reserved by kernel |
  ++ 0x
  
  MEM_TO_SHADOW(mem) = mem & ~0x6000
  SHADOW_TO_ORIGIN(shadow) = kOriginAddr - kShadowAddr + shadow

Now for x86_64:

  ++ 0x8000 (top of memory)
  |application 3   |
  ++ 0x7000
  |  invalid   |
  ++ 0x6100
  |  origin 1  |
  ++ 0x6000
  |application 2   |
  ++ 0x5100
  |  shadow 1  |
  ++ 0x5000
  |  invalid   |
  ++ 0x4000
  |  origin 3  |
  ++ 0x3000
  |  shadow 3  |
  ++ 0x2000
  |  origin 2  |
  ++ 0x1100
  |  invalid   |
  ++ 0x1000
  |  shadow 2  |
  ++ 0x0100
  |application 1   |
  ++ 0x
  
  MEM_TO_SHADOW(mem) = mem ^ 0x5000
  SHADOW_TO_ORIGIN(shadow) = shadow + 0x1000


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104896

Files:
  clang/docs/DataFlowSanitizerDesign.rst
  compiler-rt/lib/dfsan/dfsan.cpp
  compiler-rt/lib/dfsan/dfsan.h
  compiler-rt/lib/dfsan/dfsan_allocator.cpp
  compiler-rt/lib/dfsan/dfsan_platform.h
  compiler-rt/test/dfsan/origin_invalid.c
  llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp
  llvm/test/Instrumentation/DataFlowSanitizer/atomics.ll
  llvm/test/Instrumentation/DataFlowSanitizer/basic.ll
  llvm/test/Instrumentation/DataFlowSanitizer/load.ll
  llvm/test/Instrumentation/DataFlowSanitizer/origin_load.ll
  llvm/test/Instrumentation/DataFlowSanitizer/origin_store.ll
  llvm/test/Instrumentation/DataFlowSanitizer/store.ll

Index: llvm/test/Instrumentation/DataFlowSanitizer/store.ll
===
--- llvm/test/Instrumentation/DataFlowSanitizer/store.ll
+++ llvm/test/Instrumentation/DataFlowSanitizer/store.ll
@@ -22,7 +22,7 @@
   ; COMBINE_PTR_LABEL: load i[[#SBITS]], i[[#SBITS]]* {{.*}} @__dfsan_arg_tls
   ; COMBINE_PTR_LABEL: or i[[#SBITS]]
   ; CHECK: ptrtoint i8* {{.*}} i64
-  ; CHECK-NEXT:and i64
+  ; CHECK-NEXT:xor i64
   ; CHECK-NEXT:inttoptr i64 {{.*}} i[[#SBITS]]*
   ; CHECK-NEXT:getelementptr i[[#SBITS]], i[[#SBITS]]*
   ; CHECK-NEXT:store i[[#SBITS]]
@@ -39,7 +39,7 @@
   ; COMBINE_PTR_LABEL: load i[[#SBITS]], i[[#SBITS]]* {{.*}} @__dfsan_arg_tls
   ; COMBINE_PTR_LABEL: or i[[#SBITS]]
   ; CHECK: ptrtoint i16* {{.*}} i64
-  ; CHECK-NEXT:and i64
+  ; CHECK-NEXT:xor i64
   ; CHECK-NEXT:inttoptr i64 {{.*}} i[[#SBITS]]*
   ; CHECK-NEXT:getelementptr i[[#SBITS]], i[[#SBITS]]*
   ; CHECK-NEXT:store i[[#SBITS]]
@@ -58,7 +58,7 @@
   ; COMBINE_PTR_LABEL: load i[[#SBITS]], i[[#SBITS]]* {{.*}} @__dfsan_arg_tls
   ; COMBINE_PTR_LABEL: or i[[#SBITS]]
   ; CHECK: ptrtoint i32* {{.*}} i64
-  ; CHECK-NEXT:and i64
+  ; CHECK-NEXT:xor i64
   ; CHECK-NEXT:inttoptr i64 {{.*}} i[[#SBITS]]*
   ; CHECK-NEXT:getelementptr i[[#SBITS]], i[[#SBITS]]*
   ; CHECK-NEXT:store i[[#SBITS]]
@@ -81,7 +81,7 @@
   ; COMBINE_PTR_LABEL: load i[[#SBITS]], i[[#SBITS]]* {{.*}} @__dfsan_arg_tls
   ; COMBINE_PTR_LABEL: or i[[#SBITS]]
   ; CHECK: ptrtoint i64* {{.*}} i64
-  ; CHECK-NEXT:and i64
+  ; CHECK-NEXT:xor i64
   ; CHECK-NEXT:inttoptr i64 {{.*}} i[[#SBITS]]*
   ; CHECK-COUNT-8: insertelement {{.*}} i[[#SBITS]]
   ; CHECK-NEXT:bitcast i[[#SBITS]]* {{.*}} <8 x i[[#SBITS]]>*
Index: llvm/test/Instrumentation/DataFlowSanitizer/origin_store.ll
===
--- llvm/test/Instrumentation/DataFlowSanitizer/origin_store.ll
+++ llvm/test/Instrumentation/DataFlowSanitizer/origin_store.ll
@@ -52,9 +52,9 @@
   ; CHECK-NEXT:   %[[#AO:]] = load i32, i32* getelementptr inbounds ([200 x i32], [200 x 

[PATCH] D104892: [clang] Stop providing builtin overload candidate for relational function pointer comparisons

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Thanks, the summary gave me a chuckle :)




Comment at: clang/lib/Sema/SemaExpr.cpp:11809-11812
+Diag(Loc, IsError
+  ? diag::err_typecheck_ordered_comparison_of_function_pointers
+  : 
diag::ext_typecheck_ordered_comparison_of_function_pointers)
+<< LHSType << RHSType << LHS.get()->getSourceRange()

In C++, non-`IsError` cases, this should be a `warn_...` diagnostic that is a 
`Warning<...>`, rather than an `ext_...` diagnostic that is an `ExtWarn<...>`, 
otherwise we'll reject this in `-pedantic-errors` mode. (That's what's 
happening in `test/CXX/drs/dr15xx.cpp`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104892

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

[PATCH] D104550: [analyzer] Implement getType for SVal

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

ASDenysPetrov wrote:
> vsavchenko wrote:
> > ASDenysPetrov wrote:
> > > I'm not sure this is a correct type. I would expect here something like: 
> > > `class LabelType : public Type`.
> > I don't think that I fully understood what you suggest here.  Do you 
> > suggest to add a new type to `Type.h`?
> Yes. As a user I expect to see some special type for labels, not a `void*`. 
> But for the absence of such type let it be as is.
`void *` is the correct type for label values, as defined in the documentation 
of the respective GNU extension to C (which Clang mimics/supports):

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
> You can get the address of a label defined in the current function (or a 
> containing function) with the unary operator '`&&`'. The value has type `void 
> *`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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

[PATCH] D104852: [AArch64][SVEIntrinsicOpts] Convect cntb/h/w/d to vscale intrinsic or constant.

[JunMa via Phabricator via cfe-commits]

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

update clang test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104852

Files:
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cnth.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntw.c
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
  llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-counting-elems.ll

Index: llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-counting-elems.ll
===
--- /dev/null
+++ llvm/test/Transforms/InstCombine/AArch64/sve-intrinsic-opts-counting-elems.ll
@@ -0,0 +1,247 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -instcombine < %s | FileCheck %s
+
+target triple = "aarch64-unknown-linux-gnu"
+
+;
+; CNTB
+;
+
+define i64 @cntb_vl1() {
+; CHECK-LABEL: @cntb_vl1(
+; CHECK-NEXT:ret i64 1
+;
+  %out = call i64 @llvm.aarch64.sve.cntb(i32 1)
+  ret i64 %out
+}
+
+define i64 @cntb_vl2() {
+; CHECK-LABEL: @cntb_vl2(
+; CHECK-NEXT:ret i64 2
+;
+  %out = call i64 @llvm.aarch64.sve.cntb(i32 2)
+  ret i64 %out
+}
+
+define i64 @cntb_vl4() {
+; CHECK-LABEL: @cntb_vl4(
+; CHECK-NEXT:ret i64 4
+;
+  %out = call i64 @llvm.aarch64.sve.cntb(i32 4)
+  ret i64 %out
+}
+
+define i64 @cntb_mul3() {
+; CHECK-LABEL: @cntb_mul3(
+; CHECK-NEXT:ret i64 24
+;
+  %cnt = call i64 @llvm.aarch64.sve.cntb(i32 8)
+  %out = mul i64 %cnt, 3
+  ret i64 %out
+}
+
+define i64 @cntb_mul4() {
+; CHECK-LABEL: @cntb_mul4(
+; CHECK-NEXT:ret i64 64
+;
+  %cnt = call i64 @llvm.aarch64.sve.cntb(i32 9)
+  %out = mul i64 %cnt, 4
+  ret i64 %out
+}
+
+define i64 @cntb_all() {
+; CHECK-LABEL: @cntb_all(
+; CHECK-NEXT:[[TMP1:%.*]] = call i64 @llvm.vscale.i64()
+; CHECK-NEXT:[[OUT:%.*]] = shl i64 [[TMP1]], 4
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %out = call i64 @llvm.aarch64.sve.cntb(i32 31)
+  ret i64 %out
+}
+
+;
+; CNTH
+;
+
+define i64 @cnth_vl1() {
+; CHECK-LABEL: @cnth_vl1(
+; CHECK-NEXT:ret i64 1
+;
+  %out = call i64 @llvm.aarch64.sve.cnth(i32 1)
+  ret i64 %out
+}
+
+define i64 @cnth_vl2() {
+; CHECK-LABEL: @cnth_vl2(
+; CHECK-NEXT:ret i64 2
+;
+  %out = call i64 @llvm.aarch64.sve.cnth(i32 2)
+  ret i64 %out
+}
+
+define i64 @cnth_vl4() {
+; CHECK-LABEL: @cnth_vl4(
+; CHECK-NEXT:ret i64 4
+;
+  %out = call i64 @llvm.aarch64.sve.cnth(i32 4)
+  ret i64 %out
+}
+
+define i64 @cnth_mul3() {
+; CHECK-LABEL: @cnth_mul3(
+; CHECK-NEXT:ret i64 24
+;
+  %cnt = call i64 @llvm.aarch64.sve.cnth(i32 8)
+  %out = mul i64 %cnt, 3
+  ret i64 %out
+}
+
+define i64 @cnth_mul4() {
+; CHECK-LABEL: @cnth_mul4(
+; CHECK-NEXT:[[CNT:%.*]] = call i64 @llvm.aarch64.sve.cnth(i32 9)
+; CHECK-NEXT:[[OUT:%.*]] = shl i64 [[CNT]], 2
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %cnt = call i64 @llvm.aarch64.sve.cnth(i32 9)
+  %out = mul i64 %cnt, 4
+  ret i64 %out
+}
+
+define i64 @cnth_all() {
+; CHECK-LABEL: @cnth_all(
+; CHECK-NEXT:[[TMP1:%.*]] = call i64 @llvm.vscale.i64()
+; CHECK-NEXT:[[OUT:%.*]] = shl i64 [[TMP1]], 3
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %out = call i64 @llvm.aarch64.sve.cnth(i32 31)
+  ret i64 %out
+}
+
+;
+; CNTW
+;
+
+define i64 @cntw_vl1() {
+; CHECK-LABEL: @cntw_vl1(
+; CHECK-NEXT:ret i64 1
+;
+  %out = call i64 @llvm.aarch64.sve.cntw(i32 1)
+  ret i64 %out
+}
+
+define i64 @cntw_vl2() {
+; CHECK-LABEL: @cntw_vl2(
+; CHECK-NEXT:ret i64 2
+;
+  %out = call i64 @llvm.aarch64.sve.cntw(i32 2)
+  ret i64 %out
+}
+
+define i64 @cntw_vl4() {
+; CHECK-LABEL: @cntw_vl4(
+; CHECK-NEXT:ret i64 4
+;
+  %out = call i64 @llvm.aarch64.sve.cntw(i32 4)
+  ret i64 %out
+}
+
+define i64 @cntw_mul3() {
+; CHECK-LABEL: @cntw_mul3(
+; CHECK-NEXT:[[CNT:%.*]] = call i64 @llvm.aarch64.sve.cntw(i32 8)
+; CHECK-NEXT:[[OUT:%.*]] = mul i64 [[CNT]], 3
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %cnt = call i64 @llvm.aarch64.sve.cntw(i32 8)
+  %out = mul i64 %cnt, 3
+  ret i64 %out
+}
+
+define i64 @cntw_mul4() {
+; CHECK-LABEL: @cntw_mul4(
+; CHECK-NEXT:[[CNT:%.*]] = call i64 @llvm.aarch64.sve.cntw(i32 9)
+; CHECK-NEXT:[[OUT:%.*]] = shl i64 [[CNT]], 2
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %cnt = call i64 @llvm.aarch64.sve.cntw(i32 9)
+  %out = mul i64 %cnt, 4
+  ret i64 %out
+}
+
+define i64 @cntw_all() {
+; CHECK-LABEL: @cntw_all(
+; CHECK-NEXT:[[TMP1:%.*]] = call i64 @llvm.vscale.i64()
+; CHECK-NEXT:[[OUT:%.*]] = shl i64 [[TMP1]], 2
+; CHECK-NEXT:ret i64 [[OUT]]
+;
+  %out = call i64 @llvm.aarch64.sve.cntw(i32 31)
+  ret i64 %out
+}
+
+
+;
+; CNTD
+;
+
+define i64 @cntd_vl1() {
+; CHECK-LABEL: @cntd_vl1(
+; CHECK-NEXT:ret i64 1
+;
+  %out = call i64 

[PATCH] D104601: [Preprocessor] Implement -fnormalize-whitespace.

[Michael Kruse via Phabricator via cfe-commits]

Meinersbur added a comment.

During a trial phase while compiling everything twice with ccache I got the 
following results.

Only unify_mode::

  $ ccache -d . -s
  cache directory .
  primary config  ./ccache.conf
  secondary config (readonly) 
/home/meinersbur/install/ccache/release/etc/ccache.conf
  stats updated   Fri Jun 25 02:00:22 2021
  stats zeroedWed Jun 23 03:22:36 2021
  cache hit (direct)  1001
  cache hit (preprocessed)5904
  cache miss 10717
  cache hit rate 39.18 %
  compile failed 5
  cleanups performed 0
  files in cache 38182
  cache size   1.9 GB
  max cache size   5.5 GB

unify_mode with `-fnormalize-whitespace`:

  $ ccache -d . -s
  cache directory .
  primary config  ./ccache.conf
  secondary config (readonly) 
/home/meinersbur/install/ccache/release/etc/ccache.conf
  stats updated   Fri Jun 25 02:04:19 2021
  stats zeroedWed Jun 23 03:22:31 2021
  cache hit (direct)  1001
  cache hit (preprocessed)2663
  cache miss 13957
  cache hit rate 20.79 %
  compile failed 5
  cleanups performed 0
  files in cache 44661
  cache size   2.4 GB
  max cache size   5.5 GB

Admittedly, I focused on changes (of Clang and Polly) like refactoring, 
improving comments, minimize difference to upstream (clang-)formatting etc. 
during the testing.

The difference is most pronounced with changes such as 
rG3e8d1e8b12ba9017b861fff94afdd4a29b39de17 
:

  cache hit (direct) 0
  cache hit (preprocessed)   0
  cache miss  2245
  cache hit rate  0.00 %

vs

  cache hit (direct) 0
  cache hit (preprocessed)2235
  cache miss10
  cache hit rate 99.55 %

(the misses come from compilations with warning diagnostics)

In D104601#2831951 , @dblaikie wrote:

> One of the concerns I'd have, for instance (have you done some broad testing 
> of these patches on sizable code bases?) is that it wouldn't surprise me if 
> clang had some scalability bugs/issues with very long source lines - so it 
> might be necessary to introduce some (arbitrary?) newlines to break up the 
> code. Though I'm not sure - no need to do that pre-emptively, but might be 
> good to have some data that indicates whether this might be a problem or not.

I found no such issues during my trials. However, I think the request is 
understandable an I would implement it on request. It introduces a new problem 
having to determine where no newlines mat be introduced (e.g. within a #pragma).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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

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

[Manas Gupta via Phabricator via cfe-commits]

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

Fix issues involving usage of `uadd_ov` and family of functions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103440

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c

Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -251,3 +251,93 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testAdditionRules(unsigned int a, unsigned int b, int c, int d) {
+  if (a == 0) {
+clang_analyzer_eval((a + 0) == 0); // expected-warning{{TRUE}}
+  }
+
+  // Checks for unsigned operands
+  clang_analyzer_eval((a + b) < 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((a + b) <= UINT_MAX); // expected-warning{{TRUE}}
+
+  if (a == UINT_MAX && b == UINT_MAX) {
+clang_analyzer_eval((a + b) == UINT_MAX - 1); // expected-warning{{TRUE}}
+  }
+
+  // Checks for inclusive ranges for unsigned integers
+  if (a <= 10 && b <= 20) {
+clang_analyzer_eval((a + b) >= 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((a + b) > 30); // expected-warning{{FALSE}}
+  }
+
+  // Checks for negative signed integers
+  if (c < 0 && d < 0) {
+clang_analyzer_eval((c + d) != -1); // expected-warning{{TRUE}}
+  }
+
+  if (c < 0 && c != INT_MIN && d < 0) {
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) <= -2); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= 1); // expected-warning{{UNKNOWN}}
+  }
+
+  if (c == INT_MIN && d == INT_MIN) {
+clang_analyzer_eval((c + d) == 0); // expected-warning{{TRUE}}
+  }
+
+  if (c == INT_MIN && d < 0 && d != INT_MIN) {
+clang_analyzer_eval((c + d) > 0); // expected-warning{{TRUE}}
+  }
+
+  if (c < 0 && c >= -20 && d < 0 && d >= -40) {
+clang_analyzer_eval((c + d) < -1); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) >= -60); // expected-warning{{TRUE}}
+  }
+
+  // Checks for integers with different sign bits
+  if (c < 0 && d > 0) {
+if (c >= -20 && d <= 10) {
+  clang_analyzer_eval((c + d) > -20); // expected-warning{{TRUE}}
+  clang_analyzer_eval((c + d) < 10); // expected-warning{{TRUE}}
+}
+  }
+
+  // Checks for overlapping signed integers ranges
+  if (c >= -20 && c <= 20 && d >= -10 && d <= 10) {
+clang_analyzer_eval((c + d) >= -30); // expected-warning{{TRUE}}
+clang_analyzer_eval((c + d) <= 30); // expected-warning{{TRUE}}
+  }
+
+  // Checks for positive signed integers
+  if (c > 0 && d > 0) {
+clang_analyzer_eval((c + d) == 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+  }
+
+  // Check when Max overflows from positive-side
+  if (c >= 10 && d >= 0 && d <= 10) {
+clang_analyzer_eval((c + d) == INT_MIN + 10); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+  }
+
+  // Checks when Min overflows from negative side
+  if (c <= 10 && d >= -10 && d <= 0) {
+clang_analyzer_eval((c + d) == 11); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == INT_MAX - 10); // expected-warning{{FALSE}}
+  }
+
+  // Checks producing overflowing range with different signs
+  int HALF_INT_MAX = INT_MAX / 2;
+  if (c >= HALF_INT_MAX - 10 && c <= HALF_INT_MAX + 10 &&
+  d >= HALF_INT_MAX - 10 && d <= HALF_INT_MAX + 10) {
+// The resulting range for (c + d) will be:
+//   [INT_MIN, INT_MIN + 18] U [INT_MAX - 21, INT_MAX]
+clang_analyzer_eval((c + d) <= INT_MIN + 18); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) >= INT_MAX - 21); // expected-warning{{UNKNOWN}}
+clang_analyzer_eval((c + d) == INT_MIN + 19); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == INT_MAX - 22); // expected-warning{{FALSE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -17,6 +17,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SValVisitor.h"
+#include "llvm/ADT/APSInt.h"
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
@@ -964,6 +965,8 @@
   return VisitBinaryOperator(LHS, RHS, T);
 case BO_Rem:
   return VisitBinaryOperator(LHS, RHS, T);
+case 

[PATCH] D103615: [Clang] Add option for vector compare compatibility.

[Stefan Pintilie via Phabricator via cfe-commits]

stefanp updated this revision to Diff 354422.
stefanp added a comment.

Updated the name of the option to cover all of the inconsistencies for vector
pixel/bool. Future patches will continue to use this option to define the
behaviour of these two types.

Reworded the warning message.
Added InGroup<> to the warning.
Set the default to Default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103615

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/vector-compat-pixel-bool-ternary.c
  clang/test/CodeGen/vector-compat-pixel-bool.c
  clang/test/CodeGen/vector-compat-ternary.c
  clang/test/CodeGen/vector-compat.c

Index: clang/test/CodeGen/vector-compat.c
===
--- /dev/null
+++ clang/test/CodeGen/vector-compat.c
@@ -0,0 +1,162 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: not %clang_cc1 -target-feature +altivec -target-feature +vsx \
+// RUN:   -faltivec-src-compat=mixed -triple powerpc-unknown-unknown -S -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=ERROR
+// RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx \
+// RUN:   -faltivec-src-compat=gcc -triple powerpc-unknown-unknown -S -emit-llvm %s -o - | FileCheck %s
+// RUN: not %clang_cc1 -target-feature +altivec -target-feature +vsx \
+// RUN:   -faltivec-src-compat=xl -triple powerpc-unknown-unknown -S -emit-llvm %s -o - 2>&1 | FileCheck %s --check-prefix=ERROR
+// RUN: %clang -mcpu=pwr8 -faltivec-src-compat=gcc --target=powerpc-unknown-unknown -S -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang -mcpu=pwr9 -faltivec-src-compat=gcc --target=powerpc-unknown-unknown -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK-LABEL: @ui8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca <16 x i8>, align 16
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca <16 x i8>, align 16
+// CHECK-NEXT:store <16 x i8> [[A:%.*]], <16 x i8>* [[A_ADDR]], align 16
+// CHECK-NEXT:store <16 x i8> [[B:%.*]], <16 x i8>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = load <16 x i8>, <16 x i8>* [[A_ADDR]], align 16
+// CHECK-NEXT:[[TMP1:%.*]] = load <16 x i8>, <16 x i8>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[CMP:%.*]] = icmp eq <16 x i8> [[TMP0]], [[TMP1]]
+// CHECK-NEXT:[[SEXT:%.*]] = sext <16 x i1> [[CMP]] to <16 x i8>
+// CHECK-NEXT:ret <16 x i8> [[SEXT]]
+//
+// ERROR: returning 'int' from a function with incompatible result type
+vector unsigned char ui8(vector unsigned char a, vector unsigned char b) {
+  return a == b;
+}
+
+// CHECK-LABEL: @si8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca <16 x i8>, align 16
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca <16 x i8>, align 16
+// CHECK-NEXT:store <16 x i8> [[A:%.*]], <16 x i8>* [[A_ADDR]], align 16
+// CHECK-NEXT:store <16 x i8> [[B:%.*]], <16 x i8>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = load <16 x i8>, <16 x i8>* [[A_ADDR]], align 16
+// CHECK-NEXT:[[TMP1:%.*]] = load <16 x i8>, <16 x i8>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[CMP:%.*]] = icmp eq <16 x i8> [[TMP0]], [[TMP1]]
+// CHECK-NEXT:[[SEXT:%.*]] = sext <16 x i1> [[CMP]] to <16 x i8>
+// CHECK-NEXT:ret <16 x i8> [[SEXT]]
+//
+// ERROR: returning 'int' from a function with incompatible result type
+vector signed char si8(vector signed char a, vector signed char b) {
+  return a == b;
+}
+
+// CHECK-LABEL: @ui16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:store <8 x i16> [[A:%.*]], <8 x i16>* [[A_ADDR]], align 16
+// CHECK-NEXT:store <8 x i16> [[B:%.*]], <8 x i16>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = load <8 x i16>, <8 x i16>* [[A_ADDR]], align 16
+// CHECK-NEXT:[[TMP1:%.*]] = load <8 x i16>, <8 x i16>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[CMP:%.*]] = icmp eq <8 x i16> [[TMP0]], [[TMP1]]
+// CHECK-NEXT:[[SEXT:%.*]] = sext <8 x i1> [[CMP]] to <8 x i16>
+// CHECK-NEXT:ret <8 x i16> [[SEXT]]
+//
+// ERROR: returning 'int' from a function with incompatible result type
+vector unsigned short ui16(vector unsigned short a, vector unsigned short b) {
+  return a == b;
+}
+
+// CHECK-LABEL: @si16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca <8 x i16>, align 16
+// CHECK-NEXT:store <8 x i16> [[A:%.*]], <8 x i16>* [[A_ADDR]], align 16
+// CHECK-NEXT:store <8 x i16> [[B:%.*]], <8 x i16>* [[B_ADDR]], align 16
+// CHECK-NEXT:[[TMP0:%.*]] = load <8 x i16>, <8 x i16>* [[A_ADDR]], align 16
+// CHECK-NEXT:

[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

First part of the split implemented at: https://reviews.llvm.org/D104892
I will reuse this DR for the second part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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

[PATCH] D104892: [clang] Stop providing builtin overload candidate for relational function pointer comparisons

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
mizvekov requested review of this revision.
Herald added projects: clang, Sanitizers.
Herald added subscribers: Sanitizers, cfe-commits.

Word on the grapevine was that the committee had some discussion that
ended with unanimous agreement on eliminating relational function pointer 
comparisons.

We wanted to be bold and just ban all of them cold turkey.
But then we chickened out at the last second and are going for
eliminating just the spaceship overload candidate instead, for now.

See D104680  for reference.

This should be fine and "safe", because the only possible semantic change this
would cause is that overload resoltion could possibly be ambiguous if
there was another viable candidate equally as good.

But to save face a little we are going to:

- Issue an "error" for three-way comparisons on function pointers. But all this 
is doing really is changing one vague error message, from an "invalid operands 
to binary expression" into an "ordered comparison of function pointers", which 
sounds more like we mean business.
- Otherwise "warn" that comparing function pointers like that is totally not 
cool (unless we are told to keep quiet about this).
- Treat them all as errors with '-pedantic-errors'.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104892

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr15xx.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/FixIt/fixit.cpp
  clang/test/Parser/cxx-template-argument.cpp
  clang/test/Sema/compare.c
  clang/test/SemaCXX/compare-cxx2a.cpp
  clang/test/SemaCXX/compare-function-pointer.cpp
  clang/test/SemaTemplate/resolve-single-template-id.cpp
  compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp

Index: compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
===
--- compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
+++ compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,10 +39,11 @@
 
   // It matters whether the unloaded module has a higher or lower address range
   // than the remaining one. Make sure to test both cases.
+  bool lt = reinterpret_cast(bar1) < reinterpret_cast(bar2);
   if (argc < 2)
-dlclose(bar1 < bar2 ? handle1 : handle2);
+dlclose(lt ? handle1 : handle2);
   else
-dlclose(bar1 < bar2 ? handle2 : handle1);
+dlclose(lt ? handle2 : handle1);
   return 0;
 }
 #endif
Index: clang/test/SemaTemplate/resolve-single-template-id.cpp
===
--- clang/test/SemaTemplate/resolve-single-template-id.cpp
+++ clang/test/SemaTemplate/resolve-single-template-id.cpp
@@ -65,12 +65,14 @@
   void (*u)(int) = oneT;
 
   b = (void (*)()) twoT;
-  
-  one < one; //expected-warning {{self-comparison always evaluates to false}} \
- //expected-warning {{relational comparison result unused}} 
 
-  oneT < oneT;  //expected-warning {{self-comparison always evaluates to false}} \
-  //expected-warning {{relational comparison result unused}}
+  one < one; // expected-warning {{self-comparison always evaluates to false}} \
+ // expected-warning {{relational comparison result unused}}   \
+ // expected-warning {{ordered comparison of function pointers}}
+
+  oneT < oneT; // expected-warning {{self-comparison always evaluates to false}} \
+ // expected-warning {{relational comparison result unused}}   \
+ // expected-warning {{ordered comparison of function pointers}}
 
   two < two; //expected-error 2 {{reference to overloaded function could not be resolved; did you mean to call it with no arguments?}} expected-error {{invalid operands to binary expression ('void' and 'void')}}
   twoT < twoT; //expected-error {{reference to overloaded function could not be resolved; did you mean to call it?}} {{cannot resolve overloaded function 'twoT' from context}}
Index: clang/test/SemaCXX/compare-function-pointer.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/compare-function-pointer.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+using fp0_t = void (*)();
+using fp1_t = int (*)();
+
+extern fp0_t a, b;
+extern fp1_t c;
+
+bool eq0 = a == b;
+bool ne0 = a != b;
+bool lt0 = a < b;   // expected-warning {{ordered comparison of function pointers ('fp0_t' (aka 'void (*)()') and 'fp0_t')}}
+bool le0 = a <= b;  // expected-warning {{ordered comparison of 

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji 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 rGf3ef4f5bff26: [PowerPC] Add XL compat __compare_and_swap 
builtins (authored by jsji).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104837

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -0,0 +1,47 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:-emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swap(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// CHECK-NEXT:store i32 [[B:%.*]], i32* [[B_ADDR]], align 4
+// CHECK-NEXT:store i32 [[C:%.*]], i32* [[C_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[C_ADDR]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B_ADDR]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A_ADDR]], i32 [[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swap(int a, int b, int c) {
+  __compare_and_swap(, , c);
+}
+
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
+// CHECK-NEXT:store i64 [[B:%.*]], i64* [[B_ADDR]], align 8
+// CHECK-NEXT:store i64 [[C:%.*]], i64* [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[B_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i64* [[A_ADDR]], i64 [[TMP1]], i64 [[TMP0]] monotonic monotonic, align 8
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i64, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i64, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swaplp(long a, long b, long c) {
+  __compare_and_swaplp(, , c);
+}
+
Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
@@ -0,0 +1,19 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr8 \
+// RUN:   -verify %s
+
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swap(, , c); // expected-warning {{incompatible pointer types passing 'long *' to parameter of type 'int *'}}
+
+}
+
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);// expected-warning {{incompatible pointer types passing 'int *' to parameter of type 'long *'}}
+
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -15427,6 +15427,19 @@
 Value *Call = Builder.CreateCall(F, CallOps);
 return Builder.CreateAlignedStore(Call, Ops[0], MaybeAlign(64));
   }
+
+  case PPC::BI__builtin_ppc_compare_and_swap:
+  case PPC::BI__builtin_ppc_compare_and_swaplp: {
+Address Addr = EmitPointerWithAlignment(E->getArg(0));
+Address OldValAddr = EmitPointerWithAlignment(E->getArg(1));
+Value *OldVal = Builder.CreateLoad(OldValAddr);
+QualType AtomicTy = E->getArg(0)->getType()->getPointeeType();
+LValue LV = MakeAddrLValue(Addr, AtomicTy);
+auto Pair = EmitAtomicCompareExchange(
+LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
+llvm::AtomicOrdering::Monotonic, llvm::AtomicOrdering::Monotonic, true);
+return Pair.second;
+  }
   }
 }
 
Index: clang/lib/Basic/Targets/PPC.cpp

[clang] f3ef4f5 - [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji via cfe-commits]

Author: Jinsong Ji
Date: 2021-06-25T01:08:48Z
New Revision: f3ef4f5bff26ac4196a15dad7773a03b9d6df21d

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

LOG: [PowerPC] Add XL compat __compare_and_swap builtins

Prototype
int __compare_and_swap (volatile int* addr, int* old_val_addr, int
new_val);

int __compare_and_swaplp (volatile long* addr, long* old_val_addr, long
new_val);

Refer to
https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=functions-compare-swap-compare-swaplp

Reviewed By: w2yehia

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

Added: 
clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
clang/test/CodeGen/builtins-ppc-xlcompat-cas.c

Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/lib/Basic/Targets/PPC.cpp
clang/lib/CodeGen/CGBuiltin.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 9d7f765a2133c..47b485473342b 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -45,6 +45,8 @@ BUILTIN(__builtin_ppc_dcbt, "vv*", "")
 BUILTIN(__builtin_ppc_dcbtst, "vv*", "")
 BUILTIN(__builtin_ppc_dcbz, "vv*", "")
 BUILTIN(__builtin_ppc_icbt, "vv*", "")
+BUILTIN(__builtin_ppc_compare_and_swap, "iiD*i*i", "")
+BUILTIN(__builtin_ppc_compare_and_swaplp, "iLiD*Li*Li", "")
 
 BUILTIN(__builtin_ppc_get_timebase, "ULLi", "n")
 

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 3dfc0c0751e44..e051826c52168 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -97,6 +97,9 @@ static void defineXLCompatMacros(MacroBuilder ) {
   Builder.defineMacro("__dcbtst", "__builtin_ppc_dcbtst");
   Builder.defineMacro("__dcbz", "__builtin_ppc_dcbz");
   Builder.defineMacro("__icbt", "__builtin_ppc_icbt");
+  Builder.defineMacro("__compare_and_swap", "__builtin_ppc_compare_and_swap");
+  Builder.defineMacro("__compare_and_swaplp",
+  "__builtin_ppc_compare_and_swaplp");
 }
 
 /// PPCTargetInfo::getTargetDefines - Return a set of the PowerPC-specific

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index da16ee3ea722f..e8ad4e009bfb2 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -15427,6 +15427,19 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned 
BuiltinID,
 Value *Call = Builder.CreateCall(F, CallOps);
 return Builder.CreateAlignedStore(Call, Ops[0], MaybeAlign(64));
   }
+
+  case PPC::BI__builtin_ppc_compare_and_swap:
+  case PPC::BI__builtin_ppc_compare_and_swaplp: {
+Address Addr = EmitPointerWithAlignment(E->getArg(0));
+Address OldValAddr = EmitPointerWithAlignment(E->getArg(1));
+Value *OldVal = Builder.CreateLoad(OldValAddr);
+QualType AtomicTy = E->getArg(0)->getType()->getPointeeType();
+LValue LV = MakeAddrLValue(Addr, AtomicTy);
+auto Pair = EmitAtomicCompareExchange(
+LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
+llvm::AtomicOrdering::Monotonic, llvm::AtomicOrdering::Monotonic, 
true);
+return Pair.second;
+  }
   }
 }
 

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
new file mode 100644
index 0..c35c54d6b1858
--- /dev/null
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
@@ -0,0 +1,19 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr8 \
+// RUN:   -verify %s
+
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swap(, , c); // expected-warning {{incompatible pointer 
types passing 'long *' to parameter of type 'int *'}}
+
+}
+
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);// expected-warning {{incompatible pointer 
types passing 'int *' to parameter of type 'long *'}}
+
+}

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-cas.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
new file mode 100644
index 0..ea4b349d9a523
--- /dev/null
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -0,0 +1,47 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:-emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swap(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji via Phabricator via cfe-commits]

jsji added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c:19
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A]], i32 
[[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1

w2yehia wrote:
> i dont think we need to check for the extractvalue instructions, they can be 
> optimized away in theory.
Yes, but this is autogenerated for easier maintenance. Also, clang tests won't 
turn on optimization by default, so they won't be optimized away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104837

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

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji via Phabricator via cfe-commits]

jsji updated this revision to Diff 354410.
jsji added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104837

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -0,0 +1,47 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:-emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swap(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[A:%.*]], i32* [[A_ADDR]], align 4
+// CHECK-NEXT:store i32 [[B:%.*]], i32* [[B_ADDR]], align 4
+// CHECK-NEXT:store i32 [[C:%.*]], i32* [[C_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[C_ADDR]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B_ADDR]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A_ADDR]], i32 [[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swap(int a, int b, int c) {
+  __compare_and_swap(, , c);
+}
+
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[B_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[C_ADDR:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
+// CHECK-NEXT:store i64 [[B:%.*]], i64* [[B_ADDR]], align 8
+// CHECK-NEXT:store i64 [[C:%.*]], i64* [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[C_ADDR]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[B_ADDR]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i64* [[A_ADDR]], i64 [[TMP1]], i64 [[TMP0]] monotonic monotonic, align 8
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i64, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i64, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swaplp(long a, long b, long c) {
+  __compare_and_swaplp(, , c);
+}
+
Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
@@ -0,0 +1,19 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr8 \
+// RUN:   -verify %s
+
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swap(, , c); // expected-warning {{incompatible pointer types passing 'long *' to parameter of type 'int *'}}
+
+}
+
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);// expected-warning {{incompatible pointer types passing 'int *' to parameter of type 'long *'}}
+
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -15427,6 +15427,19 @@
 Value *Call = Builder.CreateCall(F, CallOps);
 return Builder.CreateAlignedStore(Call, Ops[0], MaybeAlign(64));
   }
+
+  case PPC::BI__builtin_ppc_compare_and_swap:
+  case PPC::BI__builtin_ppc_compare_and_swaplp: {
+Address Addr = EmitPointerWithAlignment(E->getArg(0));
+Address OldValAddr = EmitPointerWithAlignment(E->getArg(1));
+Value *OldVal = Builder.CreateLoad(OldValAddr);
+QualType AtomicTy = E->getArg(0)->getType()->getPointeeType();
+LValue LV = MakeAddrLValue(Addr, AtomicTy);
+auto Pair = EmitAtomicCompareExchange(
+LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
+llvm::AtomicOrdering::Monotonic, llvm::AtomicOrdering::Monotonic, true);
+return Pair.second;
+  }
   }
 }
 
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -97,6 +97,9 @@
   Builder.defineMacro("__dcbtst", 

[PATCH] D104822: [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Craig Topper via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf225367305c8: [RISCV] Add vget/vset intrinsics for inserting 
and extracting between different… (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104822

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
@@ -0,0 +1,546 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d -target-feature +experimental-v \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck --check-prefix=CHECK-RV64 %s
+
+#include 
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m2_t test_vset_v_i8m1_i8m2(vint8m2_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 24)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m1_i8m4(vint8m4_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m2_i8m4(vint8m4_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 56)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m1_i8m8(vint8m8_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m2_i8m8(vint8m8_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m8(dest, 2, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m4_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv32i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m4_i8m8(vint8m8_t dest, vint8m4_t val) {
+  return vset_v_i8m4_i8m8(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv8i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 4)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m2_t test_vset_v_i16m1_i16m2(vint16m2_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 12)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m1_i16m4(vint16m4_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m2_i16m4(vint16m4_t dest, vint16m2_t val) {
+  return vset_v_i16m2_i16m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 28)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m8_t test_vset_v_i16m1_i16m8(vint16m8_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//

[clang] f225367 - [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Craig Topper via cfe-commits]

Author: Craig Topper
Date: 2021-06-24T18:06:36-07:00
New Revision: f225367305c82ce391bb470f735b19e924ff7372

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

LOG: [RISCV] Add vget/vset intrinsics for inserting and extracting between 
different lmuls.

These allow getting a whole register from a larger lmul. Or
inserting a whole register into a larger lmul register. Fractional
lmuls are not supported as they would require a vslide.

Based on this update to the intrinsic doc
https://github.com/riscv/rvv-intrinsic-doc/pull/99

Reviewed By: HsiangKai

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

Added: 
clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c

Modified: 
clang/include/clang/Basic/riscv_vector.td
clang/lib/Sema/SemaChecking.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/riscv_vector.td 
b/clang/include/clang/Basic/riscv_vector.td
index 886929919d6e6..7cdec1477962b 100644
--- a/clang/include/clang/Basic/riscv_vector.td
+++ b/clang/include/clang/Basic/riscv_vector.td
@@ -1609,4 +1609,41 @@ let HasMask = false, HasVL = false, 
HasNoMaskedOverloaded = false,
   def vlmul_ext_u # dst_lmul : RVVBuiltin<"Uv" # dst_lmul # "Uv", dst_lmul 
# "UvUv", "csil">;
 }
   }
+
+  let Name = "vget_v",
+  ManualCodegen = [{
+  {
+ID = Intrinsic::experimental_vector_extract;
+ScalableVectorType *VecTy = cast(ResultType);
+Ops[1] = Builder.CreateMul(Ops[1],
+   ConstantInt::get(Ops[1]->getType(),
+
VecTy->getMinNumElements()));
+IntrinsicTypes = {ResultType, Ops[0]->getType()};
+return Builder.CreateCall(CGM.getIntrinsic(ID, IntrinsicTypes), Ops, 
"");
+  }
+  }] in {
+foreach dst_lmul = ["(SFixedLog2LMUL:0)", "(SFixedLog2LMUL:1)", 
"(SFixedLog2LMUL:2)"] in {
+  def : RVVBuiltin<"v" # dst_lmul # "v", dst_lmul # "vvKz", "csilfd">;
+  def : RVVBuiltin<"Uv" # dst_lmul # "Uv", dst_lmul # "UvUvKz", "csil">;
+}
+  }
+
+  let Name = "vset_v", Log2LMUL = [0, 1, 2],
+  ManualCodegen = [{
+  {
+ID = Intrinsic::experimental_vector_insert;
+IntrinsicTypes = {ResultType, Ops[2]->getType()};
+ScalableVectorType *VecTy = 
cast(Ops[2]->getType());
+Ops[1] = Builder.CreateMul(Ops[1],
+   ConstantInt::get(Ops[1]->getType(),
+
VecTy->getMinNumElements()));
+std::swap(Ops[1], Ops[2]);
+return Builder.CreateCall(CGM.getIntrinsic(ID, IntrinsicTypes), Ops, 
"");
+  }
+  }] in {
+foreach dst_lmul = ["(LFixedLog2LMUL:1)", "(LFixedLog2LMUL:2)", 
"(LFixedLog2LMUL:3)"] in {
+  def : RVVBuiltin<"v" # dst_lmul # "v", dst_lmul # "v" # dst_lmul # 
"vKzv", "csilfd">;
+  def : RVVBuiltin<"Uv" # dst_lmul # "Uv", dst_lmul # "Uv" # dst_lmul 
#"UvKzUv", "csil">;
+}
+  }
 }

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 561c83eddce2f..17eeebb0c6799 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3488,6 +3488,132 @@ bool Sema::CheckRISCVBuiltinFunctionCall(const 
TargetInfo ,
   case RISCV::BI__builtin_rvv_vsetvlimax:
 return SemaBuiltinConstantArgRange(TheCall, 0, 0, 3) ||
CheckRISCVLMUL(TheCall, 1);
+  case RISCV::BI__builtin_rvv_vget_v_i8m2_i8m1:
+  case RISCV::BI__builtin_rvv_vget_v_i16m2_i16m1:
+  case RISCV::BI__builtin_rvv_vget_v_i32m2_i32m1:
+  case RISCV::BI__builtin_rvv_vget_v_i64m2_i64m1:
+  case RISCV::BI__builtin_rvv_vget_v_f32m2_f32m1:
+  case RISCV::BI__builtin_rvv_vget_v_f64m2_f64m1:
+  case RISCV::BI__builtin_rvv_vget_v_u8m2_u8m1:
+  case RISCV::BI__builtin_rvv_vget_v_u16m2_u16m1:
+  case RISCV::BI__builtin_rvv_vget_v_u32m2_u32m1:
+  case RISCV::BI__builtin_rvv_vget_v_u64m2_u64m1:
+  case RISCV::BI__builtin_rvv_vget_v_i8m4_i8m2:
+  case RISCV::BI__builtin_rvv_vget_v_i16m4_i16m2:
+  case RISCV::BI__builtin_rvv_vget_v_i32m4_i32m2:
+  case RISCV::BI__builtin_rvv_vget_v_i64m4_i64m2:
+  case RISCV::BI__builtin_rvv_vget_v_f32m4_f32m2:
+  case RISCV::BI__builtin_rvv_vget_v_f64m4_f64m2:
+  case RISCV::BI__builtin_rvv_vget_v_u8m4_u8m2:
+  case RISCV::BI__builtin_rvv_vget_v_u16m4_u16m2:
+  case RISCV::BI__builtin_rvv_vget_v_u32m4_u32m2:
+  case RISCV::BI__builtin_rvv_vget_v_u64m4_u64m2:
+  case RISCV::BI__builtin_rvv_vget_v_i8m8_i8m4:
+  case RISCV::BI__builtin_rvv_vget_v_i16m8_i16m4:
+  case RISCV::BI__builtin_rvv_vget_v_i32m8_i32m4:
+  case RISCV::BI__builtin_rvv_vget_v_i64m8_i64m4:
+  case RISCV::BI__builtin_rvv_vget_v_f32m8_f32m4:
+  case RISCV::BI__builtin_rvv_vget_v_f64m8_f64m4:
+  case RISCV::BI__builtin_rvv_vget_v_u8m8_u8m4:
+  

[clang] e8cded5 - Unsupported sanitize-coverage-old-pm.c on 32 bit Arm

[Muhammad Omair Javaid via cfe-commits]

Author: Muhammad Omair Javaid
Date: 2021-06-25T00:57:24Z
New Revision: e8cded57fbf7b2b81aefd569b95f38ae97948ef0

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

LOG: Unsupported sanitize-coverage-old-pm.c on 32 bit Arm

sanitize-coverage-old-pm.c is passing intermittently on different
arm v7 machines. This patch moves it to unsupported on all arm 32
targets reporting armv8l core.

Added: 


Modified: 
clang/test/CodeGen/sanitize-coverage-old-pm.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-coverage-old-pm.c 
b/clang/test/CodeGen/sanitize-coverage-old-pm.c
index 610dd651587f..cbed401b1e02 100644
--- a/clang/test/CodeGen/sanitize-coverage-old-pm.c
+++ b/clang/test/CodeGen/sanitize-coverage-old-pm.c
@@ -6,6 +6,7 @@
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=undefined  -fsanitize-coverage=trace-pc,trace-cmp -o - 
-flegacy-pass-manager | FileCheck %s --check-prefixes=CHECK,UBSAN
 //
 // Host armv7 is currently unsupported: 
https://bugs.llvm.org/show_bug.cgi?id=46117
+// UNSUPPORTED: armv8l
 // XFAIL: armv7, thumbv7
 // The same issue also occurs on a riscv32 host.
 // XFAIL: riscv32



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

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[wael yehia via Phabricator via cfe-commits]

w2yehia accepted this revision.
w2yehia added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c:19
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A]], i32 
[[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1

i dont think we need to check for the extractvalue instructions, they can be 
optimized away in theory.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c:24
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  int b = 0, c = 0;

just an FYI that a volatile could have been avoided if the arguments to 
__compare_and_swap where function parameters


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104837

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

[PATCH] D104887: [clang] Evaluate strlen of strcpy argument for -Wfortify-source.

[Michael Benfield via Phabricator via cfe-commits]

mbenfield created this revision.
mbenfield added reviewers: george.burgess.iv, cjdb, rsmith.
mbenfield requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Also introduce Expr::tryEvaluateStrLen.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104887

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Analysis/security-syntax-checks.m
  clang/test/Sema/warn-fortify-source.c

Index: clang/test/Sema/warn-fortify-source.c
===
--- clang/test/Sema/warn-fortify-source.c
+++ clang/test/Sema/warn-fortify-source.c
@@ -58,6 +58,12 @@
   __builtin_stpncpy(s1, s2, 20); // expected-warning {{'stpncpy' size argument is too large; destination buffer has size 10, but size argument is 20}}
 }
 
+void call_strcpy() {
+  const char *const src = "abcdef";
+  char dst[4];
+  __builtin_strcpy(dst, src); // expected-warning {{'strcpy' will always overflow; destination buffer has size 4, but the source string has length 7 (including null byte)}}
+}
+
 void call_memmove() {
   char s1[10], s2[20];
   __builtin_memmove(s2, s1, 20);
Index: clang/test/Analysis/security-syntax-checks.m
===
--- clang/test/Analysis/security-syntax-checks.m
+++ clang/test/Analysis/security-syntax-checks.m
@@ -1,37 +1,37 @@
-// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify \
+// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify -Wno-fortify-source \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify \
+// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify -Wno-fortify-source \
 // RUN:   -DUSE_BUILTINS \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify \
+// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify -Wno-fortify-source \
 // RUN:   -DVARIANT \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify \
+// RUN: %clang_analyze_cc1 -triple i386-apple-darwin10 %s -verify -Wno-fortify-source \
 // RUN:   -DUSE_BUILTINS -DVARIANT \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify \
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify -Wno-fortify-source \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify \
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify -Wno-fortify-source \
 // RUN:   -DUSE_BUILTINS \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify \
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify -Wno-fortify-source \
 // RUN:   -DVARIANT \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
 
-// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify \
+// RUN: %clang_analyze_cc1 -triple x86_64-unknown-cloudabi %s -verify -Wno-fortify-source \
 // RUN:   -DUSE_BUILTINS -DVARIANT \
 // RUN:   -analyzer-checker=security.insecureAPI \
 // RUN:   -analyzer-checker=security.FloatLoopCounter
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -588,14 +588,8 @@
 
 } // namespace
 
-/// Check a call to BuiltinID for buffer overflows. If BuiltinID is a
-/// __builtin_*_chk function, then use the object size argument specified in the
-/// source. Otherwise, infer the object size using __builtin_object_size.
 void Sema::checkFortifiedBuiltinMemoryFunction(FunctionDecl *FD,
CallExpr *TheCall) {
-  // FIXME: There are some more useful checks we could be doing here:
-  //  - Evaluate strlen of strcpy arguments, use as object size.
-
   if (TheCall->isValueDependent() || TheCall->isTypeDependent() ||
   isConstantEvaluated())
 return;
@@ -607,13 +601,65 @@
   const TargetInfo  = getASTContext().getTargetInfo();
   unsigned SizeTypeWidth = TI.getTypeWidth(TI.getSizeType());
 
+  auto ComputeCheckVariantSize = [&](unsigned Index) -> Optional {
+Expr::EvalResult Result;
+Expr *SizeArg = TheCall->getArg(Index);
+if 

[PATCH] D104883: [CodeGen] Add ParmVarDecls to FunctionDecls that are created to generate ObjC property getter/setter functions

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

Ah - this is an alternative to D104082 ? OK. 
Yeah, looks like it'd address the thing we were discussing in D98799 
. But do you have some more details on why 
D104082  wasn't the right direction? I 
thought we found other places that used a default-constructed/null 
`GlobalDecl()` for StartFunction` correctly, so I'm wondering why this would be 
a problem in this particular case(s)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104883

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

[clang] d6a91f6 - Revert "[Clang] XFAIL sanitize-coverage-old-pm.c on 32bit Armv8l"

[Muhammad Omair Javaid via cfe-commits]

Author: Muhammad Omair Javaid
Date: 2021-06-25T05:00:14+05:00
New Revision: d6a91f6c565179e9b2dac700f9a54e105f748a6d

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

LOG: Revert "[Clang] XFAIL sanitize-coverage-old-pm.c on 32bit Armv8l"

This reverts commit c5028f3473ed50a7433fe278984cd1a755b338b9.

Added: 


Modified: 
clang/test/CodeGen/sanitize-coverage-old-pm.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-coverage-old-pm.c 
b/clang/test/CodeGen/sanitize-coverage-old-pm.c
index fc764954cce8..610dd651587f 100644
--- a/clang/test/CodeGen/sanitize-coverage-old-pm.c
+++ b/clang/test/CodeGen/sanitize-coverage-old-pm.c
@@ -6,7 +6,7 @@
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=undefined  -fsanitize-coverage=trace-pc,trace-cmp -o - 
-flegacy-pass-manager | FileCheck %s --check-prefixes=CHECK,UBSAN
 //
 // Host armv7 is currently unsupported: 
https://bugs.llvm.org/show_bug.cgi?id=46117
-// XFAIL: armv7, thumbv7, armv8l
+// XFAIL: armv7, thumbv7
 // The same issue also occurs on a riscv32 host.
 // XFAIL: riscv32
 



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

[PATCH] D104883: [CodeGen] Add ParmVarDecls to FunctionDecls that are created to generate ObjC property getter/setter functions

[Adrian Prantl via Phabricator via cfe-commits]

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

If ` args.push_back(Params[1] = SrcDecl);` doesn't trigger a warning, this 
seems reasonable.




Comment at: clang/lib/CodeGen/CGObjC.cpp:3702
+  /*DefArg=*/nullptr);
+  args.push_back(Params[0] = DstDecl);
+  ParmVarDecl *SrcDecl = ParmVarDecl::Create(

Does this compile without warnings?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104883

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

[clang] ef90657 - [PowerPC] Fix vec_add for 64-bit on pre-Power7 subtargets

[Nemanja Ivanovic via cfe-commits]

Author: Nemanja Ivanovic
Date: 2021-06-24T18:42:44-05:00
New Revision: ef906573a127cffef7cae75d5155c15a8a2a3a5e

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

LOG: [PowerPC] Fix vec_add for 64-bit on pre-Power7 subtargets

The shift of the carry was actually incorrect.

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-vsx.c

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index dadf6b5cf75bb..3517da798547a 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -312,16 +312,20 @@ vec_add_u128(vector unsigned char __a, vector unsigned 
char __b) {
 #elif defined(__VSX__)
 static __inline__ vector signed long long __ATTRS_o_ai
 vec_add(vector signed long long __a, vector signed long long __b) {
+#ifdef __LITTLE_ENDIAN__
+  // Little endian systems on CPU's prior to Power8 don't really exist
+  // so scalarizing is fine.
+  return __a + __b;
+#else
   vector unsigned int __res =
   (vector unsigned int)__a + (vector unsigned int)__b;
   vector unsigned int __carry = __builtin_altivec_vaddcuw(
   (vector unsigned int)__a, (vector unsigned int)__b);
-#ifdef __LITTLE_ENDIAN__
-  __carry = __builtin_shufflevector(__carry, __carry, 3, 0, 1, 2);
-#else
-  __carry = __builtin_shufflevector(__carry, __carry, 1, 2, 3, 0);
-#endif
+  __carry = __builtin_shufflevector((vector unsigned char)__carry,
+(vector unsigned char)__carry, 0, 0, 0, 7,
+0, 0, 0, 0, 0, 0, 0, 15, 0, 0, 0, 0);
   return (vector signed long long)(__res + __carry);
+#endif
 }
 
 static __inline__ vector unsigned long long __ATTRS_o_ai

diff  --git a/clang/test/CodeGen/builtins-ppc-vsx.c 
b/clang/test/CodeGen/builtins-ppc-vsx.c
index abd08d463e634..b5ddd03722ad0 100644
--- a/clang/test/CodeGen/builtins-ppc-vsx.c
+++ b/clang/test/CodeGen/builtins-ppc-vsx.c
@@ -2319,21 +2319,15 @@ void test_p8overloads_backwards_compat() {
   res_vsll = vec_add(vsll, vsll);
   // CHECK: add <4 x i32>
   // CHECK: call <4 x i32> @llvm.ppc.altivec.vaddcuw
-  // CHECK: shufflevector <4 x i32> {{%.*}}, <4 x i32> {{%.*}}, <4 x i32> 
+  // CHECK: shufflevector <16 x i8> {{%.*}}, <16 x i8> {{%.*}}, <16 x i32> 

   // CHECK: add <4 x i32>
-  // CHECK-LE: add <4 x i32>
-  // CHECK-LE: call <4 x i32> @llvm.ppc.altivec.vaddcuw
-  // CHECK-LE: shufflevector <4 x i32> {{%.*}}, <4 x i32> {{%.*}}, <4 x i32> 

-  // CHECK-LE: add <4 x i32>
+  // CHECK-LE: add <2 x i64>
   res_vull = vec_add(vull, vull);
   // CHECK: add <4 x i32>
   // CHECK: call <4 x i32> @llvm.ppc.altivec.vaddcuw
-  // CHECK: shufflevector <4 x i32> {{%.*}}, <4 x i32> {{%.*}}, <4 x i32> 
+  // CHECK: shufflevector <16 x i8> {{%.*}}, <16 x i8> {{%.*}}, <16 x i32> 

   // CHECK: add <4 x i32>
-  // CHECK-LE: add <4 x i32>
-  // CHECK-LE: call <4 x i32> @llvm.ppc.altivec.vaddcuw
-  // CHECK-LE: shufflevector <4 x i32> {{%.*}}, <4 x i32> {{%.*}}, <4 x i32> 

-  // CHECK-LE: add <4 x i32>
+  // CHECK-LE: add <2 x i64>
   dummy();
   // CHECK: call void @dummy()
   // CHECK-LE: call void @dummy()



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

[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov added a comment.

In D104680#2839309 , @rsmith wrote:

> I would prefer to split this into two changes:
> ...
> Does that sound reasonable?

Yeah that is fine, totally understand ;)




Comment at: clang/lib/Sema/SemaExpr.cpp:11815
+if (IsError)
+  return Opc != BO_Cmp ? Context.getLogicalOperationType() : QualType();
+  }

rsmith wrote:
> mizvekov wrote:
> > Quuxplusone wrote:
> > > Peanut gallery says: Is `QualType()` the right "placeholder" to return 
> > > here? IIUC, this is the situation where we've diagnosed an ill-formed 
> > > expression and are just trying to do error-recovery: if the expression 
> > > looks like `x < y` then we assume the programmer wants it to return 
> > > `bool`, and if the expression looks like `x <=> y` then we assume the 
> > > programmer wants it to return... `QualType()`? Is that the same thing 
> > > we'd do for e.g. `x + y` or `undeclaredfunction(x)`? (If so, good, I 
> > > think.)
> > So right now, this is the same we are doing for three-way comparison 
> > between builtin types we do not support / recognize. Check just below in 
> > this same function. Just look for the call to 
> > `getComparisonCategoryForBuiltinCmp`.
> > 
> > I agree completely with you and I was going to raise the same point, but I 
> > would prefer we changed both places at once instead of fixing it just here, 
> > so I think this should be a follow up task: Find something more appropriate 
> > to return here.
> A null `QualType` is in this case treated as an indication that the 
> comparison is invalid, recovery failed, and the callee has already produced a 
> diagnostic. (It's a bit sad that we don't generally use a separate 
> `TypeResult` for this kind of thing in order to distinguish between the "no 
> type" answer and the "invalid and I've produced a diagnostic" answer, but if 
> we wanted to change that I think we should aim to do it holistically across 
> all of Clang.)
Hmm. My thinking here is that it would be totally appropriate to error recovery 
with a 'strong_ordering' type, since that can decay into all the other 
orderings, making it kind of a safe bet that it would not cause further 
problems.

The idea of a separate type for error recovery is intriguing. But I wonder if 
it would be appropriate in some cases, but not all of them.
* The cases where all the options are equally bad and we have no good guesses 
would fit the bill, but this is not the case here.
* When we have a good safe bet, we can in principle just use that type. But 
maybe it would make sense to add a bit to it that means something like "but 
don't take this too seriously", which could be used to selectively suppress 
some diagnostics downstream.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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

[PATCH] D104883: [CodeGen] Add ParmVarDecls to FunctionDecls that are created to generate ObjC property getter/setter functions

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

clang crashes if I remove the fake FunctionDecls as I did in 
https://reviews.llvm.org/D104082.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104883

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

[PATCH] D104883: [CodeGen] Add ParmVarDecls to FunctionDecls that are created to generate ObjC property getter/setter functions

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak created this revision.
ahatanak added reviewers: rjmccall, aprantl, vsk, dblaikie.
ahatanak added a project: clang.
Herald added a subscriber: kristof.beyls.
ahatanak requested review of this revision.

This is needed to prevent clang from crashing when we make the changes proposed 
in https://reviews.llvm.org/D98799.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104883

Files:
  clang/lib/CodeGen/CGObjC.cpp


Index: clang/lib/CodeGen/CGObjC.cpp
===
--- clang/lib/CodeGen/CGObjC.cpp
+++ clang/lib/CodeGen/CGObjC.cpp
@@ -3694,12 +3694,18 @@
   FunctionTy, nullptr, SC_Static, false, false);
 
   FunctionArgList args;
-  ImplicitParamDecl DstDecl(C, FD, SourceLocation(), /*Id=*/nullptr, DestTy,
-ImplicitParamDecl::Other);
-  args.push_back();
-  ImplicitParamDecl SrcDecl(C, FD, SourceLocation(), /*Id=*/nullptr, SrcTy,
-ImplicitParamDecl::Other);
-  args.push_back();
+  ParmVarDecl *Params[2];
+  ParmVarDecl *DstDecl = ParmVarDecl::Create(
+  C, FD, SourceLocation(), SourceLocation(), nullptr, DestTy,
+  C.getTrivialTypeSourceInfo(DestTy, SourceLocation()), SC_None,
+  /*DefArg=*/nullptr);
+  args.push_back(Params[0] = DstDecl);
+  ParmVarDecl *SrcDecl = ParmVarDecl::Create(
+  C, FD, SourceLocation(), SourceLocation(), nullptr, SrcTy,
+  C.getTrivialTypeSourceInfo(SrcTy, SourceLocation()), SC_None,
+  /*DefArg=*/nullptr);
+  args.push_back(Params[1] = SrcDecl);
+  FD->setParams(Params);
 
   const CGFunctionInfo  =
   CGM.getTypes().arrangeBuiltinFunctionDeclaration(ReturnTy, args);
@@ -3715,12 +3721,12 @@
 
   StartFunction(FD, ReturnTy, Fn, FI, args);
 
-  DeclRefExpr DstExpr(C, , false, DestTy, VK_PRValue, 
SourceLocation());
+  DeclRefExpr DstExpr(C, DstDecl, false, DestTy, VK_PRValue, SourceLocation());
   UnaryOperator *DST = UnaryOperator::Create(
   C, , UO_Deref, DestTy->getPointeeType(), VK_LValue, OK_Ordinary,
   SourceLocation(), false, FPOptionsOverride());
 
-  DeclRefExpr SrcExpr(C, , false, SrcTy, VK_PRValue, SourceLocation());
+  DeclRefExpr SrcExpr(C, SrcDecl, false, SrcTy, VK_PRValue, SourceLocation());
   UnaryOperator *SRC = UnaryOperator::Create(
   C, , UO_Deref, SrcTy->getPointeeType(), VK_LValue, OK_Ordinary,
   SourceLocation(), false, FPOptionsOverride());
@@ -3778,12 +3784,18 @@
   FunctionTy, nullptr, SC_Static, false, false);
 
   FunctionArgList args;
-  ImplicitParamDecl DstDecl(C, FD, SourceLocation(), /*Id=*/nullptr, DestTy,
-ImplicitParamDecl::Other);
-  args.push_back();
-  ImplicitParamDecl SrcDecl(C, FD, SourceLocation(), /*Id=*/nullptr, SrcTy,
-ImplicitParamDecl::Other);
-  args.push_back();
+  ParmVarDecl *Params[2];
+  ParmVarDecl *DstDecl = ParmVarDecl::Create(
+  C, FD, SourceLocation(), SourceLocation(), nullptr, DestTy,
+  C.getTrivialTypeSourceInfo(DestTy, SourceLocation()), SC_None,
+  /*DefArg=*/nullptr);
+  args.push_back(Params[0] = DstDecl);
+  ParmVarDecl *SrcDecl = ParmVarDecl::Create(
+  C, FD, SourceLocation(), SourceLocation(), nullptr, SrcTy,
+  C.getTrivialTypeSourceInfo(SrcTy, SourceLocation()), SC_None,
+  /*DefArg=*/nullptr);
+  args.push_back(Params[1] = SrcDecl);
+  FD->setParams(Params);
 
   const CGFunctionInfo  =
   CGM.getTypes().arrangeBuiltinFunctionDeclaration(ReturnTy, args);
@@ -3798,7 +3810,7 @@
 
   StartFunction(FD, ReturnTy, Fn, FI, args);
 
-  DeclRefExpr SrcExpr(getContext(), , false, SrcTy, VK_PRValue,
+  DeclRefExpr SrcExpr(getContext(), SrcDecl, false, SrcTy, VK_PRValue,
   SourceLocation());
 
   UnaryOperator *SRC = UnaryOperator::Create(
@@ -3825,7 +3837,7 @@
  CXXConstExpr->getConstructionKind(),
  SourceRange());
 
-  DeclRefExpr DstExpr(getContext(), , false, DestTy, VK_PRValue,
+  DeclRefExpr DstExpr(getContext(), DstDecl, false, DestTy, VK_PRValue,
   SourceLocation());
 
   RValue DV = EmitAnyExpr();


Index: clang/lib/CodeGen/CGObjC.cpp
===
--- clang/lib/CodeGen/CGObjC.cpp
+++ clang/lib/CodeGen/CGObjC.cpp
@@ -3694,12 +3694,18 @@
   FunctionTy, nullptr, SC_Static, false, false);
 
   FunctionArgList args;
-  ImplicitParamDecl DstDecl(C, FD, SourceLocation(), /*Id=*/nullptr, DestTy,
-ImplicitParamDecl::Other);
-  args.push_back();
-  ImplicitParamDecl SrcDecl(C, FD, SourceLocation(), /*Id=*/nullptr, SrcTy,
-ImplicitParamDecl::Other);
-  args.push_back();
+  ParmVarDecl *Params[2];
+  ParmVarDecl *DstDecl = ParmVarDecl::Create(
+  C, FD, SourceLocation(), SourceLocation(), nullptr, DestTy,
+  C.getTrivialTypeSourceInfo(DestTy, SourceLocation()), SC_None,
+  /*DefArg=*/nullptr);
+  args.push_back(Params[0] = 

[PATCH] D104550: [analyzer] Implement getType for SVal

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

> I'm not sure what you mean here. If it is about this particular patch, it 
> simply adds a non-virtual method to SVal, it shouldn't affect sizeof(SVal) at 
> all.

My fault. For some reason I thought you added a QualType as a member to SVal 
declaration.

> I wanted to be more explicit here and convey to the user that the lack of 
> type is normal.

We need to think about what real usage would look and feel better.

My another proposition is to think about how we can rework `ConcreteInt` to 
`Int` which can keep ranges. Previosly we couldn't keep range sets inside Sval 
as they were ImmutableSets, but now they are just pointers to vectors. So we 
can pass the range set inside SVal. IMO now RangeConstraintManager is smart 
enough to do standart arithmetics with ranges as we do for concrete ints. These 
are just my recent thoughts out loud.




Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

vsavchenko wrote:
> ASDenysPetrov wrote:
> > I'm not sure this is a correct type. I would expect here something like: 
> > `class LabelType : public Type`.
> I don't think that I fully understood what you suggest here.  Do you suggest 
> to add a new type to `Type.h`?
Yes. As a user I expect to see some special type for labels, not a `void*`. But 
for the absence of such type let it be as is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 354368.
jhuber6 added a comment.

Removing runtime check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/ordered_codegen.cpp
  clang/test/OpenMP/parallel_for_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/sections_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_dist_schedule_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_dist_schedule_codegen.cpp

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

[clang] f1e2d58 - [OptTable] Rename PrintHelp to printHelp

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2021-06-24T14:47:03-07:00
New Revision: f1e2d5851bf869685971d5acb894b39a89ea2d49

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

LOG: [OptTable] Rename PrintHelp to printHelp

To be consistent with other member functions and match the coding standard.

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
clang/tools/driver/cc1as_main.cpp
flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
lld/COFF/DriverUtils.cpp
lld/ELF/DriverUtils.cpp
lld/MachO/DriverUtils.cpp
lld/MinGW/Driver.cpp
lld/lib/Driver/DarwinLdDriver.cpp
lld/wasm/Driver.cpp
lldb/tools/driver/Driver.cpp
lldb/tools/lldb-server/lldb-gdbserver.cpp
lldb/tools/lldb-vscode/lldb-vscode.cpp
llvm/include/llvm/Option/OptTable.h
llvm/lib/Option/OptTable.cpp
llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp
llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp
llvm/tools/dsymutil/dsymutil.cpp
llvm/tools/llvm-cvtres/llvm-cvtres.cpp
llvm/tools/llvm-lipo/llvm-lipo.cpp
llvm/tools/llvm-ml/llvm-ml.cpp
llvm/tools/llvm-mt/llvm-mt.cpp
llvm/tools/llvm-objcopy/ConfigManager.cpp
llvm/tools/llvm-objdump/llvm-objdump.cpp
llvm/tools/llvm-rc/llvm-rc.cpp
llvm/tools/llvm-symbolizer/llvm-symbolizer.cpp
llvm/unittests/Option/OptionParsingTest.cpp

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 1afaaba79105b..6ea6e2e47e639 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -1635,7 +1635,7 @@ void Driver::PrintHelp(bool ShowHidden) const {
 ExcludedFlagsBitmask |= options::FlangOnlyOption;
 
   std::string Usage = llvm::formatv("{0} [options] file...", Name).str();
-  getOpts().PrintHelp(llvm::outs(), Usage.c_str(), DriverTitle.c_str(),
+  getOpts().printHelp(llvm::outs(), Usage.c_str(), DriverTitle.c_str(),
   IncludedFlagsBitmask, ExcludedFlagsBitmask,
   /*ShowAllAliases=*/false);
 }

diff  --git a/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp 
b/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
index ac64e1708da6c..b95851e380d28 100644
--- a/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ b/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -187,7 +187,7 @@ CreateFrontendAction(CompilerInstance ) {
 bool ExecuteCompilerInvocation(CompilerInstance *Clang) {
   // Honor -help.
   if (Clang->getFrontendOpts().ShowHelp) {
-driver::getDriverOptTable().PrintHelp(
+driver::getDriverOptTable().printHelp(
 llvm::outs(), "clang -cc1 [options] file...",
 "LLVM 'Clang' Compiler: http://clang.llvm.org;,
 /*Include=*/driver::options::CC1Option,

diff  --git a/clang/tools/driver/cc1as_main.cpp 
b/clang/tools/driver/cc1as_main.cpp
index 9f6a58b634b4b..086ce0ea77875 100644
--- a/clang/tools/driver/cc1as_main.cpp
+++ b/clang/tools/driver/cc1as_main.cpp
@@ -585,7 +585,7 @@ int cc1as_main(ArrayRef Argv, const char 
*Argv0, void *MainAddr) {
 return 1;
 
   if (Asm.ShowHelp) {
-getDriverOptTable().PrintHelp(
+getDriverOptTable().printHelp(
 llvm::outs(), "clang -cc1as [options] file...",
 "Clang Integrated Assembler",
 /*Include=*/driver::options::CC1AsOption, /*Exclude=*/0,

diff  --git a/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp 
b/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
index e53f652d3b2c4..243e25163dc05 100644
--- a/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ b/flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -103,7 +103,7 @@ std::unique_ptr 
CreateFrontendAction(CompilerInstance ) {
 bool ExecuteCompilerInvocation(CompilerInstance *flang) {
   // Honor -help.
   if (flang->frontendOpts().showHelp_) {
-clang::driver::getDriverOptTable().PrintHelp(llvm::outs(),
+clang::driver::getDriverOptTable().printHelp(llvm::outs(),
 "flang-new -fc1 [options] file...", "LLVM 'Flang' Compiler",
 /*Include=*/clang::driver::options::FC1Option,
 /*Exclude=*/llvm::opt::DriverFlag::HelpHidden,

diff  --git a/lld/COFF/DriverUtils.cpp b/lld/COFF/DriverUtils.cpp
index d6261209a9c1c..b5abe8b1196d9 100644
--- a/lld/COFF/DriverUtils.cpp
+++ b/lld/COFF/DriverUtils.cpp
@@ -933,7 +933,7 @@ std::vector ArgParser::tokenize(StringRef s) {
 }
 
 void printHelp(const char *argv0) {
-  optTable.PrintHelp(lld::outs(),
+  optTable.printHelp(lld::outs(),
  (std::string(argv0) + " [options] file...").c_str(),
  "LLVM Linker", false);
 }

diff  --git a/lld/ELF/DriverUtils.cpp b/lld/ELF/DriverUtils.cpp
index a3fc522c708c2..f49deb9012b28 100644
--- a/lld/ELF/DriverUtils.cpp
+++ b/lld/ELF/DriverUtils.cpp
@@ -145,7 

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:709
+getModule().addModuleFlag(llvm::Module::Max, "openmp-device",
+  LangOpts.OpenMP);
+

jdoerfert wrote:
> Why do we need `OpenMPRuntime` in the conditional?
Probably don't explicitly need it, I'll remove it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

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

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:709
+getModule().addModuleFlag(llvm::Module::Max, "openmp-device",
+  LangOpts.OpenMP);
+

Why do we need `OpenMPRuntime` in the conditional?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

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

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Johannes Doerfert via Phabricator via cfe-commits]

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

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

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

[PATCH] D104837: [PowerPC] Add XL compat __compare_and_swap builtins

[Jinsong Ji via Phabricator via cfe-commits]

jsji updated this revision to Diff 354360.
jsji added a comment.

Add {} to case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104837

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -0,0 +1,52 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:-emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swap(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[B:%.*]] = alloca i32, align 4
+// CHECK-NEXT:[[C:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store volatile i32 0, i32* [[A]], align 4
+// CHECK-NEXT:store i32 0, i32* [[B]], align 4
+// CHECK-NEXT:store i32 0, i32* [[C]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[C]], align 4
+// CHECK-NEXT:[[TMP1:%.*]] = load i32, i32* [[B]], align 4
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A]], i32 [[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swap(, , c);
+
+}
+
+// CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[A:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[B:%.*]] = alloca i64, align 8
+// CHECK-NEXT:[[C:%.*]] = alloca i64, align 8
+// CHECK-NEXT:store volatile i64 0, i64* [[A]], align 8
+// CHECK-NEXT:store i64 0, i64* [[B]], align 8
+// CHECK-NEXT:store i64 0, i64* [[C]], align 8
+// CHECK-NEXT:[[TMP0:%.*]] = load i64, i64* [[C]], align 8
+// CHECK-NEXT:[[TMP1:%.*]] = load i64, i64* [[B]], align 8
+// CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i64* [[A]], i64 [[TMP1]], i64 [[TMP0]] monotonic monotonic, align 8
+// CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i64, i1 } [[TMP2]], 0
+// CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i64, i1 } [[TMP2]], 1
+// CHECK-NEXT:ret void
+//
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);
+
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas-error.c
@@ -0,0 +1,19 @@
+// REQUIRES: powerpc-registered-target
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -target-cpu pwr8 \
+// RUN:   -verify %s
+
+void test_builtin_ppc_compare_and_swap() {
+  volatile int a = 0;
+  long b = 0, c = 0;
+
+  __compare_and_swap(, , c); // expected-warning {{incompatible pointer types passing 'long *' to parameter of type 'int *'}}
+
+}
+
+void test_builtin_ppc_compare_and_swaplp() {
+  volatile long a = 0;
+  int b = 0, c = 0;
+
+  __compare_and_swaplp(, , c);// expected-warning {{incompatible pointer types passing 'int *' to parameter of type 'long *'}}
+
+}
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -15427,6 +15427,19 @@
 Value *Call = Builder.CreateCall(F, CallOps);
 return Builder.CreateAlignedStore(Call, Ops[0], MaybeAlign(64));
   }
+
+  case PPC::BI__builtin_ppc_compare_and_swap:
+  case PPC::BI__builtin_ppc_compare_and_swaplp: {
+Address Addr = EmitPointerWithAlignment(E->getArg(0));
+Address OldValAddr = EmitPointerWithAlignment(E->getArg(1));
+Value *OldVal = Builder.CreateLoad(OldValAddr);
+QualType AtomicTy = E->getArg(0)->getType()->getPointeeType();
+LValue LV = MakeAddrLValue(Addr, AtomicTy);
+auto Pair = EmitAtomicCompareExchange(
+LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
+llvm::AtomicOrdering::Monotonic, llvm::AtomicOrdering::Monotonic, true);
+return Pair.second;
+  }
   }
 }
 
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -97,6 +97,9 @@
   Builder.defineMacro("__dcbtst", "__builtin_ppc_dcbtst");
   Builder.defineMacro("__dcbz", "__builtin_ppc_dcbz");
   

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Martin Storsjö 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 rG3eed57e7ef7d: [ADT] Rename StringRef case insensitive 
methods for clarity (authored by mstorsjo).

Changed prior to commit:
  https://reviews.llvm.org/D104819?vs=354178=354355#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

Files:
  llvm/include/llvm/ADT/StringRef.h
  llvm/lib/Support/StringRef.cpp
  llvm/unittests/ADT/StringRefTest.cpp

Index: llvm/unittests/ADT/StringRefTest.cpp
===
--- llvm/unittests/ADT/StringRefTest.cpp
+++ llvm/unittests/ADT/StringRefTest.cpp
@@ -98,15 +98,15 @@
   EXPECT_EQ( 1, StringRef("aab").compare("aa"));
   EXPECT_EQ( 1, StringRef("\xFF").compare("\1"));
 
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("aAd"));
-  EXPECT_EQ( 0, StringRef("AaB").compare_lower("aab"));
-  EXPECT_EQ( 1, StringRef("AaB").compare_lower("AAA"));
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("aaBb"));
-  EXPECT_EQ(-1, StringRef("AaB").compare_lower("bb"));
-  EXPECT_EQ( 1, StringRef("aaBb").compare_lower("AaB"));
-  EXPECT_EQ( 1, StringRef("bb").compare_lower("AaB"));
-  EXPECT_EQ( 1, StringRef("AaB").compare_lower("aA"));
-  EXPECT_EQ( 1, StringRef("\xFF").compare_lower("\1"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("aAd"));
+  EXPECT_EQ( 0, StringRef("AaB").compare_insensitive("aab"));
+  EXPECT_EQ( 1, StringRef("AaB").compare_insensitive("AAA"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("aaBb"));
+  EXPECT_EQ(-1, StringRef("AaB").compare_insensitive("bb"));
+  EXPECT_EQ( 1, StringRef("aaBb").compare_insensitive("AaB"));
+  EXPECT_EQ( 1, StringRef("bb").compare_insensitive("AaB"));
+  EXPECT_EQ( 1, StringRef("AaB").compare_insensitive("aA"));
+  EXPECT_EQ( 1, StringRef("\xFF").compare_insensitive("\1"));
 
   EXPECT_EQ(-1, StringRef("aab").compare_numeric("aad"));
   EXPECT_EQ( 0, StringRef("aab").compare_numeric("aab"));
@@ -366,14 +366,14 @@
   EXPECT_FALSE(Str.startswith("hi"));
 }
 
-TEST(StringRefTest, StartsWithLower) {
+TEST(StringRefTest, StartsWithInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.startswith_lower(""));
-  EXPECT_TRUE(Str.startswith_lower("he"));
-  EXPECT_TRUE(Str.startswith_lower("hell"));
-  EXPECT_TRUE(Str.startswith_lower("HELlo"));
-  EXPECT_FALSE(Str.startswith_lower("helloworld"));
-  EXPECT_FALSE(Str.startswith_lower("hi"));
+  EXPECT_TRUE(Str.startswith_insensitive(""));
+  EXPECT_TRUE(Str.startswith_insensitive("he"));
+  EXPECT_TRUE(Str.startswith_insensitive("hell"));
+  EXPECT_TRUE(Str.startswith_insensitive("HELlo"));
+  EXPECT_FALSE(Str.startswith_insensitive("helloworld"));
+  EXPECT_FALSE(Str.startswith_insensitive("hi"));
 }
 
 TEST(StringRefTest, ConsumeFront) {
@@ -392,22 +392,22 @@
   EXPECT_TRUE(Str.consume_front(""));
 }
 
-TEST(StringRefTest, ConsumeFrontLower) {
+TEST(StringRefTest, ConsumeFrontInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.consume_front_lower(""));
+  EXPECT_TRUE(Str.consume_front_insensitive(""));
   EXPECT_EQ("heLLo", Str);
   EXPECT_FALSE(Str.consume_front("HEl"));
   EXPECT_EQ("heLLo", Str);
-  EXPECT_TRUE(Str.consume_front_lower("HEl"));
+  EXPECT_TRUE(Str.consume_front_insensitive("HEl"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_FALSE(Str.consume_front_lower("loworld"));
+  EXPECT_FALSE(Str.consume_front_insensitive("loworld"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_FALSE(Str.consume_front_lower("ol"));
+  EXPECT_FALSE(Str.consume_front_insensitive("ol"));
   EXPECT_EQ("Lo", Str);
-  EXPECT_TRUE(Str.consume_front_lower("lo"));
+  EXPECT_TRUE(Str.consume_front_insensitive("lo"));
   EXPECT_EQ("", Str);
-  EXPECT_FALSE(Str.consume_front_lower("o"));
-  EXPECT_TRUE(Str.consume_front_lower(""));
+  EXPECT_FALSE(Str.consume_front_insensitive("o"));
+  EXPECT_TRUE(Str.consume_front_insensitive(""));
 }
 
 TEST(StringRefTest, EndsWith) {
@@ -419,14 +419,14 @@
   EXPECT_FALSE(Str.endswith("so"));
 }
 
-TEST(StringRefTest, EndsWithLower) {
+TEST(StringRefTest, EndsWithInsensitive) {
   StringRef Str("heLLo");
-  EXPECT_TRUE(Str.endswith_lower(""));
-  EXPECT_TRUE(Str.endswith_lower("lo"));
-  EXPECT_TRUE(Str.endswith_lower("LO"));
-  EXPECT_TRUE(Str.endswith_lower("ELlo"));
-  EXPECT_FALSE(Str.endswith_lower("helloworld"));
-  EXPECT_FALSE(Str.endswith_lower("hi"));
+  EXPECT_TRUE(Str.endswith_insensitive(""));
+  EXPECT_TRUE(Str.endswith_insensitive("lo"));
+  EXPECT_TRUE(Str.endswith_insensitive("LO"));
+  EXPECT_TRUE(Str.endswith_insensitive("ELlo"));
+  EXPECT_FALSE(Str.endswith_insensitive("helloworld"));
+  EXPECT_FALSE(Str.endswith_insensitive("hi"));
 }
 
 TEST(StringRefTest, ConsumeBack) {
@@ -445,22 +445,22 @@
   EXPECT_TRUE(Str.consume_back(""));
 }
 
-TEST(StringRefTest, ConsumeBackLower) {
+TEST(StringRefTest, ConsumeBackInsensitive) {
   StringRef Str("heLLo");
-  

[clang-tools-extra] 86029e4 - [clang-tools-extra] Rename StringRef _lower() method calls to _insensitive()

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2021-06-25T00:22:01+03:00
New Revision: 86029e4c220b91be728f6ff6a17cad098821e657

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

LOG: [clang-tools-extra] Rename StringRef _lower() method calls to 
_insensitive()

Added: 


Modified: 
clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp
clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp

clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp
clang-tools-extra/clang-tidy/misc/StaticAssertCheck.cpp

clang-tools-extra/clang-tidy/readability/InconsistentDeclarationParameterNameCheck.cpp
clang-tools-extra/clang-tidy/readability/UppercaseLiteralSuffixCheck.cpp
clang-tools-extra/clangd/CodeComplete.cpp
clang-tools-extra/clangd/CompileCommands.cpp
clang-tools-extra/clangd/ConfigYAML.cpp
clang-tools-extra/clangd/HeaderSourceSwitch.cpp
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/Quality.cpp
clang-tools-extra/clangd/index/SymbolCollector.cpp
clang-tools-extra/clangd/support/Path.cpp
clang-tools-extra/modularize/ModularizeUtilities.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/ClangTidyCheck.cpp 
b/clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
index 6f7f6611c8d20..f447ee41f6f8f 100644
--- a/clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidyCheck.cpp
@@ -150,11 +150,11 @@ llvm::Optional 
ClangTidyCheck::OptionsView::getEnumInt(
   unsigned EditDistance = 3;
   for (const auto  : Mapping) {
 if (IgnoreCase) {
-  if (Value.equals_lower(NameAndEnum.second))
+  if (Value.equals_insensitive(NameAndEnum.second))
 return NameAndEnum.first;
 } else if (Value.equals(NameAndEnum.second)) {
   return NameAndEnum.first;
-} else if (Value.equals_lower(NameAndEnum.second)) {
+} else if (Value.equals_insensitive(NameAndEnum.second)) {
   Closest = NameAndEnum.second;
   EditDistance = 0;
   continue;

diff  --git 
a/clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp
index f7c71cca71594..769494207aef2 100644
--- a/clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp
+++ b/clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp
@@ -70,9 +70,9 @@ void KernelNameRestrictionPPCallbacks::InclusionDirective(
 
 bool KernelNameRestrictionPPCallbacks::fileNameIsRestricted(
 StringRef FileName) {
-  return FileName.equals_lower("kernel.cl") ||
- FileName.equals_lower("verilog.cl") ||
- FileName.equals_lower("vhdl.cl");
+  return FileName.equals_insensitive("kernel.cl") ||
+ FileName.equals_insensitive("verilog.cl") ||
+ FileName.equals_insensitive("vhdl.cl");
 }
 
 void KernelNameRestrictionPPCallbacks::EndOfMainFile() {

diff  --git a/clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
index 32af0ee6266d2..e50ebdba3b343 100644
--- a/clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/ArgumentCommentCheck.cpp
@@ -176,8 +176,8 @@ static bool sameName(StringRef InComment, StringRef InDecl, 
bool StrictMode) {
 return InComment == InDecl;
   InComment = InComment.trim('_');
   InDecl = InDecl.trim('_');
-  // FIXME: compare_lower only works for ASCII.
-  return InComment.compare_lower(InDecl) == 0;
+  // FIXME: compare_insensitive only works for ASCII.
+  return InComment.compare_insensitive(InDecl) == 0;
 }
 
 static bool looksLikeExpectMethod(const CXXMethodDecl *Expect) {

diff  --git 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp
 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp
index 6f056e73ad5d6..9ff94a009d0dd 100644
--- 
a/clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp
+++ 
b/clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp
@@ -159,7 +159,7 @@ void PreferMemberInitializerCheck::check(
 if (S->getBeginLoc().isMacroID()) {
   StringRef MacroName = Lexer::getImmediateMacroName(
   S->getBeginLoc(), *Result.SourceManager, getLangOpts());
-  if (MacroName.contains_lower("assert"))
+  if (MacroName.contains_insensitive("assert"))
 return;
 }
 if (isControlStatement(S))

diff  --git a/clang-tools-extra/clang-tidy/misc/StaticAssertCheck.cpp 
b/clang-tools-extra/clang-tidy/misc/StaticAssertCheck.cpp
index 224936887e033..93df4915e9f74 100644
--- a/clang-tools-extra/clang-tidy/misc/StaticAssertCheck.cpp
+++ 

[clang] e5c7c17 - [clang] Rename StringRef _lower() method calls to _insensitive()

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2021-06-25T00:22:01+03:00
New Revision: e5c7c171e5db6af1e3dca1059df4287b0d147eaf

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

LOG: [clang] Rename StringRef _lower() method calls to _insensitive()

This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.

Added: 


Modified: 
clang/lib/ASTMatchers/Dynamic/Marshallers.cpp
clang/lib/Analysis/CalledOnceCheck.cpp
clang/lib/Analysis/RetainSummaryManager.cpp
clang/lib/Basic/FileManager.cpp
clang/lib/CodeGen/TargetInfo.cpp
clang/lib/Driver/Driver.cpp
clang/lib/Driver/ToolChains/Arch/RISCV.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Hexagon.cpp
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Driver/ToolChains/MinGW.cpp
clang/lib/Format/Format.cpp
clang/lib/Format/SortJavaScriptImports.cpp
clang/lib/Format/UsingDeclarationsSorter.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Lex/HeaderMap.cpp
clang/lib/Lex/PPDirectives.cpp
clang/lib/Lex/PPMacroExpansion.cpp
clang/lib/Sema/CodeCompleteConsumer.cpp
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaCodeComplete.cpp
clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp
clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
clang/lib/StaticAnalyzer/Checkers/GCDAntipatternChecker.cpp
clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
clang/lib/Tooling/InterpolatingCompilationDatabase.cpp
clang/tools/clang-refactor/TestSupport.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp
clang/tools/driver/driver.cpp
clang/tools/libclang/CIndexCodeCompletion.cpp
clang/unittests/Tooling/CompilationDatabaseTest.cpp

Removed: 




diff  --git a/clang/lib/ASTMatchers/Dynamic/Marshallers.cpp 
b/clang/lib/ASTMatchers/Dynamic/Marshallers.cpp
index f6fdbe868e2df..40db70e6f4a51 100644
--- a/clang/lib/ASTMatchers/Dynamic/Marshallers.cpp
+++ b/clang/lib/ASTMatchers/Dynamic/Marshallers.cpp
@@ -20,7 +20,7 @@ getBestGuess(llvm::StringRef Search, 
llvm::ArrayRef Allowed,
 ++MaxEditDistance;
   llvm::StringRef Res;
   for (const llvm::StringRef  : Allowed) {
-if (Item.equals_lower(Search)) {
+if (Item.equals_insensitive(Search)) {
   assert(!Item.equals(Search) && "This should be handled earlier on.");
   MaxEditDistance = 1;
   Res = Item;
@@ -40,7 +40,7 @@ getBestGuess(llvm::StringRef Search, 
llvm::ArrayRef Allowed,
   auto NoPrefix = Item;
   if (!NoPrefix.consume_front(DropPrefix))
 continue;
-  if (NoPrefix.equals_lower(Search)) {
+  if (NoPrefix.equals_insensitive(Search)) {
 if (NoPrefix.equals(Search))
   return Item.str();
 MaxEditDistance = 1;

diff  --git a/clang/lib/Analysis/CalledOnceCheck.cpp 
b/clang/lib/Analysis/CalledOnceCheck.cpp
index db094129a9608..661f7b999f2b9 100644
--- a/clang/lib/Analysis/CalledOnceCheck.cpp
+++ b/clang/lib/Analysis/CalledOnceCheck.cpp
@@ -478,7 +478,7 @@ bool mentionsAnyOfConventionalNames(const Expr *E) {
 return llvm::any_of(
 CONVENTIONAL_CONDITIONS,
 [ConditionName](const llvm::StringLiteral ) {
-  return ConditionName.contains_lower(Conventional);
+  return ConditionName.contains_insensitive(Conventional);
 });
   });
 }

diff  --git a/clang/lib/Analysis/RetainSummaryManager.cpp 
b/clang/lib/Analysis/RetainSummaryManager.cpp
index 58ead1dfe3522..7ed1e40333f43 100644
--- a/clang/lib/Analysis/RetainSummaryManager.cpp
+++ b/clang/lib/Analysis/RetainSummaryManager.cpp
@@ -189,20 +189,22 @@ static bool hasRCAnnotation(const Decl *D, StringRef 
rcAnnotation) {
 }
 
 static bool isRetain(const FunctionDecl *FD, StringRef FName) {
-  return FName.startswith_lower("retain") || FName.endswith_lower("retain");
+  return FName.startswith_insensitive("retain") ||
+ FName.endswith_insensitive("retain");
 }
 
 static bool isRelease(const FunctionDecl *FD, StringRef FName) {
-  return FName.startswith_lower("release") || FName.endswith_lower("release");
+  return FName.startswith_insensitive("release") ||
+ FName.endswith_insensitive("release");
 }
 
 static bool isAutorelease(const FunctionDecl *FD, StringRef FName) {
-  return FName.startswith_lower("autorelease") ||
- FName.endswith_lower("autorelease");
+  return FName.startswith_insensitive("autorelease") ||
+ FName.endswith_insensitive("autorelease");
 }
 
 static bool isMakeCollectable(StringRef FName) {
-  return 

[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

Thank you for the repro. I added calls to 
`ApplyDebugLocation::CreateArtificial` and reapplied the patch in 
https://github.com/llvm/llvm-project/commit/8db0dbbe2c0544c38f33cf64b4cdd5135d524b23.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

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

[PATCH] D104096: [Clang-Format] Add ReferenceAlignment directive

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa08fa8a50819: [Clang-Format] Add ReferenceAlignment 
directive (authored by Seraphime Kirkovski skirkov...@vmware.com, 
committed by HazardyKnusperkeks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104096

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -1789,6 +1789,98 @@
getLLVMStyleWithColumns(62));
 }
 
+TEST_F(FormatTest, SeparatePointerReferenceAlignment) {
+  FormatStyle Style = getLLVMStyle();
+  // Check first the default LLVM style
+  // Style.PointerAlignment = FormatStyle::PAS_Right;
+  // Style.ReferenceAlignment = FormatStyle::RAS_Pointer;
+  verifyFormat("int *f1(int *a, int , int &);", Style);
+  verifyFormat("int (int &, int *a, int );", Style);
+  verifyFormat("int &(int , int &, int *a);", Style);
+  verifyFormat("int *f1(int ) const &;", Style);
+  verifyFormat("int *f1(int ) const & = 0;", Style);
+  verifyFormat("int *a = f1();", Style);
+  verifyFormat("int  = f2();", Style);
+  verifyFormat("int & = f3();", Style);
+
+  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  verifyFormat("Const unsigned int *c;\n"
+   "const unsigned int *d;\n"
+   "Const unsigned int \n"
+   "const unsigned int \n"
+   "const unsigned&\n"
+   "Const unsigned  h;",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  Style.ReferenceAlignment = FormatStyle::RAS_Pointer;
+  verifyFormat("int* f1(int* a, int& b, int&& c);", Style);
+  verifyFormat("int& f2(int&& c, int* a, int& b);", Style);
+  verifyFormat("int&& f3(int& b, int&& c, int* a);", Style);
+  verifyFormat("int* f1(int& a) const& = 0;", Style);
+  verifyFormat("int* a = f1();", Style);
+  verifyFormat("int& b = f2();", Style);
+  verifyFormat("int&& c = f3();", Style);
+
+  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  verifyFormat("Const unsigned int* c;\n"
+   "const unsigned int* d;\n"
+   "Const unsigned int& e;\n"
+   "const unsigned int& f;\n"
+   "const unsigned&&g;\n"
+   "Const unsigned  h;",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Right;
+  Style.ReferenceAlignment = FormatStyle::RAS_Left;
+  verifyFormat("int *f1(int *a, int& b, int&& c);", Style);
+  verifyFormat("int& f2(int&& c, int *a, int& b);", Style);
+  verifyFormat("int&& f3(int& b, int&& c, int *a);", Style);
+  verifyFormat("int *a = f1();", Style);
+  verifyFormat("int& b = f2();", Style);
+  verifyFormat("int&& c = f3();", Style);
+
+  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  verifyFormat("Const unsigned int *c;\n"
+   "const unsigned int *d;\n"
+   "Const unsigned int& e;\n"
+   "const unsigned int& f;\n"
+   "const unsigned  g;\n"
+   "Const unsigned  h;",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Left;
+  Style.ReferenceAlignment = FormatStyle::RAS_Middle;
+  verifyFormat("int* f1(int* a, int & b, int && c);", Style);
+  verifyFormat("int & f2(int && c, int* a, int & b);", Style);
+  verifyFormat("int && f3(int & b, int && c, int* a);", Style);
+  verifyFormat("int* a = f1();", Style);
+  verifyFormat("int & b = f2();", Style);
+  verifyFormat("int && c = f3();", Style);
+
+  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  verifyFormat("Const unsigned int*  c;\n"
+   "const unsigned int*  d;\n"
+   "Const unsigned int & e;\n"
+   "const unsigned int & f;\n"
+   "const unsigned &&g;\n"
+   "Const unsigned   h;",
+   Style);
+
+  Style.PointerAlignment = FormatStyle::PAS_Middle;
+  Style.ReferenceAlignment = FormatStyle::RAS_Right;
+  verifyFormat("int * f1(int * a, int , int &);", Style);
+  verifyFormat("int (int &, int * a, int );", Style);
+  verifyFormat("int &(int , int &, int * a);", Style);
+  verifyFormat("int * a = f1();", Style);
+  verifyFormat("int  = f2();", Style);
+  verifyFormat("int & = f3();", Style);
+
+  // FIXME: we don't handle this yet, so output may be arbitrary until it's
+  // specifically handled
+  // verifyFormat("int Add2(BTree * , char * szToAdd)", Style);
+}
+
 TEST_F(FormatTest, FormatsForLoop) {
   verifyFormat(
   "for (int VeryVeryLongLoopVariable = 0; VeryVeryLongLoopVariable < 10;\n"
@@ -18013,6 

[clang] a08fa8a - [Clang-Format] Add ReferenceAlignment directive

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

Author: Seraphime Kirkovski
Date: 2021-06-24T22:27:45+02:00
New Revision: a08fa8a508199c6463f5ee5d617e2f360f718067

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

LOG: [Clang-Format] Add ReferenceAlignment directive

This introduces ReferenceAlignment style option modeled around
PointerAlignment.
Style implementors can specify Left, Right, Middle or Pointer to
follow whatever the PointerAlignment option specifies.

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/TokenAnnotator.cpp
clang/lib/Format/TokenAnnotator.h
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 21028b1f607ad..fd19cdfc3e600 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -3236,6 +3236,38 @@ the configuration (without a prefix: ``Auto``).
   BasedOnStyle: llvm
   CanonicalDelimiter: 'cc'
 
+**ReferenceAlignment** (``ReferenceAlignmentStyle``)
+  Reference alignment style (overrides ``PointerAlignment`` for
+  references).
+
+  Possible values:
+
+  * ``RAS_Pointer`` (in configuration: ``Pointer``)
+Align reference like ``PointerAlignment``.
+
+  * ``RAS_Left`` (in configuration: ``Left``)
+Align reference to the left.
+
+.. code-block:: c++
+
+  int& a;
+
+  * ``RAS_Right`` (in configuration: ``Right``)
+Align reference to the right.
+
+.. code-block:: c++
+
+  int 
+
+  * ``RAS_Middle`` (in configuration: ``Middle``)
+Align reference in the middle.
+
+.. code-block:: c++
+
+  int & a;
+
+
+
 **ReflowComments** (``bool``)
   If ``true``, clang-format will attempt to re-flow comments.
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 06aeacc9785cc..515ac42d42f5a 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2725,7 +2725,7 @@ struct FormatStyle {
   /// (counted relative to leading non-whitespace column).
   unsigned PenaltyIndentedWhitespace;
 
-  /// The ``&`` and ``*`` alignment style.
+  /// The ``&``, ``&&`` and ``*`` alignment style.
   enum PointerAlignmentStyle : unsigned char {
 /// Align pointer to the left.
 /// \code
@@ -2820,6 +2820,31 @@ struct FormatStyle {
   /// \endcode
   std::vector RawStringFormats;
 
+  /// \brief The ``&`` and ``&&`` alignment style.
+  enum ReferenceAlignmentStyle {
+/// Align reference like ``PointerAlignment``.
+RAS_Pointer,
+/// Align reference to the left.
+/// \code
+///   int& a;
+/// \endcode
+RAS_Left,
+/// Align reference to the right.
+/// \code
+///   int 
+/// \endcode
+RAS_Right,
+/// Align reference in the middle.
+/// \code
+///   int & a;
+/// \endcode
+RAS_Middle
+  };
+
+  /// \brief Reference alignment style (overrides ``PointerAlignment`` for
+  /// references).
+  ReferenceAlignmentStyle ReferenceAlignment;
+
   // clang-format off
   /// If ``true``, clang-format will attempt to re-flow comments.
   /// \code
@@ -3455,6 +3480,7 @@ struct FormatStyle {
R.PenaltyBreakTemplateDeclaration &&
PointerAlignment == R.PointerAlignment &&
RawStringFormats == R.RawStringFormats &&
+   ReferenceAlignment == R.ReferenceAlignment &&
ShortNamespaceLines == R.ShortNamespaceLines &&
SortIncludes == R.SortIncludes &&
SortJavaStaticImport == R.SortJavaStaticImport &&

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index bfd4d8b5af503..71b7820c2b1c6 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -417,6 +417,16 @@ struct 
ScalarEnumerationTraits {
   }
 };
 
+template <>
+struct ScalarEnumerationTraits {
+  static void enumeration(IO , FormatStyle::ReferenceAlignmentStyle ) 
{
+IO.enumCase(Value, "Pointer", FormatStyle::RAS_Pointer);
+IO.enumCase(Value, "Middle", FormatStyle::RAS_Middle);
+IO.enumCase(Value, "Left", FormatStyle::RAS_Left);
+IO.enumCase(Value, "Right", FormatStyle::RAS_Right);
+  }
+};
+
 template <>
 struct ScalarEnumerationTraits {
   static void enumeration(IO ,
@@ -692,6 +702,7 @@ template <> struct MappingTraits {
 IO.mapOptional("PointerAlignment", Style.PointerAlignment);
 IO.mapOptional("PPIndentWidth", Style.PPIndentWidth);
 IO.mapOptional("RawStringFormats", Style.RawStringFormats);
+IO.mapOptional("ReferenceAlignment", Style.ReferenceAlignment);
 IO.mapOptional("ReflowComments", Style.ReflowComments);
 

[PATCH] D103612: [flang][driver] Add `-fno-analyzed-objects-for-unparse`

[Pete Steinfeld via Phabricator via cfe-commits]

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

All builds, tests, and looks good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

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

[PATCH] D104285: [analyzer] Retrieve value by direct index from list initialization of constant array declaration.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@chrish_ericsson_atx

> I don't understand -- probably I don't have enough experience with analyzer 
> state dumps to know what I should find surprising or better in this example.

Simply saying, now `ptr[3]` returns value `4` as expected, but `arr[1][1]` 
still returns `unknown` symbol.
Previously `ptr[3]` also returned `unknown` symbol, basically matched with what 
`arr[1][1]` returns. 
After my patch `ptr[3]` started to return 'undefined' and therefore asserted.
I've made a fix which improved the behavior for `ptr[3]` but remained 
`arr[1][1]` as is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104285

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

[PATCH] D104871: [Docs] use -fprofile-generate for IR PGO and -fprofile-instr-generate for code coverage

[Zequan Wu via Phabricator via cfe-commits]

zequanwu created this revision.
zequanwu added reviewers: rnk, vsk, davidxl, arphaman.
Herald added a subscriber: wenlei.
zequanwu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add docs to specify `-fprofile-generate` for IR PGO and 
`-fprofile-instr-generate` for code coverage.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104871

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/UsersManual.rst


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1878,12 +1878,13 @@
 
 1. Profile data generated with one cannot be used by the other, and there is no
conversion tool that can convert one to the other. So, a profile generated
-   via ``-fprofile-instr-generate`` must be used with ``-fprofile-instr-use``.
+   via ``-fprofile-generate`` must be used with ``-fprofile-instr-use``.
Similarly, sampling profiles generated by external profilers must be
converted and used with ``-fprofile-sample-use``.
 
-2. Instrumentation profile data can be used for code coverage analysis and
-   optimization.
+2. Instrumentation profile data generated via ``-fprofile-generate`` can be 
used 
+   for optimization and data generated via 
+   ``-fprofile-instr-generate`` can be used for code coverage analysis.
 
 3. Sampling profiles can only be used for optimization. They cannot be used for
code coverage analysis. Although it would be technically possible to use
@@ -2114,26 +2115,35 @@
 Profiling with Instrumentation
 ^^
 
-Clang also supports profiling via instrumentation. This requires building a
-special instrumented version of the code and has some runtime
+Two types of instrumentations
+""
+
+1. ``-fprofile-generate`` is the LLVM IR-based instrumentation, which aims for 
+performance.
+
+2. ``-fprofile-instr-generate`` is the AST-based instrumentation used for code
+coverage analysis (:doc:`source based code coverage 
`).
+
+This section forcuses on LLVM IR instrumentation. This requires 
+building a special instrumented version of the code and has some runtime
 overhead during the profiling, but it provides more detailed results than a
 sampling profiler. It also provides reproducible results, at least to the
 extent that the code behaves consistently across runs.
 
-Here are the steps for using profile guided optimization with
+Here are the steps for using profile guided optimization with LLVM IR
 instrumentation:
 
 1. Build an instrumented version of the code by compiling and linking with the
-   ``-fprofile-instr-generate`` option.
+   ``-fprofile-generate`` option.
 
.. code-block:: console
 
- $ clang++ -O2 -fprofile-instr-generate code.cc -o code
+ $ clang++ -O2 -fprofile-generate code.cc -o code
 
 2. Run the instrumented executable with inputs that reflect the typical usage.
By default, the profile data will be written to a ``default.profraw`` file
in the current directory. You can override that default by using option
-   ``-fprofile-instr-generate=`` or by setting the ``LLVM_PROFILE_FILE`` 
+   ``-fprofile-generate=`` or by setting the ``LLVM_PROFILE_FILE`` 
environment variable to specify an alternate file. If non-default file name
is specified by both the environment variable and the command line option,
the environment variable takes precedence. The file name pattern specified
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -2141,7 +2141,7 @@
 
 .. option:: -fprofile-generate, -fno-profile-generate
 
-Generate instrumented code to collect execution counts into default.profraw 
(overridden by LLVM\_PROFILE\_FILE env var)
+Generate instrumented code to collect execution counts into default.profraw 
(overridden by LLVM\_PROFILE\_FILE env var), used for IR PGO.
 
 .. program:: clang1
 .. option:: -fprofile-generate=
@@ -2151,7 +2151,7 @@
 
 .. option:: -fprofile-instr-generate, -fno-profile-instr-generate
 
-Generate instrumented code to collect execution counts into default.profraw 
file (overridden by '=' form of option or LLVM\_PROFILE\_FILE env var)
+Generate instrumented code to collect execution counts into default.profraw 
file (overridden by '=' form of option or LLVM\_PROFILE\_FILE env var), used 
for code coverage analysis.
 
 .. program:: clang1
 .. option:: -fprofile-instr-generate=


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1878,12 +1878,13 @@
 
 1. Profile data generated with one cannot be used by the other, and there is no
conversion tool that can convert one to the other. So, a profile generated
-   via 

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

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

dexonsmith added a comment.

In D104819#2839315 , @mstorsjo wrote:

> In D104819#2839263 , @dexonsmith 
> wrote:
>
>> Just be sure to clang-format when you do the mechanical changes in the 
>> follow up patches.)
>
> Hmm, those would have to be manually reviewed, but I guess I can try to do 
> that (discarding changes where the surrounding code isn't too well formatted 
> now already so it does more extensive reformattings other than for the 
> renaming).

Sounds good. (I'm generally in favour of erring on the side of trusting 
clang-format, especially for large refactorings like this; I wouldn't spend too 
much time analyzing whether it's an improvement...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

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

[PATCH] D104774: [clang-format] Fix a bug that indents else-comment-if incorrectly

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

HazardyKnusperkeks added a comment.

In D104774#2838287 , @MyDeveloperDay 
wrote:

> @HazardyKnusperkek Its probably my "bad" I should said "LGTM but maybe wait 
> for the others to comment", but I'm fundamentally ok I think with the change. 
> (we'll just revert if it breaks stuff! ;-))
>
> We are free to add review comments after the fact, @owenpan  has been 
> providing us with fixes and contributions to clang-format for a some time 
> (years) so I pretty much trust them. I'm less sceptical in the review of 
> those that contribute either on a regular basis (like yourself) or those who 
> have done multiple features (like @owenpan).  I did actually download the 
> patch, apply it and run all the unit tests too, (because I was slightly 
> questioning in my mind the use of "Previous" and if it could be null), but it 
> all seemed to check out (and I tried some combinations to try and break it))
>
> I don't think we need to wait multiple accepts (although between us I think 
> we do this from time to time), I think the LLVM rules specify that if you 
> have an accept then its ok, But I do feel its perfectly acceptable to review 
> after the fact and expect the author to change it again.
>
> I was the one that added you and @curdeius as reviewers (as I normally do out 
> of respect for your efforts), but perhaps only we know that we are the ones 
> doing the lion share of clang-format reviewing (others might not know that).

No problem here. :) I think the change is small enough and the fix obvious. It 
was just a small comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104774

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

[PATCH] D104285: [analyzer] Retrieve value by direct index from list initialization of constant array declaration.

[Chris Hamilton via Phabricator via cfe-commits]

chrish_ericsson_atx added a comment.

In D104285#2836190 , @ASDenysPetrov 
wrote:

>> I think the presence of the initializer list in the test case is not 
>> necessary to trigger the spurious warnings
>
> Could you please provide some test cases that you think will uncover other 
> issues. I'll add them to the test set.

I tested locally with this patch and found that my guess was incorrect-- I 
couldn't trigger the incorrect behavior without an initializer list.  So I 
think your code and testcases are good as they are!

> I also have to mention one point of what this patch do more. Consider next:
>
>   int const arr[2][2] = {{1, 2}, {3, 4}}; // global space
>   int const *ptr = [0][0];
>   ptr[3]; // represented as ConcreteInt(0) 
>   arr[1][1]; // represented as reg_$0 [2]},1 S64b,int}>
>
> As you can see, now the access through the raw pointer is more presice as 
> through the multi-level indexing. I didn't want to synchronyze those 
> retrieved values both to be `reg_$0`. I've seen a way to handle it more 
> sophisticatedly.
> I'm gonna do the same for the multi-level indexing (aka `arr[1][2][3]`).

I don't understand -- probably I don't have enough experience with analyzer 
state dumps to know what I should find surprising or better in this example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104285

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

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

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

HazardyKnusperkeks added inline comments.



Comment at: clang/include/clang/Format/Format.h:2520
+  /// readability to have the signature indented two levels and to use
+  /// ``OuterScope``. The KJ style guide requires ``OuterScope`.
+  /// `KJ style guide

Here is a ` missing, I'll fix it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102706

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

[clang] b3ccf4f - [clang-format][NFC] Fix documentation

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

Author: Björn Schäpers
Date: 2021-06-24T21:19:14+02:00
New Revision: b3ccf4fc02cdb12eb0929ad9f9dfdec39b785e6a

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

LOG: [clang-format][NFC] Fix documentation

This amends 64cf5eba06bd4f81954253b1e7a10be6fe92403e.

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 77c07284085c8..21028b1f607ad 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -2870,7 +2870,7 @@ the configuration (without a prefix: ``Auto``).
   body to be indented one additional level relative to the parent scope
   containing the lambda signature. For callback-heavy code, it may improve
   readability to have the signature indented two levels and to use
-  ``OuterScope``. The KJ style guide requires ``OuterScope`.
+  ``OuterScope``. The KJ style guide requires ``OuterScope``.
   `KJ style guide
   `_
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 506feea26e8dc..06aeacc9785cc 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2537,7 +2537,7 @@ struct FormatStyle {
   /// body to be indented one additional level relative to the parent scope
   /// containing the lambda signature. For callback-heavy code, it may improve
   /// readability to have the signature indented two levels and to use
-  /// ``OuterScope``. The KJ style guide requires ``OuterScope`.
+  /// ``OuterScope``. The KJ style guide requires ``OuterScope``.
   /// `KJ style guide
   /// 
`_
   LambdaBodyIndentationKind LambdaBodyIndentation;



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

[PATCH] D104550: [analyzer] Implement getType for SVal

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D104550#2838845 , @vsavchenko 
wrote:

>> Another thing is that we can garantee returning `QualType`. I mean, we can 
>> replace `Optional` with `QualType` itself. `QualType` has a default ctor and 
>> `isNull` predicate, which is //true// when defaultly constructed.
>
> I wanted to be more explicit here and convey to the user that the lack of 
> type is normal.  I can change that, it won't be a problem at all.  @NoQ, 
> @Szelethus what do you think?



  // May return nullptr.

And its all good!

In D104550#2835398 , @NoQ wrote:

> Another thing to mention about `SVal::getType()` in its doxygen comment is 
> that //most of the time you don't need it//. Similarly to how checking 
> whether an `SVal` is a `Loc` or a `NonLoc` results in incorrect code 95% of 
> the time (because such code is unable to discriminate between arbitrary 
> lvalues and pointer rvalues which is typically crucial in order to get 
> everything right but often forgotten / misunderstood), relying on the type of 
> the `SVal` rather than its storage raises similar problems.

Then I especially can't imagine a more important doxygen comment then this! We 
could even consider adding your point about `Loc`s and `NonLoc`s to 
`SVal::getAs`. The target audience are new to clang, static analysis, and C++ 
itself. I recall you had to beat some of this stuff into me for weeks when I 
implemented pointer chasing in `UninitializedObjectChecker` :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:301
+  const OverloadedOperatorKind OOK = FD->getOverloadedOperator();
+  if (!(OOK == OO_Equal || OOK == OO_ExclaimEqual || OOK == OO_Less ||
+OOK == OO_LessEqual || OOK == OO_Greater || OOK == OO_GreaterEqual ||

So it looks like `operator<<` is the only operator we are not supporting. I 
think it might be good to include some test code to ensure that its use does 
not suppress warnings. (Also OK, if you decide to deal with this in a follow-up 
PR.)



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:334
+  case OO_LessEqual:
+State = State->assume(()->castAs(), true);
+break;

I think in cases where we know that the result is `true` or `false`, the 
`RetVal` should probably be a constant instead of a conjured symbol with an 
assumption. 



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:341
+  case OO_Spaceship:
+// TODO: What would be a good thing to do here?
+  default:

Instead of marking this unreachable, I'd suggest to just return a conjured 
symbol for now.  Usually, we should not use asserts to test user input.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:354
+
+  if (FirstPtr && !SecondPtr &&
+  State->assume(FirstPtr->castAs(), false)) {

I am not sure if we actually need all this special casing. You could create an 
`SVal` that represents a nullpointer constant and use `evalBinOp` with that 
`SVal` when there is no symbol available.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:394
+default:
+  llvm_unreachable("cannot reach here");
+}

`cannot reach here` is redundant information. That is already encoded in 
`llvm_unreachable`. I suggest including a message that tells the reader **why** 
is it unreachable. In this case it could be `"unexpected overloaded operator 
kind"`.



Comment at: clang/test/Analysis/smart-ptr.cpp:466
+
+  clang_analyzer_eval(ptr == ptr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr > ptr);  // expected-warning{{FALSE}}

Putting tests like this on the same path can be risky. Tests might split the 
execution path (maybe not now, but in the future). I think it might be more 
future proof to have a large switch statement that switches on an unknown value 
and put the tests in separate cases. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D104831#2839301 , @tstellar wrote:

> In D104831#2838835 , @hoy wrote:
>
>> In D104831#2837712 , @MaskRay 
>> wrote:
>>
 Adding the platform tripplet x86_64-redhat-linux-gnu the while list of 
 supported x86_64 triplets so that it can be used with the --gcc-toolchain 
 option to bypass this process and force-pick a given gcc install.
>>>
>>> Did you set `--target=x86_64-redhat-linux-gnu`? With that I don't think you 
>>> need another entry in `X86_64Triples`.
>>>
>>> `X86_64Triples` and its friends are quite clumsy and many entries are not 
>>> actually needed. We should shrink the lists.
>>>
>>> For https://bugzilla.redhat.com/show_bug.cgi?id=1824365 I think the right 
>>> fix is to configure clang with x86_64-redhat-linux-gnu as the default 
>>> triple.
>>
>> Explicitly specifying target or configure the default build target would 
>> work. But I thought  the triple vector being updated is designed for 
>> automatic searching and minimizing configure changes across platforms. Is it 
>> not like that?
>>
>> In D104831#2837795 , @tstellar 
>> wrote:
>>
>>> I'm curious, what kind of system are you running on where you need to use 
>>> --gcc-toolchain x86_64-redhat-linux-gnu is required.
>>
>> One of our platforms is CentOS 7.
>
> Do you know why clang is not auto-detecting x86_64-redhat-linux-gnu?  I'm 
> just wondering if there is some larger problem.

I'm not sure why `x86_64-redhat-linux-gnu` was not in the preset triples. 
`x86_64-redhat-linux` is there though. Maybe gnu libraries are not commonly 
used on Redhat?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a comment.

In D104819#2839263 , @dexonsmith 
wrote:

> LGTM, once @MaskRay is happy. I have a couple of minor comments inline too.
>
> (I also see that there are some clang-format suggestions in the unit tests; 
> not sure any of them are actually improvements so maybe you left those out 
> intentionally?

Yeah those seem to be intentionally vertically aligned that way, no big opinion 
either way

> Just be sure to clang-format when you do the mechanical changes in the follow 
> up patches.)

Hmm, those would have to be manually reviewed, but I guess I can try to do that 
(discarding changes where the surrounding code isn't too well formatted now 
already so it does more extensive reformattings other than for the renaming).




Comment at: llvm/lib/Support/StringRef.cpp:37
 
-/// compare_lower - Compare strings, ignoring case.
-int StringRef::compare_lower(StringRef RHS) const {
+/// compare_insensitive - Compare strings, ignoring case.
+int StringRef::compare_insensitive(StringRef RHS) const {

dexonsmith wrote:
> You can drop these duplicate doxygen comments entirely from the `.cpp` file.
Sure, yeah doxygen in implementation files make little sense anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

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

[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

I would prefer to split this into two changes:

1. Stop providing a builtin overload candidate `R operator<=>(P, P)` where `P` 
is a function pointer type, to be consistent with the behavior of the built-in 
`<=>` operator.
2. Stop providing `<`/`<=`/`>`/`>=` support for function pointer types.

I think (1) is a (relatively) safe change that we can make immediately with 
very little roll-out concern. `<=>` is new, and the built-in candidate would 
never work anyway, so this is unlikely to cause problems for any real code, and 
has had clear and unanimous support in C++ committee discussions. So let's do 
that.

I think (2) is a lot riskier for existing code, and I think there's at least 
some chance that the C++ committee will end up effectively asking for change 
(1) but not change (2). It also looks like this part of the change will require 
a matching change in the standard library, because `std::less` on function 
pointer types would presumably still be required to work. So I think a safer 
approach here would be to add an enabled-by-default warning for relational 
comparisons of function pointers now, and return to this later to make the 
comparisons ill-formed if it still looks like the C++ committee is moving in 
that direction.

Does that sound reasonable?




Comment at: clang/lib/Sema/SemaExpr.cpp:11815
+if (IsError)
+  return Opc != BO_Cmp ? Context.getLogicalOperationType() : QualType();
+  }

mizvekov wrote:
> Quuxplusone wrote:
> > Peanut gallery says: Is `QualType()` the right "placeholder" to return 
> > here? IIUC, this is the situation where we've diagnosed an ill-formed 
> > expression and are just trying to do error-recovery: if the expression 
> > looks like `x < y` then we assume the programmer wants it to return `bool`, 
> > and if the expression looks like `x <=> y` then we assume the programmer 
> > wants it to return... `QualType()`? Is that the same thing we'd do for e.g. 
> > `x + y` or `undeclaredfunction(x)`? (If so, good, I think.)
> So right now, this is the same we are doing for three-way comparison between 
> builtin types we do not support / recognize. Check just below in this same 
> function. Just look for the call to `getComparisonCategoryForBuiltinCmp`.
> 
> I agree completely with you and I was going to raise the same point, but I 
> would prefer we changed both places at once instead of fixing it just here, 
> so I think this should be a follow up task: Find something more appropriate 
> to return here.
A null `QualType` is in this case treated as an indication that the comparison 
is invalid, recovery failed, and the callee has already produced a diagnostic. 
(It's a bit sad that we don't generally use a separate `TypeResult` for this 
kind of thing in order to distinguish between the "no type" answer and the 
"invalid and I've produced a diagnostic" answer, but if we wanted to change 
that I think we should aim to do it holistically across all of Clang.)



Comment at: clang/lib/Sema/SemaExpr.cpp:11807
+  RHSType->isFunctionPointerType()) {
+// Valid unless a relational comparison of function pointers
+bool IsError = getLangOpts().CPlusPlus;





Comment at: clang/lib/Sema/SemaOverload.cpp:9226
 OpBuilder.addEqualEqualOrNotEqualMemberPointerOrNullptrOverloads();
-LLVM_FALLTHROUGH;
+OpBuilder.addGenericBinaryPointerOrEnumeralOverloads(false);
+OpBuilder.addGenericBinaryArithmeticOverloads();

An `/*IsOrdered*/` comment here and below (or use of an enum) would aid 
readability.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

[Chris Lattner via Phabricator via cfe-commits]

lattner accepted this revision.
lattner added a comment.

Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Tom Stellard via Phabricator via cfe-commits]

tstellar added a comment.

In D104831#2838835 , @hoy wrote:

> In D104831#2837712 , @MaskRay wrote:
>
>>> Adding the platform tripplet x86_64-redhat-linux-gnu the while list of 
>>> supported x86_64 triplets so that it can be used with the --gcc-toolchain 
>>> option to bypass this process and force-pick a given gcc install.
>>
>> Did you set `--target=x86_64-redhat-linux-gnu`? With that I don't think you 
>> need another entry in `X86_64Triples`.
>>
>> `X86_64Triples` and its friends are quite clumsy and many entries are not 
>> actually needed. We should shrink the lists.
>>
>> For https://bugzilla.redhat.com/show_bug.cgi?id=1824365 I think the right 
>> fix is to configure clang with x86_64-redhat-linux-gnu as the default triple.
>
> Explicitly specifying target or configure the default build target would 
> work. But I thought  the triple vector being updated is designed for 
> automatic searching and minimizing configure changes across platforms. Is it 
> not like that?
>
> In D104831#2837795 , @tstellar 
> wrote:
>
>> I'm curious, what kind of system are you running on where you need to use 
>> --gcc-toolchain x86_64-redhat-linux-gnu is required.
>
> One of our platforms is CentOS 7.

Do you know why clang is not auto-detecting x86_64-redhat-linux-gnu?  I'm just 
wondering if there is some larger problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104819: [ADT] Rename StringRef case insensitive methods for clarity

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

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

LGTM, once @MaskRay is happy. I have a couple of minor comments inline too.

(I also see that there are some clang-format suggestions in the unit tests; not 
sure any of them are actually improvements so maybe you left those out 
intentionally? Just be sure to clang-format when you do the mechanical changes 
in the follow up patches.)




Comment at: llvm/include/llvm/ADT/StringRef.h:198
 
+LLVM_NODISCARD
+bool equals_lower(StringRef RHS) const { return equals_insensitive(RHS); }

You could probably drop the `LLVM_NODISCARD` from the soon-to-be-deleted 
`_lower` variants, but maybe it's not worth fussing with (up to you).



Comment at: llvm/lib/Support/StringRef.cpp:37
 
-/// compare_lower - Compare strings, ignoring case.
-int StringRef::compare_lower(StringRef RHS) const {
+/// compare_insensitive - Compare strings, ignoring case.
+int StringRef::compare_insensitive(StringRef RHS) const {

You can drop these duplicate doxygen comments entirely from the `.cpp` file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104819

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

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

[Aaron Ballman via Phabricator via cfe-commits]

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

In general, I think this looks good (I did find one minor nit that removes an 
include, but that can be fixed as you land). There's an open question for 
@jansvoboda11 and it'd be nice to hear if @joerg agrees their concerns are 
fully addressed, so please wait a bit before landing to give them time to 
respond with any concerns or feedback.




Comment at: clang/include/clang/Driver/Options.td:4300
 defm pack_derived : BooleanFFlag<"pack-derived">, Group;
-defm protect_parens : BooleanFFlag<"protect-parens">, Group;
+//defm protect_parens : BooleanFFlag<"protect-parens">, Group;
 defm range_check : BooleanFFlag<"range-check">, Group;

mibintc wrote:
> @jansvoboda11 This is a gfortran option, but I don't think there's a way to 
> allow the same option spelling for gfortran and clang. Other clang options, 
> like -short-enum, also have been pulled out of gfortran group, and the 
> gfortran option test is an expected-fail test.
@jansvoboda11 -- do you have any ideas here? Or is the current approach fine 
(and we can remove this commented-out line)?



Comment at: clang/include/clang/Sema/Sema.h:5428
bool AllowRecovery = false);
+  Expr *BuildBuiltinCallExpr(SourceLocation Loc, Builtin::ID Id,
+ MultiExprArg CallArgs);

I think it might make sense to pass in an `unsigned` rather than a 
`Builtin::ID` so that we can avoid including `Builtins.h` (we do this sort of 
dance to avoid including headers elsewhere as well). WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[clang] 8db0dbb - [CodeGen] Don't create fake FunctionDecls when generating block/byref

[Akira Hatanaka via cfe-commits]

Author: Akira Hatanaka
Date: 2021-06-24T11:45:52-07:00
New Revision: 8db0dbbe2c0544c38f33cf64b4cdd5135d524b23

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

LOG: [CodeGen] Don't create fake FunctionDecls when generating block/byref
copy/dispose helper functions

We found out that these fake functions would cause clang to crash if the
changes proposed in https://reviews.llvm.org/D98799 were made.

The original patch was reverted in f681fd927e883301658dcac9a78109ee0aba12a8
because debug locations were missing in the body of the block byref
helper functions. This patch fixes the bug by calling CreateArtificial
after the calls to StartFunction.

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

Added: 


Modified: 
clang/lib/CodeGen/CGBlocks.cpp
clang/test/CodeGenCXX/debug-info-blocks.cpp
clang/test/CodeGenObjC/block-byref-debuginfo.m
clang/test/CodeGenObjC/debug-info-block-helper.m
clang/test/CodeGenObjC/debug-info-blocks.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGBlocks.cpp b/clang/lib/CodeGen/CGBlocks.cpp
index 9956d125d514e..769501a036e60 100644
--- a/clang/lib/CodeGen/CGBlocks.cpp
+++ b/clang/lib/CodeGen/CGBlocks.cpp
@@ -1948,21 +1948,13 @@ CodeGenFunction::GenerateCopyHelperFunction(const 
CGBlockInfo ) {
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = (FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
 
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   llvm::Type *structPtrTy = blockInfo.StructureType->getPointerTo();
@@ -2143,21 +2135,12 @@ CodeGenFunction::GenerateDestroyHelperFunction(const 
CGBlockInfo ) {
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = (FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
 
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   markAsIgnoreThreadCheckingAtRuntime(Fn);
 
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
@@ -2395,21 +2378,15 @@ generateByrefCopyHelper(CodeGenFunction , const 
BlockByrefInfo ,
 llvm::Function::Create(LTy, llvm::GlobalValue::InternalLinkage,
"__Block_byref_object_copy_", ());
 
-  IdentifierInfo *II
-= ("__Block_byref_object_copy_");
-
   SmallVector ArgTys;
   ArgTys.push_back(Context.VoidPtrTy);
   ArgTys.push_back(Context.VoidPtrTy);
-  QualType FunctionTy = Context.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  Context, Context.getTranslationUnitDecl(), SourceLocation(),
-  SourceLocation(), II, FunctionTy, nullptr, SC_Static, false, false);
 
   CGF.CGM.SetInternalFunctionAttributes(GlobalDecl(), Fn, FI);
 
-  CGF.StartFunction(FD, ReturnTy, Fn, FI, args);
+  CGF.StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
+// Create a scope with an artificial location for the body of this 
function.
+  auto AL = ApplyDebugLocation::CreateArtificial(CGF);
 
   if (generator.needsCopy()) {
 llvm::Type *byrefPtrType = byrefInfo.Type->getPointerTo(0);
@@ -2471,20 +2448,14 @@ generateByrefDisposeHelper(CodeGenFunction ,
"__Block_byref_object_dispose_",
());
 
-  IdentifierInfo *II
-= ("__Block_byref_object_dispose_");
-
   SmallVector ArgTys;
   ArgTys.push_back(Context.VoidPtrTy);
-  QualType FunctionTy = Context.getFunctionType(R, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  Context, Context.getTranslationUnitDecl(), SourceLocation(),
-  SourceLocation(), II, FunctionTy, nullptr, SC_Static, false, false);
 
   

[PATCH] D104847: [Clang][NVPTX] Add NVPTX intrinsics and builtins for CUDA PTX 6.5 and 7.0 WMMA and MMA instructions

[Artem Belevich via Phabricator via cfe-commits]

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

Nice. Thank you for adding support for these missing instructions!
LGTM, modulo a few of cosmetic nits.




Comment at: clang/include/clang/Basic/BuiltinsNVPTX.def:762
 
+// Builtins to support double and alternate float WMMA instructions on sm_80
+TARGET_BUILTIN(__dmma_m8n8k4_ld_a, "vd*dC*UiIi", "", AND(SM_80,PTX70))

Is this a sufficient set of builtins to compile mma.h in CUDA-11.x?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:16411-16430
 #define MMA_VARIANTS(geom, type) {{ \
+  Intrinsic::nvvm_wmma_##geom##_mma_row_row_##type, \
+  0,\
+  Intrinsic::nvvm_wmma_##geom##_mma_row_col_##type, \
+  0,\
+  Intrinsic::nvvm_wmma_##geom##_mma_col_row_##type, \
+  0,\

Nit: satf variants are in the minority. We could  move them to the end of the 
variant list and rely on default initialization to 0. E.g something like this:

```
unsigned getMMAIntrinsic(int Layout, bool Satf) {
unsigned Index = Layout + 4*Satf;
if (Index >= Variants.size())
  return 0;
return Variants[Index];
  }
#define MMA_VARIANTS(geom, type) 
  Intrinsic::nvvm_wmma_##geom##_mma_row_row_##type, \
  Intrinsic::nvvm_wmma_##geom##_mma_row_col_##type, \
  Intrinsic::nvvm_wmma_##geom##_mma_col_row_##type, \
  Intrinsic::nvvm_wmma_##geom##_mma_col_col_##type 

#define MMA_SATF_VARIANTS(geom, type)
  MMA_VARIANTS(geom, type), \
  Intrinsic::nvvm_wmma_##geom##_mma_row_row_##type##_satfinite, \
  Intrinsic::nvvm_wmma_##geom##_mma_row_col_##type##_satfinite, \
  Intrinsic::nvvm_wmma_##geom##_mma_col_row_##type##_satfinite, \
  Intrinsic::nvvm_wmma_##geom##_mma_col_col_##type##_satfinite 
...
case NVPTX::BI__hmma_m16n16k16_mma_f16f16:
  return {8, 8, 4, 4, {{ MMA_SATF_VARIANTS(m16n16k16, f16_f16) }}};
...
case NVPTX::BI__dmma_m8n8k4_mma_f64:
  return {1, 1, 2, 2, {{MMA_VARIANTS(m8n8k4, f64)}}};

```

Up to you.



Comment at: clang/test/CodeGen/builtins-nvptx-mma.py:111
+
+  # sub-integer require row/col layout.
   if op.a.ptx_type in ["s4", "u4", "b1"]:

typo in the original code: `sub-integers` or `sub-integer types`



Comment at: clang/test/CodeGen/builtins-nvptx-mma.py:142-146
+  elif frag.geom == "m16n16k8":
+if frag.frag == "d":
+  prefix = "__mma"
+else:
+  prefix = "__mma_tf32"

It's not obvious why  frag `d` is `__mma` and not `__mma_tf32` 
Can we use frag.ptx_type to make that decision?



Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:55
   list regs = !cond(
-// mma.sync.m8n8k4 uses smaller a/b fragments than wmma fp ops
+// mma uses some smaller fragments than wmma fp ops
 !eq(gft,"m8n8k4:a:f16") : !listsplat(llvm_v2f16_ty, 2),

Nit: I'd drop `some`.



Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:219
   list id_frags = !cond(
- // int and sub-int ops are identified by input type.
- !eq(A.ptx_elt_type, "s8") : [A],
- !eq(A.ptx_elt_type, "u8") : [A],
- !eq(A.ptx_elt_type, "s4") : [A],
- !eq(A.ptx_elt_type, "u4") : [A],
- !eq(A.ptx_elt_type, "b1") : [A],
- // the rest are FP ops identified by accumulator & result type.
- true: [D, C]
+ // FP16 ops identified by accumulator & result type.
+ !eq(A.ptx_elt_type, "f16") : [D, C],

Nit: `are identified`



Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:221
+ !eq(A.ptx_elt_type, "f16") : [D, C],
+ // other ops are identified by input type.
+ !ne(A.ptx_elt_type, B.ptx_elt_type): [A, B],

Nit: `types` as both A and B are considered.



Comment at: llvm/include/llvm/IR/IntrinsicsNVVM.td:4474
+foreach satf = [0, 1] in {
+  foreach rnd = ["-", "rn", "rz", "rm", "rp"] in {
+foreach op = NVVM_MMA_OPS.all_wmma_ops in {

We're often using an empty string to represent a `none`. Comparisons with `-` 
where we check `rnd` look like we're doing something special there.
I'd use an empty string for `rnd`, too. 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104847

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

[PATCH] D102361: [OpenMP] Add Module metadata for OpenMP compilation

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 354324.
jhuber6 added a comment.

Addings tests and a module flag for openmp target devices.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102361

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/ordered_codegen.cpp
  clang/test/OpenMP/parallel_for_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/sections_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_dist_schedule_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_dist_schedule_codegen.cpp

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

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD added a comment.

We have a failing test  here (test at line 473).
Which makes me wonder if the `handleComparision` function is at all called. 
This is something I need to check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

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

[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD updated this revision to Diff 354323.
RedDocMD added a comment.

Removed re-invention, added tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtr.h
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/test/Analysis/smart-ptr.cpp

Index: clang/test/Analysis/smart-ptr.cpp
===
--- clang/test/Analysis/smart-ptr.cpp
+++ clang/test/Analysis/smart-ptr.cpp
@@ -457,3 +457,19 @@
 P->foo(); // expected-warning {{Dereference of null smart pointer 'P' [alpha.cplusplus.SmartPtr]}}
   }
 }
+
+void uniquePtrComparision(std::unique_ptr unknownPtr) {
+  auto ptr = std::unique_ptr(new int(13));
+  auto nullPtr = std::unique_ptr();
+  auto otherPtr = std::unique_ptr(new int(29));
+
+  clang_analyzer_eval(ptr == ptr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr > ptr);  // expected-warning{{FALSE}}
+  clang_analyzer_eval(ptr <= ptr); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval(nullPtr <= unknownPtr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(unknownPtr >= nullPtr); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval(ptr != otherPtr); // expected-warning{{TRUE}}
+  clang_analyzer_eval(ptr > nullPtr);   // expected-warning{{TRUE}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -29,6 +29,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SVals.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
+#include "llvm/Support/ErrorHandling.h"
 #include 
 
 using namespace clang;
@@ -68,6 +69,7 @@
   bool updateMovedSmartPointers(CheckerContext , const MemRegion *ThisRegion,
 const MemRegion *OtherSmartPtrRegion) const;
   void handleBoolConversion(const CallEvent , CheckerContext ) const;
+  bool handleComparisionOp(const CallEvent , CheckerContext ) const;
 
   using SmartPtrMethodHandlerFn =
   void (SmartPtrModeling::*)(const CallEvent , CheckerContext &) const;
@@ -89,18 +91,24 @@
   const auto *MethodDecl = dyn_cast_or_null(Call.getDecl());
   if (!MethodDecl || !MethodDecl->getParent())
 return false;
+  return isStdSmartPtr(MethodDecl->getParent());
+}
 
-  const auto *RecordDecl = MethodDecl->getParent();
-  if (!RecordDecl || !RecordDecl->getDeclContext()->isStdNamespace())
+bool isStdSmartPtr(const CXXRecordDecl *RD) {
+  if (!RD || !RD->getDeclContext()->isStdNamespace())
 return false;
 
-  if (RecordDecl->getDeclName().isIdentifier()) {
-StringRef Name = RecordDecl->getName();
+  if (RD->getDeclName().isIdentifier()) {
+StringRef Name = RD->getName();
 return Name == "shared_ptr" || Name == "unique_ptr" || Name == "weak_ptr";
   }
   return false;
 }
 
+bool isStdSmartPtr(const Expr *E) {
+  return isStdSmartPtr(E->getType()->getAsCXXRecordDecl());
+}
+
 bool isNullSmartPtr(const ProgramStateRef State, const MemRegion *ThisRegion) {
   const auto *InnerPointVal = State->get(ThisRegion);
   return InnerPointVal &&
@@ -178,6 +186,15 @@
 bool SmartPtrModeling::evalCall(const CallEvent ,
 CheckerContext ) const {
   ProgramStateRef State = C.getState();
+
+  // If any one of the arg is a unique_ptr, then
+  // we can try this function
+  if (Call.getNumArgs() == 2)
+if (smartptr::isStdSmartPtr(Call.getArgExpr(0)) ||
+smartptr::isStdSmartPtr(Call.getArgExpr(1)))
+  if (handleComparisionOp(Call, C))
+return true;
+
   if (!smartptr::isStdSmartPtrCall(Call))
 return false;
 
@@ -272,6 +289,123 @@
   return C.isDifferent();
 }
 
+bool SmartPtrModeling::handleComparisionOp(const CallEvent ,
+   CheckerContext ) const {
+  const auto *FC = dyn_cast();
+  if (!FC)
+return false;
+  const FunctionDecl *FD = FC->getDecl();
+  if (!FD->isOverloadedOperator())
+return false;
+  const OverloadedOperatorKind OOK = FD->getOverloadedOperator();
+  if (!(OOK == OO_Equal || OOK == OO_ExclaimEqual || OOK == OO_Less ||
+OOK == OO_LessEqual || OOK == OO_Greater || OOK == OO_GreaterEqual ||
+OOK == OO_Spaceship))
+return false;
+
+  SVal First = Call.getArgSVal(0);
+  SVal Second = Call.getArgSVal(1);
+
+  // There are some special cases about which we can infer about
+  // the resulting answer.
+  // For reference, there is a discussion at https://reviews.llvm.org/D104616.
+  // Also, the cppreference page is good to look at
+  // https://en.cppreference.com/w/cpp/memory/unique_ptr/operator_cmp.
+
+  ProgramStateRef State = C.getState();
+  SVal RetVal = C.getSValBuilder().conjureSymbolVal(
+  Call.getOriginExpr(), 

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml:189
 
+# RUN: sed -e 's//64/' -e 's//AMDGCN_GFX1035/' %s | yaml2obj -o 
%t.o.AMDGCN_GFX1035
+# RUN: llvm-readobj -S --file-headers %t.o.AMDGCN_GFX1035 | FileCheck 
--check-prefixes=ELF-AMDGCN-ALL,ELF-AMDGCN-GFX1035 %s

sed can be replaced by `FileCheck -D` (search examples in `test/tools/`).

The long list becomes unwieldy now. @jhenderson Suggestions on decreasing the 
number of RUN lines?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

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

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil 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 rG3453f3dd46f5: [AMDGPU] Add gfx1035 target (authored by 
aakanksha555).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/MC/AMDGPU/gfx1011_dlops.s
  llvm/test/MC/AMDGPU/gfx1030_err.s
  llvm/test/MC/AMDGPU/gfx1030_new.s
  llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
  llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
  llvm/tools/llvm-readobj/ELFDumper.cpp
  openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp

Index: openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
===
--- openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
+++ openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
@@ -51,6 +51,8 @@
 return "gfx1033";
   case EF_AMDGPU_MACH_AMDGCN_GFX1034:
 return "gfx1034";
+  case EF_AMDGPU_MACH_AMDGCN_GFX1035:
+return "gfx1035";
   default:
 return "--unknown gfx";
   }
Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1493,6 +1493,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_V3),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_SRAMECC_V3)
 };
@@ -1546,6 +1547,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ANY_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_OFF_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ON_V4),
Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -277,6 +277,14 @@
 # RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034 -DFLAG_VALUE=0x3E
 
+# RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=1 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=1 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
 
 # RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME="EF_AMDGPU_MACH_AMDGCN_GFX90A, EF_AMDGPU_FEATURE_XNACK_V3"
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,DOUBLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_0="EF_AMDGPU_FEATURE_XNACK_V3 (0x100)" -DFLAG_1="EF_AMDGPU_MACH_AMDGCN_GFX90A (0x3F)" -DFLAG_VALUE=0x13F
Index: 

[clang] 3453f3d - [AMDGPU] Add gfx1035 target

[Aakanksha Patil via cfe-commits]

Author: Aakanksha Patil
Date: 2021-06-24T14:32:41-04:00
New Revision: 3453f3dd46f5214e028cb33818b10c5d995cd858

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

LOG: [AMDGPU] Add gfx1035 target

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

Added: 


Modified: 
clang/include/clang/Basic/Cuda.h
clang/lib/Basic/Cuda.cpp
clang/lib/Basic/Targets/AMDGPU.cpp
clang/lib/Basic/Targets/NVPTX.cpp
clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
clang/test/CodeGenOpenCL/amdgpu-features.cl
clang/test/Driver/amdgpu-macros.cl
clang/test/Driver/amdgpu-mcpu.cl
clang/test/Misc/target-invalid-cpu-note.c
llvm/docs/AMDGPUUsage.rst
llvm/include/llvm/BinaryFormat/ELF.h
llvm/include/llvm/Support/TargetParser.h
llvm/lib/Object/ELFObjectFile.cpp
llvm/lib/ObjectYAML/ELFYAML.cpp
llvm/lib/Support/TargetParser.cpp
llvm/lib/Target/AMDGPU/GCNProcessors.td
llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
llvm/test/MC/AMDGPU/gfx1011_dlops.s
llvm/test/MC/AMDGPU/gfx1030_err.s
llvm/test/MC/AMDGPU/gfx1030_new.s
llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
llvm/tools/llvm-readobj/ELFDumper.cpp
openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Cuda.h 
b/clang/include/clang/Basic/Cuda.h
index 13317f62c3c5a..aa12724cbf0c6 100644
--- a/clang/include/clang/Basic/Cuda.h
+++ b/clang/include/clang/Basic/Cuda.h
@@ -89,6 +89,7 @@ enum class CudaArch {
   GFX1032,
   GFX1033,
   GFX1034,
+  GFX1035,
   LAST,
 };
 

diff  --git a/clang/lib/Basic/Cuda.cpp b/clang/lib/Basic/Cuda.cpp
index fa7f78a25829f..766135bcb376f 100644
--- a/clang/lib/Basic/Cuda.cpp
+++ b/clang/lib/Basic/Cuda.cpp
@@ -111,6 +111,7 @@ static const CudaArchToStringMap arch_names[] = {
 GFX(1032), // gfx1032
 GFX(1033), // gfx1033
 GFX(1034), // gfx1034
+GFX(1035), // gfx1035
 // clang-format on
 };
 #undef SM

diff  --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index 8a8165e9c895c..595132e2e70ba 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -184,6 +184,7 @@ bool AMDGPUTargetInfo::initFeatureMap(
   // XXX - What does the member GPU mean if device name string passed here?
   if (isAMDGCN(getTriple())) {
 switch (llvm::AMDGPU::parseArchAMDGCN(CPU)) {
+case GK_GFX1035:
 case GK_GFX1034:
 case GK_GFX1033:
 case GK_GFX1032:

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index 885dac9ab79d7..56f8a179db3cc 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -213,6 +213,7 @@ void NVPTXTargetInfo::getTargetDefines(const LangOptions 
,
   case CudaArch::GFX1032:
   case CudaArch::GFX1033:
   case CudaArch::GFX1034:
+  case CudaArch::GFX1035:
   case CudaArch::LAST:
 break;
   case CudaArch::UNUSED:

diff  --git a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
index 772717c496757..2e79e2978d3da 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -4194,6 +4194,7 @@ void CGOpenMPRuntimeGPU::processRequiresDirective(
   case CudaArch::GFX1032:
   case CudaArch::GFX1033:
   case CudaArch::GFX1034:
+  case CudaArch::GFX1035:
   case CudaArch::UNUSED:
   case CudaArch::UNKNOWN:
 break;

diff  --git a/clang/test/CodeGenOpenCL/amdgpu-features.cl 
b/clang/test/CodeGenOpenCL/amdgpu-features.cl
index b4b86d75c9ae7..a532da344df1a 100644
--- a/clang/test/CodeGenOpenCL/amdgpu-features.cl
+++ b/clang/test/CodeGenOpenCL/amdgpu-features.cl
@@ -34,6 +34,7 @@
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1032 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1032 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1033 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1033 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1034 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1034 %s
+// RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1035 -S -emit-llvm -o - %s | 
FileCheck --check-prefix=GFX1035 %s
 
 // GFX600: "target-features"="+s-memtime-inst"
 // GFX601: "target-features"="+s-memtime-inst"
@@ -66,5 +67,6 @@
 // GFX1032: 

[PATCH] D104777: PR50767: clear non-distinct debuginfo for function with nodebug definition after undecorated declaration

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D104777#2838211 , @aaron.ballman 
wrote:

> In D104777#2837794 , @dblaikie 
> wrote:
>
>> In D104777#2837347 , 
>> @brunodefraine wrote:
>>
>>> In D104777#2836669 , @dblaikie 
>>> wrote:
>>>
 Yeah, all that sounds reasonable to me - @brunodefraine could you look 
 into supporting nodebug in a similar way as @aaron.ballman has described 
 here?
>>>
>>> Since the debuginfo for `use()` is slightly affected by the `nodebug` 
>>> version of `t1()` that follows it, I can see how this back propagation is 
>>> perhaps dangerous. Checking that `nodebug` is the same on all declarations 
>>> of a function is a way to prevent this.
>>>
>>> But when discussing the PR, @probinson wrote "I'm inclined to think we want 
>>> this to work" and I can see what he means from the use case where I 
>>> observed the bug. If you don't want debuginfo for the implementation of 
>>> `t1()`, it should be fine to annotate just the function definition in an 
>>> implementation file, not the declaration in a header, since the debuginfo 
>>> of the implementation is not of the caller's concern. But `nodebug` as it 
>>> exists **does** affect the debuginfo of callers as well, so I cannot really 
>>> express that I don't want debuginfo for the implementation of a function 
>>> and leave its callers unaffected?
>>
>> I can see the convenience there, to be sure, being able to put the attribute 
>> directly on the function you want to debug - but consistency in how 
>> attributes are handled (admitedly this isn't a strong consistency - some are 
>> handled this way, some aren't) & consistently seeing the same state for an 
>> attribute for a given function seems useful.
>>
>> @probinson - thoughts?
>
> To me, this is the key bit:
>
>> But `nodebug` as it exists **does** affect the debuginfo of callers as well, 
>> so I cannot really express that I don't want debuginfo for the 
>> implementation of a function and leave its callers unaffected?
>
> because it **does** affect the callers, the programmer introducing the API 
> should be aware of that. Making this case an error helps them to understand 
> that this attribute is actually a part of their API and not an implementation 
> detail, and silently applying the attribute may cause hard-to-debug problems 
> for them after deployment of their API.

Yeah - the effect on callers is fairly minimal when it comes to DWARF. It 
changes whether DW_TAG_call_sites are emitted for the function - those call 
sites can help describe tail calls (which isn't nothing - in the absence of 
this info you can have missing stack frames, I think) but also mostly helps by 
describing "entry values" (if a caller stashes a value before calling a 
function, the call site can record where the extra copy was stored - then the 
callee might be able to describe the value of its parameters in terms of those 
entry values even if the callee's copy has been clobbered) - that these 
features would be dropped only in the translation unit that's compiling the 
implementation of the function, but not in every calling TU, is not a great 
loss - adding the attribute to the header would remove this extra information 
from everywhere (but at the expense of a longer build, having to rebuild all 
the dependencies).

Hmm - yeah, nodebug is more the sort of thing you put on a function because 
it's not an abstraction you want to debug - so I /think/ it makes sense to put 
it on the declaration in the header, rather than only on the implementation (I 
was going to say I thought it'd be the thing someone might do more 
iteratively/interactively - but that's "optnone" - where you'd want to put it 
on a function during a test/debug loop and wouldn't want to have to rebuild the 
whole project because it's more one-off, but "nodebug" isn't intended for that 
same sort of one-off use case)

Eh, I could see it going either way...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104777

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

[PATCH] D104800: [OpenCL] Do not include default header for preprocessor output as input

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

LGTM! Thanks

I agree we should have the same behavior for both options. Technically 
`-finclude-default-header` could be added in both steps but it is only 
effective in parsing the sources and does nothing otherwise. But it seems 
cleaner to align it with the header include option.


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

https://reviews.llvm.org/D104800

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

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

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 354301.
mibintc added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/AST/arithmetic-fence-builtin.c
  clang/test/CodeGen/arithmetic-fence-builtin.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Sema/arithmetic-fence-builtin.c

Index: clang/test/Sema/arithmetic-fence-builtin.c
===
--- /dev/null
+++ clang/test/Sema/arithmetic-fence-builtin.c
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -triple i386-pc-linux-gnu -emit-llvm -o - -verify -x c++ %s
+// RUN: %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -verify -x c++ %s
+// RUN: not %clang_cc1 -triple ppc64le -DPPC -emit-llvm -o - -x c++ %s \
+// RUN:-fprotect-parens 2>&1 | FileCheck -check-prefix=PPC %s
+#ifndef PPC
+int v;
+template  T addT(T a, T b) {
+  T *q = __arithmetic_fence();
+  // expected-error@-1 {{invalid operand of type 'float *' where floating, complex or a vector of such types is required}}
+  // expected-error@-2 {{invalid operand of type 'int *' where floating, complex or a vector of such types is required}}
+  return __arithmetic_fence(a + b);
+  // expected-error@-1 {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+}
+int addit(int a, int b) {
+  float x, y;
+  typedef struct {
+int a, b;
+  } stype;
+  stype s;
+  s = __arithmetic_fence(s);// expected-error {{invalid operand of type 'stype' where floating, complex or a vector of such types is required}}
+  x = __arithmetic_fence(); // expected-error {{too few arguments to function call, expected 1, have 0}}
+  x = __arithmetic_fence(x, y); // expected-error {{too many arguments to function call, expected 1, have 2}}
+  // Complex is supported.
+  _Complex double cd, cd1;
+  cd = __arithmetic_fence(cd1);
+  // Vector is supported.
+  typedef float __v4hi __attribute__((__vector_size__(8)));
+  __v4hi vec1, vec2;
+  vec1 = __arithmetic_fence(vec2);
+
+  v = __arithmetic_fence(a + b); // expected-error {{invalid operand of type 'int' where floating, complex or a vector of such types is required}}
+  float f = addT(a, b);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  int i = addT(1, 2);   // expected-note {{in instantiation of function template specialization 'addT' requested here}}
+  constexpr float d = 1.0 + 2.0;
+  constexpr float c = __arithmetic_fence(1.0 + 2.0);
+  constexpr float e = __arithmetic_fence(d);
+  return 0;
+}
+bool func(float f1, float f2, float f3) {
+  return (f1 == f2 && f1 == f3) || f2 == f3; // Should not warn here
+}
+static_assert( __arithmetic_fence(1.0 + 2.0), "message" );
+#else
+float addit(float a, float b) {
+  return __arithmetic_fence(a+b); // expected-error {{builtin is not supported on this target}}
+}
+#endif
+//PPC: error: option '-fprotect-parens' cannot be specified on this target
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -1,13 +1,14 @@
 // REQUIRES: clang-driver
 
 // RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fblocks -fbuiltin -fmath-errno -fcommon -fpascal-strings -fsplit-stack %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS1 %s
-// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
+// RUN: %clang -### -S -fasm -fblocks -fbuiltin -fno-math-errno -fcommon -fpascal-strings -fno-asm -fno-blocks -fno-builtin -fmath-errno -fno-common -fno-pascal-strings -fno-show-source-location -fshort-enums -fprotect-parens %s 2>&1 | FileCheck -check-prefix=CHECK-OPTIONS2 %s
 
 // CHECK-OPTIONS1: -fsplit-stack
 // CHECK-OPTIONS1: -fgnu-keywords
 // CHECK-OPTIONS1: -fblocks
 // CHECK-OPTIONS1: -fpascal-strings
 
+// CHECK-OPTIONS2: -fprotect-parens
 // CHECK-OPTIONS2: -fmath-errno
 // CHECK-OPTIONS2: -fno-gnu-keywords
 // CHECK-OPTIONS2: -fno-builtin
Index: clang/test/CodeGen/arithmetic-fence-builtin.c

[PATCH] D99675: [llvm][clang] Create new intrinsic llvm.arithmetic.fence to control FP optimization at expression level

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 354300.
mibintc added a comment.

Rebasing.  Hope this clears lit fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/CodeGen/SelectionDAGISel.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/Support/TargetOpcodes.def
  llvm/include/llvm/Target/Target.td
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
  llvm/test/CodeGen/X86/arithmetic_fence.ll
  llvm/test/CodeGen/X86/arithmetic_fence2.ll

Index: llvm/test/CodeGen/X86/arithmetic_fence2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/arithmetic_fence2.ll
@@ -0,0 +1,170 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
+
+define double @f1(double %a) {
+; X86-LABEL: f1:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:movsd %xmm0, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f1:
+; X64:   # %bb.0:
+; X64-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %1, %2
+  ret double %3
+}
+
+define double @f2(double %a) {
+; X86-LABEL: f2:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:addsd %xmm0, %xmm0
+; X86-NEXT:movapd %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addsd %xmm0, %xmm1
+; X86-NEXT:movsd %xmm1, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f2:
+; X64:   # %bb.0:
+; X64-NEXT:addsd %xmm0, %xmm0
+; X64-NEXT:movapd %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addsd %xmm0, %xmm1
+; X64-NEXT:movapd %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %t = call double @llvm.arithmetic.fence.f64(double %1)
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %t, %2
+  ret double %3
+}
+
+define <2 x float> @f3(<2 x float> %a) {
+; X86-LABEL: f3:
+; X86:   # %bb.0:
+; X86-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f3:
+; X64:   # %bb.0:
+; X64-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %1, %2
+  ret <2 x float> %3
+}
+
+define <2 x float> @f4(<2 x float> %a) {
+; X86-LABEL: f4:
+; X86:   # %bb.0:
+; X86-NEXT:addps %xmm0, %xmm0
+; X86-NEXT:movaps %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addps %xmm0, %xmm1
+; X86-NEXT:movaps %xmm1, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f4:
+; X64:   # %bb.0:
+; X64-NEXT:addps %xmm0, %xmm0
+; X64-NEXT:movaps %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addps %xmm0, %xmm1
+; X64-NEXT:movaps %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %t = call <2 x float> @llvm.arithmetic.fence.v2f32(<2 x float> %1)
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %t, %2
+  ret <2 x float> %3
+}
+
+define <8 x float> @f5(<8 x float> %a) {
+; X86-LABEL: f5:
+; X86:   # %bb.0:
+; X86-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X86-NEXT:mulps %xmm2, %xmm0
+; X86-NEXT:mulps %xmm2, %xmm1
+; X86-NEXT:retl
+;
+; X64-LABEL: f5:
+; X64:   # %bb.0:
+; X64-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X64-NEXT:mulps %xmm2, %xmm0
+; X64-NEXT:mulps %xmm2, %xmm1
+; X64-NEXT:retq
+  %1 = fadd fast <8 x float> %a, %a
+  %2 = fadd fast <8 x float> %a, %a
+  %3 = fadd fast <8 

[PATCH] D104822: [RISCV] Add vget/vset intrinsics for inserting and extracting between different lmuls.

[Craig Topper via Phabricator via cfe-commits]

craig.topper updated this revision to Diff 354297.
craig.topper added a comment.

Add constant argument range checking to SemaChecking


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104822

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/rvv-intrinsics/vget.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c

Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vset.c
@@ -0,0 +1,546 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv64 -target-feature +f -target-feature +d -target-feature +experimental-v \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck --check-prefix=CHECK-RV64 %s
+
+#include 
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m2_t test_vset_v_i8m1_i8m2(vint8m2_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 24)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m1_i8m4(vint8m4_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vset_v_i8m2_i8m4(vint8m4_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m1_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv8i8( [[DEST:%.*]],  [[VAL:%.*]], i64 56)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m1_i8m8(vint8m8_t dest, vint8m1_t val) {
+  return vset_v_i8m1_i8m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m2_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv16i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m2_i8m8(vint8m8_t dest, vint8m2_t val) {
+  return vset_v_i8m2_i8m8(dest, 2, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i8m4_i8m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv64i8.nxv32i8( [[DEST:%.*]],  [[VAL:%.*]], i64 32)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m8_t test_vset_v_i8m4_i8m8(vint8m8_t dest, vint8m4_t val) {
+  return vset_v_i8m4_i8m8(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv8i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 4)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m2_t test_vset_v_i16m1_i16m2(vint16m2_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m2(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 12)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m1_i16m4(vint16m4_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m4(dest, 3, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv16i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 8)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m4_t test_vset_v_i16m2_i16m4(vint16m4_t dest, vint16m2_t val) {
+  return vset_v_i16m2_i16m4(dest, 1, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m1_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i16.nxv4i16( [[DEST:%.*]],  [[VAL:%.*]], i64 28)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m8_t test_vset_v_i16m1_i16m8(vint16m8_t dest, vint16m1_t val) {
+  return vset_v_i16m1_i16m8(dest, 7, val);
+}
+
+// CHECK-RV64-LABEL: @test_vset_v_i16m2_i16m8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.experimental.vector.insert.nxv32i16.nxv8i16( [[DEST:%.*]],  [[VAL:%.*]], i64 16)
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint16m8_t test_vset_v_i16m2_i16m8(vint16m8_t dest, vint16m2_t val) {
+  return 

[PATCH] D102507: [HIP] Support in device code

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

The key difference between C++ and CUDA/HIP, as implemented in clang, is that 
`__host__` and `__device__` attributes are considered during function 
overloading in CUDA and HIP, so `__host__ void foo()`, `__device__ void foo()` 
and `__host__ __device__ void foo()` are three different functions and not 
redeclarations of the same function. Details of the original proposal are here: 
 https://goo.gl/EXnymm.

In D102507#2838776 , @yaxunl wrote:

> 2. Some libc++ functions are mostly common for device or host with minor 
> differences. For such functions, we can make them `__device__ __host__` and 
> use `#if __HIP_DEVICE_COMPILE__` (indicating device compilation) for the 
> minor difference in the function body.

I think we should rely on target overloading when possible, instead of the 
preprocessor. Minimizing the differences between the code seen by compiler 
during host and device side compilation will minimize potential issues.
Which approach we'll end up using is an implementation detail.

> 3. Some libc++ functions have different implementations for device and host. 
> We can leave these host functions as they are and adding overloaded 
> `__device__` functions.
>
> There are two ways to mark libc++ functions as `__device__ __host__`:
>
> 1. Define a macro which expands to empty for non-HIP programs and expands to 
> `__device__ __host__` for HIP and add it to each libc++ function which is to 
> be marked as `__device__ __host__`.

One caveat of the overloading based on target attributes is that we can't 
re-declare a function with `__device__ __host__` as compiler will see attempted 
redeclaration as a function overload of a function w/o attributes (implicitly 
`__host__`).

> 2. Define macros which expand to empty for non-HIP programs and expand to 
> `#pragma clang force_cuda_host_device begin/end` for HIP and put them at the 
> beginning and end of a file where all the functions are to be marked as 
> `__device__ __host__`.
>
> We plan to implement libc++ support in HIP device compilation in a 
> progressive approach, header by header, and document the supported libc++ 
> headers. We will prioritize libc++ headers to support based on 1) user 
> requests 2) whether it has already been supported through clang wrapper 
> headers (patching) 4) usefulness for device execution 3) availability of 
> lower level support with HIP runtime.

All of the above applies to CUDA, modulo the macro names and some differences 
in the builtins and the the functions provided (or not) by runtime on the GPU 
side.


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

https://reviews.llvm.org/D102507

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

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil via Phabricator via cfe-commits]

aakanksha555 added a comment.

In D104804#2838883 , @foad wrote:

> Looks OK. Have you run check-llvm and check-clang?

I did, no other failing tests observed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

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

[PATCH] D103612: [flang][driver] Add `-funparse-typed-exprs-as-fortran`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 354294.
awarzynski added a subscriber: PeteSteinfeld.
awarzynski added a comment.

Rename the new flag as `-fno-analyzed-objects-for-unparse`

Based on the discussion, I've renamed the flag to better reflect the intention. 
Does it make more sense now?

Note, the default behaviour of the drivers does not change with this patch 
(i.e. `{f18|flang-new} -fdebug-unparse` will generate identical results 
_before_ and _after_).

@klousler & @PeteSteinfeld, many thanks for all the feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103612

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

Index: flang/tools/f18/flang
===
--- flang/tools/f18/flang
+++ flang/tools/f18/flang
@@ -8,7 +8,7 @@
 #======#
 
 wd=$(cd $(dirname "$0")/.. && pwd)
-opts="-module-suffix .f18.mod "
+opts="-fno-analyzed-objects-for-unparse -module-suffix .f18.mod "
 if ! $wd/bin/f18 $opts "$@"
 then status=$?
  echo flang: in $PWD, f18 failed with exit status $status: $wd/bin/f18 $opts "$@" >&2
Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -105,7 +105,7 @@
   bool debugModuleWriter{false};
   bool defaultReal8{false};
   bool measureTree{false};
-  bool unparseTypedExprsToF18_FC{false};
+  bool useAnalyzedObjectsForUnparse{true};
   std::vector F18_FCArgs;
   const char *prefix{nullptr};
   bool getDefinition{false};
@@ -322,7 +322,8 @@
 Unparse(llvm::outs(), parseTree, driver.encoding, true /*capitalize*/,
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
-nullptr /* action before each statement */, );
+nullptr /* action before each statement */,
+driver.useAnalyzedObjectsForUnparse ?  : nullptr);
 return {};
   }
   if (driver.dumpPreFirTree) {
@@ -353,7 +354,7 @@
 options.features.IsEnabled(
 Fortran::common::LanguageFeature::BackslashEscapes),
 nullptr /* action before each statement */,
-driver.unparseTypedExprsToF18_FC ?  : nullptr);
+driver.useAnalyzedObjectsForUnparse ?  : nullptr);
   }
 
   RunOtherCompiler(driver, tmpSourcePath.data(), relo.data());
@@ -578,8 +579,8 @@
 } else if (arg == "-funparse-with-symbols" ||
 arg == "-fdebug-unparse-with-symbols") {
   driver.dumpUnparseWithSymbols = true;
-} else if (arg == "-funparse-typed-exprs-to-f18-fc") {
-  driver.unparseTypedExprsToF18_FC = true;
+} else if (arg == "-fno-analyzed-objects-for-unparse") {
+  driver.useAnalyzedObjectsForUnparse = false;
 } else if (arg == "-fparse-only" || arg == "-fsyntax-only") {
   driver.syntaxOnly = true;
 } else if (arg == "-c") {
Index: flang/test/Driver/unparse-use-analyzed.f95
===
--- /dev/null
+++ flang/test/Driver/unparse-use-analyzed.f95
@@ -0,0 +1,31 @@
+! Tests `-fno-analyzed-exprs-as-fortran` frontend option
+
+!--
+! RUN lines
+!--
+! RUN: %flang_fc1 -fdebug-unparse  %s | FileCheck %s --check-prefix=DEFAULT
+! RUN: %flang_fc1 -fdebug-unparse -fno-analyzed-objects-for-unparse %s | FileCheck %s --check-prefix=DISABLED
+
+!
+! EXPECTED OUTPUT: default - use analyzed objects
+!
+! DEFAULT: PROGRAM test
+! DEFAULT-NEXT:  REAL, PARAMETER :: val = 3.43e2_4
+! DEFAULT-NEXT:  PRINT *, 3.47e2_4
+! DEFAULT-NEXT: END PROGRAM
+
+!---
+! EXPECTED OUTPUT: disabled - don't use the analyzed objects
+!---
+! DISABLED: PROGRAM test
+! DISABLED-NEXT:  REAL, PARAMETER :: val = 343.0
+! DISABLED-NEXT:  PRINT *, val+4
+! DISABLED-NEXT: END PROGRAM
+
+!--
+! INPUT
+!--
+program test
+  real, parameter :: val = 343.0
+  print *, val + 4
+end program
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -101,6 +101,8 @@
 ! HELP-FC1-NEXT:Specify where to find the compiled intrinsic modules
 ! HELP-FC1-NEXT: -flarge-sizes  Use INTEGER(KIND=8) for the result type in size-related intrinsics
 ! 

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Jay Foad via Phabricator via cfe-commits]

foad added a comment.

Looks OK. Have you run check-llvm and check-clang?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

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

[PATCH] D104804: [AMDGPU] Add gfx1035 target

[Aakanksha Patil via Phabricator via cfe-commits]

aakanksha555 updated this revision to Diff 354270.
aakanksha555 marked 4 inline comments as done.
aakanksha555 added a comment.

Addressed feedback; fixed typo and missing check lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104804

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Cuda.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/MC/AMDGPU/gfx1011_dlops.s
  llvm/test/MC/AMDGPU/gfx1030_err.s
  llvm/test/MC/AMDGPU/gfx1030_new.s
  llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
  llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll
  llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
  llvm/tools/llvm-readobj/ELFDumper.cpp
  openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp

Index: openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
===
--- openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
+++ openmp/libomptarget/plugins/amdgpu/impl/get_elf_mach_gfx_name.cpp
@@ -51,6 +51,8 @@
 return "gfx1033";
   case EF_AMDGPU_MACH_AMDGCN_GFX1034:
 return "gfx1034";
+  case EF_AMDGPU_MACH_AMDGCN_GFX1035:
+return "gfx1035";
   default:
 return "--unknown gfx";
   }
Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1488,6 +1488,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_V3),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_SRAMECC_V3)
 };
@@ -1541,6 +1542,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1035),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ANY_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_OFF_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ON_V4),
Index: llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
===
--- llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
+++ llvm/test/tools/llvm-readobj/ELF/amdgpu-elf-headers.test
@@ -277,6 +277,14 @@
 # RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1034 -DFLAG_VALUE=0x3E
 
+# RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=1 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=1 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
+#
+# RUN: yaml2obj %s -o %t -DABI_VERSION=2 -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035
+# RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,SINGLE-FLAG --match-full-lines -DABI_VERSION=2 -DFILE=%t -DFLAG_NAME=EF_AMDGPU_MACH_AMDGCN_GFX1035 -DFLAG_VALUE=0x3D
 
 # RUN: yaml2obj %s -o %t -DABI_VERSION=0 -DFLAG_NAME="EF_AMDGPU_MACH_AMDGCN_GFX90A, EF_AMDGPU_FEATURE_XNACK_V3"
 # RUN: llvm-readobj -h %t | FileCheck %s --check-prefixes=ALL,KNOWN-ABI-VERSION,DOUBLE-FLAG --match-full-lines -DABI_VERSION=0 -DFILE=%t -DFLAG_0="EF_AMDGPU_FEATURE_XNACK_V3 (0x100)" -DFLAG_1="EF_AMDGPU_MACH_AMDGCN_GFX90A (0x3F)" -DFLAG_VALUE=0x13F
Index: llvm/test/tools/llvm-objdump/ELF/AMDGPU/subtarget.ll

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D104854#2838754 , @craig.topper 
wrote:

> Doesn't gcc also fold isnan to false under fast math? If we diverge here that 
> means your code would only work correctly with clang.

GCC does the same transformation, ICC and MSVC do not: 
https://godbolt.org/z/ovboWqPeb. Both clang and GCC do this transformation only 
with optimization level > 0. With -O0 both produce code that does real check, 
so semantic of the produced code is different depending on optimization level, 
it looks more like a bug rather than feature.

There is a GCC ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949, 
which refers to the similar thing. It is created against to libstdc++ but the 
reason is in the compiler. In one on the comments there 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84949#c8) an opinion is expressed:

  ... My conclusion: std::numeric_limits means "has NaN bitpattern" and "has 
IEC559 bit layout" not "has NaNs with NaN behavior" and "has IEC559 behavior".

So this behavior is considered as incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D104381: [analyzer] Added a test case for PR46264

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

I bisected. This bug was fixed intentionally by D85817 
, forgot to close I guess.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104381

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D104831#2838835 , @hoy wrote:

> In D104831#2837712 , @MaskRay wrote:
>
>>> Adding the platform tripplet x86_64-redhat-linux-gnu the while list of 
>>> supported x86_64 triplets so that it can be used with the --gcc-toolchain 
>>> option to bypass this process and force-pick a given gcc install.
>>
>> Did you set `--target=x86_64-redhat-linux-gnu`? With that I don't think you 
>> need another entry in `X86_64Triples`.
>>
>> `X86_64Triples` and its friends are quite clumsy and many entries are not 
>> actually needed. We should shrink the lists.
>>
>> For https://bugzilla.redhat.com/show_bug.cgi?id=1824365 I think the right 
>> fix is to configure clang with x86_64-redhat-linux-gnu as the default triple.
>
> Explicitly specifying target or configure the default build target would 
> work. But I thought  the triple vector being updated is designed for 
> automatic searching and minimizing configure changes across platforms. Is it 
> not like that?

I am not sure about this guarantee. The list could be endless long if we 
supported every platform.

The right fix is to configure llvm-project with a correct 
`LLVM_DEFAULT_TARGET_TRIPLE`.

> In D104831#2837795 , @tstellar 
> wrote:
>
>> I'm curious, what kind of system are you running on where you need to use 
>> --gcc-toolchain x86_64-redhat-linux-gnu is required.
>
> One of our platforms is CentOS 7.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104550: [analyzer] Implement getType for SVal

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D104550#2838827 , @ASDenysPetrov 
wrote:

> I'm in favor of this patch. It will help simplify `SValBuilder::evalCast`, 
> which takes an optional parameter `OriginalTy` and acts differently based on 
> whether it has been passed or has not.

@NoQ mentioned it before that it is always better to use direct types from AST. 
 But the only participant who doesn't have AST is the Store, and when it calls 
`evalCast` it doesn't have a way to get that type.  So, in this case this 
function van be pretty useful.

> Since `sizeof(SVal)` became bigger (x1.5). I'm wondering of how much this 
> reflects on memory consumption.

I'm not sure what you mean here.  If it is about this particular patch, it 
simply adds a non-virtual method to `SVal`, it shouldn't affect `sizeof(SVal)` 
at all.

> Another thing is that we can garantee returning `QualType`. I mean, we can 
> replace `Optional` with `QualType` itself. `QualType` has a default ctor and 
> `isNull` predicate, which is //true// when defaultly constructed.

I wanted to be more explicit here and convey to the user that the lack of type 
is normal.  I can change that, it won't be a problem at all.  @NoQ, @Szelethus 
what do you think?




Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

ASDenysPetrov wrote:
> I'm not sure this is a correct type. I would expect here something like: 
> `class LabelType : public Type`.
I don't think that I fully understood what you suggest here.  Do you suggest to 
add a new type to `Type.h`?



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:181-182
+void foo(int a, int b) {
+  int x = a;
+  int y = a + b;
+})") {

ASDenysPetrov wrote:
> Add a cast case.
Sure!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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

[PATCH] D104831: [clang] Add x86_64-redhat-linux-gnu as a platform triplet

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D104831#2837712 , @MaskRay wrote:

>> Adding the platform tripplet x86_64-redhat-linux-gnu the while list of 
>> supported x86_64 triplets so that it can be used with the --gcc-toolchain 
>> option to bypass this process and force-pick a given gcc install.
>
> Did you set `--target=x86_64-redhat-linux-gnu`? With that I don't think you 
> need another entry in `X86_64Triples`.
>
> `X86_64Triples` and its friends are quite clumsy and many entries are not 
> actually needed. We should shrink the lists.
>
> For https://bugzilla.redhat.com/show_bug.cgi?id=1824365 I think the right fix 
> is to configure clang with x86_64-redhat-linux-gnu as the default triple.

Explicitly specifying target or configure the default build target would work. 
But I thought  the triple vector being updated is designed for automatic 
searching and minimizing configure changes across platforms. Is it not like 
that?

In D104831#2837795 , @tstellar wrote:

> I'm curious, what kind of system are you running on where you need to use 
> --gcc-toolchain x86_64-redhat-linux-gnu is required.

One of our platforms is CentOS 7.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104831

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

[PATCH] D104550: [analyzer] Implement getType for SVal

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

I'm in favor of this patch. It will help simplify `SValBuilder::evalCast`, 
which takes an optional parameter `OriginalTy` and acts differently based on 
whether it has been passed or has not.

Since `sizeof(SVal)` became bigger (x1.5). I'm wondering of how much this 
reflects on memory consumption.

Another thing is that we can garantee returning `QualType`. I mean, we can 
replace `Optional` with `QualType` itself. `QualType` has a default ctor and 
`isNull` predicate, which is //true// when defaultly constructed.




Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:154
+  Optional VisitLocGotoLabel(loc::GotoLabel GL) {
+return QualType{Context.VoidPtrTy};
+  }

I'm not sure this is a correct type. I would expect here something like: `class 
LabelType : public Type`.



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:181-182
+void foo(int a, int b) {
+  int x = a;
+  int y = a + b;
+})") {

Add a cast case.



Comment at: clang/unittests/StaticAnalyzer/SValTest.cpp:190-192
+  SVal Y = getByName("y");
+  ASSERT_TRUE(Y.getType(Context).hasValue());
+  EXPECT_EQ(Int, *Y.getType(Context));




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

Awesome, thanks for swiftly addressing it!




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1981
   for (const SymbolRef  : ClassMembers) {
-SymbolRef SimplifiedMemberSym = ::simplify(State, MemberSym);
+SymbolRef SimplifiedMemberSym = ::clang::ento::simplify(State, MemberSym);
 if (SimplifiedMemberSym && MemberSym != SimplifiedMemberSym) {

Oof, and there is no way to avoid all these namespaces?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

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



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

vsavchenko wrote:
> martong wrote:
> > vsavchenko wrote:
> > > I don't like the idea of duplicating it into every `assume` method.  This 
> > > way we drastically increase our chances to forget it (like you did with 
> > > `assumeSymGE` and `assumeSymLE`).
> > > I think the better place for it is in 
> > > `RangedConstraintManager::assumeSymRel` and neighboring methods, though 
> > > still not perfect.
> > > I don't really get why we get not simplified symbol to begin with.
> > > 
> > `assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also 
> > e.g. from `assumeSymUnsupported`. Perhaps we could change the signature of 
> > `assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper 
> > object instead of `SymbolRef`?
> > 
> > ```
> >   ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
> >   const llvm::APSInt ,
> >   const llvm::APSInt );
> > 
> > ```
> > And for the Simplifier something like:
> > ```
> > struct Simplifier {
> >   SymbolRef SimplifiedSym = nullptr;
> >   Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
> >   
> > };
> > ```
> > 
> > assumeSymRel is not enough, because e.g. assumeSymGE is called also e.g. 
> > from assumeSymUnsupported. 
> Yep, that's why I suggested `assumeSymRel` and its neighbors.  I actually 
> think that three top-level public methods from `RangedConstraintManager` will 
> do: `assumeSym`, `assumeSymInclusiveRange`, and `assumeSymUnsupported`.
> 
> 
> We can't really change the signatures of those methods because we'll be 
> introducing this functionality into solvers that didn't sign up for this (and 
> don't need it).
> 
> Also we can least put this `if` statement inside of `simplify`, so we can use 
> it like this: `Sym = simplify(St, Sym);`.
Okay, I've updated like so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 354274.
martong added a comment.

- Use simplify from RangedConstraintManager


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  clang/test/Analysis/solver-sym-simplification-no-crash.c
  clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c

Index: clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-with-proper-range-type.c
@@ -0,0 +1,29 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here we test that the range based solver equivalency tracking mechanism
+// assigns a properly typed range to the simplified symbol.
+
+void clang_analyzer_printState();
+void clang_analyzer_eval(int);
+
+void f(int a0, int b0, int c)
+{
+int a1 = a0 - b0;
+int b1 = (unsigned)a1 + c;
+if (c == 0) {
+
+int d = 7L / b1; // ...
+// At this point b1 is considered non-zero, which results in a new
+// constraint for $a0 - $b0 + $c. The type of this sym is unsigned,
+// however, the simplified sym is $a0 - $b0 and its type is signed.
+// This is probably the result of the inherent improper handling of
+// casts. Anyway, Range assignment for constraints use this type
+// information. Therefore, we must make sure that first we simplify the
+// symbol and only then we assign the range.
+
+clang_analyzer_eval(a0 - b0 != 0); // expected-warning{{TRUE}}
+}
+}
Index: clang/test/Analysis/solver-sym-simplification-no-crash.c
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-no-crash.c
@@ -0,0 +1,26 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+// Here, we test that symbol simplification in the solver does not produce any
+// crashes.
+
+// expected-no-diagnostics
+
+static int a, b;
+static long c;
+
+static void f(int i, int j)
+{
+(void)(j <= 0 && i ? i : j);
+}
+
+static void g(void)
+{
+int d = a - b | (c < 0);
+for (;;)
+{
+f(d ^ c, c);
+}
+}
Index: clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
@@ -23,12 +23,14 @@
 ProgramStateRef RangedConstraintManager::assumeSym(ProgramStateRef State,
SymbolRef Sym,
bool Assumption) {
+  Sym = simplify(State, Sym);
+
   // Handle SymbolData.
-  if (isa(Sym)) {
+  if (isa(Sym))
 return assumeSymUnsupported(State, Sym, Assumption);
 
-// Handle symbolic expression.
-  } else if (const SymIntExpr *SIE = dyn_cast(Sym)) {
+  // Handle symbolic expression.
+  if (const SymIntExpr *SIE = dyn_cast(Sym)) {
 // We can only simplify expressions whose RHS is an integer.
 
 BinaryOperator::Opcode op = SIE->getOpcode();
@@ -93,6 +95,9 @@
 ProgramStateRef RangedConstraintManager::assumeSymInclusiveRange(
 ProgramStateRef State, SymbolRef Sym, const llvm::APSInt ,
 const llvm::APSInt , bool InRange) {
+
+  Sym = simplify(State, Sym);
+
   // Get the type used for calculating wraparound.
   BasicValueFactory  = getBasicVals();
   APSIntType WraparoundType = BVF.getAPSIntType(Sym->getType());
@@ -121,6 +126,8 @@
 ProgramStateRef
 RangedConstraintManager::assumeSymUnsupported(ProgramStateRef State,
   SymbolRef Sym, bool Assumption) {
+  Sym = simplify(State, Sym);
+
   BasicValueFactory  = getBasicVals();
   QualType T = Sym->getType();
 
@@ -219,5 +226,13 @@
   }
 }
 
+SymbolRef simplify(ProgramStateRef State, SymbolRef Sym) {
+  SValBuilder  = State->getStateManager().getSValBuilder();
+  SVal SimplifiedVal = SVB.simplifySVal(State, SVB.makeSymbolVal(Sym));
+  if (SymbolRef SimplifiedSym = SimplifiedVal.getAsSymbol())
+return SimplifiedSym;
+  return Sym;
+}
+
 } // end of namespace ento
 } // end of namespace clang
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1389,12 +1389,6 @@
 //  Constraint manager implementation details
 

[PATCH] D102507: [HIP] Support in device code

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D102507#2833594 , @ldionne wrote:

> In D102507#2830688 , @yaxunl wrote:
>
>> In D102507#2792087 , @rsmith wrote:
>>
>>> @ldionne How should we go about establishing whether libc++ would be 
>>> prepared to officially support CUDA? Right now, Clang's CUDA support is 
>>> patching in attributes onto libc++ functions from the outside, which 
>>> doesn't seem like a sustainable model.
>>
>> ping
>
> If the current approach is to patch libc++ from the outside, then yeah, 
> that's most definitely not a great design IMO. It's going to be very brittle. 
> I think it *may* be reasonable to support this in libc++, but I'd like to see 
> some sort of basic explanation of what the changes would be so we can have a 
> discussion and make our mind up about whether we can support this, and what's 
> the best way of doing it.

Thanks Louis. Please allow me to have a brief explanation about our plan to 
support libc++ for HIP device compilation.

HIP functions can have `__device__`, `__host__`, or `__device__ __host__` 
attributes, indicating the target of a function. `__device__` function can only 
be executed on device (GPU). `__host__` functions can only be executed on host. 
`__device__ __host__` functions can be executed on both device and host. By 
default (without explicit device/host attributes) a non-constexpr function is a 
host function, a constexpr function is `__device__ __host__` function. This 
also applies to member functions of class. Clang is able to resolve overloaded 
functions differing only by device/function attributes.

Currently libc++ functions are host functions by default, except constexpr 
functions. As such the non-constexpr libc++ functions can only be called by 
host functions in HIP programs. This is similar to C++ programs.

By supporting libc++ in HIP device compilation we mean "allowing libc++ 
functions to be executed on device in HIP programs". To achieve this we can 
take 3 approaches:

1. Many libc++ functions are generic regarding device or host, i.e., their code 
is common for device and host. For such functions we can make them `__device__ 
__host__` functions.

2. Some libc++ functions are mostly common for device or host with minor 
differences. For such functions, we can make them `__device__ __host__` and use 
`#if __HIP_DEVICE_COMPILE__` (indicating device compilation) for the minor 
difference in the function body.

3. Some libc++ functions have different implementations for device and host. We 
can leave these host functions as they are and adding overloaded `__device__` 
functions.

There are two ways to mark libc++ functions as `__device__ __host__`:

1. Define a macro which expands to empty for non-HIP programs and expands to 
`__device__ __host__` for HIP and add it to each libc++ function which is to be 
marked as `__device__ __host__`.

2. Define macros which expand to empty for non-HIP programs and expand to 
`#pragma clang force_cuda_host_device begin/end` for HIP and put them at the 
beginning and end of a file where all the functions are to be marked as 
`__device__ __host__`.

We plan to implement libc++ support in HIP device compilation in a progressive 
approach, header by header, and document the supported libc++ headers. We will 
prioritize libc++ headers to support based on 1) user requests 2) whether it 
has already been supported through clang wrapper headers (patching) 4) 
usefulness for device execution 3) availability of lower level support with HIP 
runtime.


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

https://reviews.llvm.org/D102507

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

Doesn't gcc also fold isnan to false under fast math? If we diverge here that 
means your code would only work correctly with clang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert accepted this revision.
jdoerfert added a comment.

Looks reasonable to me. We can always refine it as we go.




Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:137
+///  * GPUArch (Optional) - Processor name, like gfx906 or sm_30
+/// In presence of Proc, the Triple should contain separator "-" for all
+/// standard four components, even if they are empty.





Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:1263
+
+  assert(!ArchiveErr);
+

Add a message to asserts. also other places.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D104854#2838659 , @jdoerfert wrote:

> In D104854#2838495 , @sepavloff 
> wrote:
>
>> In D104854#2838468 , @thopre wrote:
>>
>>> Are you planning to do this for the other FP test builtin (isinf, isfinite, 
>>> isinf_sign, isnormal)?
>>
>> Yes, they have similar problems. 
>> If someone would like to implement them it would be nice.
>
> From a user perspective, it seems sub-optimal to postpone the others "untile 
> someone wants to implement them".
> Once `isnan` behaves differently than the rest, I can see users being 
> confused and rightfully so.
> I don't have a strong opinion but I'd prefer we switch them over together.

Sure. I Just want to say that if someone wants or has plans to implement these 
functions, I appreciate these efforts. This functionality is in my plans. 
Considering only one function in this patch must facilitatу the review process.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D104844#2838674 , @martong wrote:

>> I don't really get why we get not simplified symbol to begin with.
>
> This is because of the Environment bindings. I.e.` b1` is bound to `$a0 - $b0 
> + $c` when we evaluate `int b1 = (unsigned)a1 + c;`. This binding is not 
> changed/updated, so when we evaluate the division then we query the 
> DeclRefExpr for `b1` from the Environment and that gives still `$a0 - $b0 + 
> $c`. We either do the simplification in the ConstraintManager (as we do now 
> with this and the parent patch) or perhaps we could try to simplify the 
> Environment bindings as an alternative solution.

Yeah, I remember now, thanks!




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

martong wrote:
> vsavchenko wrote:
> > I don't like the idea of duplicating it into every `assume` method.  This 
> > way we drastically increase our chances to forget it (like you did with 
> > `assumeSymGE` and `assumeSymLE`).
> > I think the better place for it is in 
> > `RangedConstraintManager::assumeSymRel` and neighboring methods, though 
> > still not perfect.
> > I don't really get why we get not simplified symbol to begin with.
> > 
> `assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also e.g. 
> from `assumeSymUnsupported`. Perhaps we could change the signature of 
> `assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper object 
> instead of `SymbolRef`?
> 
> ```
>   ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
>   const llvm::APSInt ,
>   const llvm::APSInt );
> 
> ```
> And for the Simplifier something like:
> ```
> struct Simplifier {
>   SymbolRef SimplifiedSym = nullptr;
>   Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
>   
> };
> ```
> 
> assumeSymRel is not enough, because e.g. assumeSymGE is called also e.g. from 
> assumeSymUnsupported. 
Yep, that's why I suggested `assumeSymRel` and its neighbors.  I actually think 
that three top-level public methods from `RangedConstraintManager` will do: 
`assumeSym`, `assumeSymInclusiveRange`, and `assumeSymUnsupported`.


We can't really change the signatures of those methods because we'll be 
introducing this functionality into solvers that didn't sign up for this (and 
don't need it).

Also we can least put this `if` statement inside of `simplify`, so we can use 
it like this: `Sym = simplify(St, Sym);`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

> I don't really get why we get not simplified symbol to begin with.

This is because of the Environment bindings. I.e.` b1` is bound to `$a0 - $b0 + 
$c` when we evaluate `int b1 = (unsigned)a1 + c;`. This binding is not 
changed/updated, so when we evaluate the division then we query the DeclRefExpr 
for `b1` from the Environment and that gives still `$a0 - $b0 + $c`. We either 
do the simplification in the ConstraintManager (as we do now with this and the 
parent patch) or perhaps we could try to simplify the Environment bindings as 
an alternative solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha closed this revision.
SaurabhJha added a comment.

This is closed by this commit 
https://github.com/llvm/llvm-project/commit/cd256c8bcc9723f0ce7a32957f26600c966fa07c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

In D104198#2838665 , @fhahn wrote:

> In D104198#2838658 , @SaurabhJha 
> wrote:
>
>> Sorry, I committed this without the `Differential Revision: 
>> https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
>> message after it is in main? I could not push after `git commit --amend`
>
> There's no way to adjust an already pushed commit (force pushes are blocked). 
> You could either revert the change and re-commit with the updated wording or 
> you could manually close the revision here. If the rest of the commit message 
> is OK, I'd recommend just closing the revision manually and provide a link to 
> the commit.

Okay thanks, I will do the latter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D90399: [clang-tidy] non-portable-integer-constant check

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

steakhal added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:54
+
+MaskStr = StringRef(MaskStr.lower());
+if (!MaskStr.consume_front("0x"))

You are assigning a pointer to a temporal std::string. It will dangle.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/NonportableintegerconstantCheck.cpp:58
+
+MaskStr = MaskStr.take_while(llvm::isHexDigit);
+

There could be digit separator apostrophes. E.g.: `0x44'4'4`.


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

https://reviews.llvm.org/D90399

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

In D104198#2838658 , @SaurabhJha 
wrote:

> Sorry, I committed this without the `Differential Revision: 
> https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
> message after it is in main? I could not push after `git commit --amend`

There's no way to adjust an already pushed commit (force pushes are blocked). 
You could either revert the change and re-commit with the updated wording or 
you could manually close the revision here. If the rest of the commit message 
is OK, I'd recommend just closing the revision manually and provide a link to 
the commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104844: [Analyzer][solver] Fix crashes during symbol simplification

[Gabor Marton via Phabricator via cfe-commits]

martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2314-2315
 
+  if (SymbolRef SimplifiedSym = simplify(St, Sym))
+Sym = SimplifiedSym;
+

vsavchenko wrote:
> I don't like the idea of duplicating it into every `assume` method.  This way 
> we drastically increase our chances to forget it (like you did with 
> `assumeSymGE` and `assumeSymLE`).
> I think the better place for it is in `RangedConstraintManager::assumeSymRel` 
> and neighboring methods, though still not perfect.
> I don't really get why we get not simplified symbol to begin with.
> 
`assumeSymRel` is not enough, because e.g. `assumeSymGE` is called also e.g. 
from `assumeSymUnsupported`. Perhaps we could change the signature of 
`assumeSymEQ/NE/GT/GE/LT/LE` to take an auxiliary `Simplifier` wrapper object 
instead of `SymbolRef`?

```
  ProgramStateRef assumeSymNE(ProgramStateRef State, Simplifier S,
  const llvm::APSInt ,
  const llvm::APSInt );

```
And for the Simplifier something like:
```
struct Simplifier {
  SymbolRef SimplifiedSym = nullptr;
  Simplifier(SymbolRef Sym) : SimplifiedSym(simplify(Sym)) {}
  
};
```



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104844

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a comment.

In D104797#2838653 , @tlively wrote:

> The opaque pointers project is documented here: 
> https://llvm.org/docs/OpaquePointers.html. It's been making very slow 
> progress for the past few years but has recently been picking up steam under 
> the direction of @aeubanks. Search llvm-dev for "opaque pointers" and you 
> will see a few recent threads about it.

Thanks for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D104854#2838495 , @sepavloff wrote:

> In D104854#2838468 , @thopre wrote:
>
>> Are you planning to do this for the other FP test builtin (isinf, isfinite, 
>> isinf_sign, isnormal)?
>
> Yes, they have similar problems. 
> If someone would like to implement them it would be nice.

From a user perspective, it seems sub-optimal to postpone the others "untile 
someone wants to implement them".
Once `isnan` behaves differently than the rest, I can see users being confused 
and rightfully so.
I don't have a strong opinion but I'd prefer we switch them over together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D104198: [Matrix] Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via Phabricator via cfe-commits]

SaurabhJha added a comment.

Sorry, I committed this without the `Differential Revision: 
https://reviews.llvm.org/D104198` line. Is there a way to change the commit 
message after it is in main? I could not push after `git commit --amend`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104198

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Thomas Lively via Phabricator via cfe-commits]

tlively added a subscriber: aeubanks.
tlively added a comment.

The opaque pointers project is documented here: 
https://llvm.org/docs/OpaquePointers.html. It's been making very slow progress 
for the past few years but has recently been picking up steam under the 
direction of @aeubanks. Search llvm-dev for "opaque pointers" and you will see 
a few recent threads about it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[clang] cd256c8 - Add documentation for compound assignment and type conversion of matrix types

[Saurabh Jha via cfe-commits]

Author: Saurabh Jha
Date: 2021-06-24T15:50:58+01:00
New Revision: cd256c8bcc9723f0ce7a32957f26600c966fa07c

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

LOG: Add documentation for compound assignment and type conversion of matrix 
types

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index c60b8b39e1c9e..f9e1208634b91 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -523,6 +523,63 @@ float matrices and add the result to a third 4x4 matrix.
 return a + b * c;
   }
 
+The matrix type extension also supports operations on a matrix and a scalar.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+return (a + 23) * 12;
+  }
+
+The matrix type extension supports division on a matrix and a scalar but not 
on a matrix and a matrix.
+
+.. code-block:: c++
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a) {
+a = a / 3.0;
+return a;
+  }
+
+The matrix type extension supports compound assignments for addition, 
subtraction, and multiplication between matrices
+and between a matrix and a scalar, provided their types are consistent.
+
+.. code-block:: c++
+
+  typedef float m4x4_t __attribute__((matrix_type(4, 4)));
+
+  m4x4_t f(m4x4_t a, m4x4_t b) {
+a += b;
+a -= b;
+a *= b;
+a += 23;
+a -= 12;
+return a;
+  }
+
+The matrix type extension supports explicit casts. Implicit type conversion 
between matrix types is not allowed.
+
+.. code-block:: c++
+
+  typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+  typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+
+  fx5x5 f1(ix5x5 i, fx5x5 f) {
+return (fx5x5) i;
+  }
+
+
+  template 
+  using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+  void f2() {
+matrix_5_5 d;
+matrix_5_5 i;
+i = (matrix_5_5)d;
+i = static_cast>(d);
+  }
 
 Half-Precision Floating Point
 =



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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a comment.

In D104797#2837417 , @tlively wrote:

> In D104797#2836475 , @pmatos wrote:
>
>> @tlively Do you think it would be ok to re-add the code removed in 
>> `ac81cb7e` but only error if the pointer is to an **opaque** non-integral 
>> type?
>
> Unfortunately that wouldn't be future-proof given the ongoing project to 
> remove type information from pointers. I think the best we can do right now 
> is call `report_fatal_error` from the backend whenever a reference type is 
> the operand or result of ptrtoint or inttoptr.

Which 'ongoing project' is this and how can I obtain more information about it? 
Who's leading it?
Before the crashing, the only place we seem to touch the Wasm backend is in 
`WebAssemblyDAGToDAGISel::runOnMachineFunction`. Then this calls 
`SelectionDAGISel::runOnMachineFunction`, which visits each node in the 
Function and crashes when trying to call `getPtrExtOrTrunc` because it cannot 
create a `TRUNCATE` node for a zero sized type. So, if you prefer to have a 
`report_fatal_error` in the WebAssembly backend, we will need to visit the 
nodes in the function in `WebAssemblyDAGToDAGISel::runOnMachineFunction` before 
calling the generic `runOnMachineFunction`. I will look at how to proceed in 
this direction, but I am also interested in following this project on removing 
type information from pointers in LLVM, so any refs would be great. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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