[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru created this revision.
sylvestre.ledru added reviewers: tstellar, MaskRay.
Herald added a subscriber: mgorny.
sylvestre.ledru requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Currently, it is a bit buried in the file even if this is
pretty important for distro.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108533

Files:
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -48,6 +48,8 @@
   clangTooling
 )
 
+SET(CLANG_SONAME 13)
+
 if (CLANG_ENABLE_ARCMT)
   list(APPEND LIBS clangARCMigrate)
 endif ()
@@ -176,7 +178,7 @@
 # LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION 
${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -48,6 +48,8 @@
   clangTooling
 )
 
+SET(CLANG_SONAME 13)
+
 if (CLANG_ENABLE_ARCMT)
   list(APPEND LIBS clangARCMigrate)
 endif ()
@@ -176,7 +178,7 @@
 # LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[JinGu Kang via Phabricator via cfe-commits]

jaykang10 added a comment.

If possible, can you add more tests for different types as previous patch 
please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108470

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

[PATCH] D108045: [clangd] Fix clangd crash when including a header

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

Thanks, I can see the problem now (sorry for the late reply, i was on leave 
last week).

It is amazing that this hasn't bitten us yet during code complete flow (it 
probably did, but clangd would recover after restart so probably people didn't 
notice).
I still don't think that we'd like to parse all the new includes during code 
completion flow hence we should just create a preamble patch for the macro 
directives that moved around. (I don't think we should make the parser more 
resilient instead).
Do you mind adding a new factory function to PreamblePatch for creating a 
macro-directive only patch that can be used in CodeComplete flow to prevent 
crashes (while paying for some extra latency :/  )?

As for storing source locations, i think we can just store the offsets (we 
already have them in `spellDirective` when we decompose sourcelocation.

Does that make sense?




Comment at: clang-tools-extra/clangd/Preamble.cpp:511
 
   if (DirectivesChanged) {
 // We need to patch all the directives, since they are order dependent. 
e.g:

this is the condition i am suggesting to drop.



Comment at: clang-tools-extra/clangd/unittests/PreambleTests.cpp:553
+  llvm::StringLiteral Modified =
+  "#include \"header.h\"\n#define MACRO 12\nint num = MACRO;";
+  auto AST = createPatchedAST(Baseline, Modified);

we actually have a more problematic case, you can just insert whitespace to the 
first line rather than the `include` directive. now all the offsets are wrong 
but there's nothing to patch.


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

https://reviews.llvm.org/D108045

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

[PATCH] D54943: [clang-tidy] implement const-transformation for cppcoreguidelines-const-correctness

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

thanks for your testing! i will look at the `__unaligned` issue, not sure if 
clang supports it, its an MSVC extension, is it?

Did the transformations produce issues and approximately how much code did you 
check? I would like to get a better feeling for its quality before enabling it 
by default.




Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/ConstCorrectnessCheck.cpp:168
+*Variable, *Result.Context, DeclSpec::TQ_const,
+QualifierTarget::Value, QualifierPolicy::Right)) {
+  Diag << *Fix;

tiagoma wrote:
> The core guidelines suggests the use of west const. Could this be made the 
> default?
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rl-const
https://reviews.llvm.org/D69764


I was hoping for this feature to handle this instead.
It is extremely complicated to figure out where to insert the `const`, because 
pointer, pointee, value, templates, macros and so on and so forth.
I implemented it such that it is always correct (the right side) and hoped that 
clang-format can fix it up afterwards (`clang-tidy -fix -format`)



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/ConstCorrectnessCheck.h:31
+WarnPointersAsValues(Options.get("WarnPointersAsValues", 0)),
+TransformValues(Options.get("TransformValues", 1)),
+TransformReferences(Options.get("TransformReferences", 1)),

tiagoma wrote:
> JonasToth wrote:
> > Deactivating the transformations by default, as they are not ready for 
> > production yet.
> Ok. This got me off-guard. I would rather have this on.
the transformations were buggy and required a lot of fix-up. This might not be 
the case, but i would rather have it non-destructive by default because i think 
many people will throw this check at their code-base.

if the transformations are solid already we can activate it again (or maybe 
references only or so).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54943

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

[PATCH] D107347: [Sema] haveSameParameterTypes - fix repeated isNull() test

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107347

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

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.



Comment at: clang/lib/Sema/OpenCLBuiltins.td:1121
+let Extension = FuncExtFloatAtomicsFp32GlobalAdd in {
+def:
+  Builtin<"atomic_fetch_" #ModOp,

Please try to follow the formatting used in the rest of this file:
```
def : Builtin<...
```
So a space after `def`, then no newline after the `:`.

This applies to all the new `def`s below too.



Comment at: clang/lib/Sema/OpenCLBuiltins.td:1122
+def:
+  Builtin<"atomic_fetch_" #ModOp,
+  [Float, PointerType, GlobalAS>, 
Float]>;

The paste operator `#` is a binary operator, so it makes more sense to put a 
space on both sides.



Comment at: clang/lib/Sema/OpenCLBuiltins.td:1198
+}
+let Extension = FuncExtFloatAtomicsFp64GlobalAdd in {
+def:

Wrong extension guard.



Comment at: clang/lib/Sema/OpenCLBuiltins.td:1294
+}
+let Extension = FuncExtFloatAtomicsFp64GlobalMinMax in {
+def:

Wrong extension guard.


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

https://reviews.llvm.org/D106343

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

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

[Andy Wingo via Phabricator via cfe-commits]

wingo added a subscriber: tlively.
wingo added a comment.

In D108464#2957276 , @wingo wrote:

> So... besides the refactor, this is getting closer to where I'm going in 
> https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though still 
> NFC.  I think you can see where I would replace `getASTAllocaAddressSpace` 
> with `getAllocaAddressSpace(QualType Ty)`, and possibly (depending on the 
> source language) avoid casting the resulting alloca to `LangAS::Default`.  
> WDYT, is this sort of thing OK?

Taking this patch as perhaps a better generic discussion point, @rjmccall 
graciously gave some general feedback on this approach (thank you!!!):

In D108360#2957844 , @rjmccall wrote:

> I'm not sure that I agree with your overall plan, though:
>
> - The WebAssembly operand stack is not a good match for an address space at 
> the language level because it's not addressable at all.  If you can't 
> meaningfully have a pointer into the address space, then you don't really 
> need this in the type system; it's more like a declaration modifier at best.
> - Allocating local variables on the operand stack ought to be a very 
> straightforward analysis in the backend.  There's not much optimization value 
> in trying to do it in the frontend, and it's going to be problematic for 
> things like coroutine lowering.
> - The security argument seems pretty weak, not because security isn't 
> important but because this is not really an adequate basis for getting the 
> tamper-proof guarantee you want.  For example, LLVM passes can and do 
> introduce its own allocas and store scalars into them sometimes.  Really you 
> need some sort of "tamper-proof" *type* which the compiler can make an 
> end-to-end guarantee of non-tamper-ability for the values of, and while 
> optimally this would be implemented by just keeping values on the operand 
> stack, in the general case you will need to have some sort of strategy for 
> keeping things in memory.

Thanks for thinking about this!  Indeed I started out with the goal of not 
going deep into clang and if it's possible to avoid going too deeply, that 
would be better for everyone involved.  I am starting to think however that it 
may be unavoidable for me at least.

So, I am focusing on WebAssembly global and local variables; the WebAssembly 
operand stack is an artifact of the IR-to-MC lowering and AFAICS doesn't have 
any bearing on what clang does -- though perhaps I am misunderstanding what you 
are getting at here.  The issue is not to allocate locals on the operand stack, 
but rather to allocate them as part of the "locals" of a WebAssembly function 
.  Cc 
@tlively on the WebAssembly side.

I agree that the security argument is weak: it's something but it's not the 
real motivation.

The main motivator is the ability to have "reference type" 
 
(`externref`/`funcref`) locals and globals 
 at all.  
Reference-typed values can't be stored to linear memory.  They have no size and 
no byte representation -- they are opaque values from the host.  However, 
WebAssembly locals and globals can define storage locations of type `externref` 
or `funcref`.  The storage locations for WebAssembly locals and globals are not 
in linear memory, and are not addressable by pointer at run-time -- accesses to 
them are always by immediate.

Currently, clang always produces LLVM IR that allocates C++ globals and locals 
in linear memory.  LLVM may transform some of these to WebAssembly globals or 
locals at its discretion.  This strategy works because all values for the 
initial set of types supported by WebAssembly can be stored to linear memory; 
what you can do with a WebAssembly global or local was a subset of what you 
could do with linear-memory globals and alloca locals.

However, with reference types (merged into the spec earlier this year), this is 
no longer the case -- there are now types representable in WebAssembly 
globals/locals which can't be represented in linear memory.

Because of the limitations in how WebAssembly globals and locals can be used, 
reference-typed values have associated semantic restrictions in the front-end.  
If I declare a C++ local of type externref (which must be allocated to a 
WebAssembly local), I can't take its address:

  void f() {
externref_t x = g();
h(&x); // error
  }

Similarly I can't put an externref in an aggregate type that itself is 
allocated in linear memory:

  // global
  struct { int x; externref_t y; } z; // error

But, if we add a generic OpenCL-like address space attribute, that would allow 
the user to declare some variables to be in alternate address spaces.  Then we 
can apply the ACLE SVE semantic restrictions 

[PATCH] D108461: [OpenCL] Supports optional generic address space in C++ for OpenCL 2021

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/lib/Headers/opencl-c-base.h:33
 // Define feature macros for OpenCL C 2.0
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ == 200)
+#if (__OPENCL_CPP_VERSION__ != 202100)

I think we should just check here that C++ for OpenCL version is 1.0 so the 
same as for OpenCL C 2.0 because the same logic applies to it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108461

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

[PATCH] D108449: [clang][NFC] Tighten up code for GetGlobalVarAddressSpace

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108449

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

[PATCH] D107553: [C++4OpenCL] Initialize temporaries in the private address space

[Anastasia Stulova via Phabricator via cfe-commits]

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

LGTM! Thanks


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

https://reviews.llvm.org/D107553

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

[PATCH] D108202: [tsan] Add support for disable_sanitizer_instrumentation attribute

[Alexander Potapenko via Phabricator via cfe-commits]

glider updated this revision to Diff 368056.
glider marked 5 inline comments as done.
glider added a comment.

Addressed Marco's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108202

Files:
  clang/docs/ThreadSanitizer.rst
  clang/test/CodeGen/sanitize-thread-disable.c
  llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp


Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -562,6 +562,12 @@
   // all.
   if (F.hasFnAttribute(Attribute::Naked))
 return false;
+
+  // __attribute__(disable_sanitizer_instrumentation) prevents all kinds of
+  // instrumentation.
+  if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
+return false;
+
   initialize(*F.getParent());
   SmallVector AllLoadsAndStores;
   SmallVector LocalLoadsAndStores;
Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -0,0 +1,57 @@
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
+
+#include 
+
+// Instrumented function.
+// TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
+// Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
+// __tsan_atomicXXX_load().
+//
+// CHECK-LABEL: @instrumented1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+int instrumented1(int *a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with no_sanitize("thread").
+// TSan only inserts instrumentation necessary to prevent false positives: 
calls are inserted for
+// function entry/exit and atomics, but not plain memory accesses.
+//
+// CHECK-LABEL: @no_false_positives1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with disable_sanitizer_instrumentation: no instrumentation at all.
+//
+// CHECK-LABEL: @no_instrumentation1
+// TSAN-NOT: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN-NOT: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN-NOT: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}
Index: clang/docs/ThreadSanitizer.rst
===
--- clang/docs/ThreadSanitizer.rst
+++ clang/docs/ThreadSanitizer.rst
@@ -100,6 +100,16 @@
 traces.  This attribute may not be supported by other compilers, so we suggest
 to use it together with ``__has_feature(thread_sanitizer)``.
 
+``__attribute__((disable_sanitizer_instrumentation))``
+
+
+The ``disable_sanitizer_instrumentation`` attribute can be applied to functions
+to prevent all kinds of instrumentation. As a result, it may introduce false
+positives and incorrect stack traces. Therefore, it should be used with care,
+and only if absolutely required; for example for certain code that cannot
+tolerate any instrumentation and resulting side-effects. This attribute
+overrides ``no_sanitize("thread")``.
+
 Ignorelist
 --
 


Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -562,6 +562,12 @@
   // all.
   if (F.hasFnAttribute(Attribute::Naked))
 return false;
+
+  // __attribute__(disable_sanitizer_instrumentation) prevents all kinds of
+  // instrumentation.
+  if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
+  

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh updated this revision to Diff 368058.
svenvh added a comment.

Added more tests as requested.


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

https://reviews.llvm.org/D108470

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGenOpenCL/preserve_vec3.cl


Index: clang/test/CodeGenOpenCL/preserve_vec3.cl
===
--- clang/test/CodeGenOpenCL/preserve_vec3.cl
+++ clang/test/CodeGenOpenCL/preserve_vec3.cl
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown 
-fpreserve-vec3-type | FileCheck %s
 
 typedef char char3 __attribute__((ext_vector_type(3)));
+typedef char char8 __attribute__((ext_vector_type(8)));
 typedef short short3 __attribute__((ext_vector_type(3)));
 typedef double double2 __attribute__((ext_vector_type(2)));
 typedef float float3 __attribute__((ext_vector_type(3)));
@@ -38,6 +39,15 @@
   *b = __builtin_astype(*a, double2);
 }
 
+void kernel char8_to_short3(global short3 *a, global char8 *b) {
+  // CHECK-LABEL: spir_kernel void @char8_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast <8 x i8> addrspace(1)* %b to <4 x i16> 
addrspace(1)*
+  // CHECK: %[[LOAD_B:.*]] = load <4 x i16>, <4 x i16> addrspace(1)* %[[IN_BC]]
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[LOAD_B]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %a, align 8
+  *a = __builtin_astype(*b, short3);
+}
+
 void from_char3(char3 a, global int *out) {
   // CHECK-LABEL: void @from_char3
   // CHECK: %[[ASTYPE:.*]] = shufflevector <3 x i8> %a, <3 x i8> poison, <4 x 
i32> 
@@ -53,3 +63,19 @@
   // CHECK: store <4 x i16> %[[ASTYPE]], <4 x i16> addrspace(1)* %[[OUT_BC]]
   *out = __builtin_astype(a, long);
 }
+
+void scalar_to_char3(int a, global char3 *out) {
+  // CHECK-LABEL: void @scalar_to_char3
+  // CHECK: %[[IN_BC:.*]] = bitcast i32 %a to <4 x i8>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i8> %[[IN_BC]], <4 x i8> 
poison, <3 x i32> 
+  // CHECK: store <3 x i8> %[[ASTYPE]], <3 x i8> addrspace(1)* %out
+  *out = __builtin_astype(a, char3);
+}
+
+void scalar_to_short3(long a, global short3 *out) {
+  // CHECK-LABEL: void @scalar_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast i64 %a to <4 x i16>
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[IN_BC]], <4 x i16> 
poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %out
+  *out = __builtin_astype(a, short3);
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -4796,12 +4796,10 @@
   // to vec4 if the original type is not vec4, then a shuffle vector to
   // get a vec3.
   if (NumElementsSrc != 3 && NumElementsDst == 3) {
-if (!CGF.CGM.getCodeGenOpts().PreserveVec3Type) {
-  auto *Vec4Ty = llvm::FixedVectorType::get(
-  cast(DstTy)->getElementType(), 4);
-  Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
- Vec4Ty);
-}
+auto *Vec4Ty = llvm::FixedVectorType::get(
+cast(DstTy)->getElementType(), 4);
+Src = createCastsForTypeOfSameSize(Builder, CGF.CGM.getDataLayout(), Src,
+   Vec4Ty);
 
 Src = ConvertVec3AndVec4(Builder, CGF, Src, 3);
 Src->setName("astype");


Index: clang/test/CodeGenOpenCL/preserve_vec3.cl
===
--- clang/test/CodeGenOpenCL/preserve_vec3.cl
+++ clang/test/CodeGenOpenCL/preserve_vec3.cl
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown -fpreserve-vec3-type | FileCheck %s
 
 typedef char char3 __attribute__((ext_vector_type(3)));
+typedef char char8 __attribute__((ext_vector_type(8)));
 typedef short short3 __attribute__((ext_vector_type(3)));
 typedef double double2 __attribute__((ext_vector_type(2)));
 typedef float float3 __attribute__((ext_vector_type(3)));
@@ -38,6 +39,15 @@
   *b = __builtin_astype(*a, double2);
 }
 
+void kernel char8_to_short3(global short3 *a, global char8 *b) {
+  // CHECK-LABEL: spir_kernel void @char8_to_short3
+  // CHECK: %[[IN_BC:.*]] = bitcast <8 x i8> addrspace(1)* %b to <4 x i16> addrspace(1)*
+  // CHECK: %[[LOAD_B:.*]] = load <4 x i16>, <4 x i16> addrspace(1)* %[[IN_BC]]
+  // CHECK: %[[ASTYPE:.*]] = shufflevector <4 x i16> %[[LOAD_B]], <4 x i16> poison, <3 x i32> 
+  // CHECK: store <3 x i16> %[[ASTYPE]], <3 x i16> addrspace(1)* %a, align 8
+  *a = __builtin_astype(*b, short3);
+}
+
 void from_char3(char3 a, global int *out) {
   // CHECK-LABEL: void @from_char3
   // CHECK: %[[ASTYPE:.*]] = shufflevector <3 x i8> %a, <3 x i8> poison, <4 x i32> 
@@ -53,3 +63,19 @@
   // CHECK: store <4 x i16> %[[ASTYPE]], <4 x i16> addrspace(1)* %[[OUT_BC]]
   *out = __builtin_astype(a, long);
 }
+
+void scalar_to_char3(int a, global c

[PATCH] D108538: [clang-format] break after the closing paren of a TypeScript decoration

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir created this revision.
krasimir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes up a case that regressed from
https://reviews.llvm.org/D105964: in specific contexts, clang-format
stopped breaking after the `)` in TypeScript decorations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108538

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/unittests/Format/FormatTestJS.cpp


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -701,6 +701,27 @@
getGoogleJSStyleWithColumns(20)));
 }
 
+TEST_F(FormatTestJS, FormatsDecoratedFunctions) {
+  // Regression test: ensure that there is a break before `get`.
+  EXPECT_EQ("class A {\n"
+"  private p = () => {}\n"
+"\n"
+"  @decorated('a')\n"
+"  get f() {\n"
+"return result;\n"
+"  }\n"
+"}",
+format("class A {\n"
+   "  private p = () => {}\n"
+   "\n"
+   "  @decorated('a')\n"
+   "  get f() {\n"
+   "return result;\n"
+   "  }\n"
+   "}",
+   getGoogleJSStyleWithColumns(50)));
+}
+
 TEST_F(FormatTestJS, GeneratorFunctions) {
   verifyFormat("function* f() {\n"
"  let x = 1;\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -14,6 +14,7 @@
 #include "ContinuationIndenter.h"
 #include "BreakableToken.h"
 #include "FormatInternal.h"
+#include "FormatToken.h"
 #include "WhitespaceManager.h"
 #include "clang/Basic/OperatorPrecedence.h"
 #include "clang/Basic/SourceManager.h"
@@ -491,6 +492,12 @@
   return true;
   }
 
+  // Break after the closing parenthesis of TypeScript decorators.
+  if (Style.Language == FormatStyle::LK_JavaScript &&
+  Previous.is(tok::r_paren) && Previous.is(TT_JavaAnnotation)) {
+return true;
+  }
+
   // If the return type spans multiple lines, wrap before the function name.
   if (((Current.is(TT_FunctionDeclarationName) &&
 // Don't break before a C# function when no break after return type


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -701,6 +701,27 @@
getGoogleJSStyleWithColumns(20)));
 }
 
+TEST_F(FormatTestJS, FormatsDecoratedFunctions) {
+  // Regression test: ensure that there is a break before `get`.
+  EXPECT_EQ("class A {\n"
+"  private p = () => {}\n"
+"\n"
+"  @decorated('a')\n"
+"  get f() {\n"
+"return result;\n"
+"  }\n"
+"}",
+format("class A {\n"
+   "  private p = () => {}\n"
+   "\n"
+   "  @decorated('a')\n"
+   "  get f() {\n"
+   "return result;\n"
+   "  }\n"
+   "}",
+   getGoogleJSStyleWithColumns(50)));
+}
+
 TEST_F(FormatTestJS, GeneratorFunctions) {
   verifyFormat("function* f() {\n"
"  let x = 1;\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -14,6 +14,7 @@
 #include "ContinuationIndenter.h"
 #include "BreakableToken.h"
 #include "FormatInternal.h"
+#include "FormatToken.h"
 #include "WhitespaceManager.h"
 #include "clang/Basic/OperatorPrecedence.h"
 #include "clang/Basic/SourceManager.h"
@@ -491,6 +492,12 @@
   return true;
   }
 
+  // Break after the closing parenthesis of TypeScript decorators.
+  if (Style.Language == FormatStyle::LK_JavaScript &&
+  Previous.is(tok::r_paren) && Previous.is(TT_JavaAnnotation)) {
+return true;
+  }
+
   // If the return type spans multiple lines, wrap before the function name.
   if (((Current.is(TT_FunctionDeclarationName) &&
 // Don't break before a C# function when no break after return type
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8300d52 - [tsan] Add support for disable_sanitizer_instrumentation attribute

[Alexander Potapenko via cfe-commits]

Author: Alexander Potapenko
Date: 2021-08-23T12:38:33+02:00
New Revision: 8300d52e8cbf757192d6b66efa537e15376bf756

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

LOG: [tsan] Add support for disable_sanitizer_instrumentation attribute

Unlike __attribute__((no_sanitize("thread"))), this one will cause TSan
to skip the entire function during instrumentation.

Depends on https://reviews.llvm.org/D108029

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

Added: 
clang/test/CodeGen/sanitize-thread-disable.c

Modified: 
clang/docs/ThreadSanitizer.rst
llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp

Removed: 




diff  --git a/clang/docs/ThreadSanitizer.rst b/clang/docs/ThreadSanitizer.rst
index 92cc9392955cc..98d5307d824f9 100644
--- a/clang/docs/ThreadSanitizer.rst
+++ b/clang/docs/ThreadSanitizer.rst
@@ -100,6 +100,16 @@ instruments such functions to avoid false positives and 
provide meaningful stack
 traces.  This attribute may not be supported by other compilers, so we suggest
 to use it together with ``__has_feature(thread_sanitizer)``.
 
+``__attribute__((disable_sanitizer_instrumentation))``
+
+
+The ``disable_sanitizer_instrumentation`` attribute can be applied to functions
+to prevent all kinds of instrumentation. As a result, it may introduce false
+positives and incorrect stack traces. Therefore, it should be used with care,
+and only if absolutely required; for example for certain code that cannot
+tolerate any instrumentation and resulting side-effects. This attribute
+overrides ``no_sanitize("thread")``.
+
 Ignorelist
 --
 

diff  --git a/clang/test/CodeGen/sanitize-thread-disable.c 
b/clang/test/CodeGen/sanitize-thread-disable.c
new file mode 100644
index 0..d3ec1425e7821
--- /dev/null
+++ b/clang/test/CodeGen/sanitize-thread-disable.c
@@ -0,0 +1,57 @@
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
+
+#include 
+
+// Instrumented function.
+// TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
+// Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
+// __tsan_atomicXXX_load().
+//
+// CHECK-LABEL: @instrumented1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+int instrumented1(int *a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with no_sanitize("thread").
+// TSan only inserts instrumentation necessary to prevent false positives: 
calls are inserted for
+// function entry/exit and atomics, but not plain memory accesses.
+//
+// CHECK-LABEL: @no_false_positives1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with disable_sanitizer_instrumentation: no instrumentation at all.
+//
+// CHECK-LABEL: @no_instrumentation1
+// TSAN-NOT: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN-NOT: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN-NOT: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}

diff  --git a/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
index 87fdcc9114f44..714e21dc82bb4 100644
--- a/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -562,6 +562,12 @@ bool ThreadSanitizer::sanitizeFunction(Function &F,
   // all.
   if (F.hasFnAttribute(Attribute::Naked))
 return false;
+
+  // __attribute__(disable_sanitizer_instrumentation) prevents all kinds of
+  // instrumentation.
+  if (F.hasFnAttribute(Att

[PATCH] D108202: [tsan] Add support for disable_sanitizer_instrumentation attribute

[Alexander Potapenko via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8300d52e8cbf: [tsan] Add support for 
disable_sanitizer_instrumentation attribute (authored by glider).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108202

Files:
  clang/docs/ThreadSanitizer.rst
  clang/test/CodeGen/sanitize-thread-disable.c
  llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp


Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -562,6 +562,12 @@
   // all.
   if (F.hasFnAttribute(Attribute::Naked))
 return false;
+
+  // __attribute__(disable_sanitizer_instrumentation) prevents all kinds of
+  // instrumentation.
+  if (F.hasFnAttribute(Attribute::DisableSanitizerInstrumentation))
+return false;
+
   initialize(*F.getParent());
   SmallVector AllLoadsAndStores;
   SmallVector LocalLoadsAndStores;
Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -0,0 +1,57 @@
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
+// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
+
+#include 
+
+// Instrumented function.
+// TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
+// Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
+// __tsan_atomicXXX_load().
+//
+// CHECK-LABEL: @instrumented1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+int instrumented1(int *a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with no_sanitize("thread").
+// TSan only inserts instrumentation necessary to prevent false positives: 
calls are inserted for
+// function entry/exit and atomics, but not plain memory accesses.
+//
+// CHECK-LABEL: @no_false_positives1
+// TSAN: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
+  return *a + atomic_load(b);
+}
+
+// Function with disable_sanitizer_instrumentation: no instrumentation at all.
+//
+// CHECK-LABEL: @no_instrumentation1
+// TSAN-NOT: call void @__tsan_func_entry
+// WITHOUT-NOT: call void @__tsan_func_entry
+// TSAN-NOT: call void @__tsan_read4
+// WITHOUT-NOT: call void @__tsan_read4
+// TSAN-NOT: call i32 @__tsan_atomic32_load
+// WITHOUT-NOT: call i32 @__tsan_atomic32_load
+// TSAN-NOT: call void @__tsan_func_exit
+// WITHOUT-NOT: call void @__tsan_func_exit
+// CHECK: ret i32
+__attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
+  return *a + atomic_load(b);
+}
Index: clang/docs/ThreadSanitizer.rst
===
--- clang/docs/ThreadSanitizer.rst
+++ clang/docs/ThreadSanitizer.rst
@@ -100,6 +100,16 @@
 traces.  This attribute may not be supported by other compilers, so we suggest
 to use it together with ``__has_feature(thread_sanitizer)``.
 
+``__attribute__((disable_sanitizer_instrumentation))``
+
+
+The ``disable_sanitizer_instrumentation`` attribute can be applied to functions
+to prevent all kinds of instrumentation. As a result, it may introduce false
+positives and incorrect stack traces. Therefore, it should be used with care,
+and only if absolutely required; for example for certain code that cannot
+tolerate any instrumentation and resulting side-effects. This attribute
+overrides ``no_sanitize("thread")``.
+
 Ignorelist
 --
 


Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -562,6 +562,12 @@
   // all.
   if (F.hasFnAttribute(Attribute::Naked))
 return false;
+
+  // __attribute__(disable_sanitizer_instrumentation) pre

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Thomas Preud'homme via Phabricator via cfe-commits]

thopre added a comment.

In D104854#2957735 , @kpn wrote:

> In D104854#2957490 , @lebedev.ri 
> wrote:
>
>> In D104854#2957471 , @sepavloff 
>> wrote:
>>
>>> In D104854#2957423 , @spatel 
>>> wrote:
>>>
 Is it intentional that we are not canonicalizing the intrinsic call back 
 to `fcmp uno` in the default FP environment?
>>>
>>> It is lowered to unordered comparison by default. Changing `llvm.isnan` to  
>>> `fcmp uno` somewhere in IR would make it possible to optimize out the 
>>> latter if fast-math mode is on. Preserving semantics of `isnan` when 
>>> fast-math is in effect was one of the goals of this change.
>>
>> Eeek. Was there an RFC about this?
>> This does not sound good to me at all,
>> much like "let's not apply fast-math flags to x86 vector intrinsics".
>
> We can switch into and out of the default FP environment inside a single 
> function.

Really? The constrained intrinsic documentation claims the reverse 
(https://llvm.org/docs/LangRef.html#constrainedfp):

> If any FP operation in a function is constrained then they all must be 
> constrained. This is required for correct LLVM IR. Optimizations that move 
> code around can create miscompiles if mixing of constrained and normal 
> operations is done. The correct way to mix constrained and less constrained 
> operations is to use the rounding mode and exception handling metadata to 
> mark constrained intrinsics as having LLVM’s default behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a subscriber: hans.
lebedev.ri added a comment.

In D104854#2959680 , @thopre wrote:

> In D104854#2957735 , @kpn wrote:
>
>> In D104854#2957490 , @lebedev.ri 
>> wrote:
>>
>>> In D104854#2957471 , @sepavloff 
>>> wrote:
>>>
 In D104854#2957423 , @spatel 
 wrote:

> Is it intentional that we are not canonicalizing the intrinsic call back 
> to `fcmp uno` in the default FP environment?

 It is lowered to unordered comparison by default. Changing `llvm.isnan` to 
  `fcmp uno` somewhere in IR would make it possible to optimize out the 
 latter if fast-math mode is on. Preserving semantics of `isnan` when 
 fast-math is in effect was one of the goals of this change.
>>>
>>> Eeek. Was there an RFC about this?
>>> This does not sound good to me at all,
>>> much like "let's not apply fast-math flags to x86 vector intrinsics".
>>
>> We can switch into and out of the default FP environment inside a single 
>> function.
>
> Really? The constrained intrinsic documentation claims the reverse 
> (https://llvm.org/docs/LangRef.html#constrainedfp):
>
>> If any FP operation in a function is constrained then they all must be 
>> constrained. This is required for correct LLVM IR. Optimizations that move 
>> code around can create miscompiles if mixing of constrained and normal 
>> operations is done. The correct way to mix constrained and less constrained 
>> operations is to use the rounding mode and exception handling metadata to 
>> mark constrained intrinsics as having LLVM’s default behavior.

@sepavloff please can you undo the clang part of this change (+@hans) and post 
an RFC to further hash out the design here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D108453: [Clang/Test]: Enable enable_noundef_analysis as default(2)

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune updated this revision to Diff 368034.
aqjune added a comment.

Rebase, rename `disable-noundef-args` to `disable-noundef-analysis`, remove 
redundant diffs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108453

Files:
  clang/test/CXX/except/except.spec/p14-ir.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/blocks-irgen.mm
  clang/test/CodeGen/2006-05-19-SingleEltReturn.c
  clang/test/CodeGen/2007-06-18-SextAttrAggregate.c
  clang/test/CodeGen/2009-02-13-zerosize-union-field.c
  clang/test/CodeGen/2009-05-04-EnumInreg.c
  clang/test/CodeGen/64bit-swiftcall.c
  clang/test/CodeGen/RISCV/riscv-inline-asm.c
  clang/test/CodeGen/RISCV/riscv32-ilp32-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32f-abi.c
  clang/test/CodeGen/RISCV/riscv32-ilp32f-ilp32d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64-lp64f-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64d-abi.c
  clang/test/CodeGen/RISCV/riscv64-lp64f-lp64d-abi.c
  clang/test/CodeGen/SystemZ/systemz-abi-vector.c
  clang/test/CodeGen/SystemZ/systemz-abi.c
  clang/test/CodeGen/SystemZ/systemz-inline-asm.c
  clang/test/CodeGen/WebAssembly/wasm-arguments.c
  clang/test/CodeGen/WebAssembly/wasm-main_argc_argv.c
  clang/test/CodeGen/X86/avx-union.c
  clang/test/CodeGen/X86/avx512fp16-complex-abi.c
  clang/test/CodeGen/X86/ms-x86-intrinsics.c
  clang/test/CodeGen/X86/strictfp_builtins.c
  clang/test/CodeGen/X86/x86-atomic-long_double.c
  clang/test/CodeGen/X86/x86-inline-asm-min-vector-width.c
  clang/test/CodeGen/X86/x86-long-double.cpp
  clang/test/CodeGen/X86/x86-soft-float.c
  clang/test/CodeGen/X86/x86-vec-i128.c
  clang/test/CodeGen/X86/x86_32-arguments-darwin.c
  clang/test/CodeGen/X86/x86_32-arguments-iamcu.c
  clang/test/CodeGen/X86/x86_32-arguments-linux.c
  clang/test/CodeGen/X86/x86_32-arguments-nommx.c
  clang/test/CodeGen/X86/x86_32-arguments-realign.c
  clang/test/CodeGen/X86/x86_32-arguments-win32.c
  clang/test/CodeGen/X86/x86_64-arguments-nacl.c
  clang/test/CodeGen/X86/x86_64-arguments-win32.c
  clang/test/CodeGen/X86/x86_64-arguments.c
  clang/test/CodeGen/X86/x86_64-longdouble.c
  clang/test/CodeGen/aapcs-align.cpp
  clang/test/CodeGen/aapcs64-align.cpp
  clang/test/CodeGen/aarch64-args.cpp
  clang/test/CodeGen/aarch64-byval-temp.c
  clang/test/CodeGen/aarch64-neon-3v.c
  clang/test/CodeGen/aarch64-neon-across.c
  clang/test/CodeGen/aarch64-neon-dot-product.c
  clang/test/CodeGen/aarch64-neon-extract.c
  clang/test/CodeGen/aarch64-neon-fcvt-intrinsics.c
  clang/test/CodeGen/aarch64-neon-fma.c
  clang/test/CodeGen/aarch64-neon-ldst-one.c
  clang/test/CodeGen/aarch64-neon-scalar-copy.c
  clang/test/CodeGen/aarch64-neon-scalar-x-indexed-elem.c
  clang/test/CodeGen/aarch64-neon-tbl.c
  clang/test/CodeGen/aarch64-neon-vcombine.c
  clang/test/CodeGen/aarch64-neon-vget-hilo.c
  clang/test/CodeGen/aarch64-neon-vget.c
  clang/test/CodeGen/aarch64-poly128.c
  clang/test/CodeGen/aarch64-poly64.c
  clang/test/CodeGen/aarch64-strictfp-builtins.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.c
  clang/test/CodeGen/aarch64-sve-acle-__ARM_FEATURE_SVE_VECTOR_OPERATORS.cpp
  clang/test/CodeGen/aarch64-varargs.c
  clang/test/CodeGen/address-space-field1.c
  clang/test/CodeGen/address-space.c
  clang/test/CodeGen/aix-alignment.c
  clang/test/CodeGen/aix-altivec.c
  clang/test/CodeGen/aix-ignore-xcoff-visibility.cpp
  clang/test/CodeGen/aix-return.c
  clang/test/CodeGen/aix-struct-arg.c
  clang/test/CodeGen/aix-vaargs.c
  clang/test/CodeGen/alias.c
  clang/test/CodeGen/align_value.cpp
  clang/test/CodeGen/alloc-align-attr.c
  clang/test/CodeGen/alloc-size-fnptr.c
  clang/test/CodeGen/arc/arguments.c
  clang/test/CodeGen/arithmetic-fence-builtin.c
  clang/test/CodeGen/arm-aapcs-vfp.c
  clang/test/CodeGen/arm-abi-vector.c
  clang/test/CodeGen/arm-arguments.c
  clang/test/CodeGen/arm-bf16-params-returns.c
  clang/test/CodeGen/arm-byval-align.c
  clang/test/CodeGen/arm-cmse-attr.c
  clang/test/CodeGen/arm-cmse-call.c
  clang/test/CodeGen/arm-float-helpers.c
  clang/test/CodeGen/arm-fp16-arguments.c
  clang/test/CodeGen/arm-homogenous.c
  clang/test/CodeGen/arm-mangle-bf16.cpp
  clang/test/CodeGen/arm-neon-directed-rounding.c
  clang/test/CodeGen/arm-neon-dot-product.c
  clang/test/CodeGen/arm-neon-fma.c
  clang/test/CodeGen/arm-neon-numeric-maxmin.c
  clang/test/CodeGen/arm-neon-vcvtX.c
  clang/test/CodeGen/arm-swiftcall.c
  clang/test/CodeGen/arm-varargs.c
  clang/test/CodeGen/arm-vector-arguments.c
  clang/test/CodeGen/arm-vfp16-arguments.c
  clang/test/CodeGen/arm64-aapcs-arguments.c
  clang/test/CodeGen/arm64-abi-vector.c
  clang/test/CodeGen/arm64-arguments.c
  clang/test/CodeGen/arm64-micr

[PATCH] D108453: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default (2)

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.

Hello all, I'm a messenger of @hyeongyukim's two patches that allow clang to 
turn on noundef analysis by default.
The motivation and background of these patches are described at 
https://reviews.llvm.org/D105169#2959464.

Here is a list of tests that has `RUN: %clang_cc1` replaced with `RUN: 
%clang_cc1 -disable-noundef-analysis`: F18629568: list.txt 


They are updated to simply have the `-disable-noundef-analysis` because of the 
complicatedness of fixing them.

As described in https://reviews.llvm.org/D105169#2959464, a major concern with 
turning on this flag is that it requires a lot of tests to be updated, possibly 
raising conflicts with downstreams.
To avoid this, I'd like to receive requests for tests that need 
`-disable-noundef-analysis`. If the directories or tests are specified, I'll 
simply add the flag to the `RUN:` command.
This will reduce the opportunity of raising conflicts with downstreams.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108453

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

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

I posted the RFC: 
https://lists.llvm.org/pipermail/llvm-dev/2021-August/152257.html

Depending on the feedback I'll revert the check or modify the implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[JinGu Kang via Phabricator via cfe-commits]

jaykang10 added a comment.

Can you also add "double2_to_float3" and "float4_to_float3" tests please?


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

https://reviews.llvm.org/D108470

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

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

In D108470#2959708 , @jaykang10 wrote:

> Can you also add "double2_to_float3"

Instead of `double2_to_float3`, I decided to add `char8_to_short3`.  Same idea 
(vectorN to vector3), but reinterpreting 8 chars as 3 shorts feels like a more 
realistic case than reinterpreting 2 doubles as 3 floats.  But I'm happy to add 
`double2_to_float3` if you think there is a good reason to do so.

> and "float4_to_float3" tests please?

That test is already there, see line 17.


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

https://reviews.llvm.org/D108470

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

[PATCH] D108481: Avoid nullptr dereferencing of 'Constraint'

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

Thanks for the cleanup! Btw, it's helpful if you add more context to the patch 
when generating the diff. I typically use `git diff -U` when generating a 
diff as that gives plenty of context for the patch review within Phabricator.




Comment at: clang/lib/Sema/SemaConcept.cpp:1065-1068
   assert(TC &&
  "TPL must have a template type parameter with a type constraint");
   auto *Constraint =
+  cast(TC->getImmediatelyDeclaredConstraint());

If we're going to be touching this code, there's more suspect code here that 
needs to be cleaned up a bit. Directly above this is:
```
  const TypeConstraint *TC =
  cast(TPL->getParam(0))->getTypeConstraint();
  assert(TC &&
 "TPL must have a template type parameter with a type constraint");
```
That assertion can be removed entirely -- if the `cast<>` fails, it doesn't 
return null, it asserts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108481

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

[PATCH] D108540: [clang][deps] Collect precompiled deps from submodules too

[Jan Svoboda via Phabricator via cfe-commits]

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

In this patch, the dependency scanner starts collecting precompiled 
dependencies from all encountered submodules, not only from top-level modules.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108540

Files:
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_pch.json
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/cdb_tu.json
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/mod_common.h
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/mod_tu.h
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/mod_tu_sub.h
  
clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/module.modulemap
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/pch.h
  clang/test/ClangScanDeps/Inputs/modules-pch-common-via-submodule/tu.c
  clang/test/ClangScanDeps/modules-pch-common-via-submodule.c

Index: clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/modules-pch-common-via-submodule.c
@@ -0,0 +1,133 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/modules-pch-common-via-submodule/* %t
+
+// Scan dependencies of the PCH:
+//
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch-common-via-submodule/cdb_pch.json > %t/cdb.json
+// RUN: echo -%t > %t/result_pch.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full \
+// RUN:   -generate-modules-path-args -module-files-dir %t/build >> %t/result_pch.json
+// RUN: cat %t/result_pch.json | sed 's:\?:/:g' | FileCheck %s -check-prefix=CHECK-PCH
+//
+// CHECK-PCH:  -[[PREFIX:.*]]
+// CHECK-PCH-NEXT: {
+// CHECK-PCH-NEXT:   "modules": [
+// CHECK-PCH-NEXT: {
+// CHECK-PCH-NEXT:   "clang-module-deps": [],
+// CHECK-PCH-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
+// CHECK-PCH-NEXT:   "command-line": [
+// CHECK-PCH-NEXT: "-cc1"
+// CHECK-PCH:  "-emit-module"
+// CHECK-PCH:  "-fmodules"
+// CHECK-PCH:  "-fmodule-name=ModCommon"
+// CHECK-PCH:  "-fno-implicit-modules"
+// CHECK-PCH:],
+// CHECK-PCH-NEXT:   "context-hash": "[[HASH_MOD_COMMON:.*]]",
+// CHECK-PCH-NEXT:   "file-deps": [
+// CHECK-PCH-NEXT: "[[PREFIX]]/mod_common.h",
+// CHECK-PCH-NEXT: "[[PREFIX]]/module.modulemap"
+// CHECK-PCH-NEXT:   ],
+// CHECK-PCH-NEXT:   "name": "ModCommon"
+// CHECK-PCH-NEXT: }
+// CHECK-PCH-NEXT:   ],
+// CHECK-PCH-NEXT:   "translation-units": [
+// CHECK-PCH-NEXT: {
+// CHECK-PCH-NEXT:   "clang-context-hash": "[[HASH_PCH:.*]]",
+// CHECK-PCH-NEXT:   "clang-module-deps": [
+// CHECK-PCH-NEXT: {
+// CHECK-PCH-NEXT:   "context-hash": "[[HASH_MOD_COMMON]]",
+// CHECK-PCH-NEXT:   "module-name": "ModCommon"
+// CHECK-PCH-NEXT: }
+// CHECK-PCH-NEXT:   ],
+// CHECK-PCH-NEXT:   "command-line": [
+// CHECK-PCH-NEXT: "-fno-implicit-modules"
+// CHECK-PCH-NEXT: "-fno-implicit-module-maps"
+// CHECK-PCH-DAG:  "-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON]]/ModCommon-{{.*}}.pcm"
+// CHECK-PCH-NEXT: "-fmodule-map-file=[[PREFIX]]/module.modulemap"
+// CHECK-PCH-NEXT:   ],
+// CHECK-PCH-NEXT:   "file-deps": [
+// CHECK-PCH-NEXT: "[[PREFIX]]/pch.h"
+// CHECK-PCH-NEXT:   ],
+// CHECK-PCH-NEXT:   "input-file": "[[PREFIX]]/pch.h"
+// CHECK-PCH-NEXT: }
+// CHECK-PCH-NEXT:   ]
+// CHECK-PCH-NEXT: }
+
+// Explicitly build the PCH:
+//
+// RUN: tail -n +2 %t/result_pch.json > %t/result_pch_stripped.json
+// RUN: %python %S/../../utils/module-deps-to-rsp.py %t/result_pch_stripped.json \
+// RUN:   --module-name=ModCommon > %t/mod_common.cc1.rsp
+// RUN: %python %S/../../utils/module-deps-to-rsp.py %t/result_pch_stripped.json \
+// RUN:   --tu-index=0 > %t/pch.rsp
+//
+// RUN: %clang @%t/mod_common.cc1.rsp
+// RUN: %clang -x c-header %t/pch.h -fmodules -gmodules -fimplicit-module-maps \
+// RUN:   -fmodules-cache-path=%t/cache -o %t/pch.h.gch @%t/pch.rsp
+
+// Scan dependencies of the TU:
+//
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch-common-via-submodule/cdb_tu.json > %t/cdb.json
+// RUN: echo -%t > %t/result_tu.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full \
+// RUN:   -generate-modules-path-args -module-files-dir %t/build >> %t/result_tu.json
+// RUN: cat %t/result_tu.json | sed 's:\?:/:g' | FileCheck %s -check-prefix=CHECK-TU
+//
+// CHECK-TU:  -[[PREFIX:.*]]
+// CHECK-TU-NEXT: 

[PATCH] D108540: [clang][deps] Collect precompiled deps from submodules too

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/modules-pch-common-via-submodule.c:85
+// CHECK-TU:  "-emit-module"
+// CHECK-TU:  
"-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON:.*]]/ModCommon-{{.*}}.pcm"
+// CHECK-TU:  "-fmodules"

Previously, we'd miss this module included from `mod_tu_sub.h`, resulting in a 
compilation error for `ModTU`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108540

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

[PATCH] D108538: [clang-format] break after the closing paren of a TypeScript decoration

[MyDeveloperDay via Phabricator via cfe-commits]

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

LGTM, Thanks for picking these up


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108538

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

[PATCH] D108366: [clang][deps] Deduce resource directory from the compiler path

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 added a comment.

In D108366#2955322 , @dexonsmith 
wrote:

> The patch seems mostly straightforward, but can you clarify whether there was 
> a functionality change for clang-scan-deps? My reading of the code suggests 
> not, because it was using ResourceDirectoryCache before and still will... in 
> which case, can you walk me through how the test covers this code change? 
> (Maybe some comments in the test would help.)

For `clang-scan-deps`, this is //almost// NFC. This code kicks in iff 
`ResourceDirectoryCache` doesn't provide any result:

- the execution of `CommandLine[0] -print-resource-dir` command returns a 
non-zero exit code (exercised in the test) or doesn't print anything,
- the `CommandLine` is empty,
- the compiler executable (`CommandLine[0]`) is not an absolute path.

That's why I want to check with people if we can agree on removing 
`ResourceDirectoryCache`. I'd be keen on updating this patch to include the 
change and make the test more obviously correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

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

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[JinGu Kang via Phabricator via cfe-commits]

jaykang10 added a comment.

In D108470#2959715 , @svenvh wrote:

> In D108470#2959708 , @jaykang10 
> wrote:
>
>> Can you also add "double2_to_float3"
>
> Instead of `double2_to_float3`, I decided to add `char8_to_short3`.  Same 
> idea (vectorN to vector3), but reinterpreting 8 chars as 3 shorts feels like 
> a more realistic case than reinterpreting 2 doubles as 3 floats.  But I'm 
> happy to add `double2_to_float3` if you think there is a good reason to do so.

I am sorry for asking more tests because I did not add enough tests previously.
I do not know well how many type conversions with vec3 the recent OpenCL spec 
cover but it could be good to add more the tests of the type conversions which 
the spec mentions. If you feel the tests you have added are enough for it, I am 
ok with it.

>> and "float4_to_float3" tests please?
>
> That test is already there, see line 17.

Sorry, I missed it.

LGTM


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

https://reviews.llvm.org/D108470

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

[PATCH] D108544: [clang][deps] Avoid generating arguments for missing module map files

[Jan Svoboda via Phabricator via cfe-commits]

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

Only modules that were built from preprocessed sources have 
`PresumedModuleMapFile`. Encode the optionality into the type system and avoid 
generating the `-fmodule-map-file=` arguments in such cases.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108544

Files:
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp


Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -35,7 +35,9 @@
   // Report the prebuilt modules this module uses.
   for (const auto &PrebuiltModule : Deps.PrebuiltModuleDeps) {
 CI.getFrontendOpts().ModuleFiles.push_back(PrebuiltModule.PCMFile);
-
CI.getFrontendOpts().ModuleMapFiles.push_back(PrebuiltModule.ModuleMapFile);
+if (PrebuiltModule.ModuleMapFile)
+  CI.getFrontendOpts().ModuleMapFiles.push_back(
+  *PrebuiltModule.ModuleMapFile);
   }
 
   CI.getPreprocessorOpts().ImplicitPCHInclude.clear();
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -39,7 +39,8 @@
 
   for (const PrebuiltModuleDep &PMD : PrebuiltModuleDeps) {
 Args.push_back("-fmodule-file=" + PMD.ModuleName + "=" + PMD.PCMFile);
-Args.push_back("-fmodule-map-file=" + PMD.ModuleMapFile);
+if (PMD.ModuleMapFile)
+  Args.push_back("-fmodule-map-file=" + *PMD.ModuleMapFile);
   }
 
   return Args;
Index: clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
===
--- clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
+++ clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
@@ -32,12 +32,14 @@
 struct PrebuiltModuleDep {
   std::string ModuleName;
   std::string PCMFile;
-  std::string ModuleMapFile;
+  Optional ModuleMapFile;
 
   explicit PrebuiltModuleDep(const Module *M)
   : ModuleName(M->getTopLevelModuleName()),
 PCMFile(M->getASTFile()->getName()),
-ModuleMapFile(M->PresumedModuleMapFile) {}
+ModuleMapFile(M->PresumedModuleMapFile.empty()
+  ? None
+  : Optional(M->PresumedModuleMapFile)) {}
 };
 
 /// This is used to identify a specific module.


Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -35,7 +35,9 @@
   // Report the prebuilt modules this module uses.
   for (const auto &PrebuiltModule : Deps.PrebuiltModuleDeps) {
 CI.getFrontendOpts().ModuleFiles.push_back(PrebuiltModule.PCMFile);
-CI.getFrontendOpts().ModuleMapFiles.push_back(PrebuiltModule.ModuleMapFile);
+if (PrebuiltModule.ModuleMapFile)
+  CI.getFrontendOpts().ModuleMapFiles.push_back(
+  *PrebuiltModule.ModuleMapFile);
   }
 
   CI.getPreprocessorOpts().ImplicitPCHInclude.clear();
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -39,7 +39,8 @@
 
   for (const PrebuiltModuleDep &PMD : PrebuiltModuleDeps) {
 Args.push_back("-fmodule-file=" + PMD.ModuleName + "=" + PMD.PCMFile);
-Args.push_back("-fmodule-map-file=" + PMD.ModuleMapFile);
+if (PMD.ModuleMapFile)
+  Args.push_back("-fmodule-map-file=" + *PMD.ModuleMapFile);
   }
 
   return Args;
Index: clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
===
--- clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
+++ clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
@@ -32,12 +32,14 @@
 struct PrebuiltModuleDep {
   std::string ModuleName;
   std::string PCMFile;
-  std::string ModuleMapFile;
+  Optional ModuleMapFile;
 
   explicit PrebuiltModuleDep(const Module *M)
   : ModuleName(M->getTopLevelModuleName()),
 PCMFile(M->getASTFile()->getName()),
-ModuleMapFile(M->PresumedModuleMapFile) {}
+ModuleMapFile(M->PresumedModuleMapFile.empty()
+   

[PATCH] D108360: [clang][NFC] Remove dead code

[Andy Wingo via Phabricator via cfe-commits]

wingo added a subscriber: tlively.
wingo added a comment.

Thanks for feedback!  Following up on general question in D108464 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108360

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

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for fixing up the docs! As long as we're here, I suggested some extra 
documentation wording to make it clear what the argument is and why it's used.




Comment at: clang/include/clang/Basic/AttrDocs.td:5884
 the function is assumed to fill the corresponding argument with a new
 handle.
 





Comment at: clang/include/clang/Basic/AttrDocs.td:5905
+parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
 the state of the handle. It is also assumed to require an open handle to work 
with.
 





Comment at: clang/include/clang/Basic/AttrDocs.td:5919
+If a function parameter is annotated with ``release_handle(tag)`` it is 
assumed to
 close the handle. It is also assumed to require an open handle to work with.
 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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

[PATCH] D70469: [attributes] [analyzer] Add handle related attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:4724
+  zx_status_t zx_socket_create(uint32_t options,
+   zx_handle_t __attribute__((acquire_handle)) * 
out0,
+   zx_handle_t* out1 [[clang::acquire_handle]]);

paulherman wrote:
> Sorry for the drive-by comment, but I believe that the code snippets are out 
> of date since the addition of the string param. Would you mind clarifying 
> what the param should do -- is it a project name such as "fuchsia" or is it a 
> name of the handle such as "my_awesome_pipe"? I'd be happy to take the fix, 
> but not sure which way to go.
I understand it to be the name of the handle, not a project-specific name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70469

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

[PATCH] D107095: Implement #pragma clang header_unsafe

[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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107095

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

[PATCH] D103807: [clang][deps] Ensure deterministic order of TU '-fmodule-file=' arguments

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 requested review of this revision.
jansvoboda11 added a comment.

I'm aware of the drawbacks of `std::map`, but I think having the container 
sorted at all times promotes correctness/determinism which we really care about 
in this context. Forgetting to call `sort` at all the right places is very easy 
as this patch demonstrates.

But if you are strongly opposed to using `std::map` here, I'm okay with using 
`std::unordered_map` or `llvm::StringMap` and sorting where necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103807

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

[clang] d3d4d98 - [clang][NFC] GetOrCreateLLVMGlobal takes LangAS

[Andy Wingo via cfe-commits]

Author: Andy Wingo
Date: 2021-08-23T14:55:58+02:00
New Revision: d3d4d98576f4f9b21579fa65630f5355dd9d1234

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

LOG: [clang][NFC] GetOrCreateLLVMGlobal takes LangAS

Pass a LangAS instead of a target address space to
GetOrCreateLLVMGlobal, to remove a place where the frontend assumes that
target address space 0 is special.

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

Added: 


Modified: 
clang/lib/CodeGen/CGBlocks.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/CodeGenModule.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGBlocks.cpp b/clang/lib/CodeGen/CGBlocks.cpp
index f39a56f81d41..c8bf47fdc837 100644
--- a/clang/lib/CodeGen/CGBlocks.cpp
+++ b/clang/lib/CodeGen/CGBlocks.cpp
@@ -2910,8 +2910,8 @@ llvm::Constant *CodeGenModule::getNSConcreteGlobalBlock() 
{
   if (NSConcreteGlobalBlock)
 return NSConcreteGlobalBlock;
 
-  NSConcreteGlobalBlock =
-  GetOrCreateLLVMGlobal("_NSConcreteGlobalBlock", Int8PtrTy, 0, nullptr);
+  NSConcreteGlobalBlock = GetOrCreateLLVMGlobal(
+  "_NSConcreteGlobalBlock", Int8PtrTy, LangAS::Default, nullptr);
   configureBlocksRuntimeObject(*this, NSConcreteGlobalBlock);
   return NSConcreteGlobalBlock;
 }
@@ -2920,8 +2920,8 @@ llvm::Constant *CodeGenModule::getNSConcreteStackBlock() {
   if (NSConcreteStackBlock)
 return NSConcreteStackBlock;
 
-  NSConcreteStackBlock =
-  GetOrCreateLLVMGlobal("_NSConcreteStackBlock", Int8PtrTy, 0, nullptr);
+  NSConcreteStackBlock = GetOrCreateLLVMGlobal(
+  "_NSConcreteStackBlock", Int8PtrTy, LangAS::Default, nullptr);
   configureBlocksRuntimeObject(*this, NSConcreteStackBlock);
   return NSConcreteStackBlock;
 }

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 0fdd85cc656a..7723c4e70bbf 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -2851,7 +2851,8 @@ ConstantAddress CodeGenModule::GetWeakRefReference(const 
ValueDecl *VD) {
   GlobalDecl(cast(VD)),
   /*ForVTable=*/false);
   else
-Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(), DeclTy, 0, nullptr);
+Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(), DeclTy, LangAS::Default,
+nullptr);
 
   auto *F = cast(Aliasee);
   F->setLinkage(llvm::Function::ExternalWeakLinkage);
@@ -3824,10 +3825,11 @@ bool CodeGenModule::isTypeConstant(QualType Ty, bool 
ExcludeCtor) {
 /// mangled name but some other type.
 llvm::Constant *
 CodeGenModule::GetOrCreateLLVMGlobal(StringRef MangledName, llvm::Type *Ty,
- unsigned AddrSpace, const VarDecl *D,
+ LangAS AddrSpace, const VarDecl *D,
  ForDefinition_t IsForDefinition) {
   // Lookup the entry, lazily creating it if necessary.
   llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
+  unsigned TargetAS = getContext().getTargetAddressSpace(AddrSpace);
   if (Entry) {
 if (WeakRefReferences.erase(Entry)) {
   if (D && !D->hasAttr())
@@ -3841,7 +3843,7 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef 
MangledName, llvm::Type *Ty,
 if (LangOpts.OpenMP && !LangOpts.OpenMPSimd && D)
   getOpenMPRuntime().registerTargetGlobalVariable(D, Entry);
 
-if (Entry->getValueType() == Ty && Entry->getAddressSpace() == AddrSpace)
+if (Entry->getValueType() == Ty && Entry->getAddressSpace() == TargetAS)
   return Entry;
 
 // If there are two attempts to define the same mangled name, issue an
@@ -3865,24 +3867,23 @@ CodeGenModule::GetOrCreateLLVMGlobal(StringRef 
MangledName, llvm::Type *Ty,
 }
 
 // Make sure the result is of the correct type.
-if (Entry->getType()->getAddressSpace() != AddrSpace) {
+if (Entry->getType()->getAddressSpace() != TargetAS) {
   return llvm::ConstantExpr::getAddrSpaceCast(Entry,
-  Ty->getPointerTo(AddrSpace));
+  Ty->getPointerTo(TargetAS));
 }
 
 // (If global is requested for a definition, we always need to create a new
 // global, not just return a bitcast.)
 if (!IsForDefinition)
-  return llvm::ConstantExpr::getBitCast(Entry, 
Ty->getPointerTo(AddrSpace));
+  return llvm::ConstantExpr::getBitCast(Entry, Ty->getPointerTo(TargetAS));
   }
 
   auto DAddrSpace = GetGlobalVarAddressSpace(D);
-  auto TargetAddrSpace = getContext().getTargetAddressSpace(DAddrSpace);
 
   auto *GV = new llvm::GlobalVariable(
   getModule(), Ty, false, llvm::GlobalValue::ExternalLinkage, nullptr,
   MangledName, nullptr, llvm::GlobalVariable:

[PATCH] D108445: [clang][NFC] GetOrCreateLLVMGlobal takes LangAS

[Andy Wingo via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd3d4d98576f4: [clang][NFC] GetOrCreateLLVMGlobal takes 
LangAS (authored by wingo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108445

Files:
  clang/lib/CodeGen/CGBlocks.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h

Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1478,8 +1478,8 @@
   void UpdateMultiVersionNames(GlobalDecl GD, const FunctionDecl *FD);
 
   llvm::Constant *
-  GetOrCreateLLVMGlobal(StringRef MangledName, llvm::Type *Ty,
-unsigned AddrSpace, const VarDecl *D,
+  GetOrCreateLLVMGlobal(StringRef MangledName, llvm::Type *Ty, LangAS AddrSpace,
+const VarDecl *D,
 ForDefinition_t IsForDefinition = NotForDefinition);
 
   bool GetCPUAndFeaturesAttributes(GlobalDecl GD,
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2851,7 +2851,8 @@
   GlobalDecl(cast(VD)),
   /*ForVTable=*/false);
   else
-Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(), DeclTy, 0, nullptr);
+Aliasee = GetOrCreateLLVMGlobal(AA->getAliasee(), DeclTy, LangAS::Default,
+nullptr);
 
   auto *F = cast(Aliasee);
   F->setLinkage(llvm::Function::ExternalWeakLinkage);
@@ -3824,10 +3825,11 @@
 /// mangled name but some other type.
 llvm::Constant *
 CodeGenModule::GetOrCreateLLVMGlobal(StringRef MangledName, llvm::Type *Ty,
- unsigned AddrSpace, const VarDecl *D,
+ LangAS AddrSpace, const VarDecl *D,
  ForDefinition_t IsForDefinition) {
   // Lookup the entry, lazily creating it if necessary.
   llvm::GlobalValue *Entry = GetGlobalValue(MangledName);
+  unsigned TargetAS = getContext().getTargetAddressSpace(AddrSpace);
   if (Entry) {
 if (WeakRefReferences.erase(Entry)) {
   if (D && !D->hasAttr())
@@ -3841,7 +3843,7 @@
 if (LangOpts.OpenMP && !LangOpts.OpenMPSimd && D)
   getOpenMPRuntime().registerTargetGlobalVariable(D, Entry);
 
-if (Entry->getValueType() == Ty && Entry->getAddressSpace() == AddrSpace)
+if (Entry->getValueType() == Ty && Entry->getAddressSpace() == TargetAS)
   return Entry;
 
 // If there are two attempts to define the same mangled name, issue an
@@ -3865,24 +3867,23 @@
 }
 
 // Make sure the result is of the correct type.
-if (Entry->getType()->getAddressSpace() != AddrSpace) {
+if (Entry->getType()->getAddressSpace() != TargetAS) {
   return llvm::ConstantExpr::getAddrSpaceCast(Entry,
-  Ty->getPointerTo(AddrSpace));
+  Ty->getPointerTo(TargetAS));
 }
 
 // (If global is requested for a definition, we always need to create a new
 // global, not just return a bitcast.)
 if (!IsForDefinition)
-  return llvm::ConstantExpr::getBitCast(Entry, Ty->getPointerTo(AddrSpace));
+  return llvm::ConstantExpr::getBitCast(Entry, Ty->getPointerTo(TargetAS));
   }
 
   auto DAddrSpace = GetGlobalVarAddressSpace(D);
-  auto TargetAddrSpace = getContext().getTargetAddressSpace(DAddrSpace);
 
   auto *GV = new llvm::GlobalVariable(
   getModule(), Ty, false, llvm::GlobalValue::ExternalLinkage, nullptr,
   MangledName, nullptr, llvm::GlobalVariable::NotThreadLocal,
-  TargetAddrSpace);
+  getContext().getTargetAddressSpace(DAddrSpace));
 
   // If we already created a global with the same mangled name (but different
   // type) before, take its name and remove it from its parent.
@@ -4005,10 +4006,10 @@
   LangAS ExpectedAS =
   D ? D->getType().getAddressSpace()
 : (LangOpts.OpenCL ? LangAS::opencl_global : LangAS::Default);
-  assert(getContext().getTargetAddressSpace(ExpectedAS) == AddrSpace);
+  assert(getContext().getTargetAddressSpace(ExpectedAS) == TargetAS);
   if (DAddrSpace != ExpectedAS) {
 return getTargetCodeGenInfo().performAddrSpaceCast(
-*this, GV, DAddrSpace, ExpectedAS, Ty->getPointerTo(AddrSpace));
+*this, GV, DAddrSpace, ExpectedAS, Ty->getPointerTo(TargetAS));
   }
 
   return GV;
@@ -4098,8 +4099,7 @@
 Ty = getTypes().ConvertTypeForMem(ASTTy);
 
   StringRef MangledName = getMangledName(D);
-  return GetOrCreateLLVMGlobal(MangledName, Ty,
-   getContext().getTargetAddressSpace(ASTTy), D,
+  return GetOrCreateLLVMGlobal(MangledName, Ty, ASTTy.getAddressSpace(), D,
   

[clang] 8da70fe - [clang][NFC] Tighten up code for GetGlobalVarAddressSpace

[Andy Wingo via cfe-commits]

Author: Andy Wingo
Date: 2021-08-23T14:55:58+02:00
New Revision: 8da70fed704c15d9656cbf2df190122acb975921

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

LOG: [clang][NFC] Tighten up code for GetGlobalVarAddressSpace

The LangAS local is only used in the OpenCL case; move its decl
inwards.

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 7723c4e70bbf..13d7cce880e0 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4148,16 +4148,15 @@ CharUnits 
CodeGenModule::GetTargetTypeStoreSize(llvm::Type *Ty) const {
 }
 
 LangAS CodeGenModule::GetGlobalVarAddressSpace(const VarDecl *D) {
-  LangAS AddrSpace = LangAS::Default;
   if (LangOpts.OpenCL) {
-AddrSpace = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
-assert(AddrSpace == LangAS::opencl_global ||
-   AddrSpace == LangAS::opencl_global_device ||
-   AddrSpace == LangAS::opencl_global_host ||
-   AddrSpace == LangAS::opencl_constant ||
-   AddrSpace == LangAS::opencl_local ||
-   AddrSpace >= LangAS::FirstTargetAddressSpace);
-return AddrSpace;
+LangAS AS = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
+assert(AS == LangAS::opencl_global ||
+   AS == LangAS::opencl_global_device ||
+   AS == LangAS::opencl_global_host ||
+   AS == LangAS::opencl_constant ||
+   AS == LangAS::opencl_local ||
+   AS >= LangAS::FirstTargetAddressSpace);
+return AS;
   }
 
   if (LangOpts.SYCLIsDevice &&



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

[PATCH] D108449: [clang][NFC] Tighten up code for GetGlobalVarAddressSpace

[Andy Wingo via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8da70fed704c: [clang][NFC] Tighten up code for 
GetGlobalVarAddressSpace (authored by wingo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108449

Files:
  clang/lib/CodeGen/CodeGenModule.cpp


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4148,16 +4148,15 @@
 }
 
 LangAS CodeGenModule::GetGlobalVarAddressSpace(const VarDecl *D) {
-  LangAS AddrSpace = LangAS::Default;
   if (LangOpts.OpenCL) {
-AddrSpace = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
-assert(AddrSpace == LangAS::opencl_global ||
-   AddrSpace == LangAS::opencl_global_device ||
-   AddrSpace == LangAS::opencl_global_host ||
-   AddrSpace == LangAS::opencl_constant ||
-   AddrSpace == LangAS::opencl_local ||
-   AddrSpace >= LangAS::FirstTargetAddressSpace);
-return AddrSpace;
+LangAS AS = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
+assert(AS == LangAS::opencl_global ||
+   AS == LangAS::opencl_global_device ||
+   AS == LangAS::opencl_global_host ||
+   AS == LangAS::opencl_constant ||
+   AS == LangAS::opencl_local ||
+   AS >= LangAS::FirstTargetAddressSpace);
+return AS;
   }
 
   if (LangOpts.SYCLIsDevice &&


Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4148,16 +4148,15 @@
 }
 
 LangAS CodeGenModule::GetGlobalVarAddressSpace(const VarDecl *D) {
-  LangAS AddrSpace = LangAS::Default;
   if (LangOpts.OpenCL) {
-AddrSpace = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
-assert(AddrSpace == LangAS::opencl_global ||
-   AddrSpace == LangAS::opencl_global_device ||
-   AddrSpace == LangAS::opencl_global_host ||
-   AddrSpace == LangAS::opencl_constant ||
-   AddrSpace == LangAS::opencl_local ||
-   AddrSpace >= LangAS::FirstTargetAddressSpace);
-return AddrSpace;
+LangAS AS = D ? D->getType().getAddressSpace() : LangAS::opencl_global;
+assert(AS == LangAS::opencl_global ||
+   AS == LangAS::opencl_global_device ||
+   AS == LangAS::opencl_global_host ||
+   AS == LangAS::opencl_constant ||
+   AS == LangAS::opencl_local ||
+   AS >= LangAS::FirstTargetAddressSpace);
+return AS;
   }
 
   if (LangOpts.SYCLIsDevice &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108422: [NFC][clang] Move remaining part of X86Target.def to llvm/Support/X86TargetParser.def

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D108422#2958761 , @lebedev.ri 
wrote:

> This should be autogenerated from the main `X86.td`, otherwise this is, 
> unfortunately only partially, duplicates that.
> E.g. there isn't a single AMD CPU in there.

The intent of this list was to duplicate the list used for the `cpu_dispatch` 
feature from the Intel Compiler, which for obvious reasons didn't include AMD 
names. OUR implementation at least uses feature lists, directly, so the 
equivalent AMD cpus would work here.  At the time, I contacted a few people 
from AMD via email and invited them to improve this list if they'd like to, but 
I don't believe I ever saw a patch to do so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108422

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

[clang] 4fb0c08 - [clang][CodeGen] GetDefaultAlignTempAlloca uses preferred alignment

[Andy Wingo via cfe-commits]

Author: Andy Wingo
Date: 2021-08-23T14:55:58+02:00
New Revision: 4fb0c083429ad3119096b3fadf01954952b68a25

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

LOG: [clang][CodeGen] GetDefaultAlignTempAlloca uses preferred alignment

This function was defaulting to use the ABI alignment for the LLVM
type.  Here we change to use the preferred alignment.  This will allow
unification with GetTempAlloca, which if alignment isn't specified, uses
the preferred alignment.

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

Added: 


Modified: 
clang/lib/CodeGen/CGExpr.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 83f5f42431e0..8548a9e75f4b 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -122,7 +122,7 @@ llvm::AllocaInst 
*CodeGenFunction::CreateTempAlloca(llvm::Type *Ty,
 Address CodeGenFunction::CreateDefaultAlignTempAlloca(llvm::Type *Ty,
   const Twine &Name) {
   CharUnits Align =
-CharUnits::fromQuantity(CGM.getDataLayout().getABITypeAlignment(Ty));
+  CharUnits::fromQuantity(CGM.getDataLayout().getPrefTypeAlignment(Ty));
   return CreateTempAlloca(Ty, Align, Name);
 }
 



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

[PATCH] D108450: [clang][CodeGen] GetDefaultAlignTempAlloca uses preferred alignment

[Andy Wingo via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4fb0c083429a: [clang][CodeGen] GetDefaultAlignTempAlloca 
uses preferred alignment (authored by wingo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108450

Files:
  clang/lib/CodeGen/CGExpr.cpp


Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -122,7 +122,7 @@
 Address CodeGenFunction::CreateDefaultAlignTempAlloca(llvm::Type *Ty,
   const Twine &Name) {
   CharUnits Align =
-CharUnits::fromQuantity(CGM.getDataLayout().getABITypeAlignment(Ty));
+  CharUnits::fromQuantity(CGM.getDataLayout().getPrefTypeAlignment(Ty));
   return CreateTempAlloca(Ty, Align, Name);
 }
 


Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -122,7 +122,7 @@
 Address CodeGenFunction::CreateDefaultAlignTempAlloca(llvm::Type *Ty,
   const Twine &Name) {
   CharUnits Align =
-CharUnits::fromQuantity(CGM.getDataLayout().getABITypeAlignment(Ty));
+  CharUnits::fromQuantity(CGM.getDataLayout().getPrefTypeAlignment(Ty));
   return CreateTempAlloca(Ty, Align, Name);
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108552: [OpenMP][AMDGCN] Enable complex functions

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal created this revision.
pdhaliwal added reviewers: JonChesterfield, ronlieb, ye-luo, jdoerfert, yaxunl, 
scchan, b-sumner.
Herald added subscribers: guansong, jvesely.
pdhaliwal requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

This patch enables basic complex functionality using the ocml builtins.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108552

Files:
  clang/lib/Headers/__clang_cuda_complex_builtins.h
  clang/lib/Headers/openmp_wrappers/complex
  clang/lib/Headers/openmp_wrappers/complex.h
  clang/test/Headers/amdgcn-openmp-device-math-complex.c

Index: clang/test/Headers/amdgcn-openmp-device-math-complex.c
===
--- /dev/null
+++ clang/test/Headers/amdgcn-openmp-device-math-complex.c
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -internal-isystem %S/Inputs/include -x c -fopenmp -triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm-bc %s -o %t-host.bc
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_device_functions.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -internal-isystem %S/Inputs/include -x c -fopenmp -triple amdgcn-amd-amdhsa -aux-triple x86_64-unknown-unknown -fopenmp-targets=amdgcn-amd-amdhsa -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-host.bc -o - | FileCheck %s --check-prefixes=CHECK
+
+#include 
+
+void test_complex_f64(double _Complex a) {
+// CHECK-LABEL: define {{.*}}test_complex_f64
+#pragma omp target
+  {
+// CHECK: call { double, double } @__divdc3
+// CHECK: call { double, double } @__muldc3
+(void)(a * (a / a));
+  }
+}
+
+// CHECK: define weak {{.*}} @__divdc3
+// CHECK-DAG: call double @__ocml_fabs_f64(
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isfinite_f64(
+// CHECK-DAG: call double @__ocml_copysign_f64(
+// CHECK-DAG: call double @__ocml_scalbn_f64(
+// CHECK-DAG: call double @__ocml_logb_f64(
+
+// CHECK: define weak {{.*}} @__muldc3
+// CHECK-DAG: call i32 @__ocml_isnan_f64(
+// CHECK-DAG: call i32 @__ocml_isinf_f64(
+// CHECK-DAG: call double @__ocml_copysign_f64(
+
+void test_complex_f32(float _Complex a) {
+// CHECK-LABEL: define {{.*}}test_complex_f32
+#pragma omp target
+  {
+// CHECK: call [2 x i32] @__divsc3
+// CHECK: call [2 x i32] @__mulsc3
+(void)(a * (a / a));
+  }
+}
+
+// CHECK: define weak {{.*}} @__divsc3
+// CHECK-DAG: call float @__ocml_fabs_f32(
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isfinite_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
+// CHECK-DAG: call float @__ocml_scalbn_f32(
+// CHECK-DAG: call float @__ocml_logb_f32(
+
+// CHECK: define weak {{.*}} @__mulsc3
+// CHECK-DAG: call i32 @__ocml_isnan_f32(
+// CHECK-DAG: call i32 @__ocml_isinf_f32(
+// CHECK-DAG: call float @__ocml_copysign_f32(
Index: clang/lib/Headers/openmp_wrappers/complex.h
===
--- clang/lib/Headers/openmp_wrappers/complex.h
+++ clang/lib/Headers/openmp_wrappers/complex.h
@@ -17,10 +17,19 @@
 // We require math functions in the complex builtins below.
 #include 
 
+#ifdef __NVPTX__
 #define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
 #undef __OPENMP_NVPTX__
 #endif
 
+#ifdef __AMDGCN__
+#define __OPENMP_AMDGCN__
+#include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_AMDGCN__
+#endif
+
+#endif
+
 // Grab the host header too.
 #include_next 
Index: clang/lib/Headers/openmp_wrappers/complex
===
--- clang/lib/Headers/openmp_wrappers/complex
+++ clang/lib/Headers/openmp_wrappers/complex
@@ -17,9 +17,18 @@
 // We require std::math functions in the complex builtins below.
 #include 
 
+#ifdef __NVPTX__
 #define __OPENMP_NVPTX__
 #include <__clang_cuda_complex_builtins.h>
 #undef __OPENMP_NVPTX__
+#endif // __NVPTX__
+
+#ifdef __AMDGCN__
+#define __OPENMP_AMDGCN__
+#include <__clang_cuda_complex_builtins.h>
+#undef __OPENMP_AMDGCN__
+#endif // __AMDGCN__
+
 #endif
 
 // Grab the host header too.
@@ -43,4 +52,4 @@
 
 #pragma omp end declare variant
 
-#endif
+#endif // _LIBCPP_STD_VER
Index: clang/lib/Headers/__clang_cuda_complex_builtins.h
===
--- clang/lib/Headers/__clang_cuda_complex_builtins.h
+++ clang/lib/Headers/__clang_cuda_complex_builtins.h
@@ -16,7 +16,7 @@
 // to work with CUDA and OpenMP target offloading [in C and C++ mode].)
 
 #pragma push_macro("__DEVICE__")
-#ifdef __OPENMP_NVPTX__
+#if defined(__OPENMP_NVPTX__) || defined(__OPENMP_AMDGCN__)
 #pragma omp declare target
 #define __DEVICE__ __attribute__((noinline, nothrow, cold, weak))
 #else
@@ -26,7 +26,7 @@
 // To make the algorithms available for C and C++ in CUDA and OpenMP we select
 // different but equivalent function versions. TODO: For OpenMP we curr

[PATCH] D108370: [clang-tidy] Fix wrong FixIt about union in cppcoreguidelines-pro-type-member-init

[gehry via Phabricator via cfe-commits]

Sockke added a comment.

Any thoughts?  : )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108370

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

[PATCH] D108552: [OpenMP][AMDGCN] Enable complex functions

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Macros fine by me, haven't found time to look at what is going on with variant




Comment at: clang/lib/Headers/openmp_wrappers/complex:20
 
+#ifdef __NVPTX__
 #define __OPENMP_NVPTX__

I don't think this should be necessary - the declare variant stuff works for 
nvptx afaik


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108552

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

[PATCH] D108470: [OpenCL] Fix as_type3 invalid store creation

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

>> Instead of `double2_to_float3`, I decided to add `char8_to_short3`.  Same 
>> idea (vectorN to vector3), but reinterpreting 8 chars as 3 shorts feels like 
>> a more realistic case than reinterpreting 2 doubles as 3 floats.  But I'm 
>> happy to add `double2_to_float3` if you think there is a good reason to do 
>> so.
>
> I am sorry for asking more tests because I did not add enough tests 
> previously.
> I do not know well how many type conversions with vec3 the recent OpenCL spec 
> cover but it could be good to add more the tests of the type conversions 
> which the spec mentions. If you feel the tests you have added are enough for 
> it, I am ok with it.

You were absolutely right about asking for more tests!  I believe we now have 
much better coverage, let's see if @Anastasia (or any other reviewer) is also 
fine with the current set.


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

https://reviews.llvm.org/D108470

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

[clang] f3671a6 - [clang-format] break after the closing paren of a TypeScript decoration

[Krasimir Georgiev via cfe-commits]

Author: Krasimir Georgiev
Date: 2021-08-23T15:52:14+02:00
New Revision: f3671a688db2625ef3736ff3603ef7a9fb78610f

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

LOG: [clang-format] break after the closing paren of a TypeScript decoration

This fixes up a regression we found from
https://reviews.llvm.org/D107267: in specific contexts, clang-format
stopped breaking after the `)` in TypeScript decorations. There were no test 
cases covering this, so I added one.

Reviewed By: MyDeveloperDay

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

Added: 


Modified: 
clang/lib/Format/ContinuationIndenter.cpp
clang/unittests/Format/FormatTestJS.cpp

Removed: 




diff  --git a/clang/lib/Format/ContinuationIndenter.cpp 
b/clang/lib/Format/ContinuationIndenter.cpp
index cdb112726b80d..9561e3489c40e 100644
--- a/clang/lib/Format/ContinuationIndenter.cpp
+++ b/clang/lib/Format/ContinuationIndenter.cpp
@@ -14,6 +14,7 @@
 #include "ContinuationIndenter.h"
 #include "BreakableToken.h"
 #include "FormatInternal.h"
+#include "FormatToken.h"
 #include "WhitespaceManager.h"
 #include "clang/Basic/OperatorPrecedence.h"
 #include "clang/Basic/SourceManager.h"
@@ -491,6 +492,12 @@ bool ContinuationIndenter::mustBreak(const LineState 
&State) {
   return true;
   }
 
+  // Break after the closing parenthesis of TypeScript decorators.
+  if (Style.Language == FormatStyle::LK_JavaScript &&
+  Previous.is(tok::r_paren) && Previous.is(TT_JavaAnnotation)) {
+return true;
+  }
+
   // If the return type spans multiple lines, wrap before the function name.
   if (((Current.is(TT_FunctionDeclarationName) &&
 // Don't break before a C# function when no break after return type

diff  --git a/clang/unittests/Format/FormatTestJS.cpp 
b/clang/unittests/Format/FormatTestJS.cpp
index 1c174e9e5b170..8da822d0ccfc0 100644
--- a/clang/unittests/Format/FormatTestJS.cpp
+++ b/clang/unittests/Format/FormatTestJS.cpp
@@ -701,6 +701,27 @@ TEST_F(FormatTestJS, FormatsFreestandingFunctions) {
getGoogleJSStyleWithColumns(20)));
 }
 
+TEST_F(FormatTestJS, FormatsDecoratedFunctions) {
+  // Regression test: ensure that there is a break before `get`.
+  EXPECT_EQ("class A {\n"
+"  private p = () => {}\n"
+"\n"
+"  @decorated('a')\n"
+"  get f() {\n"
+"return result;\n"
+"  }\n"
+"}",
+format("class A {\n"
+   "  private p = () => {}\n"
+   "\n"
+   "  @decorated('a')\n"
+   "  get f() {\n"
+   "return result;\n"
+   "  }\n"
+   "}",
+   getGoogleJSStyleWithColumns(50)));
+}
+
 TEST_F(FormatTestJS, GeneratorFunctions) {
   verifyFormat("function* f() {\n"
"  let x = 1;\n"



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

[PATCH] D108538: [clang-format] break after the closing paren of a TypeScript decoration

[Krasimir Georgiev via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf3671a688db2: [clang-format] break after the closing paren 
of a TypeScript decoration (authored by krasimir).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108538

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/unittests/Format/FormatTestJS.cpp


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -701,6 +701,27 @@
getGoogleJSStyleWithColumns(20)));
 }
 
+TEST_F(FormatTestJS, FormatsDecoratedFunctions) {
+  // Regression test: ensure that there is a break before `get`.
+  EXPECT_EQ("class A {\n"
+"  private p = () => {}\n"
+"\n"
+"  @decorated('a')\n"
+"  get f() {\n"
+"return result;\n"
+"  }\n"
+"}",
+format("class A {\n"
+   "  private p = () => {}\n"
+   "\n"
+   "  @decorated('a')\n"
+   "  get f() {\n"
+   "return result;\n"
+   "  }\n"
+   "}",
+   getGoogleJSStyleWithColumns(50)));
+}
+
 TEST_F(FormatTestJS, GeneratorFunctions) {
   verifyFormat("function* f() {\n"
"  let x = 1;\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -14,6 +14,7 @@
 #include "ContinuationIndenter.h"
 #include "BreakableToken.h"
 #include "FormatInternal.h"
+#include "FormatToken.h"
 #include "WhitespaceManager.h"
 #include "clang/Basic/OperatorPrecedence.h"
 #include "clang/Basic/SourceManager.h"
@@ -491,6 +492,12 @@
   return true;
   }
 
+  // Break after the closing parenthesis of TypeScript decorators.
+  if (Style.Language == FormatStyle::LK_JavaScript &&
+  Previous.is(tok::r_paren) && Previous.is(TT_JavaAnnotation)) {
+return true;
+  }
+
   // If the return type spans multiple lines, wrap before the function name.
   if (((Current.is(TT_FunctionDeclarationName) &&
 // Don't break before a C# function when no break after return type


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -701,6 +701,27 @@
getGoogleJSStyleWithColumns(20)));
 }
 
+TEST_F(FormatTestJS, FormatsDecoratedFunctions) {
+  // Regression test: ensure that there is a break before `get`.
+  EXPECT_EQ("class A {\n"
+"  private p = () => {}\n"
+"\n"
+"  @decorated('a')\n"
+"  get f() {\n"
+"return result;\n"
+"  }\n"
+"}",
+format("class A {\n"
+   "  private p = () => {}\n"
+   "\n"
+   "  @decorated('a')\n"
+   "  get f() {\n"
+   "return result;\n"
+   "  }\n"
+   "}",
+   getGoogleJSStyleWithColumns(50)));
+}
+
 TEST_F(FormatTestJS, GeneratorFunctions) {
   verifyFormat("function* f() {\n"
"  let x = 1;\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -14,6 +14,7 @@
 #include "ContinuationIndenter.h"
 #include "BreakableToken.h"
 #include "FormatInternal.h"
+#include "FormatToken.h"
 #include "WhitespaceManager.h"
 #include "clang/Basic/OperatorPrecedence.h"
 #include "clang/Basic/SourceManager.h"
@@ -491,6 +492,12 @@
   return true;
   }
 
+  // Break after the closing parenthesis of TypeScript decorators.
+  if (Style.Language == FormatStyle::LK_JavaScript &&
+  Previous.is(tok::r_paren) && Previous.is(TT_JavaAnnotation)) {
+return true;
+  }
+
   // If the return type spans multiple lines, wrap before the function name.
   if (((Current.is(TT_FunctionDeclarationName) &&
 // Don't break before a C# function when no break after return type
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Alexander Potapenko via Phabricator via cfe-commits]

glider created this revision.
glider added a reviewer: melver.
Herald added subscribers: pengfei, jfb, kristof.beyls.
glider requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Looks like non-x86 bots are unhappy with inclusion of 
e.g.:

clang-armv7-vfpv3-2stage - 
https://lab.llvm.org/buildbot/#/builders/182/builds/626
clang-ppc64le-linux - https://lab.llvm.org/buildbot/#/builders/76/builds/3619
llvm-clang-win-x-armv7l - 
https://lab.llvm.org/buildbot/#/builders/60/builds/4514

Move the test to CodeGen/X86 to fix the builds.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108555

Files:
  clang/test/CodeGen/X86/sanitize-thread-disable.c
  clang/test/CodeGen/sanitize-thread-disable.c


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,57 +0,0 @@
-// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
-// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
-
-#include 
-
-// Instrumented function.
-// TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
-// Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
-// __tsan_atomicXXX_load().
-//
-// CHECK-LABEL: @instrumented1
-// TSAN: call void @__tsan_func_entry
-// WITHOUT-NOT: call void @__tsan_func_entry
-// TSAN: call void @__tsan_read4
-// WITHOUT-NOT: call void @__tsan_read4
-// TSAN: call i32 @__tsan_atomic32_load
-// WITHOUT-NOT: call i32 @__tsan_atomic32_load
-// TSAN: call void @__tsan_func_exit
-// WITHOUT-NOT: call void @__tsan_func_exit
-// CHECK: ret i32
-int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
-}
-
-// Function with no_sanitize("thread").
-// TSan only inserts instrumentation necessary to prevent false positives: 
calls are inserted for
-// function entry/exit and atomics, but not plain memory accesses.
-//
-// CHECK-LABEL: @no_false_positives1
-// TSAN: call void @__tsan_func_entry
-// WITHOUT-NOT: call void @__tsan_func_entry
-// TSAN-NOT: call void @__tsan_read4
-// WITHOUT-NOT: call void @__tsan_read4
-// TSAN: call i32 @__tsan_atomic32_load
-// WITHOUT-NOT: call i32 @__tsan_atomic32_load
-// TSAN: call void @__tsan_func_exit
-// WITHOUT-NOT: call void @__tsan_func_exit
-// CHECK: ret i32
-__attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
-  return *a + atomic_load(b);
-}
-
-// Function with disable_sanitizer_instrumentation: no instrumentation at all.
-//
-// CHECK-LABEL: @no_instrumentation1
-// TSAN-NOT: call void @__tsan_func_entry
-// WITHOUT-NOT: call void @__tsan_func_entry
-// TSAN-NOT: call void @__tsan_read4
-// WITHOUT-NOT: call void @__tsan_read4
-// TSAN-NOT: call i32 @__tsan_atomic32_load
-// WITHOUT-NOT: call i32 @__tsan_atomic32_load
-// TSAN-NOT: call void @__tsan_func_exit
-// WITHOUT-NOT: call void @__tsan_func_exit
-// CHECK: ret i32
-__attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
-  return *a + atomic_load(b);
-}


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,57 +0,0 @@
-// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck -check-prefixes CHECK,WITHOUT %s
-// RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s -fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
-
-#include 
-
-// Instrumented function.
-// TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to prologue/epilogue.
-// Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
-// __tsan_atomicXXX_load().
-//
-// CHECK-LABEL: @instrumented1
-// TSAN: call void @__tsan_func_entry
-// WITHOUT-NOT: call void @__tsan_func_entry
-// TSAN: call void @__tsan_read4
-// WITHOUT-NOT: call void @__tsan_read4
-// TSAN: call i32 @__tsan_atomic32_load
-// WITHOUT-NOT: call i32 @__tsan_atomic32_load
-// TSAN: call void @__tsan_func_exit
-// WITHOUT-NOT: call void @__tsan_func_exit
-// CHECK: ret i32
-int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
-}
-
-// Function with no_sanitize("thread").
-// TSan only inserts instrumentation necessary to prevent false positives: calls are inserted for
-// function entry/exit and atomics, but not plain memory accesses.
-//
-// CHECK-LABEL: @no_false_positives1
-// TSAN: call void @__tsan_func_entry
-// WITHOUT-NOT: call void @__tsan_func_entry
-// TSAN-NOT: call void @__tsan_read4
-// WITHOUT-NOT: call void @__tsan_read4
-// TSAN: call i32 @__tsan_atomic32_load
-// WITHOUT-NOT: call i32 @__tsan_atomic32_load
-// TSAN: call void @__tsan_func_exit
-// WITHOUT-NOT: call void @__tsan_func_

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Alexander Potapenko via Phabricator via cfe-commits]

glider added a comment.

Not really sure what's the best solution here, but I think restricting the test 
to x86 should help.
So far only ARM and PPC bots reported failures.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Marco Elver via Phabricator via cfe-commits]

melver added inline comments.



Comment at: clang/test/CodeGen/X86/sanitize-thread-disable.c:22
 int instrumented1(int *a, _Atomic int *b) {
   return *a + atomic_load(b);
 }

I think you do not need to use atomic_load.

You can just deref b, and because it's _Atomic type it *should* just use an 
atomic seq_cst load implicitly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Marco Elver via Phabricator via cfe-commits]

melver added inline comments.



Comment at: clang/test/CodeGen/X86/sanitize-thread-disable.c:22
 int instrumented1(int *a, _Atomic int *b) {
   return *a + atomic_load(b);
 }

melver wrote:
> I think you do not need to use atomic_load.
> 
> You can just deref b, and because it's _Atomic type it *should* just use an 
> atomic seq_cst load implicitly.
Alternatively, there are the `__atomic` builtins. You could just use 
`__atomic_load_n()` instead (it works with either _Atomic or non-_Atomic type).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108380: [openmp][nfc] Refactor GridValues

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp:551
+  llvm::Log2_32(CGF.getTarget().getGridValue().GV_Warp_Size);
+  unsigned LaneIDMask = ~0 >> (32u - LaneIDBits);
   auto &RT = static_cast(CGF.CGM.getOpenMPRuntime());

Bug is here. `~0 >> 27u == -1` (bad) and `~0u >> 27u == 31` (good). Win for 
exact codegen tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108380

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Alexander Potapenko via Phabricator via cfe-commits]

glider updated this revision to Diff 368096.
glider added a comment.

Removed the header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

Files:
  clang/test/CodeGen/sanitize-thread-disable.c


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- clang/test/CodeGen/sanitize-thread-disable.c
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,8 +1,6 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
 
-#include 
-
 // Instrumented function.
 // TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
 // Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
@@ -19,7 +17,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with no_sanitize("thread").
@@ -37,7 +35,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with disable_sanitizer_instrumentation: no instrumentation at all.
@@ -53,5 +51,5 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- clang/test/CodeGen/sanitize-thread-disable.c
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,8 +1,6 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck -check-prefixes CHECK,WITHOUT %s
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s -fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
 
-#include 
-
 // Instrumented function.
 // TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to prologue/epilogue.
 // Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
@@ -19,7 +17,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with no_sanitize("thread").
@@ -37,7 +35,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with disable_sanitizer_instrumentation: no instrumentation at all.
@@ -53,5 +51,5 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108461: [OpenCL] Supports optional generic address space in C++ for OpenCL 2021

[Justas Janickas via Phabricator via cfe-commits]

Topotuna planned changes to this revision.
Topotuna added a comment.

`__opencl_c_generic_address_space` should not have been chosen as the first 
feature to be addressed out of all OpenCL 3.0 optional core features. This is 
because `__opencl_c_device_enqueue` has a dependency on this feature. I will 
review the order in which OpenCL 3.0 optional features should be introduced to 
C++ for OpenCL 2021 and return to this revision when all dependencies are 
resolved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108461

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Alexander Potapenko via Phabricator via cfe-commits]

glider added inline comments.



Comment at: clang/test/CodeGen/X86/sanitize-thread-disable.c:22
 int instrumented1(int *a, _Atomic int *b) {
   return *a + atomic_load(b);
 }

melver wrote:
> melver wrote:
> > I think you do not need to use atomic_load.
> > 
> > You can just deref b, and because it's _Atomic type it *should* just use an 
> > atomic seq_cst load implicitly.
> Alternatively, there are the `__atomic` builtins. You could just use 
> `__atomic_load_n()` instead (it works with either _Atomic or non-_Atomic 
> type).
You are right, turns out I didn't need the header at all. Removed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Marco Elver via Phabricator via cfe-commits]

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

LGTM, thanks!

Patch title ("...an X86-only test..") also needs adjustment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108555: [tsan] Make sanitize-thread-disable.c an X86-only test

[Alexander Potapenko via Phabricator via cfe-commits]

glider added a comment.

In D108555#2960034 , @melver wrote:

> LGTM, thanks!
>
> Patch title ("...an X86-only test..") also needs adjustment.

It's strange that Phab doesn't automatically update the title when I update the 
commit message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108555: [tsan] Do not include from sanitize-thread-disable.c

[Marco Elver via Phabricator via cfe-commits]

melver added a comment.

In D108555#2960037 , @glider wrote:

> In D108555#2960034 , @melver wrote:
>
>> LGTM, thanks!
>>
>> Patch title ("...an X86-only test..") also needs adjustment.
>
> It's strange that Phab doesn't automatically update the title when I update 
> the commit message.

Hmm, yeah I remember this was broken before. I guess as long as the committed 
version is right it's fine. I think it's also possible to edit on web interface 
(not so nice..) and use arc amend or something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

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

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

[Andy Wingo via Phabricator via cfe-commits]

wingo updated this revision to Diff 368098.
wingo added a comment.

Rebase to no longer require Address default constructor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108464

Files:
  clang/lib/CodeGen/CGBuilder.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCleanup.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGException.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGGPUBuiltin.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h

Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -576,7 +576,7 @@
 
   /// A mapping from NRVO variables to the flags used to indicate
   /// when the NRVO has been applied to this variable.
-  llvm::DenseMap NRVOFlags;
+  llvm::DenseMap NRVOFlags;
 
   EHScopeStack EHStack;
   llvm::SmallVector LifetimeExtendedCleanupStack;
@@ -623,11 +623,11 @@
 
   /// The exception slot.  All landing pads write the current exception pointer
   /// into this alloca.
-  llvm::Value *ExceptionSlot = nullptr;
+  Address ExceptionSlot = Address::invalid();
 
   /// The selector slot.  Under the MandatoryCleanup model, all landing pads
   /// write the current selector value into this alloca.
-  llvm::AllocaInst *EHSelectorSlot = nullptr;
+  Address EHSelectorSlot = Address::invalid();
 
   /// A stack of exception code slots. Entering an __except block pushes a slot
   /// on the stack and leaving pops one. The __exception_code() intrinsic loads
@@ -704,11 +704,11 @@
 
 /// An i1 variable indicating whether or not the @finally is
 /// running for an exception.
-llvm::AllocaInst *ForEHVar;
+Address ForEHVar = Address::invalid();
 
 /// An i8* variable into which the exception pointer to rethrow
 /// has been saved.
-llvm::AllocaInst *SavedExnVar;
+Address SavedExnVar = Address::invalid();
 
   public:
 void enter(CodeGenFunction &CGF, const Stmt *Finally,
@@ -2474,54 +2474,58 @@
 TBAAAccessInfo *TBAAInfo = nullptr);
   LValue EmitLoadOfPointerLValue(Address Ptr, const PointerType *PtrTy);
 
-  /// CreateTempAlloca - This creates an alloca and inserts it into the entry
-  /// block if \p ArraySize is nullptr, otherwise inserts it at the current
-  /// insertion point of the builder. The caller is responsible for setting an
-  /// appropriate alignment on
-  /// the alloca.
+  /// CreateTempAllocaInAS - Create an alloca in \p AddressSpace with alignment
+  /// \p Align.
   ///
   /// \p ArraySize is the number of array elements to be allocated if it
-  ///is not nullptr.
+  /// is not nullptr.
+  ///
+  /// The alloca will be inserted into the entry block if \p ArraySize is
+  /// nullptr.  Otherwise it is inserted at the current insertion point of the
+  /// builder.
+  Address CreateTempAllocaInAS(llvm::Type *Ty, CharUnits Align,
+   LangAS AddrSpace, const Twine &Name = "tmp",
+   llvm::Value *ArraySize = nullptr);
+
+  /// CreateTempAlloca - Create an alloca with CreateTempAllocaInAS, then cast
+  /// the result to LangAS::Default if necessary.
   ///
   /// LangAS::Default is the address space of pointers to local variables and
-  /// temporaries, as exposed in the source language. In certain
-  /// configurations, this is not the same as the alloca address space, and a
-  /// cast is needed to lift the pointer from the alloca AS into
-  /// LangAS::Default. This can happen when the target uses a restricted
-  /// address space for the stack but the source language requires
-  /// LangAS::Default to be a generic address space. The latter condition is
-  /// common for most programming languages; OpenCL is an exception in that
-  /// LangAS::Default is the private address space, which naturally maps
-  /// to the stack.
+  /// temporaries, as exposed in the source language. In certain configurations,
+  /// this is not the same as the alloca address space, and a cast is needed to
+  /// lift the pointer from the alloca AS into LangAS::Default. This can happen
+  /// when the target uses a restricted address space for the stack but the
+  /// source language requires LangAS::Default to be a generic address
+  /// space. The latter condition is common for most programming languages;
+  /// OpenCL is an exception in that LangAS::Default is the private address
+  /// space, which naturally maps to the stack.
   ///
   /// Because the address of a temporary is often exposed to the program in
   /// various ways, this function will perform the cast. The original alloca
   //

[clang] cdb3916 - [tsan] Do not include from sanitize-thread-disable.c

[Alexander Potapenko via cfe-commits]

Author: Alexander Potapenko
Date: 2021-08-23T16:21:43+02:00
New Revision: cdb391698bb29fcbb9156604793121fdd73d3a89

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

LOG: [tsan] Do not include  from sanitize-thread-disable.c

Looks like non-x86 bots are unhappy with inclusion of 
e.g.:

clang-armv7-vfpv3-2stage - 
https://lab.llvm.org/buildbot/#/builders/182/builds/626
clang-ppc64le-linux - https://lab.llvm.org/buildbot/#/builders/76/builds/3619
llvm-clang-win-x-armv7l - 
https://lab.llvm.org/buildbot/#/builders/60/builds/4514

It seems to be unnecessary, just remove it and replace atomic_load()
calls with dereferences of _Atomic*.

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

Added: 


Modified: 
clang/test/CodeGen/sanitize-thread-disable.c

Removed: 




diff  --git a/clang/test/CodeGen/sanitize-thread-disable.c 
b/clang/test/CodeGen/sanitize-thread-disable.c
index d3ec1425e782..48a345928f6d 100644
--- a/clang/test/CodeGen/sanitize-thread-disable.c
+++ b/clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,8 +1,6 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
 
-#include 
-
 // Instrumented function.
 // TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
 // Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
@@ -19,7 +17,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with no_sanitize("thread").
@@ -37,7 +35,7 @@ int instrumented1(int *a, _Atomic int *b) {
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with disable_sanitizer_instrumentation: no instrumentation at all.
@@ -53,5 +51,5 @@ __attribute__((no_sanitize("thread"))) int 
no_false_positives1(int *a, _Atomic i
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }



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

[PATCH] D108555: [tsan] Do not include from sanitize-thread-disable.c

[Alexander Potapenko via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcdb391698bb2: [tsan] Do not include  from 
sanitize-thread-disable.c (authored by glider).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108555

Files:
  clang/test/CodeGen/sanitize-thread-disable.c


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- clang/test/CodeGen/sanitize-thread-disable.c
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,8 +1,6 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
-check-prefixes CHECK,WITHOUT %s
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s 
-fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
 
-#include 
-
 // Instrumented function.
 // TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to 
prologue/epilogue.
 // Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
@@ -19,7 +17,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with no_sanitize("thread").
@@ -37,7 +35,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic 
int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with disable_sanitizer_instrumentation: no instrumentation at all.
@@ -53,5 +51,5 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int 
*a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }


Index: clang/test/CodeGen/sanitize-thread-disable.c
===
--- clang/test/CodeGen/sanitize-thread-disable.c
+++ clang/test/CodeGen/sanitize-thread-disable.c
@@ -1,8 +1,6 @@
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck -check-prefixes CHECK,WITHOUT %s
 // RUN: %clang -target x86_64-linux-gnu -S -emit-llvm -o - %s -fsanitize=thread | FileCheck -check-prefixes CHECK,TSAN %s
 
-#include 
-
 // Instrumented function.
 // TSan inserts calls to __tsan_func_entry() and __tsan_func_exit() to prologue/epilogue.
 // Non-atomic loads are instrumented with __tsan_readXXX(), atomic loads - with
@@ -19,7 +17,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 int instrumented1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with no_sanitize("thread").
@@ -37,7 +35,7 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((no_sanitize("thread"))) int no_false_positives1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
 
 // Function with disable_sanitizer_instrumentation: no instrumentation at all.
@@ -53,5 +51,5 @@
 // WITHOUT-NOT: call void @__tsan_func_exit
 // CHECK: ret i32
 __attribute__((disable_sanitizer_instrumentation)) int no_instrumentation1(int *a, _Atomic int *b) {
-  return *a + atomic_load(b);
+  return *a + *b;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Kevin P. Neal via Phabricator via cfe-commits]

kpn added a comment.

In D104854#2959680 , @thopre wrote:

> In D104854#2957735 , @kpn wrote:
>
>> In D104854#2957490 , @lebedev.ri 
>> wrote:
>>
>>> In D104854#2957471 , @sepavloff 
>>> wrote:
>>>
 In D104854#2957423 , @spatel 
 wrote:

> Is it intentional that we are not canonicalizing the intrinsic call back 
> to `fcmp uno` in the default FP environment?

 It is lowered to unordered comparison by default. Changing `llvm.isnan` to 
  `fcmp uno` somewhere in IR would make it possible to optimize out the 
 latter if fast-math mode is on. Preserving semantics of `isnan` when 
 fast-math is in effect was one of the goals of this change.
>>>
>>> Eeek. Was there an RFC about this?
>>> This does not sound good to me at all,
>>> much like "let's not apply fast-math flags to x86 vector intrinsics".
>>
>> We can switch into and out of the default FP environment inside a single 
>> function.
>
> Really? The constrained intrinsic documentation claims the reverse 
> (https://llvm.org/docs/LangRef.html#constrainedfp):
>
>> If any FP operation in a function is constrained then they all must be 
>> constrained. This is required for correct LLVM IR. Optimizations that move 
>> code around can create miscompiles if mixing of constrained and normal 
>> operations is done. The correct way to mix constrained and less constrained 
>> operations is to use the rounding mode and exception handling metadata to 
>> mark constrained intrinsics as having LLVM’s default behavior.

Use of constrained intrinsics does not mean that we are automatically in an 
alternate FP environment.

When constrained intrinsics are used and the metadata says the rounding mode is 
"tonearest" with exceptions set to "ignore" then that's the default FP 
environment. If, for example, #pragma STDC FENV_ACCESS is used in only a part 
of a function then the constrained intrinsics will be used in the entire 
function but the metadata will specify different exception or rounding behavior 
in the part covered by the FENV_ACCESS.

That the constrained intrinsics can state that they are in the default FP 
environment is what makes it safe for EarlyCSE to treat them the same as a 
normal FP instruction (which is assumed to be in the default FP environment). 
For example.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D108458: [clang][CodeGen] Add default constructor for Address. NFC.

[Andy Wingo via Phabricator via cfe-commits]

wingo abandoned this revision.
wingo added a comment.

In D108458#2957789 , @rjmccall wrote:

> You can still use a type without a default constructor in a `DenseMap`; you 
> just have to use `insert` instead of `dict[key] = ...`.

Aaaah, thanks for this note.  Closing this PR, then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108458

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

[PATCH] D108380: [openmp][nfc] Refactor GridValues

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield updated this revision to Diff 368100.
JonChesterfield added a comment.

- require unsigned shift


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108380

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h

Index: llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
@@ -62,19 +62,13 @@
   const unsigned GV_Slot_Size;
   /// The default value of maximum number of threads in a worker warp.
   const unsigned GV_Warp_Size;
-  /// Alternate warp size for some AMDGCN architectures. Same as GV_Warp_Size
-  /// for NVPTX.
-  const unsigned GV_Warp_Size_32;
-  /// The number of bits required to represent the max number of threads in warp
-  const unsigned GV_Warp_Size_Log2;
-  /// GV_Warp_Size * GV_Slot_Size,
-  const unsigned GV_Warp_Slot_Size;
+
+  constexpr unsigned warpSlotSize() const {
+return GV_Warp_Size * GV_Slot_Size;
+  }
+
   /// the maximum number of teams.
   const unsigned GV_Max_Teams;
-  /// Global Memory Alignment
-  const unsigned GV_Mem_Align;
-  /// (~0u >> (GV_Warp_Size - GV_Warp_Size_Log2))
-  const unsigned GV_Warp_Size_Log2_Mask;
   // An alternative to the heavy data sharing infrastructure that uses global
   // memory is one that uses device __shared__ memory.  The amount of such space
   // (in bytes) reserved by the OpenMP runtime is noted here.
@@ -83,47 +77,32 @@
   const unsigned GV_Max_WG_Size;
   // The default maximum team size for a working group
   const unsigned GV_Default_WG_Size;
-  // This is GV_Max_WG_Size / GV_WarpSize. 32 for NVPTX and 16 for AMDGCN.
-  const unsigned GV_Max_Warp_Number;
-  /// The slot size that should be reserved for a working warp.
-  /// (~0u >> (GV_Warp_Size - GV_Warp_Size_Log2))
-  const unsigned GV_Warp_Size_Log2_MaskL;
+
+  constexpr unsigned maxWarpNumber() const {
+return GV_Max_WG_Size / GV_Warp_Size;
+  }
 };
 
 /// For AMDGPU GPUs
 static constexpr GV AMDGPUGridValues = {
-448,   // GV_Threads
-256,   // GV_Slot_Size
-64,// GV_Warp_Size
-32,// GV_Warp_Size_32
-6, // GV_Warp_Size_Log2
-64 * 256,  // GV_Warp_Slot_Size
-128,   // GV_Max_Teams
-256,   // GV_Mem_Align
-63,// GV_Warp_Size_Log2_Mask
-896,   // GV_SimpleBufferSize
-1024,  // GV_Max_WG_Size,
-256,   // GV_Defaut_WG_Size
-1024 / 64, // GV_Max_WG_Size / GV_WarpSize
-63 // GV_Warp_Size_Log2_MaskL
+448,  // GV_Threads
+256,  // GV_Slot_Size
+64,   // GV_Warp_Size
+128,  // GV_Max_Teams
+896,  // GV_SimpleBufferSize
+1024, // GV_Max_WG_Size,
+256,  // GV_Default_WG_Size
 };
 
 /// For Nvidia GPUs
 static constexpr GV NVPTXGridValues = {
-992,   // GV_Threads
-256,   // GV_Slot_Size
-32,// GV_Warp_Size
-32,// GV_Warp_Size_32
-5, // GV_Warp_Size_Log2
-32 * 256,  // GV_Warp_Slot_Size
-1024,  // GV_Max_Teams
-256,   // GV_Mem_Align
-(~0u >> (32 - 5)), // GV_Warp_Size_Log2_Mask
-896,   // GV_SimpleBufferSize
-1024,  // GV_Max_WG_Size
-128,   // GV_Defaut_WG_Size
-1024 / 32, // GV_Max_WG_Size / GV_WarpSize
-31 // GV_Warp_Size_Log2_MaskL
+992,  // GV_Threads
+256,  // GV_Slot_Size
+32,   // GV_Warp_Size
+1024, // GV_Max_Teams
+896,  // GV_SimpleBufferSize
+1024, // GV_Max_WG_Size
+128,  // GV_Default_WG_Size
 };
 
 } // namespace omp
Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -22,6 +22,7 @@
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/Frontend/OpenMP/OMPGridValues.h"
 #include "llvm/IR/IntrinsicsNVPTX.h"
+#include "llvm/Support/MathExtras.h"
 
 using namespace clang;
 using namespace CodeGen;
@@ -106,8 +107,7 @@
 /// is the same for all known NVPTX architectures.
 enum MachineConfiguration : unsigned {
   /// See "llvm/Frontend/OpenMP/OMPGridValues.h" for various related target
-  /// specific Grid Values like GV_Warp_Size, GV_Warp_Size_Log2,
-  /// and GV_Warp_Size_Log2_Mask.
+  /// specific Grid Values like GV_Warp_Size, GV_Slot_Size
 
   /// Global memory alignment for performance.
   GlobalMemoryAlignment = 128,
@@ -535,7 +535,8 @@
 /// on the NVPTX device, to generate more efficient code.
 static llvm::Value *getNVPTXWarpID(C

[PATCH] D108459: [clang][CodeGen] Rely on implicitly invalid Address. NFC.

[Andy Wingo via Phabricator via cfe-commits]

wingo abandoned this revision.
wingo added a comment.

Closing PR as it turns out that I don't need the Address() change for my work; 
no need to churn here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108459

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

[PATCH] D108556: [clangd] Don't highlight ObjC `id` and `instancetype`

[David Goldman via Phabricator via cfe-commits]

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

Even though they're implemented via typedefs, we typically
want to treat them like keywords (default editor behavior).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108556

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -661,13 +661,15 @@
 @interface $Class_decl[[Foo]]
 @end
 @interface $Class_decl[[Bar]] : $Class[[Foo]]
--($Class[[id]]) $Method_decl[[x]]:(int)$Parameter_decl[[a]] 
$Method_decl[[y]]:(int)$Parameter_decl[[b]];
+-(id) $Method_decl[[x]]:(int)$Parameter_decl[[a]] 
$Method_decl[[y]]:(int)$Parameter_decl[[b]];
++(instancetype)$StaticMethod_decl_static[[sharedInstance]];
 +(void) $StaticMethod_decl_static[[explode]];
 @end
 @implementation $Class_decl[[Bar]]
--($Class[[id]]) $Method_decl[[x]]:(int)$Parameter_decl[[a]] 
$Method_decl[[y]]:(int)$Parameter_decl[[b]] {
+-(id) $Method_decl[[x]]:(int)$Parameter_decl[[a]] 
$Method_decl[[y]]:(int)$Parameter_decl[[b]] {
   return self;
 }
++(instancetype)$StaticMethod_decl_static[[sharedInstance]] { return 0; 
}
 +(void) $StaticMethod_decl_static[[explode]] {}
 @end
 
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -78,6 +78,12 @@
   D = Templated;
   }
   if (auto *TD = dyn_cast(D)) {
+// Even though ObjC `id` and `instancetype` are implemented via typedefs, 
we
+// don't want to treat them like typedefs - instead let the editor treat
+// them like keywords.
+if (TD == D->getASTContext().getObjCInstanceTypeDecl() ||
+TD == D->getASTContext().getObjCIdDecl())
+  return llvm::None;
 // We try to highlight typedefs as their underlying type.
 if (auto K =
 kindForType(TD->getUnderlyingType().getTypePtrOrNull(), Resolver))


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -661,13 +661,15 @@
 @interface $Class_decl[[Foo]]
 @end
 @interface $Class_decl[[Bar]] : $Class[[Foo]]
--($Class[[id]]) $Method_decl[[x]]:(int)$Parameter_decl[[a]] $Method_decl[[y]]:(int)$Parameter_decl[[b]];
+-(id) $Method_decl[[x]]:(int)$Parameter_decl[[a]] $Method_decl[[y]]:(int)$Parameter_decl[[b]];
++(instancetype)$StaticMethod_decl_static[[sharedInstance]];
 +(void) $StaticMethod_decl_static[[explode]];
 @end
 @implementation $Class_decl[[Bar]]
--($Class[[id]]) $Method_decl[[x]]:(int)$Parameter_decl[[a]] $Method_decl[[y]]:(int)$Parameter_decl[[b]] {
+-(id) $Method_decl[[x]]:(int)$Parameter_decl[[a]] $Method_decl[[y]]:(int)$Parameter_decl[[b]] {
   return self;
 }
++(instancetype)$StaticMethod_decl_static[[sharedInstance]] { return 0; }
 +(void) $StaticMethod_decl_static[[explode]] {}
 @end
 
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -78,6 +78,12 @@
   D = Templated;
   }
   if (auto *TD = dyn_cast(D)) {
+// Even though ObjC `id` and `instancetype` are implemented via typedefs, we
+// don't want to treat them like typedefs - instead let the editor treat
+// them like keywords.
+if (TD == D->getASTContext().getObjCInstanceTypeDecl() ||
+TD == D->getASTContext().getObjCIdDecl())
+  return llvm::None;
 // We try to highlight typedefs as their underlying type.
 if (auto K =
 kindForType(TD->getUnderlyingType().getTypePtrOrNull(), Resolver))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104854: Introduce intrinsic llvm.isnan

[Thomas Preud'homme via Phabricator via cfe-commits]

thopre added a comment.

Ah fair enough. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104854

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

[PATCH] D107647: [PowerPC] MMA - Add __builtin_vsx_build_pair and __builtin_mma_build_acc builtins

[Ahsan Saghir via Phabricator via cfe-commits]

saghir updated this revision to Diff 368109.
saghir added a comment.

Added some more tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107647

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/Sema/ppc-pair-mma-types.c
  clang/test/SemaCXX/ppc-pair-mma-types.cpp
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
  llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll
@@ -51,6 +51,42 @@
   ret void
 }
 
+; build_pair
+declare <256 x i1> @llvm.ppc.vsx.build.pair(<16 x i8>, <16 x i8>)
+define void @build_pair(<256 x i1>* %ptr, <16 x i8> %vc) {
+; CHECK-LABEL: build_pair:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v3, v2
+; CHECK-NEXT:stxv v2, 16(r3)
+; CHECK-NEXT:stxv v3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-NOMMA-LABEL: build_pair:
+; CHECK-NOMMA:   # %bb.0: # %entry
+; CHECK-NOMMA-NEXT:vmr v3, v2
+; CHECK-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-NOMMA-NEXT:stxv v3, 0(r3)
+; CHECK-NOMMA-NEXT:blr
+;
+; CHECK-BE-LABEL: build_pair:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v3, v2
+; CHECK-BE-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NEXT:blr
+;
+; CHECK-BE-NOMMA-LABEL: build_pair:
+; CHECK-BE-NOMMA:   # %bb.0: # %entry
+; CHECK-BE-NOMMA-NEXT:vmr v3, v2
+; CHECK-BE-NOMMA-NEXT:stxv v2, 16(r3)
+; CHECK-BE-NOMMA-NEXT:stxv v2, 0(r3)
+; CHECK-BE-NOMMA-NEXT:blr
+entry:
+  %0 = tail call <256 x i1> @llvm.ppc.vsx.build.pair(<16 x i8> %vc, <16 x i8> %vc)
+  store <256 x i1> %0, <256 x i1>* %ptr, align 32
+  ret void
+}
+
 ; disassemble_pair
 declare { <16 x i8>, <16 x i8> } @llvm.ppc.vsx.disassemble.pair(<256 x i1>)
 define void @disass_pair(<256 x i1>* %ptr1, <16 x i8>* %ptr2, <16 x i8>* %ptr3) {
Index: llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
@@ -40,6 +40,101 @@
   ret void
 }
 
+; build_acc
+declare <512 x i1> @llvm.ppc.mma.build.acc(<16 x i8>, <16 x i8>, <16 x i8>, <16 x i8>)
+define void @build_acc1(<512 x i1>* %ptr, <16 x i8> %vc) {
+; CHECK-LABEL: build_acc1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vmr v3, v2
+; CHECK-NEXT:xxlor vs0, v2, v2
+; CHECK-NEXT:xxlor vs1, v3, v3
+; CHECK-NEXT:xxlor vs2, v2, v2
+; CHECK-NEXT:xxlor vs3, v3, v3
+; CHECK-NEXT:stxv vs0, 48(r3)
+; CHECK-NEXT:stxv vs1, 32(r3)
+; CHECK-NEXT:stxv vs2, 16(r3)
+; CHECK-NEXT:stxv vs3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: build_acc1:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:vmr v3, v2
+; CHECK-BE-NEXT:xxlor vs0, v2, v2
+; CHECK-BE-NEXT:xxlor vs1, v3, v3
+; CHECK-BE-NEXT:xxlor vs2, v2, v2
+; CHECK-BE-NEXT:xxlor vs3, v3, v3
+; CHECK-BE-NEXT:stxv vs1, 16(r3)
+; CHECK-BE-NEXT:stxv vs0, 0(r3)
+; CHECK-BE-NEXT:stxv vs3, 48(r3)
+; CHECK-BE-NEXT:stxv vs2, 32(r3)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = tail call <512 x i1> @llvm.ppc.mma.build.acc(<16 x i8> %vc, <16 x i8> %vc, <16 x i8> %vc, <16 x i8> %vc)
+  store <512 x i1> %0, <512 x i1>* %ptr, align 64
+  ret void
+}
+
+; build_acc
+define void @build_acc2(<512 x i1>* %ptr, <16 x i8> %in1, <16 x i8> %in2, <16 x i8> %in3, <16 x i8> %in4) {
+; CHECK-LABEL: build_acc2:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xxlor vs0, v5, v5
+; CHECK-NEXT:xxlor vs1, v4, v4
+; CHECK-NEXT:# kill: def $vsrp0 killed $vsrp0 def $uacc0
+; CHECK-NEXT:vmr v4, v3
+; CHECK-NEXT:vmr v5, v2
+; CHECK-NEXT:xxlor vs2, v4, v4
+; CHECK-NEXT:xxlor vs3, v5, v5
+; CHECK-NEXT:stxv vs0, 48(r3)
+; CHECK-NEXT:stxv vs1, 32(r3)
+; CHECK-NEXT:stxv vs2, 16(r3)
+; CHECK-NEXT:stxv vs3, 0(r3)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: build_acc2:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xxlor vs0, v5, v5
+; CHECK-BE-NEXT:xxlor vs1, v4, v4
+; CHECK-BE-NEXT:# kill: def $vsrp0 killed $vsrp0 def $uacc0
+; CHECK-BE-NEXT:vmr v4, v3
+; CHECK-BE-NEXT:vmr v5, v2
+; CHECK-BE-NEXT:xxlor vs2, v4, v4
+; CHECK-BE-NEXT:xxlor vs3, v5, v5
+; CHECK-BE-NEXT:stxv vs1, 16(r3)
+; CHECK-BE-NEXT:stxv vs0, 0(r3)
+; CHECK-BE-NEXT:stxv vs3, 48(r3)
+; CHECK-BE-NEXT:stxv vs2, 32(r3)
+; CHECK-BE-NEXT:blr
+entry:
+%0 = tail call <512 x i1> @llvm.ppc.mma.build.acc(<16 x i8> %in4, <16 x i8> %in3, <16 x i8> %in2, <16 x i8> %in1)
+store <512 x i1> %0, <512 x i1>* %ptr, align 64
+ret void
+}
+

[clang] c2574e6 - [openmp][nfc] Refactor GridValues

[Jon Chesterfield via cfe-commits]

Author: Jon Chesterfield
Date: 2021-08-23T16:19:11+01:00
New Revision: c2574e63ff71c1d3caea48cb6200c2422bd8f33d

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

LOG: [openmp][nfc] Refactor GridValues

Remove redundant fields and replace pointer with virtual function

Of fourteen fields, three are dead and four can be computed from the
remainder. This leaves a couple of currently dead fields in place as
they are expected to be used from the deviceRTL shortly. Two of the
fields that can be computed are only used from codegen and require a
log2() implementation so are inlined into codegen instead.

This change leaves the new methods in the same location in the struct
as the previous fields for convenience at review.

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/Basic/Targets/AMDGPU.cpp
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.cpp
clang/lib/Basic/Targets/NVPTX.h
clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index ab855948b447c..fe6f67d40b532 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -210,9 +210,6 @@ class TargetInfo : public virtual TransferrableTargetInfo,
   unsigned char RegParmMax, SSERegParmMax;
   TargetCXXABI TheCXXABI;
   const LangASMap *AddrSpaceMap;
-  const llvm::omp::GV *GridValues =
-  nullptr; // target-specific GPU grid values that must be
-   // consistent between host RTL (plugin), device RTL, and clang.
 
   mutable StringRef PlatformName;
   mutable VersionTuple PlatformMinVersion;
@@ -1410,10 +1407,10 @@ class TargetInfo : public virtual 
TransferrableTargetInfo,
 return LangAS::Default;
   }
 
-  /// Return a target-specific GPU grid values
-  const llvm::omp::GV &getGridValue() const {
-assert(GridValues != nullptr && "GridValues not initialized");
-return *GridValues;
+  // access target-specific GPU grid values that must be consistent between
+  // host RTL (plugin), deviceRTL and clang.
+  virtual const llvm::omp::GV &getGridValue() const {
+llvm_unreachable("getGridValue not implemented on this target");
   }
 
   /// Retrieve the name of the platform as it is used in the

diff  --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index cebb19e7ccab3..ba7ffa34c73e3 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -17,7 +17,6 @@
 #include "clang/Basic/MacroBuilder.h"
 #include "clang/Basic/TargetBuiltins.h"
 #include "llvm/ADT/StringSwitch.h"
-#include "llvm/Frontend/OpenMP/OMPGridValues.h"
 
 using namespace clang;
 using namespace clang::targets;
@@ -335,7 +334,6 @@ AMDGPUTargetInfo::AMDGPUTargetInfo(const llvm::Triple 
&Triple,
   llvm::AMDGPU::getArchAttrR600(GPUKind)) {
   resetDataLayout(isAMDGCN(getTriple()) ? DataLayoutStringAMDGCN
 : DataLayoutStringR600);
-  GridValues = &llvm::omp::AMDGPUGridValues;
 
   setAddressSpaceMap(Triple.getOS() == llvm::Triple::Mesa3D ||
  !isAMDGCN(Triple));

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 77c2c5fd50145..e791a83f38ae7 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -370,6 +370,10 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
 return getLangASFromTargetAS(Constant);
   }
 
+  const llvm::omp::GV &getGridValue() const override {
+return llvm::omp::AMDGPUGridValues;
+  }
+
   /// \returns Target specific vtbl ptr address space.
   unsigned getVtblPtrAddressSpace() const override {
 return static_cast(Constant);

diff  --git a/clang/lib/Basic/Targets/NVPTX.cpp 
b/clang/lib/Basic/Targets/NVPTX.cpp
index d1a34e4a81c56..c245753c93f41 100644
--- a/clang/lib/Basic/Targets/NVPTX.cpp
+++ b/clang/lib/Basic/Targets/NVPTX.cpp
@@ -16,7 +16,6 @@
 #include "clang/Basic/MacroBuilder.h"
 #include "clang/Basic/TargetBuiltins.h"
 #include "llvm/ADT/StringSwitch.h"
-#include "llvm/Frontend/OpenMP/OMPGridValues.h"
 
 using namespace clang;
 using namespace clang::targets;
@@ -65,7 +64,6 @@ NVPTXTargetInfo::NVPTXTargetInfo(const llvm::Triple &Triple,
   TLSSupported = false;
   VLASupported = false;
   AddrSpaceMap = &NVPTXAddrSpaceMap;
-  GridValues = &llvm::omp::NVPTXGridValues;
   UseAddrSpaceMapMangling = true;
 
   // Define available target features

diff  --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index c7db3cdaaf10a..ef751b8e1a8

[PATCH] D108380: [openmp][nfc] Refactor GridValues

[Jon Chesterfield via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc2574e63ff71: [openmp][nfc] Refactor GridValues (authored by 
JonChesterfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108380

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h

Index: llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPGridValues.h
@@ -62,19 +62,13 @@
   const unsigned GV_Slot_Size;
   /// The default value of maximum number of threads in a worker warp.
   const unsigned GV_Warp_Size;
-  /// Alternate warp size for some AMDGCN architectures. Same as GV_Warp_Size
-  /// for NVPTX.
-  const unsigned GV_Warp_Size_32;
-  /// The number of bits required to represent the max number of threads in warp
-  const unsigned GV_Warp_Size_Log2;
-  /// GV_Warp_Size * GV_Slot_Size,
-  const unsigned GV_Warp_Slot_Size;
+
+  constexpr unsigned warpSlotSize() const {
+return GV_Warp_Size * GV_Slot_Size;
+  }
+
   /// the maximum number of teams.
   const unsigned GV_Max_Teams;
-  /// Global Memory Alignment
-  const unsigned GV_Mem_Align;
-  /// (~0u >> (GV_Warp_Size - GV_Warp_Size_Log2))
-  const unsigned GV_Warp_Size_Log2_Mask;
   // An alternative to the heavy data sharing infrastructure that uses global
   // memory is one that uses device __shared__ memory.  The amount of such space
   // (in bytes) reserved by the OpenMP runtime is noted here.
@@ -83,47 +77,32 @@
   const unsigned GV_Max_WG_Size;
   // The default maximum team size for a working group
   const unsigned GV_Default_WG_Size;
-  // This is GV_Max_WG_Size / GV_WarpSize. 32 for NVPTX and 16 for AMDGCN.
-  const unsigned GV_Max_Warp_Number;
-  /// The slot size that should be reserved for a working warp.
-  /// (~0u >> (GV_Warp_Size - GV_Warp_Size_Log2))
-  const unsigned GV_Warp_Size_Log2_MaskL;
+
+  constexpr unsigned maxWarpNumber() const {
+return GV_Max_WG_Size / GV_Warp_Size;
+  }
 };
 
 /// For AMDGPU GPUs
 static constexpr GV AMDGPUGridValues = {
-448,   // GV_Threads
-256,   // GV_Slot_Size
-64,// GV_Warp_Size
-32,// GV_Warp_Size_32
-6, // GV_Warp_Size_Log2
-64 * 256,  // GV_Warp_Slot_Size
-128,   // GV_Max_Teams
-256,   // GV_Mem_Align
-63,// GV_Warp_Size_Log2_Mask
-896,   // GV_SimpleBufferSize
-1024,  // GV_Max_WG_Size,
-256,   // GV_Defaut_WG_Size
-1024 / 64, // GV_Max_WG_Size / GV_WarpSize
-63 // GV_Warp_Size_Log2_MaskL
+448,  // GV_Threads
+256,  // GV_Slot_Size
+64,   // GV_Warp_Size
+128,  // GV_Max_Teams
+896,  // GV_SimpleBufferSize
+1024, // GV_Max_WG_Size,
+256,  // GV_Default_WG_Size
 };
 
 /// For Nvidia GPUs
 static constexpr GV NVPTXGridValues = {
-992,   // GV_Threads
-256,   // GV_Slot_Size
-32,// GV_Warp_Size
-32,// GV_Warp_Size_32
-5, // GV_Warp_Size_Log2
-32 * 256,  // GV_Warp_Slot_Size
-1024,  // GV_Max_Teams
-256,   // GV_Mem_Align
-(~0u >> (32 - 5)), // GV_Warp_Size_Log2_Mask
-896,   // GV_SimpleBufferSize
-1024,  // GV_Max_WG_Size
-128,   // GV_Defaut_WG_Size
-1024 / 32, // GV_Max_WG_Size / GV_WarpSize
-31 // GV_Warp_Size_Log2_MaskL
+992,  // GV_Threads
+256,  // GV_Slot_Size
+32,   // GV_Warp_Size
+1024, // GV_Max_Teams
+896,  // GV_SimpleBufferSize
+1024, // GV_Max_WG_Size
+128,  // GV_Default_WG_Size
 };
 
 } // namespace omp
Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -22,6 +22,7 @@
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/Frontend/OpenMP/OMPGridValues.h"
 #include "llvm/IR/IntrinsicsNVPTX.h"
+#include "llvm/Support/MathExtras.h"
 
 using namespace clang;
 using namespace CodeGen;
@@ -106,8 +107,7 @@
 /// is the same for all known NVPTX architectures.
 enum MachineConfiguration : unsigned {
   /// See "llvm/Frontend/OpenMP/OMPGridValues.h" for various related target
-  /// specific Grid Values like GV_Warp_Size, GV_Warp_Size_Log2,
-  /// and GV_Warp_Size_Log2_Mask.
+  /// specific Grid Values like GV_Warp_Size, GV_Slot_Size
 
   /// Global memory alignment for performance.
   GlobalMemoryAlignment = 128,
@@ -535,7 +535,8 @@
 /// on the NVPTX device, to generate

[PATCH] D108552: [OpenMP][AMDGCN] Enable complex functions

[Johannes Doerfert via Phabricator via cfe-commits]

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

LG




Comment at: clang/lib/Headers/openmp_wrappers/complex:20
 
+#ifdef __NVPTX__
 #define __OPENMP_NVPTX__

JonChesterfield wrote:
> I don't think this should be necessary - the declare variant stuff works for 
> nvptx afaik
You need it because the file has include guards.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108552

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

[PATCH] D108560: [clang-tidy] Add support for NOLINTBEGIN ... NOLINTEND comments to suppress clang-tidy warnings over multiple lines

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz created this revision.
salman-javed-nz added reviewers: alexfh, aaron.ballman, njames93.
salman-javed-nz added a project: clang-tools-extra.
Herald added subscribers: arphaman, xazax.hun.
salman-javed-nz requested review of this revision.

Add support for `NOLINTBEGIN` ... `NOLINTEND` comments to suppress clang-tidy 
warnings over multiple lines. All lines between the "begin" and "end" markers 
are suppressed.
Example:

  // NOLINTBEGIN(some-check)
  // 
  // 
  // 
  // NOLINTEND(some-check)

Follows similar syntax as the `NOLINT` and `NOLINTNEXTLINE` comments that are 
already implemented, i.e. allows multiple checks to be provided in parentheses; 
suppresses all checks if the parentheses are omitted, etc.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108560

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/index.rst
  clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp

Index: clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp
@@ -0,0 +1,77 @@
+class A { A(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN
+class B { B(int i); };
+// NOLINTEND
+
+// NOLINTBEGIN
+// NOLINTEND
+// NOLINTBEGIN
+class B1 { B1(int i); };
+// NOLINTEND
+
+// NOLINTBEGIN
+// NOLINTEND
+class B2 { B2(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN(google-explicit-constructor)
+class C { C(int i); };
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(*)
+class C1 { C1(int i); };
+// NOLINTEND(*)
+
+// NOLINTBEGIN(some-other-check)
+class C2 { C2(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// NOLINTEND(some-other-check)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+class C3 { C3(int i); };
+// NOLINTEND(some-other-check, google-explicit-constructor)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+// NOLINTEND(some-other-check)
+class C4 { C4(int i); };
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(some-other-check, google-explicit-constructor)
+// NOLINTEND(google-explicit-constructor)
+class C5 { C5(int i); };
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: single-argument constructors must be marked explicit
+// NOLINTEND(some-other-check)
+
+// NOLINTBEGIN(google-explicit-constructor)
+// NOLINTBEGIN(some-other-check)
+class C6 { C6(int i); };
+// NOLINTEND(some-other-check)
+// NOLINTEND(google-explicit-constructor)
+
+// NOLINTBEGIN(not-closed-bracket-is-treated-as-skip-all
+class C7 { C7(int i); };
+// NOLINTEND(not-closed-bracket-is-treated-as-skip-all
+
+// NOLINTBEGIN without-brackets-skip-all, another-check
+class C8 { C8(int i); };
+// NOLINTEND without-brackets-skip-all, another-check
+
+#define MACRO(X) class X { X(int i); };
+
+MACRO(D1)
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: single-argument constructors must be marked explicit
+
+// NOLINTBEGIN
+MACRO(D2)
+// NOLINTEND
+
+#define MACRO_NOARG class E { E(int i); };
+// NOLINTBEGIN
+MACRO_NOARG
+// NOLINTEND
+
+// CHECK-MESSAGES: Suppressed 11 warnings (11 NOLINT)
+
+// RUN: %check_clang_tidy %s google-explicit-constructor %t --
Index: clang-tools-extra/docs/clang-tidy/index.rst
===
--- clang-tools-extra/docs/clang-tidy/index.rst
+++ clang-tools-extra/docs/clang-tidy/index.rst
@@ -295,17 +295,19 @@
 
 If a specific suppression mechanism is not available for a certain warning, or
 its use is not desired for some reason, :program:`clang-tidy` has a generic
-mechanism to suppress diagnostics using ``NOLINT`` or ``NOLINTNEXTLINE``
-comments.
+mechanism to suppress diagnostics using ``NOLINT``, ``NOLINTNEXTLINE``, and
+``NOLINTBEGIN`` ... ``NOLINTEND`` comments.
 
 The ``NOLINT`` comment instructs :program:`clang-tidy` to ignore warnings on the
 *same line* (it doesn't apply to a function, a block of code or any other
 language construct, it applies to the line of code it is on). If introducing the
 comment in the same line would change the formatting in undesired way, the
 ``NOLINTNEXTLINE`` comment allows to suppress clang-tidy warnings on the *next
-line*.
+line*. The ``NOLINTBEGIN`` and ``NOLINTEND`` comments allow suppressing
+clang-tidy warnings on *multiple lines* (affecting all lines between the two
+comments).
 
-Both comments can be followed by an optional list of check names in parentheses
+All comments can be followed by an optional list of check names in parentheses
 (see below for the formal syntax).
 
 For example:
@@ -325,9 +327,16 @@
 // Silence only the specified diagnostics for the ne

[PATCH] D102449: [WIP][Clang][OpenMP] Add the support for compare clause in atomic directive

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

Is this still WIP or should it be reviewed? Needs a proper commit message.




Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:5797-5800
+  // Cannot emit atomic operation.
+  // TODO: Do we really want to emit a non-atomic operation here?
+  if (!Res.first) {
+  }

This looks like something is missing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102449

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

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

[Yang Haonan via Phabricator via cfe-commits]

haonanya updated this revision to Diff 368119.
haonanya added a comment.

Unify formatting and fix some errors on OpenCLBuiltins.td


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

https://reviews.llvm.org/D106343

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/Headers/opencl-c-header.cl
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl

Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -122,6 +122,27 @@
 }
 #endif
 
+#if !defined(NO_HEADER) && !defined(NO_FP64) && __OPENCL_C_VERSION__ >= 200
+// Check added atomic_fetch_ functions by cl_ext_float_atomics
+// extension can be called
+void test_atomic_fetch_with_address_space(volatile __generic atomic_float *a_float,
+		  volatile __generic atomic_double *a_double,
+  volatile __local atomic_float *a_float_local,
+  volatile __local atomic_double *a_double_local,
+  volatile __global atomic_float *a_float_global,
+  volatile __global atomic_double *a_double_global) {
+  float f1, resf1;
+  double d1, resd1;
+  resf1 = atomic_fetch_min(a_float, f1);
+  resf1 = atomic_fetch_max_explicit(a_float_local, f1, memory_order_seq_cst);
+  resf1 = atomic_fetch_add_explicit(a_float_global, f1, memory_order_seq_cst, memory_scope_work_group);
+
+  resd1 = atomic_fetch_min(a_double, d1);
+  resd1 = atomic_fetch_max_explicit(a_double_local, d1, memory_order_seq_cst);
+  resd1 = atomic_fetch_add_explicit(a_double_global, d1, memory_order_seq_cst, memory_scope_work_group);
+}
+#endif // !defined(NO_HEADER) && __OPENCL_C_VERSION__ >= 200
+
 // Test old atomic overloaded with generic address space in C++ for OpenCL.
 #if __OPENCL_C_VERSION__ >= 200
 void test_legacy_atomics_cpp(__generic volatile unsigned int *a) {
Index: clang/test/Headers/opencl-c-header.cl
===
--- clang/test/Headers/opencl-c-header.cl
+++ clang/test/Headers/opencl-c-header.cl
@@ -135,6 +135,51 @@
 #if __opencl_c_integer_dot_product_input_4x8bit_packed != 1
 #error "Incorrectly defined __opencl_c_integer_dot_product_input_4x8bit_packed"
 #endif
+#if cl_ext_float_atomics != 1
+#error "Incorrectly defined cl_ext_float_atomics"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_load_store != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_load_store"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_load_store != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_load_store"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp32_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp64_global_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_global_atomic_add"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp32_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp64_local_atomic_add != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_local_atomic_add"
+#endif
+#if __opencl_c_ext_fp16_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp32_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp64_global_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_global_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp16_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp16_local_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp32_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp32_local_atomic_min_max"
+#endif
+#if __opencl_c_ext_fp64_local_atomic_min_max != 1
+#error "Incorrectly defined __opencl_c_ext_fp64_local_atomic_min_max"
+#endif
 
 #else
 
@@ -171,6 +216,51 @@
 #ifdef __opencl_c_integer_dot_product_input_4x8bit_packed
 #error "Incorrect __opencl_c_integer_dot_product_input_4x8bit_packed define"
 #endif
+#ifdef cl_ext_float_atomics
+#error "Incorrect cl_ext_float_atomics define"
+#endif
+#ifdef __opencl_c_ext_fp16_global_atomic_load_store
+#error "Incorrectly __opencl_c_ext_fp16_global_atomic_load_store defined"
+#endif
+#ifdef __opencl_c_ext_fp16_local_atomic_load_store
+#error "Incorrectly __opencl_c_ext_fp16_local_atomic_load_store defined"
+#endif
+#ifdef __opencl_c_ext_fp16_global_atomic_add
+#error "Incorrectly __opencl_c_ext_fp16_

[PATCH] D103807: [clang][deps] Ensure deterministic order of TU '-fmodule-file=' arguments

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

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

Another option to be aware of is `MapVector` 
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-mapvector-h). Does not 
sort, but guarantees iteration order.

But LGTM anyway. I don't think the exact data structure is important here. 
Please just add a comment documenting that consumers need a deterministic 
iteration order so anyone updating or optimizing this later knows what the 
constraints are.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103807

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

[PATCH] D108544: [clang][deps] Avoid generating arguments for missing module map files

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

dexonsmith added a comment.

Is there a way to test this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108544

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

[PATCH] D108268: [Modules] Change result of reading AST block to llvm::Error instead

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

dexonsmith added a comment.

LGTM once @vsapsai is happy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108268

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

[PATCH] D108540: [clang][deps] Collect precompiled deps from submodules too

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

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

LGTM.




Comment at: clang/test/ClangScanDeps/modules-pch-common-via-submodule.c:85
+// CHECK-TU:  "-emit-module"
+// CHECK-TU:  
"-fmodule-file=[[PREFIX]]/build/[[HASH_MOD_COMMON:.*]]/ModCommon-{{.*}}.pcm"
+// CHECK-TU:  "-fmodules"

jansvoboda11 wrote:
> Previously, we'd miss this module included from `mod_tu_sub.h`, resulting in 
> a compilation error for `ModTU`.
Can you add a comment to the top of the testcase explaining what's interesting 
about it? (Something similar to what you have here.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108540

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

[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/tools/libclang/CMakeLists.txt:176
 
 # The SOVERSION should be updated only if a change is made to the libclang
 # ABI, and when it is updated, it should be updated to the current

The comment should be lifted as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108533

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

[PATCH] D108533: [clang] Move the soname declaration in a variable at the top of the file

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru updated this revision to Diff 368126.
sylvestre.ledru added a comment.

Move the comment too


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108533

Files:
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -1,3 +1,9 @@
+# The SOVERSION should be updated only if a change is made to the libclang
+# ABI, and when it is updated, it should be updated to the current
+# LLVM_VERSION_MAJOR.
+# Please also see clang/tools/libclang/libclang.map
+set(CLANG_SONAME 13)
+
 set(SOURCES
   ARCMigrate.cpp
   BuildSystem.cpp
@@ -171,12 +177,9 @@
 set_property(SOURCE ARCMigrate.cpp APPEND PROPERTY
  OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
 
-# The SOVERSION should be updated only if a change is made to the libclang
-# ABI, and when it is updated, it should be updated to the current
-# LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION 
${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -1,3 +1,9 @@
+# The SOVERSION should be updated only if a change is made to the libclang
+# ABI, and when it is updated, it should be updated to the current
+# LLVM_VERSION_MAJOR.
+# Please also see clang/tools/libclang/libclang.map
+set(CLANG_SONAME 13)
+
 set(SOURCES
   ARCMigrate.cpp
   BuildSystem.cpp
@@ -171,12 +177,9 @@
 set_property(SOURCE ARCMigrate.cpp APPEND PROPERTY
  OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/libclang.map)
 
-# The SOVERSION should be updated only if a change is made to the libclang
-# ABI, and when it is updated, it should be updated to the current
-# LLVM_VERSION_MAJOR.
 set_target_properties(libclang PROPERTIES
   VERSION ${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}${LLVM_VERSION_SUFFIX}
-  SOVERSION 13)
+  SOVERSION ${CLANG_SONAME})
   endif()
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

[Paul Herman via Phabricator via cfe-commits]

paulherman updated this revision to Diff 368127.
paulherman added a comment.

Explaining the tag argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

Files:
  clang/include/clang/Basic/AttrDocs.td


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -5881,19 +5881,21 @@
 If this annotation is on a function or a function type it is assumed to return
 a new handle. In case this annotation is on an output parameter,
 the function is assumed to fill the corresponding argument with a new
-handle.
+handle. The attribute requires a string literal argument which used to
+identify the handle with later uses of ``use_handle`` or
+``release_handle``.
 
 .. code-block:: c++
 
   // Output arguments from Zircon.
   zx_status_t zx_socket_create(uint32_t options,
-   zx_handle_t __attribute__((acquire_handle)) * 
out0,
-   zx_handle_t* out1 [[clang::acquire_handle]]);
+   zx_handle_t 
__attribute__((acquire_handle("zircon"))) * out0,
+   zx_handle_t* out1 
[[clang::acquire_handle("zircon")]]);
 
 
   // Returned handle.
-  [[clang::acquire_handle]] int open(const char *path, int oflag, ... );
-  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle));
+  [[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
+  int open(const char *path, int oflag, ... ) 
__attribute__((acquire_handle("tag")));
   }];
 }
 
@@ -5901,12 +5903,13 @@
   let Category = HandleDocs;
   let Content = [{
 A function taking a handle by value might close the handle. If a function
-parameter is annotated with ``use_handle`` it is assumed to not to change
+parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
 the state of the handle. It is also assumed to require an open handle to work 
with.
+The attribute requires a string literal argument to identify the handle being 
used.
 
 .. code-block:: c++
 
-  zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle]],
+  zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle("zircon")]],
zx_time_t deadline,
zx_port_packet_t* packet);
   }];
@@ -5915,12 +5918,13 @@
 def ReleaseHandleDocs : Documentation {
   let Category = HandleDocs;
   let Content = [{
-If a function parameter is annotated with ``release_handle`` it is assumed to
-close the handle. It is also assumed to require an open handle to work with.
+If a function parameter is annotated with ``release_handle(tag)`` it is 
assumed to
+close the handle. It is also assumed to require an open handle to work with. 
The
+attribute requires a string literal argument to identify the handle being 
released.
 
 .. code-block:: c++
 
-  zx_status_t zx_handle_close(zx_handle_t handle [[clang::release_handle]]);
+  zx_status_t zx_handle_close(zx_handle_t handle 
[[clang::release_handle("tag")]]);
   }];
 }
 


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -5881,19 +5881,21 @@
 If this annotation is on a function or a function type it is assumed to return
 a new handle. In case this annotation is on an output parameter,
 the function is assumed to fill the corresponding argument with a new
-handle.
+handle. The attribute requires a string literal argument which used to
+identify the handle with later uses of ``use_handle`` or
+``release_handle``.
 
 .. code-block:: c++
 
   // Output arguments from Zircon.
   zx_status_t zx_socket_create(uint32_t options,
-   zx_handle_t __attribute__((acquire_handle)) * out0,
-   zx_handle_t* out1 [[clang::acquire_handle]]);
+   zx_handle_t __attribute__((acquire_handle("zircon"))) * out0,
+   zx_handle_t* out1 [[clang::acquire_handle("zircon")]]);
 
 
   // Returned handle.
-  [[clang::acquire_handle]] int open(const char *path, int oflag, ... );
-  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle));
+  [[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
+  int open(const char *path, int oflag, ... ) __attribute__((acquire_handle("tag")));
   }];
 }
 
@@ -5901,12 +5903,13 @@
   let Category = HandleDocs;
   let Content = [{
 A function taking a handle by value might close the handle. If a function
-parameter is annotated with ``use_handle`` it is assumed to not to change
+parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
 the state of the handle. It is also assumed to require an open handle to w

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

[Andrei Elovikov via Phabricator via cfe-commits]

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

Hi guys, do you want me to fix anything else? I think I've addressed what I 
could.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

[Erich Keane via Phabricator via cfe-commits]

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

2 nits, give Craig a day or two to =1 as well please, particularly since he's 
the code-owner here.




Comment at: clang/lib/Basic/Targets/X86.cpp:1063
+#ifndef NDEBUG
+  // Check that priorities are set properly in the .def file, i.e.
+#define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) PRIORITY,

Just a nit, I would like a better description here of the constraint we're 
trying to enforce.  I can imagine someone in the future failing this, and not 
getting the context without a few sentences of how no duplicates are allowed, 
and it must be all numbers from 0 to the-max-number.



Comment at: clang/lib/Basic/Targets/X86.cpp:1074
+ std::prev(std::end(Priorities))) &&
+ "Priorites don't form consecutive range!");
+#endif




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[PATCH] D108151: [NFC][clang] Use X86 Features declaration from X86TargetParser

[Craig Topper via Phabricator via cfe-commits]

craig.topper accepted this revision.
craig.topper added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108151

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

[clang] 43de869 - Implement #pragma clang restrict_expansion

[Chris Bieneman via cfe-commits]

Author: Chris Bieneman
Date: 2021-08-23T09:46:38-07:00
New Revision: 43de869d77f77eedf9f8760f94940a249d2b5a41

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

LOG: Implement #pragma clang restrict_expansion

This patch adds `#pragma clang restrict_expansion ` to enable flagging
macros as unsafe for header use. This is to allow macros that may have
ABI implications to be avoided in headers that have ABI stability
promises.

Using macros in headers (particularly public headers) can cause a
variety of issues relating to ABI and modules. This new pragma logs
warnings when using annotated macros outside the main source file.

This warning is added under a new diagnostics group -Wpedantic-macros

Reviewed By: aaron.ballman

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

Added: 
clang/test/Lexer/Inputs/pedantic-macro-interplay.h
clang/test/Lexer/Inputs/unsafe-macro-2.h
clang/test/Lexer/Inputs/unsafe-macro.h
clang/test/Lexer/pedantic-macro-interplay.c
clang/test/Lexer/unsafe-macro.c

Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Basic/IdentifierTable.h
clang/include/clang/Lex/Preprocessor.h
clang/lib/Lex/Pragma.cpp
clang/lib/Lex/Preprocessor.cpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 087aa66c1b7af..fada65c487bc5 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3931,6 +3931,40 @@ provide deprecation warnings for macro uses. For example:
 ``#pragma GCC warning`` because the warning can be controlled with
 ``-Wdeprecated``.
 
+Restricted Expansion Macros
+===
+
+Clang supports the pragma ``#pragma clang restrict_expansion``, which can be
+used restrict macro expansion in headers. This can be valuable when providing
+headers with ABI stability requirements. Any expansion of the annotated macro
+processed by the preprocessor after the ``#pragma`` annotation will log a
+warning. Redefining the macro or undefining the macro will not be diagnosed, 
nor
+will expansion of the macro within the main source file. For example:
+
+.. code-block:: c
+
+   #define TARGET_ARM 1
+   #pragma clang restrict_expansion(TARGET_ARM, "")
+
+   /// Foo.h
+   struct Foo {
+   #if TARGET_ARM // warning: TARGET_ARM is marked unsafe in headers: 
+ uint32_t X;
+   #else
+ uint64_t X;
+   #endif
+   };
+
+   /// main.c
+   #include "foo.h"
+   #if TARGET_ARM // No warning in main source file
+   X_TYPE uint32_t
+   #else
+   X_TYPE uint64_t
+   #endif
+
+This warning is controlled by ``-Wpedantic-macros``.
+
 Extended Integer Types
 ==
 

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 17b5f419ef58c..753a3d5546e2f 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -647,6 +647,7 @@ def AmbiguousMacro : DiagGroup<"ambiguous-macro">;
 def KeywordAsMacro : DiagGroup<"keyword-macro">;
 def ReservedIdAsMacro : DiagGroup<"reserved-macro-identifier">;
 def ReservedIdAsMacroAlias : DiagGroup<"reserved-id-macro", 
[ReservedIdAsMacro]>;
+def RestrictExpansionMacro : DiagGroup<"restrict-expansion">;
 
 // Just silence warnings about -Wstrict-aliasing for now.
 def : DiagGroup<"strict-aliasing=0">;
@@ -1311,3 +1312,10 @@ def WebAssemblyExceptionSpec : 
DiagGroup<"wasm-exception-spec">;
 def RTTI : DiagGroup<"rtti">;
 
 def OpenCLCoreFeaturesDiagGroup : DiagGroup<"pedantic-core-features">;
+
+// Warnings and extensions to make preprocessor macro usage pedantic.
+def PedanticMacros : DiagGroup<"pedantic-macros",
+[DeprecatedPragma,
+ MacroRedefined,
+ BuiltinMacroRedefined,
+ RestrictExpansionMacro]>;

diff  --git a/clang/include/clang/Basic/DiagnosticLexKinds.td 
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index c19adf104db1f..49c50fb27e624 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -528,6 +528,16 @@ def warn_pragma_deprecated_macro_use :
   ExtWarn<"macro %0 has been marked as deprecated%select{|: %2}1">,
   InGroup;
 
+// - #pragma clang restrict_expansion(...)
+def warn_pragma_restrict_expansion_macro_use :
+  ExtWarn<"macro %0 has been marked as unsafe for use in headers"
+  "%select{|: %2}1">,
+  InGroup;
+
+// - Note for macro annotations.
+def note_pp_macro_annotation :
+  Note<"macro marked '%select{deprecated|restrict_expansion}0' here">;
+
 // - #pragma execution_character_set(...)
 def warn_pragma_exec_chars

[PATCH] D107095: Implement #pragma clang restrict_expansion

[Chris Bieneman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG43de869d77f7: Implement #pragma clang restrict_expansion 
(authored by beanz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D107095

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Lexer/Inputs/pedantic-macro-interplay.h
  clang/test/Lexer/Inputs/unsafe-macro-2.h
  clang/test/Lexer/Inputs/unsafe-macro.h
  clang/test/Lexer/pedantic-macro-interplay.c
  clang/test/Lexer/unsafe-macro.c

Index: clang/test/Lexer/unsafe-macro.c
===
--- /dev/null
+++ clang/test/Lexer/unsafe-macro.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -Wrestrict-expansion %s -fsyntax-only -verify
+#include "Inputs/unsafe-macro.h"
+#include "Inputs/unsafe-macro-2.h"
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if UNSAFE_MACRO
+#endif
Index: clang/test/Lexer/pedantic-macro-interplay.c
===
--- /dev/null
+++ clang/test/Lexer/pedantic-macro-interplay.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -Wpedantic-macros %s -fsyntax-only -verify
+
+// This test verifies that the -Wpedantic-macros warnings don't fire in the
+// annotation pragmas themselves. This ensures you can annotate macros with
+// more than one of the pragmas without spewing warnings all over the code.
+
+#include "Inputs/pedantic-macro-interplay.h"
+
+#define UNSAFE_MACRO_2 1
+#pragma clang deprecated(UNSAFE_MACRO_2, "Don't use this!")
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as deprecated: Don't use this!}}
+#pragma clang restrict_expansion(UNSAFE_MACRO_2, "Don't use this!")
+
+// expected-no-diagnostics
Index: clang/test/Lexer/Inputs/unsafe-macro.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/unsafe-macro.h
@@ -0,0 +1,27 @@
+// expected-error@+1{{expected (}}
+#pragma clang restrict_expansion
+
+// expected-error@+1{{expected identifier}}
+#pragma clang restrict_expansion(4
+
+// expected-error@+1{{no macro named foo}}
+#pragma clang restrict_expansion(foo)
+
+
+#define UNSAFE_MACRO 1
+// expected-note@+8{{macro marked 'restrict_expansion' here}}
+// expected-note@+7{{macro marked 'restrict_expansion' here}}
+// expected-note@+6{{macro marked 'restrict_expansion' here}}
+// expected-note@+5{{macro marked 'restrict_expansion' here}}
+// expected-note@+4{{macro marked 'restrict_expansion' here}}
+// expected-note@+3{{macro marked 'restrict_expansion' here}}
+// expected-note@+2{{macro marked 'restrict_expansion' here}}
+// expected-note@+1{{macro marked 'restrict_expansion' here}} 
+#pragma clang restrict_expansion(UNSAFE_MACRO, "Don't use this!")
+
+#define UNSAFE_MACRO_2 2
+// expected-note@+1{{macro marked 'restrict_expansion' here}}
+#pragma clang restrict_expansion(UNSAFE_MACRO_2)
+
+// expected-error@+1{{expected )}}
+#pragma clang deprecated(UNSAFE_MACRO
Index: clang/test/Lexer/Inputs/unsafe-macro-2.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/unsafe-macro-2.h
@@ -0,0 +1,70 @@
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#if defined(UNSAFE_MACRO)
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#ifdef UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#ifndef UNSAFE_MACRO
+#endif
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+const int x = UNSAFE_MACRO;
+
+// expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+const int y = UNSAFE_MACRO_2;
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+#undef UNSAFE_MACRO_2
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+#define UNSAFE_MACRO_2 2
+
+// not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as unsafe for use in headers}}
+const int z = UNSAFE_MACRO_2;
+
+
+// Test that we diagnose on #elif.
+#if 0
+#elif UNSAFE_MACRO
+// expected-warning@-1{{macro 'UNSAFE_MACRO' has been marked as unsafe for use in headers: Don't use this!}}
+#endif
+
+
+// Test that we diagnose on #elifdef.
+#ifdef baz
+#elif

[PATCH] D108366: [clang][deps] Deduce resource directory from the compiler path

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

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

In D108366#2959736 , @jansvoboda11 
wrote:

> For `clang-scan-deps`, this is //almost// NFC. This code kicks in iff 
> `ResourceDirectoryCache` doesn't provide any result:
>
> - the execution of `CommandLine[0] -print-resource-dir` command returns a 
> non-zero exit code (exercised in the test) or doesn't print anything,
> - the `CommandLine` is empty,
> - the compiler executable (`CommandLine[0]`) is not an absolute path.
>
> That's why I want to check with people if we can agree on removing 
> `ResourceDirectoryCache`. I'd be keen on updating this patch to include the 
> change and make the test more obviously correct.

Got it.

I wonder if it'd be better to split "changing default behaviour of 
clang-scan-deps the tool" from "avoid inject-resource-dir logic when it's 
incorrect". I.e., commit something in this patch to fix the immediate problem 
and remove/optimize ResourceDirectoryCache in a follow-up.

For this patch, you could add an inject-resource-dir flag to the scanning 
service, which controls the new Clang::Tooling flag (and can be controlled by 
libclang), and a command-line flag in clang-scan-deps to allow testing both 
sides of it. Would be worth documenting the testcase with a good comment to 
explain the corner case. Maybe the command-line flag would also disable 
ResourceDirectoryCache.




Comment at: clang/test/ClangScanDeps/resource_directory.c:3
+// RUN: cp %S/Inputs/resource_directory/* %t
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" 
%S/Inputs/resource_directory/cdb_tu.json > %t/cdb.json
+

I don't love this hardcoded path to clang which //could// exist on some machine.

Could you use `/dev/null` for the path to clang?
Or `/dev/null/bin/clang`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108366

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

[PATCH] D108544: [clang][deps] Avoid generating arguments for missing module map files

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

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

In D108544#2960279 , @dexonsmith 
wrote:

> Is there a way to test this?

Marking "request changes" for clarity.

Since this drops `-fmodule-map-file=` arguments, I imagine you can add a test 
that demonstrates it. But if that's currently awkward to observe because you 
need another piece to land in a follow-up, I'm fine to delay testing until then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108544

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

[PATCH] D106343: [OpenCL] Support cl_ext_float_atomics

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

Thanks for the update!  I have a comment about indentation, other than that 
this is looking good to me.




Comment at: clang/lib/Sema/OpenCLBuiltins.td:1129
+let Extension = FuncExtFloatAtomicsFp64GlobalAdd in {
+def : Builtin<"atomic_fetch_" # ModOp,
+[Double, PointerType, GlobalAS>, Double]>;

Please indent the content inside all `let` blocks.


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

https://reviews.llvm.org/D106343

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

[PATCH] D107769: [OpenCL] Make generic addrspace optional for -fdeclare-opencl-builtins

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh updated this revision to Diff 368136.
svenvh edited the summary of this revision.
svenvh added a comment.

I have done an alternative spin of this patch: instead of introducing 
`RequireDisabledExtension`, simply always make the `private`, `global`, and 
`local` overloads available.  This makes tablegen diverge from `opencl-c.h` 
though.  Perhaps we should also always add make the `private`, `global`, and 
`local` overloads available in `opencl-c.h`?


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

https://reviews.llvm.org/D107769

Files:
  clang/lib/Sema/OpenCLBuiltins.td
  clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
  clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl


Index: clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/SemaOpenCL/fdeclare-opencl-builtins.cl
@@ -63,6 +63,7 @@
 
 // Enable extensions that are enabled in opencl-c-base.h.
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 200)
+#define __opencl_c_generic_address_space 1
 #define cl_khr_subgroup_extended_types 1
 #define cl_khr_subgroup_ballot 1
 #define cl_khr_subgroup_non_uniform_arithmetic 1
Index: clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
===
--- clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
+++ clang/test/CodeGenOpenCL/fdeclare-opencl-builtins.cl
@@ -1,5 +1,11 @@
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -finclude-default-header %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s | FileCheck 
%s
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-GAS
+// RUN: %clang_cc1 -emit-llvm -o - -O0 -triple spir-unknown-unknown 
-cl-std=CL3.0 -fdeclare-opencl-builtins -finclude-default-header 
-cl-ext=-__opencl_c_generic_address_space,-__opencl_c_pipes %s \
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-NOGAS
 
 // Test that mix is correctly defined.
 // CHECK-LABEL: @test_float
@@ -32,6 +38,15 @@
   size_t lid = get_local_id(0);
 }
 
+// Test that the correct builtin is called depending on the generic address
+// space feature availability.
+// CHECK-LABEL: @test_generic_optionality
+// CHECK-GAS: call spir_func float @_Z5fractfPU3AS4f
+// CHECK-NOGAS: call spir_func float @_Z5fractfPf
+void test_generic_optionality(float a, float *b) {
+  float res = fract(a, b);
+}
+
 // CHECK: attributes [[ATTR_CONST]] =
 // CHECK-SAME: readnone
 // CHECK: attributes [[ATTR_PURE]] =
Index: clang/lib/Sema/OpenCLBuiltins.td
===
--- clang/lib/Sema/OpenCLBuiltins.td
+++ clang/lib/Sema/OpenCLBuiltins.td
@@ -83,6 +83,7 @@
 def FuncExtKhrMipmapImageWrites  : 
FunctionExtension<"cl_khr_mipmap_image_writes">;
 def FuncExtKhrGlMsaaSharing  : 
FunctionExtension<"cl_khr_gl_msaa_sharing">;
 
+def FuncExtOpenCLCGenericAddressSpace: 
FunctionExtension<"__opencl_c_generic_address_space">;
 def FuncExtOpenCLCPipes  : 
FunctionExtension<"__opencl_c_pipes">;
 def FuncExtOpenCLCWGCollectiveFunctions  : 
FunctionExtension<"__opencl_c_work_group_collective_functions">;
 
@@ -566,10 +567,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : MathWithPointer<[GlobalAS, LocalAS, PrivateAS]>;
-}
-let MinVersion = CL20 in {
+defm : MathWithPointer<[GlobalAS, LocalAS, PrivateAS]>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : MathWithPointer<[GenericAS]>;
 }
 
@@ -824,10 +823,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : VloadVstore<[GlobalAS, LocalAS, PrivateAS], 1>;
-}
-let MinVersion = CL20 in {
+defm : VloadVstore<[GlobalAS, LocalAS, PrivateAS], 1>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : VloadVstore<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.
@@ -859,10 +856,8 @@
   }
 }
 
-let MaxVersion = CL20 in {
-  defm : VloadVstoreHalf<[GlobalAS, LocalAS, PrivateAS], 1>;
-}
-let MinVersion = CL20 in {
+defm : VloadVstoreHalf<[GlobalAS, LocalAS, PrivateAS], 1>;
+let Extension = FuncExtOpenCLCGenericAddressSpace in {
   defm : VloadVstoreHalf<[GenericAS], 1>;
 }
 // vload with constant address space is available regardless of version.


Index: clang/test/SemaOpenCL/fdecla

[PATCH] D108456: [CUDA] Fix static device variables with -fgpu-rdc

[Artem Belevich via Phabricator via cfe-commits]

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

LGTM.

Please wait for @yaxunl . I believe he mentioned in D85223 
 that he'll check whether it works on AMD's 
end.




Comment at: clang/lib/CodeGen/CodeGenModule.cpp:6450
 llvm::raw_ostream &OS) const {
-  OS << ".static." << getContext().getCUIDHash();
+  OS << "__static__" << getContext().getCUIDHash();
 }

Hahnfeld wrote:
> tra wrote:
> > I would expect  NVPTXAssignValidGlobalNames.cpp to deal with this ptx 
> > quirk. 
> > I'm fine with the underscores, but it would be good we're not just covering 
> > up an issue somewhere else.
> > 
> `NVPTXAssignValidGlobalNames` checks `hasLocalLinkage`, which the `static` 
> variables here are not (see discussion in D85223). I think the reason is that 
> we don't want variable and function names to differ between host and device, 
> and this might even be important here for maintaining proper connection for 
> `cudaMemcpy`s and so on.
Right. We do need to have the same names on both sides.

I wish there was a way to avoid breaking demangling, but looks like we don't 
have any good options here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108456

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

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[Renato Golin via cfe-commits]

On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> But unless I missed this, was there any discussion regarding the recent
> "Winding Down" announcement of Phabricator? and what it might mean for us
> in LLVM
>

I think we have our own self-hosted version and enough local people that
has hacked on it to "maintain" it, but we'd stop getting the updated from
upstream, which have been substantial over the years.

I don't think this should be a rush to replace with an alternative, as
there is no imminent peril, but it is an additional important point for the
ongoing discussion of potential transition.

Personally I'm excited by the concept of a community driven replacement (
> https://we.phorge.it/) .
> epriestley did a truly amazing job, it wasn't open to public
> contributions. Perhaps more open development could lead to closing some of
> the github gaps that were of concern.
>

IMO, it would have to be seriously active upstream, understand our existing
database "as is" and import without problems, and interface with Github
more closely to be worth the hassle of migration.

Github pull requests don't seem to be improving a lot, so "phorge" may be
the right answer sooner than they catch up...

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

Re: [llvm-dev] Phabricator Creator Pulling the Plug

[James Y Knight via cfe-commits]

If phabricator/phorge do turn out to be non-viable in the future, I think
we may want to reopen the option of moving to Gerrit for the primary
code-review platform.

I'll note that the Golang folks are using Gerrit as their review platform,
and they have a GitHub bot setup to translate GH pull-requests into a
gerrit review, so as to be friendly to first-time or drive-by contributors.
See e.g. https://github.com/golang/go/pull/47766 for an example.

On Mon, Aug 23, 2021 at 1:38 PM Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> But unless I missed this, was there any discussion regarding the recent
>> "Winding Down" announcement of Phabricator? and what it might mean for us
>> in LLVM
>>
>
> I think we have our own self-hosted version and enough local people that
> has hacked on it to "maintain" it, but we'd stop getting the updated from
> upstream, which have been substantial over the years.
>
> I don't think this should be a rush to replace with an alternative, as
> there is no imminent peril, but it is an additional important point for the
> ongoing discussion of potential transition.
>
> Personally I'm excited by the concept of a community driven replacement (
>> https://we.phorge.it/) .
>> epriestley did a truly amazing job, it wasn't open to public
>> contributions. Perhaps more open development could lead to closing some of
>> the github gaps that were of concern.
>>
>
> IMO, it would have to be seriously active upstream, understand our
> existing database "as is" and import without problems, and interface with
> Github more closely to be worth the hassle of migration.
>
> Github pull requests don't seem to be improving a lot, so "phorge" may be
> the right answer sooner than they catch up...
>
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108567: Implement #pragma clang final extension

[Chris Bieneman via Phabricator via cfe-commits]

beanz created this revision.
beanz added reviewers: aaron.ballman, rsmith, lgerbarg, pete, lebedev.ri, 
dexonsmith.
beanz requested review of this revision.
Herald added a project: clang.

This patch adds a new preprocessor extension ``#pragma clang final``
which enables warning on undefinition and re-definition of macros.

The intent of this warning is to extend beyond ``-Wmacro-redefined`` to
warn against any and all alterations to macros that are marked `final`.

This warning is part of the ``-Wpedantic-macros`` diagnostics group.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108567

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Lexer/Inputs/final-macro.h
  clang/test/Lexer/final-macro.c
  clang/test/Lexer/pedantic-macro-interplay.c

Index: clang/test/Lexer/pedantic-macro-interplay.c
===
--- clang/test/Lexer/pedantic-macro-interplay.c
+++ clang/test/Lexer/pedantic-macro-interplay.c
@@ -11,4 +11,17 @@
 // not-expected-warning@+1{{macro 'UNSAFE_MACRO_2' has been marked as deprecated: Don't use this!}}
 #pragma clang restrict_expansion(UNSAFE_MACRO_2, "Don't use this!")
 
-// expected-no-diagnostics
+
+#define Foo 1
+#pragma clang final(Foo)
+// expected-note@+2{{macro marked 'deprecated' here}}
+// expected-note@+1{{macro marked 'deprecated' here}}
+#pragma clang deprecated(Foo)
+// expected-note@+1{{macro marked 'restrict_expansion' here}}
+#pragma clang restrict_expansion(Foo)
+
+// Test that unsafe_header and deprecated markings stick around after the undef
+#include "Inputs/final-macro.h"
+
+// expected-warning@+1{{macro 'Foo' has been marked as deprecated}}
+const int X = Foo;
Index: clang/test/Lexer/final-macro.c
===
--- /dev/null
+++ clang/test/Lexer/final-macro.c
@@ -0,0 +1,40 @@
+// RUN: %clang_cc1 -Wfinal-macro %s -fsyntax-only -verify
+
+// Test warning production
+// expected-note@+1{{previous definition is here}}
+#define Foo 1
+// expected-note@+2{{macro marked 'final' here}}
+// expected-note@+1{{macro marked 'final' here}}
+#pragma clang final(Foo)
+#pragma clang deprecated(Foo)
+#pragma clang header_unsafe(Foo)
+
+// expected-warning@+1{{'Foo' macro redefined}}
+#define Foo 2
+
+// expected-warning@+1{{redefining builtin macro}}
+#define __TIME__ 1
+
+// expected-warning@+1{{undefining builtin macro}}
+#undef __TIMESTAMP__
+
+// expected-warning@+1{{macro 'Foo' has been marked as final and should not be undefined}}
+#undef Foo
+// expected-warning@+1{{macro 'Foo' has been marked as final and should not be redefined}}
+#define Foo 3
+
+// Test parse errors
+// expected-error@+1{{expected (}}
+#pragma clang final
+
+// expected-error@+1{{expected )}}
+#pragma clang final(Foo
+
+// expected-error@+1{{no macro named Baz}}
+#pragma clang final(Baz)
+
+// expected-error@+1{{expected identifier}}
+#pragma clang final(4)
+
+// expected-error@+1{{expected (}}
+#pragma clang final Baz
Index: clang/test/Lexer/Inputs/final-macro.h
===
--- /dev/null
+++ clang/test/Lexer/Inputs/final-macro.h
@@ -0,0 +1,4 @@
+// expected-warning@+2{{macro 'Foo' has been marked as deprecated}}
+// expected-warning@+1{{macro 'Foo' has been marked as unsafe for use in headers}}
+#if Foo
+#endif
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -1413,26 +1413,46 @@
   return true;
 }
 
-void Preprocessor::emitMacroDeprecationWarning(const Token &Identifier) {
-  auto DepMsg = getMacroDeprecationMsg(Identifier.getIdentifierInfo());
-  if (DepMsg.first.empty())
+void Preprocessor::emitMacroDeprecationWarning(const Token &Identifier) const {
+  const MacroAnnotations &A =
+  getMacroAnnotations(Identifier.getIdentifierInfo());
+  assert(A.DeprecationInfo &&
+ "Macro deprecation warning without recorded annotation!");
+  const MacroAnnotationInfo &Info = *A.DeprecationInfo;
+  if (Info.Message.empty())
 Diag(Identifier, diag::warn_pragma_deprecated_macro_use)
 << Identifier.getIdentifierInfo() << 0;
   else
 Diag(Identifier, diag::warn_pragma_deprecated_macro_use)
-<< Identifier.getIdentifierInfo() << 1 << DepMsg.first;
-  Diag(DepMsg.second, diag::note_pp_macro_annotation) << 0;
+<< Identifier.getIdentifierInfo() << 1 << Info.Message;
+  Diag(Info.Location, diag::note_pp_macro_annotation) << 0;
 }
 
-void Preprocessor::emitMacroUnsafeHeaderWarning(const Token &Identifier) {
-  auto DepMsg = getRestrictExpansionMsg(Identifier.getIdentifierInfo());
-  if (DepMsg.first

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

To summarize the conversation, can we do LD_LIBRARY_PATH overwrites after this 
patch or not? If so, I feel everyone is in favor, if not, we need a different 
solution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D108464: [clang][CodeGen] Refactor CreateTempAlloca function nest. NFC.

[John McCall via Phabricator via cfe-commits]

rjmccall added a reviewer: jfb.
rjmccall added a comment.

+ JF, who knows something about Web Assembly, or can at least drag in the right 
people

In D108464#2959591 , @wingo wrote:

> In D108464#2957276 , @wingo wrote:
>
>> So... besides the refactor, this is getting closer to where I'm going in 
>> https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html, though still 
>> NFC.  I think you can see where I would replace `getASTAllocaAddressSpace` 
>> with `getAllocaAddressSpace(QualType Ty)`, and possibly (depending on the 
>> source language) avoid casting the resulting alloca to `LangAS::Default`.  
>> WDYT, is this sort of thing OK?
>
> Taking this patch as perhaps a better generic discussion point, @rjmccall 
> graciously gave some general feedback on this approach (thank you!!!):
>
> In D108360#2957844 , @rjmccall 
> wrote:
>
>> I'm not sure that I agree with your overall plan, though:
>>
>> - The WebAssembly operand stack is not a good match for an address space at 
>> the language level because it's not addressable at all.  If you can't 
>> meaningfully have a pointer into the address space, then you don't really 
>> need this in the type system; it's more like a declaration modifier at best.
>> - Allocating local variables on the operand stack ought to be a very 
>> straightforward analysis in the backend.  There's not much optimization 
>> value in trying to do it in the frontend, and it's going to be problematic 
>> for things like coroutine lowering.
>> - The security argument seems pretty weak, not because security isn't 
>> important but because this is not really an adequate basis for getting the 
>> tamper-proof guarantee you want.  For example, LLVM passes can and do 
>> introduce its own allocas and store scalars into them sometimes.  Really you 
>> need some sort of "tamper-proof" *type* which the compiler can make an 
>> end-to-end guarantee of non-tamper-ability for the values of, and while 
>> optimally this would be implemented by just keeping values on the operand 
>> stack, in the general case you will need to have some sort of strategy for 
>> keeping things in memory.
>
> Thanks for thinking about this!  Indeed I started out with the goal of not 
> going deep into clang and if it's possible to avoid going too deeply, that 
> would be better for everyone involved.  I am starting to think however that 
> it may be unavoidable for me at least.
>
> So, I am focusing on WebAssembly global and local variables; the WebAssembly 
> operand stack is an artifact of the IR-to-MC lowering and AFAICS doesn't have 
> any bearing on what clang does -- though perhaps I am misunderstanding what 
> you are getting at here.  The issue is not to allocate locals on the operand 
> stack, but rather to allocate them as part of the "locals" of a WebAssembly 
> function 
> .  Cc 
> @tlively on the WebAssembly side.

By "operand stack" I mean the innate, unaddressable stack that the WebAssembly 
VM maintains in order to make functions reentrant.  I don't know what term the 
VM spec uses for it, but I believe "operand stack" is widely accepted 
terminology for the unaddressable stack when you've got this kind of dual-stack 
setup.  And yes, VM "locals" would go there.

> The main motivator is the ability to have "reference type" 
>  
> (`externref`/`funcref`) locals and globals 
>  at all. 
>  Reference-typed values can't be stored to linear memory.  They have no size 
> and no byte representation -- they are opaque values from the host.  However, 
> WebAssembly locals and globals can define storage locations of type 
> `externref` or `funcref`.

I see.  I think you need to think carefully about the best way to represent 
values of these types in LLVM IR, because it probably cannot just be "treat 
them as a normal value, emit code a certain way that we know how to lower, and 
hope nothing goes wrong".  It seems to me that you probably need a new IR type 
for it, since normal types aren't restricted from memory and tokens can't be 
used as parameters or return values.

Hopefully, someone had a plan for this when they introduced that WebAssembly 
extension.

> But, if we add a generic OpenCL-like address space attribute, that would 
> allow the user to declare some variables to be in alternate address spaces.  
> Then we can apply the ACLE SVE semantic restrictions to these values also, 
> and add on an additional restriction preventing address-of.  That way users 
> get to make off-heap definitions, and if they misuse them, they get 
> comprehensible errors.  LLVM IR and WebAssembly lowering is ready for these 
> alternate-address-space allocations.

Again, I'm n

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D101960#2960622 , @jdoerfert wrote:

> To summarize the conversation, can we do LD_LIBRARY_PATH overwrites after 
> this patch or not? If so, I feel everyone is in favor, if not, we need a 
> different solution.

+1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Pasting `env LD_LIBRARY_PATH=` and `env LIBRARY_PATH` into the printed 
commandline, as opposed to through magic, would solve most of my day to day 
frustration here. libomp.so and libomptarget.so are in two different 
directories, LD_LIBRARY_PATH turns out to be colon delimited. LIBRARY_PATH is 
presently used to find the deviceRTL though I'd like to change that.

That doesn't solve any of the experience for our users but does help with 
debugging the tests. I'm currently trying to work out why the set of tests that 
fail under lit are different to the set that fail outside of lit and decreasing 
magic there might help me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

At present libomptarget_amdgcn_bc_path and nvptx need to be a path to a file. 
If we relax that to accept a path to a directory in which the corresponding 
file is found, then we can use that argument in place of LIBRARY_PATH from the 
test scripts. That will let the tests run, gives developers absolute control 
over which deviceRTL library is linked in, stops clang from picking up the 
wrong file from an unrelated toolchain on LIBRARY_PATH. I consider that 
strictly better than the above patch. Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[PATCH] D108525: Fix documentation and snippets for the handle attributes.

[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, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108525

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