date:20210505

[PATCH] D101763: [analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU

2021-05-05 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/lib/CrossTU/CrossTranslationUnit.cpp:670
 return llvm::Error::success();
+  else if (index_error_code::no_error != InvocationListParsingError)
+return llvm::make_error(InvocationListParsingError);

martong wrote:
> The `if` here is superfluous because the condition must be `true` always, 
> otherwise we would have an `InvocationList`, wouldn't we?
> 
> Or we can have this condition, but then the `if (InvocatioList)` is not 
> needed.
This looks correct: We have an InvocationList if it is usable as result 
(initialized and no error). Otherwise there is an error or it is the first time 
the function is called. The second `if` checks for this condition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101763

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

[PATCH] D101763: [analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU

2021-05-05 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang/include/clang/CrossTU/CrossTranslationUnit.h:257
 llvm::Optional InvocationList;
+index_error_code InvocationListParsingError = index_error_code::no_error;
   };

martong wrote:
> I think it would be more consistent to make this an `llvm::Error`. I.e. we 
> would store the result of the whole `lazyInitInvocationList` in this member 
> variable. And as such, a better name could be `PreviousResult`. And this 
> could be an `Optional` to indicate that we have never called 
> `lazyInitInvocationList` before.
> This means we would check in `lazyInitInvocationList` whether the 
> `PreviousResult` is set and if yes is it an error. And if both conditions are 
> true then return with the stashed error.
The current solution looks good, probably it is more convenient to store the 
result in a `llvm::Error`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101763

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

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added a comment.

Could you please rebase to re-run the CI (that failed for sum unrelated reason)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[PATCH] D101860: [clang-format] Fix C# nullable-related errors

2021-05-05 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added a comment.

You can add a parent revision so that this patch will be applied upon its 
parent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101860

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

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

2021-05-05 Thread Nikita Popov via Phabricator via cfe-commits

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

LGTM. I can take care of reverting if there are issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101191

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

[PATCH] D101860: [clang-format] Fix C# nullable-related errors

2021-05-05 Thread Marek Kurdej via Phabricator via cfe-commits

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

LGTM pending CI.




Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2531
+  parseRecord();
+  // This does not apply for Java, JavaScript and C#.
+  if (Style.Language == FormatStyle::LK_Java ||

Nit when you're here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101860

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

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-05 Thread Andy Wingo via Phabricator via cfe-commits

wingo marked 3 inline comments as done.
wingo added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1324
+{LN->getChain(), Base}, LN->getMemoryVT(), LN->getMemOperand());
+return DAG.getMergeValues({GlobalGet, LN->getChain()}, DL);
+  }

tlively wrote:
> I'm not sure it's necessary to create a MERGE_NODES node here, since the the 
> GlobalGet already contains the chain. For a similar example, see how 
> LOAD_SPLAT nodes are created and returned.
I think it is 



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1324
+{LN->getChain(), Base}, LN->getMemoryVT(), LN->getMemOperand());
+return DAG.getMergeValues({GlobalGet, LN->getChain()}, DL);
+  }

wingo wrote:
> tlively wrote:
> > I'm not sure it's necessary to create a MERGE_NODES node here, since the 
> > the GlobalGet already contains the chain. For a similar example, see how 
> > LOAD_SPLAT nodes are created and returned.
> I think it is 
Aaaah thanks for this tip!  Took some finagling to find the right formula but I 
got it now.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td:268
 // are implied by virtual register uses and defs.
-multiclass LOCAL {
+multiclass LOCAL {
   let hasSideEffects = 0 in {

tlively wrote:
> In other places we have used the abbreviation `rc` as the name for 
> WebAssemblyRegClass parameters, but I don't know if we do that everywhere.
Good tip; apparently it's consistent except in WebAssemblyInstrRef.td, where I 
had initiailly looked.  Will go ahead and fix that one too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-05 Thread Andy Wingo via Phabricator via cfe-commits

wingo updated this revision to Diff 342963.
wingo marked 2 inline comments as done.
wingo added a comment.

Address feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

Files:
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrRef.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/global-get.ll
  llvm/test/CodeGen/WebAssembly/global-set.ll

Index: llvm/test/CodeGen/WebAssembly/global-set.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-set.ll
@@ -0,0 +1,57 @@
+; RUN: llc --mtriple=wasm32-unknown-unknown -asm-verbose=false < %s | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define void @set_i32_global(i32 %v) {
+; CHECK-LABEL: set_i32_global:
+; CHECK-NEXT: functype   set_i32_global (i32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i32_global
+; CHECK-NEXT: end_function
+  store i32 %v, i32 addrspace(1)* @i32_global
+  ret void
+}
+
+define void @set_i64_global(i64 %v) {
+; CHECK-LABEL: set_i64_global:
+; CHECK-NEXT: functype   set_i64_global (i64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i64_global
+; CHECK-NEXT: end_function
+  store i64 %v, i64 addrspace(1)* @i64_global
+  ret void
+}
+
+define void @set_f32_global(float %v) {
+; CHECK-LABEL: set_f32_global:
+; CHECK-NEXT: functype   set_f32_global (f32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f32_global
+; CHECK-NEXT: end_function
+  store float %v, float addrspace(1)* @f32_global
+  ret void
+}
+
+define void @set_f64_global(double %v) {
+; CHECK-LABEL: set_f64_global:
+; CHECK-NEXT: functype   set_f64_global (f64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f64_global
+; CHECK-NEXT: end_function
+  store double %v, double addrspace(1)* @f64_global
+  ret void
+}
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f32_global, f32
+; FIXME-CHECK: .globl f64_global
+; FIXME-CHECK: .globaltype f64_global, f64
Index: llvm/test/CodeGen/WebAssembly/global-get.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-get.ll
@@ -0,0 +1,54 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define i32 @return_i32_global() {
+; CHECK-LABEL: return_i32_global:
+; CHECK-NEXT: functype   return_i32_global () -> (i32)
+; CHECK-NEXT: global.get i32_global
+; CHECK-NEXT: end_function
+  %v = load i32, i32 addrspace(1)* @i32_global
+  ret i32 %v
+}
+
+define i64 @return_i64_global() {
+; CHECK-LABEL: return_i64_global:
+; CHECK-NEXT: functype   return_i64_global () -> (i64)
+; CHECK-NEXT: global.get i64_global
+; CHECK-NEXT: end_function
+  %v = load i64, i64 addrspace(1)* @i64_global
+  ret i64 %v
+}
+
+define float @return_f32_global() {
+; CHECK-LABEL: return_f32_global:
+; CHECK-NEXT: functype   return_f32_global () -> (f32)
+; CHECK-NEXT: global.get f32_global
+; CHECK-NEXT: end_function
+  %v = load float, float addrspace(1)* @f32_global
+  ret float %v
+}
+
+define double @return_f64_global() {
+; CHECK-LABEL: return_f64_global:
+; CHECK-NEXT: functype   return_f64_global () -> (f64)
+; CHECK-NEXT: global.get f64_global
+; CHECK-NEXT: end_function
+  %v = load double, double addrspace(1)* @f64_global
+  ret double %v
+}
+
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f32_global, f32
+; FIXME-CHECK: .globl f64_global
+; FIXME-CHECK: .globaltype f64_global, f64
Index: ll

[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-05-05 Thread David Spickett via Phabricator via cfe-commits

DavidSpickett added a reviewer: ostannard.
DavidSpickett added a subscriber: ostannard.
DavidSpickett added a comment.

All my comments have been answered. Perhaps @ostannard can check 
AArch64InstrInfo.cpp ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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

[PATCH] D101884: [WebAssembly] Fix constness of pointer params to load intrinsics

2021-05-05 Thread Heejin Ahn via Phabricator via cfe-commits

aheejin added a comment.

Why do only these instructions have `const`? It doesn't apply to other 
read-only arguments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101884

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

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-05 Thread Andy Wingo via Phabricator via cfe-commits

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

Pull in fixes from D101140 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

Files:
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrRef.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/global-get.ll
  llvm/test/CodeGen/WebAssembly/global-set.ll

Index: llvm/test/CodeGen/WebAssembly/global-set.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-set.ll
@@ -0,0 +1,57 @@
+; RUN: llc --mtriple=wasm32-unknown-unknown -asm-verbose=false < %s | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define void @set_i32_global(i32 %v) {
+; CHECK-LABEL: set_i32_global:
+; CHECK-NEXT: functype   set_i32_global (i32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i32_global
+; CHECK-NEXT: end_function
+  store i32 %v, i32 addrspace(1)* @i32_global
+  ret void
+}
+
+define void @set_i64_global(i64 %v) {
+; CHECK-LABEL: set_i64_global:
+; CHECK-NEXT: functype   set_i64_global (i64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i64_global
+; CHECK-NEXT: end_function
+  store i64 %v, i64 addrspace(1)* @i64_global
+  ret void
+}
+
+define void @set_f32_global(float %v) {
+; CHECK-LABEL: set_f32_global:
+; CHECK-NEXT: functype   set_f32_global (f32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f32_global
+; CHECK-NEXT: end_function
+  store float %v, float addrspace(1)* @f32_global
+  ret void
+}
+
+define void @set_f64_global(double %v) {
+; CHECK-LABEL: set_f64_global:
+; CHECK-NEXT: functype   set_f64_global (f64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f64_global
+; CHECK-NEXT: end_function
+  store double %v, double addrspace(1)* @f64_global
+  ret void
+}
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f32_global, f32
+; FIXME-CHECK: .globl f64_global
+; FIXME-CHECK: .globaltype f64_global, f64
Index: llvm/test/CodeGen/WebAssembly/global-get.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-get.ll
@@ -0,0 +1,54 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define i32 @return_i32_global() {
+; CHECK-LABEL: return_i32_global:
+; CHECK-NEXT: functype   return_i32_global () -> (i32)
+; CHECK-NEXT: global.get i32_global
+; CHECK-NEXT: end_function
+  %v = load i32, i32 addrspace(1)* @i32_global
+  ret i32 %v
+}
+
+define i64 @return_i64_global() {
+; CHECK-LABEL: return_i64_global:
+; CHECK-NEXT: functype   return_i64_global () -> (i64)
+; CHECK-NEXT: global.get i64_global
+; CHECK-NEXT: end_function
+  %v = load i64, i64 addrspace(1)* @i64_global
+  ret i64 %v
+}
+
+define float @return_f32_global() {
+; CHECK-LABEL: return_f32_global:
+; CHECK-NEXT: functype   return_f32_global () -> (f32)
+; CHECK-NEXT: global.get f32_global
+; CHECK-NEXT: end_function
+  %v = load float, float addrspace(1)* @f32_global
+  ret float %v
+}
+
+define double @return_f64_global() {
+; CHECK-LABEL: return_f64_global:
+; CHECK-NEXT: functype   return_f64_global () -> (f64)
+; CHECK-NEXT: global.get f64_global
+; CHECK-NEXT: end_function
+  %v = load double, double addrspace(1)* @f64_global
+  ret double %v
+}
+
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHEC

[PATCH] D101870: [clangd] Check if macro is already in the IdentifierTable before loading it

2021-05-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added a comment.

oh wow thanks! would you mind adding a test case like:

  TEST(CompletionTest, NoCrashDueToMacroOrdering) {
EXPECT_THAT(completions(R"cpp(
  #define ECHO(X) X
  #define ECHO2(X) ECHO(X)
  int finish_preamble = E^CHO(2);)cpp")
.Completions,
UnorderedElementsAre(Labeled("ECHO"), Labeled("ECHO2")));
  }

into clang-tools-extra/clangd/unittest/CodeCompleteTests.cpp ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101870

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

[PATCH] D101862: [clang-format] Rename common types between C#/JS

2021-05-05 Thread Marek Kurdej via Phabricator via cfe-commits

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

LGTM pending CI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101862

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

2021-05-05 Thread Marek Kurdej via Phabricator via cfe-commits

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

I like the idea, but we need more tests.




Comment at: clang/include/clang/Format/Format.h:93
 
+  /// if ``true``, when using static initialization for an array of structs
+  /// aligns the fields into columns

Why static?



Comment at: clang/include/clang/Format/Format.h:98-100
+  ///   {56, 23,"hello" },
+  ///   {-1, 93463, "world" },
+  ///   {7,  5, "!!"}

Why not like this?
Why all these spaces?



Comment at: clang/include/clang/Format/Format.h:103
+  /// \endcode
+  bool AlignArrayOfStructuresInit;
+

Maybe simplify the name. Should it really apply only to initialization, why not 
assignment?
Also, don't use "Init" but "Initialization" if need be.



Comment at: clang/unittests/Format/FormatTest.cpp:16371
+   Style);
+}
+

I think we need more tests:
* with a comma after the last element of array
* with assignment and not only initialization?
* without `struct` keyword
* with short lines/long values to see how wrapping behaves
  * also, with multiple string literals in one struct, e.g. `"hello" "world"` 
(that will get splitted into multiple lines)
* with non-plain-array types (i.e. missing `[]`/`[3]`)
* interaction with other Align* options (e.g. `AlignConsecutiveAssignments`, 
two arrays one after another, `AlignConsecutiveDeclarations`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Krasimir Georgiev via Phabricator via cfe-commits

krasimir accepted this revision.
krasimir added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:1563
+  if (Current.Previous) {
+bool isIdentifier =
+Style.Language == FormatStyle::LK_JavaScript

nit: `s/isIdentifier/IsIdentifier/` (LLVM style uses CamelCase for local 
variables)



Comment at: clang/unittests/Format/FormatTestCSharp.cpp:365
+
+  verifyFormat("test \?\?= ABC;", Style);
+  verifyFormat("test \?\?= true;", Style);

nit: you could use raw string literals for the `??=` test cases (e.g., `R"(test 
??= ABC;)"`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Krasimir Georgiev via Phabricator via cfe-commits

krasimir added inline comments.



Comment at: clang/lib/Format/FormatTokenLexer.cpp:135
   return;
+}
   }

nit: use spaces for indentation, no tabs (Phabricator makes it look this line 
starts with a tab character)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[clang] 4f4aa7b - Require asserts for clang/test/Headers/wasm.c

2021-05-05 Thread Hans Wennborg via cfe-commits


Author: Hans Wennborg
Date: 2021-05-05T11:42:18+02:00
New Revision: 4f4aa7b78df5544b0a1c07ee98475939c1175990

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

LOG: Require asserts for clang/test/Headers/wasm.c

The test doesn't pass in no-asserts builds, see comment on
https://reviews.llvm.org/D101805

Added: 


Modified: 
clang/test/Headers/wasm.c

Removed: 




diff  --git a/clang/test/Headers/wasm.c b/clang/test/Headers/wasm.c
index ceee5ec13eb3e..594da19b11375 100644
--- a/clang/test/Headers/wasm.c
+++ b/clang/test/Headers/wasm.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --force-update
-// REQUIRES: webassembly-registered-target
+// REQUIRES: webassembly-registered-target, asserts
 
 // RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown 
-msimd128 | FileCheck %s
 



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

[PATCH] D101805: [WebAssembly] Add codegen test for wasm_simd128.h

2021-05-05 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

The test was failing in no-asserts builds, see output at 
https://ghostbin.com/paste/UMtJl

I put "REQUIRES: asserts" on it in 4f4aa7b78df5544b0a1c07ee98475939c1175990 
 for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101805

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

[PATCH] D101640: [clang][patch] Add support for option -fextend-arguments={32,64}: widen integer arguments to int64 in unprototyped function calls

2021-05-05 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

Thanks! This LGTM from command-line perspective, but I'll let others judge the 
functional change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101640

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

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-05 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev updated this revision to Diff 342980.
v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

- Check if we can use death tests;
- Do not install clang-repl as being an early stage development.


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

https://reviews.llvm.org/D96033

Files:
  clang/include/clang/CodeGen/CodeGenAction.h
  clang/include/clang/Frontend/FrontendAction.h
  clang/include/clang/Interpreter/Interpreter.h
  clang/include/clang/Interpreter/Transaction.h
  clang/lib/CMakeLists.txt
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Interpreter/CMakeLists.txt
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/IncrementalParser.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/test/CMakeLists.txt
  clang/test/Interpreter/execute.cpp
  clang/test/Interpreter/sanity.c
  clang/test/lit.cfg.py
  clang/tools/CMakeLists.txt
  clang/tools/clang-repl/CMakeLists.txt
  clang/tools/clang-repl/ClangRepl.cpp
  clang/unittests/CMakeLists.txt
  clang/unittests/CodeGen/CMakeLists.txt
  clang/unittests/CodeGen/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/CMakeLists.txt
  clang/unittests/Interpreter/IncrementalProcessingTest.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- /dev/null
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -0,0 +1,122 @@
+//===- unittests/Interpreter/InterpreterTest.cpp --- Interpreter tests ===//
+//
+// 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
+//
+//===--===//
+//
+// Unit tests for Clang's Interpreter library.
+//
+//===--===//
+
+#include "clang/Interpreter/Interpreter.h"
+
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclGroup.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+
+#include "llvm/ADT/ArrayRef.h"
+
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+namespace {
+using Args = std::vector;
+static std::unique_ptr
+createInterpreter(const Args &ExtraArgs = {},
+  DiagnosticConsumer *Client = nullptr) {
+  Args ClangArgs = {"-Xclang", "-emit-llvm-only"};
+  ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
+  auto CI = cantFail(clang::IncrementalCompilerBuilder::create(ClangArgs));
+  if (Client)
+CI->getDiagnostics().setClient(Client, /*ShouldOwnClient=*/false);
+  return cantFail(clang::Interpreter::create(std::move(CI)));
+}
+
+TEST(InterpreterTest, Sanity) {
+  std::unique_ptr Interp = createInterpreter();
+  Transaction &R1(cantFail(Interp->Parse("void g(); void g() {}")));
+  EXPECT_EQ(2U, R1.Decls.size());
+
+  Transaction &R2(cantFail(Interp->Parse("int i;")));
+  EXPECT_EQ(1U, R2.Decls.size());
+}
+
+static std::string DeclToString(DeclGroupRef DGR) {
+  return llvm::cast(DGR.getSingleDecl())->getQualifiedNameAsString();
+}
+
+TEST(InterpreterTest, IncrementalInputTopLevelDecls) {
+  std::unique_ptr Interp = createInterpreter();
+  auto R1OrErr = Interp->Parse("int var1 = 42; int f() { return var1; }");
+  // gtest doesn't expand into explicit bool conversions.
+  EXPECT_TRUE(!!R1OrErr);
+  auto R1 = R1OrErr->Decls;
+  EXPECT_EQ(2U, R1.size());
+  EXPECT_EQ("var1", DeclToString(R1[0]));
+  EXPECT_EQ("f", DeclToString(R1[1]));
+
+  auto R2OrErr = Interp->Parse("int var2 = f();");
+  EXPECT_TRUE(!!R2OrErr);
+  auto R2 = R2OrErr->Decls;
+  EXPECT_EQ(1U, R2.size());
+  EXPECT_EQ("var2", DeclToString(R2[0]));
+}
+
+TEST(InterpreterTest, Errors) {
+  Args ExtraArgs = {"-Xclang", "-diagnostic-log-file", "-Xclang", "-"};
+
+  // Create the diagnostic engine with unowned consumer.
+  std::string DiagnosticOutput;
+  llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
+  auto DiagPrinter = std::make_unique(
+  DiagnosticsOS, new DiagnosticOptions());
+
+  auto Interp = createInterpreter(ExtraArgs, DiagPrinter.get());
+  auto Err = Interp->Parse("intentional_error v1 = 42; ").takeError();
+  using ::testing::HasSubstr;
+  EXPECT_THAT(DiagnosticsOS.str(),
+  HasSubstr("error: unknown type name 'intentional_error'"));
+  EXPECT_EQ("Parsing failed.", llvm::toString(std::move(Err)));
+
+#ifdef GTEST_HAS_DEATH_TEST
+  EXPECT_DEATH((void)Interp->Parse("int var1 = 42;"), "");
+#endif
+}
+
+// Here we test whether the user can mix declarations and statements. The
+// interpreter should be smart enough to recognize the declarations from the
+// statements and wrap the latter into a declaration,

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Jonathan B Coe via Phabricator via cfe-commits

jbcoe added a comment.

Thanks for this patch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[PATCH] D77598: Integral template argument suffix and cast printing

2021-05-05 Thread Pratyush Das via Phabricator via cfe-commits

reikdas updated this revision to Diff 342991.
reikdas added a comment.

Update diff to avoid printing type information if MSVCFormatting printing 
policy is enabled.


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

https://reviews.llvm.org/D77598

Files:
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/StmtDataCollectors.td
  clang/include/clang/AST/TemplateBase.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/TemplateBase.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/Analysis/eval-predefined-exprs.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p12.cpp
  clang/test/CXX/lex/lex.literal/lex.ext/p13.cpp
  clang/test/CodeGenCXX/debug-info-codeview-template-literal.cpp
  clang/test/CodeGenCXX/debug-info-codeview-template-type.cpp
  clang/test/SemaCXX/builtin-align-cxx.cpp
  clang/test/SemaCXX/cxx11-ast-print.cpp
  clang/test/SemaCXX/cxx1z-ast-print.cpp
  clang/test/SemaCXX/matrix-type-builtins.cpp
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp
  clang/test/SemaTemplate/delegating-constructors.cpp
  clang/test/SemaTemplate/matrix-type.cpp
  clang/test/SemaTemplate/temp_arg_enum_printing.cpp
  clang/test/SemaTemplate/temp_arg_nontype.cpp
  clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
  clang/tools/libclang/CIndex.cpp
  
clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/TemplateArgumentLocTraverser.cpp
@@ -20,7 +20,7 @@
 llvm::raw_string_ostream Stream(ArgStr);
 const TemplateArgument &Arg = ArgLoc.getArgument();
 
-Arg.print(Context->getPrintingPolicy(), Stream);
+Arg.print(Context->getPrintingPolicy(), Stream, /*IncludeType*/ true);
 Match(Stream.str(), ArgLoc.getLocation());
 return ExpectedLocationVisitor::
   TraverseTemplateArgumentLoc(ArgLoc);
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5185,8 +5185,9 @@
 SmallString<128> Str;
 llvm::raw_svector_ostream OS(Str);
 OS << *ClassSpec;
-printTemplateArgumentList(OS, ClassSpec->getTemplateArgs().asArray(),
-  Policy);
+printTemplateArgumentList(
+OS, ClassSpec->getTemplateArgs().asArray(), Policy,
+ClassSpec->getSpecializedTemplate()->getTemplateParameters());
 return cxstring::createDup(OS.str());
   }
 
Index: clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_nontype_cxx1z.cpp
@@ -528,3 +528,33 @@
 x1.f(x2);
   }
 }
+
+namespace TypeSuffix {
+  template  struct A {};
+  template <> struct A<1> { using type = int; }; // expected-note {{'A<1>::type' declared here}}
+  A<1L>::type a; // expected-error {{no type named 'type' in 'TypeSuffix::A<1L>'; did you mean 'A<1>::type'?}}
+
+  template  struct B {};
+  template <> struct B<1> { using type = int; }; // expected-note {{'B<1>::type' declared here}}
+  B<2>::type b;  // expected-error {{no type named 'type' in 'TypeSuffix::B<2>'; did you mean 'B<1>::type'?}}
+
+  template  struct C {};
+  template <> struct C<'a'> { using type = signed char; }; // expected-note {{'C<'a'>::type' declared here}}
+  C<(signed char)'a'>::type c; // expected-error {{no type named 'type' in 'TypeSuffix::C<(signed char)'a'>'; did you mean 'C<'a'>::type'?}}
+
+  template  struct D {};
+  template <> struct D<'a'> { using type = signed char; }; // expected-note {{'D<'a'>::type' declared here}}
+  D<'b'>::type d;  // expected-error {{no type named 'type' in 'TypeSuffix::D<'b'>'; did you mean 'D<'a'>::type'?}}
+
+  template  struct E {};
+  template <> struct E<'a'> { using type = unsigned char; }; // expected-note {{'E<'a'>::type' declared here}}
+  E<(unsigned char)'a'>::type e; // expected-error {{no type named 'type' in 'TypeSuffix::E<(unsigned char)'a'>'; did you mean 'E<'a'>::type'?}}
+
+  te

[PATCH] D100934: [clang][modules] Build inferred modules

2021-05-05 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

In D100934#2737130 , @dexonsmith 
wrote:

> In D100934#2735955 , @jansvoboda11 
> wrote:
>
>> 1. Fix `AsWritten` for umbrella headers/directories.
>> 2. Add tests to `clang/test/Modules`.
>
> It sounds like these two pieces could be done together (since the refactor 
> for `AsWritten` seems like it deserves a test), as a commit that adds support 
> for building inferred modules explicitly.
>
>> 3. Add tests to `clang/test/ClangScanDeps`, make the necessary changes to 
>> `Tooling/DependencyScanning`, add response file Python script.
>
> Followed by this, for changing clang-scan-deps to support scanning for 
> inferred modules.
>
> WDYT?

That sounds good to me.




Comment at: clang/test/ClangScanDeps/modules-inferred-explicit-build.m:13-17
+// RUN: %clang @%t.inferred.rsp -pedantic -Werror
+// RUN: %clang @%t.system.rsp -pedantic -Werror
+// RUN: %clang -x objective-c -fsyntax-only %t.dir/modules_cdb_input.cpp \
+// RUN:   -F%S/Inputs/frameworks -fmodules -fimplicit-module-maps \
+// RUN:   -pedantic -Werror @%t.tu.rsp

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > I feel like the clang invocations that build/use modules should be in 
> > > `clang/test/Modules`. Two independent things:
> > > - Can clang build inferred modules explicitly? (tested in 
> > > clang/test/Modules)
> > > - Can clang-scan-deps generate deps for inferred modules? (tested in 
> > > clang/test/ClangScanDeps)
> > I agree that we should test explicit build of inferred modules in 
> > `clang/test/Modules` (without `clang-scan-deps`). I'll look into it.
> > 
> > I'm not sure I'd be happy with only checking the dependencies produced by 
> > `clang-scan-deps` here. Testing that the generated command-line actually 
> > works is as important IMO, and it will be even more so when we start 
> > optimizing the command line (stripping out unused header search paths, 
> > definitions etc.).
> I'm not sure precisely what you mean by "works". I'm not sure just checking 
> if it still compiles tells us much. What's important is that the modified 
> options have the same semantics, and I think a subtle change that still 
> compiles is more likely than preventing compilation entirely.
> 
> I don't think it would scale to check for semantic problems here -- that 
> needs a body of testcases that covers all the things modules support.
> 
> One option would be to use the testcases (or a selection of them) in 
> clang/test/Modules, by adding an extra RUN line that builds 
> clang-scan-deps-discovered modules both with and without command-line 
> stripping. For most changes, we can arrange the AST block such that skipped 
> options won't affect it, and we could compare the hash of just that block. If 
> and when we start stripping ignored `-D` options we'll need something 
> smarter, but we can solve that problem later. (Ideally, this would just be a 
> mode in clang, `clang -Xclang -fmodules-depscan`, which does an initial 
> depscan and builds the modules in order. This might actually be an 
> improvement on the existing implicit modules.)
> 
> @Bigcheese, maybe you can weigh in? If you both think `clang -cc1` should be 
> tested here, I'm open to it. (In that case, though, this should not be 
> invoking `%clang`, but `%clang_cc1`, I think... or does the response file 
> create a driver command-line?)
> I'm not sure precisely what you mean by "works". I'm not sure just checking 
> if it still compiles tells us much. What's important is that the modified 
> options have the same semantics, and I think a subtle change that still 
> compiles is more likely than preventing compilation entirely.

I see, that's a good point.

> One option would be to use the testcases (or a selection of them) in 
> clang/test/Modules, by adding an extra RUN line that builds 
> clang-scan-deps-discovered modules both with and without command-line 
> stripping. For most changes, we can arrange the AST block such that skipped 
> options won't affect it, and we could compare the hash of just that block. If 
> and when we start stripping ignored `-D` options we'll need something 
> smarter, but we can solve that problem later. 

Using tests from `clang/test/Modules` sounds nice. What are your concerns 
regarding stripping `-D` options?

> In that case, though, this should not be invoking `%clang`, but `%clang_cc1`, 
> I think... or does the response file create a driver command-line?

The `Tooling/DependencyScanning` library already prepends the `"-cc1"` argument 
so that build tools using the API don't have to do that on their own.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100934

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

[PATCH] D101519: [C++4OpenCL] Fix reinterpret_cast of vectors and types with address spaces

2021-05-05 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added inline comments.



Comment at: clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp:1
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+

olestrohm wrote:
> Anastasia wrote:
> > Btw I assume your patch also allows reinterpret_cast between vectors? What 
> > happens if we cast b/w vector of 3 elements and vector of 4 elements?
> Yes, this is essentially the same as line 10, as int is treated as a 1 
> element vector, but I can add some more test cases that shows this more 
> specifically.
Yes, let's add a few test cases with vector to vector casts. I would especially 
suggest vec3 since it is treated at vec4 in storage I think...


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

https://reviews.llvm.org/D101519

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

[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

2021-05-05 Thread Hyundeok Park via Phabricator via cfe-commits

airglow923 created this revision.
airglow923 added a project: libc++.
airglow923 requested review of this revision.
Herald added a project: clang.
Herald added subscribers: libcxx-commits, cfe-commits.
Herald added a reviewer: libc++.

This revision is a patch for bug 50224 
.

The current implementation of `std::forward_list::swap` uses 
`propagate_on_container_move_assignment` for `noexcept` specification. This 
revision has been made in an attempt to change it to 
`propagate_on_container_swap`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101899

Files:
  clang/lib/Format/Format.cpp
  libcxx/include/forward_list


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -3054,7 +3054,7 @@
 
   LLVM_DEBUG(llvm::dbgs() << "Applying child configurations\n");
 
-  for (const auto& MemBuf : llvm::reverse(ChildFormatTextToApply)){
+  for (const auto &MemBuf : llvm::reverse(ChildFormatTextToApply)) {
 auto Ec = parseConfiguration(*MemBuf, &Style, AllowUnknownOptions,
  dropDiagnosticHandler);
 // It was already correctly parsed.


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -3054,7 +3054,7 @@
 
   LLVM_DEBUG(llvm::dbgs() << "Applying child configurations\n");
 
-  for (const auto& MemBuf : llvm::reverse(ChildFormatTextToApply)){
+  for (const auto &MemBuf : llvm::reverse(ChildFormatTextToApply)) {
 auto Ec = parseConfiguration(*MemBuf, &Style, AllowUnknownOptions,
  dropDiagnosticHandler);
 // It was already correctly parsed.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

2021-05-05 Thread Hyundeok Park via Phabricator via cfe-commits

airglow923 updated this revision to Diff 343011.

Repository:
  rCXX libc++

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

https://reviews.llvm.org/D101899

Files:
  libcxx/include/forward_list


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101873: [clang] Support clang -fpic -fno-semantic-interposition for AArch64

2021-05-05 Thread Peter Smith via Phabricator via cfe-commits

peter.smith added a comment.

I've no comments on the code in D101872  , 
and D10873  they look reasonable to me. I 
guess it is down to whether this is the right thing to do or not.

Just to check my understanding:

- Clang defaults to -fno-semantic-interposition (GCC I believe has the opposite 
default fsemantic-interposition)
- With this change code in the same translation unit that defines the global 
will use a local alias for the global rather than accessing via the GOT, but 
the global will still be defined with default visibility.
- Symbol interposing is still permitted at link time so the global can be 
interposed, but as the code is using a local alias it will still use the 
original value.
- Without this chang clang would use fhalf-no-semantic-interposition which I 
believe permits some assumptions about symbol interpositioning such as 
resolving some short range assembly pc-relative references to a local alias. 
These would be out of range if the symbol were interposed anyway.

If I've got this right, particularly the default  then this makes me nervous 
about the default behaviour as it could silently break some existing code. If a 
user had to opt in explicitly with -fno-semantic-interposition then fair enough.

Can you let me know, if I'm being overly cautious here? For example are 
programs that would be affected by this already broken by the 
half-no-semantic-interpositioning anyway? Is symbol interpositioning so rare 
that the X86 version of this didn't break anything? Have I got the default of 
-fno-semantic-interpositioning wrong?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101873

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

[PATCH] D101901: [AMDGPU][OpenMP] Fix clang driver crash when provided -c

2021-05-05 Thread Pushpinder Singh via Phabricator via cfe-commits

pdhaliwal created this revision.
pdhaliwal added reviewers: JonChesterfield, ronlieb, jdoerfert, ye-luo, 
tianshilei1992.
Herald added subscribers: kerbowa, guansong, t-tye, tpr, dstuttard, yaxunl, 
nhaehnle, jvesely, kzhuravl.
pdhaliwal requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, wdng.
Herald added a project: clang.

The offload action is used in four different ways as explained
in Driver.cpp:4495. When -c is present, the final phase will be
assemble (linker when -c is not present). However, this phase
is skipped according to D96769  for amdgcn. 
So, offload action
arrives into following situation,

compile (device) ---> offload ---> offload

without -c the chain looks like,
 compile (device) ---> offload ---> linker (device)

---> offload

The former situation creates an unhandled case which causes
problem. The solution presented in this patch delays the D96769 

logic until job creation time. This keeps the offload action
in the 1 of the 4 specified situations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101901

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -26,12 +26,14 @@
 // CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
 // CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
 // CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, 
"device-openmp (amdgcn-amd-amdhsa)" {7}, ir
-// CHECK-PHASES: 9: linker, {8}, image, (device-openmp)
-// CHECK-PHASES: 10: offload, "device-openmp (amdgcn-amd-amdhsa)" {9}, image
-// CHECK-PHASES: 11: clang-offload-wrapper, {10}, ir, (host-openmp)
-// CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
-// CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
-// CHECK-PHASES: 14: linker, {4, 13}, image, (host-openmp)
+// CHECK-PHASES: 9: backend, {8}, assembler, (device-openmp)
+// CHECK-PHASES: 10: assembler, {9}, object, (device-openmp)
+// CHECK-PHASES: 11: linker, {10}, image, (device-openmp)
+// CHECK-PHASES: 12: offload, "device-openmp (amdgcn-amd-amdhsa)" {11}, image
+// CHECK-PHASES: 13: clang-offload-wrapper, {12}, ir, (host-openmp)
+// CHECK-PHASES: 14: backend, {13}, assembler, (host-openmp)
+// CHECK-PHASES: 15: assembler, {14}, object, (host-openmp)
+// CHECK-PHASES: 16: linker, {4, 15}, image, (host-openmp)
 
 // handling of --libomptarget-amdgcn-bc-path
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 
--libomptarget-amdgcn-bc-path=%S/Inputs/hip_dev_lib/libomptarget-amdgcn-gfx803.bc
 %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIBOMPTARGET
@@ -58,3 +60,14 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-SAVE-ASM
 // CHECK-SAVE-ASM: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=asm" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906.s"
 // CHECK-SAVE-ASM: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906.o"
+
+// check the handling of -c
+// RUN:   env LIBRARY_PATH=%S/Inputs/hip_dev_lib %clang -ccc-print-bindings -c 
--target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -save-temps %s 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-C
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang",
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang",{{.*}}output: "[[HOST_BC:.*]]"
+// CHECK-C: "amdgcn-amd-amdhsa" - "clang",{{.*}}output: "[[DEVICE_I:.*]]"
+// CHECK-C: "amdgcn-amd-amdhsa" - "clang", inputs: ["[[DEVICE_I]]", 
"[[HOST_BC]]"]
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
+// CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3100,16 +3100,8 @@
   }
 
   // By default, we produce an action for each device arch.
-  for (unsigned I = 0; I < ToolChains.size(); ++I) {
-Action *&A = OpenMPDeviceActions[I];
-// AMDGPU does not support linking of object files, so we skip
-// assemble and backend actions to produce LLVM IR.
-if (ToolChains[I]->getTriple().isAMDGCN() &&
-(CurPhase == phases::Assemble || CurPhase == phases::Backend))
-  continue;
-
+  for (Action *&A : OpenMPDeviceActions)
 A = C.getDriver().ConstructPhaseAction(C, Args, CurPhase, A);
-

[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-05-05 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:10006
   "use of %select{type|declaration}0 %1 requires %2 support">;
+def ext_opencl_double_without_pragma : Extension<
+  "Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is 
supported">;

azabaznov wrote:
> nit: this can be extended to use arbitrary type and extension for other 
> patches which will eliminate pragmas for types
Well, actually I am not sure we should use it elsewhere because I don't think 
it really applies universally.
The situation for `doubles` seems to be that the older specs were intructing to 
use the pragma explicitly.

For the future work we should just avoid adding or using pragma at all unless 
it brings beneficial functionality.  


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

https://reviews.llvm.org/D100980

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

[PATCH] D101902: [clangd] Split CC and refs limit and increase refs limit to 1000

2021-05-05 Thread Kirill Bobyrev via Phabricator via cfe-commits

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

Related discussion: https://github.com/clangd/clangd/discussions/761


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101902

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -292,6 +292,14 @@
 init(100),
 };
 
+opt LimitReferences{
+"limit-references",
+cat(Features),
+desc("Limit the number of references returned by clangd. "
+ "0 means no limit (default=1000)"),
+init(1000),
+};
+
 list TweakList{
 "tweaks",
 cat(Features),
@@ -821,6 +829,7 @@
   }
 #endif
   Opts.BackgroundIndex = EnableBackgroundIndex;
+  Opts.LimitReferences = LimitReferences;
   auto PAI = createProjectAwareIndex(loadExternalIndex, Sync);
   if (StaticIdx) {
 IdxStack.emplace_back(std::move(StaticIdx));
Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -65,6 +65,9 @@
 
 /// Enable preview of InlayHints feature.
 bool InlayHints = false;
+
+/// Limit the number of references returned (0 means no limit).
+size_t LimitReferences = 0;
   };
 
   ClangdLSPServer(Transport &Transp, const ThreadsafeFS &TFS,
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -1264,7 +1264,7 @@
 void ClangdLSPServer::onReference(const ReferenceParams &Params,
   Callback> Reply) {
   Server->findReferences(
-  Params.textDocument.uri.file(), Params.position, Opts.CodeComplete.Limit,
+  Params.textDocument.uri.file(), Params.position, Opts.LimitReferences,
   [Reply = std::move(Reply),
IncludeDecl(Params.context.includeDeclaration)](
   llvm::Expected Refs) mutable {


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -292,6 +292,14 @@
 init(100),
 };
 
+opt LimitReferences{
+"limit-references",
+cat(Features),
+desc("Limit the number of references returned by clangd. "
+ "0 means no limit (default=1000)"),
+init(1000),
+};
+
 list TweakList{
 "tweaks",
 cat(Features),
@@ -821,6 +829,7 @@
   }
 #endif
   Opts.BackgroundIndex = EnableBackgroundIndex;
+  Opts.LimitReferences = LimitReferences;
   auto PAI = createProjectAwareIndex(loadExternalIndex, Sync);
   if (StaticIdx) {
 IdxStack.emplace_back(std::move(StaticIdx));
Index: clang-tools-extra/clangd/ClangdLSPServer.h
===
--- clang-tools-extra/clangd/ClangdLSPServer.h
+++ clang-tools-extra/clangd/ClangdLSPServer.h
@@ -65,6 +65,9 @@
 
 /// Enable preview of InlayHints feature.
 bool InlayHints = false;
+
+/// Limit the number of references returned (0 means no limit).
+size_t LimitReferences = 0;
   };
 
   ClangdLSPServer(Transport &Transp, const ThreadsafeFS &TFS,
Index: clang-tools-extra/clangd/ClangdLSPServer.cpp
===
--- clang-tools-extra/clangd/ClangdLSPServer.cpp
+++ clang-tools-extra/clangd/ClangdLSPServer.cpp
@@ -1264,7 +1264,7 @@
 void ClangdLSPServer::onReference(const ReferenceParams &Params,
   Callback> Reply) {
   Server->findReferences(
-  Params.textDocument.uri.file(), Params.position, Opts.CodeComplete.Limit,
+  Params.textDocument.uri.file(), Params.position, Opts.LimitReferences,
   [Reply = std::move(Reply),
IncludeDecl(Params.context.includeDeclaration)](
   llvm::Expected Refs) mutable {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101901: [AMDGPU][OpenMP] Fix clang driver crash when provided -c

2021-05-05 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

@jdoerfert This drops the logic for save-temps that I remember being 
contentious.

Doing a no-op backend pass instead of skipping over it is probably more robust.




Comment at: clang/lib/Driver/Driver.cpp:4600
+
+  if (const AssembleJobAction *AA = dyn_cast(A)) {
+return BuildJobsForAction(C, *AA->input_begin(), TC, BoundArch,

I wonder if this would be clearer as if (isa<>() || isa<>()) followed by a 
ternary to pick the second argument to BuildJobs. Overall I think I prefer the 
separate calls, as currently written.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101901

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

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Tom Weaver via Phabricator via cfe-commits

TWeaver added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

Is the missing FileCheck call here on purpose? it seems to me that the 
CHECK-MESSAGES aren't actually being verified by this test?

unless I'm missing something.

TIA


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Nathan James via Phabricator via cfe-commits

njames93 added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

TWeaver wrote:
> Is the missing FileCheck call here on purpose? it seems to me that the 
> CHECK-MESSAGES aren't actually being verified by this test?
> 
> unless I'm missing something.
> 
> TIA
`check_clang_tidy` invokes FileCheck. Does something else make you think these 
labels are being tested?? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D100934: [clang][modules] Build inferred modules

2021-05-05 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added inline comments.



Comment at: clang/test/ClangScanDeps/modules-inferred-explicit-build.m:13-17
+// RUN: %clang @%t.inferred.rsp -pedantic -Werror
+// RUN: %clang @%t.system.rsp -pedantic -Werror
+// RUN: %clang -x objective-c -fsyntax-only %t.dir/modules_cdb_input.cpp \
+// RUN:   -F%S/Inputs/frameworks -fmodules -fimplicit-module-maps \
+// RUN:   -pedantic -Werror @%t.tu.rsp

jansvoboda11 wrote:
> dexonsmith wrote:
> > jansvoboda11 wrote:
> > > dexonsmith wrote:
> > > > I feel like the clang invocations that build/use modules should be in 
> > > > `clang/test/Modules`. Two independent things:
> > > > - Can clang build inferred modules explicitly? (tested in 
> > > > clang/test/Modules)
> > > > - Can clang-scan-deps generate deps for inferred modules? (tested in 
> > > > clang/test/ClangScanDeps)
> > > I agree that we should test explicit build of inferred modules in 
> > > `clang/test/Modules` (without `clang-scan-deps`). I'll look into it.
> > > 
> > > I'm not sure I'd be happy with only checking the dependencies produced by 
> > > `clang-scan-deps` here. Testing that the generated command-line actually 
> > > works is as important IMO, and it will be even more so when we start 
> > > optimizing the command line (stripping out unused header search paths, 
> > > definitions etc.).
> > I'm not sure precisely what you mean by "works". I'm not sure just checking 
> > if it still compiles tells us much. What's important is that the modified 
> > options have the same semantics, and I think a subtle change that still 
> > compiles is more likely than preventing compilation entirely.
> > 
> > I don't think it would scale to check for semantic problems here -- that 
> > needs a body of testcases that covers all the things modules support.
> > 
> > One option would be to use the testcases (or a selection of them) in 
> > clang/test/Modules, by adding an extra RUN line that builds 
> > clang-scan-deps-discovered modules both with and without command-line 
> > stripping. For most changes, we can arrange the AST block such that skipped 
> > options won't affect it, and we could compare the hash of just that block. 
> > If and when we start stripping ignored `-D` options we'll need something 
> > smarter, but we can solve that problem later. (Ideally, this would just be 
> > a mode in clang, `clang -Xclang -fmodules-depscan`, which does an initial 
> > depscan and builds the modules in order. This might actually be an 
> > improvement on the existing implicit modules.)
> > 
> > @Bigcheese, maybe you can weigh in? If you both think `clang -cc1` should 
> > be tested here, I'm open to it. (In that case, though, this should not be 
> > invoking `%clang`, but `%clang_cc1`, I think... or does the response file 
> > create a driver command-line?)
> > I'm not sure precisely what you mean by "works". I'm not sure just checking 
> > if it still compiles tells us much. What's important is that the modified 
> > options have the same semantics, and I think a subtle change that still 
> > compiles is more likely than preventing compilation entirely.
> 
> I see, that's a good point.
> 
> > One option would be to use the testcases (or a selection of them) in 
> > clang/test/Modules, by adding an extra RUN line that builds 
> > clang-scan-deps-discovered modules both with and without command-line 
> > stripping. For most changes, we can arrange the AST block such that skipped 
> > options won't affect it, and we could compare the hash of just that block. 
> > If and when we start stripping ignored `-D` options we'll need something 
> > smarter, but we can solve that problem later. 
> 
> Using tests from `clang/test/Modules` sounds nice. What are your concerns 
> regarding stripping `-D` options?
> 
> > In that case, though, this should not be invoking `%clang`, but 
> > `%clang_cc1`, I think... or does the response file create a driver 
> > command-line?
> 
> The `Tooling/DependencyScanning` library already prepends the `"-cc1"` 
> argument so that build tools using the API don't have to do that on their own.
> 
> Using tests from clang/test/Modules sounds nice. What are your concerns 
> regarding stripping -D options?

Oh, it’s a bit mundane, but that’ll affect the identifier info, which will in 
turn change the AST block and its hash. I think?

For a truly explicit module, removing “unused” `-D` options from the identifier 
table might not be correct, since for semantics you might want importers to 
pick up those definitions (I think? Are they considered exported?). For 
implicitly-discovered modules, we know all transitive importers have a superset 
of `-D`s on their command-lines so it’s safe. 

Maybe what we can do at the time is turn on a flag to avoid writing unused 
`-D`s to the serialized identifier table so the hashes will match? Anyway, I’m 
sure there is a solution. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100934/n

[PATCH] D101901: [AMDGPU][OpenMP] Fix clang driver crash when provided -c

2021-05-05 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

Cool, this makes sense :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101901

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

[clang] e994e74 - [OpenCL] Add clang extension for non-portable kernel parameters.

2021-05-05 Thread Anastasia Stulova via cfe-commits


Author: Anastasia Stulova
Date: 2021-05-05T14:58:23+01:00
New Revision: e994e74bca49831eb649e7c67955e9de7a1784b6

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

LOG: [OpenCL] Add clang extension for non-portable kernel parameters.

Added __cl_clang_non_portable_kernel_param_types extension that
allows using non-portable types as kernel parameters. This allows
bypassing the portability guarantees from the restrictions specified
in C++ for OpenCL v1.0 s2.4.

Currently this only disables the restrictions related to the data
layout. The programmer should ensure the compiler generates the same
layout for host and device or otherwise the argument should only be
accessed on the device side. This extension could be extended to other
case (e.g. permitting size_t) if desired in the future.

Patch by olestrohm (Ole Strohm)!

https://reviews.llvm.org/D101168

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/Basic/OpenCLExtensions.def
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.h
clang/lib/Sema/SemaDecl.cpp
clang/test/Misc/amdgcn.languageOptsOpenCL.cl
clang/test/Misc/nvptx.languageOptsOpenCL.cl
clang/test/Misc/r600.languageOptsOpenCL.cl
clang/test/SemaOpenCLCXX/invalid-kernel.clcpp

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 5e5382879e0c8..bdb5b3adf39fb 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1813,6 +1813,54 @@ supporting the variadic arguments e.g. majority of CPU 
targets.
   #pragma OPENCL EXTENSION __cl_clang_variadic_functions : disable
   void bar(int a, ...); // error - variadic prototype is not allowed
 
+``__cl_clang_non_portable_kernel_param_types``
+-
+
+With this extension it is possible to enable the use of some restricted types
+in kernel parameters specified in `C++ for OpenCL v1.0 s2.4
+`_.
+The restrictions can be relaxed using regular OpenCL extension pragma mechanism
+detailed in `the OpenCL Extension Specification, section 1.2
+`_.
+
+This is not a conformant behavior and it can only be used when the
+kernel arguments are not accessed on the host side or the data layout/size
+between the host and device is known to be compatible.
+
+**Example of Use**:
+
+.. code-block:: c++
+
+  // Plain Old Data type.
+  struct Pod {
+int a;
+int b;
+  };
+
+  // Not POD type because of the constructor.
+  // Standard layout type because there is only one access control.
+  struct OnlySL {
+int a;
+int b;
+NotPod() : a(0), b(0) {}
+  };
+
+  // Not standard layout type because of two 
diff erent access controls.
+  struct NotSL {
+int a;
+  private:
+int b;
+  }
+
+  kernel void kernel_main(
+Pod a,
+  #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : enable
+OnlySL b,
+global NotSL *c,
+  #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : disable
+global OnlySL *d,
+  );
+
 Legacy 1.x atomics with generic address space
 -
 

diff  --git a/clang/include/clang/Basic/OpenCLExtensions.def 
b/clang/include/clang/Basic/OpenCLExtensions.def
index 5e2977f478f3a..a0f01a2af9c37 100644
--- a/clang/include/clang/Basic/OpenCLExtensions.def
+++ b/clang/include/clang/Basic/OpenCLExtensions.def
@@ -87,6 +87,7 @@ OPENCL_EXTENSION(cl_khr_subgroups, true, 200)
 OPENCL_EXTENSION(cl_clang_storage_class_specifiers, true, 100)
 OPENCL_EXTENSION(__cl_clang_function_pointers, true, 100)
 OPENCL_EXTENSION(__cl_clang_variadic_functions, true, 100)
+OPENCL_EXTENSION(__cl_clang_non_portable_kernel_param_types, true, 100)
 
 // AMD OpenCL extensions
 OPENCL_EXTENSION(cl_amd_media_ops, true, 100)

diff  --git a/clang/lib/Basic/Targets/AMDGPU.h 
b/clang/lib/Basic/Targets/AMDGPU.h
index 8ee0ca30d305d..b2d422ce0bbe9 100644
--- a/clang/lib/Basic/Targets/AMDGPU.h
+++ b/clang/lib/Basic/Targets/AMDGPU.h
@@ -287,6 +287,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTargetInfo final : 
public TargetInfo {
 Opts["cl_clang_storage_class_specifiers"] = true;
 Opts["__cl_clang_variadic_functions"] = true;
 Opts["__cl_clang_function_pointers"] = true;
+Opts["__cl_clang_non_portable_kernel_param_types"] = true;
 
 bool IsAMDGCN = isAMDGCN(getTriple());
 

diff  --git a/clang/lib/Basic/Targets/NVPTX.h b/clang/lib/Basic/Targets/NVPTX.h
index 9e80473df9e00..b7b0aae65819d 100644
--- a/clang/lib/Basic/Targets/NVPTX.h
+++ b/clang/lib/Basic/Targets/NVPTX.h
@@ -133,6 +133,7 @@ class LLVM_LIBRARY_

[PATCH] D101902: [clangd] Split CC and refs limit and increase refs limit to 1000

2021-05-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits

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

thanks, lgtm!




Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:70
+/// Limit the number of references returned (0 means no limit).
+size_t LimitReferences = 0;
   };

`s/LimitReferences/ReferencesLimit/` to be consistent with `CodeComplete.Limit` 
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101902

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

[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-05-05 Thread Ethan Stewart via Phabricator via cfe-commits

estewart08 added a comment.

In D99432#2736981 , @ABataev wrote:

> In D99432#2736970 , @estewart08 
> wrote:
>
>> In D99432#2728788 , @ABataev wrote:
>>
>>> In D99432#2726997 , @estewart08 
>>> wrote:
>>>
 In D99432#2726845 , @ABataev 
 wrote:

> In D99432#2726588 , @estewart08 
> wrote:
>
>> In D99432#2726391 , @ABataev 
>> wrote:
>>
>>> In D99432#2726337 , 
>>> @estewart08 wrote:
>>>
 In D99432#2726060 , @ABataev 
 wrote:

> In D99432#2726050 , 
> @estewart08 wrote:
>
>> In D99432#2726025 , 
>> @ABataev wrote:
>>
>>> In D99432#2726019 , 
>>> @estewart08 wrote:
>>>
 In reference to https://bugs.llvm.org/show_bug.cgi?id=48851, I do 
 not see how this helps SPMD mode with team privatization of 
 declarations in-between target teams and parallel regions.
>>>
>>> Diв you try the reproducer with the applied patch?
>>
>> Yes, I still saw the test fail, although it was not with latest 
>> llvm-project. Are you saying the reproducer passes for you?
>
> I don't have CUDA installed but from what I see in the LLVM IR it 
> shall pass. Do you have a debug log, does it crashes or produces 
> incorrect results?

 This is on an AMDGPU but I assume the behavior would be similar for 
 NVPTX.

 It produces incorrect/incomplete results in the dist[0] index after a 
 manual reduction and in turn the final global gpu_results array is 
 incorrect.
 When thread 0 does a reduction into dist[0] it has no knowledge of 
 dist[1] having been updated by thread 1. Which tells me the array is 
 still thread private.
 Adding some printfs, looking at one teams' output:

 SPMD

   Thread 0: dist[0]: 1
   Thread 0: dist[1]: 0  // This should be 1
   After reduction into dist[0]: 1  // This should be 2
   gpu_results = [1,1]  // [2,2] expected

 Generic Mode:

   Thread 0: dist[0]: 1
   Thread 0: dist[1]: 1   
   After reduction into dist[0]: 2
   gpu_results = [2,2]
>>>
>>> Hmm, I would expect a crash if the array was allocated in the local 
>>> memory. Could you try to add some more printfs (with data and addresses 
>>> of the array) to check the results? Maybe there is a data race 
>>> somewhere in the code?
>>
>> As a reminder, each thread updates a unique index in the dist array and 
>> each team updates a unique index in gpu_results.
>>
>> SPMD - shows each thread has a unique address for dist array
>>
>>   Team 0 Thread 1: dist[0]: 0, 0x7f92e24a8bf8
>>   Team 0 Thread 1: dist[1]: 1, 0x7f92e24a8bfc
>>   
>>   Team 0 Thread 0: dist[0]: 1, 0x7f92e24a8bf0
>>   Team 0 Thread 0: dist[1]: 0, 0x7f92e24a8bf4
>>   
>>   Team 0 Thread 0: After reduction into dist[0]: 1
>>   Team 0 Thread 0: gpu_results address: 0x7f92a500
>>   --
>>   Team 1 Thread 1: dist[0]: 0, 0x7f92f9ec5188
>>   Team 1 Thread 1: dist[1]: 1, 0x7f92f9ec518c
>>   
>>   Team 1 Thread 0: dist[0]: 1, 0x7f92f9ec5180
>>   Team 1 Thread 0: dist[1]: 0, 0x7f92f9ec5184
>>   
>>   Team 1 Thread 0: After reduction into dist[0]: 1
>>   Team 1 Thread 0: gpu_results address: 0x7f92a500
>>   
>>   gpu_results[0]: 1
>>   gpu_results[1]: 1
>>
>> Generic - shows each team shares dist array address amongst threads
>>
>>   Team 0 Thread 1: dist[0]: 1, 0x7fac01938880
>>   Team 0 Thread 1: dist[1]: 1, 0x7fac01938884
>>   
>>   Team 0 Thread 0: dist[0]: 1, 0x7fac01938880
>>   Team 0 Thread 0: dist[1]: 1, 0x7fac01938884
>>   
>>   Team 0 Thread 0: After reduction into dist[0]: 2
>>   Team 0 Thread 0: gpu_results address: 0x7fabc500
>>   --
>>   Team 1 Thread 1: dist[0]: 1, 0x7fac19354e10
>>   Team 1 Thread 1: dist[1]: 1, 0x7fac19354e14
>>   
>>   Team 1 Thread 0: dist[0]: 1, 0x7fac19354e10
>>   Team 1 Thread 0: dist[1]: 1, 0x7fac19354e14
>>   
>>   Team 1 Thread 0: After reduction into dist[0]: 2
>>   Team 1 Thread 0: gpu_results address: 0x7fabc500
>
> Co

[PATCH] D100934: [clang][modules] Build inferred modules

2021-05-05 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added inline comments.



Comment at: clang/test/ClangScanDeps/modules-inferred-explicit-build.m:13-17
+// RUN: %clang @%t.inferred.rsp -pedantic -Werror
+// RUN: %clang @%t.system.rsp -pedantic -Werror
+// RUN: %clang -x objective-c -fsyntax-only %t.dir/modules_cdb_input.cpp \
+// RUN:   -F%S/Inputs/frameworks -fmodules -fimplicit-module-maps \
+// RUN:   -pedantic -Werror @%t.tu.rsp

dexonsmith wrote:
> jansvoboda11 wrote:
> > dexonsmith wrote:
> > > jansvoboda11 wrote:
> > > > dexonsmith wrote:
> > > > > I feel like the clang invocations that build/use modules should be in 
> > > > > `clang/test/Modules`. Two independent things:
> > > > > - Can clang build inferred modules explicitly? (tested in 
> > > > > clang/test/Modules)
> > > > > - Can clang-scan-deps generate deps for inferred modules? (tested in 
> > > > > clang/test/ClangScanDeps)
> > > > I agree that we should test explicit build of inferred modules in 
> > > > `clang/test/Modules` (without `clang-scan-deps`). I'll look into it.
> > > > 
> > > > I'm not sure I'd be happy with only checking the dependencies produced 
> > > > by `clang-scan-deps` here. Testing that the generated command-line 
> > > > actually works is as important IMO, and it will be even more so when we 
> > > > start optimizing the command line (stripping out unused header search 
> > > > paths, definitions etc.).
> > > I'm not sure precisely what you mean by "works". I'm not sure just 
> > > checking if it still compiles tells us much. What's important is that the 
> > > modified options have the same semantics, and I think a subtle change 
> > > that still compiles is more likely than preventing compilation entirely.
> > > 
> > > I don't think it would scale to check for semantic problems here -- that 
> > > needs a body of testcases that covers all the things modules support.
> > > 
> > > One option would be to use the testcases (or a selection of them) in 
> > > clang/test/Modules, by adding an extra RUN line that builds 
> > > clang-scan-deps-discovered modules both with and without command-line 
> > > stripping. For most changes, we can arrange the AST block such that 
> > > skipped options won't affect it, and we could compare the hash of just 
> > > that block. If and when we start stripping ignored `-D` options we'll 
> > > need something smarter, but we can solve that problem later. (Ideally, 
> > > this would just be a mode in clang, `clang -Xclang -fmodules-depscan`, 
> > > which does an initial depscan and builds the modules in order. This might 
> > > actually be an improvement on the existing implicit modules.)
> > > 
> > > @Bigcheese, maybe you can weigh in? If you both think `clang -cc1` should 
> > > be tested here, I'm open to it. (In that case, though, this should not be 
> > > invoking `%clang`, but `%clang_cc1`, I think... or does the response file 
> > > create a driver command-line?)
> > > I'm not sure precisely what you mean by "works". I'm not sure just 
> > > checking if it still compiles tells us much. What's important is that the 
> > > modified options have the same semantics, and I think a subtle change 
> > > that still compiles is more likely than preventing compilation entirely.
> > 
> > I see, that's a good point.
> > 
> > > One option would be to use the testcases (or a selection of them) in 
> > > clang/test/Modules, by adding an extra RUN line that builds 
> > > clang-scan-deps-discovered modules both with and without command-line 
> > > stripping. For most changes, we can arrange the AST block such that 
> > > skipped options won't affect it, and we could compare the hash of just 
> > > that block. If and when we start stripping ignored `-D` options we'll 
> > > need something smarter, but we can solve that problem later. 
> > 
> > Using tests from `clang/test/Modules` sounds nice. What are your concerns 
> > regarding stripping `-D` options?
> > 
> > > In that case, though, this should not be invoking `%clang`, but 
> > > `%clang_cc1`, I think... or does the response file create a driver 
> > > command-line?
> > 
> > The `Tooling/DependencyScanning` library already prepends the `"-cc1"` 
> > argument so that build tools using the API don't have to do that on their 
> > own.
> > 
> > Using tests from clang/test/Modules sounds nice. What are your concerns 
> > regarding stripping -D options?
> 
> Oh, it’s a bit mundane, but that’ll affect the identifier info, which will in 
> turn change the AST block and its hash. I think?
> 
> For a truly explicit module, removing “unused” `-D` options from the 
> identifier table might not be correct, since for semantics you might want 
> importers to pick up those definitions (I think? Are they considered 
> exported?). For implicitly-discovered modules, we know all transitive 
> importers have a superset of `-D`s on their command-lines so it’s safe. 
> 
> Maybe what we can do at the time is turn on a flag to avoid writing unused 
> `-D`s to the serialized ide

[clang] 1f5cacf - [AMDGPU][OpenMP] Fix clang driver crash when provided -c

2021-05-05 Thread Pushpinder Singh via cfe-commits


Author: Pushpinder Singh
Date: 2021-05-05T14:26:58Z
New Revision: 1f5cacfcb845fd4163dec5a8c7991934c53d6cb3

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

LOG: [AMDGPU][OpenMP] Fix clang driver crash when provided -c

The offload action is used in four different ways as explained
in Driver.cpp:4495. When -c is present, the final phase will be
assemble (linker when -c is not present). However, this phase
is skipped according to D96769 for amdgcn. So, offload action
arrives into following situation,

 compile (device) ---> offload ---> offload

without -c the chain looks like,
 compile (device) ---> offload ---> linker (device)
---> offload

The former situation creates an unhandled case which causes
problem. The solution presented in this patch delays the D96769
logic until job creation time. This keeps the offload action
in the 1 of the 4 specified situations.

Reviewed By: JonChesterfield

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/amdgpu-openmp-toolchain.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 5008b506a883b..1086887a8de56 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -3100,16 +3100,8 @@ class OffloadingActionBuilder final {
   }
 
   // By default, we produce an action for each device arch.
-  for (unsigned I = 0; I < ToolChains.size(); ++I) {
-Action *&A = OpenMPDeviceActions[I];
-// AMDGPU does not support linking of object files, so we skip
-// assemble and backend actions to produce LLVM IR.
-if (ToolChains[I]->getTriple().isAMDGCN() &&
-(CurPhase == phases::Assemble || CurPhase == phases::Backend))
-  continue;
-
+  for (Action *&A : OpenMPDeviceActions)
 A = C.getDriver().ConstructPhaseAction(C, Args, CurPhase, A);
-  }
 
   return ABRT_Success;
 }
@@ -4594,6 +4586,25 @@ InputInfo Driver::BuildJobsForActionNoCache(
   if (!T)
 return InputInfo();
 
+  if (BuildingForOffloadDevice &&
+  A->getOffloadingDeviceKind() == Action::OFK_OpenMP) {
+if (TC->getTriple().isAMDGCN()) {
+  // AMDGCN treats backend and assemble actions as no-op because
+  // linker does not support object files.
+  if (const BackendJobAction *BA = dyn_cast(A)) {
+return BuildJobsForAction(C, *BA->input_begin(), TC, BoundArch,
+  AtTopLevel, MultipleArchs, LinkingOutput,
+  CachedResults, TargetDeviceOffloadKind);
+  }
+
+  if (const AssembleJobAction *AA = dyn_cast(A)) {
+return BuildJobsForAction(C, *AA->input_begin(), TC, BoundArch,
+  AtTopLevel, MultipleArchs, LinkingOutput,
+  CachedResults, TargetDeviceOffloadKind);
+  }
+}
+  }
+
   // If we've collapsed action list that contained OffloadAction we
   // need to build jobs for host/device-side inputs it may have held.
   for (const auto *OA : CollapsedOffloadActions)

diff  --git a/clang/test/Driver/amdgpu-openmp-toolchain.c 
b/clang/test/Driver/amdgpu-openmp-toolchain.c
index f2350a51817a9..5f2bdff549607 100644
--- a/clang/test/Driver/amdgpu-openmp-toolchain.c
+++ b/clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -26,12 +26,14 @@
 // CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
 // CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
 // CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, 
"device-openmp (amdgcn-amd-amdhsa)" {7}, ir
-// CHECK-PHASES: 9: linker, {8}, image, (device-openmp)
-// CHECK-PHASES: 10: offload, "device-openmp (amdgcn-amd-amdhsa)" {9}, image
-// CHECK-PHASES: 11: clang-offload-wrapper, {10}, ir, (host-openmp)
-// CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
-// CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
-// CHECK-PHASES: 14: linker, {4, 13}, image, (host-openmp)
+// CHECK-PHASES: 9: backend, {8}, assembler, (device-openmp)
+// CHECK-PHASES: 10: assembler, {9}, object, (device-openmp)
+// CHECK-PHASES: 11: linker, {10}, image, (device-openmp)
+// CHECK-PHASES: 12: offload, "device-openmp (amdgcn-amd-amdhsa)" {11}, image
+// CHECK-PHASES: 13: clang-offload-wrapper, {12}, ir, (host-openmp)
+// CHECK-PHASES: 14: backend, {13}, assembler, (host-openmp)
+// CHECK-PHASES: 15: assembler, {14}, object, (host-openmp)
+// CHECK-PHASES: 16: linker, {4, 15}, image, (host-openmp)
 
 // handling of --libomptarget-amdgcn-bc-path
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 
--libomptarget-amdgcn-bc-pa

[PATCH] D101901: [AMDGPU][OpenMP] Fix clang driver crash when provided -c

2021-05-05 Thread Pushpinder Singh via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1f5cacfcb845: [AMDGPU][OpenMP] Fix clang driver crash when 
provided -c (authored by pdhaliwal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101901

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/amdgpu-openmp-toolchain.c


Index: clang/test/Driver/amdgpu-openmp-toolchain.c
===
--- clang/test/Driver/amdgpu-openmp-toolchain.c
+++ clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -26,12 +26,14 @@
 // CHECK-PHASES: 6: preprocessor, {5}, cpp-output, (device-openmp)
 // CHECK-PHASES: 7: compiler, {6}, ir, (device-openmp)
 // CHECK-PHASES: 8: offload, "host-openmp (x86_64-unknown-linux-gnu)" {2}, 
"device-openmp (amdgcn-amd-amdhsa)" {7}, ir
-// CHECK-PHASES: 9: linker, {8}, image, (device-openmp)
-// CHECK-PHASES: 10: offload, "device-openmp (amdgcn-amd-amdhsa)" {9}, image
-// CHECK-PHASES: 11: clang-offload-wrapper, {10}, ir, (host-openmp)
-// CHECK-PHASES: 12: backend, {11}, assembler, (host-openmp)
-// CHECK-PHASES: 13: assembler, {12}, object, (host-openmp)
-// CHECK-PHASES: 14: linker, {4, 13}, image, (host-openmp)
+// CHECK-PHASES: 9: backend, {8}, assembler, (device-openmp)
+// CHECK-PHASES: 10: assembler, {9}, object, (device-openmp)
+// CHECK-PHASES: 11: linker, {10}, image, (device-openmp)
+// CHECK-PHASES: 12: offload, "device-openmp (amdgcn-amd-amdhsa)" {11}, image
+// CHECK-PHASES: 13: clang-offload-wrapper, {12}, ir, (host-openmp)
+// CHECK-PHASES: 14: backend, {13}, assembler, (host-openmp)
+// CHECK-PHASES: 15: assembler, {14}, object, (host-openmp)
+// CHECK-PHASES: 16: linker, {4, 15}, image, (host-openmp)
 
 // handling of --libomptarget-amdgcn-bc-path
 // RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 
--libomptarget-amdgcn-bc-path=%S/Inputs/hip_dev_lib/libomptarget-amdgcn-gfx803.bc
 %s 2>&1 | FileCheck %s --check-prefix=CHECK-LIBOMPTARGET
@@ -58,3 +60,14 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-SAVE-ASM
 // CHECK-SAVE-ASM: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=asm" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906.s"
 // CHECK-SAVE-ASM: llc{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906-linked.bc" 
"-mtriple=amdgcn-amd-amdhsa" "-mcpu=gfx906" "-filetype=obj" 
"-o"{{.*}}amdgpu-openmp-toolchain-{{.*}}-gfx906.o"
+
+// check the handling of -c
+// RUN:   env LIBRARY_PATH=%S/Inputs/hip_dev_lib %clang -ccc-print-bindings -c 
--target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa 
-Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 -save-temps %s 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-C
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang",
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang",{{.*}}output: "[[HOST_BC:.*]]"
+// CHECK-C: "amdgcn-amd-amdhsa" - "clang",{{.*}}output: "[[DEVICE_I:.*]]"
+// CHECK-C: "amdgcn-amd-amdhsa" - "clang", inputs: ["[[DEVICE_I]]", 
"[[HOST_BC]]"]
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
+// CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
+// CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3100,16 +3100,8 @@
   }
 
   // By default, we produce an action for each device arch.
-  for (unsigned I = 0; I < ToolChains.size(); ++I) {
-Action *&A = OpenMPDeviceActions[I];
-// AMDGPU does not support linking of object files, so we skip
-// assemble and backend actions to produce LLVM IR.
-if (ToolChains[I]->getTriple().isAMDGCN() &&
-(CurPhase == phases::Assemble || CurPhase == phases::Backend))
-  continue;
-
+  for (Action *&A : OpenMPDeviceActions)
 A = C.getDriver().ConstructPhaseAction(C, Args, CurPhase, A);
-  }
 
   return ABRT_Success;
 }
@@ -4594,6 +4586,25 @@
   if (!T)
 return InputInfo();
 
+  if (BuildingForOffloadDevice &&
+  A->getOffloadingDeviceKind() == Action::OFK_OpenMP) {
+if (TC->getTriple().isAMDGCN()) {
+  // AMDGCN treats backend and assemble actions as no-op because
+  // linker does not support object files.
+  if (const BackendJobAction *BA = dyn_cast(A)) {
+return BuildJobsForAction(C, *BA->input_begin(), TC, BoundArch,
+  AtTopLevel, MultipleArchs, LinkingOutput,
+  CachedResults, TargetDeviceOffloadKind);
+  }
+
+  if (const AssembleJobAction *AA = dyn_cast(A)) {
+return BuildJobsForAction(C, *AA->input_begin(), TC, BoundArch,
+  AtTopLevel, MultipleArchs, LinkingOutput,
+

[PATCH] D101462: [MC] Untangle MCContext and MCObjectFileInfo

2021-05-05 Thread Anirudh Prasad via Phabricator via cfe-commits

anirudhp added a comment.

Hi @flip1995
My apologies, but you might have to rebase this on the latest main. I 
introduced a `MCSubtargetInfo` field in https://reviews.llvm.org/D100975. Some 
of the existing changes to the file may not be needed anymore.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101462

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

[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-05-05 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

In D99432#2738859 , @estewart08 wrote:

> In D99432#2736981 , @ABataev wrote:
>
>> In D99432#2736970 , @estewart08 
>> wrote:
>>
>>> In D99432#2728788 , @ABataev wrote:
>>>
 In D99432#2726997 , @estewart08 
 wrote:

> In D99432#2726845 , @ABataev 
> wrote:
>
>> In D99432#2726588 , @estewart08 
>> wrote:
>>
>>> In D99432#2726391 , @ABataev 
>>> wrote:
>>>
 In D99432#2726337 , 
 @estewart08 wrote:

> In D99432#2726060 , @ABataev 
> wrote:
>
>> In D99432#2726050 , 
>> @estewart08 wrote:
>>
>>> In D99432#2726025 , 
>>> @ABataev wrote:
>>>
 In D99432#2726019 , 
 @estewart08 wrote:

> In reference to https://bugs.llvm.org/show_bug.cgi?id=48851, I do 
> not see how this helps SPMD mode with team privatization of 
> declarations in-between target teams and parallel regions.

 Diв you try the reproducer with the applied patch?
>>>
>>> Yes, I still saw the test fail, although it was not with latest 
>>> llvm-project. Are you saying the reproducer passes for you?
>>
>> I don't have CUDA installed but from what I see in the LLVM IR it 
>> shall pass. Do you have a debug log, does it crashes or produces 
>> incorrect results?
>
> This is on an AMDGPU but I assume the behavior would be similar for 
> NVPTX.
>
> It produces incorrect/incomplete results in the dist[0] index after a 
> manual reduction and in turn the final global gpu_results array is 
> incorrect.
> When thread 0 does a reduction into dist[0] it has no knowledge of 
> dist[1] having been updated by thread 1. Which tells me the array is 
> still thread private.
> Adding some printfs, looking at one teams' output:
>
> SPMD
>
>   Thread 0: dist[0]: 1
>   Thread 0: dist[1]: 0  // This should be 1
>   After reduction into dist[0]: 1  // This should be 2
>   gpu_results = [1,1]  // [2,2] expected
>
> Generic Mode:
>
>   Thread 0: dist[0]: 1
>   Thread 0: dist[1]: 1   
>   After reduction into dist[0]: 2
>   gpu_results = [2,2]

 Hmm, I would expect a crash if the array was allocated in the local 
 memory. Could you try to add some more printfs (with data and 
 addresses of the array) to check the results? Maybe there is a data 
 race somewhere in the code?
>>>
>>> As a reminder, each thread updates a unique index in the dist array and 
>>> each team updates a unique index in gpu_results.
>>>
>>> SPMD - shows each thread has a unique address for dist array
>>>
>>>   Team 0 Thread 1: dist[0]: 0, 0x7f92e24a8bf8
>>>   Team 0 Thread 1: dist[1]: 1, 0x7f92e24a8bfc
>>>   
>>>   Team 0 Thread 0: dist[0]: 1, 0x7f92e24a8bf0
>>>   Team 0 Thread 0: dist[1]: 0, 0x7f92e24a8bf4
>>>   
>>>   Team 0 Thread 0: After reduction into dist[0]: 1
>>>   Team 0 Thread 0: gpu_results address: 0x7f92a500
>>>   --
>>>   Team 1 Thread 1: dist[0]: 0, 0x7f92f9ec5188
>>>   Team 1 Thread 1: dist[1]: 1, 0x7f92f9ec518c
>>>   
>>>   Team 1 Thread 0: dist[0]: 1, 0x7f92f9ec5180
>>>   Team 1 Thread 0: dist[1]: 0, 0x7f92f9ec5184
>>>   
>>>   Team 1 Thread 0: After reduction into dist[0]: 1
>>>   Team 1 Thread 0: gpu_results address: 0x7f92a500
>>>   
>>>   gpu_results[0]: 1
>>>   gpu_results[1]: 1
>>>
>>> Generic - shows each team shares dist array address amongst threads
>>>
>>>   Team 0 Thread 1: dist[0]: 1, 0x7fac01938880
>>>   Team 0 Thread 1: dist[1]: 1, 0x7fac01938884
>>>   
>>>   Team 0 Thread 0: dist[0]: 1, 0x7fac01938880
>>>   Team 0 Thread 0: dist[1]: 1, 0x7fac01938884
>>>   
>>>   Team 0 Thread 0: After reduction into dist[0]: 2
>>>   Team 0 Thread 0: gpu_results address: 0x7fabc500
>>>   --
>>>   Team 1 Thread 1: dist[0]: 1, 0x7fac19354e10
>>>   Team 1 Thread 1: dist[1]: 1, 0x7fac19354e14
>>>   
>>>   Team 1 Thread 0: dist[0]: 1, 0x7fac19354e10

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Tom Weaver via Phabricator via cfe-commits

TWeaver added a comment.

whilst investigating an unrelated issue on our internal branch, I tried 
editting the check lines in this test and wasn't able to create a failure. but 
if I add

'| FileCheck %s -check-prefix=CHECK-MESSAGES' to the run line and then edit the 
checks, I can induce an error.

This could be an issue on our internal branch though... :shrug: thanks for the 
speedy reply.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D101911: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-05-05 Thread Alexey Bataev via Phabricator via cfe-commits

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

Follow the more general patch for now, do not try to SPMDize the kernel
if the variable is used and local.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101911

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/nvptx_SPMD_codegen.cpp


Index: clang/test/OpenMP/nvptx_SPMD_codegen.cpp
===
--- clang/test/OpenMP/nvptx_SPMD_codegen.cpp
+++ clang/test/OpenMP/nvptx_SPMD_codegen.cpp
@@ -120,10 +120,7 @@
 // CHECK-DAG: [[DISTR_LIGHT]]
 // CHECK-DAG: [[FOR_LIGHT]]
 // CHECK-DAG: [[LIGHT]]
-// CHECK: call void @__kmpc_spmd_kernel_init(i32 {{.+}}, i16 0)
-// CHECK-DAG: [[DISTR_LIGHT]]
-// CHECK-DAG: [[FOR_LIGHT]]
-// CHECK-DAG: [[LIGHT]]
+// CHECK: call void @__kmpc_kernel_init(
 // CHECK: call void @__kmpc_spmd_kernel_init(i32 {{.+}}, i16 1)
 // CHECK-DAG: [[DISTR_FULL]]
 // CHECK-DAG: [[FULL]]
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -6565,7 +6565,7 @@
 continue;
   // Analyze declarations.
   if (const auto *DS = dyn_cast(S)) {
-if (llvm::all_of(DS->decls(), [&Ctx](const Decl *D) {
+if (llvm::all_of(DS->decls(), [](const Decl *D) {
   if (isa(D) || isa(D) ||
   isa(D) || isa(D) ||
   isa(D) || isa(D) ||
@@ -6576,10 +6576,7 @@
   const auto *VD = dyn_cast(D);
   if (!VD)
 return false;
-  return VD->isConstexpr() ||
- ((VD->getType().isTrivialType(Ctx) ||
-   VD->getType()->isReferenceType()) &&
-  (!VD->hasInit() || isTrivial(Ctx, VD->getInit(;
+  return VD->hasGlobalStorage() || !VD->isUsed();
 }))
   continue;
   }


Index: clang/test/OpenMP/nvptx_SPMD_codegen.cpp
===
--- clang/test/OpenMP/nvptx_SPMD_codegen.cpp
+++ clang/test/OpenMP/nvptx_SPMD_codegen.cpp
@@ -120,10 +120,7 @@
 // CHECK-DAG: [[DISTR_LIGHT]]
 // CHECK-DAG: [[FOR_LIGHT]]
 // CHECK-DAG: [[LIGHT]]
-// CHECK: call void @__kmpc_spmd_kernel_init(i32 {{.+}}, i16 0)
-// CHECK-DAG: [[DISTR_LIGHT]]
-// CHECK-DAG: [[FOR_LIGHT]]
-// CHECK-DAG: [[LIGHT]]
+// CHECK: call void @__kmpc_kernel_init(
 // CHECK: call void @__kmpc_spmd_kernel_init(i32 {{.+}}, i16 1)
 // CHECK-DAG: [[DISTR_FULL]]
 // CHECK-DAG: [[FULL]]
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -6565,7 +6565,7 @@
 continue;
   // Analyze declarations.
   if (const auto *DS = dyn_cast(S)) {
-if (llvm::all_of(DS->decls(), [&Ctx](const Decl *D) {
+if (llvm::all_of(DS->decls(), [](const Decl *D) {
   if (isa(D) || isa(D) ||
   isa(D) || isa(D) ||
   isa(D) || isa(D) ||
@@ -6576,10 +6576,7 @@
   const auto *VD = dyn_cast(D);
   if (!VD)
 return false;
-  return VD->isConstexpr() ||
- ((VD->getType().isTrivialType(Ctx) ||
-   VD->getType()->isReferenceType()) &&
-  (!VD->hasInit() || isTrivial(Ctx, VD->getInit(;
+  return VD->hasGlobalStorage() || !VD->isUsed();
 }))
   continue;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101911: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-05-05 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

Hi Ethan, try this patch if it fixes the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101911

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

[PATCH] D101352: [DOCS] Removed inconsistency in clang vs Clang usage in docs (c vs C)

2021-05-05 Thread Shivam Gupta via Phabricator via cfe-commits

xgupta added a comment.

@sushmaunnibhavi Please close this revision, I got some misunderstading. 
Changes are not expected here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101352

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

[PATCH] D101791: [clang-tidy] Aliasing: Add support for aggregates with references.

2021-05-05 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM!


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D101791

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

[PATCH] D101352: [DOCS] Removed inconsistency in clang vs Clang usage in docs (c vs C)

2021-05-05 Thread Sushma Unnibhavi via Phabricator via cfe-commits

sushmaunnibhavi added a comment.

In D101352#2739003 , @xgupta wrote:

> @sushmaunnibhavi Please close this revision, I got some misunderstading. 
> Changes are not expected here.

Yes, will do it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101352

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

[PATCH] D101787: [clang-tidy] Aliasing: Add more support for lambda captures.

2021-05-05 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-redundant-branch-condition.cpp:1
 // RUN: %check_clang_tidy %s bugprone-redundant-branch-condition %t
 

You need to add `-fblocks` here to enable block support to run the test.


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

https://reviews.llvm.org/D101787

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

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Tom Weaver via Phabricator via cfe-commits

TWeaver added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

njames93 wrote:
> TWeaver wrote:
> > Is the missing FileCheck call here on purpose? it seems to me that the 
> > CHECK-MESSAGES aren't actually being verified by this test?
> > 
> > unless I'm missing something.
> > 
> > TIA
> `check_clang_tidy` invokes FileCheck. Does something else make you think 
> these labels are being tested?? 
whilst investigating an unrelated issue on our internal branch, I tried 
editting the check lines in this test and wasn't able to create a failure. but 
if I add

'| FileCheck %s -check-prefix=CHECK-MESSAGES' to the run line and then edit the 
checks, I can induce an error.

This could be an issue on our internal branch though... :shrug: thanks for the 
speedy reply.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D96215: [clang-tidy] Aliasing: Add support for lambda captures.

2021-05-05 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D96215#2737085 , @NoQ wrote:

> In D96215#2735546 , @njames93 wrote:
>
>> Just my $0.02, We shouldn't worry too much about pathological cases like 
>> that. I imagine that code would almost never appear in the wild. And for 
>> cases where you don't have access to definition for `hidden_reference `, 
>> there's not much that can be done anyway.
>
> That's not what I typically tell myself; it really amazes me that for almost 
> all such pathological cases there appear to be users who write such code on a 
> regular basis.

+1, Hyrum's Law is real. :-) (or :-(, more accurately).




Comment at: clang-tools-extra/clang-tidy/utils/Aliasing.cpp:45-48
+return llvm::any_of(LE->captures(), [Var](const LambdaCapture &C) {
+  return C.capturesVariable() && C.getCaptureKind() == LCK_ByRef &&
+ C.getCapturedVar() == Var;
+});

Should this use `capturesByRef()` from https://reviews.llvm.org/D101787?


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

https://reviews.llvm.org/D96215

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

[PATCH] D101914: [clangd][index-sever] Limit results in repsonse

2021-05-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits

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

This is to prevent server from being DOS'd by possible malicious
parties issuing requests that can yield huge responses.

One possible drawback is on rename workflow. As it really requests all
occurences, but it has an internal limit on 50 files currently.
We are putting the limit on 1 elements per response So for rename to regress
one should have 10k refs to a symbol in less than 50 files. This seems unlikely
and we fix it if there are complaints by giving up on the response based on the
number of files covered instead.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101914

Files:
  clang-tools-extra/clangd/index/remote/server/Server.cpp


Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -93,6 +93,12 @@
 llvm::cl::desc("Maximum time a channel may stay idle until server closes "
"the connection, in seconds. Defaults to 480."));
 
+llvm::cl::opt LimitResults(
+"limit-results", llvm::cl::init(1),
+llvm::cl::desc("Maximum number of results to stream as a response to "
+   "single request. Limit is to keep the server from being "
+   "DOS'd. Defaults to 1."));
+
 static Key CurrentRequest;
 
 class RemoteIndexServer final : public v1::SymbolIndex::Service {
@@ -123,7 +129,12 @@
 }
 unsigned Sent = 0;
 unsigned FailedToSend = 0;
+bool HasMore = false;
 Index.lookup(*Req, [&](const clangd::Symbol &Item) {
+  if (Sent >= LimitResults) {
+HasMore = true;
+return;
+  }
   auto SerializedItem = ProtobufMarshaller->toProtobuf(Item);
   if (!SerializedItem) {
 elog("Unable to convert Symbol to protobuf: {0}",
@@ -137,8 +148,10 @@
   Reply->Write(NextMessage);
   ++Sent;
 });
+if (HasMore)
+  log("[public] Limiting result size for Lookup request.");
 LookupReply LastMessage;
-LastMessage.mutable_final_result()->set_has_more(true);
+LastMessage.mutable_final_result()->set_has_more(HasMore);
 logResponse(LastMessage);
 Reply->Write(LastMessage);
 SPAN_ATTACH(Tracer, "Sent", Sent);
@@ -160,6 +173,10 @@
Req.takeError());
   return grpc::Status::CANCELLED;
 }
+if (!Req->Limit || *Req->Limit > LimitResults) {
+  log("[public] Limiting result size for FuzzyFind request.");
+  Req->Limit = LimitResults;
+}
 unsigned Sent = 0;
 unsigned FailedToSend = 0;
 bool HasMore = Index.fuzzyFind(*Req, [&](const clangd::Symbol &Item) {
@@ -197,6 +214,10 @@
   elog("Can not parse RefsRequest from protobuf: {0}", Req.takeError());
   return grpc::Status::CANCELLED;
 }
+if (!Req->Limit || *Req->Limit > LimitResults) {
+  log("[public] Limiting result size for Refs request.");
+  Req->Limit = LimitResults;
+}
 unsigned Sent = 0;
 unsigned FailedToSend = 0;
 bool HasMore = Index.refs(*Req, [&](const clangd::Ref &Item) {
@@ -236,6 +257,10 @@
Req.takeError());
   return grpc::Status::CANCELLED;
 }
+if (!Req->Limit || *Req->Limit > LimitResults) {
+  log("[public] Limiting result size for Relations request.");
+  Req->Limit = LimitResults;
+}
 unsigned Sent = 0;
 unsigned FailedToSend = 0;
 Index.relations(


Index: clang-tools-extra/clangd/index/remote/server/Server.cpp
===
--- clang-tools-extra/clangd/index/remote/server/Server.cpp
+++ clang-tools-extra/clangd/index/remote/server/Server.cpp
@@ -93,6 +93,12 @@
 llvm::cl::desc("Maximum time a channel may stay idle until server closes "
"the connection, in seconds. Defaults to 480."));
 
+llvm::cl::opt LimitResults(
+"limit-results", llvm::cl::init(1),
+llvm::cl::desc("Maximum number of results to stream as a response to "
+   "single request. Limit is to keep the server from being "
+   "DOS'd. Defaults to 1."));
+
 static Key CurrentRequest;
 
 class RemoteIndexServer final : public v1::SymbolIndex::Service {
@@ -123,7 +129,12 @@
 }
 unsigned Sent = 0;
 unsigned FailedToSend = 0;
+bool HasMore = false;
 Index.lookup(*Req, [&](const clangd::Symbol &Item) {
+  if (Sent >= LimitResults) {
+HasMore = true;
+return;
+  }
   auto SerializedItem = ProtobufMarshaller->toProtobuf(Item);
   if (!SerializedItem) {
 elog("Unable to convert Symbol to protobuf: {0}",
@@ -137,8 +148,10 @@
   Reply->Write(NextMessage);

[PATCH] D101915: [clangd][remote-client] Set HasMore to true for failure

2021-05-05 Thread Kadir Cetinkaya via Phabricator via cfe-commits

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

Currently client was setting the HasMore to true iff stream said so.
Hence if we had a broken stream for whatever reason (e.g. hitting deadline for a
huge response), HasMore would be false, which is semantically incorrect (e.g.
will throw rename off).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101915

Files:
  clang-tools-extra/clangd/index/remote/Client.cpp


Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -64,7 +64,10 @@
  StreamingCall RPCCall,
  CallbackT Callback) const {
 updateConnectionStatus();
-bool FinalResult = false;
+// We initialize to true because stream might be broken before we see the
+// final message. In such a case there are actually more results on the
+// stream, but we couldn't get to them.
+bool HasMore = true;
 trace::Span Tracer(RequestT::descriptor()->name());
 const auto RPCRequest = ProtobufMarshaller->toProtobuf(Request);
 SPAN_ATTACH(Tracer, "Request", RPCRequest.DebugString());
@@ -82,7 +85,7 @@
 unsigned FailedToParse = 0;
 while (Reader->Read(&Reply)) {
   if (!Reply.has_stream_result()) {
-FinalResult = Reply.final_result().has_more();
+HasMore = Reply.final_result().has_more();
 continue;
   }
   auto Response = ProtobufMarshaller->fromProtobuf(Reply.stream_result());
@@ -105,7 +108,7 @@
 SPAN_ATTACH(Tracer, "Successful", Successful);
 SPAN_ATTACH(Tracer, "Failed to parse", FailedToParse);
 updateConnectionStatus();
-return FinalResult;
+return HasMore;
   }
 
 public:


Index: clang-tools-extra/clangd/index/remote/Client.cpp
===
--- clang-tools-extra/clangd/index/remote/Client.cpp
+++ clang-tools-extra/clangd/index/remote/Client.cpp
@@ -64,7 +64,10 @@
  StreamingCall RPCCall,
  CallbackT Callback) const {
 updateConnectionStatus();
-bool FinalResult = false;
+// We initialize to true because stream might be broken before we see the
+// final message. In such a case there are actually more results on the
+// stream, but we couldn't get to them.
+bool HasMore = true;
 trace::Span Tracer(RequestT::descriptor()->name());
 const auto RPCRequest = ProtobufMarshaller->toProtobuf(Request);
 SPAN_ATTACH(Tracer, "Request", RPCRequest.DebugString());
@@ -82,7 +85,7 @@
 unsigned FailedToParse = 0;
 while (Reader->Read(&Reply)) {
   if (!Reply.has_stream_result()) {
-FinalResult = Reply.final_result().has_more();
+HasMore = Reply.final_result().has_more();
 continue;
   }
   auto Response = ProtobufMarshaller->fromProtobuf(Reply.stream_result());
@@ -105,7 +108,7 @@
 SPAN_ATTACH(Tracer, "Successful", Successful);
 SPAN_ATTACH(Tracer, "Failed to parse", FailedToParse);
 updateConnectionStatus();
-return FinalResult;
+return HasMore;
   }
 
 public:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-05 Thread Sam Clegg via Phabricator via cfe-commits

sbc100 added a comment.

Does this mean that the magic `__stack_pointer` global can be referenced at the 
IR level?   I wonder if there are some hacks around handling of 
`__stack_pointer` that could be removed after this lands?




Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:40
+  // appropriate.
+  WASM_ADDRESS_SPACE_OBJECT = 1
+};

What does "object" mean here?   Are we just talking about reference types?  Or 
also wasm globals that hold integers (like `__stack_pointer`).   If its just 
ref types that live in this address space should this be called 
`WASM_ADDRESS_SPACE_ANYREF`?   If its the latter should this be called 
`WASM_ADDRESS_SPACE_WASM_GLOBAL`?



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISD.def:48
+
+// Reference Types
+HANDLE_MEM_NODETYPE(GLOBAL_GET)

Is this just for ref types or also for global that hold integers too (like 
`__stack_pointer`)



Comment at: llvm/test/CodeGen/WebAssembly/global-get.ll:13
+; CHECK-NEXT: end_function
+  %v = load i32, i32 addrspace(1)* @i32_global
+  ret i32 %v

I don't suppose there is any way to give `addrspace(1)` a symbolic name is 
there?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101462: [MC] Untangle MCContext and MCObjectFileInfo

2021-05-05 Thread Philipp Krones via Phabricator via cfe-commits

flip1995 updated this revision to Diff 343056.
flip1995 added a comment.

rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101462

Files:
  clang/lib/Parse/ParseStmtAsm.cpp
  clang/tools/driver/cc1as_main.cpp
  lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
  lldb/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
  lldb/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
  llvm/include/llvm/MC/MCContext.h
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/lib/CodeGen/MachineModuleInfo.cpp
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/lib/DWARFLinker/DWARFStreamer.cpp
  llvm/lib/MC/MCAsmStreamer.cpp
  llvm/lib/MC/MCContext.cpp
  llvm/lib/MC/MCDisassembler/Disassembler.cpp
  llvm/lib/MC/MCMachOStreamer.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/MC/MCParser/AsmParser.cpp
  llvm/lib/MC/MCParser/COFFAsmParser.cpp
  llvm/lib/MC/MCParser/DarwinAsmParser.cpp
  llvm/lib/MC/MCParser/MasmParser.cpp
  llvm/lib/MC/MCStreamer.cpp
  llvm/lib/MC/MCWinCOFFStreamer.cpp
  llvm/lib/Object/ModuleSymbolTable.cpp
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
  llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXTargetStreamer.cpp
  llvm/lib/Target/TargetLoweringObjectFile.cpp
  llvm/tools/llvm-cfi-verify/lib/FileAnalysis.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-exegesis/lib/Analysis.cpp
  llvm/tools/llvm-exegesis/lib/LlvmState.cpp
  llvm/tools/llvm-exegesis/lib/SnippetFile.cpp
  llvm/tools/llvm-jitlink/llvm-jitlink.cpp
  llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-ml/Disassembler.cpp
  llvm/tools/llvm-ml/llvm-ml.cpp
  llvm/tools/llvm-objdump/MachODump.cpp
  llvm/tools/llvm-objdump/llvm-objdump.cpp
  llvm/tools/llvm-profgen/ProfiledBinary.cpp
  llvm/tools/llvm-rtdyld/llvm-rtdyld.cpp
  llvm/tools/sancov/sancov.cpp
  llvm/unittests/CodeGen/MachineInstrTest.cpp
  llvm/unittests/CodeGen/MachineOperandTest.cpp
  llvm/unittests/CodeGen/TestAsmPrinter.cpp
  llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
  llvm/unittests/MC/DwarfLineTables.cpp
  llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
  mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp

Index: mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
===
--- mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
+++ mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
@@ -169,8 +169,8 @@
   mai->setRelaxELFRelocations(true);
 
   llvm::MCObjectFileInfo mofi;
-  llvm::MCContext ctx(mai.get(), mri.get(), &mofi, &srcMgr, &mcOptions);
-  mofi.InitMCObjectFileInfo(triple, false, ctx, false);
+  llvm::MCContext ctx(triple, mai.get(), mri.get(), &mofi, &srcMgr, &mcOptions);
+  mofi.initMCObjectFileInfo(ctx, /*PIC=*/false, /*LargeCodeModel=*/false);
 
   SmallString<128> cwd;
   if (!llvm::sys::fs::current_path(cwd))
Index: llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
===
--- llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
+++ llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
@@ -112,9 +112,9 @@
 SrcMgr.AddNewSourceBuffer(std::move(Buffer), SMLoc());
 EXPECT_EQ(Buffer, nullptr);
 
-Ctx.reset(
-new MCContext(MUPMAI.get(), MRI.get(), &MOFI, &SrcMgr, &MCOptions));
-MOFI.InitMCObjectFileInfo(Triple, false, *Ctx, false);
+Ctx.reset(new MCContext(Triple, MUPMAI.get(), MRI.get(), &MOFI, STI.get(),
+&SrcMgr, &MCOptions));
+MOFI.initMCObjectFileInfo(*Ctx, /*PIC=*/false, /*LargeCodeModel=*/false);
 
 Str.reset(TheTarget->createNullStreamer(*Ctx));
 
Index: llvm/unittests/MC/DwarfLineTables.cpp
===
--- llvm/unittests/MC/DwarfLineTables.cpp
+++ llvm/unittests/MC/DwarfLineTables.cpp
@@ -21,7 +21,7 @@
 
 namespace {
 struct Context {
-  const char *Triple = "x86_64-pc-linux";
+  const char *TripleName = "x86_64-pc-linux";
   std::unique_ptr MRI;
   std::unique_ptr MAI;
   std::unique_ptr Ctx;
@@ -33,14 +33,15 @@
 
 // If we didn't build x86, do not run the test.
 std::string Error;
-const Target *TheTarget = TargetRegistry::lookupTarget(Triple, Error);
+const Target *TheTarget = TargetRegistry::lookupTarget(TripleName, Error);
 if (!TheTarget)
   return;
 
-MRI.reset(TheTarget->createMCRegInfo(Triple));
+MRI.reset(TheTarget->createMCRegInfo(TripleName));
 MCTargetOptions MCOptions;
-MAI.reset(TheTarget->createMCAsmInfo(*MRI, Triple, MCOptions));
-Ctx = std::make_unique(MAI.get(), MRI.get(), nullptr);
+MAI.reset(TheTarget->createMCAsmInfo(*MRI, TripleName, MCOptions));
+Ctx = std::make_unique(Triple(TripleName), MAI.get(), MRI.get(),
+  /*MOFI=*/nul

[PATCH] D100934: [clang][modules] Build inferred modules

2021-05-05 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added inline comments.



Comment at: clang/test/ClangScanDeps/modules-inferred-explicit-build.m:13-17
+// RUN: %clang @%t.inferred.rsp -pedantic -Werror
+// RUN: %clang @%t.system.rsp -pedantic -Werror
+// RUN: %clang -x objective-c -fsyntax-only %t.dir/modules_cdb_input.cpp \
+// RUN:   -F%S/Inputs/frameworks -fmodules -fimplicit-module-maps \
+// RUN:   -pedantic -Werror @%t.tu.rsp

dexonsmith wrote:
> dexonsmith wrote:
> > jansvoboda11 wrote:
> > > dexonsmith wrote:
> > > > jansvoboda11 wrote:
> > > > > dexonsmith wrote:
> > > > > > I feel like the clang invocations that build/use modules should be 
> > > > > > in `clang/test/Modules`. Two independent things:
> > > > > > - Can clang build inferred modules explicitly? (tested in 
> > > > > > clang/test/Modules)
> > > > > > - Can clang-scan-deps generate deps for inferred modules? (tested 
> > > > > > in clang/test/ClangScanDeps)
> > > > > I agree that we should test explicit build of inferred modules in 
> > > > > `clang/test/Modules` (without `clang-scan-deps`). I'll look into it.
> > > > > 
> > > > > I'm not sure I'd be happy with only checking the dependencies 
> > > > > produced by `clang-scan-deps` here. Testing that the generated 
> > > > > command-line actually works is as important IMO, and it will be even 
> > > > > more so when we start optimizing the command line (stripping out 
> > > > > unused header search paths, definitions etc.).
> > > > I'm not sure precisely what you mean by "works". I'm not sure just 
> > > > checking if it still compiles tells us much. What's important is that 
> > > > the modified options have the same semantics, and I think a subtle 
> > > > change that still compiles is more likely than preventing compilation 
> > > > entirely.
> > > > 
> > > > I don't think it would scale to check for semantic problems here -- 
> > > > that needs a body of testcases that covers all the things modules 
> > > > support.
> > > > 
> > > > One option would be to use the testcases (or a selection of them) in 
> > > > clang/test/Modules, by adding an extra RUN line that builds 
> > > > clang-scan-deps-discovered modules both with and without command-line 
> > > > stripping. For most changes, we can arrange the AST block such that 
> > > > skipped options won't affect it, and we could compare the hash of just 
> > > > that block. If and when we start stripping ignored `-D` options we'll 
> > > > need something smarter, but we can solve that problem later. (Ideally, 
> > > > this would just be a mode in clang, `clang -Xclang -fmodules-depscan`, 
> > > > which does an initial depscan and builds the modules in order. This 
> > > > might actually be an improvement on the existing implicit modules.)
> > > > 
> > > > @Bigcheese, maybe you can weigh in? If you both think `clang -cc1` 
> > > > should be tested here, I'm open to it. (In that case, though, this 
> > > > should not be invoking `%clang`, but `%clang_cc1`, I think... or does 
> > > > the response file create a driver command-line?)
> > > > I'm not sure precisely what you mean by "works". I'm not sure just 
> > > > checking if it still compiles tells us much. What's important is that 
> > > > the modified options have the same semantics, and I think a subtle 
> > > > change that still compiles is more likely than preventing compilation 
> > > > entirely.
> > > 
> > > I see, that's a good point.
> > > 
> > > > One option would be to use the testcases (or a selection of them) in 
> > > > clang/test/Modules, by adding an extra RUN line that builds 
> > > > clang-scan-deps-discovered modules both with and without command-line 
> > > > stripping. For most changes, we can arrange the AST block such that 
> > > > skipped options won't affect it, and we could compare the hash of just 
> > > > that block. If and when we start stripping ignored `-D` options we'll 
> > > > need something smarter, but we can solve that problem later. 
> > > 
> > > Using tests from `clang/test/Modules` sounds nice. What are your concerns 
> > > regarding stripping `-D` options?
> > > 
> > > > In that case, though, this should not be invoking `%clang`, but 
> > > > `%clang_cc1`, I think... or does the response file create a driver 
> > > > command-line?
> > > 
> > > The `Tooling/DependencyScanning` library already prepends the `"-cc1"` 
> > > argument so that build tools using the API don't have to do that on their 
> > > own.
> > > 
> > > Using tests from clang/test/Modules sounds nice. What are your concerns 
> > > regarding stripping -D options?
> > 
> > Oh, it’s a bit mundane, but that’ll affect the identifier info, which will 
> > in turn change the AST block and its hash. I think?
> > 
> > For a truly explicit module, removing “unused” `-D` options from the 
> > identifier table might not be correct, since for semantics you might want 
> > importers to pick up those definitions (I think? Are they considered 
> > exported?). For implicitly-discovered modules, we kno

[PATCH] D101918: [clang][Driver] Add -fintegrate-as to debug-pass-structure test

2021-05-05 Thread Jinsong Ji via Phabricator via cfe-commits

jsji created this revision.
jsji added reviewers: evgeny777, tejohnson.
jsji requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

CGProfilePass is not always on, it will be disabled when using
non-intergrated assemblers.

  // Only enable CGProfilePass when using integrated assembler, since
  // non-integrated assemblers don't recognize .cgprofile section.
  PMBuilder.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;

Add -fintegrate-as to make sure the output don't rely on the platform default.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101918

Files:
  clang/test/Driver/debug-pass-structure.c


Index: clang/test/Driver/debug-pass-structure.c
===
--- clang/test/Driver/debug-pass-structure.c
+++ clang/test/Driver/debug-pass-structure.c
@@ -1,5 +1,5 @@
 // Test that we print pass structure with new and legacy PM.
-// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -O3 -S 
-emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
+// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure 
-fintegrated-as -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s 
--check-prefix=NEWPM
 // RUN: %clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm 
%s -o /dev/null 2>&1 | FileCheck %s --check-prefix=LEGACYPM
 // REQUIRES: asserts
 
@@ -32,6 +32,7 @@
 // NEWPM-NEXT: ReversePostOrderFunctionAttrsPass on [module]
 // NEWPM-NEXT: RequireAnalysisPass<{{.*}}> on [module]
 // NEWPM-NEXT: ModuleToFunctionPassAdaptor on [module]
+// CGProfilePass is disabled with non-integrated assemblers
 // NEWPM-NEXT: CGProfilePass on [module]
 // NEWPM-NEXT: GlobalDCEPass on [module]
 // NEWPM-NEXT: ConstantMergePass on [module]


Index: clang/test/Driver/debug-pass-structure.c
===
--- clang/test/Driver/debug-pass-structure.c
+++ clang/test/Driver/debug-pass-structure.c
@@ -1,5 +1,5 @@
 // Test that we print pass structure with new and legacy PM.
-// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
+// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -fintegrated-as -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
 // RUN: %clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=LEGACYPM
 // REQUIRES: asserts
 
@@ -32,6 +32,7 @@
 // NEWPM-NEXT: ReversePostOrderFunctionAttrsPass on [module]
 // NEWPM-NEXT: RequireAnalysisPass<{{.*}}> on [module]
 // NEWPM-NEXT: ModuleToFunctionPassAdaptor on [module]
+// CGProfilePass is disabled with non-integrated assemblers
 // NEWPM-NEXT: CGProfilePass on [module]
 // NEWPM-NEXT: GlobalDCEPass on [module]
 // NEWPM-NEXT: ConstantMergePass on [module]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 67ee2f8 - Added a faster method to clone llvm project [DOCS]

2021-05-05 Thread via cfe-commits


Author: Sushma Unnibhavi
Date: 2021-05-05T21:37:53+05:30
New Revision: 67ee2f870d3b06a5684251272eae36d6e0f519b0

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

LOG: Added a faster method to clone llvm project [DOCS]

Reviewed By: xgupta, amccarth

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

Added: 


Modified: 
clang/www/get_started.html

Removed: 




diff  --git a/clang/www/get_started.html b/clang/www/get_started.html
index aacf55af8f574..40a05d92fb491 100755
--- a/clang/www/get_started.html
+++ b/clang/www/get_started.html
@@ -51,6 +51,17 @@ On Unix-like Systems
   
 Change directory to where you want the llvm directory placed.
 git clone https://github.com/llvm/llvm-project.git
+The above command is very slow. It can be made faster by creating a 
shallow clone. Shallow clone saves storage and speeds up the checkout time. 
This is done by using the command:
+  
+git clone --depth=1 https://github.com/llvm/llvm-project.git 
(using this only the latest version of llvm can be built)
+For normal users looking to just compile, this command works fine. 
But if someone later becomes a contributor, since they can't push code from a 
shallow clone, it needs to be converted into a full clone:
+  
+cd llvm-project
+git fetch --unshallow
+  
+
+  
+
   
   
   Build LLVM and Clang:



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

[PATCH] D101433: Added a faster method to clone llvm project [DOCS]

2021-05-05 Thread Shivam Gupta via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG67ee2f870d3b: Added a faster method to clone llvm project 
[DOCS] (authored by sushmaunnibhavi, committed by xgupta).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101433

Files:
  clang/www/get_started.html


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -51,6 +51,17 @@
   
 Change directory to where you want the llvm directory placed.
 git clone https://github.com/llvm/llvm-project.git
+The above command is very slow. It can be made faster by creating a 
shallow clone. Shallow clone saves storage and speeds up the checkout time. 
This is done by using the command:
+  
+git clone --depth=1 https://github.com/llvm/llvm-project.git 
(using this only the latest version of llvm can be built)
+For normal users looking to just compile, this command works fine. 
But if someone later becomes a contributor, since they can't push code from a 
shallow clone, it needs to be converted into a full clone:
+  
+cd llvm-project
+git fetch --unshallow
+  
+
+  
+
   
   
   Build LLVM and Clang:


Index: clang/www/get_started.html
===
--- clang/www/get_started.html
+++ clang/www/get_started.html
@@ -51,6 +51,17 @@
   
 Change directory to where you want the llvm directory placed.
 git clone https://github.com/llvm/llvm-project.git
+The above command is very slow. It can be made faster by creating a shallow clone. Shallow clone saves storage and speeds up the checkout time. This is done by using the command:
+  
+git clone --depth=1 https://github.com/llvm/llvm-project.git (using this only the latest version of llvm can be built)
+For normal users looking to just compile, this command works fine. But if someone later becomes a contributor, since they can't push code from a shallow clone, it needs to be converted into a full clone:
+  
+cd llvm-project
+git fetch --unshallow
+  
+
+  
+
   
   
   Build LLVM and Clang:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101918: [clang][Driver] Add -fintegrate-as to debug-pass-structure test

2021-05-05 Thread Eugene Leviant via Phabricator via cfe-commits

evgeny777 accepted this revision.
evgeny777 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/D101918/new/

https://reviews.llvm.org/D101918

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

[clang] 20d0aca - [clang][Driver] Add -fintegrate-as to debug-pass-structure test

2021-05-05 Thread Jinsong Ji via cfe-commits


Author: Jinsong Ji
Date: 2021-05-05T16:10:57Z
New Revision: 20d0aca43073f18f70b1c5a665631dee1be1598d

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

LOG: [clang][Driver] Add -fintegrate-as to debug-pass-structure test

CGProfilePass is not always on, it will be disabled when using
non-intergrated assemblers.

  // Only enable CGProfilePass when using integrated assembler, since
  // non-integrated assemblers don't recognize .cgprofile section.
  PMBuilder.CallGraphProfile = !CodeGenOpts.DisableIntegratedAS;

Add -fintegrate-as to make sure the output don't rely on the platform default.

Reviewed By: evgeny777

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

Added: 


Modified: 
clang/test/Driver/debug-pass-structure.c

Removed: 




diff  --git a/clang/test/Driver/debug-pass-structure.c 
b/clang/test/Driver/debug-pass-structure.c
index 2f250105d7b3..ca22e69baf07 100644
--- a/clang/test/Driver/debug-pass-structure.c
+++ b/clang/test/Driver/debug-pass-structure.c
@@ -1,5 +1,5 @@
 // Test that we print pass structure with new and legacy PM.
-// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -O3 -S 
-emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
+// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure 
-fintegrated-as -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s 
--check-prefix=NEWPM
 // RUN: %clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm 
%s -o /dev/null 2>&1 | FileCheck %s --check-prefix=LEGACYPM
 // REQUIRES: asserts
 
@@ -32,6 +32,7 @@
 // NEWPM-NEXT: ReversePostOrderFunctionAttrsPass on [module]
 // NEWPM-NEXT: RequireAnalysisPass<{{.*}}> on [module]
 // NEWPM-NEXT: ModuleToFunctionPassAdaptor on [module]
+// CGProfilePass is disabled with non-integrated assemblers
 // NEWPM-NEXT: CGProfilePass on [module]
 // NEWPM-NEXT: GlobalDCEPass on [module]
 // NEWPM-NEXT: ConstantMergePass on [module]



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

[PATCH] D101918: [clang][Driver] Add -fintegrate-as to debug-pass-structure test

2021-05-05 Thread Jinsong Ji via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG20d0aca43073: [clang][Driver] Add -fintegrate-as to 
debug-pass-structure test (authored by jsji).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101918

Files:
  clang/test/Driver/debug-pass-structure.c


Index: clang/test/Driver/debug-pass-structure.c
===
--- clang/test/Driver/debug-pass-structure.c
+++ clang/test/Driver/debug-pass-structure.c
@@ -1,5 +1,5 @@
 // Test that we print pass structure with new and legacy PM.
-// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -O3 -S 
-emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
+// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure 
-fintegrated-as -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s 
--check-prefix=NEWPM
 // RUN: %clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm 
%s -o /dev/null 2>&1 | FileCheck %s --check-prefix=LEGACYPM
 // REQUIRES: asserts
 
@@ -32,6 +32,7 @@
 // NEWPM-NEXT: ReversePostOrderFunctionAttrsPass on [module]
 // NEWPM-NEXT: RequireAnalysisPass<{{.*}}> on [module]
 // NEWPM-NEXT: ModuleToFunctionPassAdaptor on [module]
+// CGProfilePass is disabled with non-integrated assemblers
 // NEWPM-NEXT: CGProfilePass on [module]
 // NEWPM-NEXT: GlobalDCEPass on [module]
 // NEWPM-NEXT: ConstantMergePass on [module]


Index: clang/test/Driver/debug-pass-structure.c
===
--- clang/test/Driver/debug-pass-structure.c
+++ clang/test/Driver/debug-pass-structure.c
@@ -1,5 +1,5 @@
 // Test that we print pass structure with new and legacy PM.
-// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
+// RUN: %clang -fexperimental-new-pass-manager -fdebug-pass-structure -fintegrated-as -O3 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=NEWPM
 // RUN: %clang -flegacy-pass-manager -fdebug-pass-structure -O0 -S -emit-llvm %s -o /dev/null 2>&1 | FileCheck %s --check-prefix=LEGACYPM
 // REQUIRES: asserts
 
@@ -32,6 +32,7 @@
 // NEWPM-NEXT: ReversePostOrderFunctionAttrsPass on [module]
 // NEWPM-NEXT: RequireAnalysisPass<{{.*}}> on [module]
 // NEWPM-NEXT: ModuleToFunctionPassAdaptor on [module]
+// CGProfilePass is disabled with non-integrated assemblers
 // NEWPM-NEXT: CGProfilePass on [module]
 // NEWPM-NEXT: GlobalDCEPass on [module]
 // NEWPM-NEXT: ConstantMergePass on [module]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-05 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev added a comment.

Thanks, @teemperor. I have addressed your last comments, too.

I wanted to use the opportunity to ping @rjmccall and @rsmith.


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

https://reviews.llvm.org/D96033

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

[clang] f16afcd - [clang] remove an incremental build workaround

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


Author: Nico Weber
Date: 2021-05-05T12:21:56-04:00
New Revision: f16afcd9b5ce3054aac2b08b3a20472c07b6773a

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

LOG: [clang] remove an incremental build workaround

This cleaned up an oversight over a year ago. Should no longer be needed.

Added: 


Modified: 
clang/test/CoverageMapping/coroutine.cpp

Removed: 




diff  --git a/clang/test/CoverageMapping/coroutine.cpp 
b/clang/test/CoverageMapping/coroutine.cpp
index 21c90ab8d5402..0f7559849fb15 100644
--- a/clang/test/CoverageMapping/coroutine.cpp
+++ b/clang/test/CoverageMapping/coroutine.cpp
@@ -1,5 +1,3 @@
-// fixme: the following line is added to cleanup bots, will be removed in 
weeks.
-// RUN: rm -f %S/coroutine.ll
 // RUN: %clang_cc1 -mllvm -emptyline-comment-coverage=false -triple 
x86_64-unknown-linux-gnu -fcoroutines-ts -std=c++14 -emit-llvm 
-fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping %s -o - | 
FileCheck %s
 
 namespace std::experimental {



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

[PATCH] D101785: [clangd][ObjC] Highlight Objc Ivar refs

2021-05-05 Thread David Goldman via Phabricator via cfe-commits

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

Another attempt...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101785

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


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -780,6 +780,13 @@
   explicitReferenceTargets(DynTypedNode::create(*E), {}, Resolver)});
 }
 
+void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *OIRE) {
+  Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
+  OIRE->getLocation(),
+  /*IsDecl=*/false,
+  {OIRE->getDecl()}});
+}
+
 void VisitObjCMessageExpr(const ObjCMessageExpr *E) {
   // The name may have several tokens, we can only report the first.
   Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -780,6 +780,13 @@
   explicitReferenceTargets(DynTypedNode::create(*E), {}, Resolver)});
 }
 
+void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *OIRE) {
+  Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
+  OIRE->getLocation(),
+  /*IsDecl=*/false,
+  {OIRE->getDecl()}});
+}
+
 void VisitObjCMessageExpr(const ObjCMessageExpr *E) {
   // The name may have several tokens, we can only report the first.
   Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70094: [clang-tidy] new altera ID dependent backward branch check

2021-05-05 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM! Btw, given that you've had several of these approved, would you be 
interested in getting commit access 
(https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access)?


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

https://reviews.llvm.org/D70094

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

[PATCH] D101873: [clang] Support clang -fpic -fno-semantic-interposition for AArch64

2021-05-05 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

In D101873#2738643 , @peter.smith 
wrote:

> I've no comments on the code in D101872  , 
> and D10873  they look reasonable to me. I 
> guess it is down to whether this is the right thing to do or not.
>
> Just to check my understanding:
>
> - Clang defaults to -fno-semantic-interposition (GCC I believe has the 
> opposite default fsemantic-interposition)

Clang defaults to a state between -fno-semantic-interposition and 
-fsemantic-interposition (cc1 -fhalf-no-semantic-interposition): 
interprocedural optimizations are not disabled for default visibility 
definitions, but dso_local is not added.
This has been the traditional behavior for years.

Adding dso_local (-fno-semantic-interposition) will use `.Lfoo$local`, which 
can break a small amount of applications, so I don't want to change the default.

> - With this change code in the same translation unit that defines the global 
> will use a local alias for the global rather than accessing via the GOT, but 
> the global will still be defined with default visibility.

Only when -fno-semantic-interpoistion is explicitly specified, i.e. -fpic 
-fno-semantic-interpoistion

> - Symbol interposing is still permitted at link time so the global can be 
> interposed, but as the code is using a local alias it will still use the 
> original value.
> - Without this chang clang would use fhalf-no-semantic-interposition which I 
> believe permits some assumptions about symbol interpositioning such as 
> resolving some short range assembly pc-relative references to a local alias. 
> These would be out of range if the symbol were interposed anyway.
>
> If I've got this right, particularly the default  then this makes me nervous 
> about the default behaviour as it could silently break some existing code. If 
> a user had to opt in explicitly with -fno-semantic-interposition then fair 
> enough.
>
> Can you let me know, if I'm being overly cautious here? For example are 
> programs that would be affected by this already broken by the 
> half-no-semantic-interpositioning anyway? Is symbol interpositioning so rare 
> that the X86 version of this didn't break anything? Have I got the default of 
> -fno-semantic-interpositioning wrong?

Yes, the first step:) -fno-semantic-interposition is not the default.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101873

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

[clang] 632ebc4 - [MC] Untangle MCContext and MCObjectFileInfo

2021-05-05 Thread Fangrui Song via cfe-commits


Author: Philipp Krones
Date: 2021-05-05T10:03:02-07:00
New Revision: 632ebc4ab4374e53fce1ec870465c587e0a33668

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

LOG: [MC] Untangle MCContext and MCObjectFileInfo

This untangles the MCContext and the MCObjectFileInfo. There is a circular
dependency between MCContext and MCObjectFileInfo. Currently this dependency
also exists during construction: You can't contruct a MOFI without a MCContext
without constructing the MCContext with a dummy version of that MOFI first.
This removes this dependency during construction. In a perfect world,
MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the
MCContext, like other MC information. This is future work.

This also shifts/adds more information to the MCContext making it more
available to the different targets. Namely:

- TargetTriple
- ObjectFileType
- SubtargetInfo

Reviewed By: MaskRay

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

Added: 


Modified: 
clang/lib/Parse/ParseStmtAsm.cpp
clang/tools/driver/cc1as_main.cpp
lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp
lldb/source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
lldb/source/Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.cpp
llvm/include/llvm/MC/MCContext.h
llvm/include/llvm/MC/MCObjectFileInfo.h
llvm/lib/CodeGen/MachineModuleInfo.cpp
llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
llvm/lib/DWARFLinker/DWARFStreamer.cpp
llvm/lib/MC/MCAsmStreamer.cpp
llvm/lib/MC/MCContext.cpp
llvm/lib/MC/MCDisassembler/Disassembler.cpp
llvm/lib/MC/MCMachOStreamer.cpp
llvm/lib/MC/MCObjectFileInfo.cpp
llvm/lib/MC/MCParser/AsmParser.cpp
llvm/lib/MC/MCParser/COFFAsmParser.cpp
llvm/lib/MC/MCParser/DarwinAsmParser.cpp
llvm/lib/MC/MCParser/MasmParser.cpp
llvm/lib/MC/MCStreamer.cpp
llvm/lib/MC/MCWinCOFFStreamer.cpp
llvm/lib/Object/ModuleSymbolTable.cpp
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
llvm/lib/Target/NVPTX/MCTargetDesc/NVPTXTargetStreamer.cpp
llvm/lib/Target/TargetLoweringObjectFile.cpp
llvm/tools/llvm-cfi-verify/lib/FileAnalysis.cpp
llvm/tools/llvm-dwp/llvm-dwp.cpp
llvm/tools/llvm-exegesis/lib/Analysis.cpp
llvm/tools/llvm-exegesis/lib/LlvmState.cpp
llvm/tools/llvm-exegesis/lib/SnippetFile.cpp
llvm/tools/llvm-jitlink/llvm-jitlink.cpp
llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
llvm/tools/llvm-mc/llvm-mc.cpp
llvm/tools/llvm-mca/llvm-mca.cpp
llvm/tools/llvm-ml/Disassembler.cpp
llvm/tools/llvm-ml/llvm-ml.cpp
llvm/tools/llvm-objdump/MachODump.cpp
llvm/tools/llvm-objdump/llvm-objdump.cpp
llvm/tools/llvm-profgen/ProfiledBinary.cpp
llvm/tools/llvm-rtdyld/llvm-rtdyld.cpp
llvm/tools/sancov/sancov.cpp
llvm/unittests/CodeGen/MachineInstrTest.cpp
llvm/unittests/CodeGen/MachineOperandTest.cpp
llvm/unittests/CodeGen/TestAsmPrinter.cpp
llvm/unittests/DebugInfo/DWARF/DwarfGenerator.cpp
llvm/unittests/MC/DwarfLineTables.cpp
llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseStmtAsm.cpp 
b/clang/lib/Parse/ParseStmtAsm.cpp
index bdf40c291cb6..4c11fc60b4a0 100644
--- a/clang/lib/Parse/ParseStmtAsm.cpp
+++ b/clang/lib/Parse/ParseStmtAsm.cpp
@@ -588,8 +588,9 @@ StmtResult 
Parser::ParseMicrosoftAsmStatement(SourceLocation AsmLoc) {
   }
 
   llvm::SourceMgr TempSrcMgr;
-  llvm::MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &TempSrcMgr);
-  MOFI->InitMCObjectFileInfo(TheTriple, /*PIC*/ false, Ctx);
+  llvm::MCContext Ctx(TheTriple, MAI.get(), MRI.get(), MOFI.get(), STI.get(),
+  &TempSrcMgr);
+  MOFI->initMCObjectFileInfo(Ctx, /*PIC=*/false);
   std::unique_ptr Buffer =
   llvm::MemoryBuffer::getMemBuffer(AsmString, "");
 

diff  --git a/clang/tools/driver/cc1as_main.cpp 
b/clang/tools/driver/cc1as_main.cpp
index d4fa60c963d7..ec50e28f2796 100644
--- a/clang/tools/driver/cc1as_main.cpp
+++ b/clang/tools/driver/cc1as_main.cpp
@@ -387,7 +387,15 @@ static bool ExecuteAssemblerImpl(AssemblerInvocation &Opts,
   // MCObjectFileInfo needs a MCContext reference in order to initialize 
itself.
   std::unique_ptr MOFI(new MCObjectFileInfo());
 
-  MCContext Ctx(MAI.get(), MRI.get(), MOFI.get(), &SrcMgr, &MCOptions);
+  // Build up the feature string from the target feature list.
+  std::string FS = llvm::join(Opts.Features, ",");
+
+  std::unique_ptr STI(
+  TheTarget->createMCSubtargetInfo(Opts.Triple, Opts.CPU, FS));
+  assert(STI && "Unable to create subtarget info!");
+
+  MCContext Ctx(Triple(Opts.Triple), MAI.get()

[PATCH] D101766: [TableGen] [Clang] Clean up Options.td and add asserts

2021-05-05 Thread Paul C. Anagnostopoulos via Phabricator via cfe-commits

Paul-C-Anagnostopoulos updated this revision to Diff 343100.
Paul-C-Anagnostopoulos added a comment.

Restored whitespace as requested by Jan.


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

https://reviews.llvm.org/D101766

Files:
  clang/include/clang/Driver/Options.td

Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -274,10 +274,10 @@
 // Use this only when the option cannot be declared via BoolFOption.
 multiclass OptInFFlag flags=[]> {
-  def f#NAME : Flag<["-"], "f"#name>, Flags,
-   Group, HelpText;
+  def f#NAME : Flag<["-"], "f"#name>, Flags<[CC1Option] # flags>,
+   Group, HelpText;
   def fno_#NAME : Flag<["-"], "fno-"#name>, Flags,
-  Group, HelpText;
+  Group, HelpText;
 }
 
 // A boolean option which is opt-out in CC1. The negative option exists in CC1 and
@@ -286,9 +286,9 @@
 multiclass OptOutFFlag flags=[]> {
   def f#NAME : Flag<["-"], "f"#name>, Flags,
-   Group, HelpText;
-  def fno_#NAME : Flag<["-"], "fno-"#name>, Flags,
-  Group, HelpText;
+   Group, HelpText;
+  def fno_#NAME : Flag<["-"], "fno-"#name>, Flags<[CC1Option] # flags>,
+  Group, HelpText;
 }
 
 // Creates a positive and negative flags where both of them are prefixed with
@@ -297,9 +297,9 @@
 multiclass SimpleMFlag {
   def m#NAME : Flag<["-"], "m"#name>, Group,
-HelpText;
+HelpText;
   def mno_#NAME : Flag<["-"], "mno-"#name>, Group,
-HelpText;
+HelpText;
 }
 
 //===--===//
@@ -349,8 +349,8 @@
 class ApplySuffix {
   FlagDef Result
 = FlagDef;
+  flag.OptionFlags # suffix.OptionFlags,
+  flag.Help # suffix.Help, flag.ImpliedBy>;
 }
 
 // Definition of the command line flag with positive spelling, e.g. "-ffoo".
@@ -368,16 +368,16 @@
   : FlagDef {
   // Name of the TableGen record.
-  string RecordName = prefix#!cond(flag.Polarity : "", true : "no_")#name;
+  string RecordName = prefix # !if(flag.Polarity, "", "no_") # name;
 
   // Spelling of the flag.
-  string Spelling = prefix#!cond(flag.Polarity : "", true : "no-")#spelling;
+  string Spelling = prefix # !if(flag.Polarity, "", "no-") # spelling;
 
   // Can the flag be implied by another flag?
   bit CanBeImplied = !not(!empty(flag.ImpliedBy));
 
   // C++ code that will be assigned to the keypath when the flag is present.
-  code ValueAsCode = !cond(flag.Value : "true", true: "false");
+  code ValueAsCode = !if(flag.Value, "true", "false");
 }
 
 // TableGen record for a single marshalled flag.
@@ -404,11 +404,19 @@
   defvar flag2 = FlagDefExpanded.Result, prefix,
  NAME, spelling_base>;
 
-  // TODO: Assert that the flags have different polarity.
-  // TODO: Assert that the flags have different value.
-  // TODO: Assert that only one of the flags can be implied.
+  // The flags must have different polarity, different values, and only
+  // one can be implied.
+  assert !xor(flag1.Polarity, flag2.Polarity),
+ "the flags must have different polarity: flag1: " #
+ flag1.Polarity # ", flag2: " # flag2.Polarity;
+  assert !ne(flag1.Value, flag2.Value),
+ "the flags must have different values: flag1: " #
+ flag1.Value # ", flag2: " # flag2.Value;
+  assert !not(!and(flag1.CanBeImplied, flag2.CanBeImplied)),
+ "only one of the flags can be implied: flag1: " #
+ flag1.CanBeImplied # ", flag2: " # flag2.CanBeImplied;
 
-  defvar implied = !cond(flag1.CanBeImplied: flag1, true: flag2);
+  defvar implied = !if(flag1.CanBeImplied, flag1, flag2);
 
   def flag1.RecordName : MarshalledFlagRec;
   def flag2.RecordName : MarshalledFlagRec;
@@ -1896,8 +1904,9 @@
 "LangOptions::LaxVectorConversionKind::Integer",
 "LangOptions::LaxVectorConversionKind::All"]>,
   MarshallingInfoEnum,
-  !strconcat(open_cl.KeyPath, " ? LangOptions::LaxVectorConversionKind::None"
-  " : LangOptions::LaxVectorConversionKind::All")>;
+  open_cl.KeyPath #
+  " ? LangOptions::LaxVectorConversionKind::None" #
+  " : LangOptions::LaxVectorConversionKind::All">;
 def flax_vector_conversions : Flag<["-"], "flax-vector-conversions">, Group,
   Alias, AliasArgs<["integer"]>;
 def flimited_precision_EQ : Joined<["-"], "flimited-precision=">, Group;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Paul Robinson via Phabricator via cfe-commits

probinson added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

TWeaver wrote:
> njames93 wrote:
> > TWeaver wrote:
> > > Is the missing FileCheck call here on purpose? it seems to me that the 
> > > CHECK-MESSAGES aren't actually being verified by this test?
> > > 
> > > unless I'm missing something.
> > > 
> > > TIA
> > `check_clang_tidy` invokes FileCheck. Does something else make you think 
> > these labels are being tested?? 
> whilst investigating an unrelated issue on our internal branch, I tried 
> editting the check lines in this test and wasn't able to create a failure. 
> but if I add
> 
> '| FileCheck %s -check-prefix=CHECK-MESSAGES' to the run line and then edit 
> the checks, I can induce an error.
> 
> This could be an issue on our internal branch though... :shrug: thanks for 
> the speedy reply.
I'm suspicious that our downstream problem is because the test is assuming that 
the target is Windows, just because the host is.  That's not true for us (or 
anyone with a Windows-hosted cross-compiler).  Does clang-tidy accept a target 
triple?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

2021-05-05 Thread Paul Robinson via Phabricator via cfe-commits

probinson added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

probinson wrote:
> TWeaver wrote:
> > njames93 wrote:
> > > TWeaver wrote:
> > > > Is the missing FileCheck call here on purpose? it seems to me that the 
> > > > CHECK-MESSAGES aren't actually being verified by this test?
> > > > 
> > > > unless I'm missing something.
> > > > 
> > > > TIA
> > > `check_clang_tidy` invokes FileCheck. Does something else make you think 
> > > these labels are being tested?? 
> > whilst investigating an unrelated issue on our internal branch, I tried 
> > editting the check lines in this test and wasn't able to create a failure. 
> > but if I add
> > 
> > '| FileCheck %s -check-prefix=CHECK-MESSAGES' to the run line and then edit 
> > the checks, I can induce an error.
> > 
> > This could be an issue on our internal branch though... :shrug: thanks for 
> > the speedy reply.
> I'm suspicious that our downstream problem is because the test is assuming 
> that the target is Windows, just because the host is.  That's not true for us 
> (or anyone with a Windows-hosted cross-compiler).  Does clang-tidy accept a 
> target triple?
Or possibly the test could be set up to require a Windows target, rather than a 
Windows host.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

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

[PATCH] D101572: Make `hasTypeLoc` matcher support more node types.

2021-05-05 Thread Weston Carvalho via Phabricator via cfe-commits

SilensAngelusNex updated this revision to Diff 343106.
SilensAngelusNex added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101572

Files:
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -11,6 +11,7 @@
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
 #include "llvm/Support/Host.h"
 #include "gtest/gtest.h"
@@ -375,15 +376,104 @@
   typedefNameDecl(hasType(asString("foo")), hasName("bar";
 }
 
-TEST(HasTypeLoc, MatchesDeclaratorDecls) {
+TEST(HasTypeLoc, MatchesBlockDecl) {
+  EXPECT_TRUE(matchesConditionally(
+  "auto x = ^int (int a, int b) { return a + b; };",
+  blockDecl(hasTypeLoc(loc(asString("int (int, int)", true,
+  {"-fblocks"}));
+}
+
+TEST(HasTypeLoc, MatchesCXXBaseSpecifierAndCtorInitializer) {
+  llvm::StringRef code = R"cpp(
+  class Foo {};
+  class Bar : public Foo {
+Bar() : Foo() {}
+  };
+  )cpp";
+
+  EXPECT_TRUE(matches(
+  code, cxxRecordDecl(hasAnyBase(hasTypeLoc(loc(asString("class Foo")));
+  EXPECT_TRUE(matches(
+  code, cxxCtorInitializer(hasTypeLoc(loc(asString("class Foo"));
+}
+
+TEST(HasTypeLoc, MatchesCXXFunctionalCastExpr) {
+  EXPECT_TRUE(matches("auto x = int(3);",
+  cxxFunctionalCastExpr(hasTypeLoc(loc(asString("int"));
+}
+
+TEST(HasTypeLoc, MatchesCXXNewExpr) {
+  EXPECT_TRUE(matches("auto* x = new int(3);",
+  cxxNewExpr(hasTypeLoc(loc(asString("int"));
+  EXPECT_TRUE(matches("class Foo{}; auto* x = new Foo();",
+  cxxNewExpr(hasTypeLoc(loc(asString("class Foo"));
+}
+
+TEST(HasTypeLoc, MatchesCXXTemporaryObjectExpr) {
+  EXPECT_TRUE(
+  matches("struct Foo { Foo(int, int); }; auto x = Foo(1, 2);",
+  cxxTemporaryObjectExpr(hasTypeLoc(loc(asString("struct Foo"));
+}
+
+TEST(HasTypeLoc, MatchesCXXUnresolvedConstructExpr) {
+  EXPECT_TRUE(
+  matches("template  T make() { return T(); }",
+  cxxUnresolvedConstructExpr(hasTypeLoc(loc(asString("T"));
+}
+
+TEST(HasTypeLoc, MatchesClassTemplateSpecializationDecl) {
+  EXPECT_TRUE(matches(
+  "template  class Foo; template <> class Foo {};",
+  classTemplateSpecializationDecl(hasTypeLoc(loc(asString("Foo"));
+}
+
+TEST(HasTypeLoc, MatchesCompoundLiteralExpr) {
+  EXPECT_TRUE(
+  matches("int* x = (int [2]) { 0, 1 };",
+  compoundLiteralExpr(hasTypeLoc(loc(asString("int [2]"));
+}
+
+TEST(HasTypeLoc, MatchesDeclaratorDecl) {
   EXPECT_TRUE(matches("int x;",
   varDecl(hasName("x"), hasTypeLoc(loc(asString("int"));
+  EXPECT_TRUE(matches("int x(3);",
+  varDecl(hasName("x"), hasTypeLoc(loc(asString("int"));
+  EXPECT_TRUE(
+  matches("struct Foo { Foo(int, int); }; Foo x(1, 2);",
+  varDecl(hasName("x"), hasTypeLoc(loc(asString("struct Foo"));
 
   // Make sure we don't crash on implicit constructors.
   EXPECT_TRUE(notMatches("class X {}; X x;",
  declaratorDecl(hasTypeLoc(loc(asString("int"));
 }
 
+TEST(HasTypeLoc, MatchesExplicitCastExpr) {
+  EXPECT_TRUE(matches("auto x = (int) 3;",
+  explicitCastExpr(hasTypeLoc(loc(asString("int"));
+  EXPECT_TRUE(matches("auto x = static_cast(3);",
+  explicitCastExpr(hasTypeLoc(loc(asString("int"));
+}
+
+TEST(HasTypeLoc, MatchesObjCPropertyDecl) {
+  EXPECT_TRUE(matchesObjC(R"objc(
+  @interface Foo
+  @property int enabled;
+  @end
+)objc",
+  objcPropertyDecl(hasTypeLoc(loc(asString("int"));
+}
+
+TEST(HasTypeLoc, MatchesTemplateArgumentLoc) {
+  EXPECT_TRUE(matches("template  class Foo {}; Foo x;",
+  templateArgumentLoc(hasTypeLoc(loc(asString("int"));
+}
+
+TEST(HasTypeLoc, MatchesTypedefNameDecl) {
+  EXPECT_TRUE(matches("typedef int X;",
+  typedefNameDecl(hasTypeLoc(loc(asString("int"));
+  EXPECT_TRUE(matches("using X = int;",
+  typedefNameDecl(hasTypeLoc(loc(asString("int"));
+}
 
 TEST(Callee, MatchesDeclarations) {
   StatementMatcher CallMethodX = callExpr(callee(cxxMethodDecl(hasName("x";
Index: clang/include/clang/ASTMatchers/ASTMatchersInternal.h
===
--- clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ clang/include/clang/AS

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-05-05 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield added a comment.

We may need more robust error handling around this. I'm seeing test failures 
when building clang,

`clang-13: error: Cannot determine AMDGPU architecture: 
$HOME/llvm-build/llvm/./bin/amdgpu-arch: Execute failed: No such file or 
directory. Consider passing it via --march.`

The executable exists, but when run directly it fails with `error while loading 
shared libraries: libhsa-runtime64.so.1: cannot open shared object file: No 
such file or directory`
It's built with RUNPATH = [$ORIGIN/../lib], which doesn't necessarily work from 
the build directory.

Two somewhat orthogonal things here I think.

- skip running the corresponding clang tests when ./amdgpu-arch fails, whatever 
reason it fails for (which I thought was already the case, but can't find that 
in D99656 )
- be able to run from the build directory, which seems to be the default 
location for the tests

Changing clang_target_link_libraries to target_link_libraries made no 
difference. There is some cmake handling available around rpath but I haven't 
been able to determine what it should be set to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-05 Thread Sam Clegg via Phabricator via cfe-commits

sbc100 added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1378
-  if (GA->getAddressSpace() != 0)
-fail(DL, DAG, "WebAssembly only expects the 0 address space");
 

Is it worth checking this is within `WasmAddressSpace` range?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[clang] aefbfbc - [Clang] remove text extension from diag::err_drv_invalid_value_with_suggestion

2021-05-05 Thread Nick Desaulniers via cfe-commits


Author: Nick Desaulniers
Date: 2021-05-05T11:01:43-07:00
New Revision: aefbfbcbd776f5549b18cd6083d6408f661efacc

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

LOG: [Clang] remove text extension from 
diag::err_drv_invalid_value_with_suggestion

This hinders translations, as per:
https://clang.llvm.org/docs/InternalsManual.html#the-format-string

Reviewed By: MaskRay, xbolva00

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/stack-protector-guard.c
flang/lib/Frontend/CompilerInvocation.cpp
flang/test/Driver/fixed-line-length.f90

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 0e3ac3065ebc5..d090afa516c75 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -216,7 +216,8 @@ def warn_drv_yc_multiple_inputs_clang_cl : Warning<
 
 def err_drv_invalid_value : Error<"invalid value '%1' in '%0'">;
 def err_drv_invalid_int_value : Error<"invalid integral value '%1' in '%0'">;
-def err_drv_invalid_value_with_suggestion : Error<"invalid value '%1' in 
'%0','%2'">;
+def err_drv_invalid_value_with_suggestion : Error<
+"invalid value '%1' in '%0', expected one of: %2">;
 def err_drv_invalid_remap_file : Error<
 "invalid option '%0' not of the form ;">;
 def err_drv_invalid_gcc_output_type : Error<
@@ -275,6 +276,10 @@ def err_drv_unsupported_embed_bitcode
 : Error<"%0 is not supported with -fembed-bitcode">;
 def err_drv_bitcode_unsupported_on_toolchain : Error<
   "-fembed-bitcode is not supported on versions of iOS prior to 6.0">;
+def err_drv_negative_columns : Error<
+"invalid value '%1' in '%0', value must be 'none' or a positive integer">;
+def err_drv_small_columns : Error<
+"invalid value '%1' in '%0', value must be '%2' or greater">;
 
 def err_drv_invalid_malign_branch_EQ : Error<
   "invalid argument '%0' to -malign-branch=; each element must be one of: %1">;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 214c9b708e675..2b3934fc25418 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3112,8 +3112,7 @@ static void RenderSSPOptions(const Driver &D, const 
ToolChain &TC,
   << A->getAsString(Args) << TripleStr;
 if (Value != "tls" && Value != "global") {
   D.Diag(diag::err_drv_invalid_value_with_suggestion)
-  << A->getOption().getName() << Value
-  << "valid arguments to '-mstack-protector-guard=' are:tls global";
+  << A->getOption().getName() << Value << "tls global";
   return;
 }
 A->render(Args, CmdArgs);
@@ -3139,8 +3138,7 @@ static void RenderSSPOptions(const Driver &D, const 
ToolChain &TC,
   << A->getAsString(Args) << TripleStr;
 if (EffectiveTriple.isX86() && (Value != "fs" && Value != "gs")) {
   D.Diag(diag::err_drv_invalid_value_with_suggestion)
-  << A->getOption().getName() << Value
-  << "for X86, valid arguments to '-mstack-protector-guard-reg=' are:fs 
gs";
+  << A->getOption().getName() << Value << "fs gs";
   return;
 }
 A->render(Args, CmdArgs);

diff  --git a/clang/test/Driver/stack-protector-guard.c 
b/clang/test/Driver/stack-protector-guard.c
index f2bb8cd8555d6..cccf0d3088206 100644
--- a/clang/test/Driver/stack-protector-guard.c
+++ b/clang/test/Driver/stack-protector-guard.c
@@ -7,7 +7,7 @@
 
 // CHECK-TLS: "-cc1" {{.*}}"-mstack-protector-guard=tls"
 // CHECK-GLOBAL: "-cc1" {{.*}}"-mstack-protector-guard=global"
-// INVALID-VALUE: error: invalid value 'local' in 
'mstack-protector-guard=','valid arguments to '-mstack-protector-guard=' 
are:tls global'
+// INVALID-VALUE: error: invalid value 'local' in 'mstack-protector-guard=', 
expected one of: tls global
 
 // RUN: %clang -### -target x86_64-unknown-unknown 
-mstack-protector-guard-reg=fs %s 2>&1 | \
 // RUN:   FileCheck -check-prefix=CHECK-FS %s
@@ -35,7 +35,7 @@
 
 // CHECK-FS: "-cc1" {{.*}}"-mstack-protector-guard-reg=fs"
 // CHECK-GS: "-cc1" {{.*}}"-mstack-protector-guard-reg=gs"
-// INVALID-REG: error: invalid value {{.*}} in 
'mstack-protector-guard-reg=','for X86, valid arguments to 
'-mstack-protector-guard-reg=' are:fs gs'
+// INVALID-REG: error: invalid value {{.*}} in 'mstack-protector-guard-reg=', 
expected one of: fs gs
 
 // RUN: %clang -### -target x86_64-unknown-unknown 
-mstack-protector-guard-offset=30 %s 2>&1 | \
 // RUN:   FileCheck -check-prefix=CHECK-OFFSET %s

diff  --git a/flang/lib/Frontend/CompilerInvocation.cpp 
b/flang/lib/Frontend/CompilerInvocation.cpp
in

[PATCH] D101387: [Clang] remove text extension from diag::err_drv_invalid_value_with_suggestion

2021-05-05 Thread Nick Desaulniers 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 rGaefbfbcbd776: [Clang] remove text extension from 
diag::err_drv_invalid_value_with_suggestion (authored by nickdesaulniers).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101387

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/stack-protector-guard.c
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/test/Driver/fixed-line-length.f90

Index: flang/test/Driver/fixed-line-length.f90
===
--- flang/test/Driver/fixed-line-length.f90
+++ flang/test/Driver/fixed-line-length.f90
@@ -37,12 +37,12 @@
 !-
 ! EXPECTED OUTPUT WITH A NEGATIVE LENGTH
 !-
-! NEGATIVELENGTH: invalid value '-2' in 'ffixed-line-length=','value must be 'none' or a non-negative integer'
+! NEGATIVELENGTH: invalid value '-2' in 'ffixed-line-length=', value must be 'none' or a positive integer
 
 !-
 ! EXPECTED OUTPUT WITH LENGTH LESS THAN 7
 !-
-! INVALIDLENGTH: invalid value '3' in 'ffixed-line-length=','value must be at least seven'
+! INVALIDLENGTH: invalid value '3' in 'ffixed-line-length=', value must be '7' or greater
 
 !---
 ! EXPECTED OUTPUT WITH UNLIMITED LENGTH
Index: flang/lib/Frontend/CompilerInvocation.cpp
===
--- flang/lib/Frontend/CompilerInvocation.cpp
+++ flang/lib/Frontend/CompilerInvocation.cpp
@@ -259,15 +259,13 @@
   columns = -1;
 }
 if (columns < 0) {
-  diags.Report(clang::diag::err_drv_invalid_value_with_suggestion)
-  << arg->getOption().getName() << arg->getValue()
-  << "value must be 'none' or a non-negative integer";
+  diags.Report(clang::diag::err_drv_negative_columns)
+  << arg->getOption().getName() << arg->getValue();
 } else if (columns == 0) {
   opts.fixedFormColumns_ = 100;
 } else if (columns < 7) {
-  diags.Report(clang::diag::err_drv_invalid_value_with_suggestion)
-  << arg->getOption().getName() << arg->getValue()
-  << "value must be at least seven";
+  diags.Report(clang::diag::err_drv_small_columns)
+  << arg->getOption().getName() << arg->getValue() << "7";
 } else {
   opts.fixedFormColumns_ = columns;
 }
Index: clang/test/Driver/stack-protector-guard.c
===
--- clang/test/Driver/stack-protector-guard.c
+++ clang/test/Driver/stack-protector-guard.c
@@ -7,7 +7,7 @@
 
 // CHECK-TLS: "-cc1" {{.*}}"-mstack-protector-guard=tls"
 // CHECK-GLOBAL: "-cc1" {{.*}}"-mstack-protector-guard=global"
-// INVALID-VALUE: error: invalid value 'local' in 'mstack-protector-guard=','valid arguments to '-mstack-protector-guard=' are:tls global'
+// INVALID-VALUE: error: invalid value 'local' in 'mstack-protector-guard=', expected one of: tls global
 
 // RUN: %clang -### -target x86_64-unknown-unknown -mstack-protector-guard-reg=fs %s 2>&1 | \
 // RUN:   FileCheck -check-prefix=CHECK-FS %s
@@ -35,7 +35,7 @@
 
 // CHECK-FS: "-cc1" {{.*}}"-mstack-protector-guard-reg=fs"
 // CHECK-GS: "-cc1" {{.*}}"-mstack-protector-guard-reg=gs"
-// INVALID-REG: error: invalid value {{.*}} in 'mstack-protector-guard-reg=','for X86, valid arguments to '-mstack-protector-guard-reg=' are:fs gs'
+// INVALID-REG: error: invalid value {{.*}} in 'mstack-protector-guard-reg=', expected one of: fs gs
 
 // RUN: %clang -### -target x86_64-unknown-unknown -mstack-protector-guard-offset=30 %s 2>&1 | \
 // RUN:   FileCheck -check-prefix=CHECK-OFFSET %s
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -3112,8 +3112,7 @@
   << A->getAsString(Args) << TripleStr;
 if (Value != "tls" && Value != "global") {
   D.Diag(diag::err_drv_invalid_value_with_suggestion)
-  << A->getOption().getName() << Value
-  << "valid arguments to '-mstack-protector-guard=' are:tls global";
+  << A->getOption().getName() << Value << "tls global";
   return;
 }
 A->render(Args, CmdArgs);
@@ -3139,8 +3138,7 @@
   << A->getAsString(Args) << TripleStr;
 if (EffectiveTriple.isX86() && (Value != "fs" && Value != "gs")) {
   D.Diag(diag::err_drv_invalid_value_with_suggestion)
-  << A->getOption().getName() << Value
-  << "for X86, valid arguments to '-mstack-protector-guard-reg=' are:fs gs";
+  << A->getOption().getName() << Value << "fs gs";
   return;
 }
 A->ren

[PATCH] D101926: [amdgpu-arch] Fix rpath to run from build dir

2021-05-05 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield created this revision.
JonChesterfield added reviewers: gregrodgers, pdhaliwal, tianshilei1992, 
jdoerfert.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, yaxunl, mgorny, 
nhaehnle, jvesely, kzhuravl.
JonChesterfield requested review of this revision.
Herald added subscribers: cfe-commits, wdng.
Herald added a project: clang.

[amdgpu-arch] Fix rpath to run from build dir

Prior to this, amdgpu-arch has RUNPATH set to $ORIGIN/../lib which works
for some installs, but not from the build directory where clang executes
the tool from when running tests.

This cmake option adds the location of the rocr runtime to the RUNPATH
(note, it amends RUNPATH here, despite the cmake option referring to RPATH)
to create a binary that runs from build or install location.

Before:
RUNPATH [$ORIGIN/../lib]
After:
RUNPATH [$ORIGIN/../lib:$HOME/llvm-install/lib]

Credit to Greg for knowing this trick and pointing to examples of it in use
for the aomp build scripts.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101926

Files:
  clang/tools/amdgpu-arch/CMakeLists.txt


Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -14,4 +14,6 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
+
 clang_target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)


Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- clang/tools/amdgpu-arch/CMakeLists.txt
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -14,4 +14,6 @@
 
 add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
 
+set_target_properties(amdgpu-arch PROPERTIES INSTALL_RPATH_USE_LINK_PATH ON)
+
 clang_target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 7907c46 - Make clangd CompletionModel not depend on directory layout.

2021-05-05 Thread Harald van Dijk via cfe-commits


Author: Harald van Dijk
Date: 2021-05-05T19:25:34+01:00
New Revision: 7907c46fe6195728fafd843b8c0fb19a3e68e9ad

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

LOG: Make clangd CompletionModel not depend on directory layout.

The current code accounts for two possible layouts, but there is at
least a third supported layout: clang-tools-extra may also be checked
out as clang/tools/extra with the releases, which was not yet handled.
Rather than treating that as a special case, use the location of
CompletionModel.cmake to handle all three cases. This should address the
problems that prompted D96787 and the problems that prompted the
proposed revert D100625.

Reviewed By: usaxena95

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

Added: 


Modified: 
clang-tools-extra/clangd/quality/CompletionModel.cmake

Removed: 




diff  --git a/clang-tools-extra/clangd/quality/CompletionModel.cmake 
b/clang-tools-extra/clangd/quality/CompletionModel.cmake
index 41bc2ed1890b0..dc0c0cde4dabb 100644
--- a/clang-tools-extra/clangd/quality/CompletionModel.cmake
+++ b/clang-tools-extra/clangd/quality/CompletionModel.cmake
@@ -4,8 +4,9 @@
 # ${CMAKE_CURRENT_BINARY_DIR}. The generated header
 # will define a C++ class called ${cpp_class} - which may be a
 # namespace-qualified class name.
+set(CLANGD_COMPLETION_MODEL_COMPILER 
${CMAKE_CURRENT_LIST_DIR}/CompletionModelCodegen.py)
 function(gen_decision_forest model filename cpp_class)
-  set(model_compiler 
${LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR}/clangd/quality/CompletionModelCodegen.py)
+  set(model_compiler ${CLANGD_COMPLETION_MODEL_COMPILER})
 
   set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
   set(header_file ${output_dir}/${filename}.h)



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

[PATCH] D101851: Make clangd CompletionModel not depend on directory layout.

2021-05-05 Thread Harald van Dijk via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG7907c46fe619: Make clangd CompletionModel not depend on 
directory layout. (authored by hvdijk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101851

Files:
  clang-tools-extra/clangd/quality/CompletionModel.cmake


Index: clang-tools-extra/clangd/quality/CompletionModel.cmake
===
--- clang-tools-extra/clangd/quality/CompletionModel.cmake
+++ clang-tools-extra/clangd/quality/CompletionModel.cmake
@@ -4,8 +4,9 @@
 # ${CMAKE_CURRENT_BINARY_DIR}. The generated header
 # will define a C++ class called ${cpp_class} - which may be a
 # namespace-qualified class name.
+set(CLANGD_COMPLETION_MODEL_COMPILER 
${CMAKE_CURRENT_LIST_DIR}/CompletionModelCodegen.py)
 function(gen_decision_forest model filename cpp_class)
-  set(model_compiler 
${LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR}/clangd/quality/CompletionModelCodegen.py)
+  set(model_compiler ${CLANGD_COMPLETION_MODEL_COMPILER})
 
   set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
   set(header_file ${output_dir}/${filename}.h)


Index: clang-tools-extra/clangd/quality/CompletionModel.cmake
===
--- clang-tools-extra/clangd/quality/CompletionModel.cmake
+++ clang-tools-extra/clangd/quality/CompletionModel.cmake
@@ -4,8 +4,9 @@
 # ${CMAKE_CURRENT_BINARY_DIR}. The generated header
 # will define a C++ class called ${cpp_class} - which may be a
 # namespace-qualified class name.
+set(CLANGD_COMPLETION_MODEL_COMPILER ${CMAKE_CURRENT_LIST_DIR}/CompletionModelCodegen.py)
 function(gen_decision_forest model filename cpp_class)
-  set(model_compiler ${LLVM_EXTERNAL_CLANG_TOOLS_EXTRA_SOURCE_DIR}/clangd/quality/CompletionModelCodegen.py)
+  set(model_compiler ${CLANGD_COMPLETION_MODEL_COMPILER})
 
   set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
   set(header_file ${output_dir}/${filename}.h)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100782: [PowerPC] Improve f32 to i32 bitcast code gen

2021-05-05 Thread Albion Fung via Phabricator via cfe-commits

Conanap updated this revision to Diff 343115.
Conanap marked 2 inline comments as done.
Conanap added a comment.

Updated `COPY_TO_REGCLASS` to `SUBREG_TO_REG`, added a test case.


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

https://reviews.llvm.org/D100782

Files:
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/aix-p9-xxinsertw-xxextractuw.ll
  llvm/test/CodeGen/PowerPC/aix-vec_insert_elt.ll
  llvm/test/CodeGen/PowerPC/bitcasts-direct-move.ll
  llvm/test/CodeGen/PowerPC/p9-xxinsertw-xxextractuw.ll
  llvm/test/CodeGen/PowerPC/scalar_vector_test_4.ll
  llvm/test/CodeGen/PowerPC/vec_insert_elt.ll

Index: llvm/test/CodeGen/PowerPC/vec_insert_elt.ll
===
--- llvm/test/CodeGen/PowerPC/vec_insert_elt.ll
+++ llvm/test/CodeGen/PowerPC/vec_insert_elt.ll
@@ -200,21 +200,19 @@
 ; CHECK-LABEL: testFloat1:
 ; CHECK:   # %bb.0: # %entry
 ; CHECK-NEXT:xscvdpspn vs0, f1
-; CHECK-NEXT:extsw r3, r6
-; CHECK-NEXT:slwi r3, r3, 2
-; CHECK-NEXT:xxsldwi vs0, vs0, vs0, 3
-; CHECK-NEXT:mffprwz r4, f0
-; CHECK-NEXT:vinswrx v2, r3, r4
+; CHECK-NEXT:extsw r4, r6
+; CHECK-NEXT:slwi r4, r4, 2
+; CHECK-NEXT:mffprwz r3, f0
+; CHECK-NEXT:vinswrx v2, r4, r3
 ; CHECK-NEXT:blr
 ;
 ; CHECK-BE-LABEL: testFloat1:
 ; CHECK-BE:   # %bb.0: # %entry
 ; CHECK-BE-NEXT:xscvdpspn vs0, f1
-; CHECK-BE-NEXT:extsw r3, r6
-; CHECK-BE-NEXT:slwi r3, r3, 2
-; CHECK-BE-NEXT:xxsldwi vs0, vs0, vs0, 3
-; CHECK-BE-NEXT:mffprwz r4, f0
-; CHECK-BE-NEXT:vinswlx v2, r3, r4
+; CHECK-BE-NEXT:extsw r4, r6
+; CHECK-BE-NEXT:slwi r4, r4, 2
+; CHECK-BE-NEXT:mffprwz r3, f0
+; CHECK-BE-NEXT:vinswlx v2, r4, r3
 ; CHECK-BE-NEXT:blr
 ;
 ; CHECK-P9-LABEL: testFloat1:
@@ -346,7 +344,6 @@
 ; CHECK-LABEL: testFloatImm1:
 ; CHECK:   # %bb.0: # %entry
 ; CHECK-NEXT:xscvdpspn vs0, f1
-; CHECK-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-NEXT:xxinsertw v2, vs0, 12
 ; CHECK-NEXT:xxinsertw v2, vs0, 4
 ; CHECK-NEXT:blr
@@ -354,7 +351,6 @@
 ; CHECK-BE-LABEL: testFloatImm1:
 ; CHECK-BE:   # %bb.0: # %entry
 ; CHECK-BE-NEXT:xscvdpspn vs0, f1
-; CHECK-BE-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-BE-NEXT:xxinsertw v2, vs0, 0
 ; CHECK-BE-NEXT:xxinsertw v2, vs0, 8
 ; CHECK-BE-NEXT:blr
@@ -362,7 +358,6 @@
 ; CHECK-P9-LABEL: testFloatImm1:
 ; CHECK-P9:   # %bb.0: # %entry
 ; CHECK-P9-NEXT:xscvdpspn vs0, f1
-; CHECK-P9-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 0
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 8
 ; CHECK-P9-NEXT:blr
@@ -393,11 +388,9 @@
 ; CHECK-P9:   # %bb.0: # %entry
 ; CHECK-P9-NEXT:lfs f0, 0(r5)
 ; CHECK-P9-NEXT:xscvdpspn vs0, f0
-; CHECK-P9-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 0
 ; CHECK-P9-NEXT:lfs f0, 4(r5)
 ; CHECK-P9-NEXT:xscvdpspn vs0, f0
-; CHECK-P9-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 8
 ; CHECK-P9-NEXT:blr
 entry:
@@ -439,11 +432,9 @@
 ; CHECK-P9-NEXT:li r3, 1
 ; CHECK-P9-NEXT:rldic r3, r3, 38, 25
 ; CHECK-P9-NEXT:xscvdpspn vs0, f0
-; CHECK-P9-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 0
 ; CHECK-P9-NEXT:lfsx f0, r5, r3
 ; CHECK-P9-NEXT:xscvdpspn vs0, f0
-; CHECK-P9-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; CHECK-P9-NEXT:xxinsertw v2, vs0, 8
 ; CHECK-P9-NEXT:blr
 entry:
@@ -738,3 +729,28 @@
   ret <2 x double> %vecins
 }
 
+define dso_local <4 x float> @testInsertDoubleToFloat(<4 x float> %a, double %b) local_unnamed_addr #0 {
+; CHECK-LABEL: testInsertDoubleToFloat:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xscvdpsp f0, f1
+; CHECK-NEXT:xxinsertw v2, vs0, 8
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: testInsertDoubleToFloat:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:xsrsp f0, f1
+; CHECK-BE-NEXT:xscvdpspn vs0, f0
+; CHECK-BE-NEXT:xxinsertw v2, vs0, 4
+; CHECK-BE-NEXT:blr
+;
+; CHECK-P9-LABEL: testInsertDoubleToFloat:
+; CHECK-P9:   # %bb.0: # %entry
+; CHECK-P9-NEXT:xsrsp f0, f1
+; CHECK-P9-NEXT:xscvdpspn vs0, f0
+; CHECK-P9-NEXT:xxinsertw v2, vs0, 4
+; CHECK-P9-NEXT:blr
+entry:
+  %conv = fptrunc double %b to float
+  %vecins = insertelement <4 x float> %a, float %conv, i32 1
+  ret <4 x float> %vecins
+}
Index: llvm/test/CodeGen/PowerPC/scalar_vector_test_4.ll
===
--- llvm/test/CodeGen/PowerPC/scalar_vector_test_4.ll
+++ llvm/test/CodeGen/PowerPC/scalar_vector_test_4.ll
@@ -216,7 +216,6 @@
 ; P9LE:   # %bb.0: # %entry
 ; P9LE-NEXT:lfs f0, 0(r3)
 ; P9LE-NEXT:xscvdpspn vs0, f0
-; P9LE-NEXT:xxsldwi vs0, vs0, vs0, 3
 ; P9LE-NEXT:xxinsertw v2, vs0, 12
 ; P9LE-NEXT:blr
 ;
@@ -224,7 +223,6 @@
 ; P9BE:   # %bb.0: # %entry
 ; P9BE-NEXT:lfs f0, 0(r3)
 ; P9BE-NEXT:xscvdpspn vs0, f0
-; P9BE-NEXT:

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/FormatTokenLexer.cpp:135
   return;
+}
   }

krasimir wrote:
> nit: use spaces for indentation, no tabs (Phabricator makes it look this line 
> starts with a tab character)
That's not a tab, I fell for that one too once. It just visualizes that there 
was only whitespace added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[PATCH] D101934: [Utils][NFC] Rename replace-function-regex in update_cc_test_checks

2021-05-05 Thread Giorgis Georgakoudis via Phabricator via cfe-commits

ggeorgakoudis created this revision.
Herald added a subscriber: arichardson.
ggeorgakoudis requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101934

Files:
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  clang/test/OpenMP/target_parallel_for_debug_codegen.cpp
  clang/test/utils/update_cc_test_checks/Inputs/generated-funcs-regex.c
  clang/test/utils/update_cc_test_checks/Inputs/generated-funcs-regex.c.expected
  clang/test/utils/update_cc_test_checks/generated-funcs-regex.test
  llvm/utils/UpdateTestChecks/common.py
  llvm/utils/update_analyze_test_checks.py
  llvm/utils/update_llc_test_checks.py

Index: llvm/utils/update_llc_test_checks.py
===
--- llvm/utils/update_llc_test_checks.py
+++ llvm/utils/update_llc_test_checks.py
@@ -108,12 +108,12 @@
   check_indent = ''
 
 builder = common.FunctionTestBuilder(
-run_list=run_list, 
+run_list=run_list,
 flags=type('', (object,), {
 'verbose': ti.args.verbose,
 'function_signature': False,
 'check_attributes': False,
-'replace_function_regex': []}),
+'replace_value_regex': []}),
 scrubber_args=[ti.args])
 
 for prefixes, llc_tool, llc_args, preprocess_cmd, triple_in_cmd, march_in_cmd in run_list:
Index: llvm/utils/update_analyze_test_checks.py
===
--- llvm/utils/update_analyze_test_checks.py
+++ llvm/utils/update_analyze_test_checks.py
@@ -114,7 +114,7 @@
 'verbose': args.verbose,
 'function_signature': False,
 'check_attributes': False,
-'replace_function_regex': []}),
+'replace_value_regex': []}),
   scrubber_args = [])
 
 for prefixes, opt_args in prefix_list:
Index: llvm/utils/UpdateTestChecks/common.py
===
--- llvm/utils/UpdateTestChecks/common.py
+++ llvm/utils/UpdateTestChecks/common.py
@@ -32,8 +32,8 @@
help='Activate CHECK line generation from this point forward')
   parser.add_argument('--disable', action='store_false', dest='enabled',
   help='Deactivate CHECK line generation from this point forward')
-  parser.add_argument('--replace-function-regex', nargs='+', default=[],
-  help='List of regular expressions to replace matching function names')
+  parser.add_argument('--replace-value-regex', nargs='+', default=[],
+  help='List of regular expressions to replace matching value names')
   parser.add_argument('--prefix-filecheck-ir-name', default='',
   help='Add a prefix to FileCheck IR value names to avoid conflicts with scripted names')
   args = parser.parse_args()
@@ -297,7 +297,7 @@
 self._check_attributes = flags.check_attributes
 self._scrubber_args = scrubber_args
 # Strip double-quotes if input was read by UTC_ARGS
-self._replace_function_regex = list(map(lambda x: x.strip('"'), flags.replace_function_regex))
+self._replace_value_regex = list(map(lambda x: x.strip('"'), flags.replace_value_regex))
 self._func_dict = {}
 self._func_order = {}
 self._global_var_dict = {}
@@ -372,7 +372,7 @@
   continue
 
 # Replace function names matching the regex.
-for regex in self._replace_function_regex:
+for regex in self._replace_value_regex:
   # Pattern that matches capture groups in the regex in leftmost order.
   group_regex = re.compile('\(.*?\)')
   # Replace function name with regex.
Index: clang/test/utils/update_cc_test_checks/generated-funcs-regex.test
===
--- clang/

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

2021-05-05 Thread Jon Chesterfield via Phabricator via cfe-commits

JonChesterfield created this revision.
JonChesterfield added reviewers: jdoerfert, pdhaliwal, ronlieb, grokos, 
tianshilei1992.
Herald added subscribers: guansong, yaxunl.
JonChesterfield requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

[clang] Search runtimes build tree for openmp runtime

D96248  added support for finding the openmp 
devicertl bitcode in the clang
lib directory where it is installed, or in the LIBRARY_PATH environment.

When testing openmp from a build using ENABLE_RUNTIMES, the corresponding
bitcode may be found under runtimes/runtimes-bins. This patch adds that to
the list of places clang looks, at lower priority then the others.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101935

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1686,6 +1686,12 @@
   llvm::sys::path::append(DefaultLibPath, Twine("lib") + CLANG_LIBDIR_SUFFIX);
   LibraryPaths.emplace_back(DefaultLibPath.c_str());
 
+  // Add path to runtimes binary folder, used by ENABLE_RUNTIMES build
+  SmallString<256> RuntimesBinPath = llvm::sys::path::parent_path(D.Dir);
+  llvm::sys::path::append(RuntimesBinPath,
+  "runtimes/runtimes-bins/openmp/libomptarget");
+  LibraryPaths.emplace_back(RuntimesBinPath.c_str());
+
   OptSpecifier LibomptargetBCPathOpt =
   Triple.isAMDGCN() ? options::OPT_libomptarget_amdgcn_bc_path_EQ
 : options::OPT_libomptarget_nvptx_bc_path_EQ;


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1686,6 +1686,12 @@
   llvm::sys::path::append(DefaultLibPath, Twine("lib") + CLANG_LIBDIR_SUFFIX);
   LibraryPaths.emplace_back(DefaultLibPath.c_str());
 
+  // Add path to runtimes binary folder, used by ENABLE_RUNTIMES build
+  SmallString<256> RuntimesBinPath = llvm::sys::path::parent_path(D.Dir);
+  llvm::sys::path::append(RuntimesBinPath,
+  "runtimes/runtimes-bins/openmp/libomptarget");
+  LibraryPaths.emplace_back(RuntimesBinPath.c_str());
+
   OptSpecifier LibomptargetBCPathOpt =
   Triple.isAMDGCN() ? options::OPT_libomptarget_amdgcn_bc_path_EQ
 : options::OPT_libomptarget_nvptx_bc_path_EQ;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

2021-05-05 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks added a comment.

I really like alignment! :)

But why is this completely different than the other alignment options?

You should also add an entry to the release notes.




Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:32
+// The notion here is that we walk through the annotated line looking for
+// things like static initialization of arrays and flag them
+bool isArrayOfStructuresInit(const AnnotatedLine &Line) {

Dot at the end. :)



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:37
+  const auto *CurrentToken = Line.First;
+  enum class DetectAsiFsm {
+null,

What stands AsiFsm for?



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:82
+}
+CurrentToken = CurrentToken->getNextNonComment();
+  }

I would prefer a
`for(; CurrentToken != Line.Last && CurrentToken != nullptr; CurrentToken = 
CurrentToken->getNextNonComment())



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1232
+  } else if (CurrentToken->is(tok::r_brace)) {
+Depth--;
+  }

Why postfix, especially if using prefix in the `if`?



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1244
+  Column = 0;
+  Row++;
+} else {

Same.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1276
+}
+Layout.emplace_back(std::vector{});
+auto Row = Layout.size() - 1;

With this you should save yourself the temporary.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1278
+auto Row = Layout.size() - 1;
+Layout[Row].push_back(0);
+auto Column = 0U;

But why not just initialize the vector directly with 1 element of 0?



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1316-1327
+while (true) {
+  auto MaxColumn = 0U;
+  for (auto Row = 0U; Row < RowCount; Row++) {
+MaxColumn = std::max(MaxColumn, LayoutMatrix[Row][Column]);
+  }
+  for (auto Row = 0U; Row < RowCount; Row++) {
+LayoutMatrix[Row][Column] = MaxColumn - LayoutMatrix[Row][Column];

You should also assert that `LayoutMatrix.size() > 0`.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1404
+ isArrayOfStructuresInit(TheLine));
+  if (AlignArrayOfStructuresInit) {
+Penalty += AlignedArrayOfStructuresInitLineFormatter(

I'm not sure that you should go before the no column limit. In either case you 
should have a test case for that.



Comment at: clang/unittests/Format/FormatTest.cpp:16371
+   Style);
+}
+

curdeius wrote:
> I think we need more tests:
> * with a comma after the last element of array
> * with assignment and not only initialization?
> * without `struct` keyword
> * with short lines/long values to see how wrapping behaves
>   * also, with multiple string literals in one struct, e.g. `"hello" "world"` 
> (that will get splitted into multiple lines)
> * with non-plain-array types (i.e. missing `[]`/`[3]`)
> * interaction with other Align* options (e.g. `AlignConsecutiveAssignments`, 
> two arrays one after another, `AlignConsecutiveDeclarations`).
In addition to that I want to see:
* How it behaves with a smaller column limit which would be violated if there 
is no additional wrapping. There I also want one without `verifyFormat`.
* With no column limit.
* Maybe with a `const`, `inline` or something similar. (How about east `const` 
vs. west `const`?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[PATCH] D101684: [WebAssembly] Add end-to-end codegen tests for wasm_simd128.h

2021-05-05 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D101684#2737868 , @tlively wrote:

> In D101684#2737842 , @penzn wrote:
>
>> I think there is another dimension to this aside from project composition - 
>> intrinsics have a tendency to "interact" with their surroundings, and it 
>> better to capture the IR rather than the end result. Even if we can verify 
>> that simple calls produce instructions we expect, this might not hold true 
>> is the arguments change, or the call is in a different context. IR 
>> definitely gives more opportunities to test things through.
>
> Yeah, the contract that specific instructions are generated really only holds 
> in trivial cases by design. I'm not sure how to best formalize that, though.

I don't know that much about intrinsics, but happy to help with test 
suggestions - do you have any practical examples of this you could show & I can 
see if I've got any ideas of good ways to test them?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101684

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

[PATCH] D101805: [WebAssembly] Add codegen test for wasm_simd128.h

2021-05-05 Thread Thomas Lively via Phabricator via cfe-commits

tlively added a comment.

Thanks, @hans! That's very surprising; I'll take a deeper look at what was 
going wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101805

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

[PATCH] D101805: [WebAssembly] Add codegen test for wasm_simd128.h

2021-05-05 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D101805#2739814 , @tlively wrote:

> Thanks, @hans! That's very surprising; I'll take a deeper look at what was 
> going wrong.

Labels (& instructions/values) are only named in ASSERTS enabled builds (or you 
can opt into them more narrowly with some other build config)

eg:
With asserts:

  ; Function Attrs: nounwind uwtable
  define dso_local void @func(i32 %b, i32 %i, i32 %j) local_unnamed_addr #0 {
  entry:
%tobool.not = icmp eq i32 %b, 0
br i1 %tobool.not, label %if.end, label %if.then
  
  if.then:  ; preds = %entry
tail call void (...) @f1() #2
br label %if.end
  
  if.end:   ; preds = %if.then, %entry
ret void
  }

Without asserts:

  ; Function Attrs: nounwind uwtable
  define dso_local void @func(i32 %0, i32 %1, i32 %2) local_unnamed_addr #0 {
%4 = icmp eq i32 %0, 0
br i1 %4, label %6, label %5
  
  5:; preds = %3
tail call void (...) @f1() #2
br label %6
  
  6:; preds = %5, %3
ret void
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101805

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

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Eliza Velasquez via Phabricator via cfe-commits

exv updated this revision to Diff 343142.
exv marked 3 inline comments as done.
exv added a comment.

- Incorporate krasimir's feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/FormatTokenLexer.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -358,6 +358,39 @@
   verifyFormat("return _name ?? \"DEF\";");
 }
 
+TEST_F(FormatTestCSharp, CSharpNullCoalescingAssignment) {
+  FormatStyle Style = getGoogleStyle(FormatStyle::LK_CSharp);
+  Style.SpaceBeforeAssignmentOperators = true;
+
+  verifyFormat(R"(test ??= ABC;)", Style);
+  verifyFormat(R"(test ??= true;)", Style);
+
+  Style.SpaceBeforeAssignmentOperators = false;
+
+  verifyFormat(R"(test??= ABC;)", Style);
+  verifyFormat(R"(test??= true;)", Style);
+}
+
+TEST_F(FormatTestCSharp, CSharpNullForgiving) {
+  FormatStyle Style = getGoogleStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat("var test = null!;", Style);
+  verifyFormat("string test = someFunctionCall()! + \"ABC\"!", Style);
+  verifyFormat("int test = (1! + 2 + bar! + foo())!", Style);
+  verifyFormat(R"(test ??= !foo!;)", Style);
+  verifyFormat("test = !bar! ?? !foo!;", Style);
+  verifyFormat("bool test = !(!true && !true! || !null && !null! || !false && "
+   "!false! && !bar()! + (!foo()))!",
+   Style);
+
+  // Check that line break keeps identifier with the bang.
+  Style.ColumnLimit = 14;
+
+  verifyFormat("var test =\n"
+   "foo!;",
+   Style);
+}
+
 TEST_F(FormatTestCSharp, AttributesIndentation) {
   FormatStyle Style = getMicrosoftStyle(FormatStyle::LK_CSharp);
   Style.AlwaysBreakAfterReturnType = FormatStyle::RTBS_None;
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1055,13 +1055,6 @@
 CurrentToken->Previous->setType(TT_OverloadedOperator);
   break;
 case tok::question:
-  if (Tok->is(TT_CSharpNullConditionalLSquare)) {
-if (!parseSquare())
-  return false;
-break;
-  }
-  if (Tok->isOneOf(TT_CSharpNullConditional, TT_CSharpNullCoalescing))
-break;
   if (Style.Language == FormatStyle::LK_JavaScript && Tok->Next &&
   Tok->Next->isOneOf(tok::semi, tok::comma, tok::colon, tok::r_paren,
  tok::r_brace)) {
@@ -1085,7 +1078,7 @@
 (Tok->Next && Tok->Next->isOneOf(tok::r_paren, tok::greater)) ||
 (Tok->Next && Tok->Next->is(tok::identifier) && Tok->Next->Next &&
  Tok->Next->Next->is(tok::equal))) {
-  Tok->setType(TT_CSharpNullable);
+  Tok->setType(TT_JsTypeOptionalQuestion);
   break;
 }
   }
@@ -1571,39 +1564,29 @@
   // The token type is already known.
   return;
 
-if (Style.isCSharp() && CurrentToken->is(tok::question)) {
-  if (CurrentToken->TokenText == "??") {
-Current.setType(TT_CSharpNullCoalescing);
-return;
-  }
-  if (CurrentToken->TokenText == "?.") {
-Current.setType(TT_CSharpNullConditional);
-return;
-  }
-  if (CurrentToken->TokenText == "?[") {
-Current.setType(TT_CSharpNullConditionalLSquare);
-return;
-  }
-}
-
-if (Style.Language == FormatStyle::LK_JavaScript) {
-  if (Current.is(tok::exclaim)) {
-if (Current.Previous &&
-(Keywords.IsJavaScriptIdentifier(
- *Current.Previous, /* AcceptIdentifierName= */ true) ||
- Current.Previous->isOneOf(
- tok::kw_namespace, tok::r_paren, tok::r_square, tok::r_brace,
- Keywords.kw_type, Keywords.kw_get, Keywords.kw_set) ||
- Current.Previous->Tok.isLiteral())) {
-  Current.setType(TT_JsNonNullAssertion);
-  return;
-}
-if (Current.Next &&
-Current.Next->isOneOf(TT_BinaryOperator, Keywords.kw_as)) {
+if ((Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp()) &&
+Current.is(tok::exclaim)) {
+  if (Current.Previous) {
+bool IsIdentifier =
+Style.Language == FormatStyle::LK_JavaScript
+? Keywords.IsJavaScriptIdentifier(
+  *Current.Previous, /* AcceptIdentifierName= */ true)
+: Current.Previous->is(tok::identifier);
+if (IsIdentifier ||
+Current.Previous->isOneOf(
+tok::kw_namespace, tok::r_paren, tok::r_square, tok::r_brace,
+tok::kw_false,

[PATCH] D101870: [clangd] Check if macro is already in the IdentifierTable before loading it

2021-05-05 Thread Queen Dela Cruz via Phabricator via cfe-commits

qdelacru updated this revision to Diff 343141.
qdelacru added a comment.

Added suggested new test case


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

https://reviews.llvm.org/D101870

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3139,6 +3139,15 @@
  Kind(CompletionItemKind::Constructor;
 }
 
+TEST(CompletionTest, NoCrashDueToMacroOrdering) {
+  EXPECT_THAT(completions(R"cpp(
+#define ECHO(X) X
+#define ECHO2(X) ECHO(X)
+int finish_preamble = EC^HO(2);)cpp")
+  .Completions,
+  UnorderedElementsAre(Labeled("ECHO(X)"), Labeled("ECHO2(X)")));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1105,14 +1105,19 @@
   ExternalPreprocessorSource *PreambleMacros = PP.getExternalSource();
   // As we have the names of the macros, we can look up their IdentifierInfo
   // and then use this to load just the macros we want.
+  const auto &ITable = PP.getIdentifierTable();
   IdentifierInfoLookup *PreambleIdentifiers =
-  PP.getIdentifierTable().getExternalIdentifierLookup();
+  ITable.getExternalIdentifierLookup();
+
   if (!PreambleIdentifiers || !PreambleMacros)
 return;
-  for (const auto &MacroName : Preamble.Macros.Names)
+  for (const auto &MacroName : Preamble.Macros.Names) {
+if (ITable.find(MacroName.getKey()) != ITable.end())
+  continue;
 if (auto *II = PreambleIdentifiers->get(MacroName.getKey()))
   if (II->isOutOfDate())
 PreambleMacros->updateOutOfDateIdentifier(*II);
+  }
 }
 
 // Invokes Sema code completion on a file.


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3139,6 +3139,15 @@
  Kind(CompletionItemKind::Constructor;
 }
 
+TEST(CompletionTest, NoCrashDueToMacroOrdering) {
+  EXPECT_THAT(completions(R"cpp(
+#define ECHO(X) X
+#define ECHO2(X) ECHO(X)
+int finish_preamble = EC^HO(2);)cpp")
+  .Completions,
+  UnorderedElementsAre(Labeled("ECHO(X)"), Labeled("ECHO2(X)")));
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1105,14 +1105,19 @@
   ExternalPreprocessorSource *PreambleMacros = PP.getExternalSource();
   // As we have the names of the macros, we can look up their IdentifierInfo
   // and then use this to load just the macros we want.
+  const auto &ITable = PP.getIdentifierTable();
   IdentifierInfoLookup *PreambleIdentifiers =
-  PP.getIdentifierTable().getExternalIdentifierLookup();
+  ITable.getExternalIdentifierLookup();
+
   if (!PreambleIdentifiers || !PreambleMacros)
 return;
-  for (const auto &MacroName : Preamble.Macros.Names)
+  for (const auto &MacroName : Preamble.Macros.Names) {
+if (ITable.find(MacroName.getKey()) != ITable.end())
+  continue;
 if (auto *II = PreambleIdentifiers->get(MacroName.getKey()))
   if (II->isOutOfDate())
 PreambleMacros->updateOutOfDateIdentifier(*II);
+  }
 }
 
 // Invokes Sema code completion on a file.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101702: [clang-format] Add more support for C# 8 nullables

2021-05-05 Thread Eliza Velasquez via Phabricator via cfe-commits

exv added a comment.

Rebased and comments addressed!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101702

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

[PATCH] D101860: [clang-format] Fix C# nullable-related errors

2021-05-05 Thread Eliza Velasquez via Phabricator via cfe-commits

exv updated this revision to Diff 343143.
exv marked an inline comment as done.
exv added a comment.

- Incorporate curdeius's feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101860

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/UnwrappedLineParser.h
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -848,6 +848,21 @@
   verifyFormat(R"(var x = (int?)y;)", Style); // Cast to a nullable type.
 
   verifyFormat(R"(var x = new MyContainer();)", Style); // Generics.
+
+  verifyFormat(R"(//
+public interface I {
+  int? Function();
+})",
+   Style); // Interface methods.
+
+  Style.ColumnLimit = 10;
+  verifyFormat(R"(//
+public VeryLongType? Function(
+int arg1,
+int arg2) {
+  //
+})",
+   Style); // ? sticks with identifier.
 }
 
 TEST_F(FormatTestCSharp, CSharpArraySubscripts) {
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -114,6 +114,7 @@
   void parseNew();
   void parseAccessSpecifier();
   bool parseEnum();
+  bool parseStructLike();
   void parseConcept();
   void parseRequires();
   void parseRequiresExpression(unsigned int OriginalLevel);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1316,15 +1316,7 @@
 case tok::kw_struct:
 case tok::kw_union:
 case tok::kw_class:
-  // parseRecord falls through and does not yet add an unwrapped line as a
-  // record declaration or definition can start a structural element.
-  parseRecord();
-  // This does not apply for Java, JavaScript and C#.
-  if (Style.Language == FormatStyle::LK_Java ||
-  Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp()) {
-if (FormatTok->is(tok::semi))
-  nextToken();
-addUnwrappedLine();
+  if (parseStructLike()) {
 return;
   }
   break;
@@ -1438,6 +1430,13 @@
 return;
   }
 
+  if (FormatTok->is(Keywords.kw_interface)) {
+if (parseStructLike()) {
+  return;
+}
+break;
+  }
+
   if (Style.isCpp() && FormatTok->is(TT_StatementMacro)) {
 parseStatementMacro();
 return;
@@ -2525,6 +2524,21 @@
   // "} n, m;" will end up in one unwrapped line.
 }
 
+bool UnwrappedLineParser::parseStructLike() {
+  // parseRecord falls through and does not yet add an unwrapped line as a
+  // record declaration or definition can start a structural element.
+  parseRecord();
+  // This does not apply to Java, JavaScript and C#.
+  if (Style.Language == FormatStyle::LK_Java ||
+  Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp()) {
+if (FormatTok->is(tok::semi))
+  nextToken();
+addUnwrappedLine();
+return true;
+  }
+  return false;
+}
+
 namespace {
 // A class used to set and restore the Token position when peeking
 // ahead in the token source.
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1078,7 +1078,7 @@
 (Tok->Next && Tok->Next->isOneOf(tok::r_paren, tok::greater)) ||
 (Tok->Next && Tok->Next->is(tok::identifier) && Tok->Next->Next &&
  Tok->Next->Next->is(tok::equal))) {
-  Tok->setType(TT_JsTypeOptionalQuestion);
+  Tok->setType(TT_CSharpNullable);
   break;
 }
   }
@@ -3161,7 +3161,7 @@
   return Style.SpacesInSquareBrackets;
 
 // No space before ? in nullable types.
-if (Right.is(TT_JsTypeOptionalQuestion))
+if (Right.is(TT_CSharpNullable))
   return false;
 
 // No space before null forgiving '!'.
@@ -3818,6 +3818,10 @@
 // Only break after commas for generic type constraints.
 if (Line.First->is(TT_CSharpGenericTypeConstraint))
   return Left.is(TT_CSharpGenericTypeConstraintComma);
+// Keep nullable operators attached to their identifiers.
+if (Right.is(TT_CSharpNullable)) {
+  return false;
+}
   } else if (Style.Language == FormatStyle::LK_Java) {
 if (Left.isOneOf(Keywords.kw_throws, Keywords.kw_extends,
  Keywords.kw_implements))
Index: clang/lib/Format/FormatToken.h
===
--- clang/lib/Format/FormatToken.h
+++ clang/lib/Format/FormatToken.h
@@

[PATCH] D101862: [clang-format] Rename common types between C#/JS

2021-05-05 Thread Eliza Velasquez via Phabricator via cfe-commits

exv updated this revision to Diff 343144.
exv added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101862

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1480,9 +1480,9 @@
 }
 case tok::equal:
   // Fat arrows (=>) have tok::TokenKind tok::equal but TokenType
-  // TT_JsFatArrow. The always start an expression or a child block if
+  // TT_FatArrow. The always start an expression or a child block if
   // followed by a curly.
-  if (FormatTok->is(TT_JsFatArrow)) {
+  if (FormatTok->is(TT_FatArrow)) {
 nextToken();
 if (FormatTok->is(tok::l_brace)) {
   // C# may break after => if the next character is a newline.
@@ -1588,7 +1588,7 @@
   --Line->Level;
   break;
 case tok::equal:
-  if (FormatTok->is(TT_JsFatArrow)) {
+  if (FormatTok->is(TT_FatArrow)) {
 ++Line->Level;
 do {
   nextToken();
@@ -1791,7 +1791,7 @@
   // replace this by using parseAssigmentExpression() inside.
   do {
 if (Style.isCSharp()) {
-  if (FormatTok->is(TT_JsFatArrow)) {
+  if (FormatTok->is(TT_FatArrow)) {
 nextToken();
 // Fat arrows can be followed by simple expressions or by child blocks
 // in curly braces.
@@ -1807,7 +1807,7 @@
 tryToParseJSFunction();
 continue;
   }
-  if (FormatTok->is(TT_JsFatArrow)) {
+  if (FormatTok->is(TT_FatArrow)) {
 nextToken();
 // Fat arrows can be followed by simple expressions or by child blocks
 // in curly braces.
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1365,7 +1365,7 @@
 if (!CurrentToken->isOneOf(
 TT_LambdaLSquare, TT_LambdaLBrace, TT_AttributeMacro,
 TT_ForEachMacro, TT_TypenameMacro, TT_FunctionLBrace,
-TT_ImplicitStringLiteral, TT_InlineASMBrace, TT_JsFatArrow,
+TT_ImplicitStringLiteral, TT_InlineASMBrace, TT_FatArrow,
 TT_LambdaArrow, TT_NamespaceMacro, TT_OverloadedOperator,
 TT_RegexLiteral, TT_TemplateString, TT_ObjCStringLiteral,
 TT_UntouchableMacroFunc, TT_ConstraintJunctions,
@@ -1578,13 +1578,13 @@
 tok::kw_false, tok::kw_true, Keywords.kw_type, Keywords.kw_get,
 Keywords.kw_set) ||
 Current.Previous->Tok.isLiteral()) {
-  Current.setType(TT_JsNonNullAssertion);
+  Current.setType(TT_NonNullAssertion);
   return;
 }
   }
   if (Current.Next &&
   Current.Next->isOneOf(TT_BinaryOperator, Keywords.kw_as)) {
-Current.setType(TT_JsNonNullAssertion);
+Current.setType(TT_NonNullAssertion);
 return;
   }
 }
@@ -2174,7 +2174,7 @@
 return prec::Assignment;
   if (Current->is(TT_LambdaArrow))
 return prec::Comma;
-  if (Current->is(TT_JsFatArrow))
+  if (Current->is(TT_FatArrow))
 return prec::Assignment;
   if (Current->isOneOf(tok::semi, TT_InlineASMColon, TT_SelectorName) ||
   (Current->is(tok::comment) && NextNonComment &&
@@ -3145,7 +3145,7 @@
   return true;
 
 // Spaces around '=>'.
-if (Left.is(TT_JsFatArrow) || Right.is(TT_JsFatArrow))
+if (Left.is(TT_FatArrow) || Right.is(TT_FatArrow))
   return true;
 
 // No spaces around attribute target colons
@@ -3165,7 +3165,7 @@
   return false;
 
 // No space before null forgiving '!'.
-if (Right.is(TT_JsNonNullAssertion))
+if (Right.is(TT_NonNullAssertion))
   return false;
 
 // No space between consecutive commas '[,,]'.
@@ -3193,7 +3193,7 @@
 Right.is(tok::l_paren))
   return true;
   } else if (Style.Language == FormatStyle::LK_JavaScript) {
-if (Left.is(TT_JsFatArrow))
+if (Left.is(TT_FatArrow))
   return true;
 // for await ( ...
 if (Right.is(tok::l_paren) && Left.is(Keywords.kw_await) && Left.Previous &&
@@ -3204,7 +3204,7 @@
   const FormatToken *Next = Right.MatchingParen->getNextNonComment();
   // An async arrow function, for example: `x = async () => foo();`,
   // as opposed to calling a function called async: `x = async();`
-  if (Next && Next->is(TT_JsFatArrow))
+  if (Next && Next->is(TT_FatArrow))
 return true;
 }
 if ((Left.is(TT_TemplateString) && Left.TokenText.endswith("${")) ||
@@ -3278,9 +3278,9 @@
   // locations that should have whitespace following are identified by the
   /

[PATCH] D101884: [WebAssembly] Fix constness of pointer params to load intrinsics

2021-05-05 Thread Thomas Lively via Phabricator via cfe-commits

tlively added a comment.

It only matters for pointer parameters. For example, `const int *` is 
meaningfully different from `int *`, but `const int` is not usefully different 
from `int`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101884

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

[PATCH] D101860: [clang-format] Fix C# nullable-related errors

2021-05-05 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101860

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

[PATCH] D101884: [WebAssembly] Fix constness of pointer params to load intrinsics

2021-05-05 Thread Heejin Ahn via Phabricator via cfe-commits

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

I see, thanks. Then other load instructions are OK not to be fixed?

- `v128.load`
- `v128.loadN_splat`
- `v128.loadNxM_s/u`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101884

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

[PATCH] D101937: [Clang][Manual] Mention -fdebug-info-for-profiling.

2021-05-05 Thread Michael Benfield via Phabricator via cfe-commits

mbenfield created this revision.
mbenfield added reviewers: rsmith, wmi.
Herald added a subscriber: wenlei.
mbenfield requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This option is necessary for effective AutoFDO, and it also seems that
the `create_llvm_prof` converter won't work if the binary is compiled
without it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101937

Files:
  clang/docs/UsersManual.rst


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1911,14 +1911,16 @@
 usual build cycle when using sample profilers for optimization:
 
 1. Build the code with source line table information. You can use all the
-   usual build flags that you always build your application with. The only
-   requirement is that you add ``-gline-tables-only`` or ``-g`` to the
-   command line. This is important for the profiler to be able to map
-   instructions back to source line locations.
+   usual build flags that you always build your application with. There are two
+   flags you must use. The first is ``-gline-tables-only`` or ``-g``. This is
+   important for the profiler to be able to map instructions back to source 
line
+   locations. The second is ``-fdebug-info-for-profiling``. This will add
+   discriminators so that different expressions on the same source line can be
+   distinguished, as well as some other changes making profiling more 
effective.
 
.. code-block:: console
 
- $ clang++ -O2 -gline-tables-only code.cc -o code
+ $ clang++ -O2 -fdebug-info-for-profiling -gline-tables-only code.cc -o 
code
 
 2. Run the executable under a sampling profiler. The specific profiler
you use does not really matter, as long as its output can be converted


Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1911,14 +1911,16 @@
 usual build cycle when using sample profilers for optimization:
 
 1. Build the code with source line table information. You can use all the
-   usual build flags that you always build your application with. The only
-   requirement is that you add ``-gline-tables-only`` or ``-g`` to the
-   command line. This is important for the profiler to be able to map
-   instructions back to source line locations.
+   usual build flags that you always build your application with. There are two
+   flags you must use. The first is ``-gline-tables-only`` or ``-g``. This is
+   important for the profiler to be able to map instructions back to source line
+   locations. The second is ``-fdebug-info-for-profiling``. This will add
+   discriminators so that different expressions on the same source line can be
+   distinguished, as well as some other changes making profiling more effective.
 
.. code-block:: console
 
- $ clang++ -O2 -gline-tables-only code.cc -o code
+ $ clang++ -O2 -fdebug-info-for-profiling -gline-tables-only code.cc -o code
 
 2. Run the executable under a sampling profiler. The specific profiler
you use does not really matter, as long as its output can be converted
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101878: [git-clang-format] Do not apply clang-format to symlinks

2021-05-05 Thread Björn Schäpers via Phabricator via cfe-commits

HazardyKnusperkeks added a comment.

I have not a great knowledge about python, but it looks okay.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101878

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

[PATCH] D101572: Make `hasTypeLoc` matcher support more node types.

2021-05-05 Thread Stephen Kelly via Phabricator via cfe-commits

steveire added a comment.

Please run `llvm-project/clang/docs/tools/dump_ast_matchers.py` to generate 
updated documentation for this (there is a `urlopen(url)` which slows things 
down, so I usually comment that out when running it).

Do you have this on a git clone somewhere? It's easier to take a patch and try 
it out from a git repo than phab.

Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:3919
+/// cxxFunctionalCastExpr(hasTypeLoc(loc(asString("struct Foo"
+///   matches Foo(1, 2)
+AST_POLYMORPHIC_MATCHER_P(

This should somehow document the types it works with. You don't have to add 
examples for all of the nodes though. `hasDeclaration` is another example of a 
matcher supporting many different nodes. It has `Usable as:` at the bottom of 
its docs which gets parsed by `dump_ast_matchers.py`. Please make a similar 
change here to verify that the script generates docs for each type.

Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:138-150
+template  struct disjunction;
+template  struct disjunction : public T {};
+template  struct disjunction {
+  using type =
+  typename std::conditional>::type;
+  static constexpr bool value = type::value;
+};

SilensAngelusNex wrote:
> Is there a better way to express this? I was originally using
> 
> ```
> template  struct is_one_of {
>   template 
>   static constexpr bool value = (std::is_base_of_v || ...);
> };
> ```
> but that didn't compile because `is_base_of_v` and fold expressions are C++17 
> features.
> 
> Maybe it would be better to just explicitly write out an overload of 
> `GetTypeSourceInfo` for each type?

I like your c++17 solution too, but given that we have 
`TypeListContainsSuperOf` in this file used for this kind of thing, I think it 
makes sense to use that. I think this will work:

```
template , 
T>::value>
  * = nullptr>
```

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101572

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

[PATCH] D101883: [WebAssembly] Update narrowing builtin function operand types

2021-05-05 Thread Thomas Lively via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG627a52695537: [WebAssembly] Update narrowing builtin 
function operand types (authored by tlively).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101883

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/test/CodeGen/builtins-wasm.c


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -857,7 +857,7 @@
   // WEBASSEMBLY: ret
 }
 
-u8x16 narrow_u_i8x16_i16x8(u16x8 low, u16x8 high) {
+u8x16 narrow_u_i8x16_i16x8(i16x8 low, i16x8 high) {
   return __builtin_wasm_narrow_u_i8x16_i16x8(low, high);
   // WEBASSEMBLY: call <16 x i8> @llvm.wasm.narrow.unsigned.v16i8.v8i16(
   // WEBASSEMBLY-SAME: <8 x i16> %low, <8 x i16> %high)
@@ -871,7 +871,7 @@
   // WEBASSEMBLY: ret
 }
 
-u16x8 narrow_u_i16x8_i32x4(u32x4 low, u32x4 high) {
+u16x8 narrow_u_i16x8_i32x4(i32x4 low, i32x4 high) {
   return __builtin_wasm_narrow_u_i16x8_i32x4(low, high);
   // WEBASSEMBLY: call <8 x i16> @llvm.wasm.narrow.unsigned.v8i16.v4i32(
   // WEBASSEMBLY-SAME: <4 x i32> %low, <4 x i32> %high)
Index: clang/include/clang/Basic/BuiltinsWebAssembly.def
===
--- clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -185,9 +185,9 @@
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_u_i32x4_f32x4, "V4iV4f", "nc", 
"simd128")
 
 TARGET_BUILTIN(__builtin_wasm_narrow_s_i8x16_i16x8, "V16ScV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_narrow_u_i8x16_i16x8, "V16UcV8UsV8Us", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_narrow_u_i8x16_i16x8, "V16UcV8sV8s", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_narrow_s_i16x8_i32x4, "V8sV4iV4i", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_narrow_u_i16x8_i32x4, "V8UsV4UiV4Ui", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_narrow_u_i16x8_i32x4, "V8UsV4iV4i", "nc", 
"simd128")
 
 TARGET_BUILTIN(__builtin_wasm_trunc_sat_zero_s_f64x2_i32x4, "V4iV2d", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_trunc_sat_zero_u_f64x2_i32x4, "V4UiV2d", "nc", 
"simd128")


Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -857,7 +857,7 @@
   // WEBASSEMBLY: ret
 }
 
-u8x16 narrow_u_i8x16_i16x8(u16x8 low, u16x8 high) {
+u8x16 narrow_u_i8x16_i16x8(i16x8 low, i16x8 high) {
   return __builtin_wasm_narrow_u_i8x16_i16x8(low, high);
   // WEBASSEMBLY: call <16 x i8> @llvm.wasm.narrow.unsigned.v16i8.v8i16(
   // WEBASSEMBLY-SAME: <8 x i16> %low, <8 x i16> %high)
@@ -871,7 +871,7 @@
   // WEBASSEMBLY: ret
 }
 
-u16x8 narrow_u_i16x8_i32x4(u32x4 low, u32x4 high) {
+u16x8 narrow_u_i16x8_i32x4(i32x4 low, i32x4 high) {
   return __builtin_wasm_narrow_u_i16x8_i32x4(low, high);
   // WEBASSEMBLY: call <8 x i16> @llvm.wasm.narrow.unsigned.v8i16.v4i32(
   // WEBASSEMBLY-SAME: <4 x i32> %low, <4 x i32> %high)
Index: clang/include/clang/Basic/BuiltinsWebAssembly.def
===
--- clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -185,9 +185,9 @@
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_u_i32x4_f32x4, "V4iV4f", "nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_narrow_s_i8x16_i16x8, "V16ScV8sV8s", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_narrow_u_i8x16_i16x8, "V16UcV8UsV8Us", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_narrow_u_i8x16_i16x8, "V16UcV8sV8s", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_narrow_s_i16x8_i32x4, "V8sV4iV4i", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_narrow_u_i16x8_i32x4, "V8UsV4UiV4Ui", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_narrow_u_i16x8_i32x4, "V8UsV4iV4i", "nc", "simd128")
 
 TARGET_BUILTIN(__builtin_wasm_trunc_sat_zero_s_f64x2_i32x4, "V4iV2d", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_trunc_sat_zero_u_f64x2_i32x4, "V4UiV2d", "nc", "simd128")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

1 2 >

1 - 100 of 190 matches

Mail list logo