[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Alex Orlov via Phabricator via cfe-commits]

aorlov added a comment.

In D92024#2431452 , @Quuxplusone wrote:

> The subject line says "access checking on specializations and 
> instantiations," but I don't see any tests for explicit instantiations here — 
> just specializations. In particular, I'm very interested to know if P0692 is 
> intended to have any effect on the legality of https://godbolt.org/z/fqfo8q

Thank you for your important suggestion! I'll add test cases for //explicit 
instantiations//.

> It would also be good to document which of the two proposed wordings from 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html is 
> actually being adopted in this patch.

AFAIK there are four options in the paper. This patch covers option *A*. I'll 
mention this in the summary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

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

[PATCH] D79773: [clang-format] Improve clang-formats handling of concepts

[Johel Ernesto Guerrero Peña via Phabricator via cfe-commits]

JohelEGP added a comment.

Yes, here's my reply: https://bugs.llvm.org/show_bug.cgi?id=47161#c2.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79773

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

[PATCH] D92715: [Clang][RISCV] Define RISC-V V builtin types

[Evandro Menezes via Phabricator via cfe-commits]

evandro created this revision.
evandro added reviewers: Hsiang-Kai, craig.topper, rogfer01, frasercrmck.
Herald added subscribers: dexonsmith, NickHung, luismarques, apazos, 
sameer.abuasal, pzheng, s.egerton, lenary, Jim, benna, psnobl, jocewei, PkmX, 
arphaman, the_o, brucehoult, MartinMosbeck, edward-jones, zzheng, jrtc27, 
shiva0217, martong, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, 
asb.
Herald added a reviewer: shafik.
evandro requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

Add the types for the RISC-V V extension builtins.

Authored-by: Hsiangkai Wang 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92715

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/RISCVVTypes.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/module.modulemap
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/Sema/riscv-types.c
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -1548,6 +1548,8 @@
 #include "clang/Basic/AArch64SVEACLETypes.def"
 #define PPC_MMA_VECTOR_TYPE(Name, Id, Size) case BuiltinType::Id:
 #include "clang/Basic/PPCTypes.def"
+#define RVV_TYPE(Name, Id, SingletonId) case BuiltinType::Id:
+#include "clang/Basic/RISCVVTypes.def"
 #define BUILTIN_TYPE(Id, SingletonId)
 #define SIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
 #define UNSIGNED_TYPE(Id, SingletonId) case BuiltinType::Id:
Index: clang/test/Sema/riscv-types.c
===
--- /dev/null
+++ clang/test/Sema/riscv-types.c
@@ -0,0 +1,136 @@
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v -ast-print %s \
+// RUN:| FileCheck %s
+
+void bar(void) {
+  // CHECK: __rvv_int64m1_t x0;
+  __rvv_int64m1_t x0;
+
+  // CHECK: __rvv_float64m1_t x1;
+  __rvv_float64m1_t x1;
+
+  // CHECK: __rvv_int64m2_t x2;
+  __rvv_int64m2_t x2;
+
+  // CHECK: __rvv_float64m2_t x3;
+  __rvv_float64m2_t x3;
+
+  // CHECK: __rvv_int64m4_t x4;
+  __rvv_int64m4_t x4;
+
+  // CHECK: __rvv_float64m4_t x5;
+  __rvv_float64m4_t x5;
+
+  // CHECK: __rvv_int64m8_t x6;
+  __rvv_int64m8_t x6;
+
+  // CHECK: __rvv_float64m8_t x7;
+  __rvv_float64m8_t x7;
+
+  // CHECK: __rvv_int32m1_t x8;
+  __rvv_int32m1_t x8;
+
+  // CHECK: __rvv_float32m1_t x9;
+  __rvv_float32m1_t x9;
+
+  // CHECK: __rvv_int32m2_t x10;
+  __rvv_int32m2_t x10;
+
+  // CHECK: __rvv_float32m2_t x11;
+  __rvv_float32m2_t x11;
+
+  // CHECK: __rvv_int32m4_t x12;
+  __rvv_int32m4_t x12;
+
+  // CHECK: __rvv_float32m4_t x13;
+  __rvv_float32m4_t x13;
+
+  // CHECK: __rvv_int32m8_t x14;
+  __rvv_int32m8_t x14;
+
+  // CHECK: __rvv_float32m8_t x15;
+  __rvv_float32m8_t x15;
+
+  // CHECK: __rvv_int16m1_t x16;
+  __rvv_int16m1_t x16;
+
+  // CHECK: __rvv_float16m1_t x17;
+  __rvv_float16m1_t x17;
+
+  // CHECK: __rvv_int16m2_t x18;
+  __rvv_int16m2_t x18;
+
+  // CHECK: __rvv_float16m2_t x19;
+  __rvv_float16m2_t x19;
+
+  // CHECK: __rvv_int16m4_t x20;
+  __rvv_int16m4_t x20;
+
+  // CHECK: __rvv_float16m4_t x21;
+  __rvv_float16m4_t x21;
+
+  // CHECK: __rvv_int16m8_t x22;
+  __rvv_int16m8_t x22;
+
+  // CHECK: __rvv_float16m8_t x23;
+  __rvv_float16m8_t x23;
+
+  // CHECK: __rvv_int8m1_t x24;
+  __rvv_int8m1_t x24;
+
+  // CHECK: __rvv_int8m2_t x25;
+  __rvv_int8m2_t x25;
+
+  // CHECK: __rvv_int8m4_t x26;
+  __rvv_int8m4_t x26;
+
+  // CHECK: __rvv_int8m8_t x27;
+  __rvv_int8m8_t x27;
+
+  // CHECK: __rvv_bool64_t x28;
+  __rvv_bool64_t x28;
+
+  // CHECK: __rvv_bool32_t x29;
+  __rvv_bool32_t x29;
+
+  // CHECK: __rvv_bool16_t x30;
+  __rvv_bool16_t x30;
+
+  // CHECK: __rvv_bool8_t x31;
+  __rvv_bool8_t x31;
+
+  // CHECK: __rvv_bool8_t x32;
+  __rvv_bool8_t x32;
+
+  // CHECK: __rvv_bool8_t x33;
+  __rvv_bool8_t x33;
+
+  // CHECK: __rvv_bool8_t x34;
+  __rvv_bool8_t x34;
+
+  // CHECK: __rvv_int32mf2_t x35;
+  __rvv_int32mf2_t x35;
+
+  // CHECK: __rvv_float32mf2_t x36;
+  __rvv_float32mf2_t x36;
+
+  // CHECK: __rvv_int16mf4_t x37;
+  __rvv_int16mf4_t x37;
+
+  // CHECK: __rvv_float16mf4_t x38;
+  __rvv_float16mf4_t x38;
+
+  // CHECK: __rvv_int16mf2_t x39;
+  __rvv_int16mf2_t x39;
+
+  // 

[PATCH] D92714: Make -fno-pic respect -fno-direct-access-external-data

[Fangrui Song via Phabricator via cfe-commits]

MaskRay created this revision.
MaskRay added reviewers: hjl.tools, rnk, tmsriram.
MaskRay requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

D92633  added 
-f[no-]direct-access-external-data to supersede -m[no-]pie-copy-relocations.
(The option works for -fpie but is a no-op for -fno-pic and -fpic.)

This patch makes -fno-pic -fno-direct-access-external-data drop dso_local from
global variable declarations. This usually causes the backend to emit a GOT
indirection for external data access. With a GOT relocation, the subsequent
-no-pie link will not have copy relocation even if the data symbol turns out to
be defined by a shared object.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92714

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/dso-local-executable.c


Index: clang/test/CodeGen/dso-local-executable.c
===
--- clang/test/CodeGen/dso-local-executable.c
+++ clang/test/CodeGen/dso-local-executable.c
@@ -20,6 +20,8 @@
 // MINGW-DAG: define dso_local i32* @zed()
 // MINGW-DAG: declare dllimport void @import_func()
 
+/// Static relocation model defaults to -fdirect-access-external-data and sets
+/// dso_local on most global objects.
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -mrelocation-model static %s -o - 
| FileCheck --check-prefix=STATIC %s
 // STATIC:  @baz = dso_local global i32 42
 // STATIC-NEXT: @import_var = external dso_local global i32
@@ -31,6 +33,19 @@
 // STATIC-DAG: define dso_local i32* @zed()
 // STATIC-DAG: declare dso_local void @import_func()
 
+/// If -fno-direct-access-external-data is set, drop dso_local from global 
variable
+/// declarations.
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm %s -mrelocation-model static 
-fno-direct-access-external-data -o - | FileCheck 
--check-prefix=STATIC-INDIRECT %s
+// STATIC-INDIRECT:  @baz = dso_local global i32 42
+// STATIC-INDIRECT-NEXT: @import_var = external global i32
+// STATIC-INDIRECT-NEXT: @weak_bar = extern_weak global i32
+// STATIC-INDIRECT-NEXT: @bar = external global i32
+// STATIC-INDIRECT-NEXT: @local_thread_var = dso_local thread_local global i32 
42
+// STATIC-INDIRECT-NEXT: @thread_var = external thread_local global i32
+// STATIC-INDIRECT-DAG: declare dso_local void @import_func()
+// STATIC-INDIRECT-DAG: define dso_local i32* @zed()
+// STATIC-INDIRECT-DAG: declare dso_local void @foo()
+
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-level 1 -pic-is-pie %s -o - 
| FileCheck --check-prefix=PIE %s
 // PIE:  @baz = dso_local global i32 42
 // PIE-NEXT: @import_var = external global i32
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -975,8 +975,7 @@
 
   // If we can use copy relocations we can assume it is local.
   if (auto *Var = dyn_cast(GV))
-if (!Var->isThreadLocal() &&
-(RM == llvm::Reloc::Static || CGOpts.DirectAccessExternalData))
+if (!Var->isThreadLocal() && CGOpts.DirectAccessExternalData)
   return true;
 
   // If we can use a plt entry as the symbol address we can assume it


Index: clang/test/CodeGen/dso-local-executable.c
===
--- clang/test/CodeGen/dso-local-executable.c
+++ clang/test/CodeGen/dso-local-executable.c
@@ -20,6 +20,8 @@
 // MINGW-DAG: define dso_local i32* @zed()
 // MINGW-DAG: declare dllimport void @import_func()
 
+/// Static relocation model defaults to -fdirect-access-external-data and sets
+/// dso_local on most global objects.
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -mrelocation-model static %s -o - | FileCheck --check-prefix=STATIC %s
 // STATIC:  @baz = dso_local global i32 42
 // STATIC-NEXT: @import_var = external dso_local global i32
@@ -31,6 +33,19 @@
 // STATIC-DAG: define dso_local i32* @zed()
 // STATIC-DAG: declare dso_local void @import_func()
 
+/// If -fno-direct-access-external-data is set, drop dso_local from global variable
+/// declarations.
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm %s -mrelocation-model static -fno-direct-access-external-data -o - | FileCheck --check-prefix=STATIC-INDIRECT %s
+// STATIC-INDIRECT:  @baz = dso_local global i32 42
+// STATIC-INDIRECT-NEXT: @import_var = external global i32
+// STATIC-INDIRECT-NEXT: @weak_bar = extern_weak global i32
+// STATIC-INDIRECT-NEXT: @bar = external global i32
+// STATIC-INDIRECT-NEXT: @local_thread_var = dso_local thread_local global i32 42
+// STATIC-INDIRECT-NEXT: @thread_var = external thread_local global i32
+// STATIC-INDIRECT-DAG: declare dso_local void @import_func()
+// STATIC-INDIRECT-DAG: define dso_local i32* @zed()
+// STATIC-INDIRECT-DAG: declare dso_local void @foo()
+
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-level 1 -pic-is-pie %s -o - 

[PATCH] D92617: [DWARF] Allow toolchain to adjust specified DWARF version.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: clang/test/Driver/debug-options.c:364-366
+// GEMBED_2:  warning: debug information option '-gembed-source' is not 
supported for target
 // NOGEMBED_5-NOT:  "-gembed-source"
+// NOGEMBED_2-NOT:  warning: debug information option '-gembed-source' is not 
supported for target

scott.linder wrote:
> tra wrote:
> > scott.linder wrote:
> > > dblaikie wrote:
> > > > This is a bit of a loss in fidelity - might need a new diagnostic 
> > > > message (or go hunting around for a more general purpose one than this 
> > > > one at least) to say '-gembed-source' is ignored when not using 
> > > > DWARFv5. (in the nvptx case it's "not supported on target", but in the 
> > > > existing cases covered by this test it's "not supported because the 
> > > > user requested DWARFv2", for instance)
> > > > 
> > > > @JDevlieghere & @scott.linder for thoughts on this.
> > > I agree that I'd prefer we detect whether the target-specific clamped 
> > > version is to blame (and use the proposed warning message) or the 
> > > original DWARF version is to blame (and use the old message).
> > > 
> > > If I were compiling for x86 and gave e.g. `-gdwarf-4 -gembed-source` and 
> > > the error said "not supported by target" I'd probably get the wrong idea.
> > > 
> > > It would also be nice to retain the error semantics in the case where the 
> > > user is explicitly requesting incompatible options.
> > This sounds pretty close to what the older iterations of this patch did:  
> > https://reviews.llvm.org/D92617?id=309404, except that it preserved the 
> > current behavior which makes it an error to use -gembed-source with an 
> > explicitly specified DWARF version below 5. Same options with a lower 
> > clamped version produces a warning. I.e. If user specified a nominally 
> > valid combination of `-gdwarf-5 -gembed-source` but the target like NVPTX 
> > clamped it down to DWARF2, there will only be a warning.
> > 
> > I would appreciate if you (as in debug info stakeholders) could clarify 
> > couple of moments for me:
> > 
> > * should `-gdwarf-4 -gembed-source` be an error or warning? It's currently 
> > an error.
> > * `-gdwarf-5 -gembed-source` with the dwarf version clamped below 5 should 
> > produce a warning. `not supported for target` appears to be correct, but 
> > does not explain why. Do we want to amend/change it to say `because target 
> > only supports DWARF 2` or `target does not support DWARF 5`? Or is `not 
> > supported by target` sufficient as is?
> > 
> > 
> > This sounds pretty close to what the older iterations of this patch did:  
> > https://reviews.llvm.org/D92617?id=309404, except that it preserved the 
> > current behavior which makes it an error to use -gembed-source with an 
> > explicitly specified DWARF version below 5. Same options with a lower 
> > clamped version produces a warning. I.e. If user specified a nominally 
> > valid combination of `-gdwarf-5 -gembed-source` but the target like NVPTX 
> > clamped it down to DWARF2, there will only be a warning.
> > 
> > I would appreciate if you (as in debug info stakeholders) could clarify 
> > couple of moments for me:
> > 
> > * should `-gdwarf-4 -gembed-source` be an error or warning? It's currently 
> > an error.
> 
> I think it should remain an error when an incompatible DWARF version is 
> explicitly specified by the user. They said they wanted two things which are 
> mutually exclusive, and we have no way to know which one they meant (or if 
> they just aren't aware they are incompatible) so we should stop and prompt 
> them to fix it.
> 
> > * `-gdwarf-5 -gembed-source` with the dwarf version clamped below 5 should 
> > produce a warning. `not supported for target` appears to be correct, but 
> > does not explain why. Do we want to amend/change it to say `because target 
> > only supports DWARF 2` or `target does not support DWARF 5`? Or is `not 
> > supported by target` sufficient as is?
> > 
> > 
> 
> I think giving more context is a good thing in this situation; I don't know 
> that I have a strong opinion on the wording, but something indicating the 
> warning is due to a target restriction which caps the DWARF version seems 
> helpful enough to warrant being more verbose. I'd vote for your `because 
> target only supports DWARF `
> 
OK, sounds like we're going mostly back towards the originally proposed code.

Fair enough - if that's the case I'd make one suggestion to tweak the original 
code:

Rather than keeping DWARFVersion unclamped and having AdjustedDWARFVersion as 
well - It might work better to have DWARFVersion updated correctly (in the "if 
(EmitDwarf)" block) and save "UnadjustedDWARFVersion" (open to other naming 
suggestions) so that vaule can be consulted later to determine the appropriate 
error or warning to be emitted. But this way "DWARFVersion" does carry the 
to-be-emitted DWARF version which is more likely what the next developer to 
touch this 

[PATCH] D92480: [llvm] Add asserts in (ThreadSafe)?RefCountedBase destructors

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: llvm/include/llvm/Support/ManagedStatic.h:25
+// that are const with no params.
+template  struct HasRetainRelease {
+private:

njames93 wrote:
> dblaikie wrote:
> > Are there many uses that rely on this? I don't think it's really worth all 
> > this infrastructure - compared to having it supported on an as-needed 
> > basis, such as directly in TrueMatcherImpl's ctor and dtor.
> It doesn't work in TrueMatcherImpl ctor/dtor due to the whole double free 
> issue(See [[ https://reviews.llvm.org/D92480#inline-864517 | previous comment 
> ]]). I can go back to just supporting it for TrueMatcherImpl by writing a 
> single custom creator/deleter for that class.
> 
> This approach taken was a little overkill but likely a little more foolproof 
> for someone using the library. I'll go ahead with whichever approach you 
> would prefer. 
Ah, right - thanks for walking me through it again, now I better understand 
your previous comment - sorry for that erroneous suggestion/confusion.

Fair points all.

Given all that, I'm sort of leaning towards the idea that maybe the right 
solution here is for the `TrueMatcherInstance` bear the cost of the complexity 
here (if it's the only one) with something like:

```
struct TrueMatcherImplCreator {
  static void *call() {
return new IntrusiveRefCntPtr(new TrueMatcherImpl());  
  }
};
static llvm::ManagedStatic, 
TrueMatcherImplCreator> TrueMatcherInstance;
```

I worry about creating a fairly generic extension point for customizing how 
elements in ManagedStatic can be constructed and destroyed via specialization 
rather than via explicit creator/destroyer parameters.

And while the custom destroyer is a bit simpler mechanically (doesn't involve 
dynamically allocating an IntrusiveCntPtr, which is unintuitive to say the 
least) - I think sticking to the "if you ever share ownership of a 
RefCountedBase object, you must've allocated it with 'new' and be really 
sharing ownership - no lies" is probably a healthier model for 
RefCountedBase/IntrusiveRefCntPtr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92480

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ye-luo wrote:
> > ye-luo wrote:
> > > ABataev wrote:
> > > > ABataev wrote:
> > > > > ye-luo wrote:
> > > > > > ye-luo wrote:
> > > > > > > ye-luo wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > ye-luo wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > > > > grokos wrote:
> > > > > > > > > > > > > > > > > > What is the current status of the order of 
> > > > > > > > > > > > > > > > > > the arguments clang emits? Is it still 
> > > > > > > > > > > > > > > > > > necessary to traverse arguments in reverse 
> > > > > > > > > > > > > > > > > > order here?
> > > > > > > > > > > > > > > > > Yes, still required
> > > > > > > > > > > > > > > > Based on the conversation in
> > > > > > > > > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > > > > > > > > This line of code neither before nor after the 
> > > > > > > > > > > > > > > > change plays well.
> > > > > > > > > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > > > > > > > > This change is part of this patch and cannot be 
> > > > > > > > > > > > > > > committed separately. 
> > > > > > > > > > > > > > I mean could you fix that issue as a parent of this 
> > > > > > > > > > > > > > patch?
> > > > > > > > > > > > > > This change is part of this patch and cannot be 
> > > > > > > > > > > > > > committed separately. 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > If fixing the reordering is part of this patch, I 
> > > > > > > > > > > > > should have seen "target_data_function == 
> > > > > > > > > > > > > targetDataEnd ?" branches disappear.
> > > > > > > > > > > > Nope, just with this patch. It reorders the maps and 
> > > > > > > > > > > > need to change the cleanup order too. 
> > > > > > > > > > > It works just like constructors/destructors: allocate in 
> > > > > > > > > > > direct order, deallocate in reversed to correctly handle 
> > > > > > > > > > > map order. 
> > > > > > > > > > The description says that "present and alloc mappings are 
> > > > > > > > > > processed first and then all others."
> > > > > > > > > > Why the order of arguments in targetDataBegin, 
> > > > > > > > > > targetDataEnd and targetDataUpdate all get reversed.
> > > > > > > > > Because this is for mappers. Mapper maps are ordered by the 
> > > > > > > > > compiler in the direct order (alloc, maps, delete) but when 
> > > > > > > > > we need to do exit, we need to release the data in reversed 
> > > > > > > > > order (deletes, maps, allocs). 
> > > > > > > > I was not making the question clear. My question about 
> > > > > > > > "reverse" is not about having a reverse order for 
> > > > > > > > targetDataBegin. My question was about "reversing" from the the 
> > > > > > > > old code. Your change put the opposite order for 
> > > > > > > > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > > > > > > I was not making the question clear. My question about 
> > > > > > > > "reverse" is not about having a reverse order for 
> > > > > > > > targetDataBegin. My question was about "reversing" from the the 
> > > > > > > > old code. Your change put the opposite order for 
> > > > > > > > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > > > > > 
> > > > > > > typo correction
> > > > > > > I was not making the question clear. My question about "reverse" 
> > > > > > > is not about having a reverse order for **targetDataEnd**. My 
> > > > > > > question was about "reversing" from the the old code. Your change 
> > > > > > > put the opposite order for targetDataBegin, targetDataEnd and 
> > > > > > > targetDataUpdate cases.
> > > > > > My separate question specifically for targetDataEnd is the 
> > > > > > following.
> > > > > > 
> > > > > > In target(), we call
> > > > > > ```
> > > > > > targetDataBegin(args)
> > > > > > {  // forward order
> > > > > >   for (int32_t i = 0; i < arg_num; ++i) { ... }
> > > > > > }
> > > > > > launch_kernels
> > > > > > targetDataEnd(args)
> > > > > > {  // reverse order
> > > > > >   for (int32_t I = ArgNum - 1; I >= 0; --I) { }
> > > > > > }
> > > > > > ```
> > > > > > 
> > > > > > At a mapper,
> > > > > > ```
> > > > > > targetDataMapper
> > > > > > {
> > > > > >   // generate args_reverse in reverse order for targetDataEnd
> > > > > >   targetDataEnd(args_reverse)
> > > > > > }
> > > > > > ```
> > > > > > Are we actually getting the original forward order 

[PATCH] D92650: [RISCV] Define preprocessor definitions for 'V' extension.

[Hsiangkai Wang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5e953a274b2a: [RISCV] Define preprocessor definitions for 
V extension. (authored by HsiangKai).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92650

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/test/Preprocessor/riscv-target-features.c


Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -79,6 +79,14 @@
 // CHECK-DOUBLE-NOT: __riscv_float_abi_soft
 // CHECK-DOUBLE-NOT: __riscv_float_abi_single
 
+// RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN:   -march=rv32iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN:   -march=rv64iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// CHECK-V-EXT: __riscv_vector 1
+//
 // RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions -march=rv32izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions -march=rv64izfh0p1 -x c -E -dM %s \
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -31,12 +31,13 @@
   bool HasD;
   bool HasC;
   bool HasB;
+  bool HasV;
   bool HasZfh;
 
 public:
   RISCVTargetInfo(const llvm::Triple , const TargetOptions &)
   : TargetInfo(Triple), HasM(false), HasA(false), HasF(false), HasD(false),
-HasC(false), HasB(false), HasZfh(false) {
+HasC(false), HasB(false), HasV(false), HasZfh(false) {
 LongDoubleWidth = 128;
 LongDoubleAlign = 128;
 LongDoubleFormat = ::APFloat::IEEEquad();
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -136,6 +136,9 @@
   if (HasB)
 Builder.defineMacro("__riscv_bitmanip");
 
+  if (HasV)
+Builder.defineMacro("__riscv_vector");
+
   if (HasZfh)
 Builder.defineMacro("__riscv_zfh");
 }
@@ -153,6 +156,7 @@
   .Case("d", HasD)
   .Case("c", HasC)
   .Case("experimental-b", HasB)
+  .Case("experimental-v", HasV)
   .Case("experimental-zfh", HasZfh)
   .Default(false);
 }
@@ -173,6 +177,8 @@
   HasC = true;
 else if (Feature == "+experimental-b")
   HasB = true;
+else if (Feature == "+experimental-v")
+  HasV = true;
 else if (Feature == "+experimental-zfh")
   HasZfh = true;
   }


Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -79,6 +79,14 @@
 // CHECK-DOUBLE-NOT: __riscv_float_abi_soft
 // CHECK-DOUBLE-NOT: __riscv_float_abi_single
 
+// RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions \
+// RUN:   -march=rv32iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions \
+// RUN:   -march=rv64iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// CHECK-V-EXT: __riscv_vector 1
+//
 // RUN: %clang -target riscv32-unknown-linux-gnu -menable-experimental-extensions -march=rv32izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu -menable-experimental-extensions -march=rv64izfh0p1 -x c -E -dM %s \
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -31,12 +31,13 @@
   bool HasD;
   bool HasC;
   bool HasB;
+  bool HasV;
   bool HasZfh;
 
 public:
   RISCVTargetInfo(const llvm::Triple , const TargetOptions &)
   : TargetInfo(Triple), HasM(false), HasA(false), HasF(false), HasD(false),
-HasC(false), HasB(false), HasZfh(false) {
+HasC(false), HasB(false), HasV(false), HasZfh(false) {
 LongDoubleWidth = 128;
 LongDoubleAlign = 128;
 LongDoubleFormat = ::APFloat::IEEEquad();
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -136,6 +136,9 @@
   if (HasB)
 Builder.defineMacro("__riscv_bitmanip");
 
+  if (HasV)
+

[clang] 5e953a2 - [RISCV] Define preprocessor definitions for 'V' extension.

[Hsiangkai Wang via cfe-commits]

Author: Hsiangkai Wang
Date: 2020-12-05T08:34:32+08:00
New Revision: 5e953a274b2ada5bfa54b3d765e391abb03f474f

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

LOG: [RISCV] Define preprocessor definitions for 'V' extension.

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

Added: 


Modified: 
clang/lib/Basic/Targets/RISCV.cpp
clang/lib/Basic/Targets/RISCV.h
clang/test/Preprocessor/riscv-target-features.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/RISCV.cpp 
b/clang/lib/Basic/Targets/RISCV.cpp
index 2b076c9c16f2..4436db904d59 100644
--- a/clang/lib/Basic/Targets/RISCV.cpp
+++ b/clang/lib/Basic/Targets/RISCV.cpp
@@ -136,6 +136,9 @@ void RISCVTargetInfo::getTargetDefines(const LangOptions 
,
   if (HasB)
 Builder.defineMacro("__riscv_bitmanip");
 
+  if (HasV)
+Builder.defineMacro("__riscv_vector");
+
   if (HasZfh)
 Builder.defineMacro("__riscv_zfh");
 }
@@ -153,6 +156,7 @@ bool RISCVTargetInfo::hasFeature(StringRef Feature) const {
   .Case("d", HasD)
   .Case("c", HasC)
   .Case("experimental-b", HasB)
+  .Case("experimental-v", HasV)
   .Case("experimental-zfh", HasZfh)
   .Default(false);
 }
@@ -173,6 +177,8 @@ bool 
RISCVTargetInfo::handleTargetFeatures(std::vector ,
   HasC = true;
 else if (Feature == "+experimental-b")
   HasB = true;
+else if (Feature == "+experimental-v")
+  HasV = true;
 else if (Feature == "+experimental-zfh")
   HasZfh = true;
   }

diff  --git a/clang/lib/Basic/Targets/RISCV.h b/clang/lib/Basic/Targets/RISCV.h
index 20a7b1c73175..8430407b041e 100644
--- a/clang/lib/Basic/Targets/RISCV.h
+++ b/clang/lib/Basic/Targets/RISCV.h
@@ -31,12 +31,13 @@ class RISCVTargetInfo : public TargetInfo {
   bool HasD;
   bool HasC;
   bool HasB;
+  bool HasV;
   bool HasZfh;
 
 public:
   RISCVTargetInfo(const llvm::Triple , const TargetOptions &)
   : TargetInfo(Triple), HasM(false), HasA(false), HasF(false), HasD(false),
-HasC(false), HasB(false), HasZfh(false) {
+HasC(false), HasB(false), HasV(false), HasZfh(false) {
 LongDoubleWidth = 128;
 LongDoubleAlign = 128;
 LongDoubleFormat = ::APFloat::IEEEquad();

diff  --git a/clang/test/Preprocessor/riscv-target-features.c 
b/clang/test/Preprocessor/riscv-target-features.c
index c0ffd83bc7e2..d60e7039a92f 100644
--- a/clang/test/Preprocessor/riscv-target-features.c
+++ b/clang/test/Preprocessor/riscv-target-features.c
@@ -79,6 +79,14 @@
 // CHECK-DOUBLE-NOT: __riscv_float_abi_soft
 // CHECK-DOUBLE-NOT: __riscv_float_abi_single
 
+// RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN:   -march=rv32iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions \
+// RUN:   -march=rv64iv0p9 -x c -E -dM %s \
+// RUN:   -o - | FileCheck --check-prefix=CHECK-V-EXT %s
+// CHECK-V-EXT: __riscv_vector 1
+//
 // RUN: %clang -target riscv32-unknown-linux-gnu 
-menable-experimental-extensions -march=rv32izfh0p1 -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-ZFH-EXT %s
 // RUN: %clang -target riscv64-unknown-linux-gnu 
-menable-experimental-extensions -march=rv64izfh0p1 -x c -E -dM %s \



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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ABataev wrote:
> > ye-luo wrote:
> > > ye-luo wrote:
> > > > ye-luo wrote:
> > > > > ABataev wrote:
> > > > > > ye-luo wrote:
> > > > > > > ABataev wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > ye-luo wrote:
> > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > > grokos wrote:
> > > > > > > > > > > > > > > What is the current status of the order of the 
> > > > > > > > > > > > > > > arguments clang emits? Is it still necessary to 
> > > > > > > > > > > > > > > traverse arguments in reverse order here?
> > > > > > > > > > > > > > Yes, still required
> > > > > > > > > > > > > Based on the conversation in
> > > > > > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > > > > > This line of code neither before nor after the change 
> > > > > > > > > > > > > plays well.
> > > > > > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > > > > > This change is part of this patch and cannot be 
> > > > > > > > > > > > committed separately. 
> > > > > > > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > > > separately. 
> > > > > > > > > > 
> > > > > > > > > > If fixing the reordering is part of this patch, I should 
> > > > > > > > > > have seen "target_data_function == targetDataEnd ?" 
> > > > > > > > > > branches disappear.
> > > > > > > > > Nope, just with this patch. It reorders the maps and need to 
> > > > > > > > > change the cleanup order too. 
> > > > > > > > It works just like constructors/destructors: allocate in direct 
> > > > > > > > order, deallocate in reversed to correctly handle map order. 
> > > > > > > The description says that "present and alloc mappings are 
> > > > > > > processed first and then all others."
> > > > > > > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > > > > > > targetDataUpdate all get reversed.
> > > > > > Because this is for mappers. Mapper maps are ordered by the 
> > > > > > compiler in the direct order (alloc, maps, delete) but when we need 
> > > > > > to do exit, we need to release the data in reversed order (deletes, 
> > > > > > maps, allocs). 
> > > > > I was not making the question clear. My question about "reverse" is 
> > > > > not about having a reverse order for targetDataBegin. My question was 
> > > > > about "reversing" from the the old code. Your change put the opposite 
> > > > > order for targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > > > I was not making the question clear. My question about "reverse" is 
> > > > > not about having a reverse order for targetDataBegin. My question was 
> > > > > about "reversing" from the the old code. Your change put the opposite 
> > > > > order for targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > > 
> > > > typo correction
> > > > I was not making the question clear. My question about "reverse" is not 
> > > > about having a reverse order for **targetDataEnd**. My question was 
> > > > about "reversing" from the the old code. Your change put the opposite 
> > > > order for targetDataBegin, targetDataEnd and targetDataUpdate cases.
> > > My separate question specifically for targetDataEnd is the following.
> > > 
> > > In target(), we call
> > > ```
> > > targetDataBegin(args)
> > > {  // forward order
> > >   for (int32_t i = 0; i < arg_num; ++i) { ... }
> > > }
> > > launch_kernels
> > > targetDataEnd(args)
> > > {  // reverse order
> > >   for (int32_t I = ArgNum - 1; I >= 0; --I) { }
> > > }
> > > ```
> > > 
> > > At a mapper,
> > > ```
> > > targetDataMapper
> > > {
> > >   // generate args_reverse in reverse order for targetDataEnd
> > >   targetDataEnd(args_reverse)
> > > }
> > > ```
> > > Are we actually getting the original forward order due to one reverse in 
> > > targetDataMapper and second reverse in targetDataEnd? Is this the desired 
> > > behavior? This part confused me. Do I miss something? Could you explain a 
> > > bit?
> > Yes, something like this. targetDataEnd reverses the order of mapping 
> > arrays. But mapper generator always generates mapping arrays in the direct 
> > order (it fills mapping arrays that later processed by the targetDataEnd 
> > function). We could fix this by passing extra Boolean flag to the generator 
> > function but it means the redesign of the mappers. That's why we have to 
> > reverse it in the libomptarget.
> You can check it yourself. Apply the  patch, restore the original 

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ye-luo wrote:
> > ye-luo wrote:
> > > ye-luo wrote:
> > > > ABataev wrote:
> > > > > ye-luo wrote:
> > > > > > ABataev wrote:
> > > > > > > ABataev wrote:
> > > > > > > > ye-luo wrote:
> > > > > > > > > ye-luo wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > > grokos wrote:
> > > > > > > > > > > > > > What is the current status of the order of the 
> > > > > > > > > > > > > > arguments clang emits? Is it still necessary to 
> > > > > > > > > > > > > > traverse arguments in reverse order here?
> > > > > > > > > > > > > Yes, still required
> > > > > > > > > > > > Based on the conversation in
> > > > > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > > > > This line of code neither before nor after the change 
> > > > > > > > > > > > plays well.
> > > > > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > > > separately. 
> > > > > > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > > separately. 
> > > > > > > > > 
> > > > > > > > > If fixing the reordering is part of this patch, I should have 
> > > > > > > > > seen "target_data_function == targetDataEnd ?" branches 
> > > > > > > > > disappear.
> > > > > > > > Nope, just with this patch. It reorders the maps and need to 
> > > > > > > > change the cleanup order too. 
> > > > > > > It works just like constructors/destructors: allocate in direct 
> > > > > > > order, deallocate in reversed to correctly handle map order. 
> > > > > > The description says that "present and alloc mappings are processed 
> > > > > > first and then all others."
> > > > > > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > > > > > targetDataUpdate all get reversed.
> > > > > Because this is for mappers. Mapper maps are ordered by the compiler 
> > > > > in the direct order (alloc, maps, delete) but when we need to do 
> > > > > exit, we need to release the data in reversed order (deletes, maps, 
> > > > > allocs). 
> > > > I was not making the question clear. My question about "reverse" is not 
> > > > about having a reverse order for targetDataBegin. My question was about 
> > > > "reversing" from the the old code. Your change put the opposite order 
> > > > for targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > > I was not making the question clear. My question about "reverse" is not 
> > > > about having a reverse order for targetDataBegin. My question was about 
> > > > "reversing" from the the old code. Your change put the opposite order 
> > > > for targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > 
> > > typo correction
> > > I was not making the question clear. My question about "reverse" is not 
> > > about having a reverse order for **targetDataEnd**. My question was about 
> > > "reversing" from the the old code. Your change put the opposite order for 
> > > targetDataBegin, targetDataEnd and targetDataUpdate cases.
> > My separate question specifically for targetDataEnd is the following.
> > 
> > In target(), we call
> > ```
> > targetDataBegin(args)
> > {  // forward order
> >   for (int32_t i = 0; i < arg_num; ++i) { ... }
> > }
> > launch_kernels
> > targetDataEnd(args)
> > {  // reverse order
> >   for (int32_t I = ArgNum - 1; I >= 0; --I) { }
> > }
> > ```
> > 
> > At a mapper,
> > ```
> > targetDataMapper
> > {
> >   // generate args_reverse in reverse order for targetDataEnd
> >   targetDataEnd(args_reverse)
> > }
> > ```
> > Are we actually getting the original forward order due to one reverse in 
> > targetDataMapper and second reverse in targetDataEnd? Is this the desired 
> > behavior? This part confused me. Do I miss something? Could you explain a 
> > bit?
> Yes, something like this. targetDataEnd reverses the order of mapping arrays. 
> But mapper generator always generates mapping arrays in the direct order (it 
> fills mapping arrays that later processed by the targetDataEnd function). We 
> could fix this by passing extra Boolean flag to the generator function but it 
> means the redesign of the mappers. That's why we have to reverse it in the 
> libomptarget.
You can check it yourself. Apply the  patch, restore the original behavior in 
libomptarget and run libomptarget tests. Mapper related tests will crash.


Repository:
  rG LLVM Github Monorepo

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ye-luo wrote:
> > ye-luo wrote:
> > > ABataev wrote:
> > > > ye-luo wrote:
> > > > > ABataev wrote:
> > > > > > ABataev wrote:
> > > > > > > ye-luo wrote:
> > > > > > > > ye-luo wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > ye-luo wrote:
> > > > > > > > > > > ABataev wrote:
> > > > > > > > > > > > grokos wrote:
> > > > > > > > > > > > > What is the current status of the order of the 
> > > > > > > > > > > > > arguments clang emits? Is it still necessary to 
> > > > > > > > > > > > > traverse arguments in reverse order here?
> > > > > > > > > > > > Yes, still required
> > > > > > > > > > > Based on the conversation in
> > > > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > > > This line of code neither before nor after the change 
> > > > > > > > > > > plays well.
> > > > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > > separately. 
> > > > > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > separately. 
> > > > > > > > 
> > > > > > > > If fixing the reordering is part of this patch, I should have 
> > > > > > > > seen "target_data_function == targetDataEnd ?" branches 
> > > > > > > > disappear.
> > > > > > > Nope, just with this patch. It reorders the maps and need to 
> > > > > > > change the cleanup order too. 
> > > > > > It works just like constructors/destructors: allocate in direct 
> > > > > > order, deallocate in reversed to correctly handle map order. 
> > > > > The description says that "present and alloc mappings are processed 
> > > > > first and then all others."
> > > > > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > > > > targetDataUpdate all get reversed.
> > > > Because this is for mappers. Mapper maps are ordered by the compiler in 
> > > > the direct order (alloc, maps, delete) but when we need to do exit, we 
> > > > need to release the data in reversed order (deletes, maps, allocs). 
> > > I was not making the question clear. My question about "reverse" is not 
> > > about having a reverse order for targetDataBegin. My question was about 
> > > "reversing" from the the old code. Your change put the opposite order for 
> > > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > > I was not making the question clear. My question about "reverse" is not 
> > > about having a reverse order for targetDataBegin. My question was about 
> > > "reversing" from the the old code. Your change put the opposite order for 
> > > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > 
> > typo correction
> > I was not making the question clear. My question about "reverse" is not 
> > about having a reverse order for **targetDataEnd**. My question was about 
> > "reversing" from the the old code. Your change put the opposite order for 
> > targetDataBegin, targetDataEnd and targetDataUpdate cases.
> My separate question specifically for targetDataEnd is the following.
> 
> In target(), we call
> ```
> targetDataBegin(args)
> {  // forward order
>   for (int32_t i = 0; i < arg_num; ++i) { ... }
> }
> launch_kernels
> targetDataEnd(args)
> {  // reverse order
>   for (int32_t I = ArgNum - 1; I >= 0; --I) { }
> }
> ```
> 
> At a mapper,
> ```
> targetDataMapper
> {
>   // generate args_reverse in reverse order for targetDataEnd
>   targetDataEnd(args_reverse)
> }
> ```
> Are we actually getting the original forward order due to one reverse in 
> targetDataMapper and second reverse in targetDataEnd? Is this the desired 
> behavior? This part confused me. Do I miss something? Could you explain a bit?
Yes, something like this. targetDataEnd reverses the order of mapping arrays. 
But mapper generator always generates mapping arrays in the direct order (it 
fills mapping arrays that later processed by the targetDataEnd function). We 
could fix this by passing extra Boolean flag to the generator function but it 
means the redesign of the mappers. That's why we have to reverse it in the 
libomptarget.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92602: [objc] diagnose protocol conformance in categories with direct members in their corresponding class interfaces

[Alex Lorenz 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 rGdb226cdf4cf9: [objc] diagnose protocol conformance in 
categories with direct members (authored by arphaman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92602

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclObjC.cpp
  clang/test/SemaObjC/category-direct-members-protocol-conformance.m

Index: clang/test/SemaObjC/category-direct-members-protocol-conformance.m
===
--- /dev/null
+++ clang/test/SemaObjC/category-direct-members-protocol-conformance.m
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+__attribute__((objc_root_class))
+@interface RootClass
+
+- (void)baseMethod;
+
+@end
+
+__attribute__((objc_direct_members))
+@interface I : RootClass
+
+- (void)direct; // expected-note {{direct member declared here}}
+
+@end
+
+@protocol P
+- (void)direct;
+@end
+
+@interface I (Cat1)  // expected-error {{category 'Cat1' cannot conform to protocol 'P' because of direct members declared in interface 'I'}}
+@end
+
+@protocol BaseP
+- (void)baseMethod;
+@end
+
+@interface I (CatBase)  // OK
+@end
+
+@protocol P2
+- (void)indirect;
+@end
+
+@interface I (Cat2)  // OK
+- (void)indirect;
+@end
+
+@protocol P3
+- (void)indirect3;
+@end
+
+@interface I (Cat3)  // OK
+@end
+
+@interface ExpDirect : RootClass
+
+- (void)direct __attribute__((objc_direct)); // expected-note {{direct member declared here}}
+
+- (void)directRecursive __attribute__((objc_direct)); // expected-note {{direct member declared here}}
+
+@end
+
+@interface ExpDirect (CatExpDirect)  // expected-error {{category 'CatExpDirect' cannot conform to protocol 'P' because of direct members declared in interface 'ExpDirect'}}
+@end
+
+@protocol PRecursive1
+- (void)directRecursive;
+@end
+
+@protocol PRecursiveTop 
+@end
+
+@interface ExpDirect ()  // expected-error {{class extension cannot conform to protocol 'PRecursive1' because of direct members declared in interface 'ExpDirect'}}
+@end
+
+
+@protocol PProp
+
+@property (nonatomic, readonly) I *name;
+
+@end
+
+__attribute__((objc_direct_members))
+@interface IProp1 : RootClass
+
+@property (nonatomic, readonly) I *name; // expected-note {{direct member declared here}}
+
+@end
+
+@interface IProp1 ()  // expected-error {{class extension cannot conform to protocol 'PProp' because of direct members declared in interface 'IProp1'}}
+@end
+
+
+@protocol PProp2
+
+@property (nonatomic, readonly, class) I *name;
+
+@end
+
+@interface IProp2 : RootClass
+
+@property (nonatomic, readonly, class, direct) I *name; // expected-note {{direct member declared here}}
+
+@end
+
+@interface IProp2 ()  // expected-error {{class extension cannot conform to protocol 'PProp2' because of direct members declared in interface 'IProp2'}}
+@end
Index: clang/lib/Sema/SemaDeclObjC.cpp
===
--- clang/lib/Sema/SemaDeclObjC.cpp
+++ clang/lib/Sema/SemaDeclObjC.cpp
@@ -3912,6 +3912,55 @@
   }
 }
 
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCProtocolDecl *PDecl, ObjCCategoryDecl *CDecl);
+
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCCategoryDecl *CDecl,
+const llvm::iterator_range ) {
+  for (auto *PI : Protocols)
+DiagnoseCategoryDirectMembersProtocolConformance(S, PI, CDecl);
+}
+
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCProtocolDecl *PDecl, ObjCCategoryDecl *CDecl) {
+  if (!PDecl->isThisDeclarationADefinition() && PDecl->getDefinition())
+PDecl = PDecl->getDefinition();
+
+  llvm::SmallVector DirectMembers;
+  const auto *IDecl = CDecl->getClassInterface();
+  for (auto *MD : PDecl->methods()) {
+if (!MD->isPropertyAccessor()) {
+  if (const auto *CMD =
+  IDecl->getMethod(MD->getSelector(), MD->isInstanceMethod())) {
+if (CMD->isDirectMethod())
+  DirectMembers.push_back(CMD);
+  }
+}
+  }
+  for (auto *PD : PDecl->properties()) {
+if (const auto *CPD = IDecl->FindPropertyVisibleInPrimaryClass(
+PD->getIdentifier(),
+PD->isClassProperty()
+? ObjCPropertyQueryKind::OBJC_PR_query_class
+: ObjCPropertyQueryKind::OBJC_PR_query_instance)) {
+  if (CPD->isDirectProperty())
+DirectMembers.push_back(CPD);
+}
+  }
+  if (!DirectMembers.empty()) {
+S.Diag(CDecl->getLocation(), diag::err_objc_direct_protocol_conformance)
+<< CDecl->IsClassExtension() << CDecl << PDecl << IDecl;
+for (const auto *MD : DirectMembers)
+  S.Diag(MD->getLocation(), diag::note_direct_member_here);
+return;
+  }
+
+  // Check on this protocols's referenced protocols, recursively.
+  

[PATCH] D92355: [clang] add a `swift_async_name` attribute

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGeddd1d192bca: [clang] add a `swift_async_name` attribute 
(authored by arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D92355?vs=309582=309690#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92355

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaObjC/attr-swift_name.m
  clang/test/SemaObjCXX/attr-swift_name-cxx.mm

Index: clang/test/SemaObjCXX/attr-swift_name-cxx.mm
===
--- /dev/null
+++ clang/test/SemaObjCXX/attr-swift_name-cxx.mm
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fobjc-arc -fblocks %s
+
+#define SWIFT_ASYNC_NAME(name) __attribute__((__swift_async_name__(name)))
+
+typedef int (^CallbackTy)(void);
+
+class CXXClass {
+public:
+  virtual void doSomethingWithCallback(CallbackTy callback) SWIFT_ASYNC_NAME("doSomething()");
+
+  // expected-warning@+1 {{too few parameters in the signature specified by the '__swift_async_name__' attribute (expected 1; got 0)}}
+  virtual void doSomethingWithCallback(int x, CallbackTy callback) SWIFT_ASYNC_NAME("doSomething()");
+};
Index: clang/test/SemaObjC/attr-swift_name.m
===
--- clang/test/SemaObjC/attr-swift_name.m
+++ clang/test/SemaObjC/attr-swift_name.m
@@ -1,6 +1,7 @@
-// RUN: %clang_cc1 -verify -fsyntax-only -fobjc-arc %s
+// RUN: %clang_cc1 -verify -fsyntax-only -fobjc-arc -fblocks %s
 
 #define SWIFT_NAME(name) __attribute__((__swift_name__(name)))
+#define SWIFT_ASYNC_NAME(name) __attribute__((__swift_async_name__(name)))
 
 typedef struct {
   float x, y, z;
@@ -27,31 +28,31 @@
 // expected-warning@-1 {{'__swift_name__' attribute argument must be a string literal specifying a Swift function name}}
 
 + (I *)iWithAnotherValue:(int)value SWIFT_NAME("i()");
-// expected-warning@-1 {{too few parameters in '__swift_name__' attribute (expected 1; got 0)}}
+// expected-warning@-1 {{too few parameters in the signature specified by the '__swift_name__' attribute (expected 1; got 0)}}
 
 + (I *)iWithYetAnotherValue:(int)value SWIFT_NAME("i(value:extra:)");
-// expected-warning@-1 {{too many parameters in '__swift_name__' attribute (expected 1; got 2}}
+// expected-warning@-1 {{too many parameters in the signature specified by the '__swift_name__' attribute (expected 1; got 2}}
 
 + (I *)iAndReturnErrorCode:(int *)errorCode SWIFT_NAME("i()"); // no-warning
 + (I *)iWithValue:(int)value andReturnErrorCode:(int *)errorCode SWIFT_NAME("i(value:)"); // no-warning
 
 + (I *)iFromErrorCode:(const int *)errorCode SWIFT_NAME("i()");
-// expected-warning@-1 {{too few parameters in '__swift_name__' attribute (expected 1; got 0)}}
+// expected-warning@-1 {{too few parameters in the signature specified by the '__swift_name__' attribute (expected 1; got 0)}}
 
 + (I *)iWithPointerA:(int *)value andReturnErrorCode:(int *)errorCode SWIFT_NAME("i()"); // no-warning
 + (I *)iWithPointerB:(int *)value andReturnErrorCode:(int *)errorCode SWIFT_NAME("i(pointer:)"); // no-warning
 + (I *)iWithPointerC:(int *)value andReturnErrorCode:(int *)errorCode SWIFT_NAME("i(pointer:errorCode:)"); // no-warning
 
 + (I *)iWithOtherI:(I *)other SWIFT_NAME("i()");
-// expected-warning@-1 {{too few parameters in '__swift_name__' attribute (expected 1; got 0)}}
+// expected-warning@-1 {{too few parameters in the signature specified by the '__swift_name__' attribute (expected 1; got 0)}}
 
 + (instancetype)specialI SWIFT_NAME("init(options:)");
 + (instancetype)specialJ SWIFT_NAME("init(options:extra:)");
-// expected-warning@-1 {{too many parameters in '__swift_name__' attribute (expected 0; got 2)}}
+// expected-warning@-1 {{too many parameters in the signature specified by the '__swift_name__' attribute (expected 0; got 2)}}
 + (instancetype)specialK SWIFT_NAME("init(_:)");
-// expected-warning@-1 {{too many parameters in '__swift_name__' attribute (expected 0; got 1)}}
+// expected-warning@-1 {{too many parameters in the signature specified by the '__swift_name__' attribute (expected 0; got 1)}}
 + (instancetype)specialL SWIFT_NAME("i(options:)");
-// expected-warning@-1 {{too many parameters in '__swift_name__' attribute (expected 0; got 1)}}
+// expected-warning@-1 {{too many parameters in the signature specified by the '__swift_name__' attribute (expected 0; got 1)}}
 
 + (instancetype)trailingParen SWIFT_NAME("foo(");
 // expected-warning@-1 {{'__swift_name__' attribute argument must be a string literal specifying a Swift function name}}
@@ -82,10 +83,10 @@
 // expected-warning@-1 {{'__swift_name__' attribute argument must 

[PATCH] D92354: [clang] add a new `swift_attr` attribute

[Alex Lorenz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG03dcd57ecf99: [clang] add a new `swift_attr` attribute 
(authored by arphaman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92354

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/AST/attr-swift_attr.m
  clang/test/SemaObjC/validate-attr-swift_attr.m

Index: clang/test/SemaObjC/validate-attr-swift_attr.m
===
--- /dev/null
+++ clang/test/SemaObjC/validate-attr-swift_attr.m
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+// expected-error@+1 {{'swift_attr' attribute takes one argument}}
+__attribute__((swift_attr))
+@interface I
+@end
+
+// expected-error@+1 {{'swift_attr' attribute requires a string}}
+__attribute__((swift_attr(1)))
+@interface J
+@end
Index: clang/test/AST/attr-swift_attr.m
===
--- /dev/null
+++ clang/test/AST/attr-swift_attr.m
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -fsyntax-only -ast-dump %s | FileCheck %s
+
+__attribute__((swift_attr("@actor")))
+@interface View
+@end
+
+// CHECK: InterfaceDecl {{.*}} View
+// CHECK-NEXT: SwiftAttrAttr {{.*}} "@actor"
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -5607,6 +5607,16 @@
   D->addAttr(::new (S.Context) ObjCPreciseLifetimeAttr(S.Context, AL));
 }
 
+static void handleSwiftAttrAttr(Sema , Decl *D, const ParsedAttr ) {
+  // Make sure that there is a string literal as the annotation's single
+  // argument.
+  StringRef Str;
+  if (!S.checkStringLiteralArgumentAttr(AL, 0, Str))
+return;
+
+  D->addAttr(::new (S.Context) SwiftAttrAttr(S.Context, AL, Str));
+}
+
 static void handleSwiftBridge(Sema , Decl *D, const ParsedAttr ) {
   // Make sure that there is a string literal as the annotation's single
   // argument.
@@ -7941,6 +7951,9 @@
 break;
 
   // Swift attributes.
+  case ParsedAttr::AT_SwiftAttr:
+handleSwiftAttrAttr(S, D, AL);
+break;
   case ParsedAttr::AT_SwiftBridge:
 handleSwiftBridge(S, D, AL);
 break;
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -3628,6 +3628,19 @@
   }];
 }
 
+def SwiftAttrDocs : Documentation {
+  let Category = SwiftDocs;
+  let Heading = "swift_attr";
+  let Content = [{
+The ``swift_attr`` provides a Swift-specific annotation for the declaration
+to which the attribute appertains to. It can be used on any declaration
+in Clang. This kind of annotation is ignored by Clang as it doesn't have any
+semantic meaning in languages supported by Clang. The Swift compiler can
+interpret these annotations according to its own rules when importing C or
+Objective-C declarations.
+}];
+}
+
 def SwiftBridgeDocs : Documentation {
   let Category = SwiftDocs;
   let Heading = "swift_bridge";
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -2149,6 +2149,12 @@
   let ASTNode = 0;
 }
 
+def SwiftAttr : InheritableAttr {
+  let Spellings = [GNU<"swift_attr">];
+  let Args = [StringArgument<"Attribute">];
+  let Documentation = [SwiftAttrDocs];
+}
+
 def SwiftBridge : InheritableAttr {
   let Spellings = [GNU<"swift_bridge">];
   let Args = [StringArgument<"SwiftType">];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] db226cd - [objc] diagnose protocol conformance in categories with direct members

[Alex Lorenz via cfe-commits]

Author: Alex Lorenz
Date: 2020-12-04T15:55:34-08:00
New Revision: db226cdf4cf91f350267da1a5b95dda42dd23413

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

LOG: [objc] diagnose protocol conformance in categories with direct members
in their corresponding class interfaces

Categories that add protocol conformances to classes with direct members should 
prohibit protocol
conformances when the methods/properties that the protocol expects are actually 
declared as 'direct' in the class.

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

Added: 
clang/test/SemaObjC/category-direct-members-protocol-conformance.m

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

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 21660965abf7..01a521fc603e 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1062,6 +1062,10 @@ def warn_objc_direct_property_ignored : Warning<
   InGroup;
 def err_objc_direct_dynamic_property : Error<
   "direct property cannot be @dynamic">;
+def err_objc_direct_protocol_conformance : Error<
+  "%select{category %1|class extension}0 cannot conform to protocol %2 because 
"
+  "of direct members declared in interface %3">;
+def note_direct_member_here : Note<"direct member declared here">;
 
 def warn_conflicting_overriding_ret_types : Warning<
   "conflicting return type in "

diff  --git a/clang/lib/Sema/SemaDeclObjC.cpp b/clang/lib/Sema/SemaDeclObjC.cpp
index a48919685ba2..60253a82e93a 100644
--- a/clang/lib/Sema/SemaDeclObjC.cpp
+++ b/clang/lib/Sema/SemaDeclObjC.cpp
@@ -3912,6 +3912,55 @@ static void DiagnoseVariableSizedIvars(Sema , 
ObjCContainerDecl *OCD) {
   }
 }
 
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCProtocolDecl *PDecl, ObjCCategoryDecl *CDecl);
+
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCCategoryDecl *CDecl,
+const llvm::iterator_range ) {
+  for (auto *PI : Protocols)
+DiagnoseCategoryDirectMembersProtocolConformance(S, PI, CDecl);
+}
+
+static void DiagnoseCategoryDirectMembersProtocolConformance(
+Sema , ObjCProtocolDecl *PDecl, ObjCCategoryDecl *CDecl) {
+  if (!PDecl->isThisDeclarationADefinition() && PDecl->getDefinition())
+PDecl = PDecl->getDefinition();
+
+  llvm::SmallVector DirectMembers;
+  const auto *IDecl = CDecl->getClassInterface();
+  for (auto *MD : PDecl->methods()) {
+if (!MD->isPropertyAccessor()) {
+  if (const auto *CMD =
+  IDecl->getMethod(MD->getSelector(), MD->isInstanceMethod())) {
+if (CMD->isDirectMethod())
+  DirectMembers.push_back(CMD);
+  }
+}
+  }
+  for (auto *PD : PDecl->properties()) {
+if (const auto *CPD = IDecl->FindPropertyVisibleInPrimaryClass(
+PD->getIdentifier(),
+PD->isClassProperty()
+? ObjCPropertyQueryKind::OBJC_PR_query_class
+: ObjCPropertyQueryKind::OBJC_PR_query_instance)) {
+  if (CPD->isDirectProperty())
+DirectMembers.push_back(CPD);
+}
+  }
+  if (!DirectMembers.empty()) {
+S.Diag(CDecl->getLocation(), diag::err_objc_direct_protocol_conformance)
+<< CDecl->IsClassExtension() << CDecl << PDecl << IDecl;
+for (const auto *MD : DirectMembers)
+  S.Diag(MD->getLocation(), diag::note_direct_member_here);
+return;
+  }
+
+  // Check on this protocols's referenced protocols, recursively.
+  DiagnoseCategoryDirectMembersProtocolConformance(S, CDecl,
+   PDecl->protocols());
+}
+
 // Note: For class/category implementations, allMethods is always null.
 Decl *Sema::ActOnAtEnd(Scope *S, SourceRange AtEnd, ArrayRef 
allMethods,
ArrayRef allTUVars) {
@@ -4012,6 +4061,8 @@ Decl *Sema::ActOnAtEnd(Scope *S, SourceRange AtEnd, 
ArrayRef allMethods,
   ObjCInterfaceDecl *CCPrimary = C->getClassInterface();
   DiagnoseClassExtensionDupMethods(C, CCPrimary);
 }
+
+DiagnoseCategoryDirectMembersProtocolConformance(*this, C, C->protocols());
   }
   if (ObjCContainerDecl *CDecl = dyn_cast(ClassDecl)) {
 if (CDecl->getIdentifier())

diff  --git 
a/clang/test/SemaObjC/category-direct-members-protocol-conformance.m 
b/clang/test/SemaObjC/category-direct-members-protocol-conformance.m
new file mode 100644
index ..dfee42f58869
--- /dev/null
+++ b/clang/test/SemaObjC/category-direct-members-protocol-conformance.m
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+__attribute__((objc_root_class))
+@interface RootClass
+
+- (void)baseMethod;
+
+@end
+

[clang] eddd1d1 - [clang] add a `swift_async_name` attribute

[Alex Lorenz via cfe-commits]

Author: Alex Lorenz
Date: 2020-12-04T15:55:29-08:00
New Revision: eddd1d192bcaf11e449b34a3a569b85eb390e4f2

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

LOG: [clang] add a `swift_async_name` attribute

The swift_async_name attribute provides a name for a function/method that can 
be used
to call the async overload of this method from Swift. This name specified in 
this attribute
assumes that the last parameter in the function/method its applied to is 
removed when
Swift invokes it, as the the Swift's await/async transformation implicitly 
constructs the callback.

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

Added: 
clang/test/SemaObjCXX/attr-swift_name-cxx.mm

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test
clang/test/SemaObjC/attr-swift_name.m

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 3beef7b89243..0212b60a2afe 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2149,6 +2149,13 @@ def Regparm : TypeAttr {
   let ASTNode = 0;
 }
 
+def SwiftAsyncName : InheritableAttr {
+  let Spellings = [GNU<"swift_async_name">];
+  let Args = [StringArgument<"Name">];
+  let Subjects = SubjectList<[ObjCMethod, Function], ErrorDiag>;
+  let Documentation = [SwiftAsyncNameDocs];
+}
+
 def SwiftAttr : InheritableAttr {
   let Spellings = [GNU<"swift_attr">];
   let Args = [StringArgument<"Attribute">];

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 673c9553c83d..bf985986e21b 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3628,6 +3628,27 @@ Swift.
   }];
 }
 
+def SwiftAsyncNameDocs : Documentation {
+  let Category = SwiftDocs;
+  let Heading = "swift_async_name";
+  let Content = [{
+The ``swift_async_name`` attribute provides the name of the ``async`` overload 
for
+the given declaration in Swift. If this attribute is absent, the name is
+transformed according to the algorithm built into the Swift compiler.
+
+The argument is a string literal that contains the Swift name of the function 
or
+method. The name may be a compound Swift name. The function or method with such
+an attribute must have more than zero parameters, as its last parameter is
+assumed to be a callback that's eliminated in the Swift ``async`` name.
+
+  .. code-block:: objc
+
+@interface URL
++ (void) loadContentsFrom:(URL *)url callback:(void (^)(NSData *))data 
__attribute__((__swift_async_name__("URL.loadContentsFrom(_:)")))
+@end
+  }];
+}
+
 def SwiftAttrDocs : Documentation {
   let Category = SwiftDocs;
   let Heading = "swift_attr";

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f51ef849b932..21660965abf7 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4028,7 +4028,12 @@ def warn_attr_swift_name_subscript_getter_newValue
   : Warning<"%0 attribute for 'subscript' getter cannot have a 'newValue:' 
parameter">,
 InGroup;
 def warn_attr_swift_name_num_params
-  : Warning<"too %select{few|many}0 parameters in %1 attribute (expected %2; 
got %3)">,
+  : Warning<"too %select{few|many}0 parameters in the signature specified by "
+"the %1 attribute (expected %2; got %3)">,
+InGroup;
+def warn_attr_swift_name_decl_missing_params
+  : Warning<"%0 attribute cannot be applied to a %select{function|method}1 "
+"with no parameters">,
 InGroup;
 
 def err_attr_swift_error_no_error_parameter : Error<

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index b3ede504542f..980be69cb1a5 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1977,7 +1977,7 @@ class Sema final {
   ///
   /// \returns true if the name is a valid swift name for \p D, false 
otherwise.
   bool DiagnoseSwiftName(Decl *D, StringRef Name, SourceLocation Loc,
- const ParsedAttr );
+ const ParsedAttr , bool IsAsync);
 
   /// A derivative of BoundTypeDiagnoser for which the diagnostic's type
   /// parameter is preceded by a 0/1 enum that is 1 if the type is sizeless.

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index e0aa6d1f119c..a3153979deff 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -5922,7 +5922,7 @@ 

[clang] 03dcd57 - [clang] add a new `swift_attr` attribute

[Alex Lorenz via cfe-commits]

Author: Alex Lorenz
Date: 2020-12-04T15:53:24-08:00
New Revision: 03dcd57ecf99b31021644b868cae422897d520f8

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

LOG: [clang] add a new `swift_attr` attribute

The swift_attr attribute is a generic annotation attribute that's not used by 
clang,
but is used by the Swift compiler. The Swift compiler can use these annotations 
to provide
various syntactic and semantic sugars for the imported Objective-C API 
declarations.

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

Added: 
clang/test/AST/attr-swift_attr.m
clang/test/SemaObjC/validate-attr-swift_attr.m

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/lib/Sema/SemaDeclAttr.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 8555bd351747..3beef7b89243 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2149,6 +2149,12 @@ def Regparm : TypeAttr {
   let ASTNode = 0;
 }
 
+def SwiftAttr : InheritableAttr {
+  let Spellings = [GNU<"swift_attr">];
+  let Args = [StringArgument<"Attribute">];
+  let Documentation = [SwiftAttrDocs];
+}
+
 def SwiftBridge : InheritableAttr {
   let Spellings = [GNU<"swift_bridge">];
   let Args = [StringArgument<"SwiftType">];

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 1781543cc4f3..673c9553c83d 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3628,6 +3628,19 @@ Swift.
   }];
 }
 
+def SwiftAttrDocs : Documentation {
+  let Category = SwiftDocs;
+  let Heading = "swift_attr";
+  let Content = [{
+The ``swift_attr`` provides a Swift-specific annotation for the declaration
+to which the attribute appertains to. It can be used on any declaration
+in Clang. This kind of annotation is ignored by Clang as it doesn't have any
+semantic meaning in languages supported by Clang. The Swift compiler can
+interpret these annotations according to its own rules when importing C or
+Objective-C declarations.
+}];
+}
+
 def SwiftBridgeDocs : Documentation {
   let Category = SwiftDocs;
   let Heading = "swift_bridge";

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index d31d18eac474..e0aa6d1f119c 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -5607,6 +5607,16 @@ static void handleObjCPreciseLifetimeAttr(Sema , Decl 
*D,
   D->addAttr(::new (S.Context) ObjCPreciseLifetimeAttr(S.Context, AL));
 }
 
+static void handleSwiftAttrAttr(Sema , Decl *D, const ParsedAttr ) {
+  // Make sure that there is a string literal as the annotation's single
+  // argument.
+  StringRef Str;
+  if (!S.checkStringLiteralArgumentAttr(AL, 0, Str))
+return;
+
+  D->addAttr(::new (S.Context) SwiftAttrAttr(S.Context, AL, Str));
+}
+
 static void handleSwiftBridge(Sema , Decl *D, const ParsedAttr ) {
   // Make sure that there is a string literal as the annotation's single
   // argument.
@@ -7941,6 +7951,9 @@ static void ProcessDeclAttribute(Sema , Scope *scope, 
Decl *D,
 break;
 
   // Swift attributes.
+  case ParsedAttr::AT_SwiftAttr:
+handleSwiftAttrAttr(S, D, AL);
+break;
   case ParsedAttr::AT_SwiftBridge:
 handleSwiftBridge(S, D, AL);
 break;

diff  --git a/clang/test/AST/attr-swift_attr.m 
b/clang/test/AST/attr-swift_attr.m
new file mode 100644
index ..3cd51b81e349
--- /dev/null
+++ b/clang/test/AST/attr-swift_attr.m
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -fsyntax-only -ast-dump %s | FileCheck %s
+
+__attribute__((swift_attr("@actor")))
+@interface View
+@end
+
+// CHECK: InterfaceDecl {{.*}} View
+// CHECK-NEXT: SwiftAttrAttr {{.*}} "@actor"

diff  --git a/clang/test/SemaObjC/validate-attr-swift_attr.m 
b/clang/test/SemaObjC/validate-attr-swift_attr.m
new file mode 100644
index ..4ff434d17972
--- /dev/null
+++ b/clang/test/SemaObjC/validate-attr-swift_attr.m
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+// expected-error@+1 {{'swift_attr' attribute takes one argument}}
+__attribute__((swift_attr))
+@interface I
+@end
+
+// expected-error@+1 {{'swift_attr' attribute requires a string}}
+__attribute__((swift_attr(1)))
+@interface J
+@end



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

[PATCH] D68410: [AttrDocs] document always_inline

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

LGTM




Comment at: clang/include/clang/Basic/AttrDocs.td:4401
+disabled. Does not guarantee that inline substitution actually occurs.
+}];
+  let Heading = "always_inline";

nickdesaulniers wrote:
> lebedev.ri wrote:
> > jdoerfert wrote:
> > > It is more than that. This would imply that with optimizations enabled 
> > > there is no effect. I would mention that the inline heuristic is disabled 
> > > and inlining is always attempted, w/ or w/o optimizations.
> > This comment wasn't addressed.
> I don't follow. I'm not sure if this comment has bit rot?  I think it's 
> critical to mention that `always_inline` does not mean always, as inline 
> substitution MAY fail.
Original text:
> Hint that inline substitution should be attempted when optimizations are
disabled. Does not guarantee that inline substitution actually occurs.


The new text is better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68410

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

[PATCH] D92704: [clangd] Publish config file errors over LSP

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 309688.
sammccall added a comment.

Handle diagnostics without a filename


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92704

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/ConfigProvider.h
  clang-tools-extra/clangd/ConfigYAML.cpp
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/Diagnostics.h
  clang-tools-extra/clangd/test/config.test
  clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
  clang-tools-extra/clangd/unittests/ConfigTesting.h
  clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp

Index: clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
@@ -67,6 +67,7 @@
   )yaml";
   auto Results = Fragment::parseYAML(YAML, "config.yaml", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Files, ElementsAre("config.yaml"));
   ASSERT_EQ(Results.size(), 4u);
   EXPECT_FALSE(Results[0].If.HasUnrecognizedCondition);
   EXPECT_THAT(Results[0].If.PathMatch, ElementsAre(Val("abc")));
Index: clang-tools-extra/clangd/unittests/ConfigTesting.h
===
--- clang-tools-extra/clangd/unittests/ConfigTesting.h
+++ clang-tools-extra/clangd/unittests/ConfigTesting.h
@@ -24,6 +24,12 @@
 struct CapturedDiags {
   std::function callback() {
 return [this](const llvm::SMDiagnostic ) {
+  if (Files.empty() || Files.back() != D.getFilename())
+Files.push_back(D.getFilename().str());
+
+  if (D.getKind() > llvm::SourceMgr::DK_Warning)
+return;
+
   Diagnostics.emplace_back();
   Diag  = Diagnostics.back();
   Out.Message = D.getMessage().str();
@@ -50,7 +56,13 @@
   << D.Message << "@" << llvm::to_string(D.Pos);
 }
   };
-  std::vector Diagnostics;
+  std::vector Diagnostics;  // Warning or higher.
+  std::vector Files; // Filename from diagnostics including notes.
+
+  void clear() {
+Diagnostics.clear();
+Files.clear();
+  }
 };
 
 MATCHER_P(DiagMessage, M, "") { return arg.Message == M; }
Index: clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
@@ -96,21 +96,26 @@
   auto Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
+  EXPECT_THAT(Diags.Files, ElementsAre(testPath("foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo"));
-  Diags.Diagnostics.clear();
+  Diags.clear();
 
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Cached, not re-parsed";
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo"));
 
   FS.Files["foo.yaml"] = AddBarBaz;
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "New config, no errors";
+  EXPECT_THAT(Diags.Files, ElementsAre(testPath("foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("bar", "baz"));
+  Diags.clear();
 
   FS.Files.erase("foo.yaml");
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Missing file is not an error";
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
 }
 
@@ -133,21 +138,26 @@
 
   auto Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
 
   Cfg = P->getConfig(ABCParams, Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
+  EXPECT_THAT(Diags.Files,
+  ElementsAre(testPath("a/foo.yaml"), testPath("a/b/c/foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo", "bar", "baz"));
-  Diags.Diagnostics.clear();
+  Diags.clear();
 
   Cfg = P->getConfig(AParams, Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Cached config";
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo"));
 
   FS.Files.erase("a/foo.yaml");
   Cfg = P->getConfig(ABCParams, Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("bar", "baz"));
 }
 
@@ -169,7 +179,7 @@
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
   EXPECT_THAT(getAddedArgs(Cfg), 

[PATCH] D92704: [clangd] Publish config file errors over LSP

[Sam McCall via Phabricator via cfe-commits]

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

We don't act as a language server for these files (e.g. don't get open/close
notifications for them), but just blindly publish diagnostics for them.

This works reasonably well in coc.nvim and vscode: they show up in the
workspace diagnostic list and when you open the file.
The only update after the file is reparsed, not as you type which is a bit
janky, but seems a lot better than nothing.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92704

Files:
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/ConfigProvider.h
  clang-tools-extra/clangd/ConfigYAML.cpp
  clang-tools-extra/clangd/Diagnostics.cpp
  clang-tools-extra/clangd/Diagnostics.h
  clang-tools-extra/clangd/test/config.test
  clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
  clang-tools-extra/clangd/unittests/ConfigTesting.h
  clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp

Index: clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigYAMLTests.cpp
@@ -67,6 +67,7 @@
   )yaml";
   auto Results = Fragment::parseYAML(YAML, "config.yaml", Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Files, ElementsAre("config.yaml"));
   ASSERT_EQ(Results.size(), 4u);
   EXPECT_FALSE(Results[0].If.HasUnrecognizedCondition);
   EXPECT_THAT(Results[0].If.PathMatch, ElementsAre(Val("abc")));
Index: clang-tools-extra/clangd/unittests/ConfigTesting.h
===
--- clang-tools-extra/clangd/unittests/ConfigTesting.h
+++ clang-tools-extra/clangd/unittests/ConfigTesting.h
@@ -24,6 +24,12 @@
 struct CapturedDiags {
   std::function callback() {
 return [this](const llvm::SMDiagnostic ) {
+  if (Files.empty() || Files.back() != D.getFilename())
+Files.push_back(D.getFilename().str());
+
+  if (D.getKind() > llvm::SourceMgr::DK_Warning)
+return;
+
   Diagnostics.emplace_back();
   Diag  = Diagnostics.back();
   Out.Message = D.getMessage().str();
@@ -50,7 +56,13 @@
   << D.Message << "@" << llvm::to_string(D.Pos);
 }
   };
-  std::vector Diagnostics;
+  std::vector Diagnostics;  // Warning or higher.
+  std::vector Files; // Filename from diagnostics including notes.
+
+  void clear() {
+Diagnostics.clear();
+Files.clear();
+  }
 };
 
 MATCHER_P(DiagMessage, M, "") { return arg.Message == M; }
Index: clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
===
--- clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
+++ clang-tools-extra/clangd/unittests/ConfigProviderTests.cpp
@@ -96,21 +96,26 @@
   auto Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
+  EXPECT_THAT(Diags.Files, ElementsAre(testPath("foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo"));
-  Diags.Diagnostics.clear();
+  Diags.clear();
 
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Cached, not re-parsed";
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo"));
 
   FS.Files["foo.yaml"] = AddBarBaz;
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "New config, no errors";
+  EXPECT_THAT(Diags.Files, ElementsAre(testPath("foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("bar", "baz"));
+  Diags.clear();
 
   FS.Files.erase("foo.yaml");
   Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Missing file is not an error";
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
 }
 
@@ -133,21 +138,26 @@
 
   auto Cfg = P->getConfig(Params(), Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty());
+  EXPECT_THAT(Diags.Files, IsEmpty());
   EXPECT_THAT(getAddedArgs(Cfg), IsEmpty());
 
   Cfg = P->getConfig(ABCParams, Diags.callback());
   EXPECT_THAT(Diags.Diagnostics,
   ElementsAre(DiagMessage("Unknown CompileFlags key Unknown")));
+  EXPECT_THAT(Diags.Files,
+  ElementsAre(testPath("a/foo.yaml"), testPath("a/b/c/foo.yaml")));
   EXPECT_THAT(getAddedArgs(Cfg), ElementsAre("foo", "bar", "baz"));
-  Diags.Diagnostics.clear();
+  Diags.clear();
 
   Cfg = P->getConfig(AParams, Diags.callback());
   EXPECT_THAT(Diags.Diagnostics, IsEmpty()) << "Cached config";
+  

[PATCH] D68410: [AttrDocs] document always_inline

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers added a comment.

Sorry, I should not have waiting this long to update this patch...




Comment at: clang/include/clang/Basic/AttrDocs.td:4401
+disabled. Does not guarantee that inline substitution actually occurs.
+}];
+  let Heading = "always_inline";

lebedev.ri wrote:
> jdoerfert wrote:
> > It is more than that. This would imply that with optimizations enabled 
> > there is no effect. I would mention that the inline heuristic is disabled 
> > and inlining is always attempted, w/ or w/o optimizations.
> This comment wasn't addressed.
I don't follow. I'm not sure if this comment has bit rot?  I think it's 
critical to mention that `always_inline` does not mean always, as inline 
substitution MAY fail.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68410

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

[PATCH] D68410: [AttrDocs] document always_inline

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers updated this revision to Diff 309682.
nickdesaulniers marked an inline comment as done.
nickdesaulniers added a comment.

- rebased, s/Inline/Inlining/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68410

Files:
  clang/include/clang/Basic/Attr.td
  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
@@ -5486,3 +5486,22 @@
 `_ for more information.
   }];
 }
+
+def AlwaysInlineDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Inlining heuristics are disabled and inlining is always attempted regardless of
+optimization level.
+
+Does not guarantee that inline substitution actually occurs.
+
+See also `the MSDN Inline docs`_, `the GCC Common Function Attribute docs`_,
+and `the GCC Inline docs`_.
+
+.. _the MSDN Inline docs: 
https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp
+.. _the GCC Common Function Attribute docs: 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
+.. _the GCC Inline docs: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
+
+}];
+  let Heading = "always_inline, __force_inline";
+}
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -678,7 +678,7 @@
 def AlwaysInline : InheritableAttr {
   let Spellings = [GCC<"always_inline">, Keyword<"__forceinline">];
   let Subjects = SubjectList<[Function]>;
-  let Documentation = [Undocumented];
+  let Documentation = [AlwaysInlineDocs];
 }
 
 def Artificial : InheritableAttr {


Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -5486,3 +5486,22 @@
 `_ for more information.
   }];
 }
+
+def AlwaysInlineDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Inlining heuristics are disabled and inlining is always attempted regardless of
+optimization level.
+
+Does not guarantee that inline substitution actually occurs.
+
+See also `the MSDN Inline docs`_, `the GCC Common Function Attribute docs`_,
+and `the GCC Inline docs`_.
+
+.. _the MSDN Inline docs: https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp
+.. _the GCC Common Function Attribute docs: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
+.. _the GCC Inline docs: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
+
+}];
+  let Heading = "always_inline, __force_inline";
+}
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -678,7 +678,7 @@
 def AlwaysInline : InheritableAttr {
   let Spellings = [GCC<"always_inline">, Keyword<"__forceinline">];
   let Subjects = SubjectList<[Function]>;
-  let Documentation = [Undocumented];
+  let Documentation = [AlwaysInlineDocs];
 }
 
 def Artificial : InheritableAttr {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ye-luo wrote:
> > ABataev wrote:
> > > ye-luo wrote:
> > > > ABataev wrote:
> > > > > ABataev wrote:
> > > > > > ye-luo wrote:
> > > > > > > ye-luo wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > ye-luo wrote:
> > > > > > > > > > ABataev wrote:
> > > > > > > > > > > grokos wrote:
> > > > > > > > > > > > What is the current status of the order of the 
> > > > > > > > > > > > arguments clang emits? Is it still necessary to 
> > > > > > > > > > > > traverse arguments in reverse order here?
> > > > > > > > > > > Yes, still required
> > > > > > > > > > Based on the conversation in
> > > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > > This line of code neither before nor after the change plays 
> > > > > > > > > > well.
> > > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > > separately. 
> > > > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > separately. 
> > > > > > > 
> > > > > > > If fixing the reordering is part of this patch, I should have 
> > > > > > > seen "target_data_function == targetDataEnd ?" branches disappear.
> > > > > > Nope, just with this patch. It reorders the maps and need to change 
> > > > > > the cleanup order too. 
> > > > > It works just like constructors/destructors: allocate in direct 
> > > > > order, deallocate in reversed to correctly handle map order. 
> > > > The description says that "present and alloc mappings are processed 
> > > > first and then all others."
> > > > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > > > targetDataUpdate all get reversed.
> > > Because this is for mappers. Mapper maps are ordered by the compiler in 
> > > the direct order (alloc, maps, delete) but when we need to do exit, we 
> > > need to release the data in reversed order (deletes, maps, allocs). 
> > I was not making the question clear. My question about "reverse" is not 
> > about having a reverse order for targetDataBegin. My question was about 
> > "reversing" from the the old code. Your change put the opposite order for 
> > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> > I was not making the question clear. My question about "reverse" is not 
> > about having a reverse order for targetDataBegin. My question was about 
> > "reversing" from the the old code. Your change put the opposite order for 
> > targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> 
> typo correction
> I was not making the question clear. My question about "reverse" is not about 
> having a reverse order for **targetDataEnd**. My question was about 
> "reversing" from the the old code. Your change put the opposite order for 
> targetDataBegin, targetDataEnd and targetDataUpdate cases.
My separate question specifically for targetDataEnd is the following.

In target(), we call
```
targetDataBegin(args)
{  // forward order
  for (int32_t i = 0; i < arg_num; ++i) { ... }
}
launch_kernels
targetDataEnd(args)
{  // reverse order
  for (int32_t I = ArgNum - 1; I >= 0; --I) { }
}
```

At a mapper,
```
targetDataMapper
{
  // generate args_reverse in reverse order for targetDataEnd
  targetDataEnd(args_reverse)
}
```
Are we actually getting the original forward order due to one reverse in 
targetDataMapper and second reverse in targetDataEnd? Is this the desired 
behavior? This part confused me. Do I miss something? Could you explain a bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:235-239
+  for (const auto  : Options) {
+std::string Val = HNOption.General.lookup(Opt.first);
+if (Val.empty())
+  HNOption.General.insert({Opt.first, Opt.second.str()});
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:244-248
+  for (const auto  : DerivedTypes) {
+std::string Val = HNOption.DerivedType.lookup(Other.first);
+if (Val.empty())
+  HNOption.DerivedType.insert({Other.first, Other.second.str()});
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:256-260
+  for (const auto  : CStrings) {
+std::string Val = HNOption.CString.lookup(CStr.first);
+if (Val.empty())
+  HNOption.CString.insert({CStr.first, CStr.second.str()});
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:308-312
+  for (const auto  : PrimitiveTypes) {
+std::string Val = HNOption.PrimitiveType.lookup(Type.first);
+if (Val.empty())
+  HNOption.PrimitiveType.insert({Type.first, Type.second.str()});
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:347-348
+  for (const auto  : UserDefinedTypes) {
+std::string Val = HNOption.UserDefinedType.lookup(Type.first);
+if (Val.empty())
+  HNOption.UserDefinedType.insert({Type.first, Type.second.str()});





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:366
+if (!Val.empty())
+  HNOption.General[Opt] = Val;
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:373
+if (!Val.empty())
+  HNOption.DerivedType[Type] = Val;
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:386
+if (!Val.empty())
+  HNOption.CString[CStr.first] = Val;
+  }





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:392-401
+std::string Type = PrimType.str();
+if (!Val.empty()) {
+  if (Type.find('-') != std::string::npos) {
+for (size_t I = 0; I < Type.length(); ++I) {
+  if (Type[I] == '-')
+Type.replace(I, 1, " ");
+}





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:407-409
+std::string Type = WDType.str();
+if (!Val.empty())
+  HNOption.UserDefinedType[Type] = Val;





Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h:124-125
   const bool IgnoreFailedSplit;
+
+  IdentifierNamingCheck::HungarianNotationOption HNOption;
 };

This should be part of the `FileStyle` struct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ABataev wrote:
> > ye-luo wrote:
> > > ABataev wrote:
> > > > ABataev wrote:
> > > > > ye-luo wrote:
> > > > > > ye-luo wrote:
> > > > > > > ABataev wrote:
> > > > > > > > ye-luo wrote:
> > > > > > > > > ABataev wrote:
> > > > > > > > > > grokos wrote:
> > > > > > > > > > > What is the current status of the order of the arguments 
> > > > > > > > > > > clang emits? Is it still necessary to traverse arguments 
> > > > > > > > > > > in reverse order here?
> > > > > > > > > > Yes, still required
> > > > > > > > > Based on the conversation in
> > > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > > This line of code neither before nor after the change plays 
> > > > > > > > > well.
> > > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > > separately. 
> > > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > separately. 
> > > > > > 
> > > > > > If fixing the reordering is part of this patch, I should have seen 
> > > > > > "target_data_function == targetDataEnd ?" branches disappear.
> > > > > Nope, just with this patch. It reorders the maps and need to change 
> > > > > the cleanup order too. 
> > > > It works just like constructors/destructors: allocate in direct order, 
> > > > deallocate in reversed to correctly handle map order. 
> > > The description says that "present and alloc mappings are processed first 
> > > and then all others."
> > > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > > targetDataUpdate all get reversed.
> > Because this is for mappers. Mapper maps are ordered by the compiler in the 
> > direct order (alloc, maps, delete) but when we need to do exit, we need to 
> > release the data in reversed order (deletes, maps, allocs). 
> I was not making the question clear. My question about "reverse" is not about 
> having a reverse order for targetDataBegin. My question was about "reversing" 
> from the the old code. Your change put the opposite order for 
> targetDataBegin, targetDataEnd and targetDataUpdate cases. 
> I was not making the question clear. My question about "reverse" is not about 
> having a reverse order for targetDataBegin. My question was about "reversing" 
> from the the old code. Your change put the opposite order for 
> targetDataBegin, targetDataEnd and targetDataUpdate cases. 

typo correction
I was not making the question clear. My question about "reverse" is not about 
having a reverse order for **targetDataEnd**. My question was about "reversing" 
from the the old code. Your change put the opposite order for targetDataBegin, 
targetDataEnd and targetDataUpdate cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ye-luo wrote:
> > ABataev wrote:
> > > ABataev wrote:
> > > > ye-luo wrote:
> > > > > ye-luo wrote:
> > > > > > ABataev wrote:
> > > > > > > ye-luo wrote:
> > > > > > > > ABataev wrote:
> > > > > > > > > grokos wrote:
> > > > > > > > > > What is the current status of the order of the arguments 
> > > > > > > > > > clang emits? Is it still necessary to traverse arguments in 
> > > > > > > > > > reverse order here?
> > > > > > > > > Yes, still required
> > > > > > > > Based on the conversation in
> > > > > > > > https://reviews.llvm.org/D85216
> > > > > > > > This line of code neither before nor after the change plays 
> > > > > > > > well.
> > > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > > This change is part of this patch and cannot be committed 
> > > > > > > separately. 
> > > > > > I mean could you fix that issue as a parent of this patch?
> > > > > > This change is part of this patch and cannot be committed 
> > > > > > separately. 
> > > > > 
> > > > > If fixing the reordering is part of this patch, I should have seen 
> > > > > "target_data_function == targetDataEnd ?" branches disappear.
> > > > Nope, just with this patch. It reorders the maps and need to change the 
> > > > cleanup order too. 
> > > It works just like constructors/destructors: allocate in direct order, 
> > > deallocate in reversed to correctly handle map order. 
> > The description says that "present and alloc mappings are processed first 
> > and then all others."
> > Why the order of arguments in targetDataBegin, targetDataEnd and 
> > targetDataUpdate all get reversed.
> Because this is for mappers. Mapper maps are ordered by the compiler in the 
> direct order (alloc, maps, delete) but when we need to do exit, we need to 
> release the data in reversed order (deletes, maps, allocs). 
I was not making the question clear. My question about "reverse" is not about 
having a reverse order for targetDataBegin. My question was about "reversing" 
from the the old code. Your change put the opposite order for targetDataBegin, 
targetDataEnd and targetDataUpdate cases. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92699: Frontend: Migrate to FileEntryRef in VerifyDiagnosticConsumer.cpp, NFC

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

dexonsmith created this revision.
dexonsmith added reviewers: arphaman, JDevlieghere, jansvoboda11.
Herald added a subscriber: ributzka.
dexonsmith requested review of this revision.
Herald added a project: clang.

Add a `FileEntryRef` overload of `SourceManager::translateFile`, and
migrate `ParseDirective` in VerifyDiagnosticConsumer.cpp to use it and
the corresponding overload of `createFileID`.

No functionality change here.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92699

Files:
  clang/include/clang/Basic/SourceManager.h
  clang/lib/Frontend/VerifyDiagnosticConsumer.cpp


Index: clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
===
--- clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
+++ clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
@@ -554,10 +554,9 @@
 continue;
   }
 
-  const FileEntry *FE = >getFileEntry();
-  FileID FID = SM.translateFile(FE);
+  FileID FID = SM.translateFile(*File);
   if (FID.isInvalid())
-FID = SM.createFileID(FE, Pos, SrcMgr::C_User);
+FID = SM.createFileID(*File, Pos, SrcMgr::C_User);
 
   if (PH.Next(Line) && Line > 0)
 ExpectedLoc = SM.translateLineCol(FID, Line, 1);
Index: clang/include/clang/Basic/SourceManager.h
===
--- clang/include/clang/Basic/SourceManager.h
+++ clang/include/clang/Basic/SourceManager.h
@@ -1593,6 +1593,9 @@
   /// If the source file is included multiple times, the FileID will be the
   /// first inclusion.
   FileID translateFile(const FileEntry *SourceFile) const;
+  FileID translateFile(FileEntryRef SourceFile) const {
+return translateFile(());
+  }
 
   /// Get the source location in \p FID for the given line:col.
   /// Returns null location if \p FID is not a file SLocEntry.


Index: clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
===
--- clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
+++ clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
@@ -554,10 +554,9 @@
 continue;
   }
 
-  const FileEntry *FE = >getFileEntry();
-  FileID FID = SM.translateFile(FE);
+  FileID FID = SM.translateFile(*File);
   if (FID.isInvalid())
-FID = SM.createFileID(FE, Pos, SrcMgr::C_User);
+FID = SM.createFileID(*File, Pos, SrcMgr::C_User);
 
   if (PH.Next(Line) && Line > 0)
 ExpectedLoc = SM.translateLineCol(FID, Line, 1);
Index: clang/include/clang/Basic/SourceManager.h
===
--- clang/include/clang/Basic/SourceManager.h
+++ clang/include/clang/Basic/SourceManager.h
@@ -1593,6 +1593,9 @@
   /// If the source file is included multiple times, the FileID will be the
   /// first inclusion.
   FileID translateFile(const FileEntry *SourceFile) const;
+  FileID translateFile(FileEntryRef SourceFile) const {
+return translateFile(());
+  }
 
   /// Get the source location in \p FID for the given line:col.
   /// Returns null location if \p FID is not a file SLocEntry.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ABataev wrote:
> > ABataev wrote:
> > > ye-luo wrote:
> > > > ye-luo wrote:
> > > > > ABataev wrote:
> > > > > > ye-luo wrote:
> > > > > > > ABataev wrote:
> > > > > > > > grokos wrote:
> > > > > > > > > What is the current status of the order of the arguments 
> > > > > > > > > clang emits? Is it still necessary to traverse arguments in 
> > > > > > > > > reverse order here?
> > > > > > > > Yes, still required
> > > > > > > Based on the conversation in
> > > > > > > https://reviews.llvm.org/D85216
> > > > > > > This line of code neither before nor after the change plays well.
> > > > > > > Shall we fix the order in targetDataEnd first?
> > > > > > This change is part of this patch and cannot be committed 
> > > > > > separately. 
> > > > > I mean could you fix that issue as a parent of this patch?
> > > > > This change is part of this patch and cannot be committed separately. 
> > > > 
> > > > If fixing the reordering is part of this patch, I should have seen 
> > > > "target_data_function == targetDataEnd ?" branches disappear.
> > > Nope, just with this patch. It reorders the maps and need to change the 
> > > cleanup order too. 
> > It works just like constructors/destructors: allocate in direct order, 
> > deallocate in reversed to correctly handle map order. 
> The description says that "present and alloc mappings are processed first and 
> then all others."
> Why the order of arguments in targetDataBegin, targetDataEnd and 
> targetDataUpdate all get reversed.
Because this is for mappers. Mapper maps are ordered by the compiler in the 
direct order (alloc, maps, delete) but when we need to do exit, we need to 
release the data in reversed order (deletes, maps, allocs). 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[clang] d126943 - Index: Remove unused internal header SimpleFormatContext.h, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-12-04T15:10:27-08:00
New Revision: d126943251d0cd77e572bced5ab6c23595acd468

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

LOG: Index: Remove unused internal header SimpleFormatContext.h, NFC

Looks like nothing has included this header since
d21485d2f5ffacf7b726c741ee409b3682045255 / r286279 in 2016. Delete the
dead code.

Added: 


Modified: 
clang/lib/Index/CMakeLists.txt
llvm/utils/gn/secondary/clang/lib/Index/BUILD.gn

Removed: 
clang/lib/Index/SimpleFormatContext.h



diff  --git a/clang/lib/Index/CMakeLists.txt b/clang/lib/Index/CMakeLists.txt
index 68ebb5b7ede3..68c689b01969 100644
--- a/clang/lib/Index/CMakeLists.txt
+++ b/clang/lib/Index/CMakeLists.txt
@@ -16,7 +16,6 @@ add_clang_library(clangIndex
 
   ADDITIONAL_HEADERS
   IndexingContext.h
-  SimpleFormatContext.h
 
   LINK_LIBS
   clangAST

diff  --git a/clang/lib/Index/SimpleFormatContext.h 
b/clang/lib/Index/SimpleFormatContext.h
deleted file mode 100644
index 17793154a3ae..
--- a/clang/lib/Index/SimpleFormatContext.h
+++ /dev/null
@@ -1,72 +0,0 @@
-//===--- SimpleFormatContext.h --*- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-//
-/// \file
-///
-/// Defines a utility class for use of clang-format in libclang
-//
-//===--===//
-
-#ifndef LLVM_CLANG_LIB_INDEX_SIMPLEFORMATCONTEXT_H
-#define LLVM_CLANG_LIB_INDEX_SIMPLEFORMATCONTEXT_H
-
-#include "clang/Basic/Diagnostic.h"
-#include "clang/Basic/DiagnosticOptions.h"
-#include "clang/Basic/FileManager.h"
-#include "clang/Basic/LangOptions.h"
-#include "clang/Basic/SourceManager.h"
-#include "clang/Rewrite/Core/Rewriter.h"
-#include "llvm/Support/FileSystem.h"
-#include "llvm/Support/Path.h"
-#include "llvm/Support/raw_ostream.h"
-
-namespace clang {
-namespace index {
-
-/// A small class to be used by libclang clients to format
-/// a declaration string in memory. This object is instantiated once
-/// and used each time a formatting is needed.
-class SimpleFormatContext {
-public:
-  SimpleFormatContext(LangOptions Options)
-  : DiagOpts(new DiagnosticOptions()),
-Diagnostics(new DiagnosticsEngine(new DiagnosticIDs, DiagOpts.get())),
-InMemoryFileSystem(new llvm::vfs::InMemoryFileSystem),
-Files(FileSystemOptions(), InMemoryFileSystem),
-Sources(*Diagnostics, Files), Rewrite(Sources, Options) {
-Diagnostics->setClient(new IgnoringDiagConsumer, true);
-  }
-
-  FileID createInMemoryFile(StringRef Name, StringRef Content) {
-InMemoryFileSystem->addFile(Name, 0,
-llvm::MemoryBuffer::getMemBuffer(Content));
-const FileEntry *Entry = Files.getFile(Name);
-assert(Entry != nullptr);
-return Sources.createFileID(Entry, SourceLocation(), SrcMgr::C_User);
-  }
-
-  std::string getRewrittenText(FileID ID) {
-std::string Result;
-llvm::raw_string_ostream OS(Result);
-Rewrite.getEditBuffer(ID).write(OS);
-OS.flush();
-return Result;
-  }
-
-  IntrusiveRefCntPtr DiagOpts;
-  IntrusiveRefCntPtr Diagnostics;
-  IntrusiveRefCntPtr InMemoryFileSystem;
-  FileManager Files;
-  SourceManager Sources;
-  Rewriter Rewrite;
-};
-
-} // end namespace index
-} // end namespace clang
-
-#endif

diff  --git a/llvm/utils/gn/secondary/clang/lib/Index/BUILD.gn 
b/llvm/utils/gn/secondary/clang/lib/Index/BUILD.gn
index ef15a55ff9d3..942b4047b8b5 100644
--- a/llvm/utils/gn/secondary/clang/lib/Index/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/lib/Index/BUILD.gn
@@ -22,7 +22,6 @@ static_library("Index") {
 "IndexingAction.cpp",
 "IndexingContext.cpp",
 "IndexingContext.h",
-"SimpleFormatContext.h",
 "USRGeneration.cpp",
   ]
 }



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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ABataev wrote:
> > ye-luo wrote:
> > > ye-luo wrote:
> > > > ABataev wrote:
> > > > > ye-luo wrote:
> > > > > > ABataev wrote:
> > > > > > > grokos wrote:
> > > > > > > > What is the current status of the order of the arguments clang 
> > > > > > > > emits? Is it still necessary to traverse arguments in reverse 
> > > > > > > > order here?
> > > > > > > Yes, still required
> > > > > > Based on the conversation in
> > > > > > https://reviews.llvm.org/D85216
> > > > > > This line of code neither before nor after the change plays well.
> > > > > > Shall we fix the order in targetDataEnd first?
> > > > > This change is part of this patch and cannot be committed separately. 
> > > > I mean could you fix that issue as a parent of this patch?
> > > > This change is part of this patch and cannot be committed separately. 
> > > 
> > > If fixing the reordering is part of this patch, I should have seen 
> > > "target_data_function == targetDataEnd ?" branches disappear.
> > Nope, just with this patch. It reorders the maps and need to change the 
> > cleanup order too. 
> It works just like constructors/destructors: allocate in direct order, 
> deallocate in reversed to correctly handle map order. 
The description says that "present and alloc mappings are processed first and 
then all others."
Why the order of arguments in targetDataBegin, targetDataEnd and 
targetDataUpdate all get reversed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92078: [asan] Default to -asan-use-private-alias=1

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp:4-5
 
-// RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared %s -o %dynamiclib1
-// RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared %s -o %dynamiclib2
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib1
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib2
 // RUN: %clangxx_asan -fno-rtti %s %ld_flags_rpath_exe1 %ld_flags_rpath_exe2 
-o %t

vitalybuka wrote:
> Is this going to work?
Yes. -asan-use-odr-indicator=1 adds a named global symbol which can detect such 
issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92078

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

[PATCH] D92078: [asan] Default to -asan-use-private-alias=1

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 309675.
MaskRay marked 6 inline comments as done.
MaskRay edited the summary of this revision.
MaskRay added a comment.

Pre-committed test improvement in 190b4374c00a9cf090ea73f9eddf3d8f71b11ec8 

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92078

Files:
  clang/test/CodeGen/asan-globals-odr.cpp
  clang/test/CodeGen/asan-static-odr.cpp
  compiler-rt/test/asan/TestCases/Linux/odr-violation.cpp
  compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/local_alias.ll

Index: llvm/test/Instrumentation/AddressSanitizer/local_alias.ll
===
--- llvm/test/Instrumentation/AddressSanitizer/local_alias.ll
+++ llvm/test/Instrumentation/AddressSanitizer/local_alias.ll
@@ -1,6 +1,6 @@
 ; Defaults
-; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -S | FileCheck %s --check-prefixes=CHECK-NOALIAS,CHECK-NOINDICATOR
-; RUN: opt < %s -passes='asan-pipeline' -S | FileCheck %s --check-prefixes=CHECK-NOALIAS,CHECK-NOINDICATOR
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -S | FileCheck %s --check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
+; RUN: opt < %s -passes='asan-pipeline' -S | FileCheck %s --check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
 
 ; {newPM,legacyPM} x {alias0,alias1} x {odr0,odr1}
 ; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=0 -asan-use-odr-indicator=0 -S | FileCheck %s --check-prefixes=CHECK-NOALIAS,CHECK-NOINDICATOR
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -363,7 +363,7 @@
 static cl::opt
 ClUsePrivateAlias("asan-use-private-alias",
   cl::desc("Use private aliases for global variables"),
-  cl::Hidden, cl::init(false));
+  cl::Hidden, cl::init(true));
 
 static cl::opt
 ClUseOdrIndicator("asan-use-odr-indicator",
Index: compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
===
--- compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
+++ compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp
@@ -10,11 +10,11 @@
 // RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared -mllvm -asan-use-odr-indicator=1 %s -o %dynamiclib2
 // RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=2 not %run %t 2>&1 | FileCheck %s
 
-/// By default we can detect ODR issues in vtables.
+/// By default we cannot detect ODR issues in vtables.
 // RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared %s -o %dynamiclib1
 // RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared %s -o %dynamiclib2
 // RUN: %clangxx_asan -fno-rtti %s %ld_flags_rpath_exe1 %ld_flags_rpath_exe2 -o %t
-// RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=2 not %run %t 2>&1 | FileCheck %s
+// RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=2 %run %t 2>&1 | count 0
 
 struct XYZ {
   virtual void foo();
Index: compiler-rt/test/asan/TestCases/Linux/odr-violation.cpp
===
--- compiler-rt/test/asan/TestCases/Linux/odr-violation.cpp
+++ compiler-rt/test/asan/TestCases/Linux/odr-violation.cpp
@@ -6,16 +6,18 @@
 // We use fast_unwind_on_malloc=0 to have full unwinding even w/o frame
 // pointers. This setting is not on by default because it's too expensive.
 //
+// Note, -asan-use-private-alias=1 -asan-use-odr-indicator=0 is the default.
+//
 // Different size: detect a bug if detect_odr_violation>=1
-// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared %s -o %dynamiclib
-// RUN: %clangxx_asan %s %ld_flags_rpath_exe -o %t-ODR-EXE
+// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared -mllvm -asan-use-private-alias=0 %s -o %dynamiclib
+// RUN: %clangxx_asan -mllvm -asan-use-private-alias=0 %s %ld_flags_rpath_exe -o %t-ODR-EXE
 // RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=1 not %run %t-ODR-EXE 2>&1 | FileCheck %s
 // RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=2 not %run %t-ODR-EXE 2>&1 | FileCheck %s
 // RUN: %env_asan_opts=fast_unwind_on_malloc=0:detect_odr_violation=0 %run %t-ODR-EXE 2>&1 | FileCheck %s --check-prefix=DISABLED
 // RUN: %env_asan_opts=fast_unwind_on_malloc=0not %run %t-ODR-EXE 2>&1 | FileCheck %s
 //
 // Same size: report a bug only if detect_odr_violation>=2.
-// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared %s -o %dynamiclib -DSZ=100
+// RUN: %clangxx_asan -DBUILD_SO=1 -fPIC -shared -mllvm -asan-use-private-alias=0 %s -o %dynamiclib -DSZ=100
 // 

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

[Renato Golin via Phabricator via cfe-commits]

rengolin added inline comments.



Comment at: clang/include/clang/Driver/Options.td:164
+def m_m68k_Features_Group: OptionGroup<"">,
+ Group, DocName<"M68k">;
 def m_mips_Features_Group : OptionGroup<"">,

craig.topper wrote:
> bruno wrote:
> > Looks like this is missing `clang-format`?
> I don't think clang-format really understands tablegen files.
It does not. Don't clang-format table-gen files, the end result is horrendous. 
:)


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

https://reviews.llvm.org/D88394

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

[PATCH] D92671: Add diagnostic for for-range-declaration being specificed with thread_local

[Shafik Yaghmour via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6333871f8540: Add diagnostic for for-range-declaration being 
specificed with thread_local (authored by shafik).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92671

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp


Index: clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
===
--- clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
+++ clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
@@ -151,6 +151,7 @@
 
   for (extern int a : A()) {} // expected-error {{loop variable 'a' may not be 
declared 'extern'}}
   for (static int a : A()) {} // expected-error {{loop variable 'a' may not be 
declared 'static'}}
+  for (thread_local int a : A()) {} // expected-error {{loop variable 'a' may 
not be declared 'thread_local'}}
   for (register int a : A()) {} // expected-error {{loop variable 'a' may not 
be declared 'register'}} expected-warning 0-1{{register}} expected-error 
0-1{{register}}
   for (constexpr int a : X::C()) {} // OK per CWG issue #1204.
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12782,6 +12782,18 @@
 Error = 4;
 break;
   }
+
+  // for-range-declaration cannot be given a storage class specifier con't.
+  switch (VD->getTSCSpec()) {
+  case TSCS_thread_local:
+Error = 6;
+break;
+  case TSCS___thread:
+  case TSCS__Thread_local:
+  case TSCS_unspecified:
+break;
+  }
+
   if (Error != -1) {
 Diag(VD->getOuterLocStart(), diag::err_for_range_storage_class)
 << VD << Error;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2448,7 +2448,7 @@
   "for range declaration must declare a variable">;
 def err_for_range_storage_class : Error<
   "loop variable %0 may not be declared %select{'extern'|'static'|"
-  "'__private_extern__'|'auto'|'register'|'constexpr'}1">;
+  "'__private_extern__'|'auto'|'register'|'constexpr'|'thread_local'}1">;
 def err_type_defined_in_for_range : Error<
   "types may not be defined in a for range declaration">;
 def err_for_range_deduction_failure : Error<


Index: clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
===
--- clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
+++ clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
@@ -151,6 +151,7 @@
 
   for (extern int a : A()) {} // expected-error {{loop variable 'a' may not be declared 'extern'}}
   for (static int a : A()) {} // expected-error {{loop variable 'a' may not be declared 'static'}}
+  for (thread_local int a : A()) {} // expected-error {{loop variable 'a' may not be declared 'thread_local'}}
   for (register int a : A()) {} // expected-error {{loop variable 'a' may not be declared 'register'}} expected-warning 0-1{{register}} expected-error 0-1{{register}}
   for (constexpr int a : X::C()) {} // OK per CWG issue #1204.
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12782,6 +12782,18 @@
 Error = 4;
 break;
   }
+
+  // for-range-declaration cannot be given a storage class specifier con't.
+  switch (VD->getTSCSpec()) {
+  case TSCS_thread_local:
+Error = 6;
+break;
+  case TSCS___thread:
+  case TSCS__Thread_local:
+  case TSCS_unspecified:
+break;
+  }
+
   if (Error != -1) {
 Diag(VD->getOuterLocStart(), diag::err_for_range_storage_class)
 << VD << Error;
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2448,7 +2448,7 @@
   "for range declaration must declare a variable">;
 def err_for_range_storage_class : Error<
   "loop variable %0 may not be declared %select{'extern'|'static'|"
-  "'__private_extern__'|'auto'|'register'|'constexpr'}1">;
+  "'__private_extern__'|'auto'|'register'|'constexpr'|'thread_local'}1">;
 def err_type_defined_in_for_range : Error<
   "types may not be defined in a for range declaration">;
 def err_for_range_deduction_failure : Error<
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 6333871 - Add diagnostic for for-range-declaration being specificed with thread_local

[via cfe-commits]

Author: shafik
Date: 2020-12-04T15:06:35-08:00
New Revision: 6333871f85403d07abc62fdb6182f288ff60ccd8

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

LOG: Add diagnostic for for-range-declaration being specificed with thread_local

Currently we have a diagnostic that catches the other storage class specifies 
for the range based for loop declaration but we miss the thread_local case. 
This changes adds a diagnostic for that case as well.

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 23f374987c92..f51ef849b932 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2448,7 +2448,7 @@ def err_for_range_decl_must_be_var : Error<
   "for range declaration must declare a variable">;
 def err_for_range_storage_class : Error<
   "loop variable %0 may not be declared %select{'extern'|'static'|"
-  "'__private_extern__'|'auto'|'register'|'constexpr'}1">;
+  "'__private_extern__'|'auto'|'register'|'constexpr'|'thread_local'}1">;
 def err_type_defined_in_for_range : Error<
   "types may not be defined in a for range declaration">;
 def err_for_range_deduction_failure : Error<

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index dc11dacb2491..0031f874c05a 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -12782,6 +12782,18 @@ void Sema::ActOnCXXForRangeDecl(Decl *D) {
 Error = 4;
 break;
   }
+
+  // for-range-declaration cannot be given a storage class specifier con't.
+  switch (VD->getTSCSpec()) {
+  case TSCS_thread_local:
+Error = 6;
+break;
+  case TSCS___thread:
+  case TSCS__Thread_local:
+  case TSCS_unspecified:
+break;
+  }
+
   if (Error != -1) {
 Diag(VD->getOuterLocStart(), diag::err_for_range_storage_class)
 << VD << Error;

diff  --git a/clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp 
b/clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
index 7c95a3ca88eb..1c6aeeefe006 100644
--- a/clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
+++ b/clang/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
@@ -151,6 +151,7 @@ void g() {
 
   for (extern int a : A()) {} // expected-error {{loop variable 'a' may not be 
declared 'extern'}}
   for (static int a : A()) {} // expected-error {{loop variable 'a' may not be 
declared 'static'}}
+  for (thread_local int a : A()) {} // expected-error {{loop variable 'a' may 
not be declared 'thread_local'}}
   for (register int a : A()) {} // expected-error {{loop variable 'a' may not 
be declared 'register'}} expected-warning 0-1{{register}} expected-error 
0-1{{register}}
   for (constexpr int a : X::C()) {} // OK per CWG issue #1204.
 



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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ye-luo wrote:
> > ye-luo wrote:
> > > ABataev wrote:
> > > > ye-luo wrote:
> > > > > ABataev wrote:
> > > > > > grokos wrote:
> > > > > > > What is the current status of the order of the arguments clang 
> > > > > > > emits? Is it still necessary to traverse arguments in reverse 
> > > > > > > order here?
> > > > > > Yes, still required
> > > > > Based on the conversation in
> > > > > https://reviews.llvm.org/D85216
> > > > > This line of code neither before nor after the change plays well.
> > > > > Shall we fix the order in targetDataEnd first?
> > > > This change is part of this patch and cannot be committed separately. 
> > > I mean could you fix that issue as a parent of this patch?
> > > This change is part of this patch and cannot be committed separately. 
> > 
> > If fixing the reordering is part of this patch, I should have seen 
> > "target_data_function == targetDataEnd ?" branches disappear.
> Nope, just with this patch. It reorders the maps and need to change the 
> cleanup order too. 
It works just like constructors/destructors: allocate in direct order, 
deallocate in reversed to correctly handle map order. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92661: [RFC] Fix TLS and Coroutine

[Xun Li via Phabricator via cfe-commits]

lxfind added inline comments.



Comment at: llvm/include/llvm/IR/Intrinsics.td:1309
+// Intrinsic to obtain the address of a thread_local variable.
+def int_threadlocal : Intrinsic<[llvm_ptr_ty], [llvm_ptr_ty]>;
+

hoy wrote:
> lxfind wrote:
> > hoy wrote:
> > > hoy wrote:
> > > > With the intrinsic, can TLS variable reference in the same coroutine or 
> > > > regular routine be DCE-ed anymore?
> > > Sorry, I meant CSE-ed.
> > Since the intrinsics does not have readnone attribute, it won't be CSE-ed 
> > before CoroSplit.
> > However after CoroSplit, it will be lowered back to the direct reference of 
> > the TLS, and will be CSE-ed by latter passes.
> > I can add a test function to demonstrate that too.
> Sounds good. Can you please point out what optimization passes CSE-ed tls 
> reference without this implementation? I'm wondering if those optimizations 
> can be postponed to after CoroSplit. 
To clarify, it wasn't just CSE that would merge the references of the same TLS.
For instance, without this patch, a reference to "tls_variable" will just be 
"@tls_variable". For code like this:

  @tls_variable = internal thread_local global i32 0, align 4

  define i32* @foo(){
ret i32* @tls_variable
  }
  
  define void @bar() {
%tls1 = call i32* @foo()
..coro.suspend..
%tls2 = call i32* @foo()
%cond = icmp eq i32* %tls1, %tls2
  }

When foo() is inlined into bar(), all uses of %tls1 will be replaced with 
@tls_variable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92661

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ye-luo wrote:
> > ABataev wrote:
> > > ye-luo wrote:
> > > > ABataev wrote:
> > > > > grokos wrote:
> > > > > > What is the current status of the order of the arguments clang 
> > > > > > emits? Is it still necessary to traverse arguments in reverse order 
> > > > > > here?
> > > > > Yes, still required
> > > > Based on the conversation in
> > > > https://reviews.llvm.org/D85216
> > > > This line of code neither before nor after the change plays well.
> > > > Shall we fix the order in targetDataEnd first?
> > > This change is part of this patch and cannot be committed separately. 
> > I mean could you fix that issue as a parent of this patch?
> > This change is part of this patch and cannot be committed separately. 
> 
> If fixing the reordering is part of this patch, I should have seen 
> "target_data_function == targetDataEnd ?" branches disappear.
Nope, just with this patch. It reorders the maps and need to change the cleanup 
order too. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ABataev wrote:
> > ye-luo wrote:
> > > ABataev wrote:
> > > > grokos wrote:
> > > > > What is the current status of the order of the arguments clang emits? 
> > > > > Is it still necessary to traverse arguments in reverse order here?
> > > > Yes, still required
> > > Based on the conversation in
> > > https://reviews.llvm.org/D85216
> > > This line of code neither before nor after the change plays well.
> > > Shall we fix the order in targetDataEnd first?
> > This change is part of this patch and cannot be committed separately. 
> I mean could you fix that issue as a parent of this patch?
> This change is part of this patch and cannot be committed separately. 

If fixing the reordering is part of this patch, I should have seen 
"target_data_function == targetDataEnd ?" branches disappear.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D91974: [PowerPC] Rename the vector pair intrinsics and builtins to replace the _mma_ prefix by _vsx_

[Amy Kwan via Phabricator via cfe-commits]

amyk accepted this revision as: amyk.
amyk added a comment.
This revision is now accepted and ready to land.

Just a minor comment but LGTM overall.




Comment at: llvm/test/CodeGen/PowerPC/paired-vector-intrinsics.ll:15
+
+; This test is to check that the paired vector intrinsics are available even
+

Unfinished comment?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91974

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

[clang] b4f4fc6 - ASTImporter: Migrate to the FileEntryRef overload of SourceManager::createFileID, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-12-04T14:45:59-08:00
New Revision: b4f4fc6872fbe4e296d3270d297a0e4afbda6670

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

LOG: ASTImporter: Migrate to the FileEntryRef overload of 
SourceManager::createFileID, NFC

Migrate `ASTImporter::Import` over to using the `FileEntryRef` overload
of `SourceManager::createFileID`. No functionality change here.

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

Added: 


Modified: 
clang/lib/AST/ASTImporter.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index a74e316f688e6..50632efc281ff 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -8719,7 +8719,7 @@ Expected ASTImporter::Import(FileID FromID, bool 
IsBuiltin) {
 // FIXME: We definitely want to re-use the existing MemoryBuffer, 
rather
 // than mmap the files several times.
 auto Entry =
-ToFileManager.getFile(Cache->OrigEntry->getName());
+ToFileManager.getOptionalFileRef(Cache->OrigEntry->getName());
 // FIXME: The filename may be a virtual name that does probably not
 // point to a valid file and we get no Entry here. In this case try 
with
 // the memory buffer below.



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

[PATCH] D92529: ASTImporter: Migrate to the FileEntryRef overload of SourceManager::createFileID, NFC

[Duncan P. N. Exon Smith 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 rGb4f4fc6872fb: ASTImporter: Migrate to the FileEntryRef 
overload of SourceManager… (authored by dexonsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92529

Files:
  clang/lib/AST/ASTImporter.cpp


Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -8719,7 +8719,7 @@
 // FIXME: We definitely want to re-use the existing MemoryBuffer, 
rather
 // than mmap the files several times.
 auto Entry =
-ToFileManager.getFile(Cache->OrigEntry->getName());
+ToFileManager.getOptionalFileRef(Cache->OrigEntry->getName());
 // FIXME: The filename may be a virtual name that does probably not
 // point to a valid file and we get no Entry here. In this case try 
with
 // the memory buffer below.


Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -8719,7 +8719,7 @@
 // FIXME: We definitely want to re-use the existing MemoryBuffer, rather
 // than mmap the files several times.
 auto Entry =
-ToFileManager.getFile(Cache->OrigEntry->getName());
+ToFileManager.getOptionalFileRef(Cache->OrigEntry->getName());
 // FIXME: The filename may be a virtual name that does probably not
 // point to a valid file and we get no Entry here. In this case try with
 // the memory buffer below.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D91819: [PowerPC] Enable paired vector type and intrinsics when MMA is disabled

[Amy Kwan via Phabricator via cfe-commits]

amyk added inline comments.



Comment at: clang/lib/AST/ASTContext.cpp:1427
+  if (Target.getTriple().isPPC64() &&
+  Target.hasFeature("paired-vector-memops")) {
+if (Target.hasFeature("mma")) {

Is it better to do `hasFeature()` over `PairedVectorMemops` and `HasMMA`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91819

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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> ye-luo wrote:
> > ABataev wrote:
> > > grokos wrote:
> > > > What is the current status of the order of the arguments clang emits? 
> > > > Is it still necessary to traverse arguments in reverse order here?
> > > Yes, still required
> > Based on the conversation in
> > https://reviews.llvm.org/D85216
> > This line of code neither before nor after the change plays well.
> > Shall we fix the order in targetDataEnd first?
> This change is part of this patch and cannot be committed separately. 
I mean could you fix that issue as a parent of this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92597: ARCMigrate: Initialize fields in EditEntry inline, NFC

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

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9ae0a46f2bbf: ARCMigrate: Initialize fields in EditEntry 
inline, NFC (authored by dexonsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92597

Files:
  clang/lib/ARCMigrate/ObjCMT.cpp


Index: clang/lib/ARCMigrate/ObjCMT.cpp
===
--- clang/lib/ARCMigrate/ObjCMT.cpp
+++ clang/lib/ARCMigrate/ObjCMT.cpp
@@ -2034,12 +2034,10 @@
 
 namespace {
 struct EditEntry {
-  const FileEntry *File;
-  unsigned Offset;
-  unsigned RemoveLen;
+  const FileEntry *File = nullptr;
+  unsigned Offset = 0;
+  unsigned RemoveLen = 0;
   std::string Text;
-
-  EditEntry() : File(), Offset(), RemoveLen() {}
 };
 } // end anonymous namespace
 


Index: clang/lib/ARCMigrate/ObjCMT.cpp
===
--- clang/lib/ARCMigrate/ObjCMT.cpp
+++ clang/lib/ARCMigrate/ObjCMT.cpp
@@ -2034,12 +2034,10 @@
 
 namespace {
 struct EditEntry {
-  const FileEntry *File;
-  unsigned Offset;
-  unsigned RemoveLen;
+  const FileEntry *File = nullptr;
+  unsigned Offset = 0;
+  unsigned RemoveLen = 0;
   std::string Text;
-
-  EditEntry() : File(), Offset(), RemoveLen() {}
 };
 } // end anonymous namespace
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 9ae0a46 - ARCMigrate: Initialize fields in EditEntry inline, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-12-04T14:43:22-08:00
New Revision: 9ae0a46f2bbff5c0eb962c5a6225a2b469d1802f

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

LOG: ARCMigrate: Initialize fields in EditEntry inline, NFC

Initialize the fields inline instead of having to manually write out a
default constructor.

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

Added: 


Modified: 
clang/lib/ARCMigrate/ObjCMT.cpp

Removed: 




diff  --git a/clang/lib/ARCMigrate/ObjCMT.cpp b/clang/lib/ARCMigrate/ObjCMT.cpp
index 51c4a460cc25..ef2985d16d23 100644
--- a/clang/lib/ARCMigrate/ObjCMT.cpp
+++ b/clang/lib/ARCMigrate/ObjCMT.cpp
@@ -2034,12 +2034,10 @@ MigrateSourceAction::CreateASTConsumer(CompilerInstance 
, StringRef InFile) {
 
 namespace {
 struct EditEntry {
-  const FileEntry *File;
-  unsigned Offset;
-  unsigned RemoveLen;
+  const FileEntry *File = nullptr;
+  unsigned Offset = 0;
+  unsigned RemoveLen = 0;
   std::string Text;
-
-  EditEntry() : File(), Offset(), RemoveLen() {}
 };
 } // end anonymous namespace
 



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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ye-luo wrote:
> ABataev wrote:
> > grokos wrote:
> > > What is the current status of the order of the arguments clang emits? Is 
> > > it still necessary to traverse arguments in reverse order here?
> > Yes, still required
> Based on the conversation in
> https://reviews.llvm.org/D85216
> This line of code neither before nor after the change plays well.
> Shall we fix the order in targetDataEnd first?
This change is part of this patch and cannot be committed separately. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[clang] 1b023f5 - Frontend: Use translateLineCol instead of translateFileLineCol, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-12-04T14:37:48-08:00
New Revision: 1b023f54b61737552242868bdfc385487f1c3e74

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

LOG: Frontend: Use translateLineCol instead of translateFileLineCol, NFC

`ParseDirective` in VerifyDiagnosticConsumer.cpp is already calling
`translateFile`, so use the `FileID` returned by that to call
`translateLineCol` instead of using the more heavyweight
`translateFileLineCol`.

No functionality change here.

Added: 


Modified: 
clang/lib/Frontend/VerifyDiagnosticConsumer.cpp

Removed: 




diff  --git a/clang/lib/Frontend/VerifyDiagnosticConsumer.cpp 
b/clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
index 35f95ecfec68..a10a3dd8a446 100644
--- a/clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
+++ b/clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
@@ -555,14 +555,15 @@ static bool ParseDirective(StringRef S, ExpectedData *ED, 
SourceManager ,
   }
 
   const FileEntry *FE = >getFileEntry();
-  if (SM.translateFile(FE).isInvalid())
-SM.createFileID(FE, Pos, SrcMgr::C_User);
+  FileID FID = SM.translateFile(FE);
+  if (FID.isInvalid())
+FID = SM.createFileID(FE, Pos, SrcMgr::C_User);
 
   if (PH.Next(Line) && Line > 0)
-ExpectedLoc = SM.translateFileLineCol(FE, Line, 1);
+ExpectedLoc = SM.translateLineCol(FID, Line, 1);
   else if (PH.Next("*")) {
 MatchAnyLine = true;
-ExpectedLoc = SM.translateFileLineCol(FE, 1, 1);
+ExpectedLoc = SM.translateLineCol(FID, 1, 1);
   }
 }
   } else if (PH.Next("*")) {



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

[PATCH] D86119: [OPENMP50]Allow overlapping mapping in target constrcuts.

[Ye Luo via Phabricator via cfe-commits]

ye-luo added inline comments.



Comment at: openmp/libomptarget/src/omptarget.cpp:233
 MapperComponents
-.Components[target_data_function == targetDataEnd ? I : E - I - 1];
+.Components[target_data_function == targetDataEnd ? E - I - 1 : I];
 MapperArgsBase[I] = C.Base;

ABataev wrote:
> grokos wrote:
> > What is the current status of the order of the arguments clang emits? Is it 
> > still necessary to traverse arguments in reverse order here?
> Yes, still required
Based on the conversation in
https://reviews.llvm.org/D85216
This line of code neither before nor after the change plays well.
Shall we fix the order in targetDataEnd first?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86119

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

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 309661.
njames93 added a comment.

Update bugprone-not-null-terminated-result incorrect option name


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-argument-comment.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-misplaced-widening-cast.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-reserved-identifier.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-signed-char-misuse.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-sizeof-expression.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-string-constructor.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-string-compare.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-special-member-functions.rst
  clang-tools-extra/docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-definitions-in-headers.rst
  
clang-tools-extra/docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-unused-parameters.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-avoid-bind.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-make-shared.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-make-unique.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-pass-by-value.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-auto.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-bool-literals.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-default-member-init.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-emplace.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-equals-default.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-equals-delete.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-noexcept.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-override.rst
  
clang-tools-extra/docs/clang-tidy/checks/modernize-use-transparent-functors.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-using.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-for-range-copy.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-move-const-arg.rst
  clang-tools-extra/docs/clang-tidy/checks/portability-simd-intrinsics.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-implicit-bool-conversion.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-qualified-auto.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-access-specifiers.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-redundant-declaration.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-smartptr-get.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst

Index: clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
@@ -52,5 +52,5 @@
 
 .. option:: IgnoreMacros
 
-   If this option is set to non-zero (default is `1`), the check will not warn
+   If this option is set to `true` (default is `true`), the check will not warn
about literal suffixes inside macros.
Index: clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
@@ -77,10 +77,10 @@
 
 .. option:: ChainedConditionalReturn
 
-   If non-zero, conditional boolean return statements 

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Nathan James via Phabricator via cfe-commits]

njames93 removed a subscriber: Charusso.
njames93 added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst:60
 - If copy to the destination array can overflow [1] and
-  ``AreSafeFunctionsAvailable`` is set to ``Yes``, ``y`` or non-zero and it is
+  ``AreSafeFunctionsAvailable`` is set to `true` and it is
   possible to obtain the capacity of the destination array then the new 
function

Charusso wrote:
> aaron.ballman wrote:
> > njames93 wrote:
> > > aaron.ballman wrote:
> > > > This edit loses information about also accepting `Yes` and `y` -- is 
> > > > that intentional (or were those unsupported before)?
> > > > 
> > > > FWIW, I'd be fine dropping support for alternate spellings of `true`.
> > > Having looked throughout the NotNullTerminatedResultCheck header/impl 
> > > files, I can't find any reference to `AreSafeFunctionsAvailable`.
> > > I can only guess this is meant to say WantToUseSafeFunctions. If that is 
> > > the case, `Yes` and `y` were never supported spellings.
> > > 
> > > Should this be changed to use that option name instead? cc @Charusso
> > > 
> > > FWIW I intend (in the near future) to extend boolean parsing for check 
> > > options to:
> > > `y|Y|yes|Yes|YES|true|True|TRUE|on|On|ON`
> > > `n|N|no|No|NO|false|False|FALSE|off|Off|OFF`.
> > > 
> > > Reason for this is we claim to use YAML for config format and according 
> > > to its specification, this is what is accepted as a boolean value. Ref 
> > > https://yaml.org/type/bool.html.
> > > Still need to keep the old integer method of specifying bools for 
> > > backwards compatibility reasons.
> > > 
> > > Should this be changed to use that option name instead? cc @Charusso
> > 
> > I think so, but that can be done in an NFC followup if you'd like.
> > 
> > > Reason for this is we claim to use YAML for config format and according 
> > > to its specification, this is what is accepted as a boolean value.
> > 
> > Oh, that's a good reason to support those spellings, thank you for 
> > clarifying.
> Hey, nice catch and cool patch! Sorry for the extra work. 
> `WantToUseSafeFunctions` is wanted to be here as a zero or non-zero value 
> [1]. It would be great if you could rewrite this variable name because I do 
> not write LLVM code any more. Thanks!
> 
> [1] 
> https://clang.llvm.org/extra/clang-tidy/checks/bugprone-not-null-terminated-result.html#options
No worries, I just wanted to make sure that was your initial intention :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

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

[PATCH] D92617: [DWARF] Allow toolchain to adjust specified DWARF version.

[Scott Linder via Phabricator via cfe-commits]

scott.linder added inline comments.



Comment at: clang/test/Driver/debug-options.c:364-366
+// GEMBED_2:  warning: debug information option '-gembed-source' is not 
supported for target
 // NOGEMBED_5-NOT:  "-gembed-source"
+// NOGEMBED_2-NOT:  warning: debug information option '-gembed-source' is not 
supported for target

tra wrote:
> scott.linder wrote:
> > dblaikie wrote:
> > > This is a bit of a loss in fidelity - might need a new diagnostic message 
> > > (or go hunting around for a more general purpose one than this one at 
> > > least) to say '-gembed-source' is ignored when not using DWARFv5. (in the 
> > > nvptx case it's "not supported on target", but in the existing cases 
> > > covered by this test it's "not supported because the user requested 
> > > DWARFv2", for instance)
> > > 
> > > @JDevlieghere & @scott.linder for thoughts on this.
> > I agree that I'd prefer we detect whether the target-specific clamped 
> > version is to blame (and use the proposed warning message) or the original 
> > DWARF version is to blame (and use the old message).
> > 
> > If I were compiling for x86 and gave e.g. `-gdwarf-4 -gembed-source` and 
> > the error said "not supported by target" I'd probably get the wrong idea.
> > 
> > It would also be nice to retain the error semantics in the case where the 
> > user is explicitly requesting incompatible options.
> This sounds pretty close to what the older iterations of this patch did:  
> https://reviews.llvm.org/D92617?id=309404, except that it preserved the 
> current behavior which makes it an error to use -gembed-source with an 
> explicitly specified DWARF version below 5. Same options with a lower clamped 
> version produces a warning. I.e. If user specified a nominally valid 
> combination of `-gdwarf-5 -gembed-source` but the target like NVPTX clamped 
> it down to DWARF2, there will only be a warning.
> 
> I would appreciate if you (as in debug info stakeholders) could clarify 
> couple of moments for me:
> 
> * should `-gdwarf-4 -gembed-source` be an error or warning? It's currently an 
> error.
> * `-gdwarf-5 -gembed-source` with the dwarf version clamped below 5 should 
> produce a warning. `not supported for target` appears to be correct, but does 
> not explain why. Do we want to amend/change it to say `because target only 
> supports DWARF 2` or `target does not support DWARF 5`? Or is `not supported 
> by target` sufficient as is?
> 
> 
> This sounds pretty close to what the older iterations of this patch did:  
> https://reviews.llvm.org/D92617?id=309404, except that it preserved the 
> current behavior which makes it an error to use -gembed-source with an 
> explicitly specified DWARF version below 5. Same options with a lower clamped 
> version produces a warning. I.e. If user specified a nominally valid 
> combination of `-gdwarf-5 -gembed-source` but the target like NVPTX clamped 
> it down to DWARF2, there will only be a warning.
> 
> I would appreciate if you (as in debug info stakeholders) could clarify 
> couple of moments for me:
> 
> * should `-gdwarf-4 -gembed-source` be an error or warning? It's currently an 
> error.

I think it should remain an error when an incompatible DWARF version is 
explicitly specified by the user. They said they wanted two things which are 
mutually exclusive, and we have no way to know which one they meant (or if they 
just aren't aware they are incompatible) so we should stop and prompt them to 
fix it.

> * `-gdwarf-5 -gembed-source` with the dwarf version clamped below 5 should 
> produce a warning. `not supported for target` appears to be correct, but does 
> not explain why. Do we want to amend/change it to say `because target only 
> supports DWARF 2` or `target does not support DWARF 5`? Or is `not supported 
> by target` sufficient as is?
> 
> 

I think giving more context is a good thing in this situation; I don't know 
that I have a strong opinion on the wording, but something indicating the 
warning is due to a target restriction which caps the DWARF version seems 
helpful enough to warrant being more verbose. I'd vote for your `because target 
only supports DWARF `



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92617

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

[PATCH] D92480: [llvm] Add asserts in (ThreadSafe)?RefCountedBase destructors

[Nathan James via Phabricator via cfe-commits]

njames93 marked 6 inline comments as done and 2 inline comments as done.
njames93 added inline comments.



Comment at: llvm/include/llvm/Support/ManagedStatic.h:25
+// that are const with no params.
+template  struct HasRetainRelease {
+private:

dblaikie wrote:
> Are there many uses that rely on this? I don't think it's really worth all 
> this infrastructure - compared to having it supported on an as-needed basis, 
> such as directly in TrueMatcherImpl's ctor and dtor.
It doesn't work in TrueMatcherImpl ctor/dtor due to the whole double free 
issue(See [[ https://reviews.llvm.org/D92480#inline-864517 | previous comment 
]]). I can go back to just supporting it for TrueMatcherImpl by writing a 
single custom creator/deleter for that class.

This approach taken was a little overkill but likely a little more foolproof 
for someone using the library. I'll go ahead with whichever approach you would 
prefer. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92480

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

[PATCH] D88393: [cfe][M68k] (Patch 7/8) Basic Clang support

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a reviewer: bruno.
bruno accepted this revision.
bruno added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D88393

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

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/include/clang/Driver/Options.td:164
+def m_m68k_Features_Group: OptionGroup<"">,
+ Group, DocName<"M68k">;
 def m_mips_Features_Group : OptionGroup<"">,

bruno wrote:
> Looks like this is missing `clang-format`?
I don't think clang-format really understands tablegen files.


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

https://reviews.llvm.org/D88394

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

[PATCH] D88394: [Driver][M68k] (Patch 8/8) Add driver support for M68k

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added a reviewer: bruno.
bruno added inline comments.



Comment at: clang/include/clang/Driver/Options.td:164
+def m_m68k_Features_Group: OptionGroup<"">,
+ Group, DocName<"M68k">;
 def m_mips_Features_Group : OptionGroup<"">,

Looks like this is missing `clang-format`?


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

https://reviews.llvm.org/D88394

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

[PATCH] D92617: [DWARF] Allow toolchain to adjust specified DWARF version.

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/test/Driver/cuda-unsupported-debug-options.cu:22
+// Make sure we do not see any dwarf version other than 2, regardless of 
what's used on the host side.
+// CHECK-NOT: {{-dwarf-version=[^2]}}
 // CHECK: "-triple" "x86_64

dblaikie wrote:
> tra wrote:
> > MaskRay wrote:
> > > A NOT pattern may easily become stale and do not actually check anything. 
> > > Just turn to a positive pattern?
> > In this case the issue is with the CHECK-NOT line above. I'll have to 
> > replicate it around the positive match of `-dwarf-version` which would 
> > raise more questions.
> > 
> > I wish filecheck would allow to `mark` a region and then run multiple 
> > matches on it, instead of re-anchoring on each match. 
> Sounds like you're looking for CHECK-DAG, maybe? ( 
> https://llvm.org/docs/CommandGuide/FileCheck.html#the-check-dag-directive )
I don't think CHECK-DAG can be mixed with CHECK-NOT. At least, not the way I 
need them here. From FileCheck docs:
> CHECK-NOT: directives could be mixed with CHECK-DAG: directives to exclude 
> strings between the surrounding CHECK-DAG: directives.

So, in order to use it here I'll need something like this:
```
// CHECK: -triple // GPU-side compilation
// CHECK-NOT: {{all unsupported options}}
// CHECK: -dwarf-version=2  // Could be CHECK-DAG, too, it does not matter in 
this case.
// We have to repeat the NOT check here because the positive check above 
creates another subset of input to check for -NOT.
// CHECK-NOT: {{all unsupported options}} 
// CHECK: - triple // Host-side compilation
```

Ideally I want something like this:
```
// CHECK-WITHOUT-ADVANCE: -dwarf-version=2
// CHECK-NOT: {{unsupported options}}
```

If you prefer positive check with replicated -NOT, I'm fine with that.



Comment at: clang/test/Driver/debug-options.c:364-366
+// GEMBED_2:  warning: debug information option '-gembed-source' is not 
supported for target
 // NOGEMBED_5-NOT:  "-gembed-source"
+// NOGEMBED_2-NOT:  warning: debug information option '-gembed-source' is not 
supported for target

scott.linder wrote:
> dblaikie wrote:
> > This is a bit of a loss in fidelity - might need a new diagnostic message 
> > (or go hunting around for a more general purpose one than this one at 
> > least) to say '-gembed-source' is ignored when not using DWARFv5. (in the 
> > nvptx case it's "not supported on target", but in the existing cases 
> > covered by this test it's "not supported because the user requested 
> > DWARFv2", for instance)
> > 
> > @JDevlieghere & @scott.linder for thoughts on this.
> I agree that I'd prefer we detect whether the target-specific clamped version 
> is to blame (and use the proposed warning message) or the original DWARF 
> version is to blame (and use the old message).
> 
> If I were compiling for x86 and gave e.g. `-gdwarf-4 -gembed-source` and the 
> error said "not supported by target" I'd probably get the wrong idea.
> 
> It would also be nice to retain the error semantics in the case where the 
> user is explicitly requesting incompatible options.
This sounds pretty close to what the older iterations of this patch did:  
https://reviews.llvm.org/D92617?id=309404, except that it preserved the current 
behavior which makes it an error to use -gembed-source with an explicitly 
specified DWARF version below 5. Same options with a lower clamped version 
produces a warning. I.e. If user specified a nominally valid combination of 
`-gdwarf-5 -gembed-source` but the target like NVPTX clamped it down to DWARF2, 
there will only be a warning.

I would appreciate if you (as in debug info stakeholders) could clarify couple 
of moments for me:

* should `-gdwarf-4 -gembed-source` be an error or warning? It's currently an 
error.
* `-gdwarf-5 -gembed-source` with the dwarf version clamped below 5 should 
produce a warning. `not supported for target` appears to be correct, but does 
not explain why. Do we want to amend/change it to say `because target only 
supports DWARF 2` or `target does not support DWARF 5`? Or is `not supported by 
target` sufficient as is?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92617

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

[PATCH] D92633: Add -f[no-]direct-access-external-data to deprecate -mpie-copy-relocations

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D92633#2434766 , @MaskRay wrote:

> In D92633#2434714 , @tmsriram wrote:
>
>> Correct me if I am wrong, but I do see that this behavior is touched.  Line 
>> 10 in -fdirect-access-external-data.c :
>>
>> // RUN: %clang -### -c -target aarch64 %s -fpic 
>> -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT
>>
>> With -fpic, the variable access will go directly and not via GOT.
>
> `clang/test/Driver/fdirect-access-external-data.c` is a driver test which 
> tests how the driver passes options to CC1.



> `clang/lib/CodeGen/CodeGenModule.cpp` says how the CC1 option affects the 
> dso_local specifier in the LLVM IR output. Currently it is a no op for 
> -fpic/-fPIC.

Great! Sorry I didnt realize this,  this is fine with me now!

> (I have made some tests. It looks like implementing 
> -fno-direct-access-external-data for -fno-pic is not an insurmountable work: 
> ~50 tests)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92633

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

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Csaba Dabis via Phabricator via cfe-commits]

Charusso added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst:60
 - If copy to the destination array can overflow [1] and
-  ``AreSafeFunctionsAvailable`` is set to ``Yes``, ``y`` or non-zero and it is
+  ``AreSafeFunctionsAvailable`` is set to `true` and it is
   possible to obtain the capacity of the destination array then the new 
function

aaron.ballman wrote:
> njames93 wrote:
> > aaron.ballman wrote:
> > > This edit loses information about also accepting `Yes` and `y` -- is that 
> > > intentional (or were those unsupported before)?
> > > 
> > > FWIW, I'd be fine dropping support for alternate spellings of `true`.
> > Having looked throughout the NotNullTerminatedResultCheck header/impl 
> > files, I can't find any reference to `AreSafeFunctionsAvailable`.
> > I can only guess this is meant to say WantToUseSafeFunctions. If that is 
> > the case, `Yes` and `y` were never supported spellings.
> > 
> > Should this be changed to use that option name instead? cc @Charusso
> > 
> > FWIW I intend (in the near future) to extend boolean parsing for check 
> > options to:
> > `y|Y|yes|Yes|YES|true|True|TRUE|on|On|ON`
> > `n|N|no|No|NO|false|False|FALSE|off|Off|OFF`.
> > 
> > Reason for this is we claim to use YAML for config format and according to 
> > its specification, this is what is accepted as a boolean value. Ref 
> > https://yaml.org/type/bool.html.
> > Still need to keep the old integer method of specifying bools for backwards 
> > compatibility reasons.
> > 
> > Should this be changed to use that option name instead? cc @Charusso
> 
> I think so, but that can be done in an NFC followup if you'd like.
> 
> > Reason for this is we claim to use YAML for config format and according to 
> > its specification, this is what is accepted as a boolean value.
> 
> Oh, that's a good reason to support those spellings, thank you for clarifying.
Hey, nice catch and cool patch! Sorry for the extra work. 
`WantToUseSafeFunctions` is wanted to be here as a zero or non-zero value [1]. 
It would be great if you could rewrite this variable name because I do not 
write LLVM code any more. Thanks!

[1] 
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-not-null-terminated-result.html#options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

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

[PATCH] D92633: Add -f[no-]direct-access-external-data to deprecate -mpie-copy-relocations

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D92633#2434714 , @tmsriram wrote:

> Correct me if I am wrong, but I do see that this behavior is touched.  Line 
> 10 in -fdirect-access-external-data.c :
>
> // RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 
> 2>&1 | FileCheck %s --check-prefix=DIRECT
>
> With -fpic, the variable access will go directly and not via GOT.

`clang/test/Driver/fdirect-access-external-data.c` is a driver test which tests 
how the driver passes options to CC1.

`clang/lib/CodeGen/CodeGenModule.cpp` says how the CC1 option affects the 
dso_local specifier in the LLVM IR output. Currently it is a no op for 
-fpic/-fPIC.

(I have made some tests. It looks like implementing 
-fno-direct-access-external-data for -fno-pic is not an insurmountable work: 
~50 tests)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92633

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

[PATCH] D92682: [OPENMP]Fix PR48394: need to capture variables used in atomic constructs.

[Alexey Bataev 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 rGd764ad72e5fe: [OPENMP]Fix PR48394: need to capture variables 
used in atomic constructs. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92682

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/taskloop_with_atomic_codegen.cpp


Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+// CHECK-LABEL: @main
+int main() {
+  unsigned occupanices = 0;
+
+// CHECK: call void @__kmpc_taskloop(%struct.ident_t* @{{.+}}, i32 %{{.+}}, 
i8* %{{.+}}, i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 1, i32 0, i64 
0, i8* null)
+#pragma omp taskloop
+  for (int i = 0; i < 1; i++) {
+#pragma omp atomic
+occupanices++;
+  }
+}
+
+// CHECK: define internal i32 @{{.+}}(
+// Check that occupanices var is firstprivatized.
+// CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1
+// CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
+// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** 
[[FP_OCCUP_ADDR]])
+
+#endif
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -3339,12 +3339,15 @@
 
   void VisitSubCaptures(OMPExecutableDirective *S) {
 // Check implicitly captured variables.
-if (!S->hasAssociatedStmt() || !S->getAssociatedStmt() ||
-S->getDirectiveKind() == OMPD_atomic ||
+if (!S->hasAssociatedStmt() || !S->getAssociatedStmt())
+  return;
+if (S->getDirectiveKind() == OMPD_atomic ||
 S->getDirectiveKind() == OMPD_critical ||
 S->getDirectiveKind() == OMPD_section ||
-S->getDirectiveKind() == OMPD_master)
+S->getDirectiveKind() == OMPD_master) {
+  Visit(S->getAssociatedStmt());
   return;
+}
 visitSubCaptures(S->getInnermostCapturedStmt());
 // Try to capture inner this->member references to generate correct 
mappings
 // and diagnostics.


Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd -fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+// CHECK-LABEL: @main
+int main() {
+  unsigned occupanices = 0;
+
+// CHECK: call void @__kmpc_taskloop(%struct.ident_t* @{{.+}}, i32 %{{.+}}, i8* %{{.+}}, i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 1, i32 0, i64 0, i8* null)
+#pragma omp taskloop
+  for (int i = 0; i < 1; i++) {
+#pragma omp atomic
+occupanices++;
+  }
+}
+
+// CHECK: define internal i32 @{{.+}}(
+// Check that occupanices var is firstprivatized.
+// CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1
+// CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
+// CHECK-DAG: call void (i8*, ...) 

[clang] d764ad7 - [OPENMP]Fix PR48394: need to capture variables used in atomic constructs.

[Alexey Bataev via cfe-commits]

Author: Alexey Bataev
Date: 2020-12-04T13:08:54-08:00
New Revision: d764ad72e5fe7ae1cd9b345ad72f4447355a11b2

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

LOG: [OPENMP]Fix PR48394: need to capture variables used in atomic constructs.

The variables used in atomic construct should be captured in outer
task-based regions implicitly. Otherwise, the compiler will crash trying
to find the address of the local variable.

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

Added: 
clang/test/OpenMP/taskloop_with_atomic_codegen.cpp

Modified: 
clang/lib/Sema/SemaOpenMP.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 932017d638f5..13c0a485ac38 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -3339,12 +3339,15 @@ class DSAAttrChecker final : public 
StmtVisitor {
 
   void VisitSubCaptures(OMPExecutableDirective *S) {
 // Check implicitly captured variables.
-if (!S->hasAssociatedStmt() || !S->getAssociatedStmt() ||
-S->getDirectiveKind() == OMPD_atomic ||
+if (!S->hasAssociatedStmt() || !S->getAssociatedStmt())
+  return;
+if (S->getDirectiveKind() == OMPD_atomic ||
 S->getDirectiveKind() == OMPD_critical ||
 S->getDirectiveKind() == OMPD_section ||
-S->getDirectiveKind() == OMPD_master)
+S->getDirectiveKind() == OMPD_master) {
+  Visit(S->getAssociatedStmt());
   return;
+}
 visitSubCaptures(S->getInnermostCapturedStmt());
 // Try to capture inner this->member references to generate correct 
mappings
 // and diagnostics.

diff  --git a/clang/test/OpenMP/taskloop_with_atomic_codegen.cpp 
b/clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
new file mode 100644
index ..16c09b68d0cf
--- /dev/null
+++ b/clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+// CHECK-LABEL: @main
+int main() {
+  unsigned occupanices = 0;
+
+// CHECK: call void @__kmpc_taskloop(%struct.ident_t* @{{.+}}, i32 %{{.+}}, 
i8* %{{.+}}, i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 1, i32 0, i64 
0, i8* null)
+#pragma omp taskloop
+  for (int i = 0; i < 1; i++) {
+#pragma omp atomic
+occupanices++;
+  }
+}
+
+// CHECK: define internal i32 @{{.+}}(
+// Check that occupanices var is firstprivatized.
+// CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1
+// CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
+// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** 
[[FP_OCCUP_ADDR]])
+
+#endif



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

[PATCH] D92661: [RFC] Fix TLS and Coroutine

[Hongtao Yu via Phabricator via cfe-commits]

hoy added inline comments.



Comment at: llvm/include/llvm/IR/Intrinsics.td:1309
+// Intrinsic to obtain the address of a thread_local variable.
+def int_threadlocal : Intrinsic<[llvm_ptr_ty], [llvm_ptr_ty]>;
+

lxfind wrote:
> hoy wrote:
> > hoy wrote:
> > > With the intrinsic, can TLS variable reference in the same coroutine or 
> > > regular routine be DCE-ed anymore?
> > Sorry, I meant CSE-ed.
> Since the intrinsics does not have readnone attribute, it won't be CSE-ed 
> before CoroSplit.
> However after CoroSplit, it will be lowered back to the direct reference of 
> the TLS, and will be CSE-ed by latter passes.
> I can add a test function to demonstrate that too.
Sounds good. Can you please point out what optimization passes CSE-ed tls 
reference without this implementation? I'm wondering if those optimizations can 
be postponed to after CoroSplit. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92661

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

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Jon Roelofs via Phabricator via cfe-commits]

jroelofs added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:108
+
+  return std::string(SysRootDir.str());
+}

abidh wrote:
> jroelofs wrote:
> > Small string has an implicit conversion to std::string, so you can just 
> > `return SysRootDir;` here.
> I was getting a compile error on that. Looking in SmallString.h, it seems 
> that conversion to std::string is explicit.
ohh, I see what's going on. doxygen doesn't list the explicit keyword in the 
html page, so I thought it was implicit. sorry.


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

https://reviews.llvm.org/D92677

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

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Jon Roelofs via Phabricator via cfe-commits]

jroelofs added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:105
+
+  return std::string(SysRootDir);
+}

did `return SysRootDir;` not work? Why do you need the explicit std::string 
ctor call?


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

https://reviews.llvm.org/D92677

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

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Hafiz Abid Qadeer via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:108
+
+  return std::string(SysRootDir.str());
+}

jroelofs wrote:
> Small string has an implicit conversion to std::string, so you can just 
> `return SysRootDir;` here.
I was getting a compile error on that. Looking in SmallString.h, it seems that 
conversion to std::string is explicit.


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

https://reviews.llvm.org/D92677

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

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Hafiz Abid Qadeer via Phabricator via cfe-commits]

abidh updated this revision to Diff 309637.
abidh added a comment.

Handled review comments.


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

https://reviews.llvm.org/D92677

Files:
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/lib/Driver/ToolChains/BareMetal.h
  clang/test/Driver/baremetal-sysroot.cpp


Index: clang/test/Driver/baremetal-sysroot.cpp
===
--- /dev/null
+++ clang/test/Driver/baremetal-sysroot.cpp
@@ -0,0 +1,22 @@
+// REQUIRES: shell
+// UNSUPPORTED: system-windows
+
+// Test that when a --sysroot is not provided, driver picks the default
+// location correctly if available.
+
+// RUN: rm -rf %T/baremetal_default_sysroot
+// RUN: mkdir -p %T/baremetal_default_sysroot/bin
+// RUN: mkdir -p 
%T/baremetal_default_sysroot/lib/clang-runtimes/armv6m-none-eabi
+// RUN: ln -s %clang %T/baremetal_default_sysroot/bin/clang
+
+// RUN: %T/baremetal_default_sysroot/bin/clang -no-canonical-prefixes %s -### 
-o %t.o 2>&1 \
+// RUN: -target armv6m-none-eabi \
+// RUN:   | FileCheck --check-prefix=CHECK-V6M-C %s
+// CHECK-V6M-C: "{{.*}}clang{{.*}}" "-cc1" "-triple" 
"thumbv6m-none-unknown-eabi"
+// CHECK-V6M-C-SAME: "-internal-isystem" 
"{{.*}}/baremetal_default_sysroot{{[/\\]+}}bin{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}armv6m-none-eabi{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
+// CHECk-V6M-C-SAME: "-internal-isystem" 
"{{.*}}/baremetal_default_sysroot{{[/\\]+}}bin{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}armv6m-none-eabi{{[/\\]+}}include"
+// CHECK-V6M-C-SAME: "-x" "c++" "{{.*}}baremetal-sysroot.cpp"
+// CHECK-V6M-C-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" 
"{{.*}}.o" "-Bstatic"
+// CHECK-V6M-C-SAME: 
"-L{{.*}}/baremetal_default_sysroot{{[/\\]+}}bin{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}armv6m-none-eabi{{[/\\]+}}lib"
+// CHECK-V6M-C-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m"
+// CHECK-V6M-C-SAME: "-o" "{{.*}}.o"
Index: clang/lib/Driver/ToolChains/BareMetal.h
===
--- clang/lib/Driver/ToolChains/BareMetal.h
+++ clang/lib/Driver/ToolChains/BareMetal.h
@@ -67,6 +67,7 @@
llvm::opt::ArgStringList ) const override;
   void AddLinkRuntimeLib(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) const;
+  std::string computeSysRoot() const override;
 };
 
 } // namespace toolchains
Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -33,7 +33,7 @@
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
-  SmallString<128> SysRoot(getDriver().SysRoot);
+  SmallString<128> SysRoot(computeSysRoot());
   if (!SysRoot.empty()) {
 llvm::sys::path::append(SysRoot, "lib");
 getFilePaths().push_back(std::string(SysRoot));
@@ -94,6 +94,17 @@
   return std::string(Dir.str());
 }
 
+std::string BareMetal::computeSysRoot() const {
+  if (!getDriver().SysRoot.empty())
+return getDriver().SysRoot;
+
+  SmallString<128> SysRootDir;
+  llvm::sys::path::append(SysRootDir, getDriver().Dir, "../lib/clang-runtimes",
+  getDriver().getTargetTriple());
+
+  return std::string(SysRootDir);
+}
+
 void BareMetal::AddClangSystemIncludeArgs(const ArgList ,
   ArgStringList ) const {
   if (DriverArgs.hasArg(options::OPT_nostdinc))
@@ -106,7 +117,7 @@
   }
 
   if (!DriverArgs.hasArg(options::OPT_nostdlibinc)) {
-SmallString<128> Dir(getDriver().SysRoot);
+SmallString<128> Dir(computeSysRoot());
 if (!Dir.empty()) {
   llvm::sys::path::append(Dir, "include");
   addSystemInclude(DriverArgs, CC1Args, Dir.str());
@@ -127,7 +138,7 @@
   DriverArgs.hasArg(options::OPT_nostdincxx))
 return;
 
-  StringRef SysRoot = getDriver().SysRoot;
+  std::string SysRoot(computeSysRoot());
   if (SysRoot.empty())
 return;
 


Index: clang/test/Driver/baremetal-sysroot.cpp
===
--- /dev/null
+++ clang/test/Driver/baremetal-sysroot.cpp
@@ -0,0 +1,22 @@
+// REQUIRES: shell
+// UNSUPPORTED: system-windows
+
+// Test that when a --sysroot is not provided, driver picks the default
+// location correctly if available.
+
+// RUN: rm -rf %T/baremetal_default_sysroot
+// RUN: mkdir -p %T/baremetal_default_sysroot/bin
+// RUN: mkdir -p %T/baremetal_default_sysroot/lib/clang-runtimes/armv6m-none-eabi
+// RUN: ln -s %clang %T/baremetal_default_sysroot/bin/clang
+
+// RUN: %T/baremetal_default_sysroot/bin/clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target armv6m-none-eabi \
+// RUN:   | FileCheck --check-prefix=CHECK-V6M-C %s
+// 

[PATCH] D92633: Add -f[no-]direct-access-external-data to deprecate -mpie-copy-relocations

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.

In D92633#2434511 , @MaskRay wrote:

> In D92633#2434337 , @tmsriram wrote:
>
>> In D92633#2434267 , @MaskRay wrote:
>>
>>> In D92633#2434231 , @tmsriram 
>>> wrote:
>>>
 Sorry just one more thing which is a bit concerning:

 When I do  :

 $ clang -fPIC -frxternal-data-access foo.c

 You will omit the GOT but this object can go into a shared object and 
 break the build as this does not apply to shared objects?  Should we allow 
 this at all for -fPIC?  I dont see a need for this but if you want to,  
 maybe warn?  The user should know that this cannot go into a shared object 
 right?
 I am also ok with commenting that this option can do bad things for -fPIC 
 and the user should know what they are doing.
>>>
>>> `clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie 
>>> a.o` (producing an executable with either `-no-pie` or `-pie`) is fine.
>>
>> Yes, agreed. Putting this object into an executable (pie/no-pie) no matter 
>> how you compile it  is always fine as long as the backend supports copy 
>> relocations. No issues there.
>>
>>> For `-shared`, because an ELF linker assumes interposition for non-local 
>>> STV_DEFAULT symbols by default, linking such an object files requires some 
>>> mechanism to make it non-preemptible.
>>
>> Right, that was my point.  Without -fPIC, we can be guaranteed that it won't 
>> go into a shared object and this case wouldn't arise.
>>
>>> The simplest is `clang -fPIC -fdirect-access-external-data -c a.c; ld 
>>> -shared -Bsymbolic a.o`
>>> Other mechanisms include: `--dynamic-list` (don't list the symbol) and 
>>> `--version-script` (localize the symbol).
>>> This is going to be tricky and I don't know how to fit the information into 
>>> the few-line description of the option.
>>
>> How about making this option applicable for -fpie/fPIE and the default case 
>> and *not allowing* it for -fPIC/-fpic?   That seems the safest approach.
>>
>>> I just checked how to make -fdirect-access-eternal-data work for -fno-pic 
>>> (both TargetMachine::shouldAssumeDSOLocal and 
>>> CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for 
>>> Reloc::Static), unfortunately there are 200 tests needing updates. (This 
>>> reminds me that LLVM doesn't get the default for dso_local right, so many 
>>> tests have `dso_local` in ELF/COFF but no `dso_local` in Mach-O. 
>>> Unfortunately it is extremely difficult to fix it today (D76561 
>>> ))
>>
>> Ok, I lost you here a bit.  This should be fine for -fno-pic was my 
>> understanding.
>>
>> Let me try to summarize the motivations of this patch:
>>
>> 1. Originally, the default build (fno-pie/fno-pic), always used direct 
>> access for external globals resulting in copy relocations if it is truly 
>> external at link time.  You want to change that to be able to not have copy 
>> relocations with -fno-direct-access-external-data, and you claim this would 
>> be useful for POWER, great!
>> 2. Originally, with -fPIE and -fpie, -mpie-copy-relocations allowed direct 
>> access to externals.  This was always safe because the object was guaranteed 
>> to go into an executable.  The new option preserves this behavior so there 
>> is **no concern**.
>
> Yes for 1 and 2. This patch only makes the options work for -fpie (as the 
> original -mpie-copy-relocations does).
>
> 1 will be a nice cleanup (to drop 2 lines from 
> TargetMachine::shouldAssumeDSOLocal) but it may require some test updates and 
> it looks like `CodeGen/MachineCSE.cpp` exposes a crashing bug that it cannot 
> handle non-dso_local `external constant` in -relocation-model=static mode 
> correctly...
>
>> 3. Originally, there was no way to generate direct accesses to external 
>> global variables with -fPIC/-fpic. That behavior will change if you support 
>> -fdirect-access-external-data with -fPIC. **That is my concern that this 
>> adds to the complexity and the user should know what they are doing.**
>>
>> Given 3), I am wondering if you really need this patch.  I will leave it to 
>> you but please do consider the fact that opening up this option to -fPIC 
>> might be a problem.
>
> I agree. The behavior is not touched in this patch.

Correct me if I am wrong, but I do see that this behavior is touched.  Line 10 
in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 
2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

> I think the existing -mpie-copy-relocations users should be aware that the 
> option (-fdirect-access-external-data) should generally only be used with 
> -fno-pic and -fpie.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  

[PATCH] D92671: Add diagnostic for for-range-declaration being specificed with thread_local

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

In D92671#2434154 , @shafik wrote:

> The problem with this approach is given:
>
>   for (static thread_local int a : A()) {}
>
> it just issues one diagnostic and it points to `static` but I am not sure 
> what the right approach to handling this case is.

I think that's reasonable behavior for this corner case.




Comment at: clang/lib/Sema/SemaDecl.cpp:12752
 Error = 4;
 break;
   }

Quuxplusone wrote:
> Incidentally, why is this case here to begin with? Loop variables can totally 
> be `register`. (But I guess it's moot at this point; clearly no Clang user is 
> depending on this to work, and `register` is gone from C++20.)
See [stmt.ranged]p2 -- it's explicitly disallowed. FWIW, loop variables in C++ 
can also be static (https://godbolt.org/z/rM15Yz). ;-)


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

https://reviews.llvm.org/D92671

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

[PATCH] D92663: [clangd] Add hot-reload of compile_commands.json and compile_flags.txt

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

The compilationdatabase changes won't be landed as part of this patch, they've 
been sent separately for review.
I can try the git gymnastics to get them out of this patch, but if you don't 
mind ignoring them that's easier :-)

There might be a sensible way to split this further, but I'm not seeing it for 
some reason - definitely open to suggestions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92663

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

[PATCH] D92617: [DWARF] Allow toolchain to adjust specified DWARF version.

[Scott Linder via Phabricator via cfe-commits]

scott.linder added inline comments.



Comment at: clang/test/Driver/debug-options.c:364-366
+// GEMBED_2:  warning: debug information option '-gembed-source' is not 
supported for target
 // NOGEMBED_5-NOT:  "-gembed-source"
+// NOGEMBED_2-NOT:  warning: debug information option '-gembed-source' is not 
supported for target

dblaikie wrote:
> This is a bit of a loss in fidelity - might need a new diagnostic message (or 
> go hunting around for a more general purpose one than this one at least) to 
> say '-gembed-source' is ignored when not using DWARFv5. (in the nvptx case 
> it's "not supported on target", but in the existing cases covered by this 
> test it's "not supported because the user requested DWARFv2", for instance)
> 
> @JDevlieghere & @scott.linder for thoughts on this.
I agree that I'd prefer we detect whether the target-specific clamped version 
is to blame (and use the proposed warning message) or the original DWARF 
version is to blame (and use the old message).

If I were compiling for x86 and gave e.g. `-gdwarf-4 -gembed-source` and the 
error said "not supported by target" I'd probably get the wrong idea.

It would also be nice to retain the error semantics in the case where the user 
is explicitly requesting incompatible options.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92617

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

[PATCH] D92439: [CLANG] Fix missing error for use of 128-bit integer inside SPIR64 device code.

[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


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

https://reviews.llvm.org/D92439

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

[PATCH] D92640: Add ability to load a FixedCompilationDatabase from a buffer.

[Sam McCall via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/Tooling/CompilationDatabase.h:194
+  static std::unique_ptr
+  loadFromBuffer(StringRef Path, StringRef Data, std::string );
+

usaxena95 wrote:
> usaxena95 wrote:
> > `Path` is not meaningful for load from buffer. May be change name to 
> > `Directory` and call loadFromBuffer(**llvm::sys::path::parent_path(Path)**, 
> > (*File)->getBuffer(), ErrorMsg); instead.
> Do you intend to use it apart from testing ?
Yes. See D92663


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92640

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

[PATCH] D92682: [OPENMP]Fix PR48394: need to capture variables used in atomic constructs.

[Johannes Doerfert via Phabricator via cfe-commits]

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

LGTM, thanks for the quick fix!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92682

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

[PATCH] D92640: Add ability to load a FixedCompilationDatabase from a buffer.

[Sam McCall via Phabricator via cfe-commits]

sammccall updated this revision to Diff 309630.
sammccall marked an inline comment as done.
sammccall added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92640

Files:
  clang/include/clang/Tooling/CompilationDatabase.h
  clang/lib/Tooling/CompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -541,6 +541,27 @@
   EXPECT_EQ(0ul, Database.getAllCompileCommands().size());
 }
 
+TEST(FixedCompilationDatabase, FromBuffer) {
+  const char *Data = R"(
+
+ -DFOO=BAR
+
+--baz
+
+  )";
+  std::string ErrorMsg;
+  auto CDB =
+  FixedCompilationDatabase::loadFromBuffer("/cdb/dir", Data, ErrorMsg);
+
+  std::vector Result = CDB->getCompileCommands("/foo/bar.cc");
+  ASSERT_EQ(1ul, Result.size());
+  EXPECT_EQ("/cdb/dir", Result.front().Directory);
+  EXPECT_EQ("/foo/bar.cc", Result.front().Filename);
+  EXPECT_THAT(
+  Result.front().CommandLine,
+  ElementsAre(EndsWith("clang-tool"), "-DFOO=BAR", "--baz", 
"/foo/bar.cc"));
+}
+
 TEST(ParseFixedCompilationDatabase, ReturnsNullOnEmptyArgumentList) {
   int Argc = 0;
   std::string ErrorMsg;
Index: clang/lib/Tooling/CompilationDatabase.cpp
===
--- clang/lib/Tooling/CompilationDatabase.cpp
+++ clang/lib/Tooling/CompilationDatabase.cpp
@@ -348,16 +348,24 @@
 ErrorMsg = "Error while opening fixed database: " + Result.message();
 return nullptr;
   }
+  return loadFromBuffer(llvm::sys::path::parent_path(Path),
+(*File)->getBuffer(), ErrorMsg);
+}
+
+std::unique_ptr
+FixedCompilationDatabase::loadFromBuffer(StringRef Directory, StringRef Data,
+ std::string ) {
+  ErrorMsg.clear();
   std::vector Args;
-  for (llvm::StringRef Line :
-   llvm::make_range(llvm::line_iterator(**File), llvm::line_iterator())) {
+  StringRef Line;
+  while (!Data.empty()) {
+std::tie(Line, Data) = Data.split('\n');
 // Stray whitespace is almost certainly unintended.
 Line = Line.trim();
 if (!Line.empty())
   Args.push_back(Line.str());
   }
-  return std::make_unique(
-  llvm::sys::path::parent_path(Path), std::move(Args));
+  return std::make_unique(Directory, 
std::move(Args));
 }
 
 FixedCompilationDatabase::
Index: clang/include/clang/Tooling/CompilationDatabase.h
===
--- clang/include/clang/Tooling/CompilationDatabase.h
+++ clang/include/clang/Tooling/CompilationDatabase.h
@@ -184,11 +184,16 @@
   int , const char *const *Argv, std::string ,
   Twine Directory = ".");
 
-  /// Reads flags from the given file, one-per line.
+  /// Reads flags from the given file, one-per-line.
   /// Returns nullptr and sets ErrorMessage if we can't read the file.
   static std::unique_ptr
   loadFromFile(StringRef Path, std::string );
 
+  /// Reads flags from the given buffer, one-per-line.
+  /// Directory is the command CWD, typically the parent of compile_flags.txt.
+  static std::unique_ptr
+  loadFromBuffer(StringRef Directory, StringRef Data, std::string );
+
   /// Constructs a compilation data base from a specified directory
   /// and command line.
   FixedCompilationDatabase(Twine Directory, ArrayRef CommandLine);


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -541,6 +541,27 @@
   EXPECT_EQ(0ul, Database.getAllCompileCommands().size());
 }
 
+TEST(FixedCompilationDatabase, FromBuffer) {
+  const char *Data = R"(
+
+ -DFOO=BAR
+
+--baz
+
+  )";
+  std::string ErrorMsg;
+  auto CDB =
+  FixedCompilationDatabase::loadFromBuffer("/cdb/dir", Data, ErrorMsg);
+
+  std::vector Result = CDB->getCompileCommands("/foo/bar.cc");
+  ASSERT_EQ(1ul, Result.size());
+  EXPECT_EQ("/cdb/dir", Result.front().Directory);
+  EXPECT_EQ("/foo/bar.cc", Result.front().Filename);
+  EXPECT_THAT(
+  Result.front().CommandLine,
+  ElementsAre(EndsWith("clang-tool"), "-DFOO=BAR", "--baz", "/foo/bar.cc"));
+}
+
 TEST(ParseFixedCompilationDatabase, ReturnsNullOnEmptyArgumentList) {
   int Argc = 0;
   std::string ErrorMsg;
Index: clang/lib/Tooling/CompilationDatabase.cpp
===
--- clang/lib/Tooling/CompilationDatabase.cpp
+++ clang/lib/Tooling/CompilationDatabase.cpp
@@ -348,16 +348,24 @@
 ErrorMsg = "Error while opening fixed database: " + Result.message();
 return nullptr;
   }
+  return 

[PATCH] D92682: [OPENMP]Fix PR48394: need to capture variables used in atomic constructs.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: jfb, guansong, yaxunl.
ABataev requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added a project: clang.

The variables used in atomic construct should be captured in outer
task-based regions implicitly. Otherwise, the compiler will crash trying
to find the address of the local variable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92682

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/taskloop_with_atomic_codegen.cpp


Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd 
-fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple 
x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck 
--check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+// CHECK-LABEL: @main
+int main() {
+  unsigned occupanices = 0;
+
+// CHECK: call void @__kmpc_taskloop(%struct.ident_t* @{{.+}}, i32 %{{.+}}, 
i8* %{{.+}}, i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 1, i32 0, i64 
0, i8* null)
+#pragma omp taskloop
+  for (int i = 0; i < 1; i++) {
+#pragma omp atomic
+occupanices++;
+  }
+}
+
+// CHECK: define internal i32 @{{.+}}(
+// Check that occupanices var is firstprivatized.
+// CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1
+// CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
+// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** 
[[FP_OCCUP_ADDR]])
+
+#endif
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -3339,12 +3339,15 @@
 
   void VisitSubCaptures(OMPExecutableDirective *S) {
 // Check implicitly captured variables.
-if (!S->hasAssociatedStmt() || !S->getAssociatedStmt() ||
-S->getDirectiveKind() == OMPD_atomic ||
+if (!S->hasAssociatedStmt() || !S->getAssociatedStmt())
+  return;
+if (S->getDirectiveKind() == OMPD_atomic ||
 S->getDirectiveKind() == OMPD_critical ||
 S->getDirectiveKind() == OMPD_section ||
-S->getDirectiveKind() == OMPD_master)
+S->getDirectiveKind() == OMPD_master) {
+  Visit(S->getAssociatedStmt());
   return;
+}
 visitSubCaptures(S->getInnermostCapturedStmt());
 // Try to capture inner this->member references to generate correct 
mappings
 // and diagnostics.


Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp-simd -fopenmp-version=50 -x c++ -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+// CHECK-LABEL: @main
+int main() {
+  unsigned occupanices = 0;
+
+// CHECK: call void @__kmpc_taskloop(%struct.ident_t* @{{.+}}, i32 %{{.+}}, i8* %{{.+}}, i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 1, i32 0, i64 0, i8* null)
+#pragma omp taskloop
+  for (int i = 0; i < 1; i++) {
+#pragma omp atomic
+occupanices++;
+  }
+}
+
+// CHECK: define internal i32 @{{.+}}(
+// Check that occupanices var is firstprivatized.
+// CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1
+// CHECK-DAG: [[FP_OCCUP]] = 

[PATCH] D92671: Add diagnostic for for-range-declaration being specificed with thread_local

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:12752
 Error = 4;
 break;
   }

Incidentally, why is this case here to begin with? Loop variables can totally 
be `register`. (But I guess it's moot at this point; clearly no Clang user is 
depending on this to work, and `register` is gone from C++20.)


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

https://reviews.llvm.org/D92671

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

[PATCH] D92646: [Tooling] JSONCompilationDatabase::loadFromBuffer retains the buffer, copy it.

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG650e04e179c9: [Tooling] 
JSONCompilationDatabase::loadFromBuffer retains the buffer, copy it. (authored 
by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92646

Files:
  clang/lib/Tooling/JSONCompilationDatabase.cpp
  clang/unittests/Tooling/CompilationDatabaseTest.cpp


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -172,13 +172,15 @@
 }
 
 static CompileCommand findCompileArgsInJsonDatabase(StringRef FileName,
-StringRef JSONDatabase,
+std::string JSONDatabase,
 std::string ) 
{
   std::unique_ptr Database(
   JSONCompilationDatabase::loadFromBuffer(JSONDatabase, ErrorMessage,
   JSONCommandLineSyntax::Gnu));
   if (!Database)
 return CompileCommand();
+  // Overwrite the string to verify we're not reading from it later.
+  JSONDatabase.assign(JSONDatabase.size(), '*');
   std::vector Commands = 
Database->getCompileCommands(FileName);
   EXPECT_LE(Commands.size(), 1u);
   if (Commands.empty())
Index: clang/lib/Tooling/JSONCompilationDatabase.cpp
===
--- clang/lib/Tooling/JSONCompilationDatabase.cpp
+++ clang/lib/Tooling/JSONCompilationDatabase.cpp
@@ -217,7 +217,7 @@
 std::string ,
 JSONCommandLineSyntax Syntax) {
   std::unique_ptr DatabaseBuffer(
-  llvm::MemoryBuffer::getMemBuffer(DatabaseString));
+  llvm::MemoryBuffer::getMemBufferCopy(DatabaseString));
   std::unique_ptr Database(
   new JSONCompilationDatabase(std::move(DatabaseBuffer), Syntax));
   if (!Database->parse(ErrorMessage))


Index: clang/unittests/Tooling/CompilationDatabaseTest.cpp
===
--- clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -172,13 +172,15 @@
 }
 
 static CompileCommand findCompileArgsInJsonDatabase(StringRef FileName,
-StringRef JSONDatabase,
+std::string JSONDatabase,
 std::string ) {
   std::unique_ptr Database(
   JSONCompilationDatabase::loadFromBuffer(JSONDatabase, ErrorMessage,
   JSONCommandLineSyntax::Gnu));
   if (!Database)
 return CompileCommand();
+  // Overwrite the string to verify we're not reading from it later.
+  JSONDatabase.assign(JSONDatabase.size(), '*');
   std::vector Commands = Database->getCompileCommands(FileName);
   EXPECT_LE(Commands.size(), 1u);
   if (Commands.empty())
Index: clang/lib/Tooling/JSONCompilationDatabase.cpp
===
--- clang/lib/Tooling/JSONCompilationDatabase.cpp
+++ clang/lib/Tooling/JSONCompilationDatabase.cpp
@@ -217,7 +217,7 @@
 std::string ,
 JSONCommandLineSyntax Syntax) {
   std::unique_ptr DatabaseBuffer(
-  llvm::MemoryBuffer::getMemBuffer(DatabaseString));
+  llvm::MemoryBuffer::getMemBufferCopy(DatabaseString));
   std::unique_ptr Database(
   new JSONCompilationDatabase(std::move(DatabaseBuffer), Syntax));
   if (!Database->parse(ErrorMessage))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92671: Add diagnostic for for-range-declaration being specificed with thread_local

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

Spoilsport. ;)
LGTM, fwiw.


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

https://reviews.llvm.org/D92671

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

[clang] 650e04e - [Tooling] JSONCompilationDatabase::loadFromBuffer retains the buffer, copy it.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-12-04T21:54:55+01:00
New Revision: 650e04e179c9d355cd6d8f9a108d60c7969d24ca

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

LOG: [Tooling] JSONCompilationDatabase::loadFromBuffer retains the buffer, copy 
it.

This function doesn't seem to be used in-tree outside tests.
However clangd wants to use it soon, and having the CDB be self-contained seems
reasonable.

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

Added: 


Modified: 
clang/lib/Tooling/JSONCompilationDatabase.cpp
clang/unittests/Tooling/CompilationDatabaseTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/JSONCompilationDatabase.cpp 
b/clang/lib/Tooling/JSONCompilationDatabase.cpp
index 4aa16853ce45..2d8847a7a327 100644
--- a/clang/lib/Tooling/JSONCompilationDatabase.cpp
+++ b/clang/lib/Tooling/JSONCompilationDatabase.cpp
@@ -217,7 +217,7 @@ JSONCompilationDatabase::loadFromBuffer(StringRef 
DatabaseString,
 std::string ,
 JSONCommandLineSyntax Syntax) {
   std::unique_ptr DatabaseBuffer(
-  llvm::MemoryBuffer::getMemBuffer(DatabaseString));
+  llvm::MemoryBuffer::getMemBufferCopy(DatabaseString));
   std::unique_ptr Database(
   new JSONCompilationDatabase(std::move(DatabaseBuffer), Syntax));
   if (!Database->parse(ErrorMessage))

diff  --git a/clang/unittests/Tooling/CompilationDatabaseTest.cpp 
b/clang/unittests/Tooling/CompilationDatabaseTest.cpp
index 9e2342894f71..168a1d6f0fb0 100644
--- a/clang/unittests/Tooling/CompilationDatabaseTest.cpp
+++ b/clang/unittests/Tooling/CompilationDatabaseTest.cpp
@@ -172,13 +172,15 @@ TEST(JSONCompilationDatabase, GetAllCompileCommands) {
 }
 
 static CompileCommand findCompileArgsInJsonDatabase(StringRef FileName,
-StringRef JSONDatabase,
+std::string JSONDatabase,
 std::string ) 
{
   std::unique_ptr Database(
   JSONCompilationDatabase::loadFromBuffer(JSONDatabase, ErrorMessage,
   JSONCommandLineSyntax::Gnu));
   if (!Database)
 return CompileCommand();
+  // Overwrite the string to verify we're not reading from it later.
+  JSONDatabase.assign(JSONDatabase.size(), '*');
   std::vector Commands = 
Database->getCompileCommands(FileName);
   EXPECT_LE(Commands.size(), 1u);
   if (Commands.empty())



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

[PATCH] D92354: [clang] add a new `swift_attr` attribute

[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/D92354/new/

https://reviews.llvm.org/D92354

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

[PATCH] D92355: [clang] add a `swift_async_name` attribute

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!


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

https://reviews.llvm.org/D92355

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

[PATCH] D92355: [clang] add a `swift_async_name` attribute

[Doug Gregor via Phabricator via cfe-commits]

doug.gregor accepted this revision.
doug.gregor added a comment.

Thank you!


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

https://reviews.llvm.org/D92355

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

[PATCH] D92680: Frontend: Migrate to FileEntryRef in CompilerInstance::InitializeSourceManager, NFC

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

dexonsmith created this revision.
dexonsmith added reviewers: jansvoboda11, JDevlieghere, arphaman.
Herald added a subscriber: ributzka.
dexonsmith requested review of this revision.
Herald added a project: clang.

Use `FileManager::getVirtualFileRef` to get the virtual file for stdin,
and add an overload of `SourceManager::overrideFileContents` that takes
a `FileEntryRef`, migrating `CompilerInstance::InitializeSourceManager`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D92680

Files:
  clang/include/clang/Basic/SourceManager.h
  clang/lib/Frontend/CompilerInstance.cpp


Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -869,8 +869,8 @@
 }
 std::unique_ptr SB = std::move(SBOrErr.get());
 
-const FileEntry *File = FileMgr.getVirtualFile(SB->getBufferIdentifier(),
-   SB->getBufferSize(), 0);
+FileEntryRef File = FileMgr.getVirtualFileRef(SB->getBufferIdentifier(),
+  SB->getBufferSize(), 0);
 SourceMgr.setMainFileID(
 SourceMgr.createFileID(File, SourceLocation(), Kind));
 SourceMgr.overrideFileContents(File, std::move(SB));
Index: clang/include/clang/Basic/SourceManager.h
===
--- clang/include/clang/Basic/SourceManager.h
+++ clang/include/clang/Basic/SourceManager.h
@@ -958,6 +958,10 @@
   /// data in the given source file.
   void overrideFileContents(const FileEntry *SourceFile,
 std::unique_ptr Buffer);
+  void overrideFileContents(FileEntryRef SourceFile,
+std::unique_ptr Buffer) {
+overrideFileContents((), std::move(Buffer));
+  }
 
   /// Override the given source file with another one.
   ///


Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -869,8 +869,8 @@
 }
 std::unique_ptr SB = std::move(SBOrErr.get());
 
-const FileEntry *File = FileMgr.getVirtualFile(SB->getBufferIdentifier(),
-   SB->getBufferSize(), 0);
+FileEntryRef File = FileMgr.getVirtualFileRef(SB->getBufferIdentifier(),
+  SB->getBufferSize(), 0);
 SourceMgr.setMainFileID(
 SourceMgr.createFileID(File, SourceLocation(), Kind));
 SourceMgr.overrideFileContents(File, std::move(SB));
Index: clang/include/clang/Basic/SourceManager.h
===
--- clang/include/clang/Basic/SourceManager.h
+++ clang/include/clang/Basic/SourceManager.h
@@ -958,6 +958,10 @@
   /// data in the given source file.
   void overrideFileContents(const FileEntry *SourceFile,
 std::unique_ptr Buffer);
+  void overrideFileContents(FileEntryRef SourceFile,
+std::unique_ptr Buffer) {
+overrideFileContents((), std::move(Buffer));
+  }
 
   /// Override the given source file with another one.
   ///
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Jon Roelofs via Phabricator via cfe-commits]

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

LGTM




Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:105
+
+  if (!llvm::sys::fs::exists(SysRootDir))
+return std::string();

Why not always add it, even if it doesn't exist? That's an easier failure mode 
to diagnose as a user, since you'll see the compiler appending paths that 
aren't there, rather than having magic behavior.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:108
+
+  return std::string(SysRootDir.str());
+}

Small string has an implicit conversion to std::string, so you can just `return 
SysRootDir;` here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92677

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

[PATCH] D92516: ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC

[Duncan P. N. Exon Smith 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 rGd10f9863a5ac: ADT: Migrate users of AlignedCharArrayUnion to 
std::aligned_union_t, NFC (authored by dexonsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92516

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/AST/ParentMapContext.h
  clang/include/clang/Frontend/PrecompiledPreamble.h
  clang/include/clang/Sema/Overload.h
  clang/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp
  clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp
  clang/lib/Lex/PPDirectives.cpp
  llvm/include/llvm/ADT/DenseMap.h
  llvm/include/llvm/ADT/IntervalMap.h
  llvm/include/llvm/CodeGen/DIE.h
  llvm/include/llvm/CodeGen/SelectionDAGNodes.h
  llvm/include/llvm/Support/Error.h
  llvm/include/llvm/Support/ErrorOr.h
  llvm/include/llvm/Support/JSON.h
  llvm/include/llvm/Support/TrailingObjects.h
  llvm/include/llvm/Support/YAMLTraits.h
  llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp

Index: llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
===
--- llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
+++ llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp
@@ -26,7 +26,6 @@
 #include "llvm/IR/PatternMatch.h"
 #include "llvm/IR/Type.h"
 #include "llvm/IR/Value.h"
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/KnownBits.h"
 #include "llvm/Transforms/InstCombine/InstCombiner.h"
@@ -120,7 +119,7 @@
 // is overkill of this end.
 short IntVal = 0;
 
-AlignedCharArrayUnion FpValBuf;
+std::aligned_union_t<1, APFloat> FpValBuf;
   };
 
   /// FAddend is used to represent floating-point addend. An addend is
Index: llvm/include/llvm/Support/YAMLTraits.h
===
--- llvm/include/llvm/Support/YAMLTraits.h
+++ llvm/include/llvm/Support/YAMLTraits.h
@@ -15,7 +15,6 @@
 #include "llvm/ADT/StringMap.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Twine.h"
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/Regex.h"
@@ -1311,7 +1310,7 @@
   TNorm* operator->() { return BufPtr; }
 
 private:
-  using Storage = AlignedCharArrayUnion;
+  using Storage = std::aligned_union_t<1, TNorm>;
 
   Storage   Buffer;
   IO   
@@ -1348,7 +1347,7 @@
   TNorm* operator->() { return BufPtr; }
 
 private:
-  using Storage = AlignedCharArrayUnion;
+  using Storage = std::aligned_union_t<1, TNorm>;
 
   Storage   Buffer;
   IO   
Index: llvm/include/llvm/Support/TrailingObjects.h
===
--- llvm/include/llvm/Support/TrailingObjects.h
+++ llvm/include/llvm/Support/TrailingObjects.h
@@ -46,7 +46,6 @@
 #ifndef LLVM_SUPPORT_TRAILINGOBJECTS_H
 #define LLVM_SUPPORT_TRAILINGOBJECTS_H
 
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Alignment.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/MathExtras.h"
Index: llvm/include/llvm/Support/JSON.h
===
--- llvm/include/llvm/Support/JSON.h
+++ llvm/include/llvm/Support/JSON.h
@@ -479,8 +479,8 @@
   };
   // All members mutable, see moveFrom().
   mutable ValueType Type;
-  mutable llvm::AlignedCharArrayUnion
+  mutable std::aligned_union_t<1, bool, double, int64_t, llvm::StringRef,
+   std::string, json::Array, json::Object>
   Union;
   friend bool operator==(const Value &, const Value &);
 };
Index: llvm/include/llvm/Support/ErrorOr.h
===
--- llvm/include/llvm/Support/ErrorOr.h
+++ llvm/include/llvm/Support/ErrorOr.h
@@ -15,7 +15,6 @@
 #ifndef LLVM_SUPPORT_ERROROR_H
 #define LLVM_SUPPORT_ERROROR_H
 
-#include "llvm/Support/AlignOf.h"
 #include 
 #include 
 #include 
@@ -253,8 +252,8 @@
   }
 
   union {
-AlignedCharArrayUnion TStorage;
-AlignedCharArrayUnion ErrorStorage;
+std::aligned_union_t<1, storage_type> TStorage;
+std::aligned_union_t<1, std::error_code> ErrorStorage;
   };
   bool HasError : 1;
 };
Index: llvm/include/llvm/Support/Error.h
===
--- llvm/include/llvm/Support/Error.h
+++ llvm/include/llvm/Support/Error.h
@@ -19,7 +19,6 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/Config/abi-breaking.h"
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/ErrorHandling.h"
@@ -678,8 +677,8 @@
   }
 
   union {
-AlignedCharArrayUnion TStorage;

[clang] d10f986 - ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-12-04T12:34:49-08:00
New Revision: d10f9863a5ac1cb681af07719650c44b48f289ce

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

LOG: ADT: Migrate users of AlignedCharArrayUnion to std::aligned_union_t, NFC

Prepare to delete `AlignedCharArrayUnion` by migrating its users over to
`std::aligned_union_t`.

I will delete `AlignedCharArrayUnion` and its tests in a follow-up
commit so that it's easier to revert in isolation in case some
downstream wants to keep using it.

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

Added: 


Modified: 
clang/include/clang/AST/APValue.h
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/ASTTypeTraits.h
clang/include/clang/AST/ParentMapContext.h
clang/include/clang/Frontend/PrecompiledPreamble.h
clang/include/clang/Sema/Overload.h
clang/lib/DirectoryWatcher/linux/DirectoryWatcher-linux.cpp
clang/lib/DirectoryWatcher/windows/DirectoryWatcher-windows.cpp
clang/lib/Lex/PPDirectives.cpp
llvm/include/llvm/ADT/DenseMap.h
llvm/include/llvm/ADT/IntervalMap.h
llvm/include/llvm/CodeGen/DIE.h
llvm/include/llvm/CodeGen/SelectionDAGNodes.h
llvm/include/llvm/Support/Error.h
llvm/include/llvm/Support/ErrorOr.h
llvm/include/llvm/Support/JSON.h
llvm/include/llvm/Support/TrailingObjects.h
llvm/include/llvm/Support/YAMLTraits.h
llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp

Removed: 




diff  --git a/clang/include/clang/AST/APValue.h 
b/clang/include/clang/AST/APValue.h
index eded34808ad7..d6a33c13b096 100644
--- a/clang/include/clang/AST/APValue.h
+++ b/clang/include/clang/AST/APValue.h
@@ -20,7 +20,7 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/PointerIntPair.h"
 #include "llvm/ADT/PointerUnion.h"
-#include "llvm/Support/AlignOf.h"
+#include 
 
 namespace clang {
   class AddrLabelExpr;
@@ -286,9 +286,10 @@ class APValue {
   struct MemberPointerData;
 
   // We ensure elsewhere that Data is big enough for LV and MemberPointerData.
-  typedef llvm::AlignedCharArrayUnion DataType;
+  typedef std::aligned_union_t<1, void *, APSInt, APFloat, ComplexAPSInt,
+   ComplexAPFloat, Vec, Arr, StructData, UnionData,
+   AddrLabelDiffData>
+  DataType;
   static const size_t DataSize = sizeof(DataType);
 
   DataType Data;

diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 8c0930237583..7d58b426a3df 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -57,7 +57,6 @@
 #include "llvm/ADT/TinyPtrVector.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/ADT/iterator_range.h"
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Casting.h"
 #include "llvm/Support/Compiler.h"

diff  --git a/clang/include/clang/AST/ASTTypeTraits.h 
b/clang/include/clang/AST/ASTTypeTraits.h
index 8791e41b9ac3..ea3da8d90c5b 100644
--- a/clang/include/clang/AST/ASTTypeTraits.h
+++ b/clang/include/clang/AST/ASTTypeTraits.h
@@ -22,7 +22,7 @@
 #include "clang/AST/TypeLoc.h"
 #include "clang/Basic/LLVM.h"
 #include "llvm/ADT/DenseMapInfo.h"
-#include "llvm/Support/AlignOf.h"
+#include 
 
 namespace llvm {
 
@@ -456,9 +456,8 @@ class DynTypedNode {
   /// \c QualTypes, \c NestedNameSpecifierLocs, \c TypeLocs,
   /// \c TemplateArguments and \c TemplateArgumentLocs on the other hand do not
   /// have storage or unique pointers and thus need to be stored by value.
-  llvm::AlignedCharArrayUnion
+  std::aligned_union_t<1, const void *, TemplateArgument, TemplateArgumentLoc,
+   NestedNameSpecifierLoc, QualType, TypeLoc>
   Storage;
 };
 

diff  --git a/clang/include/clang/AST/ParentMapContext.h 
b/clang/include/clang/AST/ParentMapContext.h
index a0412380a864..a15790605a3d 100644
--- a/clang/include/clang/AST/ParentMapContext.h
+++ b/clang/include/clang/AST/ParentMapContext.h
@@ -89,7 +89,7 @@ class TraversalKindScope {
 /// Container for either a single DynTypedNode or for an ArrayRef to
 /// DynTypedNode. For use with ParentMap.
 class DynTypedNodeList {
-  llvm::AlignedCharArrayUnion> Storage;
+  std::aligned_union_t<1, DynTypedNode, ArrayRef> Storage;
   bool IsSingleNode;
 
 public:

diff  --git a/clang/include/clang/Frontend/PrecompiledPreamble.h 
b/clang/include/clang/Frontend/PrecompiledPreamble.h
index cea39bfec95d..1f768310d0b2 100644
--- a/clang/include/clang/Frontend/PrecompiledPreamble.h
+++ b/clang/include/clang/Frontend/PrecompiledPreamble.h
@@ -17,7 +17,6 @@
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/IntrusiveRefCntPtr.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/Support/AlignOf.h"
 #include "llvm/Support/MD5.h"
 

[PATCH] D92436: [Time-report] Add a flag -ftime-report={per-pass,per-pass-run} to control the pass timing aggregation

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 309618.
ychen added a comment.

- fix rebase error


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92436

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/FrontendOptions.h
  clang/include/clang/Frontend/Utils.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CMakeLists.txt
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/FrontendTiming.cpp
  clang/test/Driver/time-report.c
  clang/test/Misc/time-passes.c
  llvm/include/llvm/IR/PassTimingInfo.h
  llvm/include/llvm/Pass.h
  llvm/lib/IR/PassTimingInfo.cpp
  llvm/test/Other/time-passes.ll

Index: llvm/test/Other/time-passes.ll
===
--- llvm/test/Other/time-passes.ll
+++ llvm/test/Other/time-passes.ll
@@ -1,9 +1,15 @@
 ; RUN: opt -enable-new-pm=0 < %s -disable-output -instcombine -instcombine -licm -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-LEGACY
 ; RUN: opt -enable-new-pm=0 < %s -disable-output -instcombine -instcombine -licm -licm -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-LEGACY --check-prefix=TIME-DOUBLE-LICM-LEGACY
-; RUN: opt < %s -disable-output -passes='instcombine,instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW
-; RUN: opt < %s -disable-output -passes='instcombine,loop(licm),instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW -check-prefix=TIME-DOUBLE-LICM-NEW
 ; RUN: opt < %s -disable-output -passes='default' -time-passes 2>&1 | FileCheck %s --check-prefix=TIME
 ;
+; For new pass manager, check that -time-passes-per-run emit one report for each pass run.
+; RUN: opt < %s -disable-output -passes='instcombine,instcombine,loop(licm)' -time-passes-per-run 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW
+; RUN: opt < %s -disable-output -passes='instcombine,loop(licm),instcombine,loop(licm)' -time-passes-per-run 2>&1 | FileCheck %s --check-prefix=TIME --check-prefix=TIME-NEW -check-prefix=TIME-DOUBLE-LICM-NEW
+;
+; For new pass manager, check that -time-passes emit one report for each pass.
+; RUN: opt < %s -disable-output -passes='instcombine,instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefixes=TIME,TIME-NEW-PER-PASS
+; RUN: opt < %s -disable-output -passes='instcombine,loop(licm),instcombine,loop(licm)' -time-passes 2>&1 | FileCheck %s --check-prefixes=TIME,TIME-NEW-PER-PASS
+;
 ; The following 4 test runs verify -info-output-file interaction (default goes to stderr, '-' goes to stdout).
 ; RUN: opt -enable-new-pm=0 < %s -disable-output -O2 -time-passes -info-output-file='-' 2>/dev/null | FileCheck %s --check-prefix=TIME
 ; RUN: opt < %s -disable-output -passes='default' -time-passes -info-output-file='-' 2>/dev/null | FileCheck %s --check-prefix=TIME
@@ -46,6 +52,15 @@
 ; TIME-NEW-DAG:  VerifierPass
 ; TIME-NEW-DAG:  DominatorTreeAnalysis
 ; TIME-NEW-DAG:  TargetLibraryAnalysis
+; TIME-NEW-PER-PASS-DAG:   InstCombinePass
+; TIME-NEW-PER-PASS-DAG:   LICMPass
+; TIME-NEW-PER-PASS-DAG:   LCSSAPass
+; TIME-NEW-PER-PASS-DAG:   LoopSimplifyPass
+; TIME-NEW-PER-PASS-DAG:   ScalarEvolutionAnalysis
+; TIME-NEW-PER-PASS-DAG:   LoopAnalysis
+; TIME-NEW-PER-PASS-DAG:   VerifierPass
+; TIME-NEW-PER-PASS-DAG:   DominatorTreeAnalysis
+; TIME-NEW-PER-PASS-DAG:   TargetLibraryAnalysis
 ; TIME: Total{{$}}
 
 define i32 @foo() {
Index: llvm/lib/IR/PassTimingInfo.cpp
===
--- llvm/lib/IR/PassTimingInfo.cpp
+++ llvm/lib/IR/PassTimingInfo.cpp
@@ -35,11 +35,17 @@
 namespace llvm {
 
 bool TimePassesIsEnabled = false;
+bool TimePassesPerRun = false;
 
 static cl::opt EnableTiming(
 "time-passes", cl::location(TimePassesIsEnabled), cl::Hidden,
 cl::desc("Time each pass, printing elapsed time for each on exit"));
 
+static cl::opt EnableTimingPerRun(
+"time-passes-per-run", cl::location(TimePassesPerRun), cl::Hidden,
+cl::desc("Time each pass run, printing elapsed time for each run on exit"),
+cl::callback([](const bool &) { TimePassesIsEnabled = true; }));
+
 namespace {
 namespace legacy {
 
@@ -165,6 +171,13 @@
 /// Returns the timer for the specified pass invocation of \p PassID.
 /// Each time it creates a new timer.
 Timer ::getPassTimer(StringRef PassID) {
+  if (!PerRun) {
+TimerVector  = TimingData[PassID];
+if (Timers.size() == 0)
+  Timers.emplace_back(new Timer(PassID, PassID, TG));
+return *Timers.front();
+  }
+
   // Take a vector of Timers created for this \p PassID and append
   // one more timer to it.
   TimerVector  = TimingData[PassID];
@@ -179,8 +192,12 

[PATCH] D92480: [llvm] Add asserts in (ThreadSafe)?RefCountedBase destructors

[David Blaikie via Phabricator via cfe-commits]

dblaikie added inline comments.



Comment at: llvm/include/llvm/Support/ManagedStatic.h:25
+// that are const with no params.
+template  struct HasRetainRelease {
+private:

Are there many uses that rely on this? I don't think it's really worth all this 
infrastructure - compared to having it supported on an as-needed basis, such as 
directly in TrueMatcherImpl's ctor and dtor.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92480

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

[PATCH] D91885: [clang-tidy] Add support for diagnostics with no location

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




Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:276
+  // Never ignore these.
+} else if (!Context.isCheckEnabled(Error.DiagnosticName) &&
+   Error.DiagLevel != ClangTidyError::Error) {

njames93 wrote:
> aaron.ballman wrote:
> > Perhaps this is a bad idea, but would it make sense to have 
> > `isCheckEnabled()` report `true` for `clang-tidy-config`? It's not really a 
> > check, so that's a bit odd, but it seems like anywhere we're testing this 
> > property we wouldn't want to ignore config issues?
> I didn't personally think that was a good way to go. This is the only real 
> place its used where you would get isCheckEnabled called with 
> `clang-tidy-config`.
Okay, that's good enough for me, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91885

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

[PATCH] D92617: [DWARF] Allow toolchain to adjust specified DWARF version.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added subscribers: scott.linder, JDevlieghere.
dblaikie added inline comments.



Comment at: clang/test/Driver/cuda-unsupported-debug-options.cu:22
+// Make sure we do not see any dwarf version other than 2, regardless of 
what's used on the host side.
+// CHECK-NOT: {{-dwarf-version=[^2]}}
 // CHECK: "-triple" "x86_64

tra wrote:
> MaskRay wrote:
> > A NOT pattern may easily become stale and do not actually check anything. 
> > Just turn to a positive pattern?
> In this case the issue is with the CHECK-NOT line above. I'll have to 
> replicate it around the positive match of `-dwarf-version` which would raise 
> more questions.
> 
> I wish filecheck would allow to `mark` a region and then run multiple matches 
> on it, instead of re-anchoring on each match. 
Sounds like you're looking for CHECK-DAG, maybe? ( 
https://llvm.org/docs/CommandGuide/FileCheck.html#the-check-dag-directive )



Comment at: clang/test/Driver/debug-options.c:364-366
+// GEMBED_2:  warning: debug information option '-gembed-source' is not 
supported for target
 // NOGEMBED_5-NOT:  "-gembed-source"
+// NOGEMBED_2-NOT:  warning: debug information option '-gembed-source' is not 
supported for target

This is a bit of a loss in fidelity - might need a new diagnostic message (or 
go hunting around for a more general purpose one than this one at least) to say 
'-gembed-source' is ignored when not using DWARFv5. (in the nvptx case it's 
"not supported on target", but in the existing cases covered by this test it's 
"not supported because the user requested DWARFv2", for instance)

@JDevlieghere & @scott.linder for thoughts on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92617

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

[PATCH] D68590: [clangd] Improve hover scopes for Objective-C code

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

I think there's still some more work to be done after this which might move 
some of this around:

- DocumentSymbol support: Currently categories show up as (anonymous) or 
 (see here 
).
- QualifiedNames for ObjC, see the conversation here 
), possibly 
`MyClass.property` and `MyClass(Category)->Ivar`? Someone from Apple might know 
more


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68590

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

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thank you for this cleanup!




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst:60
 - If copy to the destination array can overflow [1] and
-  ``AreSafeFunctionsAvailable`` is set to ``Yes``, ``y`` or non-zero and it is
+  ``AreSafeFunctionsAvailable`` is set to `true` and it is
   possible to obtain the capacity of the destination array then the new 
function

njames93 wrote:
> aaron.ballman wrote:
> > This edit loses information about also accepting `Yes` and `y` -- is that 
> > intentional (or were those unsupported before)?
> > 
> > FWIW, I'd be fine dropping support for alternate spellings of `true`.
> Having looked throughout the NotNullTerminatedResultCheck header/impl files, 
> I can't find any reference to `AreSafeFunctionsAvailable`.
> I can only guess this is meant to say WantToUseSafeFunctions. If that is the 
> case, `Yes` and `y` were never supported spellings.
> 
> Should this be changed to use that option name instead? cc @Charusso
> 
> FWIW I intend (in the near future) to extend boolean parsing for check 
> options to:
> `y|Y|yes|Yes|YES|true|True|TRUE|on|On|ON`
> `n|N|no|No|NO|false|False|FALSE|off|Off|OFF`.
> 
> Reason for this is we claim to use YAML for config format and according to 
> its specification, this is what is accepted as a boolean value. Ref 
> https://yaml.org/type/bool.html.
> Still need to keep the old integer method of specifying bools for backwards 
> compatibility reasons.
> 
> Should this be changed to use that option name instead? cc @Charusso

I think so, but that can be done in an NFC followup if you'd like.

> Reason for this is we claim to use YAML for config format and according to 
> its specification, this is what is accepted as a boolean value.

Oh, that's a good reason to support those spellings, thank you for clarifying.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

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

[PATCH] D92633: Add -f[no-]direct-access-external-data to deprecate -mpie-copy-relocations

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D92633#2434337 , @tmsriram wrote:

> In D92633#2434267 , @MaskRay wrote:
>
>> In D92633#2434231 , @tmsriram wrote:
>>
>>> Sorry just one more thing which is a bit concerning:
>>>
>>> When I do  :
>>>
>>> $ clang -fPIC -frxternal-data-access foo.c
>>>
>>> You will omit the GOT but this object can go into a shared object and break 
>>> the build as this does not apply to shared objects?  Should we allow this 
>>> at all for -fPIC?  I dont see a need for this but if you want to,  maybe 
>>> warn?  The user should know that this cannot go into a shared object right?
>>> I am also ok with commenting that this option can do bad things for -fPIC 
>>> and the user should know what they are doing.
>>
>> `clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie 
>> a.o` (producing an executable with either `-no-pie` or `-pie`) is fine.
>
> Yes, agreed. Putting this object into an executable (pie/no-pie) no matter 
> how you compile it  is always fine as long as the backend supports copy 
> relocations. No issues there.
>
>> For `-shared`, because an ELF linker assumes interposition for non-local 
>> STV_DEFAULT symbols by default, linking such an object files requires some 
>> mechanism to make it non-preemptible.
>
> Right, that was my point.  Without -fPIC, we can be guaranteed that it won't 
> go into a shared object and this case wouldn't arise.
>
>> The simplest is `clang -fPIC -fdirect-access-external-data -c a.c; ld 
>> -shared -Bsymbolic a.o`
>> Other mechanisms include: `--dynamic-list` (don't list the symbol) and 
>> `--version-script` (localize the symbol).
>> This is going to be tricky and I don't know how to fit the information into 
>> the few-line description of the option.
>
> How about making this option applicable for -fpie/fPIE and the default case 
> and *not allowing* it for -fPIC/-fpic?   That seems the safest approach.
>
>> I just checked how to make -fdirect-access-eternal-data work for -fno-pic 
>> (both TargetMachine::shouldAssumeDSOLocal and 
>> CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for 
>> Reloc::Static), unfortunately there are 200 tests needing updates. (This 
>> reminds me that LLVM doesn't get the default for dso_local right, so many 
>> tests have `dso_local` in ELF/COFF but no `dso_local` in Mach-O. 
>> Unfortunately it is extremely difficult to fix it today (D76561 
>> ))
>
> Ok, I lost you here a bit.  This should be fine for -fno-pic was my 
> understanding.
>
> Let me try to summarize the motivations of this patch:
>
> 1. Originally, the default build (fno-pie/fno-pic), always used direct access 
> for external globals resulting in copy relocations if it is truly external at 
> link time.  You want to change that to be able to not have copy relocations 
> with -fno-direct-access-external-data, and you claim this would be useful for 
> POWER, great!
> 2. Originally, with -fPIE and -fpie, -mpie-copy-relocations allowed direct 
> access to externals.  This was always safe because the object was guaranteed 
> to go into an executable.  The new option preserves this behavior so there is 
> **no concern**.

Yes for 1 and 2. This patch only makes the options work for -fpie (as the 
original -mpie-copy-relocations does).

1 will be a nice cleanup (to drop 2 lines from 
TargetMachine::shouldAssumeDSOLocal) but it may require some test updates and 
it looks like `CodeGen/MachineCSE.cpp` exposes a crashing bug that it cannot 
handle non-dso_local `external constant` in -relocation-model=static mode 
correctly...

> 3. Originally, there was no way to generate direct accesses to external 
> global variables with -fPIC/-fpic. That behavior will change if you support 
> -fdirect-access-external-data with -fPIC. **That is my concern that this adds 
> to the complexity and the user should know what they are doing.**
>
> Given 3), I am wondering if you really need this patch.  I will leave it to 
> you but please do consider the fact that opening up this option to -fPIC 
> might be a problem.

I agree. The behavior is not touched in this patch.
I think the existing -mpie-copy-relocations users should be aware that the 
option (-fdirect-access-external-data) should generally only be used with 
-fno-pic and -fpie.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92633

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

[PATCH] D92078: [asan] Default to -asan-use-private-alias=1

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added inline comments.



Comment at: compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp:4-5
 
-// RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared %s -o %dynamiclib1
-// RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared %s -o %dynamiclib2
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib1
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib2
 // RUN: %clangxx_asan -fno-rtti %s %ld_flags_rpath_exe1 %ld_flags_rpath_exe2 
-o %t

Is this going to work?



Comment at: compiler-rt/test/asan/TestCases/Linux/odr-vtable.cpp:5
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO1 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib1
+// RUN: %clangxx_asan -fno-rtti -DBUILD_SO2 -fPIC -shared -mllvm 
-asan-use-private-alias=0 %s -o %dynamiclib2
 // RUN: %clangxx_asan -fno-rtti %s %ld_flags_rpath_exe1 %ld_flags_rpath_exe2 
-o %t

vitalybuka wrote:
> now we don't test default behavior
> can you add CHECKs for alias=1 as well?
> same below
It was more about llvm/test/Instrumentation test


You just flipped to asan-use-private-alias=0 so we do not test =1.  it was an 
issue before but now as with that as default we need to test it.



Comment at: llvm/test/Instrumentation/AddressSanitizer/global_metadata.ll:1-4
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=0 
-asan-globals-live-support=1 -S | FileCheck %s
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=0 
-asan-globals-live-support=1 -S | FileCheck %s
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=0 
-asan-globals-live-support=1 -asan-mapping-scale=5 -S | FileCheck %s
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=0 
-asan-globals-live-support=1 -asan-mapping-scale=5 -S | FileCheck %s





Comment at: 
llvm/test/Instrumentation/AddressSanitizer/global_metadata_darwin.ll:4-6
 
-; RUN: opt < %s -asan -asan-module -enable-new-pm=0 
-asan-globals-live-support=1 -S | FileCheck %s
-; RUN: opt < %s -passes='asan-pipeline' -asan-globals-live-support=1 -S | 
FileCheck %s
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=0 
-asan-globals-live-support=1 -S | FileCheck %s
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=0 
-asan-globals-live-support=1 -S | FileCheck %s





Comment at: llvm/test/Instrumentation/AddressSanitizer/local_alias.ll:1-8
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -S | FileCheck %s 
--check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
+; RUN: opt < %s -passes='asan-pipeline' -S | FileCheck %s 
--check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
 ; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=1 
-S | FileCheck %s --check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
-; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=1 -S | 
FileCheck %s --check-prefixes=CHECK-ALIAS,CHECK-NOINDICATOR
-; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-odr-indicator=1 
-S | FileCheck %s --check-prefixes=CHECK-INDICATOR,CHECK-NOALIAS
-; RUN: opt < %s -passes='asan-pipeline' -asan-use-odr-indicator=1 -S | 
FileCheck %s --check-prefixes=CHECK-INDICATOR,CHECK-NOALIAS
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=0 -S | 
FileCheck %s --check-prefixes=CHECK-NOALIAS,CHECK-NOINDICATOR
+; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-odr-indicator=1 
-S | FileCheck %s --check-prefixes=CHECK-INDICATOR,CHECK-ALIAS
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-odr-indicator=1 -S | 
FileCheck %s --check-prefixes=CHECK-INDICATOR,CHECK-ALIAS
 ; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -asan-use-private-alias=1 
-asan-use-odr-indicator=1 -S | FileCheck %s 
--check-prefixes=CHECK-ALIAS,CHECK-INDICATOR

I didn't update FileCheck here



Comment at: llvm/test/Instrumentation/AddressSanitizer/odr-check-ignore.ll:1-2
-; RUN: opt < %s -asan -asan-module -enable-new-pm=0 -S | FileCheck %s 
-; RUN: opt < %s -passes='asan-pipeline' -S | FileCheck %s 
+; RUN: opt < %s -asan -asan-module -asan-use-private-alias=0 -enable-new-pm=0 
-S | FileCheck %s
+; RUN: opt < %s -passes='asan-pipeline' -asan-use-private-alias=0 -S | 
FileCheck %s
 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92078

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

[PATCH] D68590: [clangd] Improve hover support for Objective-C

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 309611.
dgoldman added a comment.

- Rebase + refactor, sorry for the long delay


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68590

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1988,7 +1988,8 @@
 HI.Name = "data";
 HI.Type = "char";
 HI.Kind = index::SymbolKind::Field;
-HI.NamespaceScope = "ObjC::"; // FIXME: fix it
+HI.LocalScope = "ObjC::";
+HI.NamespaceScope = "";
 HI.Definition = "char data";
   }},
   {
@@ -2019,6 +2020,67 @@
 HI.NamespaceScope = "";
 HI.Definition = "@interface MYObject\n@end";
   }},
+  {
+  R"cpp(
+  @interface MYObject
+  @end
+  @interface MYObject (Private)
+  @property(nonatomic, assign) int privateField;
+  @end
+
+  int someFunction() {
+MYObject *obj = [MYObject sharedInstance];
+return obj.[[private^Field]];
+  }
+  )cpp",
+  [](HoverInfo ) {
+HI.Name = "privateField";
+HI.Kind = index::SymbolKind::InstanceProperty;
+HI.LocalScope = "MYObject(Private)::";
+HI.NamespaceScope = "";
+HI.Definition = "@property(nonatomic, assign, unsafe_unretained, "
+"readwrite) int privateField;";
+  }},
+  {R"objc(
+@interface Foo
+@end
+
+@implementation Foo(Private)
++ (int)somePrivateMethod {
+  int [[res^ult]] = 2;
+  return result;
+}
+@end
+)objc",
+   [](HoverInfo ) {
+ HI.Name = "result";
+ HI.Definition = "int result = 2";
+ HI.Kind = index::SymbolKind::Variable;
+ HI.Type = "int";
+ HI.LocalScope = "+[Foo(Private) somePrivateMethod]::";
+ HI.NamespaceScope = "";
+ HI.Value = "2";
+   }},
+  {R"objc(
+@interface Foo
+@end
+
+@implementation Foo
+- (int)variadicArgMethod:(id)first, ... {
+  int [[res^ult]] = 0;
+  return result;
+}
+@end
+)objc",
+   [](HoverInfo ) {
+ HI.Name = "result";
+ HI.Definition = "int result = 0";
+ HI.Kind = index::SymbolKind::Variable;
+ HI.Type = "int";
+ HI.LocalScope = "-[Foo variadicArgMethod:, ...]::";
+ HI.NamespaceScope = "";
+ HI.Value = "0";
+   }},
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -22,6 +22,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclBase.h"
 #include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
@@ -60,12 +61,63 @@
   return Policy;
 }
 
+static llvm::StringRef getNameForObjCInterface(const ObjCInterfaceDecl *ID) {
+  return ID ? ID->getName() : "<>";
+}
+
+static std::string objcMethodLocalScope(const ObjCMethodDecl *Method) {
+  std::string Name;
+  llvm::raw_string_ostream OS(Name);
+  const ObjCInterfaceDecl *Class = Method->getClassInterface();
+
+  OS << (Method->isInstanceMethod() ? '-' : '+') << '['
+ << getNameForObjCInterface(Class);
+
+  if (const ObjCCategoryImplDecl *CID =
+  dyn_cast(Method->getDeclContext()))
+OS << '(' << *CID << ')';
+
+  OS << ' ' << Method->getSelector().getAsString();
+  if (Method->isVariadic())
+OS << ", ...";
+
+  OS << ']';
+  return Name;
+}
+
+static std::string objcContainerLocalScope(const ObjCContainerDecl *C) {
+  if (const ObjCCategoryDecl *Category = dyn_cast(C)) {
+std::string Name;
+llvm::raw_string_ostream OS(Name);
+const ObjCInterfaceDecl *Class = Category->getClassInterface();
+OS << getNameForObjCInterface(Class) << '(' << Category->getName() << ')';
+return Name;
+  }
+  if (const ObjCCategoryImplDecl *CI = dyn_cast(C)) {
+std::string Name;
+llvm::raw_string_ostream OS(Name);
+const ObjCInterfaceDecl *Class = CI->getClassInterface();
+OS << getNameForObjCInterface(Class) << '(' << *CI << ')';
+return Name;
+  }
+  return C->getNameAsString();
+}
+
 /// Given a declaration \p D, return a human-readable string representing the
 /// local scope in which it is declared, i.e. class(es) and method name. Returns
 /// an empty string if it is not local.
 std::string 

[clang] 88c21f8 - [clang-format] NFC update in the overall clang-formatted status

[via cfe-commits]

Author: mydeveloperday
Date: 2020-12-04T20:10:10Z
New Revision: 88c21f8488646b6809d46c197077cfb40b5ac15b

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

LOG: [clang-format] NFC  update in the overall clang-formatted status

The current state of the clang-formatted-ness of the LLVM project hasn't been 
updated since June bring it upto date

Added: 


Modified: 
clang/docs/ClangFormattedStatus.rst

Removed: 




diff  --git a/clang/docs/ClangFormattedStatus.rst 
b/clang/docs/ClangFormattedStatus.rst
index 3e348eadd4ff..108351c16931 100644
--- a/clang/docs/ClangFormattedStatus.rst
+++ b/clang/docs/ClangFormattedStatus.rst
@@ -17,7 +17,7 @@ Clang Formatted Status
 ==
 
 :doc:`ClangFormattedStatus` describes the state of LLVM source
-tree in terms of conformance to :doc:`ClangFormat` as of: June 27, 2020 
11:36:24 (`eb50838ba08 
`_).
+tree in terms of conformance to :doc:`ClangFormat` as of: December 04, 2020 
17:56:14 (`840e651dc6d 
`_).
 
 
 .. list-table:: LLVM Clang-Format Status
@@ -49,6 +49,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `0`
  - `1`
  - :none:`0%`
+   * - clang/examples/CallSuperAttribute
+ - `1`
+ - `1`
+ - `0`
+ - :good:`100%`
* - clang/examples/clang-interpreter
  - `1`
  - `0`
@@ -60,10 +65,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `1`
  - :none:`0%`
* - clang/include/clang/Analysis
- - `14`
- - `3`
+ - `15`
+ - `4`
  - `11`
- - :part:`21%`
+ - :part:`26%`
* - clang/include/clang/Analysis/Analyses
  - `14`
  - `2`
@@ -84,30 +89,35 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `0`
  - `1`
  - :none:`0%`
+   * - clang/include/clang/APINotes
+ - `2`
+ - `2`
+ - `0`
+ - :good:`100%`
* - clang/include/clang/ARCMigrate
  - `3`
  - `0`
  - `3`
  - :none:`0%`
* - clang/include/clang/AST
- - `113`
- - `20`
+ - `114`
+ - `21`
  - `93`
- - :part:`17%`
+ - :part:`18%`
* - clang/include/clang/ASTMatchers
  - `5`
- - `1`
- - `4`
- - :part:`20%`
+ - `0`
+ - `5`
+ - :none:`0%`
* - clang/include/clang/ASTMatchers/Dynamic
  - `4`
  - `1`
  - `3`
  - :part:`25%`
* - clang/include/clang/Basic
- - `76`
- - `26`
- - `50`
+ - `78`
+ - `27`
+ - `51`
  - :part:`34%`
* - clang/include/clang/CodeGen
  - `9`
@@ -126,9 +136,9 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - :good:`100%`
* - clang/include/clang/Driver
  - `17`
- - `4`
- - `13`
- - :part:`23%`
+ - `5`
+ - `12`
+ - :part:`29%`
* - clang/include/clang/Edit
  - `5`
  - `1`
@@ -154,6 +164,11 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `2`
  - `5`
  - :part:`28%`
+   * - clang/include/clang/IndexSerialization
+ - `1`
+ - `1`
+ - `0`
+ - :good:`100%`
* - clang/include/clang/Lex
  - `29`
  - `4`
@@ -201,17 +216,17 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - :part:`25%`
* - clang/include/clang/StaticAnalyzer/Core/PathSensitive
  - `36`
- - `9`
- - `27`
- - :part:`25%`
+ - `10`
+ - `26`
+ - :part:`27%`
* - clang/include/clang/StaticAnalyzer/Frontend
  - `5`
- - `3`
  - `2`
- - :part:`60%`
+ - `3`
+ - :part:`40%`
* - clang/include/clang/Testing
- - `1`
- - `1`
+ - `2`
+ - `2`
  - `0`
  - :good:`100%`
* - clang/include/clang/Tooling
@@ -225,10 +240,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `0`
  - :good:`100%`
* - clang/include/clang/Tooling/Core
- - `3`
- - `1`
  - `2`
- - :part:`33%`
+ - `0`
+ - `2`
+ - :none:`0%`
* - clang/include/clang/Tooling/DependencyScanning
  - `5`
  - `4`
@@ -240,10 +255,10 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `2`
  - :none:`0%`
* - clang/include/clang/Tooling/Refactoring
- - `14`
- - `12`
+ - `15`
+ - `13`
  - `2`
- - :part:`85%`
+ - :part:`86%`
* - clang/include/clang/Tooling/Refactoring/Extract
  - `2`
  - `1`
@@ -265,20 +280,20 @@ tree in terms of conformance to :doc:`ClangFormat` as of: 
June 27, 2020 11:36:24
  - `1`
  - :part:`87%`
* - 

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 309605.
njames93 added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-argument-comment.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-misplaced-widening-cast.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-reserved-identifier.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-signed-char-misuse.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-sizeof-expression.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-string-constructor.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-suspicious-string-compare.rst
  
clang-tools-extra/docs/clang-tidy/checks/bugprone-unhandled-self-assignment.rst
  clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-macro-usage.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-narrowing-conversions.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-prefer-member-initializer.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-special-member-functions.rst
  clang-tools-extra/docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-definitions-in-headers.rst
  
clang-tools-extra/docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-unused-parameters.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-avoid-bind.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-make-shared.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-make-unique.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-pass-by-value.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-auto.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-bool-literals.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-default-member-init.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-emplace.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-equals-default.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-equals-delete.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-noexcept.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-override.rst
  
clang-tools-extra/docs/clang-tidy/checks/modernize-use-transparent-functors.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-using.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-for-range-copy.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-string-concatenation.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
  clang-tools-extra/docs/clang-tidy/checks/performance-move-const-arg.rst
  clang-tools-extra/docs/clang-tidy/checks/portability-simd-intrinsics.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-identifier-naming.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-implicit-bool-conversion.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-qualified-auto.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-access-specifiers.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-redundant-declaration.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-smartptr-get.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
  
clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst

Index: clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-uppercase-literal-suffix.rst
@@ -52,5 +52,5 @@
 
 .. option:: IgnoreMacros
 
-   If this option is set to non-zero (default is `1`), the check will not warn
+   If this option is set to `true` (default is `true`), the check will not warn
about literal suffixes inside macros.
Index: clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-simplify-boolean-expr.rst
@@ -77,10 +77,10 @@
 
 .. option:: ChainedConditionalReturn
 
-   If non-zero, conditional boolean return statements at the end of an
-   ``if/else if`` chain will 

[PATCH] D92652: [clang-tidy][docs] Update check options with boolean values instead of non-zero/0/1

[Nathan James via Phabricator via cfe-commits]

njames93 marked 3 inline comments as done.
njames93 added a subscriber: Charusso.
njames93 added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-not-null-terminated-result.rst:60
 - If copy to the destination array can overflow [1] and
-  ``AreSafeFunctionsAvailable`` is set to ``Yes``, ``y`` or non-zero and it is
+  ``AreSafeFunctionsAvailable`` is set to `true` and it is
   possible to obtain the capacity of the destination array then the new 
function

aaron.ballman wrote:
> This edit loses information about also accepting `Yes` and `y` -- is that 
> intentional (or were those unsupported before)?
> 
> FWIW, I'd be fine dropping support for alternate spellings of `true`.
Having looked throughout the NotNullTerminatedResultCheck header/impl files, I 
can't find any reference to `AreSafeFunctionsAvailable`.
I can only guess this is meant to say WantToUseSafeFunctions. If that is the 
case, `Yes` and `y` were never supported spellings.

Should this be changed to use that option name instead? cc @Charusso

FWIW I intend (in the near future) to extend boolean parsing for check options 
to:
`y|Y|yes|Yes|YES|true|True|TRUE|on|On|ON`
`n|N|no|No|NO|false|False|FALSE|off|Off|OFF`.

Reason for this is we claim to use YAML for config format and according to its 
specification, this is what is accepted as a boolean value. Ref 
https://yaml.org/type/bool.html.
Still need to keep the old integer method of specifying bools for backwards 
compatibility reasons.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92652

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