[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.

LGTM, too.  Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79059: Fix and re-submit D78534 - [libclang] Install both libclang.a and libclang.so when LIBCLANG_BUILD_STATIC=ON

2020-05-05 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai accepted this revision.
smeenai added a comment.
This revision is now accepted and ready to land.

Sorry for the delayed review here.

I'm not the biggest fan of this cos it's encoding knowledge of 
`llvm_add_library`'s internal behavior (that it creates a `*_static` target if 
both STATIC and SHARED are passed) inside `add_clang_library`, so that if 
someone changes `llvm_add_library`, they might break `add_clang_library` 
without realizing it. However, it looks like a bunch of other places in the 
build also assume the `_static` suffix, so we already have that problem today, 
and this is fine.




Comment at: clang/cmake/modules/AddClang.cmake:107
+  if(ARG_SHARED AND ARG_STATIC)
+set(libs ${name} ${name}_static)
   endif()

Super nit: you can do `list(APPEND libs ${name}_static)` instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79059



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


[PATCH] D79451: [libclang] Remove duplicate dependency on LLVMSupport

2020-05-05 Thread Jan Korous via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG02b303321d3f: [libclang] Remove duplicate dependency on 
LLVMSupport (authored by jkorous).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79451

Files:
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -44,7 +44,6 @@
   clangSema
   clangSerialization
   clangTooling
-  LLVMSupport
 )
 
 if (CLANG_ENABLE_ARCMT)


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -44,7 +44,6 @@
   clangSema
   clangSerialization
   clangTooling
-  LLVMSupport
 )
 
 if (CLANG_ENABLE_ARCMT)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79448: [X86] Allow Yz inline assembly constraint to choose ymm0 or zmm0 when avx/avx512 are enabled and type is 256 or 512 bits

2020-05-05 Thread Craig Topper via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0fac1c191281: [X86] Allow Yz inline assembly constraint to 
choose ymm0 or zmm0 when… (authored by craig.topper).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D79448?vs=262233=262289#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79448

Files:
  clang/lib/Basic/Targets/X86.cpp
  clang/test/CodeGen/x86-inline-asm-v-constraint.c
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
  llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll

Index: llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
===
--- llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
+++ llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
@@ -70,3 +70,12 @@
   ret <16 x float> %0
 }
 
+define <16 x float> @testZMM0() {
+entry:
+; CHECK: vpternlogd $255, %zmm0, %zmm0, %zmm0
+  %zmm0 = alloca <16 x float>, align 64
+  %0 = call <16 x float> asm "vpternlogd $$255, $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+  store <16 x float> %0, <16 x float>* %zmm0, align 64
+  %1 = load <16 x float>, <16 x float>* %zmm0, align 64
+  ret <16 x float> %1
+}
Index: llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
===
--- llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
+++ llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
@@ -134,3 +134,13 @@
   ret <8 x float> %0
 }
 
+define <8 x float> @testYMM0() {
+; CHECK: vpcmpeqd %ymm0, %ymm0, %ymm0
+entry:
+  %ymm0 = alloca <8 x float>, align 32
+  %0 = call <8 x float> asm "vpcmpeqd $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+  store <8 x float> %0, <8 x float>* %ymm0, align 32
+  %1 = load <8 x float>, <8 x float>* %ymm0, align 32
+  ret <8 x float> %1
+}
+
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -48046,7 +48046,9 @@
   // XMM0
   case 'z':
   case '0':
-if ((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1())
+if (((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1()) ||
+((type->getPrimitiveSizeInBits() == 256) && Subtarget.hasAVX()) ||
+((type->getPrimitiveSizeInBits() == 512) && Subtarget.hasAVX512()))
   return CW_SpecificReg;
 return CW_Invalid;
   // Conditional OpMask regs (AVX512)
@@ -48496,6 +48498,8 @@
 if (Subtarget.hasAVX())
   return std::make_pair(0U, ::VR256RegClass);
 break;
+  case MVT::v64i8:
+  case MVT::v32i16:
   case MVT::v8f64:
   case MVT::v16f32:
   case MVT::v16i32:
@@ -48521,7 +48525,42 @@
 case 'z':
 case '0':
   if (!Subtarget.hasSSE1()) break;
-  return std::make_pair(X86::XMM0, ::VR128RegClass);
+  switch (VT.SimpleTy) {
+  default: break;
+  // Scalar SSE types.
+  case MVT::f32:
+  case MVT::i32:
+return std::make_pair(X86::XMM0, ::FR32RegClass);
+  case MVT::f64:
+  case MVT::i64:
+return std::make_pair(X86::XMM0, ::FR64RegClass);
+  case MVT::f128:
+  case MVT::v16i8:
+  case MVT::v8i16:
+  case MVT::v4i32:
+  case MVT::v2i64:
+  case MVT::v4f32:
+  case MVT::v2f64:
+return std::make_pair(X86::XMM0, ::VR128RegClass);
+  // AVX types.
+  case MVT::v32i8:
+  case MVT::v16i16:
+  case MVT::v8i32:
+  case MVT::v4i64:
+  case MVT::v8f32:
+  case MVT::v4f64:
+if (Subtarget.hasAVX())
+  return std::make_pair(X86::YMM0, ::VR256RegClass);
+break;
+  case MVT::v8f64:
+  case MVT::v16f32:
+  case MVT::v16i32:
+  case MVT::v8i64:
+if (Subtarget.hasAVX512())
+  return std::make_pair(X86::ZMM0, ::VR512_0_15RegClass);
+break;
+  }
+  break;
 case 'k':
   // This register class doesn't allocate k0 for masked vector operation.
   if (Subtarget.hasAVX512()) {
Index: clang/test/CodeGen/x86-inline-asm-v-constraint.c
===
--- clang/test/CodeGen/x86-inline-asm-v-constraint.c
+++ clang/test/CodeGen/x86-inline-asm-v-constraint.c
@@ -28,3 +28,28 @@
 #endif
   return _zmm0;
 }
+
+// SSE: call <4 x float> asm "pcmpeqd $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m128 testXMM0(void) {
+  __m128 xmm0;
+  __asm__("pcmpeqd %0, %0" :"=Yz"(xmm0));
+  return xmm0;
+}
+
+// AVX: call <8 x float> asm "vpcmpeqd $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m256 testYMM0(void) {
+  __m256 ymm0;
+#ifdef AVX
+  __asm__("vpcmpeqd %0, %0, %0" :"=Yz"(ymm0));
+#endif
+  return ymm0;
+}
+
+// AVX512: call <16 x float> 

[PATCH] D71687: Fix full loop unrolling initialization in new pass manager

2020-05-05 Thread Chandler Carruth via Phabricator via cfe-commits
chandlerc added a comment.

Wooot about finally having a test case! (Sorry for nit picking it a bit )




Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:4-6
+; We don't end up deleting the loop, but we remove everything inside of it so 
checking for any
+; reasonable instruction from the original loop will work.
+; CHECK-NOT: br i1

Make sure it is in the correct function at least, and maybe after the label for 
the loop header?



Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:12-17
+; Function Attrs: noinline optnone uwtable
+define dso_local void @_Z3Runv() #0 {
+entry:
+  call void @_Z6Helperv()
+  ret void
+}

Are both functions needed?



Comment at: llvm/test/Transforms/LoopUnroll/FullUnroll.ll:19-20
+
+; Function Attrs: noinline nounwind optnone uwtable
+define linkonce_odr dso_local void @_Z6Helperv() #1 comdat {
+entry:

Nit, but minimize and clean this function up a touch?

At the least, removing all the target features seems valuable, and I'd give 
things stable names instead of numbered values.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71687



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


[clang] 02b3033 - [libclang] Remove duplicate dependency on LLVMSupport

2020-05-05 Thread Jan Korous via cfe-commits

Author: Jan Korous
Date: 2020-05-05T21:31:07-07:00
New Revision: 02b303321d3f0d3b2c69f68aa25560848dd61f98

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

LOG: [libclang] Remove duplicate dependency on LLVMSupport

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

Added: 


Modified: 
clang/tools/libclang/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index f56771b8a594..4f0eec9e6016 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -44,7 +44,6 @@ set(LIBS
   clangSema
   clangSerialization
   clangTooling
-  LLVMSupport
 )
 
 if (CLANG_ENABLE_ARCMT)



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


[clang] 0fac1c1 - [X86] Allow Yz inline assembly constraint to choose ymm0 or zmm0 when avx/avx512 are enabled and type is 256 or 512 bits

2020-05-05 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2020-05-05T21:12:30-07:00
New Revision: 0fac1c19128106b6d65d349a5ed22fedacab520c

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

LOG: [X86] Allow Yz inline assembly constraint to choose ymm0 or zmm0 when 
avx/avx512 are enabled and type is 256 or 512 bits

gcc supports selecting ymm0/zmm0 for the Yz constraint when used with 256 or 
512 bit vector types.

Fixes PR45806

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

Added: 


Modified: 
clang/lib/Basic/Targets/X86.cpp
clang/test/CodeGen/x86-inline-asm-v-constraint.c
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll

Removed: 




diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index 747d07692fee..b0fecd6fd1c1 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -1898,8 +1898,14 @@ bool X86TargetInfo::validateOperandSize(const 
llvm::StringMap ,
   return Size <= 64;
 case 'z':
 case '0':
-  // XMM0
-  if (FeatureMap.lookup("sse"))
+  // XMM0/YMM/ZMM0
+  if (FeatureMap.lookup("avx512f"))
+// ZMM0 can be used if target supports AVX512F.
+return Size <= 512U;
+  else if (FeatureMap.lookup("avx"))
+// YMM0 can be used if target supports AVX.
+return Size <= 256U;
+  else if (FeatureMap.lookup("sse"))
 return Size <= 128U;
   return false;
 case 'i':

diff  --git a/clang/test/CodeGen/x86-inline-asm-v-constraint.c 
b/clang/test/CodeGen/x86-inline-asm-v-constraint.c
index d335e4b6a0f7..215cccfa443e 100644
--- a/clang/test/CodeGen/x86-inline-asm-v-constraint.c
+++ b/clang/test/CodeGen/x86-inline-asm-v-constraint.c
@@ -28,3 +28,28 @@ __m512 testZMM(__m512 _zmm0, __m512 _zmm1) {
 #endif
   return _zmm0;
 }
+
+// SSE: call <4 x float> asm "pcmpeqd $0, $0", 
"=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m128 testXMM0(void) {
+  __m128 xmm0;
+  __asm__("pcmpeqd %0, %0" :"=Yz"(xmm0));
+  return xmm0;
+}
+
+// AVX: call <8 x float> asm "vpcmpeqd $0, $0, $0", 
"=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m256 testYMM0(void) {
+  __m256 ymm0;
+#ifdef AVX
+  __asm__("vpcmpeqd %0, %0, %0" :"=Yz"(ymm0));
+#endif
+  return ymm0;
+}
+
+// AVX512: call <16 x float> asm "vpternlogd $$255, $0, $0, $0", 
"=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m512 testZMM0(void) {
+  __m512 zmm0;
+#ifdef AVX512
+  __asm__("vpternlogd $255, %0, %0, %0" :"=Yz"(zmm0));
+#endif
+  return zmm0;
+}

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index 57db959a6743..35c6d24ff80a 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -48046,7 +48046,9 @@ TargetLowering::ConstraintWeight
   // XMM0
   case 'z':
   case '0':
-if ((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1())
+if (((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1()) ||
+((type->getPrimitiveSizeInBits() == 256) && Subtarget.hasAVX()) ||
+((type->getPrimitiveSizeInBits() == 512) && Subtarget.hasAVX512()))
   return CW_SpecificReg;
 return CW_Invalid;
   // Conditional OpMask regs (AVX512)
@@ -48496,6 +48498,8 @@ X86TargetLowering::getRegForInlineAsmConstraint(const 
TargetRegisterInfo *TRI,
 if (Subtarget.hasAVX())
   return std::make_pair(0U, ::VR256RegClass);
 break;
+  case MVT::v64i8:
+  case MVT::v32i16:
   case MVT::v8f64:
   case MVT::v16f32:
   case MVT::v16i32:
@@ -48521,7 +48525,42 @@ X86TargetLowering::getRegForInlineAsmConstraint(const 
TargetRegisterInfo *TRI,
 case 'z':
 case '0':
   if (!Subtarget.hasSSE1()) break;
-  return std::make_pair(X86::XMM0, ::VR128RegClass);
+  switch (VT.SimpleTy) {
+  default: break;
+  // Scalar SSE types.
+  case MVT::f32:
+  case MVT::i32:
+return std::make_pair(X86::XMM0, ::FR32RegClass);
+  case MVT::f64:
+  case MVT::i64:
+return std::make_pair(X86::XMM0, ::FR64RegClass);
+  case MVT::f128:
+  case MVT::v16i8:
+  case MVT::v8i16:
+  case MVT::v4i32:
+  case MVT::v2i64:
+  case MVT::v4f32:
+  case MVT::v2f64:
+return std::make_pair(X86::XMM0, ::VR128RegClass);
+  // AVX types.
+  case MVT::v32i8:
+  case MVT::v16i16:
+  case MVT::v8i32:
+  case MVT::v4i64:
+  case MVT::v8f32:
+  case MVT::v4f64:
+if (Subtarget.hasAVX())
+  return std::make_pair(X86::YMM0, ::VR256RegClass);
+break;
+  case MVT::v8f64:
+  case MVT::v16f32:
+  case MVT::v16i32:
+  case MVT::v8i64:
+if 

[PATCH] D79465: Fix line lengths w/ comments in align

2020-05-05 Thread Jake Merdich via Phabricator via cfe-commits
JakeMerdichAMD added a project: clang-format.
JakeMerdichAMD added reviewers: MyDeveloperDay, krasimir, VelocityRa, 
sylvestre.ledru, sammccall, enyquist.
JakeMerdichAMD added a comment.

The failing case in this commit looks like the following after formatting (with 
alignconsecutiveassignments and a specific column limit)

  int x = 0;
  int yy = 1; ///specificlennospace
  int zzz = 2;

See PR43845 for more failing cases besides this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79465



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


[PATCH] D74813: Function block naming - add hash of parameter type to end of block name

2020-05-05 Thread Alex Borcan via Phabricator via cfe-commits
alexbdv updated this revision to Diff 262281.

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

https://reviews.llvm.org/D74813

Files:
  clang/lib/AST/Mangle.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/blocks-irgen.mm
  clang/test/CodeGen/block-with-perdefinedexpr.cpp
  clang/test/CodeGen/blocks.c
  clang/test/CodeGen/debug-info-block-vars.c
  clang/test/CodeGen/func-in-block.c
  clang/test/CodeGen/mangle-blocks.c
  clang/test/CodeGenCXX/block-byref.cpp
  clang/test/CodeGenCXX/blocks.cpp
  clang/test/CodeGenCXX/debug-info-block-invocation-linkage-name.cpp
  clang/test/CodeGenCXX/predefined-expr-cxx14.cpp
  clang/test/CodeGenObjC/blocks-2.m
  clang/test/CodeGenObjC/blocks.m
  clang/test/CodeGenObjC/debug-info-block-line.m
  clang/test/CodeGenObjC/debug-info-nested-blocks.m
  clang/test/CodeGenObjC/mangle-blocks.m
  clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm
  clang/test/CodeGenObjCXX/block-default-arg.mm
  clang/test/CodeGenObjCXX/lambda-expressions.mm
  clang/test/CodeGenObjCXX/mangle-blocks.mm
  clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
  clang/test/CodeGenOpenCL/blocks.cl
  clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
  clang/test/PCH/block-helpers.cpp
  clang/test/PCH/no-escaping-block-tail-calls.cpp
  clang/test/Profile/Inputs/objc-general.proftext
  clang/test/Profile/objc-general.m

Index: clang/test/Profile/objc-general.m
===
--- clang/test/Profile/objc-general.m
+++ clang/test/Profile/objc-general.m
@@ -34,7 +34,7 @@
 #endif
 
 // PGOGEN: @[[FRC:"__profc_objc_general.m_\+\[A foreach_\]"]] = private global [2 x i64] zeroinitializer
-// PGOGEN: @[[BLC:"__profc_objc_general.m___13\+\[A foreach_\]_block_invoke"]] = private global [2 x i64] zeroinitializer
+// PGOGEN: @[[BLC:"__profc_objc_general.m___13\+\[A foreach_\]_block_invoke_7636"]] = private global [2 x i64] zeroinitializer
 // PGOGEN: @[[MAC:__profc_main]] = private global [1 x i64] zeroinitializer
 
 @interface A : NSObject
@@ -52,8 +52,8 @@
   // PGOUSE: br {{.*}} !prof ![[FR1:[0-9]+]]
   // PGOUSE: br {{.*}} !prof ![[FR2:[0-9]+]]
   for (id x in array) {
-// PGOGEN: define {{.*}}_block_invoke
-// PGOUSE: define {{.*}}_block_invoke
+// PGOGEN: define {{.*}}_block_invoke_7636
+// PGOUSE: define {{.*}}_block_invoke_7636
 // PGOGEN: store {{.*}} @[[BLC]], i64 0, i64 0
 ^{ static int init = 0;
   // PGOGEN: store {{.*}} @[[BLC]], i64 0, i64 1
Index: clang/test/Profile/Inputs/objc-general.proftext
===
--- clang/test/Profile/Inputs/objc-general.proftext
+++ clang/test/Profile/Inputs/objc-general.proftext
@@ -1,4 +1,4 @@
-objc-general.m:__13+[A foreach:]_block_invoke
+objc-general.m:__13+[A foreach:]_block_invoke_7636
 42129
 2
 2
Index: clang/test/PCH/no-escaping-block-tail-calls.cpp
===
--- clang/test/PCH/no-escaping-block-tail-calls.cpp
+++ clang/test/PCH/no-escaping-block-tail-calls.cpp
@@ -4,7 +4,7 @@
 // Check that -fno-escaping-block-tail-calls doesn't disable tail-call
 // optimization if the block is non-escaping.
 
-// CHECK-LABEL: define internal i32 @___ZN1S1mEv_block_invoke(
+// CHECK-LABEL: define internal i32 @___ZN1S1mEv_block_invoke_7636(
 // CHECK: %[[CALL:.*]] = tail call i32 @_ZN1S3fooER2S0(
 // CHECK-NEXT: ret i32 %[[CALL]]
 
Index: clang/test/PCH/block-helpers.cpp
===
--- clang/test/PCH/block-helpers.cpp
+++ clang/test/PCH/block-helpers.cpp
@@ -19,7 +19,7 @@
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_BLOCK_BYREF_Y]]* %[[Y]] to i8*
 // CHECK: store i8* %[[V1]], i8** %[[BLOCK_CAPTURED10]], align 8
 
-// CHECK-LABEL: define internal void @___ZN1S1mEv_block_invoke(
+// CHECK-LABEL: define internal void @___ZN1S1mEv_block_invoke_7636(
 
 // The second call to block_object_assign should be an invoke.
 
Index: clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
===
--- clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
+++ clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
@@ -312,7 +312,7 @@
   };
 
   // Uses global block literal [[BLG8]] and invoke function [[INVG8]].
-  // COMMON: call spir_func void @__device_side_enqueue_block_invoke_11(i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BLG8]] to i8 addrspace(1)*) to i8 addrspace(4)*))
+  // COMMON: call spir_func void @__device_side_enqueue_block_invoke_7636.{{[0-9]+}}(i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BLG8]] to i8 addrspace(1)*) to i8 addrspace(4)*))
   block_A();
 
   // Emits global block literal [[BLG8]] and block kernel [[INVGK8]]. [[INVGK8]] calls [[INVG8]].
@@ -331,7 +331,7 @@
   unsigned size = get_kernel_work_group_size(block_A);
 
   // Uses 

[PATCH] D79465: Fix line lengths w/ comments in align

2020-05-05 Thread Jake Merdich via Phabricator via cfe-commits
JakeMerdichAMD created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
JakeMerdichAMD added a project: clang-format.
JakeMerdichAMD added reviewers: MyDeveloperDay, krasimir, VelocityRa, 
sylvestre.ledru, sammccall, enyquist.
JakeMerdichAMD added a comment.

The failing case in this commit looks like the following after formatting (with 
alignconsecutiveassignments and a specific column limit)

  int x = 0;
  int yy = 1; ///specificlennospace
  int zzz = 2;

See PR43845 for more failing cases besides this.


When a '//comment' trails a consecutive alignment, it adds a whitespace
replacement within the comment token. This wasn't handled correctly in
the alignment code, which treats it as a whole token and thus double
counts it.

This can wrongly trigger the "line too long, it'll wrap" alignment-break
condition with specific lengths, causing the alignment to break for
seemingly no reason.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79465

Files:
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11564,6 +11564,16 @@
"  x = 1;\n"
"y = 1;\n",
Alignment);
+
+  Alignment.ReflowComments = true;
+  Alignment.ColumnLimit = 50;
+  EXPECT_EQ("int x   = 0;\n"
+"int yy  = 1; /// specificlennospace\n"
+"int zzz = 2;\n",
+format("int x   = 0;\n"
+   "int yy  = 1; ///specificlennospace\n"
+   "int zzz = 2;\n",
+   Alignment));
 }
 
 TEST_F(FormatTest, AlignConsecutiveDeclarations) {
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -410,8 +410,11 @@
 
 unsigned ChangeMinColumn = Changes[i].StartOfTokenColumn;
 int LineLengthAfter = -Changes[i].Spaces;
-for (unsigned j = i; j != e && Changes[j].NewlinesBefore == 0; ++j)
-  LineLengthAfter += Changes[j].Spaces + Changes[j].TokenLength;
+for (unsigned j = i; j != e && Changes[j].NewlinesBefore == 0; ++j) {
+  LineLengthAfter += Changes[j].Spaces;
+  if (!Changes[j].IsInsideToken)
+LineLengthAfter += Changes[j].TokenLength;
+}
 unsigned ChangeMaxColumn = Style.ColumnLimit - LineLengthAfter;
 
 // If we are restricted by the maximum column width, end the sequence.


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -11564,6 +11564,16 @@
"  x = 1;\n"
"y = 1;\n",
Alignment);
+
+  Alignment.ReflowComments = true;
+  Alignment.ColumnLimit = 50;
+  EXPECT_EQ("int x   = 0;\n"
+"int yy  = 1; /// specificlennospace\n"
+"int zzz = 2;\n",
+format("int x   = 0;\n"
+   "int yy  = 1; ///specificlennospace\n"
+   "int zzz = 2;\n",
+   Alignment));
 }
 
 TEST_F(FormatTest, AlignConsecutiveDeclarations) {
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -410,8 +410,11 @@
 
 unsigned ChangeMinColumn = Changes[i].StartOfTokenColumn;
 int LineLengthAfter = -Changes[i].Spaces;
-for (unsigned j = i; j != e && Changes[j].NewlinesBefore == 0; ++j)
-  LineLengthAfter += Changes[j].Spaces + Changes[j].TokenLength;
+for (unsigned j = i; j != e && Changes[j].NewlinesBefore == 0; ++j) {
+  LineLengthAfter += Changes[j].Spaces;
+  if (!Changes[j].IsInsideToken)
+LineLengthAfter += Changes[j].TokenLength;
+}
 unsigned ChangeMaxColumn = Style.ColumnLimit - LineLengthAfter;
 
 // If we are restricted by the maximum column width, end the sequence.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-05 Thread Steve Canon via Phabricator via cfe-commits
scanon accepted this revision.
scanon added a comment.
This revision is now accepted and ready to land.

My concerns have been addressed. Thanks for bearing with me, Melanie!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-05 Thread Steve Canon via Phabricator via cfe-commits
scanon added a comment.

(Please get one additional sign off before committing; I'm mainly signing off 
on the numerics model aspect).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka requested changes to this revision.
vitalybuka added reviewers: eugenis, glider.
vitalybuka added a comment.
This revision now requires changes to proceed.

In D79445#2021502 , @aeubanks wrote:

> In D79445#2021311 , @leonardchan 
> wrote:
>
> > In `addSanitizersAtO0`, could you make something similar to the `ASanPass` 
> > lambda for the MSan passes and also apply it when adding kernel MSan?
>
>
> It ends up calling an extra 
> `MPM.addPass(createModuleToFunctionPassAdaptor())` in the `KernelMemory` 
> case, is that okay?


Not sure about that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445



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


[PATCH] D74813: Function block naming - add hash of parameter type to end of block name

2020-05-05 Thread Alex Borcan via Phabricator via cfe-commits
alexbdv updated this revision to Diff 262272.
alexbdv marked an inline comment as done.
alexbdv edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813

Files:
  clang/lib/AST/Mangle.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/blocks-irgen.mm
  clang/test/CodeGen/block-with-perdefinedexpr.cpp
  clang/test/CodeGen/blocks.c
  clang/test/CodeGen/debug-info-block-vars.c
  clang/test/CodeGen/func-in-block.c
  clang/test/CodeGen/mangle-blocks.c
  clang/test/CodeGenCXX/block-byref.cpp
  clang/test/CodeGenCXX/blocks.cpp
  clang/test/CodeGenCXX/debug-info-block-invocation-linkage-name.cpp
  clang/test/CodeGenCXX/predefined-expr-cxx14.cpp
  clang/test/CodeGenObjC/blocks-2.m
  clang/test/CodeGenObjC/blocks.m
  clang/test/CodeGenObjC/debug-info-block-line.m
  clang/test/CodeGenObjC/debug-info-nested-blocks.m
  clang/test/CodeGenObjC/mangle-blocks.m
  clang/test/CodeGenObjCXX/arc-forwarded-lambda-call.mm
  clang/test/CodeGenObjCXX/block-default-arg.mm
  clang/test/CodeGenObjCXX/lambda-expressions.mm
  clang/test/CodeGenObjCXX/mangle-blocks.mm
  clang/test/CodeGenOpenCL/amdgpu-enqueue-kernel.cl
  clang/test/CodeGenOpenCL/blocks.cl
  clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
  clang/test/PCH/block-helpers.cpp
  clang/test/PCH/no-escaping-block-tail-calls.cpp
  clang/test/Profile/Inputs/objc-general.proftext
  clang/test/Profile/objc-general.m

Index: clang/test/Profile/objc-general.m
===
--- clang/test/Profile/objc-general.m
+++ clang/test/Profile/objc-general.m
@@ -34,7 +34,7 @@
 #endif
 
 // PGOGEN: @[[FRC:"__profc_objc_general.m_\+\[A foreach_\]"]] = private global [2 x i64] zeroinitializer
-// PGOGEN: @[[BLC:"__profc_objc_general.m___13\+\[A foreach_\]_block_invoke"]] = private global [2 x i64] zeroinitializer
+// PGOGEN: @[[BLC:"__profc_objc_general.m___13\+\[A foreach_\]_block_invoke_7636"]] = private global [2 x i64] zeroinitializer
 // PGOGEN: @[[MAC:__profc_main]] = private global [1 x i64] zeroinitializer
 
 @interface A : NSObject
@@ -52,8 +52,8 @@
   // PGOUSE: br {{.*}} !prof ![[FR1:[0-9]+]]
   // PGOUSE: br {{.*}} !prof ![[FR2:[0-9]+]]
   for (id x in array) {
-// PGOGEN: define {{.*}}_block_invoke
-// PGOUSE: define {{.*}}_block_invoke
+// PGOGEN: define {{.*}}_block_invoke_7636
+// PGOUSE: define {{.*}}_block_invoke_7636
 // PGOGEN: store {{.*}} @[[BLC]], i64 0, i64 0
 ^{ static int init = 0;
   // PGOGEN: store {{.*}} @[[BLC]], i64 0, i64 1
Index: clang/test/Profile/Inputs/objc-general.proftext
===
--- clang/test/Profile/Inputs/objc-general.proftext
+++ clang/test/Profile/Inputs/objc-general.proftext
@@ -1,4 +1,4 @@
-objc-general.m:__13+[A foreach:]_block_invoke
+objc-general.m:__13+[A foreach:]_block_invoke_7636
 42129
 2
 2
Index: clang/test/PCH/no-escaping-block-tail-calls.cpp
===
--- clang/test/PCH/no-escaping-block-tail-calls.cpp
+++ clang/test/PCH/no-escaping-block-tail-calls.cpp
@@ -4,7 +4,7 @@
 // Check that -fno-escaping-block-tail-calls doesn't disable tail-call
 // optimization if the block is non-escaping.
 
-// CHECK-LABEL: define internal i32 @___ZN1S1mEv_block_invoke(
+// CHECK-LABEL: define internal i32 @___ZN1S1mEv_block_invoke_7636(
 // CHECK: %[[CALL:.*]] = tail call i32 @_ZN1S3fooER2S0(
 // CHECK-NEXT: ret i32 %[[CALL]]
 
Index: clang/test/PCH/block-helpers.cpp
===
--- clang/test/PCH/block-helpers.cpp
+++ clang/test/PCH/block-helpers.cpp
@@ -19,7 +19,7 @@
 // CHECK: %[[V1:.*]] = bitcast %[[STRUCT_BLOCK_BYREF_Y]]* %[[Y]] to i8*
 // CHECK: store i8* %[[V1]], i8** %[[BLOCK_CAPTURED10]], align 8
 
-// CHECK-LABEL: define internal void @___ZN1S1mEv_block_invoke(
+// CHECK-LABEL: define internal void @___ZN1S1mEv_block_invoke_7636(
 
 // The second call to block_object_assign should be an invoke.
 
Index: clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
===
--- clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
+++ clang/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
@@ -312,7 +312,7 @@
   };
 
   // Uses global block literal [[BLG8]] and invoke function [[INVG8]].
-  // COMMON: call spir_func void @__device_side_enqueue_block_invoke_11(i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BLG8]] to i8 addrspace(1)*) to i8 addrspace(4)*))
+  // COMMON: call spir_func void @__device_side_enqueue_block_invoke_7636.{{[0-9]+}}(i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i32, i32, i8 addrspace(4)* } addrspace(1)* [[BLG8]] to i8 addrspace(1)*) to i8 addrspace(4)*))
   block_A();
 
   // Emits global block literal [[BLG8]] and block kernel 

[PATCH] D78655: [HIP] Add -fhip-lambda-host-device

2020-05-05 Thread Paul Fultz II via Phabricator via cfe-commits
pfultz2 added a comment.

> A slight variation on that, that might be better: lambdas with no 
> lambda-capture are implicitly HD; lambdas with any lambda-capture (which must 
> therefore have an enclosing function) inherit the enclosing function's HDness.

Lambdas should already inherit the enclosing functions HDness. Keeping 
capturing lambdas as implictly HD matches closer the behavior in HIP/HCC, and 
as we are porting code it is not always clear which lambdas need explicit HD 
annotation since running on the device is an implementation detail.

Capturing lambdas has its pitfalls but they are no different from the same 
pitfalls that happen with asynchronous programming or signal callbacks.




Comment at: clang/lib/Sema/SemaCUDA.cpp:733
+  (Method->isConstexpr() ||
+   (getLangOpts().HIPLambdaHostDevice && !LambdaHasRefCaptures(LI {
+Method->addAttr(CUDADeviceAttr::CreateImplicit(Context));

rsmith wrote:
> The reference captures check seems quite strange to me. A copy capture of a 
> pointer could have the same problem, as could a copy capture of a class that 
> contains a reference or a pointer. As could an init-capture.
> 
> These kinds of quirky language rules are usually more trouble than they're 
> worth.
Capturing by value is not always an error, only when copying a pointer to a 
host variable. but this requires a lot more static analysis to diagnose. 
However, capturing by reference is almost always wrong(at least with the 
current HIP) when the context is host and the lambda is called on the device.

Therefore, we avoid this scenario by not making such lambdas implicitly HD, but 
the error message may not be quite as clear. It is a quirky language rule, and 
we could remove this restriction and rely on a warning or static analysis to 
diagnose the issue.


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

https://reviews.llvm.org/D78655



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


[PATCH] D68049: Propeller: Clang options for basic block sections

2020-05-05 Thread Han Shen via Phabricator via cfe-commits
shenhan added inline comments.



Comment at: lld/ELF/LTO.cpp:80
   // Check if basic block sections must be used.
   // Allowed values for --lto-basicblock-sections are "all", "labels",
   // "", or none.  This is the equivalent

Maybe "--lto-basicblock-sections" should be changed to 
"--lto-basic-block-sections" too?


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

https://reviews.llvm.org/D68049



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


[PATCH] D73307: Unique Names for Functions with Internal Linkage

2020-05-05 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm

Sorry for the delay.


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

https://reviews.llvm.org/D73307



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


[PATCH] D79456: [clangd] Complete filenames after < / ".

2020-05-05 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: adamcz.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.

Extract prefix filters to CodeComplete so it can be easily tested.

Fixes https://github.com/clangd/clangd/issues/366


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79456

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -25,6 +25,7 @@
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Testing/Support/Annotations.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -2828,6 +2829,32 @@
   ElementsAre(AllOf(Qualifier(""), Scope("a::";
 }
 
+TEST(AllowImplicitCompletion, All) {
+  const char *Yes[] = {
+  "foo.^bar",
+  "foo->^bar",
+  "foo::^bar",
+  "  #  include <^foo.h>",
+  "#import ",
+  };
+  const char *No[] = {
+  "foo>^bar",
+  "foo:^bar",
+  "foo\n^bar",
+  "#include  //^",
+  "#include \"foo.h\"^",
+  "#error <^",
+  };
+  for (const char *Test : Yes) {
+llvm::Annotations A(Test);
+EXPECT_TRUE(allowImplicitCompletion(A.code(), A.point())) << Test;
+  }
+  for (const char *Test : No) {
+llvm::Annotations A(Test);
+EXPECT_FALSE(allowImplicitCompletion(A.code(), A.point())) << Test;
+  }
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -11,8 +11,11 @@
 # CHECK-NEXT:"resolveProvider": false,
 # CHECK-NEXT:"triggerCharacters": [
 # CHECK-NEXT:  ".",
+# CHECK-NEXT:  "<",
 # CHECK-NEXT:  ">",
-# CHECK-NEXT:  ":"
+# CHECK-NEXT:  ":",
+# CHECK-NEXT:  "\"",
+# CHECK-NEXT:  "/"
 # CHECK-NEXT:]
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "declarationProvider": true,
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -314,6 +314,10 @@
 CompletionPrefix guessCompletionPrefix(llvm::StringRef Content,
unsigned Offset);
 
+// Whether it makes sense to complete at the point based on typed characters.
+// For instance, we implicitly trigger at `a->^` but not at `a>^`.
+bool allowImplicitCompletion(llvm::StringRef Content, unsigned Offset);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1912,5 +1912,42 @@
   return OS;
 }
 
+// Heuristically detect whether the `Line` is an unterminated include filename.
+bool isIncludeFile(llvm::StringRef Line) {
+  Line = Line.ltrim();
+  if (!Line.consume_front("#"))
+return false;
+  Line = Line.ltrim();
+  Line.consume_front("include") || Line.consume_front("import") ||
+  Line.consume_front("import_next");
+  Line = Line.ltrim();
+  if (Line.consume_front("<"))
+return Line.count('>') == 0;
+  if (Line.consume_front("\""))
+return Line.count('"') == 0;
+  return false;
+}
+
+bool allowImplicitCompletion(llvm::StringRef Content, unsigned Offset) {
+  // Look at last line before completion point only.
+  Content = Content.take_front(Offset);
+  auto Pos = Content.rfind('\n');
+  if (Pos != llvm::StringRef::npos)
+Content = Content.substr(Pos + 1);
+
+  // Complete after scope operators.
+  if (Content.endswith(".") || Content.endswith("->") || Content.endswith("::"))
+return true;
+  // Complete after `#include <` and #include 

[PATCH] D78607: [local-bounds] Ignore volatile operations

2020-05-05 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/docs/UndefinedBehaviorSanitizer.rst:175-177
   -  ``-fsanitize=undefined``: All of the checks listed above other than
  ``float-divide-by-zero``, ``unsigned-integer-overflow``,
  ``implicit-conversion``, and the ``nullability-*`` group of checks.

While we're here we should mention that `local-bounds` isn't part of 
`undefined`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78607



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


[PATCH] D74238: [clang] Improve diagnostic note for implicit conversion sequences that would work if more than one implicit user-defined conversion were allowed.

2020-05-05 Thread Logan Smith via Phabricator via cfe-commits
logan-5 abandoned this revision.
logan-5 added a comment.

@rsmith the intention is to only speculatively search one level deep (e.g. 
search for chains like A->B, B->C, but no deeper), which should cover most of 
the cases that are surprising to users.

However, the implementation of this patch has some issues, and it doesn't work 
quite how I intended. I still like the idea and I'd like to revisit it, but 
pondering how to get it to work properly is more than I have time for at the 
moment, with all the craziness in the world. So in the meantime, I'd like to 
withdraw it--I'll mark it and its related patches as 'abandoned'. Thanks very 
much for your time considering it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74238



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


[PATCH] D79449: [CUDA] Make NVVM builtins available with CUDA-11 & PTX6.5

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG844096b996a0: [CUDA] Make NVVM builtins available with 
CUDA-11/PTX6.5 (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79449

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -20,7 +20,9 @@
 #pragma push_macro("SM_70")
 #pragma push_macro("SM_72")
 #pragma push_macro("SM_75")
-#define SM_75 "sm_75"
+#pragma push_macro("SM_80")
+#define SM_80 "sm_80"
+#define SM_75 "sm_75|" SM_80
 #define SM_72 "sm_72|" SM_75
 #define SM_70 "sm_70|" SM_72
 
@@ -31,7 +33,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -721,7 +725,9 @@
 #pragma pop_macro("SM_70")
 #pragma pop_macro("SM_72")
 #pragma pop_macro("SM_75")
+#pragma pop_macro("SM_80")
 #pragma pop_macro("PTX60")
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -20,7 +20,9 @@
 #pragma push_macro("SM_70")
 #pragma push_macro("SM_72")
 #pragma push_macro("SM_75")
-#define SM_75 "sm_75"
+#pragma push_macro("SM_80")
+#define SM_80 "sm_80"
+#define SM_75 "sm_75|" SM_80
 #define SM_72 "sm_72|" SM_75
 #define SM_70 "sm_70|" SM_72
 
@@ -31,7 +33,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -721,7 +725,9 @@
 #pragma pop_macro("SM_70")
 #pragma pop_macro("SM_72")
 #pragma pop_macro("SM_75")
+#pragma pop_macro("SM_80")
 #pragma pop_macro("PTX60")
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79035: [clang][AIX] Implement ABIInfo and TargetCodeGenInfo for AIX

2020-05-05 Thread Jason Liu via Phabricator via cfe-commits
jasonliu added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4368
+
+  return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ false, TypeInfo,
+  SlotSize, /*AllowHigher*/ true);

ZarkoCA wrote:
> Is there a reason why Indirect is set to `false` instead of querying for it 
> using `classifyArgumentType(Ty).isIndirect()`?
For how we handle Vaarg in backend, we just expect everything on register(no 
ByVal) even when it's a structure. So the indirect should always be false 
unless there is change in backend implementation.  



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4641
 return false;
   case CodeGenOptions::SRCK_InRegs: // -msvr4-struct-return
 return true;

ZarkoCA wrote:
> Has this option been verified to work correctly on AIX? In 
> https://reviews.llvm.org/D76360 we added a defensive error because we weren't 
> sure whether padding was handled correctly as described in the code. 
Thanks. I think we should disable this option in this patch.



Comment at: clang/test/CodeGen/ppc32-and-aix-struct-return.c:8
+// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX
+// RUN: %clang_cc1 -triple powerpc-unknown-linux \
+// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX

Xiangling_L wrote:
> Do you mean to check AIX or SVR4?
This file is actually from llvm-project/clang/test/CodeGen/ppc32-struct-return.c
What I did is only adding the check for AIX triple. And apparently, the default 
behavior of powerpc-unknown-linux triple is CHECK-AIX.


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

https://reviews.llvm.org/D79035



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


[PATCH] D79035: [clang][AIX] Implement ABIInfo and TargetCodeGenInfo for AIX

2020-05-05 Thread Jason Liu via Phabricator via cfe-commits
jasonliu updated this revision to Diff 262252.

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

https://reviews.llvm.org/D79035

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/aix-complex.c
  clang/test/CodeGen/aix-return.c
  clang/test/CodeGen/aix-struct-arg.c
  clang/test/CodeGen/aix-vaargs.c
  clang/test/CodeGen/aix-vector.c
  clang/test/CodeGen/ppc32-and-aix-struct-return.c
  clang/test/CodeGen/ppc32-dwarf.c
  clang/test/CodeGen/ppc32-struct-return.c
  clang/test/CodeGen/ppc64-dwarf.c
  clang/test/Driver/ppc-unsupported.c

Index: clang/test/Driver/ppc-unsupported.c
===
--- clang/test/Driver/ppc-unsupported.c
+++ clang/test/Driver/ppc-unsupported.c
@@ -7,4 +7,12 @@
 // RUN:   -c %s 2>&1 | FileCheck %s
 // RUN: not %clang -target powerpc64le-unknown-linux -msvr4-struct-return \
 // RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc-unknown-aix -maix-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc-unknown-aix -msvr4-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64-unknown-aix -maix-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64-unknown-aix -msvr4-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
 // CHECK: unsupported option
Index: clang/test/CodeGen/ppc64-dwarf.c
===
--- clang/test/CodeGen/ppc64-dwarf.c
+++ clang/test/CodeGen/ppc64-dwarf.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,PPC64
 static unsigned char dwarf_reg_size_table[1024];
 
 int test() {
@@ -119,10 +120,10 @@
 // CHECK-NEXT: store i8 16, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 108), align 1
 // CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 109), align 1
 // CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 110), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 111), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 112), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 113), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 114), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 115), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 116), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 111), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 112), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 113), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 114), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 115), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 116), align 1
 // CHECK-NEXT: ret i32 1
Index: clang/test/CodeGen/ppc32-struct-return.c
===
--- clang/test/CodeGen/ppc32-struct-return.c
+++ /dev/null
@@ -1,88 +0,0 @@
-// REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -triple powerpc-unknown-freebsd \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 -triple powerpc-unknown-linux \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX
-// RUN: %clang_cc1 -triple powerpc-unknown-linux -maix-struct-return \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX
-// RUN: %clang_cc1 -triple powerpc-unknown-linux -msvr4-struct-return \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 -triple powerpc-unknown-netbsd \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 -triple powerpc-unknown-openbsd \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4

[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-05 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

In D79445#2021311 , @leonardchan wrote:

> In `addSanitizersAtO0`, could you make something similar to the `ASanPass` 
> lambda for the MSan passes and also apply it when adding kernel MSan?


It ends up calling an extra `MPM.addPass(createModuleToFunctionPassAdaptor())` 
in the `KernelMemory` case, is that okay?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445



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


[PATCH] D78573: [Clang][Sema] Capturing section type conflicts between #pragma clang section and section attributes

2020-05-05 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm




Comment at: clang/include/clang/AST/ASTContext.h:3008
+/// Insertion operator for diagnostics.
+inline const DiagnosticBuilder &
+operator<<(const DiagnosticBuilder ,

pratlucas wrote:
> rnk wrote:
> > It seems like there is no need for this to be defined inline, since it is 
> > presumably cold code.
> The `inline`'s purpose here is just to allow the definition in the header 
> file, avoiding multiple definition errors.
Yes, I am suggesting that the body be moved out of line, but this is optional. 
Less code in headers --> faster builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78573



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


[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-05 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 262248.
aeubanks added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1015,14 +1015,20 @@
 ASanPass(SanitizerKind::KernelAddress, /*CompileKernel=*/true);
   }
 
+  auto MSanPass = [&](SanitizerMask Mask, bool Kernel) {
+bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, Kernel}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, Kernel})));
+  };
+
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+MSanPass(SanitizerKind::Memory, /*Kernel=*/false);
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({0, false, /*Kernel=*/true})));
+MSanPass(SanitizerKind::KernelMemory, /*Kernel=*/true);
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
@@ -1236,12 +1242,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) 
{
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1015,14 +1015,20 @@
 ASanPass(SanitizerKind::KernelAddress, /*CompileKernel=*/true);
   }
 
+  auto MSanPass = [&](SanitizerMask Mask, bool Kernel) {
+bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, Kernel}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, Kernel})));
+  };
+
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+MSanPass(SanitizerKind::Memory, /*Kernel=*/false);
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({0, false, /*Kernel=*/true})));
+MSanPass(SanitizerKind::KernelMemory, /*Kernel=*/true);
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
@@ -1236,12 +1242,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) {
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
___
cfe-commits mailing list

[PATCH] D79035: [clang][AIX] Implement ABIInfo and TargetCodeGenInfo for AIX

2020-05-05 Thread Jason Liu via Phabricator via cfe-commits
jasonliu updated this revision to Diff 262250.
jasonliu marked 12 inline comments as done.
jasonliu added a comment.

Rebase and address comments.


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

https://reviews.llvm.org/D79035

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/aix-complex.c
  clang/test/CodeGen/aix-return.c
  clang/test/CodeGen/aix-struct-arg.c
  clang/test/CodeGen/aix-vaargs.c
  clang/test/CodeGen/aix-vector.c
  clang/test/CodeGen/ppc32-and-aix-struct-return.c
  clang/test/CodeGen/ppc32-dwarf.c
  clang/test/CodeGen/ppc32-struct-return.c
  clang/test/CodeGen/ppc64-dwarf.c
  clang/test/Driver/ppc-unsupported.c

Index: clang/test/Driver/ppc-unsupported.c
===
--- clang/test/Driver/ppc-unsupported.c
+++ clang/test/Driver/ppc-unsupported.c
@@ -7,4 +7,12 @@
 // RUN:   -c %s 2>&1 | FileCheck %s
 // RUN: not %clang -target powerpc64le-unknown-linux -msvr4-struct-return \
 // RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc-unknown-aix -maix-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc-unknown-aix -msvr4-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64-unknown-aix -maix-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64-unknown-aix -msvr4-struct-return \
+// RUN:   -c %s 2>&1 | FileCheck %s
 // CHECK: unsupported option
Index: clang/test/CodeGen/ppc64-dwarf.c
===
--- clang/test/CodeGen/ppc64-dwarf.c
+++ clang/test/CodeGen/ppc64-dwarf.c
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,PPC64
 static unsigned char dwarf_reg_size_table[1024];
 
 int test() {
@@ -119,10 +120,10 @@
 // CHECK-NEXT: store i8 16, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 108), align 1
 // CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 109), align 1
 // CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 110), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 111), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 112), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 113), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 114), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 115), align 1
-// CHECK-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 116), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 111), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 112), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 113), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 114), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 115), align 1
+// PPC64-NEXT: store i8 8, i8* getelementptr inbounds ([1024 x i8], [1024 x i8]* @dwarf_reg_size_table, i64 0, i64 116), align 1
 // CHECK-NEXT: ret i32 1
Index: clang/test/CodeGen/ppc32-struct-return.c
===
--- clang/test/CodeGen/ppc32-struct-return.c
+++ /dev/null
@@ -1,88 +0,0 @@
-// REQUIRES: powerpc-registered-target
-// RUN: %clang_cc1 -triple powerpc-unknown-freebsd \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 -triple powerpc-unknown-linux \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX
-// RUN: %clang_cc1 -triple powerpc-unknown-linux -maix-struct-return \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-AIX
-// RUN: %clang_cc1 -triple powerpc-unknown-linux -msvr4-struct-return \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 -triple powerpc-unknown-netbsd \
-// RUN:   -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-SVR4
-// RUN: %clang_cc1 

[clang] b0eb7cd - Reapply "NFC: utils/perf-training: Python 3 compatibility for lit.cfg"

2020-05-05 Thread Azharuddin Mohammed via cfe-commits

Author: Azharuddin Mohammed
Date: 2020-05-05T15:56:23-07:00
New Revision: b0eb7cd2be849f0551e9b05a0cbf2d59d8c9f50d

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

LOG: Reapply "NFC: utils/perf-training: Python 3 compatibility for lit.cfg"

This is in response to the recent move to Python 3.

This reverts commit 5f4426e517fc26d10db2fd09f3e254e80446d62d.

Added: 


Modified: 
clang/utils/perf-training/lit.cfg

Removed: 




diff  --git a/clang/utils/perf-training/lit.cfg 
b/clang/utils/perf-training/lit.cfg
index e5b7162e5904..acb50ad30d7a 100644
--- a/clang/utils/perf-training/lit.cfg
+++ b/clang/utils/perf-training/lit.cfg
@@ -10,7 +10,7 @@ def getSysrootFlagsOnDarwin(config, lit_config):
 # default system root path.
 if 'darwin' in config.target_triple:
 try:
-out = subprocess.check_output(['xcrun', '--show-sdk-path']).strip()
+out = subprocess.check_output(['xcrun', 
'--show-sdk-path']).strip().decode()
 res = 0
 except OSError:
 res = -1



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


[clang] 844096b - [CUDA] Make NVVM builtins available with CUDA-11/PTX6.5

2020-05-05 Thread Artem Belevich via cfe-commits

Author: Artem Belevich
Date: 2020-05-05T15:43:32-07:00
New Revision: 844096b996a0b17d3f380af323614a5fe31b8a68

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

LOG: [CUDA] Make NVVM builtins available with CUDA-11/PTX6.5

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsNVPTX.def
clang/test/CodeGen/builtins-nvptx-ptx60.cu

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsNVPTX.def 
b/clang/include/clang/Basic/BuiltinsNVPTX.def
index 70be6182c7ac..96455753ae4d 100644
--- a/clang/include/clang/Basic/BuiltinsNVPTX.def
+++ b/clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -20,7 +20,9 @@
 #pragma push_macro("SM_70")
 #pragma push_macro("SM_72")
 #pragma push_macro("SM_75")
-#define SM_75 "sm_75"
+#pragma push_macro("SM_80")
+#define SM_80 "sm_80"
+#define SM_75 "sm_75|" SM_80
 #define SM_72 "sm_72|" SM_75
 #define SM_70 "sm_70|" SM_72
 
@@ -31,7 +33,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -721,7 +725,9 @@ TARGET_BUILTIN(__imma_m8n8k32_st_c_i32, "vi*iC*UiIi", "", 
AND(SM_75,PTX63))
 #pragma pop_macro("SM_70")
 #pragma pop_macro("SM_72")
 #pragma pop_macro("SM_75")
+#pragma pop_macro("SM_80")
 #pragma pop_macro("PTX60")
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")

diff  --git a/clang/test/CodeGen/builtins-nvptx-ptx60.cu 
b/clang/test/CodeGen/builtins-nvptx-ptx60.cu
index 11db9ac46ea5..f6af9de6e8d7 100644
--- a/clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ b/clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 



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


[PATCH] D78607: [local-bounds] Ignore volatile operations

2020-05-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka updated this revision to Diff 262239.
vitalybuka added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

doc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78607

Files:
  clang/docs/UndefinedBehaviorSanitizer.rst
  llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
  llvm/test/Instrumentation/BoundsChecking/simple.ll

Index: llvm/test/Instrumentation/BoundsChecking/simple.ll
===
--- llvm/test/Instrumentation/BoundsChecking/simple.ll
+++ llvm/test/Instrumentation/BoundsChecking/simple.ll
@@ -46,6 +46,16 @@
   ret void
 }
 
+; CHECK: @store_volatile
+define void @store_volatile(i64 %x) nounwind {
+  %1 = tail call i8* @calloc(i64 4, i64 %x)
+  %2 = bitcast i8* %1 to i32*
+  %idx = getelementptr inbounds i32, i32* %2, i64 8
+; CHECK-NOT: trap
+  store volatile i32 3, i32* %idx, align 4
+  ret void
+}
+
 ; CHECK: @f4
 define void @f4(i64 %x) nounwind {
   %1 = tail call i8* @realloc(i8* null, i64 %x) nounwind
@@ -144,12 +154,23 @@
 define i64 @f12(i64 %x, i64 %y) nounwind {
   %1 = tail call i8* @calloc(i64 1, i64 %x)
 ; CHECK: mul i64 %y, 8
+; CHECK: trap
   %2 = bitcast i8* %1 to i64*
   %3 = getelementptr inbounds i64, i64* %2, i64 %y
   %4 = load i64, i64* %3, align 8
   ret i64 %4
 }
 
+; CHECK: @load_volatile
+define i64 @load_volatile(i64 %x, i64 %y) nounwind {
+  %1 = tail call i8* @calloc(i64 1, i64 %x)
+; CHECK-NOT: trap
+  %2 = bitcast i8* %1 to i64*
+  %3 = getelementptr inbounds i64, i64* %2, i64 %y
+  %4 = load volatile i64, i64* %3, align 8
+  ret i64 %4
+}
+
 ; PR17402
 ; CHECK-LABEL: @f13
 define void @f13() nounwind {
Index: llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
===
--- llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
+++ llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
@@ -154,17 +154,22 @@
 Value *Or = nullptr;
 BuilderTy IRB(I.getParent(), BasicBlock::iterator(), TargetFolder(DL));
 if (LoadInst *LI = dyn_cast()) {
-  Or = getBoundsCheckCond(LI->getPointerOperand(), LI, DL, TLI,
-  ObjSizeEval, IRB, SE);
+  if (!LI->isVolatile())
+Or = getBoundsCheckCond(LI->getPointerOperand(), LI, DL, TLI,
+ObjSizeEval, IRB, SE);
 } else if (StoreInst *SI = dyn_cast()) {
-  Or = getBoundsCheckCond(SI->getPointerOperand(), SI->getValueOperand(),
-  DL, TLI, ObjSizeEval, IRB, SE);
+  if (!SI->isVolatile())
+Or = getBoundsCheckCond(SI->getPointerOperand(), SI->getValueOperand(),
+DL, TLI, ObjSizeEval, IRB, SE);
 } else if (AtomicCmpXchgInst *AI = dyn_cast()) {
-  Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getCompareOperand(),
-  DL, TLI, ObjSizeEval, IRB, SE);
+  if (!AI->isVolatile())
+Or =
+getBoundsCheckCond(AI->getPointerOperand(), AI->getCompareOperand(),
+   DL, TLI, ObjSizeEval, IRB, SE);
 } else if (AtomicRMWInst *AI = dyn_cast()) {
-  Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getValOperand(), DL,
-  TLI, ObjSizeEval, IRB, SE);
+  if (!AI->isVolatile())
+Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getValOperand(),
+DL, TLI, ObjSizeEval, IRB, SE);
 }
 if (Or)
   TrapInfo.push_back(std::make_pair(, Or));
Index: clang/docs/UndefinedBehaviorSanitizer.rst
===
--- clang/docs/UndefinedBehaviorSanitizer.rst
+++ clang/docs/UndefinedBehaviorSanitizer.rst
@@ -81,7 +81,8 @@
  ``true`` nor ``false``.
   -  ``-fsanitize=builtin``: Passing invalid values to compiler builtins.
   -  ``-fsanitize=bounds``: Out of bounds array indexing, in cases
- where the array bound can be statically determined.
+ where the array bound can be statically determined. Includes 
+ ``-fsanitize=local-bounds`` and ``-fsanitize=array-bounds``.
   -  ``-fsanitize=enum``: Load of a value of an enumerated type which
  is not in the range of representable values for that enumerated
  type.
@@ -202,7 +203,7 @@
 Volatile
 
 
-The ``null``, ``alignment``, ``object-size``, and ``vptr`` checks do not apply
+The ``null``, ``alignment``, ``object-size``, ``local-bounds``, and ``vptr`` checks do not apply
 to pointers to types with the ``volatile`` qualifier.
 
 Minimal Runtime
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78607: [local-bounds] Ignore volatile operations

2020-05-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka updated this revision to Diff 262240.
vitalybuka added a comment.

updated doc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78607

Files:
  clang/docs/UndefinedBehaviorSanitizer.rst
  llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
  llvm/test/Instrumentation/BoundsChecking/simple.ll

Index: llvm/test/Instrumentation/BoundsChecking/simple.ll
===
--- llvm/test/Instrumentation/BoundsChecking/simple.ll
+++ llvm/test/Instrumentation/BoundsChecking/simple.ll
@@ -46,6 +46,16 @@
   ret void
 }
 
+; CHECK: @store_volatile
+define void @store_volatile(i64 %x) nounwind {
+  %1 = tail call i8* @calloc(i64 4, i64 %x)
+  %2 = bitcast i8* %1 to i32*
+  %idx = getelementptr inbounds i32, i32* %2, i64 8
+; CHECK-NOT: trap
+  store volatile i32 3, i32* %idx, align 4
+  ret void
+}
+
 ; CHECK: @f4
 define void @f4(i64 %x) nounwind {
   %1 = tail call i8* @realloc(i8* null, i64 %x) nounwind
@@ -144,12 +154,23 @@
 define i64 @f12(i64 %x, i64 %y) nounwind {
   %1 = tail call i8* @calloc(i64 1, i64 %x)
 ; CHECK: mul i64 %y, 8
+; CHECK: trap
   %2 = bitcast i8* %1 to i64*
   %3 = getelementptr inbounds i64, i64* %2, i64 %y
   %4 = load i64, i64* %3, align 8
   ret i64 %4
 }
 
+; CHECK: @load_volatile
+define i64 @load_volatile(i64 %x, i64 %y) nounwind {
+  %1 = tail call i8* @calloc(i64 1, i64 %x)
+; CHECK-NOT: trap
+  %2 = bitcast i8* %1 to i64*
+  %3 = getelementptr inbounds i64, i64* %2, i64 %y
+  %4 = load volatile i64, i64* %3, align 8
+  ret i64 %4
+}
+
 ; PR17402
 ; CHECK-LABEL: @f13
 define void @f13() nounwind {
Index: llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
===
--- llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
+++ llvm/lib/Transforms/Instrumentation/BoundsChecking.cpp
@@ -154,17 +154,22 @@
 Value *Or = nullptr;
 BuilderTy IRB(I.getParent(), BasicBlock::iterator(), TargetFolder(DL));
 if (LoadInst *LI = dyn_cast()) {
-  Or = getBoundsCheckCond(LI->getPointerOperand(), LI, DL, TLI,
-  ObjSizeEval, IRB, SE);
+  if (!LI->isVolatile())
+Or = getBoundsCheckCond(LI->getPointerOperand(), LI, DL, TLI,
+ObjSizeEval, IRB, SE);
 } else if (StoreInst *SI = dyn_cast()) {
-  Or = getBoundsCheckCond(SI->getPointerOperand(), SI->getValueOperand(),
-  DL, TLI, ObjSizeEval, IRB, SE);
+  if (!SI->isVolatile())
+Or = getBoundsCheckCond(SI->getPointerOperand(), SI->getValueOperand(),
+DL, TLI, ObjSizeEval, IRB, SE);
 } else if (AtomicCmpXchgInst *AI = dyn_cast()) {
-  Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getCompareOperand(),
-  DL, TLI, ObjSizeEval, IRB, SE);
+  if (!AI->isVolatile())
+Or =
+getBoundsCheckCond(AI->getPointerOperand(), AI->getCompareOperand(),
+   DL, TLI, ObjSizeEval, IRB, SE);
 } else if (AtomicRMWInst *AI = dyn_cast()) {
-  Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getValOperand(), DL,
-  TLI, ObjSizeEval, IRB, SE);
+  if (!AI->isVolatile())
+Or = getBoundsCheckCond(AI->getPointerOperand(), AI->getValOperand(),
+DL, TLI, ObjSizeEval, IRB, SE);
 }
 if (Or)
   TrapInfo.push_back(std::make_pair(, Or));
Index: clang/docs/UndefinedBehaviorSanitizer.rst
===
--- clang/docs/UndefinedBehaviorSanitizer.rst
+++ clang/docs/UndefinedBehaviorSanitizer.rst
@@ -81,7 +81,8 @@
  ``true`` nor ``false``.
   -  ``-fsanitize=builtin``: Passing invalid values to compiler builtins.
   -  ``-fsanitize=bounds``: Out of bounds array indexing, in cases
- where the array bound can be statically determined.
+ where the array bound can be statically determined. The check includes
+ ``-fsanitize=local-bounds`` and ``-fsanitize=array-bounds``.
   -  ``-fsanitize=enum``: Load of a value of an enumerated type which
  is not in the range of representable values for that enumerated
  type.
@@ -202,7 +203,7 @@
 Volatile
 
 
-The ``null``, ``alignment``, ``object-size``, and ``vptr`` checks do not apply
+The ``null``, ``alignment``, ``object-size``, ``local-bounds``, and ``vptr`` checks do not apply
 to pointers to types with the ``volatile`` qualifier.
 
 Minimal Runtime
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78607: [local-bounds] Ignore volatile operations

2020-05-05 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

done


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78607



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


[PATCH] D79449: [CUDA] Make NVVM builtins available with CUDA-11 & PTX6.5

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra updated this revision to Diff 262237.
tra added a comment.

Actually added sm_80 predicate. It's not used on any builtins yet, but it makes
sense to add it right now along with ptx65.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79449

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -20,7 +20,9 @@
 #pragma push_macro("SM_70")
 #pragma push_macro("SM_72")
 #pragma push_macro("SM_75")
-#define SM_75 "sm_75"
+#pragma push_macro("SM_80")
+#define SM_80 "sm_80"
+#define SM_75 "sm_75|" SM_80
 #define SM_72 "sm_72|" SM_75
 #define SM_70 "sm_70|" SM_72
 
@@ -31,7 +33,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -721,7 +725,9 @@
 #pragma pop_macro("SM_70")
 #pragma pop_macro("SM_72")
 #pragma pop_macro("SM_75")
+#pragma pop_macro("SM_80")
 #pragma pop_macro("PTX60")
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -20,7 +20,9 @@
 #pragma push_macro("SM_70")
 #pragma push_macro("SM_72")
 #pragma push_macro("SM_75")
-#define SM_75 "sm_75"
+#pragma push_macro("SM_80")
+#define SM_80 "sm_80"
+#define SM_75 "sm_75|" SM_80
 #define SM_72 "sm_72|" SM_75
 #define SM_70 "sm_70|" SM_72
 
@@ -31,7 +33,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -721,7 +725,9 @@
 #pragma pop_macro("SM_70")
 #pragma pop_macro("SM_72")
 #pragma pop_macro("SM_75")
+#pragma pop_macro("SM_80")
 #pragma pop_macro("PTX60")
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 67175d8 - [cmake] Allow std::filesystem tests in CrossWinToARMLinux.cmake

2020-05-05 Thread Sergej Jaskiewicz via cfe-commits

Author: Sergej Jaskiewicz
Date: 2020-05-06T01:31:32+03:00
New Revision: 67175d8dc53b580bad439f85fda12623fa6993fa

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

LOG: [cmake] Allow std::filesystem tests in CrossWinToARMLinux.cmake

Now that https://reviews.llvm.org/D78200 has landed, there should be
no problem with those tests. If there is, it is OK to revert this.

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index c01c31ae5a72..3d1e961ada8d 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -89,9 +89,6 @@ set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXOFF CACHE BOOL 
"")
 set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXXABIOFF CACHE BOOL "")
 set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXX   OFF CACHE BOOL "")
 
-# FIXME: Remove this when https://reviews.llvm.org/D78200 is merged.
-set(LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "") 
-
 set(LIBCXX_USE_COMPILER_RT  ON CACHE BOOL "")
 set(LIBCXX_TARGET_TRIPLE"${CMAKE_C_COMPILER_TARGET}" CACHE 
STRING "")
 set(LIBCXX_SYSROOT  "${DEFAULT_SYSROOT}" CACHE STRING 
"")



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


[PATCH] D79449: [CUDA] Make NVVM builtins available with CUDA-11 & PTX6.5

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra created this revision.
tra added a reviewer: timshen.
Herald added subscribers: sanjoy.google, bixia, yaxunl, jholewinski.
Herald added a project: clang.
tra updated this revision to Diff 262236.
tra added a comment.

Test that the builtins work all the way to sm_80/ptx65


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79449

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -31,7 +31,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -725,3 +727,4 @@
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -31,7 +31,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -725,3 +727,4 @@
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79449: [CUDA] Make NVVM builtins available with CUDA-11 & PTX6.5

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra updated this revision to Diff 262236.
tra added a comment.

Test that the builtins work all the way to sm_80/ptx65


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79449

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/test/CodeGen/builtins-nvptx-ptx60.cu


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -31,7 +31,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -725,3 +727,4 @@
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")


Index: clang/test/CodeGen/builtins-nvptx-ptx60.cu
===
--- clang/test/CodeGen/builtins-nvptx-ptx60.cu
+++ clang/test/CodeGen/builtins-nvptx-ptx60.cu
@@ -2,6 +2,10 @@
 // RUN:-fcuda-is-device -target-feature +ptx60 \
 // RUN:-S -emit-llvm -o - -x cuda %s \
 // RUN:   | FileCheck -check-prefix=CHECK %s
+// RUN: %clang_cc1 -triple nvptx64-unknown-unknown -target-cpu sm_80 \
+// RUN:-fcuda-is-device -target-feature +ptx65 \
+// RUN:-S -emit-llvm -o - -x cuda %s \
+// RUN:   | FileCheck -check-prefix=CHECK %s
 // RUN: %clang_cc1 -triple nvptx-unknown-unknown -target-cpu sm_60 \
 // RUN:   -fcuda-is-device -S -o /dev/null -x cuda -verify %s
 
Index: clang/include/clang/Basic/BuiltinsNVPTX.def
===
--- clang/include/clang/Basic/BuiltinsNVPTX.def
+++ clang/include/clang/Basic/BuiltinsNVPTX.def
@@ -31,7 +31,9 @@
 #pragma push_macro("PTX61")
 #pragma push_macro("PTX63")
 #pragma push_macro("PTX64")
-#define PTX64 "ptx64"
+#pragma push_macro("PTX65")
+#define PTX65 "ptx65"
+#define PTX64 "ptx64|" PTX65
 #define PTX63 "ptx63|" PTX64
 #define PTX61 "ptx61|" PTX63
 #define PTX60 "ptx60|" PTX61
@@ -725,3 +727,4 @@
 #pragma pop_macro("PTX61")
 #pragma pop_macro("PTX63")
 #pragma pop_macro("PTX64")
+#pragma pop_macro("PTX65")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-05 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 262231.
MyDeveloperDay added a comment.

Reduce false formatting


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

https://reviews.llvm.org/D79354

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7636,6 +7636,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,12 +2399,14 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, tok::l_square) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
+
 if (Style.Language == FormatStyle::LK_JavaScript &&
 FormatTok->isOneOf(Keywords.kw_extends, Keywords.kw_implements)) {
   // JavaScript/TypeScript supports inline object types in
@@ -2421,8 +2423,15 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->Tok.is(tok::l_square)) {
+parseSquare();
+// Consume the closing TT_AttributeSquare.
+nextToken();
+  }
+}
   }
 
   // Note that parsing away template declarations here leads to incorrectly


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7636,6 +7636,10 @@
   verifyFormat("void f() [[deprecated(\"so sorry\")]];");
   verifyFormat("aa\n"
"[[unused]] aaa(int i);");
+  verifyFormat("[[nodiscard]] bool f() { return false; }");
+  verifyFormat("class [[nodiscard]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[deprecated(\"so sorry\")]] f {\npublic:\n  f() {}\n}");
+  verifyFormat("class [[gnu::unused]] f {\npublic:\n  f() {}\n}");
 
   // Make sure we do not mistake attributes for array subscripts.
   verifyFormat("int a() {}\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2399,12 +2399,14 @@
 
   // The actual identifier can be a nested name specifier, and in macros
   // it is often token-pasted.
+  // An [[attribute]] can be before the identifier
   while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash,
 tok::kw___attribute, tok::kw___declspec,
-tok::kw_alignas) ||
+tok::kw_alignas, tok::l_square) ||
  ((Style.Language == FormatStyle::LK_Java ||
Style.Language == FormatStyle::LK_JavaScript) &&
   FormatTok->isOneOf(tok::period, tok::comma))) {
+
 if (Style.Language == FormatStyle::LK_JavaScript &&
 FormatTok->isOneOf(Keywords.kw_extends, Keywords.kw_implements)) {
   // JavaScript/TypeScript supports inline object types in
@@ -2421,8 +2423,15 @@
 FormatTok->TokenText != FormatTok->TokenText.upper();
 nextToken();
 // We can have macros or attributes in between 'class' and the class name.
-if (!IsNonMacroIdentifier && FormatTok->Tok.is(tok::l_paren))
-  parseParens();
+if (!IsNonMacroIdentifier) {
+  if (FormatTok->Tok.is(tok::l_paren)) {
+parseParens();
+  } else if (FormatTok->Tok.is(tok::l_square)) {
+   

[PATCH] D79448: [X86] Allow Yz inline assembly constraint to choose ymm0 or zmm0 when avx/avx512 are enabled and type is 256 or 512 bits

2020-05-05 Thread Craig Topper via Phabricator via cfe-commits
craig.topper created this revision.
craig.topper added reviewers: RKSimon, spatel, rnk, echristo.
Herald added a subscriber: hiraditya.
Herald added a project: LLVM.

gcc supports selecting ymm0/zmm0 for the Yz constraint when used with 256 or 
512 bit vector types.

Fixes PR45806


https://reviews.llvm.org/D79448

Files:
  clang/lib/Basic/Targets/X86.cpp
  clang/test/CodeGen/x86-inline-asm-v-constraint.c
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
  llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll

Index: llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
===
--- llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
+++ llvm/test/CodeGen/X86/inline-asm-avx512f-v-constraint.ll
@@ -70,3 +70,12 @@
   ret <16 x float> %0
 }
 
+define <16 x float> @testZMM0() {
+entry:
+; CHECK: vpternlogd $255, %zmm0, %zmm0, %zmm0
+  %zmm0 = alloca <16 x float>, align 64
+  %0 = call <16 x float> asm "vpternlogd $$255, $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+  store <16 x float> %0, <16 x float>* %zmm0, align 64
+  %1 = load <16 x float>, <16 x float>* %zmm0, align 64
+  ret <16 x float> %1
+}
Index: llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
===
--- llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
+++ llvm/test/CodeGen/X86/inline-asm-avx-v-constraint.ll
@@ -134,3 +134,13 @@
   ret <8 x float> %0
 }
 
+define <8 x float> @testYMM0() {
+; CHECK: vpcmpeqd %ymm0, %ymm0, %ymm0
+entry:
+  %ymm0 = alloca <8 x float>, align 32
+  %0 = call <8 x float> asm "vpcmpeqd $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+  store <8 x float> %0, <8 x float>* %ymm0, align 32
+  %1 = load <8 x float>, <8 x float>* %ymm0, align 32
+  ret <8 x float> %1
+}
+
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -48041,7 +48041,9 @@
   // XMM0
   case 'z':
   case '0':
-if ((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1())
+if (((type->getPrimitiveSizeInBits() == 128) && Subtarget.hasSSE1()) ||
+((type->getPrimitiveSizeInBits() == 256) && Subtarget.hasAVX()) ||
+((type->getPrimitiveSizeInBits() == 512) && Subtarget.hasAVX512()))
   return CW_SpecificReg;
 return CW_Invalid;
   // Conditional OpMask regs (AVX512)
@@ -48491,6 +48493,8 @@
 if (Subtarget.hasAVX())
   return std::make_pair(0U, ::VR256RegClass);
 break;
+  case MVT::v64i8:
+  case MVT::v32i16:
   case MVT::v8f64:
   case MVT::v16f32:
   case MVT::v16i32:
@@ -48516,7 +48520,42 @@
 case 'z':
 case '0':
   if (!Subtarget.hasSSE1()) break;
-  return std::make_pair(X86::XMM0, ::VR128RegClass);
+  switch (VT.SimpleTy) {
+  default: break;
+  // Scalar SSE types.
+  case MVT::f32:
+  case MVT::i32:
+return std::make_pair(X86::XMM0, ::FR32RegClass);
+  case MVT::f64:
+  case MVT::i64:
+return std::make_pair(X86::XMM0, ::FR64RegClass);
+  case MVT::f128:
+  case MVT::v16i8:
+  case MVT::v8i16:
+  case MVT::v4i32:
+  case MVT::v2i64:
+  case MVT::v4f32:
+  case MVT::v2f64:
+return std::make_pair(X86::XMM0, ::VR128RegClass);
+  // AVX types.
+  case MVT::v32i8:
+  case MVT::v16i16:
+  case MVT::v8i32:
+  case MVT::v4i64:
+  case MVT::v8f32:
+  case MVT::v4f64:
+if (Subtarget.hasAVX())
+  return std::make_pair(X86::YMM0, ::VR256RegClass);
+break;
+  case MVT::v8f64:
+  case MVT::v16f32:
+  case MVT::v16i32:
+  case MVT::v8i64:
+if (Subtarget.hasAVX512())
+  return std::make_pair(X86::ZMM0, ::VR512_0_15RegClass);
+break;
+  }
+  break;
 case 'k':
   // This register class doesn't allocate k0 for masked vector operation.
   if (Subtarget.hasAVX512()) {
Index: clang/test/CodeGen/x86-inline-asm-v-constraint.c
===
--- clang/test/CodeGen/x86-inline-asm-v-constraint.c
+++ clang/test/CodeGen/x86-inline-asm-v-constraint.c
@@ -28,3 +28,28 @@
 #endif
   return _zmm0;
 }
+
+// SSE: call <4 x float> asm "cmpeqd $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m128 testXMM0(void) {
+  __m128 xmm0;
+  __asm__("pcmpeqd %0, %0" :"=Yz"(xmm0));
+  return xmm0;
+}
+
+// AVX: call <8 x float> asm "vcmpeqd $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m256 testYMM0(void) {
+  __m256 ymm0;
+#ifdef AVX
+  __asm__("vpcmpeqd %0, %0, %0" :"=Yz"(ymm0));
+#endif
+  return ymm0;
+}
+
+// AVX512: call <16 x float> asm "vpternlogd $$255, $0, $0, $0", "=^Yz,~{dirflag},~{fpsr},~{flags}"()
+__m512 testZMM0(void) {
+  __m512 zmm0;
+#ifdef AVX512
+  

[PATCH] D79232: [analyzer] Refactor range inference for symbolic expressions

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:127-128
+  if (a > 10) {
+clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
+  }

NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > How can both of these be false? o.o
> > Yeah :) I realized how weird it is.
> > Anything is possible in the land of infeasible ranges.
> > 
> > I changed a comment there to address this
> I mean, this pretty much never happened before. How are you not tripping on 
> [[ 
> https://github.com/llvm/llvm-project/blob/1a4421a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h#L100
>  | this assert ]]? (probably it's simply been disabled in normal debug builds 
> now that it's under "expensive checks")
> 
> The correct thing to do is to detect the paradox earlier and mark the path as 
> infeasible. What prevents us from doing it right away here?
Before we didn't really care about constraints on the operands and I changed it 
:)
So, now `Intersect` (which is logically not a correct way to do what is meant) 
can cause this type of behaviour


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79232



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


[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D77954#2021299 , @yaxunl wrote:

> I will put a workaround: In device compilation, in implicit `__device__ 
> __host__` callers, I will keep the old behavior, that is, implicit 
> `__device__ __host__` candidate has equal preference with wrong-sided 
> candidate. By doing this, we will in most cases resolve the overloading the 
> same way as if the callers and callees are host functions, therefore resolved 
> the same way as in their expected environment. This will make sure: 1. we 
> will not end up with no viable candidate 2. we will not have ambiguity, since 
> we know it is resolvable in host compilation.


LMK when you have something. I can give it a spin internally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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


[PATCH] D79419: [clang/clang-tools-extra] Fix BZ44437 - add_new_check.py does not work with Python 3

2020-05-05 Thread Konrad Wilhelm Kleine via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG24b4965ce65b: [clang/clang-tools-extra] Fix BZ44437 - 
add_new_check.py does not work with… (authored by kwk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79419

Files:
  clang-tools-extra/clang-tidy/add_new_check.py


Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -172,7 +172,7 @@
 lines = iter(lines)
 try:
   while True:
-line = lines.next()
+line = next(lines)
 if not header_added:
   match = re.search('#include "(.*)"', line)
   if match:
@@ -197,7 +197,7 @@
 # If we didn't find the check name on this line, look on the
 # next one.
 prev_line = line
-line = lines.next()
+line = next(lines)
 match = re.search(' *"([^"]*)"', line)
 if match:
   current_check_name = match.group(1)


Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -172,7 +172,7 @@
 lines = iter(lines)
 try:
   while True:
-line = lines.next()
+line = next(lines)
 if not header_added:
   match = re.search('#include "(.*)"', line)
   if match:
@@ -197,7 +197,7 @@
 # If we didn't find the check name on this line, look on the
 # next one.
 prev_line = line
-line = lines.next()
+line = next(lines)
 match = re.search(' *"([^"]*)"', line)
 if match:
   current_check_name = match.group(1)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79419: [clang/clang-tools-extra] Fix BZ44437 - add_new_check.py does not work with Python 3

2020-05-05 Thread Konrad Wilhelm Kleine via Phabricator via cfe-commits
kwk updated this revision to Diff 262226.
kwk added a comment.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79419

Files:
  clang-tools-extra/clang-tidy/add_new_check.py


Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -172,7 +172,7 @@
 lines = iter(lines)
 try:
   while True:
-line = lines.next()
+line = next(lines)
 if not header_added:
   match = re.search('#include "(.*)"', line)
   if match:
@@ -197,7 +197,7 @@
 # If we didn't find the check name on this line, look on the
 # next one.
 prev_line = line
-line = lines.next()
+line = next(lines)
 match = re.search(' *"([^"]*)"', line)
 if match:
   current_check_name = match.group(1)


Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -172,7 +172,7 @@
 lines = iter(lines)
 try:
   while True:
-line = lines.next()
+line = next(lines)
 if not header_added:
   match = re.search('#include "(.*)"', line)
   if match:
@@ -197,7 +197,7 @@
 # If we didn't find the check name on this line, look on the
 # next one.
 prev_line = line
-line = lines.next()
+line = next(lines)
 match = re.search(' *"([^"]*)"', line)
 if match:
   current_check_name = match.group(1)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-05 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan accepted this revision.
leonardchan added a comment.
This revision is now accepted and ready to land.

In `addSanitizersAtO0`, could you make something similar to the `ASanPass` 
lambda for the MSan passes and also apply it when adding kernel MSan?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79445



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


[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

FYI, I've just reverted it in bf6a26b066382e0f41bf023c781d84061c542307 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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


[PATCH] D79400: [CMAKE] Fix build failure when source directory is read only

2020-05-05 Thread Scott Linder via Phabricator via cfe-commits
scott.linder added a comment.

Can you provide more context in the diff? Looking at the current `master` 
locally it seems like this patch changes the behavior of the 
`llvm_vcsrevision_h` target when `logs/HEAD` isn't found, such that it only 
depends on the generation script. I.e. if you configure CMake without the 
`HEAD` file present, and then you do something which changes the working 
directory and creates `HEAD` the target will not be out of date and won't be 
rebuilt. Before this patch it would have noticed the change to `HEAD` and 
forced regenerating the version header.

I don't know how much this matters? In the case where the filesystem is 
read-only from CMake's perspective would it make more sense to always 
regenerate the header instead, or is the assumption that nobody else is 
modifying it either?

Also for the case where the filesystem is not read-only do we want to retain 
the old behavior? I.e. could we try to write the file and if it fails just 
proceed rather than `FATAL_ERROR`? I don't know if this is possible with 
CMake's `file()`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79400



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


[PATCH] D79118: Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:719
+ !getContext().getTargetInfo().hasInt128Type()))
+  return getNaturalAlignIndirect(Ty);
+

erichkeane wrote:
> rjmccall wrote:
> > It's very weird for 64 and 128 to be showing up as constants in the default 
> > ABI rule.
> Good point.  I rewrote this in terms of the Context.LongLongTy and 
> Context.Int128Ty.
Maybe:

```
if (EIT->getNumBits() > 
Context.getTypeSize(Context.getTargetInfo().hasInt128Type() ? Context.Int128Ty 
: Context.LongLongTy)))
```



Comment at: clang/lib/CodeGen/TargetInfo.cpp:741
+ !getContext().getTargetInfo().hasInt128Type()))
+  return getNaturalAlignIndirect(RetTy);
+

Same rule needed here.


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

https://reviews.llvm.org/D79118



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


[clang-tools-extra] 24b4965 - [clang/clang-tools-extra] Fix BZ44437 - add_new_check.py does not work with Python 3

2020-05-05 Thread Konrad Kleine via cfe-commits

Author: Konrad Kleine
Date: 2020-05-05T17:22:50-04:00
New Revision: 24b4965ce65b14ead595dcc68add22ba37533207

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

LOG: [clang/clang-tools-extra] Fix BZ44437 - add_new_check.py does not work 
with Python 3

Summary:
This fixes https://bugs.llvm.org/show_bug.cgi?id=44437.

Thanks to Arnaud Desitter for providing the patch in the bug report!

A simple example program to reproduce this error is this:

```lang=python

import sys

with open(sys.argv[0], 'r') as f:
  lines = f.readlines()
lines = iter(lines)
line = lines.next()
print(line)
```

which will error with this in python python 3:

```
Traceback (most recent call last):
  File "./mytest.py", line 8, in 
line = lines.next()
AttributeError: 'list_iterator' object has no attribute 'next'
```

Here's the same strategy applied to my test program as applied to the 
`add_new_check.py` file:

```lang=python

import sys

with open(sys.argv[0], 'r') as f:
  lines = f.readlines()
lines = iter(lines)
line = next(lines)
print(line)
```

The built-in function `next()` is new since Python 2.6: 
https://docs.python.org/2/library/functions.html#next

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/add_new_check.py

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/add_new_check.py 
b/clang-tools-extra/clang-tidy/add_new_check.py
index 22aadd612d70..4477444cc127 100755
--- a/clang-tools-extra/clang-tidy/add_new_check.py
+++ b/clang-tools-extra/clang-tidy/add_new_check.py
@@ -172,7 +172,7 @@ def adapt_module(module_path, module, check_name, 
check_name_camel):
 lines = iter(lines)
 try:
   while True:
-line = lines.next()
+line = next(lines)
 if not header_added:
   match = re.search('#include "(.*)"', line)
   if match:
@@ -197,7 +197,7 @@ def adapt_module(module_path, module, check_name, 
check_name_camel):
 # If we didn't find the check name on this line, look on the
 # next one.
 prev_line = line
-line = lines.next()
+line = next(lines)
 match = re.search(' *"([^"]*)"', line)
 if match:
   current_check_name = match.group(1)



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


[clang] bf6a26b - Revert D77954 -- it breaks Eigen & Tensorflow.

2020-05-05 Thread Artem Belevich via cfe-commits

Author: Artem Belevich
Date: 2020-05-05T14:07:31-07:00
New Revision: bf6a26b066382e0f41bf023c781d84061c542307

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

LOG: Revert D77954 -- it breaks Eigen & Tensorflow.

This reverts commit 55bcb96f3154808bcb5afc3fb46d8e00bf1db847.

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 57b650de3fee..c400d47dd2bd 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,22 +9374,16 @@ static Comparison compareEnableIfAttrs(const Sema , 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static Comparison
-isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static bool isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return Comparison::Equal;
+return false;
 
-  // If both are invalid, they are equal. If one of them is invalid, the other
-  // is better.
-  if (Cand1.Function->isInvalidDecl()) {
-if (Cand2.Function->isInvalidDecl())
-  return Comparison::Equal;
-return Comparison::Worse;
-  }
-  if (Cand2.Function->isInvalidDecl())
-return Comparison::Better;
+  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
+  // is obviously better.
+  if (Cand1.Function->isInvalidDecl()) return false;
+  if (Cand2.Function->isInvalidDecl()) return true;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9399,18 +9393,16 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return Comparison::Equal;
+return false;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return Comparison::Better;
+return true;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return Comparison::Worse;
+return false;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
- ? Comparison::Better
- : Comparison::Worse;
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9423,9 +9415,7 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
-   ? Comparison::Better
-   : Comparison::Worse;
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9485,50 +9475,6 @@ bool clang::isBetterOverloadCandidate(
   else if (!Cand1.Viable)
 return false;
 
-  // [CUDA] A function with 'never' preference is marked not viable, therefore
-  // is never shown up here. The worst preference shown up here is 'wrong 
side',
-  // e.g. a host function called by a device host function in device
-  // compilation. This is valid AST as long as the host device function is not
-  // emitted, e.g. it is an inline function which is called only by a host
-  // function. A deferred diagnostic will be triggered if it is emitted.
-  // However a wrong-sided function is still a viable candidate here.
-  //
-  // If Cand1 can be emitted and Cand2 cannot be emitted in the current
-  // context, Cand1 is better than Cand2. If Cand1 can not be emitted and Cand2
-  // can be emitted, Cand1 is not better than Cand2. This rule should have
-  // precedence over other rules.
-  //
-  // If both Cand1 and Cand2 can be emitted, or neither can be emitted, then
-  // other rules should be used to determine which is better. This is because
-  // host/device based overloading resolution is mostly for determining
-  // viability of a function. If two functions are both viable, other factors
-  // should take precedence in preference, e.g. the standard-defined 
preferences
-  // like argument conversion ranks or enable_if partial-ordering. The
-  // preference for pass-object-size parameters is probably most similar to a
-  // type-based-overloading decision and 

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-05-05 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D77954#2021026 , @tra wrote:

> It appears that re-landed b46b1a916d44216f0c70de55ae2123eb9de69027 
>  has 
> created another compilation regression. I don't have a simple reproducer yet, 
> so here's the error message for now:
>
>   llvm_unstable/toolchain/bin/../include/c++/v1/tuple:232:15: error: call to 
> implicitly-deleted copy constructor of 
> 'std::__u::unique_ptr std::__u::default_delete>'
>   : __value_(_VSTD::forward<_Tp>(__t))
> ^
>   llvm_unstable/toolchain/bin/../include/c++/v1/tuple:388:13: note: in 
> instantiation of function template specialization 'std::__u::__tuple_leaf<0, 
> std::__u::unique_ptr std::__u::default_delete>, 
> false>::__tuple_leaf std::__u::default_delete>, void>' requested here
>   __tuple_leaf<_Uf, _Tf>(_VSTD::forward<_Up>(__u))...,
>   ^
>   llvm_unstable/toolchain/bin/../include/c++/v1/tuple:793:15: note: in 
> instantiation of function template specialization 
> 'std::__u::__tuple_impl, 
> std::__u::unique_ptr std::__u::default_delete>, std::__u::function ()>>::__tuple_impl<0, 1, std::__u::unique_ptr std::__u::default_delete>, std::__u::function ()>, std::__u::unique_ptr std::__u::default_delete>, std::__u::function ()>>' requested here
>   : __base_(typename __make_tuple_indices::type(),
> ^
>   llvm_unstable/toolchain/bin/../include/c++/v1/thread:297:17: note: in 
> instantiation of function template specialization 
> 'std::__u::tuple std::__u::default_delete>, std::__u::function ()>>::tuple std::__u::default_delete>, std::__u::function ()>, false, false>' requested here
>   new _Gp(std::move(__tsp),
>   ^
>   
> ./third_party/eigen3/unsupported/Eigen/CXX11/src/ThreadPool/ThreadEnvironment.h:24:42:
>  note: in instantiation of function template specialization 
> 'std::__u::thread::thread, void>' requested here
>   EnvThread(std::function f) : thr_(std::move(f)) {}
>^
>   llvm_unstable/toolchain/bin/../include/c++/v1/memory:2583:3: note: copy 
> constructor is implicitly deleted because 
> 'unique_ptr std::__u::default_delete>' has a user-declared 
> move constructor
> unique_ptr(unique_ptr&& __u) _NOEXCEPT
> ^
>   1 error generated when compiling for sm_60.
>


For implicit `__host__ __device__` functions, they may be promoted by pragma 
but themselves may not be qualified as `__host__ __device__` functions.

Since they are promoted from host functions, they are good citizens in host 
compilation, but may incur diagnostics in device compilation, because their 
callees may be missing in device side. Since we cannot defer all the 
diagnostics, once such things happen, we are doomed.

So now we can understand why the previous behavior: that is, in a `__host__ 
__device__` function, same-side candidate is always preferred over wrong-sided 
candidate. However, `__device__ __host__` candidate is not preferred over 
wrong-sided candidate. On the other hand, their other properties take 
precedence. Only if all others are equal, `__device__ __host__` candidate is 
preferred over wrong-sided candidate.

I will put a workaround: In device compilation, in implicit `__device__ 
__host__` callers, I will keep the old behavior, that is, implicit `__device__ 
__host__` candidate has equal preference with wrong-sided candidate. By doing 
this, we will in most cases resolve the overloading the same way as if the 
callers and callees are host functions, therefore resolved the same way as in 
their expected environment. This will make sure: 1. we will not end up with no 
viable candidate 2. we will not have ambiguity, since we know it is resolvable 
in host compilation.

For explicit `__device__ __host__` functions, we do not need the workaround, 
since they are intended for host and device and are supposed to work for both 
host and device.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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


[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-05-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5813
+  // Don't touch the link register
+  if (MI.readsRegister(ARM::LR, TRI) || MI.modifiesRegister(ARM::LR, TRI))
+return outliner::InstrType::Illegal;

yroux wrote:
> efriedma wrote:
> > Why do you need to forbid outlining code that touches LR or SP? None of the 
> > new instructions you're generating read or clobber them.   (It might start 
> > mattering if you add support for additional forms of outlining, or Thumb1 
> > support, but this patch has neither.)
> I agree that there is no issue with SP until we modify it, I'll move that to 
> the right patch, for LR it is needed here, when doing thunk outlining the 
> call to the outlined function is a BL and if an instruction uses LR in the 
> outlined region we will have a problem.
Oh, right, we're effectively hoisting the definition of LR in thunk outlining.  
Makes sense.

For tail-call outlining, we don't care about LR, but I guess it's trickier to 
separate out those two cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(on|off) -- floating point control of associative math transformations

2020-05-05 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 262217.
mibintc retitled this revision from "Add support for #pragma clang fp 
reassociate(fast|off) -- floating point control of associative math 
transformations" to "Add support for #pragma clang fp reassociate(on|off) -- 
floating point control of associative math transformations".
mibintc edited the summary of this revision.
mibintc added a comment.

Here it is again with the on/off spelling


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGen/fp-reassoc-pragma.cpp
  clang/test/Parser/pragma-fp-contract.c
  clang/test/Parser/pragma-fp.cpp

Index: clang/test/Parser/pragma-fp.cpp
===
--- clang/test/Parser/pragma-fp.cpp
+++ clang/test/Parser/pragma-fp.cpp
@@ -1,14 +1,14 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s
 
 void test_0(int *List, int Length) {
-/* expected-error@+1 {{missing option; expected contract}} */
+/* expected-error@+1 {{missing option; expected 'contract' or 'reassociate'}} */
 #pragma clang fp
   for (int i = 0; i < Length; i++) {
 List[i] = i;
   }
 }
 void test_1(int *List, int Length) {
-/* expected-error@+1 {{invalid option 'blah'; expected contract}} */
+/* expected-error@+1 {{invalid option 'blah'; expected 'contract' or 'reassociate'}} */
 #pragma clang fp blah
   for (int i = 0; i < Length; i++) {
 List[i] = i;
@@ -24,7 +24,7 @@
 }
 
 void test_4(int *List, int Length) {
-/* expected-error@+1 {{unexpected argument 'while' to '#pragma clang fp contract'; expected 'on', 'fast' or 'off'}} */
+/* expected-error@+1 {{unexpected argument 'while' to '#pragma clang fp contract'; expected 'fast' or 'on' or 'off'}} */
 #pragma clang fp contract(while)
   for (int i = 0; i < Length; i++) {
 List[i] = i;
@@ -32,7 +32,7 @@
 }
 
 void test_5(int *List, int Length) {
-/* expected-error@+1 {{unexpected argument 'maybe' to '#pragma clang fp contract'; expected 'on', 'fast' or 'off'}} */
+/* expected-error@+1 {{unexpected argument 'maybe' to '#pragma clang fp contract'; expected 'fast' or 'on' or 'off'}} */
 #pragma clang fp contract(maybe)
   for (int i = 0; i < Length; i++) {
 List[i] = i;
Index: clang/test/Parser/pragma-fp-contract.c
===
--- clang/test/Parser/pragma-fp-contract.c
+++ clang/test/Parser/pragma-fp-contract.c
@@ -23,3 +23,18 @@
 // expected-error@+1 {{this pragma cannot appear in union declaration}}
 #pragma STDC FP_CONTRACT ON
 };
+
+float fp_reassoc_fail(float a, float b) {
+  // CHECK-LABEL: fp_reassoc_fail
+  // expected-error@+2{{'#pragma clang fp' can only appear at file scope or at the start of a compound statement}}
+  float c = a + b;
+#pragma clang fp reassociate(off)
+  return c - b;
+}
+
+float fp_reassoc_no_fast(float a, float b) {
+// CHECK-LABEL: fp_reassoc_no_fast
+// expected-error@+1{{unexpected argument 'fast' to '#pragma clang fp reassociate'; expected 'on' or 'off'}}
+#pragma clang fp reassociate(fast)
+  return a - b;
+}
Index: clang/test/CodeGen/fp-reassoc-pragma.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-reassoc-pragma.cpp
@@ -0,0 +1,92 @@
+// RUN: %clang_cc1 -O3 -triple %itanium_abi_triple -emit-llvm -o - %s | FileCheck %s
+// Simple case
+float fp_reassoc_simple(float a, float b, float c) {
+// CHECK: _Z17fp_reassoc_simplefff
+// CHECK: %[[A:.+]] = fadd reassoc float %b, %c
+// CHECK: %[[M:.+]] = fmul reassoc float %[[A]], %b
+// CHECK-NEXT: fadd reassoc float %[[M]], %c
+#pragma clang fp reassociate(on)
+  a = b + c;
+  return a * b + c;
+}
+
+// Reassoc pragma should only apply to its scope
+float fp_reassoc_scoped(float a, float b, float c) {
+  // CHECK: _Z17fp_reassoc_scopedfff
+  // CHECK: %[[M:.+]] = fmul float %a, %b
+  // CHECK-NEXT: fadd float %[[M]], %c
+  {
+#pragma clang fp reassociate(on)
+  }
+  return a * b + c;
+}
+
+// Reassoc pragma should apply to templates as well
+class Foo {};
+Foo operator+(Foo, Foo);
+template 
+T template_reassoc(T a, T b, T c) {
+#pragma clang fp reassociate(on)
+  return ((a + b) - c) + c;
+}
+
+float fp_reassoc_template(float a, float b, float c) {
+  // CHECK: _Z19fp_reassoc_templatefff
+  // CHECK: %[[A1:.+]] = fadd reassoc float %a, %b
+  // CHECK-NEXT: %[[A2:.+]] = fsub reassoc float %[[A1]], %c
+  // CHECK-NEXT: fadd reassoc float %[[A2]], %c
+  return template_reassoc(a, b, c);
+}
+
+// File Scoping should work across functions
+#pragma clang fp reassociate(on)
+float fp_file_scope_on(float a, 

[PATCH] D79445: [MSan] Pass MSan command line options under new pass manager

2020-05-05 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks created this revision.
aeubanks added reviewers: nemanjai, vitalybuka, leonardchan.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Properly forward TrackOrigins and Recover user options to the MSan pass under 
the new pass manager.
This makes the number of check-msan failures when 
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER is TRUE go from 52 to 2.

Based on https://reviews.llvm.org/D77249.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79445

Files:
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) 
{
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1016,8 +1016,11 @@
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-MPM.addPass(MemorySanitizerPass({}));
-MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+MPM.addPass(createModuleToFunctionPassAdaptor(
+MemorySanitizerPass({TrackOrigins, Recover, false})));
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
@@ -1236,12 +1239,16 @@
   FPM.addPass(BoundsCheckingPass());
 });
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-PB.registerPipelineStartEPCallback([](ModulePassManager ) {
-  MPM.addPass(MemorySanitizerPass({}));
-});
+int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
+bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
+PB.registerPipelineStartEPCallback(
+[TrackOrigins, Recover](ModulePassManager ) {
+  MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
+});
 PB.registerOptimizerLastEPCallback(
-[](FunctionPassManager , PassBuilder::OptimizationLevel Level) {
-  FPM.addPass(MemorySanitizerPass({}));
+[TrackOrigins, Recover](FunctionPassManager ,
+PassBuilder::OptimizationLevel Level) {
+  FPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
 });
   }
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79357: [SveEmitter] Add builtins for svdup and svindex

2020-05-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:8047
+Value *PFalse = Constant::getNullValue(PTrue->getType());
+Value *Sel = Builder.CreateSelect(CmpNE, PTrue, PFalse);
+return EmitSVEPredicateCast(Sel, cast(Ty));

sdesmalen wrote:
> efriedma wrote:
> > The select might not be the best approach. I mean, it's semantically 
> > correct, but the backend currently doesn't know how to lower a select like 
> > that.  And even if it did, it's probably better to avoid generating it for 
> > now.
> > 
> > Maybe this should use whilelo directly, since that's what the backend would 
> > eventually use anyway.
> > but the backend currently doesn't know how to lower a select like that
> Yes I noticed, that was the reason for D79356 (added as parent revision)
> 
> > And even if it did, it's probably better to avoid generating it for now.
> Is that because there are common optimisations on the select? I thought it 
> would be safe to use the 'full vector' form of `select` where the predicate 
> is a scalar (and both operands are splats)
Yes, the idea would just be to avoid common optimizations.  Maybe there aren't 
that many vector optimizations on a select with a scalar condition, though.  If 
it isn't blowing up, I guess it's fine.


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

https://reviews.llvm.org/D79357



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


[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-05-05 Thread Yvan Roux via Phabricator via cfe-commits
yroux updated this revision to Diff 262205.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.h
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/test/CodeGen/ARM/machine-outliner-tail.ll
  llvm/test/CodeGen/ARM/machine-outliner-thunk.ll
  llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
  llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir

Index: llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
@@ -0,0 +1,114 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=arm-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @outline_cpsr_r12_ok() #0 { ret void }
+  define void @dont_outline_cpsr_r12_1() #0 { ret void }
+  define void @dont_outline_cpsr_r12_2() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   outline_cpsr_r12_ok
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: outline_cpsr_r12_ok
+  ; CHECK: bb.0:
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  ; CHECK:   $r3 = MOVr $r12, 14 /* CC::al */, $noreg, $noreg
+  ; CHECK: bb.1:
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  ; CHECK:   $r4 = MOVr $r12, 14 /* CC::al */, $noreg, $noreg
+  bb.0:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+$r3 = MOVr $r12, 14, $noreg, $noreg
+  bb.1:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+$r4 = MOVr $r12, 14, $noreg, $noreg
+  bb.2:
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_cpsr_r12_1
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_cpsr_r12_1
+  ; CHECK:  bb.0:
+  ; CHECK:BL @OUTLINED_FUNCTION_1
+  ; CHECK:  bb.1:
+  ; CHECK:BL @OUTLINED_FUNCTION_1
+  ; CHECK-LABEL: bb.2:
+  ; CHECK-NOT: BL @OUTLINED_FUNCTION_1
+  bb.0:
+$r0 = MOVi 2, 14, $noreg, $noreg
+$r1 = MOVi 2, 14, $noreg, $noreg
+$r2 = MOVi 2, 14, $noreg, $noreg
+$r3 = MOVi 2, 14, $noreg, $noreg
+BL @z
+  bb.1:
+$r0 = MOVi 2, 14, $noreg, $noreg
+$r1 = MOVi 2, 14, $noreg, $noreg
+$r2 = MOVi 2, 14, $noreg, $noreg
+$r3 = MOVi 2, 14, $noreg, $noreg
+BL @z
+  bb.2:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 2, 14, $noreg, $noreg
+$r1 = MOVi 2, 14, $noreg, $noreg
+$r2 = MOVi 2, 14, $noreg, $noreg
+$r3 = MOVi 2, 14, $noreg, $noreg
+BL @z
+  bb.3:
+liveins: $cpsr, $r12
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_cpsr_r12_2
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_cpsr_r12_2
+  ; CHECK-NOT: BL @OUTLINED_FUNCTION
+  bb.0:
+liveins: $r12
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 3, 14, $noreg, $noreg
+$r1 = MOVi 3, 14, $noreg, $noreg
+$r2 = MOVi 3, 14, $noreg, $noreg
+$r3 = MOVi 3, 14, $noreg, $noreg
+BL @z
+  bb.1:
+liveins: $r12
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 3, 14, $noreg, $noreg
+$r1 = MOVi 3, 14, $noreg, $noreg
+$r2 = MOVi 3, 14, $noreg, $noreg
+$r3 = MOVi 3, 14, $noreg, $noreg
+BL @z
+  bb.2:
+liveins: $r12
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 3, 14, $noreg, $noreg
+$r1 = MOVi 3, 14, $noreg, $noreg
+$r2 = MOVi 3, 14, $noreg, $noreg
+$r3 = MOVi 3, 14, $noreg, $noreg
+BL @z
+  bb.3:
+BX_RET 14, $noreg
Index: llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
@@ -0,0 +1,140 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=thumbv7-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @dont_outline_asm() #0 { ret void }
+  define void @dont_outline_lr() #0 { ret void }
+  define void @dont_outline_it() #0 { ret void }
+  define void @dont_outline_pic() #0 { ret void }
+  define void @dont_outline_mve() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   

[PATCH] D79357: [SveEmitter] Add builtins for svdup and svindex

2020-05-05 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen marked 2 inline comments as done.
sdesmalen added inline comments.



Comment at: clang/include/clang/Basic/arm_sve.td:1050
 def SVCOMPACT: SInst<"svcompact[_{d}]",   "dPd",  "ilUiUlfd",
MergeNone, "aarch64_sve_compact">;
-//  SVDUP_LANE(to land in D78750)
+def SVDUP_LANE   : SInst<"svdup_lane[_{d}]",  "ddL",  "csilUcUsUiUlhfd", 
MergeNone, "aarch64_sve_tbl">; // Implemented using tbl
 def SVDUPQ_LANE  : SInst<"svdupq_lane[_{d}]", "ddn",  "csilUcUsUiUlhfd", 
MergeNone, "aarch64_sve_dupq_lane">;

efriedma wrote:
> "Implemented using tbl" isn't really a helpful comment.
> 
> I guess you're doing it this way so the lane doesn't have to be a constant?  
> (And then I guess you can optimize it in the backend.)
Yes that's right. I can probably clarify the comment a bit more.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:8047
+Value *PFalse = Constant::getNullValue(PTrue->getType());
+Value *Sel = Builder.CreateSelect(CmpNE, PTrue, PFalse);
+return EmitSVEPredicateCast(Sel, cast(Ty));

efriedma wrote:
> The select might not be the best approach. I mean, it's semantically correct, 
> but the backend currently doesn't know how to lower a select like that.  And 
> even if it did, it's probably better to avoid generating it for now.
> 
> Maybe this should use whilelo directly, since that's what the backend would 
> eventually use anyway.
> but the backend currently doesn't know how to lower a select like that
Yes I noticed, that was the reason for D79356 (added as parent revision)

> And even if it did, it's probably better to avoid generating it for now.
Is that because there are common optimisations on the select? I thought it 
would be safe to use the 'full vector' form of `select` where the predicate is 
a scalar (and both operands are splats)


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

https://reviews.llvm.org/D79357



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


[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

2020-05-05 Thread Yvan Roux via Phabricator via cfe-commits
yroux added a comment.

In D76066#2014697 , @samparker wrote:

> Thanks for adding the MVE changes, but I also still don't see any DSP tests, 
> i.e QADD, SADD16.


hmm... I was wrong w/r to DSP instructions Q and GE flags handling, I don't get 
what I did in my tests, but there is no info about CPSR in the MIR attached to 
these instructions.  So, you had a good feeling and I can disable them, but as 
Eli said in his comments we don't really need to worry about APCS but only to 
linker veneers and I don't think a linker would clear the sticky Q bit or touch 
the GE ones.

Do you think we can let it as it is ?




Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5607
+  // * Register R12(IP),
+  // * Condition codes (and thus the CPSR register)
+  //

efriedma wrote:
> If you control all the instructions that execute, you don't need to worry 
> about what the procedure call standard says.  You do need to worry about 
> linker veneers if the outlined function is in a different section, though.
> 
> So you need to worry about `R12`/`CPSR` on entry to the outlined function, 
> but not on exit from the outlined function.
Yes I agree and it is what is done here, I put the same comment as what was 
done on AArch64 to explain where it comes from, but as it is mentioned below we 
remove the candidate when these registers are live into or across, which means 
that we can outline cases where def and use are inside the outlined region or 
the def inside and the use after the exit as you said.

I've modify the machine-outliner-unsafe-registers.mir test in the update 
version I'll submit to exhibit this.



Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5753
+  // ahead and skip over them.
+  if (MI.isKill())
+return outliner::InstrType::Invisible;

samparker wrote:
> Should IMPLICIT_DEF instructions be considered invisible too?
Yes, I'll add it



Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5813
+  // Don't touch the link register
+  if (MI.readsRegister(ARM::LR, TRI) || MI.modifiesRegister(ARM::LR, TRI))
+return outliner::InstrType::Illegal;

efriedma wrote:
> Why do you need to forbid outlining code that touches LR or SP? None of the 
> new instructions you're generating read or clobber them.   (It might start 
> mattering if you add support for additional forms of outlining, or Thumb1 
> support, but this patch has neither.)
I agree that there is no issue with SP until we modify it, I'll move that to 
the right patch, for LR it is needed here, when doing thunk outlining the call 
to the outlined function is a BL and if an instruction uses LR in the outlined 
region we will have a problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066



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


[PATCH] D79440: Fix ForRangeCopyCheck not triggering on iterators returning elements by value in C++17.

2020-05-05 Thread Felix Berger via Phabricator via cfe-commits
flx created this revision.
flx added a reviewer: gribozavr2.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The AST is different in C++17 in that there is no MaterializeTemporaryExpr for 
in the AST for a loop variable that is initialized from an iterator that 
returns its elements by value.

Account for this by checking that the variable is not initialized by an 
operator* call that returns a value type.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79440

Files:
  clang-tools-extra/clang-tidy/performance/ForRangeCopyCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp


Index: clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
@@ -28,6 +28,7 @@
 };
 template 
 struct View {
+  View() = default;
   T begin() { return T(); }
   T begin() const { return T(); }
   T end() { return T(); }
@@ -270,3 +271,27 @@
   for (auto _ : View>()) {
   }
 }
+
+template  struct ValueReturningIterator {
+  void operator++() {}
+  T operator*() { return T(); }
+  bool operator!=(const ValueReturningIterator &) { return false; }
+  typedef const T _reference;
+};
+
+void negativeValueIterator() {
+  // Check does not trigger for iterators that return elements by value.
+  for (const S SS : View>()) {
+  }
+}
+
+View> createView(S) { return View>(); }
+
+void positiveValueIteratorUsedElseWhere() {
+  for (const S SS : createView(*ValueReturningIterator())) {
+// CHECK-MESSAGES: [[@LINE-1]]:16: warning: the loop variable's type is not
+// a reference type; this creates a copy in each iteration; consider making
+// this a reference [performance-for-range-copy] CHECK-FIXES: for (const S&
+// SS : createView(*ValueReturningIterator())) {
+  }
+}
Index: clang-tools-extra/clang-tidy/performance/ForRangeCopyCheck.cpp
===
--- clang-tools-extra/clang-tidy/performance/ForRangeCopyCheck.cpp
+++ clang-tools-extra/clang-tidy/performance/ForRangeCopyCheck.cpp
@@ -37,12 +37,18 @@
   // Match loop variables that are not references or pointers or are already
   // initialized through MaterializeTemporaryExpr which indicates a type
   // conversion.
-  auto LoopVar = varDecl(
-  hasType(qualType(
-  unless(anyOf(hasCanonicalType(anyOf(referenceType(), pointerType())),
-   hasDeclaration(namedDecl(
-   matchers::matchesAnyListedName(AllowedTypes))),
-  unless(hasInitializer(expr(hasDescendant(materializeTemporaryExpr());
+  auto HasReferenceOrPointerTypeOrIsAllowed = hasType(qualType(
+  unless(anyOf(hasCanonicalType(anyOf(referenceType(), pointerType())),
+   hasDeclaration(namedDecl(
+   matchers::matchesAnyListedName(AllowedTypes)));
+  auto IteratorReturnsValueType = cxxOperatorCallExpr(
+  hasOverloadedOperatorName("*"),
+  callee(
+  cxxMethodDecl(returns(unless(hasCanonicalType(referenceType()));
+  auto LoopVar =
+  varDecl(HasReferenceOrPointerTypeOrIsAllowed,
+  unless(hasInitializer(expr(hasDescendant(expr(anyOf(
+  materializeTemporaryExpr(), IteratorReturnsValueType)));
   Finder->addMatcher(cxxForRangeStmt(hasLoopVariable(LoopVar.bind("loopVar")))
  .bind("forRange"),
  this);


Index: clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-for-range-copy.cpp
@@ -28,6 +28,7 @@
 };
 template 
 struct View {
+  View() = default;
   T begin() { return T(); }
   T begin() const { return T(); }
   T end() { return T(); }
@@ -270,3 +271,27 @@
   for (auto _ : View>()) {
   }
 }
+
+template  struct ValueReturningIterator {
+  void operator++() {}
+  T operator*() { return T(); }
+  bool operator!=(const ValueReturningIterator &) { return false; }
+  typedef const T _reference;
+};
+
+void negativeValueIterator() {
+  // Check does not trigger for iterators that return elements by value.
+  for (const S SS : View>()) {
+  }
+}
+
+View> createView(S) { return View>(); }
+
+void positiveValueIteratorUsedElseWhere() {
+  for (const S SS : createView(*ValueReturningIterator())) {
+// CHECK-MESSAGES: [[@LINE-1]]:16: warning: the loop variable's type is not
+// a reference type; this creates a copy in each iteration; consider making
+// this a reference [performance-for-range-copy] CHECK-FIXES: for (const S&
+// SS : createView(*ValueReturningIterator())) {
+  }
+}
Index: 

[PATCH] D79121: Add nomerge function attribute to clang

2020-05-05 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu marked an inline comment as done.
zequanwu added inline comments.



Comment at: clang/lib/Sema/SemaStmtAttr.cpp:178
+return true;
+  return llvm::any_of(S->children(), hasCallExpr);
+}

rsmith wrote:
> This will recurse into too much (eg, the bodies of lambdas and blocks, and 
> unevaluated operands). It would be better to make this a 
> `ConstEvaluatedExprVisitor` instead (see 
> include/clang/AST/EvaluatedExprVisitor.h).
Do you mean to create a subclass of `ConstEvaluatedExprVisitor` to find if the 
statement has call expression?


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

https://reviews.llvm.org/D79121



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


[PATCH] D79419: [clang/clang-tools-extra] Fix BZ44437 - add_new_check.py does not work with Python 3

2020-05-05 Thread Daniel Sanders via Phabricator via cfe-commits
dsanders accepted this revision.
dsanders added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79419



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


[PATCH] D79118: Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs

2020-05-05 Thread Erich Keane via Phabricator via cfe-commits
erichkeane marked an inline comment as done.
erichkeane added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4938
+if (EIT->getNumBits() > 128)
+  return getNaturalAlignIndirect(Ty, /*ByVal=*/true);
+

rjmccall wrote:
> erichkeane wrote:
> > rjmccall wrote:
> > > rjmccall wrote:
> > > > erichkeane wrote:
> > > > > rjmccall wrote:
> > > > > > Does this need to consider the aggregate-as-array logic below?
> > > > > I'm not sure what you mean by this?  Are you suggesting I 
> > > > > could/should pass this as an array instead of indirectly?
> > > > My interpretation is that in general you're lowering large a `_ExtInt` 
> > > > like a struct with a bunch of integer members in it.  My understanding 
> > > > is that, for this target, that would make it a homogeneous aggregate 
> > > > eligible for the special treatment given to certain aggregate types 
> > > > below.  I don't know what that corresponds to at the code-emission 
> > > > level.
> > > This seems to work, although it's unfortunate that it duplicates some of 
> > > the existing behavior.  Do we also need to modify 
> > > `isHomogeneousAggregate` to consider `ExtInts`?  And if we do, does that 
> > > avoid any of the duplicate logic here?
> > I think doing that would result in altering a number of other targets as 
> > well (thats not a PPC specific function I think?). 
> > 
> > While there IS a little duplication, it is just the 5 lines that calculates 
> > the array and coerces it. Otherwise the logic is just slightly different 
> > enough I don't think it would save much.
> > 
> > That said, perhaps there is value in extracting those 5 lines or so into a 
> > function.  I'll give that a shot.
> Yeah, the function isn't PPC-specific.  The question is what the right rules 
> are for homogeneous aggregates when aggregates contain ExtInt types.  For 
> PPC64 ELFv2, that... oh right, it only applies to floating-point and vector 
> types.  So I'm sorry, I led you on a false path here; we should not be trying 
> to apply this logic to ExtInt types at all.
So I should switch it back to direct/indirect like earlier?  That I can do.


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

https://reviews.llvm.org/D79118



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


[PATCH] D79118: Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIs

2020-05-05 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 262190.
erichkeane added a comment.

Revert PPC64 changes back to direct/indirect.


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

https://reviews.llvm.org/D79118

Files:
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/ARC.h
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Basic/Targets/Hexagon.h
  clang/lib/Basic/Targets/Lanai.h
  clang/lib/Basic/Targets/Mips.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/PNaCl.h
  clang/lib/Basic/Targets/PPC.h
  clang/lib/Basic/Targets/RISCV.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/Sparc.h
  clang/lib/Basic/Targets/SystemZ.h
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Basic/Targets/XCore.h
  clang/lib/CodeGen/ABIInfo.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/ext-int-cc.c
  clang/test/CodeGen/ext-int-sanitizer.cpp
  clang/test/CodeGenCXX/ext-int.cpp
  clang/test/Sema/ext-int-not-supported.c

Index: clang/test/Sema/ext-int-not-supported.c
===
--- clang/test/Sema/ext-int-not-supported.c
+++ /dev/null
@@ -1,5 +0,0 @@
-// RUN: %clang_cc1 -triple armv7 -fsyntax-only -verify %s
-
-void foo() {
-  _ExtInt(33) a; // expected-error{{_ExtInt is not supported on this target}}
-}
Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -98,7 +98,7 @@
 };
 
 void UnderlyingTypeUsage(AsEnumUnderlyingType Param) {
-  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i16 %
+  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i9 signext %
   // WIN: define dso_local void @"?UnderlyingTypeUsage@@YAXW4AsEnumUnderlyingType@@@Z"(i9 %
   AsEnumUnderlyingType Var;
   // CHECK: alloca i9, align 2
Index: clang/test/CodeGen/ext-int-sanitizer.cpp
===
--- clang/test/CodeGen/ext-int-sanitizer.cpp
+++ clang/test/CodeGen/ext-int-sanitizer.cpp
@@ -145,8 +145,7 @@
 
   // Also triggers signed integer overflow.
   E / E;
-  // CHECK: %[[E1LOAD:.+]] = load i11
-  // CHECK: store i11 %[[E1LOAD]], i11* %[[EADDR:.+]]
+  // CHECK: %[[EADDR:.+]] = alloca i11
   // CHECK: %[[E:.+]] = load i11, i11* %[[EADDR]]
   // CHECK: %[[E2:.+]] = load i11, i11* %[[EADDR]]
   // CHECK: %[[NEZERO:.+]] = icmp ne i11 %[[E2]], 0
@@ -163,8 +162,7 @@
 // CHECK: define void @_Z6ShiftsU7_ExtIntILi9EEi
 void Shifts(_ExtInt(9) E) {
   E >> E;
-  // CHECK: %[[E1LOAD:.+]] = load i9, i9*
-  // CHECK: store i9 %[[E1LOAD]], i9* %[[EADDR:.+]]
+  // CHECK: %[[EADDR:.+]] = alloca i9
   // CHECK: %[[LHSE:.+]] = load i9, i9* %[[EADDR]]
   // CHECK: %[[RHSE:.+]] = load i9, i9* %[[EADDR]]
   // CHECK: %[[CMP:.+]] = icmp ule i9 %[[RHSE]], 8
@@ -227,8 +225,7 @@
  unsigned _ExtInt(23) SmallE,
  unsigned _ExtInt(35) BigE) {
   u = SmallE + SmallE;
-  // CHECK: %[[LOADBIGGESTE2:.+]] = load i23
-  // CHECK: store i23 %[[LOADBIGGESTE2]], i23* %[[BIGGESTEADDR:.+]]
+  // CHECK: %[[BIGGESTEADDR:.+]] = alloca i23
   // CHECK: %[[LOADE1:.+]] = load i23, i23* %[[BIGGESTEADDR]]
   // CHECK: %[[LOADE2:.+]] = load i23, i23* %[[BIGGESTEADDR]]
   // CHECK: %[[OFCALL:.+]] = call { i23, i1 } @llvm.uadd.with.overflow.i23(i23 %[[LOADE1]], i23 %[[LOADE2]])
Index: clang/test/CodeGen/ext-int-cc.c
===
--- clang/test/CodeGen/ext-int-cc.c
+++ clang/test/CodeGen/ext-int-cc.c
@@ -2,6 +2,32 @@
 // RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN64
 // RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=LIN32
 // RUN: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN32
+// RUN: %clang_cc1 -triple le32-nacl -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=NACL
+// RUN: %clang_cc1 -triple nvptx64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=NVPTX64
+// RUN: %clang_cc1 -triple nvptx -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=NVPTX
+// RUN: %clang_cc1 -triple sparcv9 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPARCV9
+// RUN: %clang_cc1 -triple sparc -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPARC
+// RUN: %clang_cc1 -triple mips64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=MIPS64
+// RUN: %clang_cc1 -triple mips -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=MIPS
+// RUN: %clang_cc1 -triple spir64 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s --check-prefixes=SPIR64
+// RUN: %clang_cc1 

[PATCH] D79232: [analyzer] Refactor range inference for symbolic expressions

2020-05-05 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:127-128
+  if (a > 10) {
+clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
+  }

vsavchenko wrote:
> NoQ wrote:
> > How can both of these be false? o.o
> Yeah :) I realized how weird it is.
> Anything is possible in the land of infeasible ranges.
> 
> I changed a comment there to address this
I mean, this pretty much never happened before. How are you not tripping on [[ 
https://github.com/llvm/llvm-project/blob/1a4421a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h#L100
 | this assert ]]? (probably it's simply been disabled in normal debug builds 
now that it's under "expensive checks")

The correct thing to do is to detect the paradox earlier and mark the path as 
infeasible. What prevents us from doing it right away here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79232



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


[PATCH] D79394: [clang][codegen] Refactor argument loading in function prolog. NFC.

2020-05-05 Thread Michael Liao via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG276c8dde0b58: [clang][codegen] Refactor argument loading in 
function prolog. NFC. (authored by hliao).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79394

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenFunction.h

Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -4356,7 +4356,7 @@
   ///
   /// \param AI - The first function argument of the expansion.
   void ExpandTypeFromArgs(QualType Ty, LValue Dst,
-  SmallVectorImpl::iterator );
+  llvm::Function::arg_iterator );
 
   /// ExpandTypeToArgs - Expand an CallArg \arg Arg, with the LLVM type for \arg
   /// Ty, into individual arguments on the provided vector \arg IRCallArgs,
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1016,8 +1016,8 @@
   }
 }
 
-void CodeGenFunction::ExpandTypeFromArgs(
-QualType Ty, LValue LV, SmallVectorImpl::iterator ) {
+void CodeGenFunction::ExpandTypeFromArgs(QualType Ty, LValue LV,
+ llvm::Function::arg_iterator ) {
   assert(LV.isSimple() &&
  "Unexpected non-simple lvalue during struct expansion.");
 
@@ -1046,17 +1046,17 @@
   ExpandTypeFromArgs(FD->getType(), SubLV, AI);
 }
   } else if (isa(Exp.get())) {
-auto realValue = *AI++;
-auto imagValue = *AI++;
+auto realValue = &*AI++;
+auto imagValue = &*AI++;
 EmitStoreOfComplex(ComplexPairTy(realValue, imagValue), LV, /*init*/ true);
   } else {
 // Call EmitStoreOfScalar except when the lvalue is a bitfield to emit a
 // primitive store.
 assert(isa(Exp.get()));
 if (LV.isBitField())
-  EmitStoreThroughLValue(RValue::get(*AI++), LV);
+  EmitStoreThroughLValue(RValue::get(&*AI++), LV);
 else
-  EmitStoreOfScalar(*AI++, LV);
+  EmitStoreOfScalar(&*AI++, LV);
   }
 }
 
@@ -2323,19 +2323,13 @@
   // simplify.
 
   ClangToLLVMArgMapping IRFunctionArgs(CGM.getContext(), FI);
-  // Flattened function arguments.
-  SmallVector FnArgs;
-  FnArgs.reserve(IRFunctionArgs.totalIRArgs());
-  for (auto  : Fn->args()) {
-FnArgs.push_back();
-  }
-  assert(FnArgs.size() == IRFunctionArgs.totalIRArgs());
+  assert(Fn->arg_size() == IRFunctionArgs.totalIRArgs());
 
   // If we're using inalloca, all the memory arguments are GEPs off of the last
   // parameter, which is a pointer to the complete memory area.
   Address ArgStruct = Address::invalid();
   if (IRFunctionArgs.hasInallocaArg()) {
-ArgStruct = Address(FnArgs[IRFunctionArgs.getInallocaArgNo()],
+ArgStruct = Address(Fn->getArg(IRFunctionArgs.getInallocaArgNo()),
 FI.getArgStructAlignment());
 
 assert(ArgStruct.getType() == FI.getArgStruct()->getPointerTo());
@@ -2343,7 +2337,7 @@
 
   // Name the struct return parameter.
   if (IRFunctionArgs.hasSRetArg()) {
-auto AI = cast(FnArgs[IRFunctionArgs.getSRetArgNo()]);
+auto AI = Fn->getArg(IRFunctionArgs.getSRetArgNo());
 AI->setName("agg.result");
 AI->addAttr(llvm::Attribute::NoAlias);
   }
@@ -2394,7 +2388,8 @@
 
 case ABIArgInfo::Indirect: {
   assert(NumIRArgs == 1);
-  Address ParamAddr = Address(FnArgs[FirstIRArg], ArgI.getIndirectAlign());
+  Address ParamAddr =
+  Address(Fn->getArg(FirstIRArg), ArgI.getIndirectAlign());
 
   if (!hasScalarEvaluationKind(Ty)) {
 // Aggregates and complex variables are accessed by reference.  All we
@@ -2436,8 +2431,7 @@
   ArgI.getCoerceToType() == ConvertType(Ty) &&
   ArgI.getDirectOffset() == 0) {
 assert(NumIRArgs == 1);
-llvm::Value *V = FnArgs[FirstIRArg];
-auto AI = cast(V);
+auto AI = Fn->getArg(FirstIRArg);
 
 if (const ParmVarDecl *PVD = dyn_cast(Arg)) {
   if (getNonNullAttr(CurCodeDecl, PVD, PVD->getType(),
@@ -2499,6 +2493,7 @@
 
 // LLVM expects swifterror parameters to be used in very restricted
 // ways.  Copy the value into a less-restricted temporary.
+llvm::Value *V = AI;
 if (FI.getExtParameterInfo(ArgNo).getABI()
   == ParameterABI::SwiftErrorResult) {
   QualType pointeeTy = Ty->getPointeeType();
@@ -2560,7 +2555,7 @@
 
 assert(STy->getNumElements() == NumIRArgs);
 for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
-  auto AI = FnArgs[FirstIRArg + i];
+  auto AI = Fn->getArg(FirstIRArg + i);
   AI->setName(Arg->getName() + ".coerce" + Twine(i));
   Address EltPtr = Builder.CreateStructGEP(AddrToStoreInto, i);
   

[PATCH] D78660: [SemaObjC] Add a warning for dictionary literals with duplicate keys

2020-05-05 Thread Erik Pilkington via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG873e27909539: [SemaObjC] Add a warning for dictionary 
literals with duplicate keys (authored by erik.pilkington).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78660

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/SemaObjC/dictionary-literal-duplicates.m

Index: clang/test/SemaObjC/dictionary-literal-duplicates.m
===
--- /dev/null
+++ clang/test/SemaObjC/dictionary-literal-duplicates.m
@@ -0,0 +1,62 @@
+// RUN: %clang_cc1 -Wno-objc-root-class %s -verify
+// RUN: %clang_cc1 -xobjective-c++ -Wno-objc-root-class %s -verify
+
+#define YES __objc_yes
+#define NO __objc_no
+
+@interface NSNumber
++(instancetype)numberWithChar:(char)value;
++(instancetype)numberWithInt:(int)value;
++(instancetype)numberWithDouble:(double)value;
++(instancetype)numberWithBool:(unsigned char)value;
++(instancetype)numberWithUnsignedLong:(unsigned long)value;
++(instancetype)numberWithLongLong:(long long) value;
++(instancetype)numberWithUnsignedInt:(unsigned)value;
+@end
+
+@interface NSString
+@end
+
+@interface NSDictionary
++ (instancetype)dictionaryWithObjects:(const id[])objects
+  forKeys:(const id[])keys
+count:(unsigned long)cnt;
+@end
+
+void test() {
+  NSDictionary *t1 = @{
+@"foo" : @0, // expected-note 2 {{previous equal key is here}}
+@"foo" : @0, // expected-warning{{duplicate key in dictionary literal}}
+@("foo") : @0, // expected-warning{{duplicate key in dictionary literal}}
+@"foo\0" : @0,
+
+@1 : @0, // expected-note + {{previous equal key is here}}
+@YES : @0, // expected-warning{{duplicate key in dictionary literal}}
+@'\1' : @0, // expected-warning{{duplicate key in dictionary literal}}
+@1 : @0, // expected-warning{{duplicate key in dictionary literal}}
+@1ul : @0, // expected-warning{{duplicate key in dictionary literal}}
+@1ll : @0, // expected-warning{{duplicate key in dictionary literal}}
+#ifdef __cplusplus
+@true : @0, // expected-warning{{duplicate key in dictionary literal}}
+#endif
+@1.0 : @0, // FIXME: should warn
+
+@-1 : @0, // expected-note + {{previous equal key is here}}
+@4294967295u : @0, // no warning
+@-1ll : @0, // expected-warning{{duplicate key in dictionary literal}}
+@(NO-YES) : @0, // expected-warning{{duplicate key in dictionary literal}}
+  };
+}
+
+#ifdef __cplusplus
+template  void variadic(Ts... ts) {
+  NSDictionary *nd = @{
+ts : @0 ...,
+@0 : ts ... // expected-warning 2 {{duplicate key in dictionary literal}} expected-note 2 {{previous equal key is here}}
+  };
+}
+
+void call_variadic() {
+  variadic(@0, @1, @2); // expected-note {{in instantiation}}
+}
+#endif
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -894,6 +894,62 @@
 ArrayWithObjectsMethod, SR));
 }
 
+/// Check for duplicate keys in an ObjC dictionary literal. For instance:
+///   NSDictionary *nd = @{ @"foo" : @"bar", @"foo" : @"baz" };
+static void
+CheckObjCDictionaryLiteralDuplicateKeys(Sema ,
+ObjCDictionaryLiteral *Literal) {
+  if (Literal->isValueDependent() || Literal->isTypeDependent())
+return;
+
+  // NSNumber has quite relaxed equality semantics (for instance, @YES is
+  // considered equal to @1.0). For now, ignore floating points and just do a
+  // bit-width and sign agnostic integer compare.
+  struct APSIntCompare {
+bool operator()(const llvm::APSInt , const llvm::APSInt ) const {
+  return llvm::APSInt::compareValues(LHS, RHS) < 0;
+}
+  };
+
+  llvm::DenseMap StringKeys;
+  std::map IntegralKeys;
+
+  auto checkOneKey = [&](auto , const auto , SourceLocation Loc) {
+auto Pair = Map.insert({Key, Loc});
+if (!Pair.second) {
+  S.Diag(Loc, diag::warn_nsdictionary_duplicate_key);
+  S.Diag(Pair.first->second, diag::note_nsdictionary_duplicate_key_here);
+}
+  };
+
+  for (unsigned Idx = 0, End = Literal->getNumElements(); Idx != End; ++Idx) {
+Expr *Key = Literal->getKeyValueElement(Idx).Key->IgnoreParenImpCasts();
+
+if (auto *StrLit = dyn_cast(Key)) {
+  StringRef Bytes = StrLit->getString()->getBytes();
+  SourceLocation Loc = StrLit->getExprLoc();
+  checkOneKey(StringKeys, Bytes, Loc);
+}
+
+if (auto *BE = dyn_cast(Key)) {
+  Expr *Boxed = BE->getSubExpr();
+  SourceLocation Loc = BE->getExprLoc();
+
+  // Check for @("foo").
+  if (auto *Str = dyn_cast(Boxed->IgnoreParenImpCasts())) {
+checkOneKey(StringKeys, Str->getBytes(), Loc);
+

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-05 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added a comment.

I'm not familiar with ObjC, but hope this helps:

  % cat ~/example.mm   # left as-is by clang-format without D79354  
   
  (int)f : (int)arg {
struct A as[] = {{a11, a12},  //
 {a21, a22},  //
 {nil, 0}};
return 0;
  }
  % bin/clang-format ~/example.mm  # clang-format with D79354
  (int)f : (int)arg {
struct A as[] = {
  {a11, a12}, //
  {a21, a22}, //
  {
nil, 0
  }
};
return 0;
  }
  % 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79354



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


[PATCH] D79395: [clang][codegen] Hoist parameter attribute setting in function prolog.

2020-05-05 Thread Michael Liao via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9142c0b46bfe: [clang][codegen] Hoist parameter attribute 
setting in function prolog. (authored by hliao).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79395

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu


Index: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
@@ -67,3 +67,10 @@
   t.x[0][0] += 1.f;
   t.x[1][0] += 2.f;
 }
+
+// Check that coerced pointers retain the noalias attribute when qualified 
with __restrict.
+// CHECK: define amdgpu_kernel void @_Z7kernel7Pi(i32 addrspace(1)* noalias 
%x.coerce)
+// HOST: define void @_Z22__device_stub__kernel7Pi(i32* noalias %x)
+__global__ void kernel7(int *__restrict x) {
+  x[0]++;
+}
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2425,15 +2425,18 @@
 
 case ABIArgInfo::Extend:
 case ABIArgInfo::Direct: {
-
-  // If we have the trivial case, handle it with no muss and fuss.
-  if (!isa(ArgI.getCoerceToType()) &&
-  ArgI.getCoerceToType() == ConvertType(Ty) &&
-  ArgI.getDirectOffset() == 0) {
+  auto AI = Fn->getArg(FirstIRArg);
+  llvm::Type *LTy = ConvertType(Arg->getType());
+
+  // Prepare parameter attributes. So far, only attributes for pointer
+  // parameters are prepared. See
+  // http://llvm.org/docs/LangRef.html#paramattrs.
+  if (ArgI.getDirectOffset() == 0 && LTy->isPointerTy() &&
+  ArgI.getCoerceToType()->isPointerTy()) {
 assert(NumIRArgs == 1);
-auto AI = Fn->getArg(FirstIRArg);
 
 if (const ParmVarDecl *PVD = dyn_cast(Arg)) {
+  // Set `nonnull` attribute if any.
   if (getNonNullAttr(CurCodeDecl, PVD, PVD->getType(),
  PVD->getFunctionScopeIndex()) &&
   !CGM.getCodeGenOpts().NullPointerIsValid)
@@ -2471,6 +2474,7 @@
   AI->addAttr(llvm::Attribute::NonNull);
   }
 
+  // Set `align` attribute if any.
   const auto *AVAttr = PVD->getAttr();
   if (!AVAttr)
 if (const auto *TOTy = dyn_cast(OTy))
@@ -2488,8 +2492,17 @@
   }
 }
 
+// Set 'noalias' if an argument type has the `restrict` qualifier.
 if (Arg->getType().isRestrictQualified())
   AI->addAttr(llvm::Attribute::NoAlias);
+  }
+
+  // Prepare the argument value. If we have the trivial case, handle it
+  // with no muss and fuss.
+  if (!isa(ArgI.getCoerceToType()) &&
+  ArgI.getCoerceToType() == ConvertType(Ty) &&
+  ArgI.getDirectOffset() == 0) {
+assert(NumIRArgs == 1);
 
 // LLVM expects swifterror parameters to be used in very restricted
 // ways.  Copy the value into a less-restricted temporary.


Index: clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
@@ -67,3 +67,10 @@
   t.x[0][0] += 1.f;
   t.x[1][0] += 2.f;
 }
+
+// Check that coerced pointers retain the noalias attribute when qualified with __restrict.
+// CHECK: define amdgpu_kernel void @_Z7kernel7Pi(i32 addrspace(1)* noalias %x.coerce)
+// HOST: define void @_Z22__device_stub__kernel7Pi(i32* noalias %x)
+__global__ void kernel7(int *__restrict x) {
+  x[0]++;
+}
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2425,15 +2425,18 @@
 
 case ABIArgInfo::Extend:
 case ABIArgInfo::Direct: {
-
-  // If we have the trivial case, handle it with no muss and fuss.
-  if (!isa(ArgI.getCoerceToType()) &&
-  ArgI.getCoerceToType() == ConvertType(Ty) &&
-  ArgI.getDirectOffset() == 0) {
+  auto AI = Fn->getArg(FirstIRArg);
+  llvm::Type *LTy = ConvertType(Arg->getType());
+
+  // Prepare parameter attributes. So far, only attributes for pointer
+  // parameters are prepared. See
+  // http://llvm.org/docs/LangRef.html#paramattrs.
+  if (ArgI.getDirectOffset() == 0 && LTy->isPointerTy() &&
+  ArgI.getCoerceToType()->isPointerTy()) {
 assert(NumIRArgs == 1);
-auto AI = Fn->getArg(FirstIRArg);
 
 if (const ParmVarDecl *PVD = dyn_cast(Arg)) {
+  // Set `nonnull` attribute if any.
   if (getNonNullAttr(CurCodeDecl, PVD, PVD->getType(),
  

[PATCH] D79334: [clang-tidy]: Add cert-str34-c alias for bugprone-signed-char-misuse.

2020-05-05 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some small nits with the documentation.




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-signed-char-misuse.rst:117
+
+  When non-zero, the check will warn on ``signed char``/``unsigned char`` 
comparison
+  otherwise this use case is ignored. By default, this option is set to ``1``.

non-zero -> nonzero
comparison -> comparisons,
(with the plural and comma)



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-signed-char-misuse.rst:118
+  When non-zero, the check will warn on ``signed char``/``unsigned char`` 
comparison
+  otherwise this use case is ignored. By default, this option is set to ``1``.

this use case is -> these comparisons are



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-str34-c.rst:6
+cert-str34-c
+==
+

The underlining here looks too long.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79334



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


[PATCH] D79232: [analyzer] Refactor range inference for symbolic expressions

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:127-128
+  if (a > 10) {
+clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
+  }

NoQ wrote:
> How can both of these be false? o.o
Yeah :) I realized how weird it is.
Anything is possible in the land of infeasible ranges.

I changed a comment there to address this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79232



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


[PATCH] D79244: [Sema] Put existing warning under -Wexcess-initializers

2020-05-05 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79244



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


[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

2020-05-05 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

In D79354#2020722 , @krasimir wrote:

> I have an example where this goes wrong in ObjC (modulo indentation):
>
> I think we should try harder to detect the beginning of an attribute 
> specifier. I think there may be a helper for that somewhere in clang-format.


could you give me your .clang-format settings standard LLVM gives me

  struct Stuff stuff[] = {{key, value}, // comment
  {key, value}, // comment
  {key, value}, // comment
  {key, value}, {key, value}, {nil, 0}};


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79354



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


[clang] 276c8dd - [clang][codegen] Refactor argument loading in function prolog. NFC.

2020-05-05 Thread Michael Liao via cfe-commits

Author: Michael Liao
Date: 2020-05-05T15:31:51-04:00
New Revision: 276c8dde0b58cfe29035448a27e16eff9fcf2a5a

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

LOG: [clang][codegen] Refactor argument loading in function prolog. NFC.

Summary:
- Skip copying function arguments and unnecessary casting by using them
  directly.

Reviewers: rjmccall, kerbowa, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CodeGenFunction.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 55f106e7c300..44f298892ecf 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -1016,8 +1016,8 @@ static void forConstantArrayExpansion(CodeGenFunction 
,
   }
 }
 
-void CodeGenFunction::ExpandTypeFromArgs(
-QualType Ty, LValue LV, SmallVectorImpl::iterator ) {
+void CodeGenFunction::ExpandTypeFromArgs(QualType Ty, LValue LV,
+ llvm::Function::arg_iterator ) {
   assert(LV.isSimple() &&
  "Unexpected non-simple lvalue during struct expansion.");
 
@@ -1046,17 +1046,17 @@ void CodeGenFunction::ExpandTypeFromArgs(
   ExpandTypeFromArgs(FD->getType(), SubLV, AI);
 }
   } else if (isa(Exp.get())) {
-auto realValue = *AI++;
-auto imagValue = *AI++;
+auto realValue = &*AI++;
+auto imagValue = &*AI++;
 EmitStoreOfComplex(ComplexPairTy(realValue, imagValue), LV, /*init*/ true);
   } else {
 // Call EmitStoreOfScalar except when the lvalue is a bitfield to emit a
 // primitive store.
 assert(isa(Exp.get()));
 if (LV.isBitField())
-  EmitStoreThroughLValue(RValue::get(*AI++), LV);
+  EmitStoreThroughLValue(RValue::get(&*AI++), LV);
 else
-  EmitStoreOfScalar(*AI++, LV);
+  EmitStoreOfScalar(&*AI++, LV);
   }
 }
 
@@ -2323,19 +2323,13 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
   // simplify.
 
   ClangToLLVMArgMapping IRFunctionArgs(CGM.getContext(), FI);
-  // Flattened function arguments.
-  SmallVector FnArgs;
-  FnArgs.reserve(IRFunctionArgs.totalIRArgs());
-  for (auto  : Fn->args()) {
-FnArgs.push_back();
-  }
-  assert(FnArgs.size() == IRFunctionArgs.totalIRArgs());
+  assert(Fn->arg_size() == IRFunctionArgs.totalIRArgs());
 
   // If we're using inalloca, all the memory arguments are GEPs off of the last
   // parameter, which is a pointer to the complete memory area.
   Address ArgStruct = Address::invalid();
   if (IRFunctionArgs.hasInallocaArg()) {
-ArgStruct = Address(FnArgs[IRFunctionArgs.getInallocaArgNo()],
+ArgStruct = Address(Fn->getArg(IRFunctionArgs.getInallocaArgNo()),
 FI.getArgStructAlignment());
 
 assert(ArgStruct.getType() == FI.getArgStruct()->getPointerTo());
@@ -2343,7 +2337,7 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
 
   // Name the struct return parameter.
   if (IRFunctionArgs.hasSRetArg()) {
-auto AI = cast(FnArgs[IRFunctionArgs.getSRetArgNo()]);
+auto AI = Fn->getArg(IRFunctionArgs.getSRetArgNo());
 AI->setName("agg.result");
 AI->addAttr(llvm::Attribute::NoAlias);
   }
@@ -2394,7 +2388,8 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
 
 case ABIArgInfo::Indirect: {
   assert(NumIRArgs == 1);
-  Address ParamAddr = Address(FnArgs[FirstIRArg], ArgI.getIndirectAlign());
+  Address ParamAddr =
+  Address(Fn->getArg(FirstIRArg), ArgI.getIndirectAlign());
 
   if (!hasScalarEvaluationKind(Ty)) {
 // Aggregates and complex variables are accessed by reference.  All we
@@ -2436,8 +2431,7 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
   ArgI.getCoerceToType() == ConvertType(Ty) &&
   ArgI.getDirectOffset() == 0) {
 assert(NumIRArgs == 1);
-llvm::Value *V = FnArgs[FirstIRArg];
-auto AI = cast(V);
+auto AI = Fn->getArg(FirstIRArg);
 
 if (const ParmVarDecl *PVD = dyn_cast(Arg)) {
   if (getNonNullAttr(CurCodeDecl, PVD, PVD->getType(),
@@ -2499,6 +2493,7 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
 
 // LLVM expects swifterror parameters to be used in very restricted
 // ways.  Copy the value into a less-restricted temporary.
+llvm::Value *V = AI;
 if (FI.getExtParameterInfo(ArgNo).getABI()
   == ParameterABI::SwiftErrorResult) {
   QualType pointeeTy = Ty->getPointeeType();
@@ -2560,7 +2555,7 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
 
 assert(STy->getNumElements() == NumIRArgs);
 for (unsigned i = 0, e = STy->getNumElements(); 

[clang] 9142c0b - [clang][codegen] Hoist parameter attribute setting in function prolog.

2020-05-05 Thread Michael Liao via cfe-commits

Author: Michael Liao
Date: 2020-05-05T15:31:51-04:00
New Revision: 9142c0b46bfea13d9348ab3d1d706a10ad9e5c8e

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

LOG: [clang][codegen] Hoist parameter attribute setting in function prolog.

Summary:
- If the coerced type is still a pointer, it should be set with proper
  parameter attributes, such as `noalias`, `nonnull`, and etc. Hoist
  that (pointer) parameter attribute setting so that the coerced pointer
  parameter could be marked properly.

Depends on D79394

Reviewers: rjmccall, kerbowa, yaxunl

Subscribers: jvesely, nhaehnle, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 44f298892ecf..e336741d9111 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2425,15 +2425,18 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
 
 case ABIArgInfo::Extend:
 case ABIArgInfo::Direct: {
-
-  // If we have the trivial case, handle it with no muss and fuss.
-  if (!isa(ArgI.getCoerceToType()) &&
-  ArgI.getCoerceToType() == ConvertType(Ty) &&
-  ArgI.getDirectOffset() == 0) {
+  auto AI = Fn->getArg(FirstIRArg);
+  llvm::Type *LTy = ConvertType(Arg->getType());
+
+  // Prepare parameter attributes. So far, only attributes for pointer
+  // parameters are prepared. See
+  // http://llvm.org/docs/LangRef.html#paramattrs.
+  if (ArgI.getDirectOffset() == 0 && LTy->isPointerTy() &&
+  ArgI.getCoerceToType()->isPointerTy()) {
 assert(NumIRArgs == 1);
-auto AI = Fn->getArg(FirstIRArg);
 
 if (const ParmVarDecl *PVD = dyn_cast(Arg)) {
+  // Set `nonnull` attribute if any.
   if (getNonNullAttr(CurCodeDecl, PVD, PVD->getType(),
  PVD->getFunctionScopeIndex()) &&
   !CGM.getCodeGenOpts().NullPointerIsValid)
@@ -2471,6 +2474,7 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
   AI->addAttr(llvm::Attribute::NonNull);
   }
 
+  // Set `align` attribute if any.
   const auto *AVAttr = PVD->getAttr();
   if (!AVAttr)
 if (const auto *TOTy = dyn_cast(OTy))
@@ -2488,8 +2492,17 @@ void CodeGenFunction::EmitFunctionProlog(const 
CGFunctionInfo ,
   }
 }
 
+// Set 'noalias' if an argument type has the `restrict` qualifier.
 if (Arg->getType().isRestrictQualified())
   AI->addAttr(llvm::Attribute::NoAlias);
+  }
+
+  // Prepare the argument value. If we have the trivial case, handle it
+  // with no muss and fuss.
+  if (!isa(ArgI.getCoerceToType()) &&
+  ArgI.getCoerceToType() == ConvertType(Ty) &&
+  ArgI.getDirectOffset() == 0) {
+assert(NumIRArgs == 1);
 
 // LLVM expects swifterror parameters to be used in very restricted
 // ways.  Copy the value into a less-restricted temporary.

diff  --git a/clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu 
b/clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
index 6e4de1f0f5c3..8aeb0f759e6c 100644
--- a/clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
+++ b/clang/test/CodeGenCUDA/amdgpu-kernel-arg-pointer-type.cu
@@ -67,3 +67,10 @@ __global__ void kernel6(struct T t) {
   t.x[0][0] += 1.f;
   t.x[1][0] += 2.f;
 }
+
+// Check that coerced pointers retain the noalias attribute when qualified 
with __restrict.
+// CHECK: define amdgpu_kernel void @_Z7kernel7Pi(i32 addrspace(1)* noalias 
%x.coerce)
+// HOST: define void @_Z22__device_stub__kernel7Pi(i32* noalias %x)
+__global__ void kernel7(int *__restrict x) {
+  x[0]++;
+}



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


[clang] 86e50af - [AST] Print fixed enum type regardless of language mode

2020-05-05 Thread Erik Pilkington via cfe-commits

Author: Erik Pilkington
Date: 2020-05-05T15:30:39-04:00
New Revision: 86e50af72d0a0f5cddd2cb487681709eda7934e8

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

LOG: [AST] Print fixed enum type regardless of language mode

These are permitted in all language modes, not just C++11.

Added: 


Modified: 
clang/lib/AST/DeclPrinter.cpp
clang/test/AST/ast-print-enum-decl.c

Removed: 




diff  --git a/clang/lib/AST/DeclPrinter.cpp b/clang/lib/AST/DeclPrinter.cpp
index 706452fcc4a7..fc2a166e11b4 100644
--- a/clang/lib/AST/DeclPrinter.cpp
+++ b/clang/lib/AST/DeclPrinter.cpp
@@ -532,7 +532,7 @@ void DeclPrinter::VisitEnumDecl(EnumDecl *D) {
 
   Out << ' ' << *D;
 
-  if (D->isFixed() && D->getASTContext().getLangOpts().CPlusPlus11)
+  if (D->isFixed())
 Out << " : " << D->getIntegerType().stream(Policy);
 
   if (D->isCompleteDefinition()) {

diff  --git a/clang/test/AST/ast-print-enum-decl.c 
b/clang/test/AST/ast-print-enum-decl.c
index fba931344285..0e2a8ed7d8e5 100644
--- a/clang/test/AST/ast-print-enum-decl.c
+++ b/clang/test/AST/ast-print-enum-decl.c
@@ -103,3 +103,8 @@ struct DeclGroupInMemberList {
   enum T2 { T20 } *p1, *p2;
   // PRINT-NEXT: };
 };
+
+enum fixedEnum : int { fixedEnumerator };
+// PRINT-LABEL: enum fixedEnum : int {
+// PRINT-NEXT: fixedEnumerator
+// PRINT-NEXT: };



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


[clang] 873e279 - [SemaObjC] Add a warning for dictionary literals with duplicate keys

2020-05-05 Thread Erik Pilkington via cfe-commits

Author: Erik Pilkington
Date: 2020-05-05T15:30:39-04:00
New Revision: 873e279095391df347b58ba4bab26dbfecab1262

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

LOG: [SemaObjC] Add a warning for dictionary literals with duplicate keys

Duplicate keys in a literal break NSDictionary's invariants. rdar://50454461A

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

Added: 
clang/test/SemaObjC/dictionary-literal-duplicates.m

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaExprObjC.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index ac53ad6ab344..8beb47812d40 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2969,6 +2969,11 @@ def warn_objc_collection_literal_element : Warning<
   "object of type %0 is not compatible with "
   "%select{array element type|dictionary key type|dictionary value type}1 %2">,
   InGroup;
+def warn_nsdictionary_duplicate_key : Warning<
+  "duplicate key in dictionary literal">,
+  InGroup>;
+def note_nsdictionary_duplicate_key_here : Note<
+  "previous equal key is here">;
 def err_swift_param_attr_not_swiftcall : Error<
   "'%0' parameter can only be used with swiftcall calling convention">;
 def err_swift_indirect_result_not_first : Error<

diff  --git a/clang/lib/Sema/SemaExprObjC.cpp b/clang/lib/Sema/SemaExprObjC.cpp
index 11ab4db1e485..474aba6a0d44 100644
--- a/clang/lib/Sema/SemaExprObjC.cpp
+++ b/clang/lib/Sema/SemaExprObjC.cpp
@@ -894,6 +894,62 @@ ExprResult Sema::BuildObjCArrayLiteral(SourceRange SR, 
MultiExprArg Elements) {
 ArrayWithObjectsMethod, SR));
 }
 
+/// Check for duplicate keys in an ObjC dictionary literal. For instance:
+///   NSDictionary *nd = @{ @"foo" : @"bar", @"foo" : @"baz" };
+static void
+CheckObjCDictionaryLiteralDuplicateKeys(Sema ,
+ObjCDictionaryLiteral *Literal) {
+  if (Literal->isValueDependent() || Literal->isTypeDependent())
+return;
+
+  // NSNumber has quite relaxed equality semantics (for instance, @YES is
+  // considered equal to @1.0). For now, ignore floating points and just do a
+  // bit-width and sign agnostic integer compare.
+  struct APSIntCompare {
+bool operator()(const llvm::APSInt , const llvm::APSInt ) const {
+  return llvm::APSInt::compareValues(LHS, RHS) < 0;
+}
+  };
+
+  llvm::DenseMap StringKeys;
+  std::map IntegralKeys;
+
+  auto checkOneKey = [&](auto , const auto , SourceLocation Loc) {
+auto Pair = Map.insert({Key, Loc});
+if (!Pair.second) {
+  S.Diag(Loc, diag::warn_nsdictionary_duplicate_key);
+  S.Diag(Pair.first->second, diag::note_nsdictionary_duplicate_key_here);
+}
+  };
+
+  for (unsigned Idx = 0, End = Literal->getNumElements(); Idx != End; ++Idx) {
+Expr *Key = Literal->getKeyValueElement(Idx).Key->IgnoreParenImpCasts();
+
+if (auto *StrLit = dyn_cast(Key)) {
+  StringRef Bytes = StrLit->getString()->getBytes();
+  SourceLocation Loc = StrLit->getExprLoc();
+  checkOneKey(StringKeys, Bytes, Loc);
+}
+
+if (auto *BE = dyn_cast(Key)) {
+  Expr *Boxed = BE->getSubExpr();
+  SourceLocation Loc = BE->getExprLoc();
+
+  // Check for @("foo").
+  if (auto *Str = dyn_cast(Boxed->IgnoreParenImpCasts())) {
+checkOneKey(StringKeys, Str->getBytes(), Loc);
+continue;
+  }
+
+  Expr::EvalResult Result;
+  if (Boxed->EvaluateAsInt(Result, S.getASTContext(),
+   Expr::SE_AllowSideEffects)) {
+checkOneKey(IntegralKeys, Result.Val.getInt(), Loc);
+  }
+}
+  }
+}
+
 ExprResult Sema::BuildObjCDictionaryLiteral(SourceRange SR,
   MutableArrayRef Elements) 
{
   SourceLocation Loc = SR.getBegin();
@@ -1061,12 +1117,14 @@ ExprResult Sema::BuildObjCDictionaryLiteral(SourceRange 
SR,
 HasPackExpansions = true;
   }
 
-  QualType Ty
-= Context.getObjCObjectPointerType(
-
Context.getObjCInterfaceType(NSDictionaryDecl));
-  return MaybeBindToTemporary(ObjCDictionaryLiteral::Create(
-  Context, Elements, HasPackExpansions, Ty,
-  DictionaryWithObjectsMethod, SR));
+  QualType Ty = Context.getObjCObjectPointerType(
+  Context.getObjCInterfaceType(NSDictionaryDecl));
+
+  auto *Literal =
+  ObjCDictionaryLiteral::Create(Context, Elements, HasPackExpansions, Ty,
+DictionaryWithObjectsMethod, SR);
+  CheckObjCDictionaryLiteralDuplicateKeys(*this, Literal);
+  return MaybeBindToTemporary(Literal);
 }
 
 ExprResult Sema::BuildObjCEncodeExpression(SourceLocation AtLoc,


[PATCH] D79244: [Sema] Put existing warning under -Wexcess-initializers

2020-05-05 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm updated this revision to Diff 262189.
rsandifo-arm added a comment.

Put two other related warnings under the new option


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79244

Files:
  clang/docs/DiagnosticsReference.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/test/Misc/warning-flags.c
  clang/test/Sema/array-init.c
  clang/test/Sema/init.c

Index: clang/test/Sema/init.c
===
--- clang/test/Sema/init.c
+++ clang/test/Sema/init.c
@@ -121,6 +121,10 @@
 };
 
 struct foo2 bar3 = { 1, 2 }; // expected-warning{{excess elements in struct initializer}}
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wexcess-initializers"
+struct foo2 bar3_silent = {1, 2};
+#pragma clang diagnostic pop
 
 int* ptest1 = __builtin_choose_expr(1, (int*)0, (int*)0);
 
Index: clang/test/Sema/array-init.c
===
--- clang/test/Sema/array-init.c
+++ clang/test/Sema/array-init.c
@@ -148,11 +148,20 @@
 static char const yy[5] = "test";
 static char const zz[3] = "test"; // expected-warning{{initializer-string for char array is too long}}
 
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wexcess-initializers"
+static char const zz_quiet[3] = "test";
+#pragma clang diagnostic pop
+
 void charArrays() {
   static char const test[] = "test";
   int test_sizecheck[(sizeof(test) / sizeof(char)) == 5? 1 : -1];
   static char const test2[] = { "weird stuff" };
   static char const test3[] = { "test", "excess stuff" }; // expected-warning{{excess elements in char array initializer}}
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wexcess-initializers"
+  static char const test3_quiet[] = {"test", "excess stuff"};
+#pragma clang diagnostic pop
 
   char* cp[] = { "Hello" };
 
Index: clang/test/Misc/warning-flags.c
===
--- clang/test/Misc/warning-flags.c
+++ clang/test/Misc/warning-flags.c
@@ -18,12 +18,9 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (75):
-CHECK-NEXT:   ext_excess_initializers
-CHECK-NEXT:   ext_excess_initializers_in_char_array_initializer
+CHECK: Warnings without flags (72):
 CHECK-NEXT:   ext_expected_semi_decl_list
 CHECK-NEXT:   ext_explicit_specialization_storage_class
-CHECK-NEXT:   ext_initializer_string_for_char_array_too_long
 CHECK-NEXT:   ext_missing_declspec
 CHECK-NEXT:   ext_missing_whitespace_after_macro_name
 CHECK-NEXT:   ext_new_paren_array_nonconst
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -5391,15 +5391,18 @@
 def err_excess_initializers : Error<
   "excess elements in %select{array|vector|scalar|union|struct}0 initializer">;
 def ext_excess_initializers : ExtWarn<
-  "excess elements in %select{array|vector|scalar|union|struct}0 initializer">;
+  "excess elements in %select{array|vector|scalar|union|struct}0 initializer">,
+  InGroup;
 def err_excess_initializers_in_char_array_initializer : Error<
   "excess elements in char array initializer">;
 def ext_excess_initializers_in_char_array_initializer : ExtWarn<
-  "excess elements in char array initializer">;
+  "excess elements in char array initializer">,
+  InGroup;
 def err_initializer_string_for_char_array_too_long : Error<
   "initializer-string for char array is too long">;
 def ext_initializer_string_for_char_array_too_long : ExtWarn<
-  "initializer-string for char array is too long">;
+  "initializer-string for char array is too long">,
+  InGroup;
 def warn_missing_field_initializers : Warning<
   "missing field %0 initializer">,
   InGroup, DefaultIgnore;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -350,6 +350,7 @@
   DanglingGsl,
   ReturnStackAddress]>;
 def DistributedObjectModifiers : DiagGroup<"distributed-object-modifiers">;
+def ExcessInitializers : DiagGroup<"excess-initializers">;
 def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
 def FlagEnum : DiagGroup<"flag-enum">;
 def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
Index: clang/docs/DiagnosticsReference.rst
===
--- clang/docs/DiagnosticsReference.rst
+++ clang/docs/DiagnosticsReference.rst
@@ -4481,6 +4481,35 @@
 

[PATCH] D72281: [Matrix] Add matrix type to Clang.

2020-05-05 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 262188.
fhahn marked 9 inline comments as done.
fhahn added a comment.

Thanks for the extensive comments! They should be addressed: refactor dependent 
type construction, template argument deduction, adjust mangling.

In D72281#2019417 , @rjmccall wrote:

> The test cases for function template partial specialization would look 
> something like this:
>
>   template 
>   using matrix = T __attribute__((matrix_type(R, C)));
>  
>   template  struct selector {};
>  
>   template 
>   selector<0> use_matrix(matrix m) {}
>  
>   template 
>   selector<1> use_matrix(matrix m) {}
>  
>   template 
>   selector<2> use_matrix(matrix m) {}
>  
>   void test() {
> selector<2> x = use_matrix(matrix());
> selector<1> y = use_matrix(matrix());
> selector<0> z = use_matrix(matrix());
>   }
>


That's a great example that highlighted a few other issues (e.g. 
BuildMatrixType not supporting dependent element types).

The latest version of the patch manages to compile each `use_matrix` definition 
individually (if there is only a single template definition of `use_matrix`), 
but there still is a disambiguation failure in the snippet below, if all 3 
`use_matrix` definitions are available.

  matrix m1;
  selector<2> x = use_matrix(m1);

The type of `m1` matches the matrix argument in all 3 definitions of 
`use_matrix` and for some reason the return type is not used to disambiguate 
the definitions:

  llvm-project/clang/test/CodeGenCXX/matrix-type.cpp:310:19: error: call to 
'use_matrix' is ambiguous
selector<2> x = use_matrix(m1);
^~
  llvm-project/clang/test/CodeGenCXX/matrix-type.cpp:300:13: note: candidate 
function [with T = int, R = 10, C = 10]
  selector<0> use_matrix(matrix ) {}
  ^
  llvm-project/clang/test/CodeGenCXX/matrix-type.cpp:303:13: note: candidate 
function [with T = int, R = 10]
  selector<1> use_matrix(matrix ) {}
  ^
  llvm-project/clang/test/CodeGenCXX/matrix-type.cpp:306:13: note: candidate 
function [with T = int]
  selector<2> use_matrix(matrix ) {}

I am not sure where things are going wrong unfortunately. The matrix argument 
deduction should mirror the code for types like DependentSizedArrayType. Do you 
have any idea what could be missing?

> But you should include some weirder kinds of template, expressions that 
> aren't deducible, and so on.

Will do, once the issue above is sorted out :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72281

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TypeNodes.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/TypeBitCodes.def
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTStructuralEquivalence.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/CodeGen/debug-info-matrix-types.c
  clang/test/CodeGen/matrix-type.c
  clang/test/CodeGenCXX/matrix-type.cpp
  clang/test/Parser/matrix-type-disabled.c
  clang/test/SemaCXX/matrix-type.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1795,6 +1795,8 @@
 DEFAULT_TYPELOC_IMPL(DependentSizedExtVector, Type)
 DEFAULT_TYPELOC_IMPL(Vector, Type)
 DEFAULT_TYPELOC_IMPL(ExtVector, VectorType)
+DEFAULT_TYPELOC_IMPL(ConstantMatrix, MatrixType)
+DEFAULT_TYPELOC_IMPL(DependentSizedMatrix, MatrixType)
 DEFAULT_TYPELOC_IMPL(FunctionProto, FunctionType)
 DEFAULT_TYPELOC_IMPL(FunctionNoProto, FunctionType)
 DEFAULT_TYPELOC_IMPL(Record, TagType)
Index: clang/test/SemaCXX/matrix-type.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/matrix-type.cpp
@@ -0,0 +1,61 @@

[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

2020-05-05 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:478
+
+  // FIXME: Check for stream in EOF state?
+

balazske wrote:
> Szelethus wrote:
> > Will that be the next patch? :D Eager to see it!
> It may be too big change to add it as well here (or cause more difficulties). 
> But it should be a  check for `ErrorFEof` in the `ErrorState` (and add 
> another bug type). This is not a fatal error.
> 
> It may be more difficult to make `fread` return the feof error again if it 
> starts already with feof state. (Because the state with FEof should be split 
> from the generic error state that can contain other possible errors.)
> It may be too big change to add it as well here (or cause more difficulties). 
> But it should be a check for ErrorFEof in the ErrorState (and add another bug 
> type). This is not a fatal error.

Oh, yea, right, we went over this once :) What I really meant, is an EOF 
related error, like reading a variable with an EOF value in any context that 
isn't a comparison to the actual `EOF` (which in many contexts still isn't a 
//fatal// error, but is far more an indicator of code smell). But I'm just 
thinking aloud, please proceed with this project however it is convenient to 
you!

> It may be more difficult to make fread return the feof error again if it 
> starts already with feof state. (Because the state with FEof should be split 
> from the generic error state that can contain other possible errors.)

I gave this plenty of thought, how do you imagine the problem of us not 
splitting up to 3 states to show up? Suppose we're calling fread on a stream 
where the error state is either EOF or ERROR, but we don't know which. We could 
just leave the `StreamErrorState` as-is, couldn't we?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78374



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


[PATCH] D78827: Add support for #pragma clang fp reassociate(fast|off) -- floating point control of associative math transformations

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

That makes sense, thanks.  I think I'm comfortable using on/off for this, but 
it's definitely good to stop and consider, and you're absolutely right that it 
needs to be documented.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79244: [Sema] Put existing warning under -Wexcess-initializers

2020-05-05 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm added a comment.

In D79244#2019027 , @efriedma wrote:

> Should we stick ext_excess_initializers_in_char_array_initializer and 
> ext_initializer_string_for_char_array_too_long in the same warning group?


Yeah, agree that would be better.  Done in v2.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79244



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


[PATCH] D72281: [Matrix] Add matrix type to Clang.

2020-05-05 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:3846
+  New = new (*this, TypeAlignment) DependentSizedMatrixType(
+  *this, ElementTy, QualType(Canon, 0), RowExpr, ColumnExpr, AttrLoc);
+  } else {

rjmccall wrote:
> Some of this redundancy is avoidable.  I think you can just structure this as:
> 
> - Look for an existing canonical matrix type.
> - If you find one, and it matches exactly, return it.
> - If you don't have a canonical matrix type, build it and add it to both 
> `DependentSizedMatrixTypes` and `Types`.
> - You now have a canonical matrix type; if it doesn't match exactly (you can 
> remember a flag for this), build a non-canonical matrix type (and add it to 
> `Types`).
> - Return the non-canonical matrix type if you built one, or otherwise the 
> canonical matrix type.
Thanks for the suggestion! I've updated the code accordingly.



Comment at: clang/lib/AST/ItaniumMangle.cpp:3349
+void CXXNameMangler::mangleType(const MatrixType *T) {
+  Out << "Dm" << T->getNumRows() << "_" << T->getNumColumns() << '_';
+  mangleType(T->getElementType());

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > fhahn wrote:
> > > > rjmccall wrote:
> > > > > fhahn wrote:
> > > > > > rjmccall wrote:
> > > > > > > You need to ask the Itanium C++ ABI for this mangling, since it's 
> > > > > > > not using a vendor-extension prefix.  I know that wasn't done for 
> > > > > > > vector types, but we're trying to do the right thing.
> > > > > > That basically means reaching out to 
> > > > > > https://github.com/itanium-cxx-abi/cxx-abi/, right?
> > > > > > 
> > > > > > Do you think it would be feasible to initially go with a 
> > > > > > vendor-extensions mangling (like 
> > > > > > `uMatrixxx`)? I've 
> > > > > > updated the mangling to this.
> > > > > Yeah, you can open an issue there.
> > > > > 
> > > > > That approach doesn't quite work because mangling the element type 
> > > > > can use or introduce substitutions, but the demangler will naturally 
> > > > > skip the whole thing.  I think there are two possible approaches 
> > > > > here: we could either treat the entire matrix type as a 
> > > > > vendor-extended qualifier on the element type (i.e. 
> > > > > `U11matrix_typeILi3ELi4EEi`), or we could extend the vendor-extended 
> > > > > type mangling to allow template-args (i.e. 
> > > > > `u11matrix_typeIiLi3ELi4EE`).  The latter is probably better and 
> > > > > should fit cleanly into the mangling grammar.
> > > > Thanks for those suggestions. For now I went with the vendor-extended 
> > > > qualifier, because IIUC that would fit in the existing mangling scheme 
> > > > without any changes, while the second option would require changes to 
> > > > the grammar, right?
> > > > 
> > > Yes, but it's a very modest change; please raise this with the Itanium 
> > > committee (which is largely just me again, but wearing a different hat).
> > > 
> > > In the meantime, the qualifier approach is fine as a hack, but it's not 
> > > technically correct unless you do annoying things with the mangling of 
> > > actually-qualified matrix types.  But the proper qualifier approach is to 
> > > provide the arguments as template-arguments, not one big unstructured 
> > > string.
> > > 
> > > Also you should do the same thing with DependentSizedMatrixType.
> > > Yes, but it's a very modest change; please raise this with the Itanium 
> > > committee (which is largely just me again, but wearing a different hat).
> > 
> > Great, I will do so shortly (probably tomorrow).
> > 
> > > Also you should do the same thing with DependentSizedMatrixType.
> > 
> > I am not sure if it would make sense for DependentSizedMatrixType, as we 
> > would have to mangle both the row and column expressions and add them to 
> > the qualifier IIUC. I've disabled mangling for DependentSizedMatrixType for 
> > now.
> The qualifier production is `U  ?`, where the 
> intent of the `` is to capture any arguments you might have.  
> So instead of building one big string with all the sizes in it, you should 
> build just the constant string `matrix_type` and then add `I...E` with the 
> arguments.  For the constant case, you can just call 
> `mangleIntegerLiteral(Context.getSizeType(), T->getNumRows())`; I think 
> `size_t` is the appropriate presumed type for these bounds.  For the 
> dependent case, you should actually call `mangleTemplateArgument` passing the 
> expression, which should promote to `TemplateArgument` implicitly.
Ah right, I thought we have to provide the length of the full qualifier 
(including the arguments), but it should be OK to just provide the size of 
matrix_type and then mangle the arguments directly. Updated.

I also filed an issue for the mangling: 
https://github.com/itanium-cxx-abi/cxx-abi/issues/100



Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:2109
+if (!RowExprTemplateParam || 

[PATCH] D77954: [CUDA][HIP] Fix host/device based overload resolution

2020-05-05 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

It appears that re-landed b46b1a916d44216f0c70de55ae2123eb9de69027 
 has 
created another compilation regression. I don't have a simple reproducer yet, 
so here's the error message for now:

  llvm_unstable/toolchain/bin/../include/c++/v1/tuple:232:15: error: call to 
implicitly-deleted copy constructor of 
'std::__u::unique_ptr>'
  : __value_(_VSTD::forward<_Tp>(__t))
^
  llvm_unstable/toolchain/bin/../include/c++/v1/tuple:388:13: note: in 
instantiation of function template specialization 'std::__u::__tuple_leaf<0, 
std::__u::unique_ptr>, 
false>::__tuple_leaf>, void>' requested here
  __tuple_leaf<_Uf, _Tf>(_VSTD::forward<_Up>(__u))...,
  ^
  llvm_unstable/toolchain/bin/../include/c++/v1/tuple:793:15: note: in 
instantiation of function template specialization 
'std::__u::__tuple_impl, 
std::__u::unique_ptr>, std::__u::function>::__tuple_impl<0, 1, std::__u::unique_ptr>, std::__u::function, std::__u::unique_ptr>, std::__u::function>' requested here
  : __base_(typename __make_tuple_indices::type(),
^
  llvm_unstable/toolchain/bin/../include/c++/v1/thread:297:17: note: in 
instantiation of function template specialization 
'std::__u::tuple>, std::__u::function>::tuple>, std::__u::function, false, false>' requested here
  new _Gp(std::move(__tsp),
  ^
  
./third_party/eigen3/unsupported/Eigen/CXX11/src/ThreadPool/ThreadEnvironment.h:24:42:
 note: in instantiation of function template specialization 
'std::__u::thread::thread, void>' requested here
  EnvThread(std::function f) : thr_(std::move(f)) {}
   ^
  llvm_unstable/toolchain/bin/../include/c++/v1/memory:2583:3: note: copy 
constructor is implicitly deleted because 
'unique_ptr>' has a user-declared move 
constructor
unique_ptr(unique_ptr&& __u) _NOEXCEPT
^
  1 error generated when compiling for sm_60.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77954



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


[PATCH] D79276: [FileCheck] Support comment directives

2020-05-05 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny updated this revision to Diff 262185.
jdenny added a comment.

My last update accidentally included D79375 .  
This strips it back out.  Sorry about that.


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

https://reviews.llvm.org/D79276

Files:
  clang/test/CodeGen/default-address-space.c
  clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
  clang/test/Driver/hip-device-libs.hip
  llvm/docs/CommandGuide/FileCheck.rst
  llvm/include/llvm/Support/FileCheck.h
  llvm/lib/Support/FileCheck.cpp
  llvm/test/Assembler/drop-debug-info-nonzero-alloca.ll
  llvm/test/FileCheck/comment/after-words.txt
  llvm/test/FileCheck/comment/bad-comment-prefix.txt
  llvm/test/FileCheck/comment/blank-comments.txt
  llvm/test/FileCheck/comment/suffixes.txt
  llvm/test/FileCheck/comment/suppresses-checks.txt
  llvm/test/FileCheck/comment/unused-check-prefixes.txt
  llvm/test/FileCheck/comment/unused-comment-prefixes.txt
  llvm/test/FileCheck/comment/within-checks.txt
  llvm/test/FileCheck/first-character-match.txt
  llvm/test/FileCheck/validate-check-prefix.txt
  llvm/utils/FileCheck/FileCheck.cpp

Index: llvm/utils/FileCheck/FileCheck.cpp
===
--- llvm/utils/FileCheck/FileCheck.cpp
+++ llvm/utils/FileCheck/FileCheck.cpp
@@ -44,6 +44,14 @@
 cl::desc(
 "Alias for -check-prefix permitting multiple comma separated values"));
 
+static cl::list CommentPrefixes(
+"comment-prefixes", cl::CommaSeparated, cl::Hidden,
+cl::desc("Comma-separated list of comment prefixes to use from check file\n"
+ "(defaults to 'COM,RUN'). Please avoid using this feature in\n"
+ "LLVM's LIT-based test suites, which should be easier to\n"
+ "maintain if they all follow a consistent comment style. This\n"
+ "feature is meant for non-LIT test suites using FileCheck."));
+
 static cl::opt NoCanonicalizeWhiteSpace(
 "strict-whitespace",
 cl::desc("Do not treat all horizontal whitespace as equivalent"));
@@ -279,6 +287,8 @@
 return "label";
   case Check::CheckEmpty:
 return "empty";
+  case Check::CheckComment:
+return "com";
   case Check::CheckEOF:
 return "eof";
   case Check::CheckBadNot:
@@ -565,6 +575,9 @@
   for (StringRef Prefix : CheckPrefixes)
 Req.CheckPrefixes.push_back(Prefix);
 
+  for (StringRef Prefix : CommentPrefixes)
+Req.CommentPrefixes.push_back(Prefix);
+
   for (StringRef CheckNot : ImplicitCheckNot)
 Req.ImplicitCheckNot.push_back(CheckNot);
 
Index: llvm/test/FileCheck/validate-check-prefix.txt
===
--- llvm/test/FileCheck/validate-check-prefix.txt
+++ llvm/test/FileCheck/validate-check-prefix.txt
@@ -8,6 +8,6 @@
 
 ; BAD_PREFIX: supplied check prefix must start with a letter and contain only alphanumeric characters, hyphens, and underscores: 'A!'
 
-; DUPLICATE_PREFIX: error: supplied check prefix must be unique among check prefixes: 'REPEAT'
+; DUPLICATE_PREFIX: error: supplied check prefix must be unique among check and comment prefixes: 'REPEAT'
 
 ; EMPTY_PREFIX: error: supplied check prefix must not be the empty string
Index: llvm/test/FileCheck/first-character-match.txt
===
--- llvm/test/FileCheck/first-character-match.txt
+++ llvm/test/FileCheck/first-character-match.txt
@@ -1,2 +1,2 @@
-RUN: FileCheck -check-prefix=RUN -input-file %s %s
+RUN: FileCheck -check-prefix=RUN --comment-prefixes=COM -input-file %s %s
 // Prefix is at the first character in the file. The run line then matches itself.
Index: llvm/test/FileCheck/comment/within-checks.txt
===
--- /dev/null
+++ llvm/test/FileCheck/comment/within-checks.txt
@@ -0,0 +1,8 @@
+# A comment directive is not recognized within a check directive's pattern and
+# thus does not comment out the remainder of the pattern.
+
+RUN: echo 'foo' > %t.in
+RUN: echo 'CHECK: foo COM: bar' > %t.chk
+RUN: %ProtectFileCheckOutput not FileCheck %t.chk < %t.in 2>&1 | FileCheck %s
+
+CHECK: .chk:1:8: error: CHECK: expected string not found in input
Index: llvm/test/FileCheck/comment/unused-comment-prefixes.txt
===
--- /dev/null
+++ llvm/test/FileCheck/comment/unused-comment-prefixes.txt
@@ -0,0 +1,16 @@
+# Not using comment directives is always fine.
+
+RUN: echo 'foo'> %t.in
+RUN: echo 'CHECK: foo' > %t.chk
+
+# Check the case of default comment prefixes.
+RUN: %ProtectFileCheckOutput \
+RUN: FileCheck -vv %t.chk < %t.in 2>&1 | FileCheck %s
+
+# Specifying non-default comment prefixes doesn't mean you have to use them.
+# For example, they might be applied to an entire test suite via
+# FILECHECK_OPTS or via a wrapper command or substitution.
+RUN: %ProtectFileCheckOutput \
+RUN: FileCheck -vv 

[PATCH] D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function

2020-05-05 Thread Andrii Nakryiko via Phabricator via cfe-commits
anakryiko added a comment.

In D74668#2020554 , @yonghong-song 
wrote:

> In D74668#2019558 , @anakryiko wrote:
>
> > what's the use case for flag==0 (no relocation)? why using built-in at all 
> > in such case? Also flag==1 means relocate to local BTF ID or remote 
> > (kernel) BTF ID? Do you plan to add flag=2 as well to cover both cases? Or 
> > am I misunderstanding the meaning of this flag?
>
>
> Originally, I thought flag = 0 for the following use case:
>
>e.g., they just want to know the type of a particular local structure for 
> pretty print purpose.
>Note that currently only types for global/extern variables, function 
> parameters are recorded in btf.
>  int test() {
> struct { int a; int b; ...} ctx;
> btf_id = __builtin_btf_type_id(ctx, 0);
> bpf_seq_write(seq, _id, sizeof(btf_id));
> bpf_seq_write(seq, , sizeof(ctx));
> ...
>  }
>   
>   But obviously without relocation, this will not work with btf 
> deduplication, future static linking etc.


Right, that's what I was thinking. We should have relocation always, even if 
it's a noop for libbpf today.

> flag 1: for relocation. My original thinking is for vmlinux relocation.
> 
>  
> 
> I think you brought a good point about local relocation, so will need
>  to change the flag to:
> 
>   flag 0 : local relocation
>   flag 1:  vmlinux relocation
>
> 
> Two more relocation types will be generated:
> 
>   BTF_TYPE_ID_LOCAL
>   BTF_TYPE_ID_REMOTE

Yep, that would be great.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74668



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


[PATCH] D79265: Let normalize() for posix style convert backslash to slash unconditionally.

2020-05-05 Thread Nico Weber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8fc7a907b93a: Let normalize() for posix style convert 
backslash to slash unconditionally. (authored by thakis).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D79265?vs=261980=262180#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79265

Files:
  clang/test/Lexer/case-insensitive-include-ms.c
  llvm/lib/Support/Path.cpp
  llvm/unittests/Support/Path.cpp


Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1182,7 +1182,7 @@
   Tests.emplace_back("a", "a", "a");
   Tests.emplace_back("a/b", "a\\b", "a/b");
   Tests.emplace_back("a\\b", "a\\b", "a/b");
-  Tests.emplace_back("ab", "ab", "ab");
+  Tests.emplace_back("ab", "ab", "a//b");
   Tests.emplace_back("\\a", "\\a", "/a");
   Tests.emplace_back("a\\", "a\\", "a/");
   Tests.emplace_back("a\\t", "a\\t", "a/t");
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -540,15 +540,9 @@
   Path = PathHome;
 }
   } else {
-for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI) {
-  if (*PI == '\\') {
-auto PN = PI + 1;
-if (PN < PE && *PN == '\\')
-  ++PI; // increment once, the for loop will move over the escaped 
slash
-else
-  *PI = '/';
-  }
-}
+for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI)
+  if (*PI == '\\')
+*PI = '/';
   }
 }
 
Index: clang/test/Lexer/case-insensitive-include-ms.c
===
--- clang/test/Lexer/case-insensitive-include-ms.c
+++ clang/test/Lexer/case-insensitive-include-ms.c
@@ -6,15 +6,17 @@
 // RUN: %clang_cc1 -fsyntax-only -fms-compatibility %s -include %s -I 
%t/Output -verify
 // RUN: %clang_cc1 -fsyntax-only -fms-compatibility 
-fdiagnostics-parseable-fixits %s -include %s -I %t/Output 2>&1 | FileCheck %s
 
-// FIXME: Add a test with repeated backslashes once clang can handle that
-// in ms-compat mode on non-Windows hosts.
 #include "..\Output\.\case-insensitive-include.h"
 #include "..\Output\.\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:50}:"\"..\\Output\\.\\case-insensitive-include.h\""
+#include "..\\Output\.\\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:52}:"\"..Output\\.case-insensitive-include.h\""
 #include "..\output\.\case-insensitive-include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:50}:"\"..\\Output\\.\\case-insensitive-include.h\""
 
 #include "apath\..\.\case-insensitive-include.h"
 #include "apath\..\.\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:49}:"\"apath\\..\\.\\case-insensitive-include.h\""
+#include "apath\\..\\.\\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:52}:"\"apath...case-insensitive-include.h\""
 #include "APath\..\.\case-insensitive-include.h" // For the sake of 
efficiency, this case is not diagnosed. :-(


Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1182,7 +1182,7 @@
   Tests.emplace_back("a", "a", "a");
   Tests.emplace_back("a/b", "a\\b", "a/b");
   Tests.emplace_back("a\\b", "a\\b", "a/b");
-  Tests.emplace_back("ab", "ab", "ab");
+  Tests.emplace_back("ab", "ab", "a//b");
   Tests.emplace_back("\\a", "\\a", "/a");
   Tests.emplace_back("a\\", "a\\", "a/");
   Tests.emplace_back("a\\t", "a\\t", "a/t");
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -540,15 +540,9 @@
   Path = PathHome;
 }
   } else {
-for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI) {
-  if (*PI == '\\') {
-auto PN = PI + 1;
-if (PN < PE && *PN == '\\')
-  ++PI; // increment once, the for loop will move over the escaped slash
-else
-  *PI = '/';
-  }
-}
+for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI)
+  if (*PI == '\\')
+*PI = '/';
   }
 }
 
Index: clang/test/Lexer/case-insensitive-include-ms.c
===
--- clang/test/Lexer/case-insensitive-include-ms.c
+++ 

[PATCH] D78827: Add support for #pragma clang fp reassociate(fast|off) -- floating point control of associative math transformations

2020-05-05 Thread Steve Canon via Phabricator via cfe-commits
scanon added a comment.

> I don't think the C standard is likely to ever bless reassociative FP math 
> with an expression-local restriction. Steve, do you actually think that would 
> be a useful optimization mode?

I think it's pretty unlikely that C would do this, as well. It is plausibly a 
useful semantic mode, but I don't know that we need to reserve the name for it. 
I only want to raise the question, and be sure that we're aware that we're 
making a decision here (also, either way we need to document it clearly).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


[PATCH] D79431: [analyzer] StdLibraryFunctionsChecker: Add better diagnostics

2020-05-05 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

Sure, this is an improvement because we display more information, but I'd argue 
that it isn't really a more readable warning message :) How about

th argument to the call to 

- cannot be represented with a character
- is a null pointer
- ...

, which violates the function's preconditions.

WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79431



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


[PATCH] D68049: Propeller: Clang options for basic block sections

2020-05-05 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram added a comment.

@rsmith Ping.


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

https://reviews.llvm.org/D68049



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


[PATCH] D79434: [analyzer] Generalize bitwise AND rules for ranges

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

Here is a little proof I've put together (using Z3): 
https://gist.github.com/SavchenkoValeriy/2355170159ce1febd27498c36ea22149


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79434



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


[PATCH] D79336: [analyzer] Generalize bitwise OR rules for ranges

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 262171.
vsavchenko added a comment.

Fix clang-format issue


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79336

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  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
@@ -77,7 +77,7 @@
   clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
 }
 
-void testBitwiseRules(unsigned int a, int b) {
+void testBitwiseRules(unsigned int a, int b, int c) {
   clang_analyzer_eval((a | 1) >= 1); // expected-warning{{TRUE}}
   clang_analyzer_eval((a | -1) >= -1); // expected-warning{{TRUE}}
   clang_analyzer_eval((a | 2) >= 2); // expected-warning{{TRUE}}
@@ -96,9 +96,9 @@
   // Again, check for different argument order.
   clang_analyzer_eval((1 & a) <= 1); // expected-warning{{TRUE}}
 
-  unsigned int c = a;
-  c |= 1;
-  clang_analyzer_eval((c | 0) == 0); // expected-warning{{FALSE}}
+  unsigned int d = a;
+  d |= 1;
+  clang_analyzer_eval((d | 0) == 0); // expected-warning{{FALSE}}
 
   // Rules don't apply to signed typed, as the values might be negative.
   clang_analyzer_eval((b | 1) > 0); // expected-warning{{UNKNOWN}}
@@ -108,20 +108,47 @@
   clang_analyzer_eval((b | -2) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 10) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 0) == 0); // expected-warning{{UNKNOWN}}
-#ifdef ANALYZER_CM_Z3
   clang_analyzer_eval((b | -2) >= 0); // expected-warning{{FALSE}}
-#else
-  clang_analyzer_eval((b | -2) >= 0); // expected-warning{{UNKNOWN}}
-#endif
+
+  // Check that we can operate with negative ranges
+  if (b < 0) {
+clang_analyzer_eval((b | -1) == -1);   // expected-warning{{TRUE}}
+clang_analyzer_eval((b | -10) >= -10); // expected-warning{{TRUE}}
+
+int e = (b | -5);
+clang_analyzer_eval(e >= -5 && e <= -1); // expected-warning{{TRUE}}
+
+if (b < -20) {
+  clang_analyzer_eval((b | e) >= -5); // expected-warning{{TRUE}}
+}
+
+// Check that we can reason about the result even if know nothing
+// about one of the operands.
+clang_analyzer_eval((b | c) != 0); // expected-warning{{TRUE}}
+  }
+
+  if (a <= 30 && b >= 10 && c >= 20) {
+// Check that we can reason about non-constant operands.
+clang_analyzer_eval((b | c) >= 20); // expected-warning{{TRUE}}
+
+// Check that we can reason about the resulting range even if
+// the types are not the same, but we still can convert operand
+// ranges.
+clang_analyzer_eval((a | b) >= 10); // expected-warning{{TRUE}}
+  }
 
   // Check that dynamically computed constants also work.
   unsigned int constant = 1 << 3;
-  unsigned int d = a | constant;
-  clang_analyzer_eval(d >= constant); // expected-warning{{TRUE}}
+  unsigned int f = a | constant;
+  clang_analyzer_eval(f >= constant); // expected-warning{{TRUE}}
 
   // Check that nested expressions also work.
   clang_analyzer_eval(((a | 10) | 5) >= 10); // expected-warning{{TRUE}}
 
+  if (a < 10) {
+clang_analyzer_eval((a | 20) >= 20); // expected-warning{{TRUE}}
+  }
+
   // TODO: We misuse intersection of ranges for bitwise AND and OR operators.
   //   Resulting ranges for the following cases are infeasible.
   //   This is what causes paradoxical results below.
@@ -129,8 +156,4 @@
 clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
 clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
   }
-  if (a < 10) {
-clang_analyzer_eval((a | 20) >= 20); // expected-warning{{FALSE}}
-clang_analyzer_eval((a | 20) < 20);  // expected-warning{{FALSE}}
-  }
 }
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -69,7 +69,19 @@
 
 const llvm::APSInt ::getMinValue() const {
   assert(!isEmpty());
-  return ranges.begin()->From();
+  return begin()->From();
+}
+
+const llvm::APSInt ::getMaxValue() const {
+  assert(!isEmpty());
+  // NOTE: It's a shame that we can't implement 'getMaxValue' without scanning
+  //   the whole tree to get to the last element.
+  //   llvm::ImmutableSet should support decrement for 'end' iterators
+  //   or reverse order iteration.
+  auto It = begin();
+  for (auto End = end(); std::next(It) != End; ++It) {
+  }
+  return It->To();
 }
 
 bool RangeSet::pin(llvm::APSInt , llvm::APSInt ) const {
@@ -364,22 +376,106 @@
 }
   }
 
+  

[PATCH] D79432: [analyzer] StdLibraryFunctionsChecker: Add summaries for libc

2020-05-05 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

There a couple functional lines commented out, and we need more tests, so I 
take that the patch is a proof of concept for now? Because its pretty cool if 
so. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79432



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


[clang] 8fc7a90 - Let normalize() for posix style convert backslash to slash unconditionally.

2020-05-05 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-05-05T13:54:55-04:00
New Revision: 8fc7a907b93a8e9eef96e872f8f926db3ebfe9b6

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

LOG: Let normalize() for posix style convert backslash to slash unconditionally.

Currently, normalize() for posix replaces backslashes to slashes, except
that two backslashes in sequence are kept as-is.

clang calls normalize() to convert \ to / is microsoft compat mode. This
generally works well, but a path like "c:\\foo\\bar.h" with two
backslashes doesn't work due to the exception in normalize().

These paths happen naturally on Windows hosts with e.g.
`#include __FILE__`, and them not working on other hosts makes it
more difficult to write tests for this case.

The special case has been around without justification since this code
was added in r203611 (since then moved around in r215241 r215243).  No
integration tests fail if I remove it.

Try removing the special case.

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

Added: 


Modified: 
clang/test/Lexer/case-insensitive-include-ms.c
llvm/lib/Support/Path.cpp
llvm/unittests/Support/Path.cpp

Removed: 




diff  --git a/clang/test/Lexer/case-insensitive-include-ms.c 
b/clang/test/Lexer/case-insensitive-include-ms.c
index cf14d2530d01..f7af1fef8b4e 100644
--- a/clang/test/Lexer/case-insensitive-include-ms.c
+++ b/clang/test/Lexer/case-insensitive-include-ms.c
@@ -6,15 +6,17 @@
 // RUN: %clang_cc1 -fsyntax-only -fms-compatibility %s -include %s -I 
%t/Output -verify
 // RUN: %clang_cc1 -fsyntax-only -fms-compatibility 
-fdiagnostics-parseable-fixits %s -include %s -I %t/Output 2>&1 | FileCheck %s
 
-// FIXME: Add a test with repeated backslashes once clang can handle that
-// in ms-compat mode on non-Windows hosts.
 #include "..\Output\.\case-insensitive-include.h"
 #include "..\Output\.\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:50}:"\"..\\Output\\.\\case-insensitive-include.h\""
+#include "..\\Output\.\\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:52}:"\"..Output\\.case-insensitive-include.h\""
 #include "..\output\.\case-insensitive-include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:50}:"\"..\\Output\\.\\case-insensitive-include.h\""
 
 #include "apath\..\.\case-insensitive-include.h"
 #include "apath\..\.\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
 // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:49}:"\"apath\\..\\.\\case-insensitive-include.h\""
+#include "apath\\..\\.\\Case-Insensitive-Include.h" // expected-warning 
{{non-portable path}}
+// CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:10-[[@LINE-1]]:52}:"\"apath...case-insensitive-include.h\""
 #include "APath\..\.\case-insensitive-include.h" // For the sake of 
efficiency, this case is not diagnosed. :-(

diff  --git a/llvm/lib/Support/Path.cpp b/llvm/lib/Support/Path.cpp
index 0a4d5818703b..775629074f6c 100644
--- a/llvm/lib/Support/Path.cpp
+++ b/llvm/lib/Support/Path.cpp
@@ -540,15 +540,9 @@ void native(SmallVectorImpl , Style style) {
   Path = PathHome;
 }
   } else {
-for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI) {
-  if (*PI == '\\') {
-auto PN = PI + 1;
-if (PN < PE && *PN == '\\')
-  ++PI; // increment once, the for loop will move over the escaped 
slash
-else
-  *PI = '/';
-  }
-}
+for (auto PI = Path.begin(), PE = Path.end(); PI < PE; ++PI)
+  if (*PI == '\\')
+*PI = '/';
   }
 }
 

diff  --git a/llvm/unittests/Support/Path.cpp b/llvm/unittests/Support/Path.cpp
index d80edbe19d12..a577f1b744bc 100644
--- a/llvm/unittests/Support/Path.cpp
+++ b/llvm/unittests/Support/Path.cpp
@@ -1182,7 +1182,7 @@ TEST(Support, NormalizePath) {
   Tests.emplace_back("a", "a", "a");
   Tests.emplace_back("a/b", "a\\b", "a/b");
   Tests.emplace_back("a\\b", "a\\b", "a/b");
-  Tests.emplace_back("ab", "ab", "ab");
+  Tests.emplace_back("ab", "ab", "a//b");
   Tests.emplace_back("\\a", "\\a", "/a");
   Tests.emplace_back("a\\", "a\\", "a/");
   Tests.emplace_back("a\\t", "a\\t", "a/t");



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


[PATCH] D79232: [analyzer] Refactor range inference for symbolic expressions

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 262170.
vsavchenko added a comment.

Add clarification on infeasible ranges in bitwise tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79232

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  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
@@ -115,7 +115,22 @@
 #endif
 
   // Check that dynamically computed constants also work.
-  int constant = 1 << 3;
+  unsigned int constant = 1 << 3;
   unsigned int d = a | constant;
-  clang_analyzer_eval(constant > 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(d >= constant); // expected-warning{{TRUE}}
+
+  // Check that nested expressions also work.
+  clang_analyzer_eval(((a | 10) | 5) >= 10); // expected-warning{{TRUE}}
+
+  // TODO: We misuse intersection of ranges for bitwise AND and OR operators.
+  //   Resulting ranges for the following cases are infeasible.
+  //   This is what causes paradoxical results below.
+  if (a > 10) {
+clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
+clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
+  }
+  if (a < 10) {
+clang_analyzer_eval((a | 20) >= 20); // expected-warning{{FALSE}}
+clang_analyzer_eval((a | 20) < 20);  // expected-warning{{FALSE}}
+  }
 }
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -16,6 +16,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/SValVisitor.h"
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/Support/raw_ostream.h"
@@ -23,10 +24,16 @@
 using namespace clang;
 using namespace ento;
 
+//===--===//
+//   RangeSet implementation
+//===--===//
+
 void RangeSet::IntersectInRange(BasicValueFactory , Factory ,
-  const llvm::APSInt , const llvm::APSInt ,
-  PrimRangeSet , PrimRangeSet::iterator ,
-  PrimRangeSet::iterator ) const {
+const llvm::APSInt ,
+const llvm::APSInt ,
+PrimRangeSet ,
+PrimRangeSet::iterator ,
+PrimRangeSet::iterator ) const {
   // There are six cases for each range R in the set:
   //   1. R is entirely before the intersection range.
   //   2. R is entirely after the intersection range.
@@ -66,6 +73,11 @@
 }
 
 bool RangeSet::pin(llvm::APSInt , llvm::APSInt ) const {
+  if (isEmpty()) {
+// This range is already infeasible.
+return false;
+  }
+
   // This function has nine cases, the cartesian product of range-testing
   // both the upper and lower bounds against the symbol's type.
   // Each case requires a different pinning operation.
@@ -238,6 +250,190 @@
 }
 
 namespace {
+
+/// A little component aggregating all of the reasoning we have about
+/// the ranges of symbolic expressions.
+///
+/// Even when we don't know the exact values of the operands, we still
+/// can get a pretty good estimate of the result's range.
+class SymbolicRangeInferrer
+: public SymExprVisitor {
+public:
+  static RangeSet inferRange(BasicValueFactory , RangeSet::Factory ,
+ ProgramStateRef State, SymbolRef Sym) {
+SymbolicRangeInferrer Inferrer(BV, F, State);
+return Inferrer.infer(Sym);
+  }
+
+  RangeSet VisitSymExpr(SymbolRef Sym) {
+// If we got to this function, the actual type of the symbolic
+// expression is not supported for advanced inference.
+// In this case, we simply backoff to the default "let's simply
+// infer the range from the expression's type".
+return infer(Sym->getType());
+  }
+
+  RangeSet VisitSymIntExpr(const SymIntExpr *Sym) {
+return VisitBinaryOperator(Sym);
+  }
+
+  RangeSet VisitIntSymExpr(const IntSymExpr *Sym) {
+return VisitBinaryOperator(Sym);
+  }
+
+  RangeSet VisitSymSymExpr(const SymSymExpr *Sym) {
+return VisitBinaryOperator(Sym);
+  }
+
+private:
+  SymbolicRangeInferrer(BasicValueFactory , RangeSet::Factory ,
+ProgramStateRef S)
+  

[PATCH] D79394: [clang][codegen] Refactor argument loading in function prolog. NFC.

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Oh, yes, if `Fn->getArg(n)` is no longer an `O(n)` linked-list walk, then this 
seems like a great change.  I see that that happened... slightly over three 
years ago.  Hooray for legacies.  LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79394



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


[PATCH] D79336: [analyzer] Generalize bitwise OR rules for ranges

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 262163.
vsavchenko added a comment.

Fix few things here and there


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79336

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  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
@@ -77,7 +77,7 @@
   clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
 }
 
-void testBitwiseRules(unsigned int a, int b) {
+void testBitwiseRules(unsigned int a, int b, int c) {
   clang_analyzer_eval((a | 1) >= 1); // expected-warning{{TRUE}}
   clang_analyzer_eval((a | -1) >= -1); // expected-warning{{TRUE}}
   clang_analyzer_eval((a | 2) >= 2); // expected-warning{{TRUE}}
@@ -96,9 +96,9 @@
   // Again, check for different argument order.
   clang_analyzer_eval((1 & a) <= 1); // expected-warning{{TRUE}}
 
-  unsigned int c = a;
-  c |= 1;
-  clang_analyzer_eval((c | 0) == 0); // expected-warning{{FALSE}}
+  unsigned int d = a;
+  d |= 1;
+  clang_analyzer_eval((d | 0) == 0); // expected-warning{{FALSE}}
 
   // Rules don't apply to signed typed, as the values might be negative.
   clang_analyzer_eval((b | 1) > 0); // expected-warning{{UNKNOWN}}
@@ -108,20 +108,47 @@
   clang_analyzer_eval((b | -2) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 10) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 0) == 0); // expected-warning{{UNKNOWN}}
-#ifdef ANALYZER_CM_Z3
   clang_analyzer_eval((b | -2) >= 0); // expected-warning{{FALSE}}
-#else
-  clang_analyzer_eval((b | -2) >= 0); // expected-warning{{UNKNOWN}}
-#endif
+
+  // Check that we can operate with negative ranges
+  if (b < 0) {
+clang_analyzer_eval((b | -1) == -1);   // expected-warning{{TRUE}}
+clang_analyzer_eval((b | -10) >= -10); // expected-warning{{TRUE}}
+
+int e = (b | -5);
+clang_analyzer_eval(e >= -5 && e <= -1); // expected-warning{{TRUE}}
+
+if (b < -20) {
+  clang_analyzer_eval((b | e) >= -5); // expected-warning{{TRUE}}
+}
+
+// Check that we can reason about the result even if know nothing
+// about one of the operands.
+clang_analyzer_eval((b | c) != 0); // expected-warning{{TRUE}}
+  }
+
+  if (a <= 30 && b >= 10 && c >= 20) {
+// Check that we can reason about non-constant operands.
+clang_analyzer_eval((b | c) >= 20); // expected-warning{{TRUE}}
+
+// Check that we can reason about the resulting range even if
+// the types are not the same, but we still can convert operand
+// ranges.
+clang_analyzer_eval((a | b) >= 10); // expected-warning{{TRUE}}
+  }
 
   // Check that dynamically computed constants also work.
   unsigned int constant = 1 << 3;
-  unsigned int d = a | constant;
-  clang_analyzer_eval(d >= constant); // expected-warning{{TRUE}}
+  unsigned int f = a | constant;
+  clang_analyzer_eval(f >= constant); // expected-warning{{TRUE}}
 
   // Check that nested expressions also work.
   clang_analyzer_eval(((a | 10) | 5) >= 10); // expected-warning{{TRUE}}
 
+  if (a < 10) {
+clang_analyzer_eval((a | 20) >= 20);  // expected-warning{{TRUE}}
+  }
+
   // TODO: We misuse intersection of ranges for bitwise AND and OR operators.
   //   Resulting ranges for the following cases are infeasible.
   //   This is what causes paradoxical results below.
@@ -129,8 +156,4 @@
 clang_analyzer_eval((a & 1) <= 1); // expected-warning{{FALSE}}
 clang_analyzer_eval((a & 1) > 1);  // expected-warning{{FALSE}}
   }
-  if (a < 10) {
-clang_analyzer_eval((a | 20) >= 20); // expected-warning{{FALSE}}
-clang_analyzer_eval((a | 20) < 20);  // expected-warning{{FALSE}}
-  }
 }
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -69,7 +69,19 @@
 
 const llvm::APSInt ::getMinValue() const {
   assert(!isEmpty());
-  return ranges.begin()->From();
+  return begin()->From();
+}
+
+const llvm::APSInt ::getMaxValue() const {
+  assert(!isEmpty());
+  // NOTE: It's a shame that we can't implement 'getMaxValue' without scanning
+  //   the whole tree to get to the last element.
+  //   llvm::ImmutableSet should support decrement for 'end' iterators
+  //   or reverse order iteration.
+  auto It = begin();
+  for (auto End = end(); std::next(It) != End; ++It) {
+  }
+  return It->To();
 }
 
 bool RangeSet::pin(llvm::APSInt , llvm::APSInt ) const {
@@ -364,22 +376,106 @@
 }
   }
 
+  

[PATCH] D79236: [docs] Regenerate DiagnosticsReference.rst

2020-05-05 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm reclaimed this revision.
rsandifo-arm added a comment.

OK, thanks!  Reclaiming and reopening the revision in that case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79236



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


[PATCH] D79395: [clang][codegen] Hoist parameter attribute setting in function prolog.

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79395



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


[PATCH] D79434: [analyzer] Generalize bitwise AND rules for ranges

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 262158.
vsavchenko added a comment.

Add parent change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79434

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c
  clang/test/Analysis/switch-case.c
  clang/test/Analysis/uninit-exhaustive-switch-bug.c

Index: clang/test/Analysis/uninit-exhaustive-switch-bug.c
===
--- /dev/null
+++ clang/test/Analysis/uninit-exhaustive-switch-bug.c
@@ -0,0 +1,20 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// rdar://problem/54359410
+// expected-no-diagnostics
+
+int rand();
+
+void test() {
+  int offset = 0;
+  int value;
+  int test = rand();
+  switch (test & 0x1) {
+  case 0:
+  case 1:
+value = 0;
+break;
+  }
+
+  offset += value; // no-warning
+}
Index: clang/test/Analysis/switch-case.c
===
--- clang/test/Analysis/switch-case.c
+++ clang/test/Analysis/switch-case.c
@@ -218,3 +218,14 @@
 break;
   }
 }
+
+void testExhaustiveSwitch(unsigned int a) {
+  switch (a & 5) {
+  case 0 ... 5:
+clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+break;
+  default:
+clang_analyzer_warnIfReached(); // no-warning
+break;
+  }
+}
Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -78,19 +78,20 @@
 }
 
 void testBitwiseRules(unsigned int a, int b, int c) {
-  clang_analyzer_eval((a | 1) >= 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 1) >= 1);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | -1) >= -1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 2) >= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 5) >= 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 2) >= 2);   // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 5) >= 5);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | 10) >= 10); // expected-warning{{TRUE}}
 
   // Argument order should not influence this
   clang_analyzer_eval((1 | a) >= 1); // expected-warning{{TRUE}}
 
-  clang_analyzer_eval((a & 1) <= 1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 2) <= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 5) <= 5); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 10) <= 10); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) <= 1);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) >= 0);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 2) <= 2);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 5) <= 5);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 10) <= 10);  // expected-warning{{TRUE}}
   clang_analyzer_eval((a & -10) <= 10); // expected-warning{{UNKNOWN}}
 
   // Again, check for different argument order.
@@ -104,22 +105,37 @@
   clang_analyzer_eval((b | 1) > 0); // expected-warning{{UNKNOWN}}
 
   // Even for signed values, bitwise OR with a non-zero is always non-zero.
-  clang_analyzer_eval((b | 1) == 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((b | 1) == 0);  // expected-warning{{FALSE}}
   clang_analyzer_eval((b | -2) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 10) == 0); // expected-warning{{FALSE}}
-  clang_analyzer_eval((b | 0) == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval((b | 0) == 0);  // expected-warning{{UNKNOWN}}
   clang_analyzer_eval((b | -2) >= 0); // expected-warning{{FALSE}}
 
   // Check that we can operate with negative ranges
   if (b < 0) {
 clang_analyzer_eval((b | -1) == -1);   // expected-warning{{TRUE}}
 clang_analyzer_eval((b | -10) >= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 0) == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & -10) <= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 5) >= 0); // expected-warning{{TRUE}}
 
 int e = (b | -5);
 clang_analyzer_eval(e >= -5 && e <= -1); // expected-warning{{TRUE}}
 
 if (b < -20) {
-  clang_analyzer_eval((b | e) >= -5); // expected-warning{{TRUE}}
+  clang_analyzer_eval((b | e) >= -5);// expected-warning{{TRUE}}
+  clang_analyzer_eval((b & -10) < -20);  // expected-warning{{TRUE}}
+  clang_analyzer_eval((b & e) < -20);// expected-warning{{TRUE}}
+  clang_analyzer_eval((b & -30) <= -30); // expected-warning{{TRUE}}
+
+  if (c >= -30 && c <= -10) {
+clang_analyzer_eval((b & c) <= -20); // expected-warning{{TRUE}}
+  }
+}
+
+if (a <= 40) {
+  int g = (int)a & b;
+  clang_analyzer_eval(g <= 40 && g >= 0); // expected-warning{{TRUE}}
 }
 
 // Check that we can reason about the result even if 

[PATCH] D79434: [analyzer] Generalize bitwise AND rules for ranges

2020-05-05 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko created this revision.
vsavchenko added reviewers: NoQ, dcoughlin.
vsavchenko added a project: clang.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
vsavchenko updated this revision to Diff 262158.
vsavchenko added a comment.
vsavchenko added a parent revision: D79336: [analyzer] Generalize bitwise OR 
rules for ranges.

Add parent change


Previously the current solver started reasoning about bitwise AND
expressions only when one of the operands is a constant.  However,
very similar logic could be applied to ranges.  This commit addresses
this shortcoming.  Additionally, it refines how we deal with negative
operands.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79434

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c
  clang/test/Analysis/switch-case.c
  clang/test/Analysis/uninit-exhaustive-switch-bug.c

Index: clang/test/Analysis/uninit-exhaustive-switch-bug.c
===
--- /dev/null
+++ clang/test/Analysis/uninit-exhaustive-switch-bug.c
@@ -0,0 +1,20 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// rdar://problem/54359410
+// expected-no-diagnostics
+
+int rand();
+
+void test() {
+  int offset = 0;
+  int value;
+  int test = rand();
+  switch (test & 0x1) {
+  case 0:
+  case 1:
+value = 0;
+break;
+  }
+
+  offset += value; // no-warning
+}
Index: clang/test/Analysis/switch-case.c
===
--- clang/test/Analysis/switch-case.c
+++ clang/test/Analysis/switch-case.c
@@ -218,3 +218,14 @@
 break;
   }
 }
+
+void testExhaustiveSwitch(unsigned int a) {
+  switch (a & 5) {
+  case 0 ... 5:
+clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+break;
+  default:
+clang_analyzer_warnIfReached(); // no-warning
+break;
+  }
+}
Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -78,19 +78,20 @@
 }
 
 void testBitwiseRules(unsigned int a, int b, int c) {
-  clang_analyzer_eval((a | 1) >= 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 1) >= 1);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | -1) >= -1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 2) >= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 5) >= 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 2) >= 2);   // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 5) >= 5);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | 10) >= 10); // expected-warning{{TRUE}}
 
   // Argument order should not influence this
   clang_analyzer_eval((1 | a) >= 1); // expected-warning{{TRUE}}
 
-  clang_analyzer_eval((a & 1) <= 1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 2) <= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 5) <= 5); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 10) <= 10); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) <= 1);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) >= 0);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 2) <= 2);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 5) <= 5);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 10) <= 10);  // expected-warning{{TRUE}}
   clang_analyzer_eval((a & -10) <= 10); // expected-warning{{UNKNOWN}}
 
   // Again, check for different argument order.
@@ -104,22 +105,37 @@
   clang_analyzer_eval((b | 1) > 0); // expected-warning{{UNKNOWN}}
 
   // Even for signed values, bitwise OR with a non-zero is always non-zero.
-  clang_analyzer_eval((b | 1) == 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((b | 1) == 0);  // expected-warning{{FALSE}}
   clang_analyzer_eval((b | -2) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 10) == 0); // expected-warning{{FALSE}}
-  clang_analyzer_eval((b | 0) == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval((b | 0) == 0);  // expected-warning{{UNKNOWN}}
   clang_analyzer_eval((b | -2) >= 0); // expected-warning{{FALSE}}
 
   // Check that we can operate with negative ranges
   if (b < 0) {
 clang_analyzer_eval((b | -1) == -1);   // expected-warning{{TRUE}}
 clang_analyzer_eval((b | -10) >= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 0) == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & -10) <= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 5) >= 0); // expected-warning{{TRUE}}
 
 int e = (b | -5);
 clang_analyzer_eval(e >= -5 && e <= -1); // expected-warning{{TRUE}}
 
 if (b < -20) {
-  clang_analyzer_eval((b | e) >= -5); // expected-warning{{TRUE}}
+  

[PATCH] D79433: [analyzer] StdLibraryFunctionsChecker: Add summaries for POSIX

2020-05-05 Thread Gabor Marton via Phabricator via cfe-commits
martong created this revision.
martong added reviewers: Szelethus, NoQ, baloghadamsoftware, balazske, steakhal.
Herald added subscribers: cfe-commits, ASDenysPetrov, Charusso, gamesh411, 
dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, rnkovacs, szepet, xazax.hun, 
whisperity.
Herald added a project: clang.
martong added parent revisions: D77148: [analyzer] ApiModeling: Add buffer size 
arg constraint with multiplier involved, D79430: [analyzer] 
StdLibraryFunctionsChecker: Add LazyRanges to support type dependent Max.

Add functions for POSIX. Contrary to libc, Posix functions do not contain any
nonull attributes, thus providing nonull information through this checker adds
high value. The code in this patch is auto generated from Cppcheck's config
directory (https://github.com/danmar/cppcheck/blob/master/cfg/std.cfg). The
list is as complete as it is in Cppcheck. I measered the effect of these newly
added summaries on real projects: tmux, redis, curl. The number of bugs has
increased by 3-6%. During these tests it turned out that some summaries were
not correct in the original config file for Cppcheck, those errors have been
corrected in this patch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79433

Files:
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -790,7 +790,10 @@
   // or long long, so three summary variants would be enough).
   // Of course, function variants are also useful for C++ overloads.
   const QualType IntTy = ACtx.IntTy;
+  const QualType SizeTy = ACtx.getSizeType();
   const QualType VoidPtrTy = ACtx.VoidPtrTy; // void *
+  const QualType ConstVoidPtrTy =
+  ACtx.getPointerType(ACtx.VoidTy.withConst()); // const void *
   const QualType ConstCharPtrTy =
   ACtx.getPointerType(ACtx.CharTy.withConst()); // const char *
 
@@ -1077,6 +1080,1307 @@
   Summary(NoEvalCall)
   .Case({ReturnValueCondition(WithinRange, {{-1, -1}, {1, Max}})}));
 
+  // POSIX
+
+  // long a64l(const char *str64);
+  addToFunctionSummaryMap("a64l",
+  Summary(NoEvalCall).ArgConstraint(NotNull(ArgNo(0;
+
+  // char *l64a(long value);The behavior of l64a() is undefined when
+  // value is negative.
+  addToFunctionSummaryMap("l64a", Summary(NoEvalCall)
+  .ArgConstraint(ArgumentCondition(
+  0, WithinRange, Range(0, Max;
+
+  // int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+  addToFunctionSummaryMap("accept", Summary(NoEvalCall)
+.ArgConstraint(ArgumentCondition(
+0, WithinRange, Range(0, Max;
+
+  // int access(const char *pathname, int amode);
+  addToFunctionSummaryMap("access",
+  Summary(NoEvalCall).ArgConstraint(NotNull(ArgNo(0;
+
+  // int bind(int socket, const struct sockaddr *address, socklen_t
+  // address_len);
+  addToFunctionSummaryMap(
+  "bind",
+  Summary(NoEvalCall)
+  .ArgConstraint(ArgumentCondition(0, WithinRange, Range(0, Max)))
+  // FIXME The below param is actually a transparent union in C
+  // (__CONST_SOCKADDR_ARG). We should be able to handle transparent
+  // union of pointers as a pointer. See the attribute
+  // __transparent_union__ .
+  //.ArgConstraint(NotNull(ArgNo(1)))
+  .ArgConstraint(BufferSize(1, 2))
+  .ArgConstraint(ArgumentCondition(2, WithinRange, Range(0, Max;
+
+  // int listen(int sockfd, int backlog);
+  addToFunctionSummaryMap("listen", Summary(NoEvalCall)
+.ArgConstraint(ArgumentCondition(
+0, WithinRange, Range(0, Max;
+
+  // int getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+  addToFunctionSummaryMap(
+  "getpeername",
+  Summary(NoEvalCall)
+  .ArgConstraint(ArgumentCondition(0, WithinRange, Range(0, Max)))
+  // FIXME The below param is actually a transparent union in C
+  // (__CONST_SOCKADDR_ARG). We should be able to handle transparent
+  // union of pointers as a pointer. See the attribute
+  // __transparent_union__ .
+  //.ArgConstraint(NotNull(ArgNo(1)))
+  .ArgConstraint(NotNull(ArgNo(2;
+
+  // int getsockname(int sockfd, struct sockaddr *addr, socklen_t *addrlen);
+  addToFunctionSummaryMap(
+  "getsockname",
+  Summary(NoEvalCall)
+  .ArgConstraint(ArgumentCondition(0, WithinRange, Range(0, Max)))
+  // FIXME The below param is actually a transparent union in C
+  // 

[PATCH] D78827: Add support for #pragma clang fp reassociate(fast|off) -- floating point control of associative math transformations

2020-05-05 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

The reason we call FP contraction "fast" instead of "on" when it's 
cross-statement is because "on" is supposed to be consistent with the C 
language rules, whereas "fast" is stronger.  There's no analogous situation 
with reassociation; I don't think the C standard is likely to ever bless 
reassociative FP math with an expression-local restriction.  Steve, do you 
actually think that would be a useful optimization mode?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827



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


  1   2   3   >