date:20200918

[PATCH] D87888: [X86] Use inlineasm flag output for the _bittest* intrinsics.

2020-09-18 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added a comment.

In D87888#2281360 , @RKSimon wrote:

> Do we have sufficient backend test coverage for this?

Taking a closer look, I don't think our coverage is very good. We just have one 
test for each the 28 condition code strings we support and they are all 
identical tests that just change the string. So we don't have tests that use 
the condition code as a branch condition. But the code just emits a EFLAGS copy 
and X86ISD::SETCC so existing combines probably just work.

I did fine a copy paste mistake on one of the condition strings while reviewing 
the asm flags code. Fixed in 58ecbbcdcddf80b289c449b86d5996d58fba0d78 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87888

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

[PATCH] D85810: [clang] Pass-through remarks options to linker

2020-09-18 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:95
+if (F.empty())
+  F = llvm::sys::path::stem(Input.getBaseInput());
+  }

Is the `F.empty()` case unreachable? Please delete the code or add an assert



Comment at: clang/test/Driver/opt-record.c:47
+// No pass-through: lto is disabled
+// RUN: %clang -target x86_64 -### -o FOO -fdiagnostics-hotness-threshold=100 
-fsave-optimization-record %s 2>&1 | not FileCheck %s -check-prefix=CHECK-PASS
+

This looks strange. We don't test with `not FileCheck`

You are right that we should specify `x86_64-linux` because otherwise the 
command line is constructed from gcc (rarely used bare metal linking).

Suggest: use this RUN line to test the case without `-o`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85810

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

[PATCH] D87349: [clang] adapt c++17 behavior for dependent decltype-specifiers

2020-09-18 Thread Richard Smith - zygoloid via Phabricator via cfe-commits

rsmith added inline comments.



Comment at: clang/include/clang/AST/Type.h:4478
 
-  DecltypeType(Expr *E, QualType underlyingType, QualType can = QualType());
+  const ASTContext 
+  DecltypeType(Expr *E, QualType underlyingType, const ASTContext ,

We shouldn't store the context here. To provide it to the `Profile` 
implementation, use a `ContextualFoldingSet`.



Comment at: clang/include/clang/AST/Type.h:4499-4508
 /// Internal representation of canonical, dependent
 /// decltype(expr) types.
 ///
 /// This class is used internally by the ASTContext to manage
 /// canonical, dependent types, only. Clients will only see instances
 /// of this class via DecltypeType nodes.
+class DependentDecltypeType : public DecltypeType {

Can we remove this class now?



Comment at: clang/lib/AST/ASTContext.cpp:5342-5347
 /// Unlike many "get" functions, we don't unique DecltypeType
 /// nodes. This would never be helpful, since each such type has its own
 /// expression, and would not give a significant memory saving, since there
 /// is an Expr tree under each such type.
+/// The instantiation-dependent-but-not-type-dependent DecltypeType node is an
+/// exception, we unique it for forming correct substitutions in name mangling.

Maybe fold these two paragraphs together

> Unlike many "get" functions, we don't unique DecltypeType nodes unless 
> they are instantiation-dependent. [...] 



Comment at: clang/test/CodeGenCXX/mangle.cpp:805
 
-  // CHECK-LABEL: define weak_odr void 
@_ZN6test341fIiEEvDTstDTplcvT__EcvS1__EEE
+  // CHECK-LABEL: define weak_odr void @_ZN6test341fIiEEvm
   template void f(decltype(sizeof(1)));

hokein wrote:
> rsmith wrote:
> > rsmith wrote:
> > > sammccall wrote:
> > > > sammccall wrote:
> > > > > GCC mangles this as `_ZN6test341fIiEEvDTstDTplcvT__EcvS1__EEE`, so 
> > > > > we're breaking compat here :-\
> > > > > 
> > > > > And in fact we're just incorrect. 
> > > > > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling:
> > > > > 
> > > > > > If the operand expression of decltype is not 
> > > > > > instantiation-dependent then the resulting type is encoded directly.
> > > > > 
> > > > > Here, instantiation-dependent *is* explicitly defined as 
> > > > > "type-dependent or value-dependent or ...". And therefore these cases 
> > > > > must not be "encoded directly", including the motivating case 
> > > > > (decltype(N) where N is a typed constant whose initializer is 
> > > > > value-dependent).
> > > > > 
> > > > > We could consider not two but *three* types of decltypetypes:
> > > > >  - decltype(type-dependent), which is sugar for a canonical 
> > > > > DependentDeclTypeType
> > > > >  - decltype(instantiation-but-not-type-dependent), which is still 
> > > > > sugar for a concrete canonical type (per C++17) but mangles using the 
> > > > > expr (per cxxabi)
> > > > >  - decltype(non-dependent), which is sugar for a concrete canonical 
> > > > > type and mangles directly
> > > > > 
> > > > > This only works if it's OK for mangling to depend on non-canonical 
> > > > > type details - I don't know whether this is the case. @rsmith - any 
> > > > > hints here?
> > > > Hmm, my naive reading of the mangle code matches what I described.
> > > > 
> > > > The big comment in ItaniumMangle talks about related issues: 
> > > > https://github.com/llvm/llvm-project/blob/24238f09edb98b0f460aa41139874ae5d4e5cd8d/clang/lib/AST/ItaniumMangle.cpp#L2541-L2572
> > > > 
> > > > I don't really understand what's going on here, sorry.
> > > Looks like we need the single-step-desugaring loop below the big comment 
> > > you quoted to stop when it hits a `decltype` type. That's presumably 
> > > where we step from the instantiation-dependent-but-not-type-dependent 
> > > `decltype` node to its desugared type.
> > Also... the FIXME from that comment will apply here too. Given:
> > ```
> > template void f(decltype(sizeof(T)), decltype(sizeof(T))) {}
> > template void f(unsigned long, unsigned long);
> > ```
> > we currently (correctly, as far as I can see) use a substitution for the 
> > second parameter type, but with the change here, I don't think we will do 
> > so any more. We could fix that by deduplicating `DecltypeType`s when 
> > they're instantiation dependent but not dependent; that's what we do for 
> > `ConstantArrayType`'s size expression, for example. If we do that, we'll 
> > need to store the actual expression on the `DecltypeTypeLoc`, since we 
> > can't rely on the `DecltypeType` having the right expression any more (only 
> > an expression that's equivalent to it).
> Thanks for the hints and explanations.
> 
> > we currently (correctly, as far as I can see) use a substitution for the 
> > second parameter type, but with the change here, I don't think we will do 
> > so any more.
> 
> thanks for the example, yeah, the behavior was changed with the prior change

[PATCH] D87956: [WIP][IR] add fn attr for no_stack_protector; prevent inlining ssp into no-ssp

2020-09-18 Thread Nick Desaulniers via Phabricator via cfe-commits

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

Not ready for review yet, posting a WIP fix for 
https://bugs.llvm.org/show_bug.cgi?id=47479.

TODO next week:

- tests, tests, and more tests.
- interaction with `__attribute__((always_inline))`.
- fix TODOs in code.
- IR verifier that the attributes never have more than one ssp attr; they 
should be mutually exclusive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87956

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

[PATCH] D87956: [WIP][IR] add fn attr for no_stack_protector; prevent inlining ssp into no-ssp

2020-09-18 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers created this revision.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, steven_wu, 
hiraditya.
Herald added a reviewer: jdoerfert.
Herald added projects: clang, LLVM.
nickdesaulniers requested review of this revision.

It's currently ambiguous in IR whether the source language explicitly
did not want a stack a stack protector (in C, via function attribute
no_stack_protector) or doesn't care for any given function.

Prior to this, developers only had translation unit granularity to
enable or disable stack protectors via command line flags. Now we can do
so on a per function level granularity.

It's common for code that manipulates the stack via inline assembly or
that has to set up its own stack canary (such as the Linux kernel) would
like to avoid stack protectors in certain functions. In this case, we've
been bitten by numerous bugs where a callee with a stack protector is
inlined into an __attribute__((__no_stack_protector__)) caller, which
generally breaks the caller's assumptions about not having a stack
protector. LTO can exacerbate the issue.

While developers can avoid this by putting all no_stack_protector
functions in one translation unit together, it's generally not very
ergonomic or as ergonomic as a function attribute, and still doesn't
work for LTO. See also:
https://lore.kernel.org/linux-pm/20200915172658.1432732-1-r...@google.com/

Typically, when inlining a callee into a caller, the caller will be
upgraded in its level of stack protection (see adjustCallerSSPLevel()).
By adding an explicit attribute in the IR when the function attribute is
used in the source language, we can now identify such cases and prevent
inlining.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87956

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/stack-protector.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/CodeGen/SafeStack.cpp
  llvm/lib/CodeGen/StackProtector.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/IPO/ForceFunctionAttrs.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/lib/Transforms/Utils/InlineFunction.cpp
  llvm/test/Transforms/CodeExtractor/PartialInlineAttributes.ll
  llvm/test/Transforms/Inline/inline_ssp.ll

Index: llvm/test/Transforms/Inline/inline_ssp.ll
===
--- llvm/test/Transforms/Inline/inline_ssp.ll
+++ llvm/test/Transforms/Inline/inline_ssp.ll
@@ -2,6 +2,8 @@
 ; RUN: opt -passes='cgscc(inline)' %s -S | FileCheck %s
 ; Ensure SSP attributes are propagated correctly when inlining.
 
+; TODO: ensure no_stack_protector are not inlined.
+
 @.str = private unnamed_addr constant [11 x i8] c"fun_nossp\0A\00", align 1
 @.str1 = private unnamed_addr constant [9 x i8] c"fun_ssp\0A\00", align 1
 @.str2 = private unnamed_addr constant [15 x i8] c"fun_sspstrong\0A\00", align 1
Index: llvm/test/Transforms/CodeExtractor/PartialInlineAttributes.ll
===
--- llvm/test/Transforms/CodeExtractor/PartialInlineAttributes.ll
+++ llvm/test/Transforms/CodeExtractor/PartialInlineAttributes.ll
@@ -73,10 +73,10 @@
 attributes #0 = {
   inlinehint minsize noduplicate noimplicitfloat norecurse noredzone nounwind
   nonlazybind optsize safestack sanitize_address sanitize_hwaddress sanitize_memory
-  sanitize_thread ssp sspreq sspstrong strictfp uwtable "foo"="bar"
+  sanitize_thread no-ssp ssp sspreq sspstrong strictfp uwtable "foo"="bar"
   "patchable-function"="prologue-short-redirect" "probe-stack"="_foo_guard" "stack-probe-size"="4096" }
 
-; CHECK: attributes [[FN_ATTRS]] = { inlinehint minsize noduplicate noimplicitfloat norecurse noredzone nounwind nonlazybind optsize safestack sanitize_address sanitize_hwaddress sanitize_memory sanitize_thread ssp sspreq sspstrong strictfp uwtable "foo"="bar" "patchable-function"="prologue-short-redirect" "probe-stack"="_foo_guard" "stack-probe-size"="4096" }
+; CHECK: attributes [[FN_ATTRS]] = { inlinehint minsize noduplicate noimplicitfloat norecurse noredzone nounwind nonlazybind optsize safestack sanitize_address sanitize_hwaddress sanitize_memory sanitize_thread no-ssp ssp sspreq sspstrong strictfp uwtable "foo"="bar" "patchable-function"="prologue-short-redirect" "probe-stack"="_foo_guard" "stack-probe-size"="4096" }
 
 ; attributes to drop
 attributes #1 = {
Index: llvm/lib/Transforms/Utils/InlineFunction.cpp
===
--- llvm/lib/Transforms/Utils/InlineFunction.cpp
+++ llvm/lib/Transforms/Utils/InlineFunction.cpp
@@ -1676,6 +1676,16 @@
   return InlineResult::failure("incompatible GC");
   }
 
+  // Inlining a function the explicitly should not have a stack protector may
+  // break the code if inlined into a function that

[PATCH] D87949: [ThinLTO] Option to bypass function importing.

2020-09-18 Thread Teresa Johnson via Phabricator via cfe-commits

tejohnson added a comment.

Minor comments.




Comment at: clang/test/CodeGen/thinlto_embed_bitcode.ll:17
+; RUN: rm %t1.bc %t2.bc
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t-redo.o -x ir 
%t-embedded.bc -c -fthinlto-index=%t.o.thinlto.bc -mllvm 
-lto-embed-bitcode=post-merge-pre-opt -mllvm -thinlto-assume-merged
+; RUN: diff %t-redo.o %t.o

Can we do this clang invocation and diff later on so you don't need to redo the 
opt and llvm-lto steps below?



Comment at: llvm/include/llvm/LTO/LTOBackend.h:59
+
+/// Load the referenced modules, keeping their buffers alive in the provided
+/// OwnedImportLifetimeManager. Returns false if the operation failed.

Note this is for distributed ThinLTO.



Comment at: llvm/lib/LTO/LTOBackend.cpp:75
+cl::desc(
+"Assume the input has already undergone ThinLTO function importing."));
+

Nit on name/comment. It isn't just thinlto importing (also things like linkage 
type changes). I'm not sure of a concise name to represent this though. Because 
we do apply some ThinLTO optimizations from the index later (WPD). Maybe just 
expand the description to something like "ThinLTO function importing and other 
pre-optimization pipeline changes."?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87949

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

[PATCH] D82725: [PowerPC] Implement Move to VSR Mask builtins in LLVM/Clang

2020-09-18 Thread Amy Kwan 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 rG37e7673c21af: [PowerPC] Implement Move to VSR Mask builtins 
in LLVM/Clang (authored by amyk).

Changed prior to commit:
  https://reviews.llvm.org/D82725?vs=292634=292921#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82725

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-vector-mask-ops.ll

Index: llvm/test/CodeGen/PowerPC/p10-vector-mask-ops.ll
===
--- llvm/test/CodeGen/PowerPC/p10-vector-mask-ops.ll
+++ llvm/test/CodeGen/PowerPC/p10-vector-mask-ops.ll
@@ -165,3 +165,109 @@
   %cnt = tail call i64 @llvm.ppc.altivec.vcntmbd(<2 x i64> %a, i32 0)
   ret i64 %cnt
 }
+
+declare <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64)
+declare <8 x i16> @llvm.ppc.altivec.mtvsrhm(i64)
+declare <4 x i32> @llvm.ppc.altivec.mtvsrwm(i64)
+declare <2 x i64> @llvm.ppc.altivec.mtvsrdm(i64)
+declare <1 x i128> @llvm.ppc.altivec.mtvsrqm(i64)
+
+define <16 x i8>  @test_mtvsrbm(i64 %a) {
+; CHECK-LABEL: test_mtvsrbm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbm v2, r3
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 %a)
+  ret <16 x i8> %mv
+}
+
+define <16 x i8>  @test_mtvsrbmi() {
+; CHECK-LABEL: test_mtvsrbmi:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbmi v2, 1
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 1)
+  ret <16 x i8> %mv
+}
+
+define <16 x i8>  @test_mtvsrbmi2() {
+; CHECK-LABEL: test_mtvsrbmi2:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbmi v2, 255
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 255)
+  ret <16 x i8> %mv
+}
+
+define <16 x i8>  @test_mtvsrbmi3() {
+; CHECK-LABEL: test_mtvsrbmi3:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbmi v2, 65535
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 65535)
+  ret <16 x i8> %mv
+}
+
+define <16 x i8>  @test_mtvsrbmi4() {
+; CHECK-LABEL: test_mtvsrbmi4:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbmi v2, 0
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 65536)
+  ret <16 x i8> %mv
+}
+
+define <16 x i8>  @test_mtvsrbmi5() {
+; CHECK-LABEL: test_mtvsrbmi5:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrbmi v2, 10
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <16 x i8> @llvm.ppc.altivec.mtvsrbm(i64 65546)
+  ret <16 x i8> %mv
+}
+
+define <8 x i16> @test_mtvsrhm(i64 %a) {
+; CHECK-LABEL: test_mtvsrhm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrhm v2, r3
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <8 x i16> @llvm.ppc.altivec.mtvsrhm(i64 %a)
+  ret <8 x i16> %mv
+}
+
+define <4 x i32> @test_mtvsrwm(i64 %a) {
+; CHECK-LABEL: test_mtvsrwm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrwm v2, r3
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <4 x i32> @llvm.ppc.altivec.mtvsrwm(i64 %a)
+  ret <4 x i32> %mv
+}
+
+define <2 x i64> @test_mtvsrdm(i64 %a) {
+; CHECK-LABEL: test_mtvsrdm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrdm v2, r3
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <2 x i64> @llvm.ppc.altivec.mtvsrdm(i64 %a)
+  ret <2 x i64> %mv
+}
+
+define <1 x i128> @test_mtvsrqm(i64 %a) {
+; CHECK-LABEL: test_mtvsrqm:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtvsrqm v2, r3
+; CHECK-NEXT:blr
+entry:
+  %mv = tail call <1 x i128> @llvm.ppc.altivec.mtvsrqm(i64 %a)
+  ret <1 x i128> %mv
+}
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -1054,22 +1054,28 @@
v1i128:$vB))]>;
   def MTVSRBM : VXForm_RD5_XO5_RS5<1602, 16, (outs vrrc:$vD), (ins g8rc:$rB),
"mtvsrbm $vD, $rB", IIC_VecGeneral,
-   []>;
+   [(set v16i8:$vD,
+ (int_ppc_altivec_mtvsrbm i64:$rB))]>;
   def MTVSRHM : VXForm_RD5_XO5_RS5<1602, 17, (outs vrrc:$vD), (ins g8rc:$rB),
"mtvsrhm $vD, $rB", IIC_VecGeneral,
-   []>;
+   [(set v8i16:$vD,
+ (int_ppc_altivec_mtvsrhm i64:$rB))]>;
   def MTVSRWM : VXForm_RD5_XO5_RS5<1602, 18, (outs vrrc:$vD), (ins g8rc:$rB),
"mtvsrwm $vD, $rB",

[clang] 37e7673 - [PowerPC] Implement Move to VSR Mask builtins in LLVM/Clang

2020-09-18 Thread Amy Kwan via cfe-commits


Author: Amy Kwan
Date: 2020-09-18T18:16:14-05:00
New Revision: 37e7673c21af1531b601ca975cb6118d04b6e1cc

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

LOG: [PowerPC] Implement Move to VSR Mask builtins in LLVM/Clang

This patch implements the vec_gen[b|h|w|d|q]m function prototypes in altivec.h
in order to utilize the move to VSR with mask instructions introduced in 
Power10.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-p10vector.c
llvm/include/llvm/IR/IntrinsicsPowerPC.td
llvm/lib/Target/PowerPC/PPCInstrPrefix.td
llvm/test/CodeGen/PowerPC/p10-vector-mask-ops.ll

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 4b97cbc09209..777932a2e910 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -335,6 +335,13 @@ BUILTIN(__builtin_altivec_vcntmbh, "ULLiV8UsUi", "")
 BUILTIN(__builtin_altivec_vcntmbw, "ULLiV4UiUi", "")
 BUILTIN(__builtin_altivec_vcntmbd, "ULLiV2ULLiUi", "")
 
+// P10 Move to VSR with Mask built-ins.
+BUILTIN(__builtin_altivec_mtvsrbm, "V16UcULLi", "")
+BUILTIN(__builtin_altivec_mtvsrhm, "V8UsULLi", "")
+BUILTIN(__builtin_altivec_mtvsrwm, "V4UiULLi", "")
+BUILTIN(__builtin_altivec_mtvsrdm, "V2ULLiULLi", "")
+BUILTIN(__builtin_altivec_mtvsrqm, "V1ULLLiULLi", "")
+
 // P10 Vector Parallel Bits built-ins.
 BUILTIN(__builtin_altivec_vpdepd, "V2ULLiV2ULLiV2ULLi", "")
 BUILTIN(__builtin_altivec_vpextd, "V2ULLiV2ULLiV2ULLi", "")

diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 32b161d82d8e..905d06bdae68 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -17092,6 +17092,33 @@ vec_expandm(vector unsigned __int128 __a) {
  vector unsigned long long 
\
: __builtin_altivec_vcntmbd((__a), (unsigned int)(__mp)))
 
+/* vec_gen[b|h|w|d|q]m */
+
+static __inline__ vector unsigned char __ATTRS_o_ai
+vec_genbm(unsigned long long __bm) {
+  return __builtin_altivec_mtvsrbm(__bm);
+}
+
+static __inline__ vector unsigned short __ATTRS_o_ai
+vec_genhm(unsigned long long __bm) {
+  return __builtin_altivec_mtvsrhm(__bm);
+}
+
+static __inline__ vector unsigned int __ATTRS_o_ai
+vec_genwm(unsigned long long __bm) {
+  return __builtin_altivec_mtvsrwm(__bm);
+}
+
+static __inline__ vector unsigned long long __ATTRS_o_ai
+vec_gendm(unsigned long long __bm) {
+  return __builtin_altivec_mtvsrdm(__bm);
+}
+
+static __inline__ vector unsigned __int128 __ATTRS_o_ai
+vec_genqm(unsigned long long __bm) {
+  return __builtin_altivec_mtvsrqm(__bm);
+}
+
 /* vec_pdep */
 
 static __inline__ vector unsigned long long __ATTRS_o_ai

diff  --git a/clang/test/CodeGen/builtins-ppc-p10vector.c 
b/clang/test/CodeGen/builtins-ppc-p10vector.c
index 0f72c5b0146e..8557446de800 100644
--- a/clang/test/CodeGen/builtins-ppc-p10vector.c
+++ b/clang/test/CodeGen/builtins-ppc-p10vector.c
@@ -268,6 +268,71 @@ unsigned long long test_vec_cntm_ull(void) {
   return vec_cntm(vulla, 0);
 }
 
+vector unsigned char test_vec_genbm(void) {
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(ulla);
+}
+
+vector unsigned char test_vec_genbm_imm(void) {
+  // CHECK: store i64 1
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(1);
+}
+
+vector unsigned char test_vec_genbm_imm2(void) {
+  // CHECK: store i64 255
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(255);
+}
+
+vector unsigned char test_vec_genbm_imm3(void) {
+  // CHECK: store i64 65535
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(65535);
+}
+
+vector unsigned char test_vec_genbm_imm4(void) {
+  // CHECK: store i64 65536
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(65536);
+}
+
+vector unsigned char test_vec_genbm_imm5(void) {
+  // CHECK: store i64 65546
+  // CHECK: @llvm.ppc.altivec.mtvsrbm(i64 %{{.+}})
+  // CHECK-NEXT: ret <16 x i8>
+  return vec_genbm(65546);
+}
+
+vector unsigned short test_vec_genhm(void) {
+  // CHECK: @llvm.ppc.altivec.mtvsrhm(i64 %{{.+}})
+  // CHECK-NEXT: ret <8 x i16>
+  return vec_genhm(ulla);
+}
+
+vector unsigned int test_vec_genwm(void) {
+  // CHECK: @llvm.ppc.altivec.mtvsrwm(i64 %{{.+}})
+  // CHECK-NEXT: ret <4 x i32>
+  return vec_genwm(ulla);
+}
+
+vector unsigned long long test_vec_gendm(void) {
+  // CHECK: @llvm.ppc.altivec.mtvsrdm(i64 %{{.+}})
+  //

[PATCH] D87953: [xray] Function coverage groups

2020-09-18 Thread Ian Levesque via Phabricator via cfe-commits

ianlevesque created this revision.
ianlevesque added reviewers: dberris, MaskRay, kyulee.
Herald added subscribers: cfe-commits, dang.
Herald added a project: clang.
ianlevesque requested review of this revision.

Add the ability to selectively instrument a subset of functions by dividing the 
functions into N logical groups and then selecting a group to cover. By 
selecting different groups over time you could cover the entire application 
incrementally with lower overhead than instrumenting the entire application at 
once.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87953

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/XRayArgs.h
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/XRayArgs.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/xray-function-groups.cpp

Index: clang/test/CodeGen/xray-function-groups.cpp
===
--- /dev/null
+++ clang/test/CodeGen/xray-function-groups.cpp
@@ -0,0 +1,64 @@
+// RUN: %clang_cc1 -fxray-instrument -fxray-instruction-threshold=1 \
+// RUN:-fxray-function-groups=3 \
+// RUN:-fxray-selected-function-group=0 \
+// RUN:-x c++ -std=c++11 -emit-llvm -o - %s \
+// RUN:-triple x86_64-unknown-linux-gnu | FileCheck --check-prefix=GROUP0 %s
+
+// RUN: %clang_cc1 -fxray-instrument -fxray-instruction-threshold=1 \
+// RUN:-fxray-function-groups=3 \
+// RUN:-fxray-selected-function-group=1 \
+// RUN:-x c++ -std=c++11 -emit-llvm -o - %s \
+// RUN:-triple x86_64-unknown-linux-gnu | FileCheck --check-prefix=GROUP1 %s
+
+// RUN: %clang_cc1 -fxray-instrument -fxray-instruction-threshold=1 \
+// RUN:-fxray-function-groups=3 \
+// RUN:-fxray-selected-function-group=2 \
+// RUN:-x c++ -std=c++11 -emit-llvm -o - %s \
+// RUN:-triple x86_64-unknown-linux-gnu | FileCheck --check-prefix=GROUP2 %s
+
+int foo() { // part of group 0
+  return 1;
+}
+
+int bar() { // part of group 2
+  return 1;
+}
+
+int yarr() { // part of group 1
+  return 1;
+}
+
+[[clang::xray_always_instrument]] int always() { // part of group 0
+  return 1;
+}
+
+[[clang::xray_never_instrument]] int never() { // part of group 1
+  return 1;
+}
+
+// GROUP0: define{{.*}} i32 @_Z3foov() #[[ATTRS_FOO:[0-9]+]] {
+// GROUP0: define{{.*}} i32 @_Z3barv() #[[ATTRS_BAR:[0-9]+]] {
+// GROUP0: define{{.*}} i32 @_Z4yarrv() #[[ATTRS_BAR]] {
+// GROUP0: define{{.*}} i32 @_Z6alwaysv() #[[ATTRS_ALWAYS:[0-9]+]] {
+// GROUP0: define{{.*}} i32 @_Z5neverv() #[[ATTRS_NEVER:[0-9]+]] {
+// GROUP0-DAG: attributes #[[ATTRS_BAR]] = {{.*}} "function-instrument"="xray-never" {{.*}}
+// GROUP0-DAG: attributes #[[ATTRS_ALWAYS]] = {{.*}} "function-instrument"="xray-always" {{.*}}
+// GROUP0-DAG: attributes #[[ATTRS_NEVER]] = {{.*}} "function-instrument"="xray-never" {{.*}}
+
+// GROUP1: define{{.*}} i32 @_Z3foov() #[[ATTRS_FOO:[0-9]+]] {
+// GROUP1: define{{.*}} i32 @_Z3barv() #[[ATTRS_FOO]] {
+// GROUP1: define{{.*}} i32 @_Z4yarrv() #[[ATTRS_YARR:[0-9]+]] {
+// GROUP1: define{{.*}} i32 @_Z6alwaysv() #[[ATTRS_ALWAYS:[0-9]+]] {
+// GROUP1: define{{.*}} i32 @_Z5neverv() #[[ATTRS_NEVER:[0-9]+]] {
+// GROUP1-DAG: attributes #[[ATTRS_FOO]] = {{.*}} "function-instrument"="xray-never" {{.*}}
+// GROUP1-DAG: attributes #[[ATTRS_ALWAYS]] = {{.*}} "function-instrument"="xray-always" {{.*}}
+// GROUP1-DAG: attributes #[[ATTRS_NEVER]] = {{.*}} "function-instrument"="xray-never" {{.*}}
+
+// GROUP2: define{{.*}} i32 @_Z3foov() #[[ATTRS_FOO:[0-9]+]] {
+// GROUP2: define{{.*}} i32 @_Z3barv() #[[ATTRS_BAR:[0-9]+]] {
+// GROUP2: define{{.*}} i32 @_Z4yarrv() #[[ATTRS_FOO]] {
+// GROUP2: define{{.*}} i32 @_Z6alwaysv() #[[ATTRS_ALWAYS:[0-9]+]] {
+// GROUP2: define{{.*}} i32 @_Z5neverv() #[[ATTRS_NEVER:[0-9]+]] {
+// GROUP2-DAG: attributes #[[ATTRS_FOO]] = {{.*}} "function-instrument"="xray-never" {{.*}}
+// GROUP2-DAG: attributes #[[ATTRS_ALWAYS]] = {{.*}} "function-instrument"="xray-always" {{.*}}
+// GROUP2-DAG: attributes #[[ATTRS_NEVER]] = {{.*}} "function-instrument"="xray-never" {{.*}}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1130,6 +1130,20 @@
   getLastArgIntValue(Args, OPT_fxray_instruction_threshold_EQ, 200, Diags);
   Opts.XRayIgnoreLoops = Args.hasArg(OPT_fxray_ignore_loops);
   Opts.XRayOmitFunctionIndex = Args.hasArg(OPT_fno_xray_function_index);
+  Opts.XRayTotalFunctionGroups =
+  getLastArgIntValue(Args, OPT_fxray_function_groups, 1, Diags);
+  if (Opts.XRayTotalFunctionGroups < 1) {
+const Arg *A = Args.getLastArg(OPT_fxray_function_groups);
+Diags.Report(diag::err_drv_invalid_value)
+<< A->getAsString(Args) << A->getValue();
+  }
+

[PATCH] D84988: [Coverage] Add empty line regions to SkippedRegions

2020-09-18 Thread Zequan Wu via Phabricator via cfe-commits

zequanwu added a comment.

In D84988#2282849 , @vsk wrote:

> @zequanwu FTR, I don't have any outstanding concerns (I understand you might 
> be asking for a second reviewer to chime in though).

Thanks for reviewing. Then, I think it might be ready to land.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84988

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

[PATCH] D87943: [clang] Remove profile available check for fsplit-machine-functions.

2020-09-18 Thread Snehasish Kumar via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb86f1af42395: [clang] Remove profile available check for 
fsplit-machine-functions. (authored by snehasish).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87943

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fsplit-machine-functions.c


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,8 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires 
profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for 
target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4916,16 +4916,8 @@
options::OPT_fno_split_machine_functions)) {
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
-  if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
-  A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
-  }
+  if (A->getOption().matches(options::OPT_fsplit_machine_functions))
+A->render(Args, CmdArgs);
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getAsString(Args) << TripleStr;


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,8 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4916,16 +4916,8 @@
options::OPT_fno_split_machine_functions)) {
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
-  if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
-  A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
-  }
+  if (A->getOption().matches(options::OPT_fsplit_machine_functions))
+A->render(Args, CmdArgs);
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   <<

[clang] b86f1af - [clang] Remove profile available check for fsplit-machine-functions.

2020-09-18 Thread Snehasish Kumar via cfe-commits


Author: Snehasish Kumar
Date: 2020-09-18T15:08:00-07:00
New Revision: b86f1af423952d9f1dbe105b651b948ce0e1e8d0

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

LOG: [clang] Remove profile available check for fsplit-machine-functions.

Enforcing a profile available check in the driver does not work with
incremental LTO builds where the LTO backend invocation does not include
the profile flags. At this point the profiles have already been consumed
and the IR contains profile metadata. Instead we always pass through the
-fsplit-machine-functions flag on user request. The pass itself contains
a check to return early if no profile information is available.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/fsplit-machine-functions.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 67c17ee2cbb4..0c03a90b8566 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4916,16 +4916,8 @@ void Clang::ConstructJob(Compilation , const JobAction 
,
options::OPT_fno_split_machine_functions)) {
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
-  if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
-  A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
-  }
+  if (A->getOption().matches(options::OPT_fsplit_machine_functions))
+A->render(Args, CmdArgs);
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getAsString(Args) << TripleStr;

diff  --git a/clang/test/Driver/fsplit-machine-functions.c 
b/clang/test/Driver/fsplit-machine-functions.c
index e126e4d41edb..fc0bb31f0f2b 100644
--- a/clang/test/Driver/fsplit-machine-functions.c
+++ b/clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,8 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires 
profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for 
target



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

[PATCH] D87946: [OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

2020-09-18 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 added a comment.

In D87946#2283049 , @jdoerfert wrote:

> I guess you can try to use `sed` to update the tests.

That's what I did for all the clang tests, they all pass as far as I know and I 
can use the built clang to correctly build offloaded applications for CUDA at 
least. The tests that are problematic are the OpenMPOpt tests because I'm 
assuming they had a hard coded argument index somewhere into one of the runtime 
functions that needs to be incremented by one now.

I also didn't add the an ident_t argument to all of the runtime functions, only 
the ones that I could see being generated by `CGOpenMPRuntime.cpp`. I just made 
those functions pass in a `nullptr` if they call into one of the functions that 
requires an ident_t.




Comment at: openmp/libomptarget/src/interface.cpp:149
 
-EXTERN void __tgt_target_data_begin_nowait_mapper(int64_t device_id,
+EXTERN void __tgt_target_data_begin_nowait_mapper(const ident_t *loc, int64_t 
device_id,
 int32_t arg_num, void **args_base, void **args, int64_t *arg_sizes,

I should probably remove `const` here so we can pass `loc` to 
`__kmpc_omp_taskwait`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87946

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

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Artem Belevich via Phabricator via cfe-commits

tra added a comment.

In D84362#2283065 , @yaxunl wrote:

> I think this is probably a different issue. The issue reported in D84364 
>  was introduced by change in D84364 
> .

It's possible. Unfortunately it's only triggered by our internal tool and it's 
hard to create a public reproducer for it. I'll debug and try to fix it on 
Monday.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[PATCH] D82118: [clang][module] Improve incomplete-umbrella warning

2020-09-18 Thread Zixu Wang 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 rGed79827aea44: [clang][module] Improve incomplete-umbrella 
warning (authored by zixuw).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82118

Files:
  clang/lib/Lex/PPLexerChange.cpp
  clang/test/Modules/incomplete-umbrella.m


Index: clang/test/Modules/incomplete-umbrella.m
===
--- clang/test/Modules/incomplete-umbrella.m
+++ clang/test/Modules/incomplete-umbrella.m
@@ -6,8 +6,12 @@
 #import 
 @import Foo.Private;
 
-// CHECK: warning: umbrella header for module 'Foo' does not include header 
'Bar.h'
-// CHECK: warning: umbrella header for module 'Foo.Private' does not include 
header 'Baz.h'
+// CHECK: While building module 'Foo' imported from 
{{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :1:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]Headers[/\]}}FooPublic.h:2:1: warning: 
umbrella header for module 'Foo' does not include header 'Bar.h'
+// CHECK: While building module 'Foo' imported from 
{{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :2:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]PrivateHeaders[/\]}}Foo.h:2:1: warning: 
umbrella header for module 'Foo.Private' does not include header 'Baz.h'
 int foo() {
   int a = BAR_PUBLIC;
   int b = BAZ_PRIVATE;
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -263,10 +263,12 @@
 }
 
 void Preprocessor::diagnoseMissingHeaderInUmbrellaDir(const Module ) {
-  assert(Mod.getUmbrellaHeader() && "Module must use umbrella header");
-  SourceLocation StartLoc =
-  SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID());
-  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header, StartLoc))
+  const Module::Header  = Mod.getUmbrellaHeader();
+  assert(UmbrellaHeader.Entry && "Module must use umbrella header");
+  const FileID  = SourceMgr.translateFile(UmbrellaHeader.Entry);
+  SourceLocation ExpectedHeadersLoc = SourceMgr.getLocForEndOfFile(File);
+  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header,
+ ExpectedHeadersLoc))
 return;
 
   ModuleMap  = getHeaderSearchInfo().getModuleMap();
@@ -291,7 +293,7 @@
   // Find the relative path that would access this header.
   SmallString<128> RelativePath;
   computeRelativePath(FileMgr, Dir, *Header, RelativePath);
-  Diag(StartLoc, diag::warn_uncovered_module_header)
+  Diag(ExpectedHeadersLoc, diag::warn_uncovered_module_header)
   << Mod.getFullModuleName() << RelativePath;
 }
   }


Index: clang/test/Modules/incomplete-umbrella.m
===
--- clang/test/Modules/incomplete-umbrella.m
+++ clang/test/Modules/incomplete-umbrella.m
@@ -6,8 +6,12 @@
 #import 
 @import Foo.Private;
 
-// CHECK: warning: umbrella header for module 'Foo' does not include header 'Bar.h'
-// CHECK: warning: umbrella header for module 'Foo.Private' does not include header 'Baz.h'
+// CHECK: While building module 'Foo' imported from {{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :1:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]Headers[/\]}}FooPublic.h:2:1: warning: umbrella header for module 'Foo' does not include header 'Bar.h'
+// CHECK: While building module 'Foo' imported from {{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :2:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]PrivateHeaders[/\]}}Foo.h:2:1: warning: umbrella header for module 'Foo.Private' does not include header 'Baz.h'
 int foo() {
   int a = BAR_PUBLIC;
   int b = BAZ_PRIVATE;
Index: clang/lib/Lex/PPLexerChange.cpp
===
--- clang/lib/Lex/PPLexerChange.cpp
+++ clang/lib/Lex/PPLexerChange.cpp
@@ -263,10 +263,12 @@
 }
 
 void Preprocessor::diagnoseMissingHeaderInUmbrellaDir(const Module ) {
-  assert(Mod.getUmbrellaHeader() && "Module must use umbrella header");
-  SourceLocation StartLoc =
-  SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID());
-  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header, StartLoc))
+  const Module::Header  = Mod.getUmbrellaHeader();
+  assert(UmbrellaHeader.Entry && "Module must use umbrella header");
+  const FileID  = SourceMgr.translateFile(UmbrellaHeader.Entry);
+  SourceLocation ExpectedHeadersLoc = SourceMgr.getLocForEndOfFile(File);
+  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header,
+ ExpectedHeadersLoc))
 return;
 
   ModuleMap  = getHeaderSearchInfo().getModuleMap();
@@ -291,7 +293,7 @@
   // Find the

[clang] ed79827 - [clang][module] Improve incomplete-umbrella warning

2020-09-18 Thread Zixu Wang via cfe-commits


Author: Zixu Wang
Date: 2020-09-18T14:56:47-07:00
New Revision: ed79827aea444e6995fb3d36abc2bfd36331773c

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

LOG: [clang][module] Improve incomplete-umbrella warning

Change the warning message for -Wincomplete-umbrella to report the location of 
the umbrella header;

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

Added: 


Modified: 
clang/lib/Lex/PPLexerChange.cpp
clang/test/Modules/incomplete-umbrella.m

Removed: 




diff  --git a/clang/lib/Lex/PPLexerChange.cpp b/clang/lib/Lex/PPLexerChange.cpp
index b7c7e2693ef1..de7b9b73ddf7 100644
--- a/clang/lib/Lex/PPLexerChange.cpp
+++ b/clang/lib/Lex/PPLexerChange.cpp
@@ -263,10 +263,12 @@ static void collectAllSubModulesWithUmbrellaHeader(
 }
 
 void Preprocessor::diagnoseMissingHeaderInUmbrellaDir(const Module ) {
-  assert(Mod.getUmbrellaHeader() && "Module must use umbrella header");
-  SourceLocation StartLoc =
-  SourceMgr.getLocForStartOfFile(SourceMgr.getMainFileID());
-  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header, StartLoc))
+  const Module::Header  = Mod.getUmbrellaHeader();
+  assert(UmbrellaHeader.Entry && "Module must use umbrella header");
+  const FileID  = SourceMgr.translateFile(UmbrellaHeader.Entry);
+  SourceLocation ExpectedHeadersLoc = SourceMgr.getLocForEndOfFile(File);
+  if (getDiagnostics().isIgnored(diag::warn_uncovered_module_header,
+ ExpectedHeadersLoc))
 return;
 
   ModuleMap  = getHeaderSearchInfo().getModuleMap();
@@ -291,7 +293,7 @@ void Preprocessor::diagnoseMissingHeaderInUmbrellaDir(const 
Module ) {
   // Find the relative path that would access this header.
   SmallString<128> RelativePath;
   computeRelativePath(FileMgr, Dir, *Header, RelativePath);
-  Diag(StartLoc, diag::warn_uncovered_module_header)
+  Diag(ExpectedHeadersLoc, diag::warn_uncovered_module_header)
   << Mod.getFullModuleName() << RelativePath;
 }
   }

diff  --git a/clang/test/Modules/incomplete-umbrella.m 
b/clang/test/Modules/incomplete-umbrella.m
index 8760b815718b..0574921203b2 100644
--- a/clang/test/Modules/incomplete-umbrella.m
+++ b/clang/test/Modules/incomplete-umbrella.m
@@ -6,8 +6,12 @@
 #import 
 @import Foo.Private;
 
-// CHECK: warning: umbrella header for module 'Foo' does not include header 
'Bar.h'
-// CHECK: warning: umbrella header for module 'Foo.Private' does not include 
header 'Baz.h'
+// CHECK: While building module 'Foo' imported from 
{{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :1:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]Headers[/\]}}FooPublic.h:2:1: warning: 
umbrella header for module 'Foo' does not include header 'Bar.h'
+// CHECK: While building module 'Foo' imported from 
{{.*[/\]}}incomplete-umbrella.m:4:
+// CHECK-NEXT: In file included from :2:
+// CHECK-NEXT: {{.*Foo[.]framework[/\]PrivateHeaders[/\]}}Foo.h:2:1: warning: 
umbrella header for module 'Foo.Private' does not include header 'Baz.h'
 int foo() {
   int a = BAR_PUBLIC;
   int b = BAZ_PRIVATE;



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

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D84362#2283045 , @tra wrote:

> In D84362#2282992 , @yaxunl wrote:
>
>> The fix is for the change in D84364 . It 
>> has no effect on the change in this review. Are you sure the issue you saw 
>> is due to change in this review instead of change in D84364 
>> ?
>
> Pretty sure. We've bisected the failure specifically to commit 
> ee5519d323571c4a9a7d92cb817023c9b95334cd 
> , before 
>  D84364  landed.

I think this is probably a different issue. The issue reported in D84364 
 was introduced by change in D84364 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[PATCH] D87949: [ThinLTO] Option to bypass function importing.

2020-09-18 Thread Mircea Trofin via Phabricator via cfe-commits

mtrofin created this revision.
mtrofin added a reviewer: tejohnson.
Herald added subscribers: llvm-commits, cfe-commits, dexonsmith, steven_wu, 
hiraditya, inglorion.
Herald added a reviewer: alexshap.
Herald added projects: clang, LLVM.
mtrofin requested review of this revision.

This completes the circle, complementing -lto-embed-bitcode
(specifically, post-merge-pre-opt). Using -thinlto-assume-merged skips
function importing. The index file is still needed for the other data it
contains.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87949

Files:
  clang/include/clang/CodeGen/BackendUtil.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGen/thinlto_embed_bitcode.ll
  llvm/include/llvm/LTO/LTOBackend.h
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -69,6 +69,11 @@
   "Embed post merge, but before optimizations")),
 cl::desc("Embed LLVM bitcode in object files produced by LTO"));
 
+static cl::opt ThinLTOAssumeMerged(
+"thinlto-assume-merged", cl::init(false),
+cl::desc(
+"Assume the input has already undergone ThinLTO function importing."));
+
 LLVM_ATTRIBUTE_NORETURN static void reportOpenError(StringRef Path, Twine Msg) {
   errs() << "failed to open " << Path << ": " << Msg << '\n';
   errs().flush();
@@ -583,6 +588,21 @@
   if (Conf.PreOptModuleHook && !Conf.PreOptModuleHook(Task, Mod))
 return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
 
+  auto OptimizeAndCodegen =
+  [&](Module , TargetMachine *TM,
+  std::unique_ptr DiagnosticOutputFile) {
+if (!opt(Conf, TM, Task, Mod, /*IsThinLTO=*/true,
+ /*ExportSummary=*/nullptr, /*ImportSummary=*/,
+ CmdArgs))
+  return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
+
+codegen(Conf, TM, AddStream, Task, Mod, CombinedIndex);
+return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
+  };
+
+  if (ThinLTOAssumeMerged)
+return OptimizeAndCodegen(Mod, TM.get(), std::move(DiagnosticOutputFile));
+
   // When linking an ELF shared object, dso_local should be dropped. We
   // conservatively do this for -fpic.
   bool ClearDSOLocalOnDeclarations =
@@ -623,11 +643,81 @@
   if (Conf.PostImportModuleHook && !Conf.PostImportModuleHook(Task, Mod))
 return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
 
-  if (!opt(Conf, TM.get(), Task, Mod, /*IsThinLTO=*/true,
-   /*ExportSummary=*/nullptr, /*ImportSummary=*/,
-   CmdArgs))
-return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
+  return OptimizeAndCodegen(Mod, TM.get(), std::move(DiagnosticOutputFile));
+}
+
+BitcodeModule *lto::findThinLTOModule(MutableArrayRef BMs) {
+  if (ThinLTOAssumeMerged && BMs.size() == 1)
+return BMs.begin();
 
-  codegen(Conf, TM.get(), AddStream, Task, Mod, CombinedIndex);
-  return finalizeOptimizationRemarks(std::move(DiagnosticOutputFile));
+  for (BitcodeModule  : BMs) {
+Expected LTOInfo = BM.getLTOInfo();
+if (LTOInfo && LTOInfo->IsThinLTO)
+  return 
+  }
+  return nullptr;
 }
+
+Expected lto::findThinLTOModule(MemoryBufferRef MBRef) {
+  Expected> BMsOrErr = getBitcodeModuleList(MBRef);
+  if (!BMsOrErr)
+return BMsOrErr.takeError();
+
+  // The bitcode file may contain multiple modules, we want the one that is
+  // marked as being the ThinLTO module.
+  if (const BitcodeModule *Bm = lto::findThinLTOModule(*BMsOrErr))
+return *Bm;
+
+  return make_error("Could not find module summary",
+ inconvertibleErrorCode());
+}
+
+bool lto::loadReferencedModules(
+const Module , const ModuleSummaryIndex ,
+FunctionImporter::ImportMapTy ,
+MapVector ,
+std::vector>
+) {
+  if (ThinLTOAssumeMerged)
+return true;
+  // We can simply import the values mentioned in the combined index, since
+  // we should only invoke this using the individual indexes written out
+  // via a WriteIndexesThinBackend.
+  for (auto  : CombinedIndex) {
+// Ignore entries for undefined references.
+if (GlobalList.second.SummaryList.empty())
+  continue;
+
+auto GUID = GlobalList.first;
+for (auto  : GlobalList.second.SummaryList) {
+  // Skip the summaries for the importing module. These are included to
+  // e.g. record required linkage changes.
+  if (Summary->modulePath() == M.getModuleIdentifier())
+continue;
+  // Add an entry to provoke importing by thinBackend.
+  ImportList[Summary->modulePath()].insert(GUID);
+}
+  }
+
+  for (auto  : ImportList) {
+ErrorOr> MBOrErr =
+llvm::MemoryBuffer::getFile(I.first());
+if (!MBOrErr) {
+  errs() << "Error loading imported file '" << I.first()
+ << "': " <<

[PATCH] D87946: [OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

2020-09-18 Thread Johannes Doerfert via Phabricator via cfe-commits

jdoerfert added a comment.

I guess you can try to use `sed` to update the tests.




Comment at: openmp/libomptarget/include/omptarget.h:4
-// 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

this got messed up



Comment at: openmp/libomptarget/include/omptarget.h:121
+}; 
+
 /// This struct is a record of an entry point or global. For a function

just make the type opaque for now: `struct ident_t;` We will include the 
original definition later. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87946

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

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Artem Belevich via Phabricator via cfe-commits

tra added a comment.

In D84362#2282992 , @yaxunl wrote:

> The fix is for the change in D84364 . It has 
> no effect on the change in this review. Are you sure the issue you saw is due 
> to change in this review instead of change in D84364 
> ?

Pretty sure. We've bisected the failure specifically to commit 
ee5519d323571c4a9a7d92cb817023c9b95334cd 
, before  
D84364  landed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[clang-tools-extra] 549e55b - Temporarily Revert "[clangd] Add Random Forest runtime for code completion."

2020-09-18 Thread Eric Christopher via cfe-commits


Author: Eric Christopher
Date: 2020-09-18T14:47:43-07:00
New Revision: 549e55b3d5634870aa9d42135f51ad46a6a0e347

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

LOG: Temporarily Revert "[clangd] Add Random Forest runtime for code 
completion."
as a header doesn't appear to have made it into the commit.

This reverts commit 9b6765e784b39c88cb8cdb85ab083e6c95a997ed and followup

Added: 


Modified: 
clang-tools-extra/clangd/CMakeLists.txt
clang-tools-extra/clangd/unittests/CMakeLists.txt
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 
clang-tools-extra/clangd/quality/CompletionModel.cmake
clang-tools-extra/clangd/quality/CompletionModelCodegen.py
clang-tools-extra/clangd/quality/README.md
clang-tools-extra/clangd/quality/model/features.json
clang-tools-extra/clangd/quality/model/forest.json
clang-tools-extra/clangd/unittests/DecisionForestTests.cpp

clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
clang-tools-extra/clangd/unittests/decision_forest_model/features.json
clang-tools-extra/clangd/unittests/decision_forest_model/forest.json



diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 9d2ab5be222a..3a1a034ed17b 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -28,9 +28,6 @@ set(LLVM_LINK_COMPONENTS
   FrontendOpenMP
   Option
   )
-  
-include(${CMAKE_CURRENT_SOURCE_DIR}/quality/CompletionModel.cmake)
-gen_decision_forest(${CMAKE_CURRENT_SOURCE_DIR}/quality/model CompletionModel 
clang::clangd::Example)
 
 if(MSVC AND NOT CLANG_CL)
  set_source_files_properties(CompileCommands.cpp PROPERTIES COMPILE_FLAGS 
-wd4130) # disables C4130: logical operation on address of string constant
@@ -80,7 +77,6 @@ add_clang_library(clangDaemon
   TUScheduler.cpp
   URI.cpp
   XRefs.cpp
-  ${CMAKE_CURRENT_BINARY_DIR}/CompletionModel.cpp
 
   index/Background.cpp
   index/BackgroundIndexLoader.cpp
@@ -121,11 +117,6 @@ add_clang_library(clangDaemon
   omp_gen
   )
 
-# Include generated CompletionModel headers.
-target_include_directories(clangDaemon PUBLIC
-  $
-)
-
 clang_target_link_libraries(clangDaemon
   PRIVATE
   clangAST

diff  --git a/clang-tools-extra/clangd/quality/CompletionModel.cmake 
b/clang-tools-extra/clangd/quality/CompletionModel.cmake
deleted file mode 100644
index 60c6d2aa8433..
--- a/clang-tools-extra/clangd/quality/CompletionModel.cmake
+++ /dev/null
@@ -1,37 +0,0 @@
-# Run the Completion Model Codegenerator on the model present in the 
-# ${model} directory.
-# Produces a pair of files called ${filename}.h and  ${filename}.cpp in the 
-# ${CMAKE_CURRENT_BINARY_DIR}. The generated header
-# will define a C++ class called ${cpp_class} - which may be a
-# namespace-qualified class name.
-function(gen_decision_forest model filename cpp_class)
-  set(model_compiler 
${CMAKE_SOURCE_DIR}/../clang-tools-extra/clangd/quality/CompletionModelCodegen.py)
-  
-  set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
-  set(header_file ${output_dir}/${filename}.h)
-  set(cpp_file ${output_dir}/${filename}.cpp)
-
-  add_custom_command(OUTPUT ${header_file} ${cpp_file}
-COMMAND "${Python3_EXECUTABLE}" ${model_compiler}
-  --model ${model}
-  --output_dir ${output_dir}
-  --filename ${filename}
-  --cpp_class ${cpp_class}
-COMMENT "Generating code completion model runtime..."
-DEPENDS ${model_compiler} ${model}/forest.json ${model}/features.json
-VERBATIM )
-
-  set_source_files_properties(${header_file} PROPERTIES
-GENERATED 1)
-  set_source_files_properties(${cpp_file} PROPERTIES
-GENERATED 1)
-
-  # Disable unused label warning for generated files.
-  if (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
-set_source_files_properties(${cpp_file} PROPERTIES
-  COMPILE_FLAGS /wd4102)
-  else()
-set_source_files_properties(${cpp_file} PROPERTIES
-  COMPILE_FLAGS -Wno-unused)
-  endif()
-endfunction()

diff  --git a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py 
b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
deleted file mode 100644
index 20bfccd8806f..
--- a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
+++ /dev/null
@@ -1,290 +0,0 @@
-"""Code generator for Code Completion Model Inference.
-
-Tool runs on the Decision Forest model defined in {model} directory.
-It generates two files: {output_dir}/{filename}.h and 
{output_dir}/{filename}.cpp 
-The generated files defines the Example class named {cpp_class} having all the 
features as class members.
-The generated runtime provides an `Evaluate` function which can be used to 
score a code completion candidate.
-"""
-
-import argparse
-import json

[PATCH] D87946: [OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

2020-09-18 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 added a comment.

WIP for adding ident_t support to libomptarget. Still breaks some tests, just 
wanted to get a start.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87946

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

[PATCH] D87946: [OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

2020-09-18 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 created this revision.
jhuber6 added a reviewer: jdoerfert.
jhuber6 added a project: OpenMP.
Herald added subscribers: llvm-commits, openmp-commits, cfe-commits, jfb, 
guansong, yaxunl.
Herald added projects: clang, LLVM.
jhuber6 requested review of this revision.
Herald added a subscriber: sstefan1.

Add support for passing source locations to libomptarget runtime functions.  
This will allow the runtime system to give much more insightful error messages 
and debugging values.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87946

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/capturing_in_templates.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/declare_target_link_codegen.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_lambda_pointer_capturing.cpp
  clang/test/OpenMP/nvptx_target_requires_unified_shared_memory.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_data_codegen.cpp
  clang/test/OpenMP/target_data_use_device_addr_codegen.cpp
  clang/test/OpenMP/target_defaultmap_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_device_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_firstprivate_codegen.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp
  clang/test/OpenMP/target_map_codegen_00.cpp
  clang/test/OpenMP/target_map_codegen_01.cpp
  clang/test/OpenMP/target_map_codegen_02.cpp
  clang/test/OpenMP/target_map_codegen_03.cpp
  clang/test/OpenMP/target_map_codegen_04.cpp
  clang/test/OpenMP/target_map_codegen_05.cpp
  clang/test/OpenMP/target_map_codegen_06.cpp
  clang/test/OpenMP/target_map_codegen_07.cpp
  clang/test/OpenMP/target_map_codegen_08.cpp
  clang/test/OpenMP/target_map_codegen_09.cpp
  clang/test/OpenMP/target_map_codegen_10.cpp
  clang/test/OpenMP/target_map_codegen_11.cpp
  clang/test/OpenMP/target_map_codegen_12.cpp
  clang/test/OpenMP/target_map_codegen_13.cpp
  clang/test/OpenMP/target_map_codegen_14.cpp
  clang/test/OpenMP/target_map_codegen_15.cpp
  clang/test/OpenMP/target_map_codegen_16.cpp
  clang/test/OpenMP/target_map_codegen_17.cpp
  clang/test/OpenMP/target_map_codegen_18.inc
  clang/test/OpenMP/target_map_codegen_19.cpp
  clang/test/OpenMP/target_map_codegen_20.cpp
  clang/test/OpenMP/target_map_codegen_21.cpp
  clang/test/OpenMP/target_map_codegen_22.cpp
  clang/test/OpenMP/target_map_codegen_23.cpp
  clang/test/OpenMP/target_map_codegen_24.cpp
  clang/test/OpenMP/target_map_codegen_25.cpp
  clang/test/OpenMP/target_map_codegen_26.cpp
  clang/test/OpenMP/target_map_codegen_27.cpp
  clang/test/OpenMP/target_map_codegen_28.cpp
  clang/test/OpenMP/target_map_codegen_29.cpp
  clang/test/OpenMP/target_map_codegen_30.cpp
  clang/test/OpenMP/target_map_codegen_31.cpp
  clang/test/OpenMP/target_map_codegen_32.cpp
  clang/test/OpenMP/target_map_codegen_33.cpp
  clang/test/OpenMP/target_map_member_expr_array_section_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp

[PATCH] D87604: [X86] Convert integer _mm_reduce_* intrinsics to emit llvm.reduction intrinsics (PR47506)

2020-09-18 Thread Simon Pilgrim via Phabricator via cfe-commits

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

WIP until reductions are no longer experimental


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87604

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

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D84362#2282965 , @tra wrote:

> In D84362#2282890 , @yaxunl wrote:
>
>> I have a fix for the issue reported in D84364 
>> . Would you like to try? Thanks.
>
> I can try it on the internal test that crashed with the patch. I've reopened 
> this review and will pick up the diff once you update it.

The fix is for the change in D84364 . It has 
no effect on the change in this review. Are you sure the issue you saw is due 
to change in this review instead of change in D84364 
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[PATCH] D87720: Sema: add support for `attribute((__swift_private__))`

2020-09-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

gribozavr2 added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3592
+  let Content = [{
+Objective-C declarations marked with the ``swift_private`` attribute are hidden
+from the framework client but are still made available for use within the

Please drop the "Objective-C" part.



Comment at: clang/include/clang/Basic/AttrDocs.td:3597
+The purpose of this attribute is to permit a more idomatic implementation of
+declarations in Swift.
+  }];

..., while hiding the non-idiomatic one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87720

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

[PATCH] D87394: [PowerPC][Power10] Implementation of 128-bit Binary Vector Mod and Sign Extend builtins

2020-09-18 Thread Albion Fung via Phabricator via cfe-commits

Conanap updated this revision to Diff 292901.
Conanap added a comment.

Open coded VMODS/UQ instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87394

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10vector.c
  clang/test/CodeGen/builtins-ppc-p9vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCInstrAltivec.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-vector-modulo.ll
  llvm/test/CodeGen/PowerPC/p10-vector-sign-extend.ll

Index: llvm/test/CodeGen/PowerPC/p10-vector-sign-extend.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/p10-vector-sign-extend.ll
@@ -0,0 +1,67 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
+
+; This test case aims to test vector sign extend builtins.
+
+declare <4 x i32> @llvm.ppc.altivec.vextsb2w(<16 x i8>) nounwind readnone
+declare <2 x i64> @llvm.ppc.altivec.vextsb2d(<16 x i8>) nounwind readnone
+declare <4 x i32> @llvm.ppc.altivec.vextsh2w(<8 x i16>) nounwind readnone
+declare <2 x i64> @llvm.ppc.altivec.vextsh2d(<8 x i16>) nounwind readnone
+declare <2 x i64> @llvm.ppc.altivec.vextsw2d(<4 x i32>) nounwind readnone
+declare <1 x i128> @llvm.ppc.altivec.vextsd2q(<2 x i64>) nounwind readnone
+
+define <4 x i32> @test_vextsb2w(<16 x i8> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsb2w:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsb2w v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <4 x i32> @llvm.ppc.altivec.vextsb2w(<16 x i8> %x)
+  ret <4 x i32> %tmp
+}
+
+define <2 x i64> @test_vextsb2d(<16 x i8> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsb2d:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsb2d v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vextsb2d(<16 x i8> %x)
+  ret <2 x i64> %tmp
+}
+
+define <4 x i32> @test_vextsh2w(<8 x i16> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsh2w:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsh2w v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <4 x i32> @llvm.ppc.altivec.vextsh2w(<8 x i16> %x)
+  ret <4 x i32> %tmp
+}
+
+define <2 x i64> @test_vextsh2d(<8 x i16> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsh2d:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsh2d v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vextsh2d(<8 x i16> %x)
+  ret <2 x i64> %tmp
+}
+
+define <2 x i64> @test_vextsw2d(<4 x i32> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsw2d:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsw2d v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <2 x i64> @llvm.ppc.altivec.vextsw2d(<4 x i32> %x)
+  ret <2 x i64> %tmp
+}
+
+define <1 x i128> @test_vextsd2q(<2 x i64> %x) nounwind readnone {
+; CHECK-LABEL: test_vextsd2q:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vextsd2q v2, v2
+; CHECK-NEXT:blr
+  %tmp = tail call <1 x i128> @llvm.ppc.altivec.vextsd2q(<2 x i64> %x)
+  ret <1 x i128> %tmp
+}
Index: llvm/test/CodeGen/PowerPC/p10-vector-modulo.ll
===
--- llvm/test/CodeGen/PowerPC/p10-vector-modulo.ll
+++ llvm/test/CodeGen/PowerPC/p10-vector-modulo.ll
@@ -10,6 +10,28 @@
 ; The vector modulo instructions operate on signed and unsigned words
 ; and doublewords.
 
+; The vector modulo instructions operate on signed and unsigned words,
+; doublewords and 128-bit values.
+
+
+define <1 x i128> @test_vmodsq(<1 x i128> %x, <1 x i128> %y) nounwind readnone {
+; CHECK-LABEL: test_vmodsq:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vmodsq v2, v2, v3
+; CHECK-NEXT:blr
+  %tmp = srem <1 x i128> %x, %y
+  ret <1 x i128> %tmp
+}
+
+define <1 x i128> @test_vmoduq(<1 x i128> %x, <1 x i128> %y) nounwind readnone {
+; CHECK-LABEL: test_vmoduq:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:vmoduq v2, v2, v3
+; CHECK-NEXT:blr
+  %tmp = urem <1 x i128> %x, %y
+  ret <1 x i128> %tmp
+}
+
 define <2 x i64> @test_vmodud(<2 x i64> %a, <2 x i64> %b) {
 ; CHECK-LABEL: test_vmodud:
 ; CHECK:   # %bb.0: # %entry
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -1301,11 +1301,14 @@
   def VCMPGTSQ_rec : VCMPo <903, "vcmpgtsq. $vD, $vA, $vB" , v1i128>;
   def VCMPGTUQ_rec : VCMPo <647, "vcmpgtuq. $vD, $vA, $vB" , v1i128>;
   def VMODSQ : VXForm_1<1803, (outs vrrc:$vD), (ins vrrc:$vA, vrrc:$vB),
-"vmodsq $vD, $vA, $vB", IIC_VecGeneral, []>;
+"vmodsq $vD, $vA, $vB",

[PATCH] D87629: Thread safety analysis: Improve documentation for ASSERT_CAPABILITY

2020-09-18 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

In D87629#2280475 , @ajtowns wrote:

> Sure, it makes perfect sense that it's too hard.

It's not really too hard, there is an existing parameter somewhere in the CFG 
generation that controls these exception handling edges, and we'd probably have 
to change some other diagnostics plus improve the performance/memory usage.

> But as far as I can see the end result is that catch blocks are treated as if 
> the code therein was annotated with NO_THREAD_SAFETY_ANALYSIS?

Not quite, if you have an explicit `throw` statement that connects to the 
`catch` block it will be analyzed just like anything else. Otherwise we 
currently see the catch block as unreachable (wrongly of course). Some other 
diagnostics work around that, but I don't think it's worth doing it here as 
well. We better fix the CFG.

>> You're cherry-picking here. If you move `i=9` into the catch block, there is 
>> still no warning.
>
> Right -- that was the `a=0` and `i=5` cases. But there's no way to get a 
> warning for those cases, no matter what I do, as far as I can see?

With an explicit throw you should be able to reach the catch block. Otherwise 
no.

>> And if you remove `if (b) thrower();` we wouldn't want the warning, because 
>> the assertion could be calling `std::abort` and then we'd have a false 
>> positive.
>
> I'd expect: `try { if (b) throw; x(); } catch(...) { } y(); ` and `if (!b) { 
> x(); } y();`
>
> to generate the same errors/warnings. If `x()` is marked 
> `ASSERT_CAPABILITY(m)` and `y()` is marked `REQUIRES(m)` they don't.

Right, if you have a `throw`, but that's not what I was saying. If there is no 
potentially throwing call before `x()` then `y()` can only be called after 
`x()`.

> But if I have to choose between getting warnings on bug free code, and not 
> getting warnings on buggy code, I think I'd rather get warnings on the bug 
> free code, since it's easy to make them go away just by moving the assertion 
> claim into the outer scope, or adding a second assertion later given it 
> compiles to a no-op.

Completely understand your sentiment here, but for a compiler warning that's 
treated as error on large code bases we have to be a bit careful. See e.g. 
D52395#1248608  by the original author 
of this feature. I've almost gotten those angry rollbacks, see e.g. 
D49355#1188448  or D52398#1255149 
.

>> Assertions aren't scoped. The easiest way to see that is that the destructor 
>> doesn't do anything.
>
> Right, and in a perfect world that would be fine; but when other parts of the 
> analysis aren't also perfect, it seems like it leads to false negatives that 
> let bugs through?

That's the situation, there are false negatives. And we're slowly trying to 
close the gaps. But hacky workarounds using misleading annotations don't 
improve it.

> I mean, I get that that's "wrong" in that it's generating the warning due to 
> the code path that's safe rather than the code path that's unsafe;

That's the key: It accidentally does the right thing in your example, but for 
the wrong reasons. (It thinks we get the capability, but then release it, 
whereas in reality we never had it.)

Regarding your analysis: scopes and code paths are orthogonal. Scopes are only 
interesting for lookup and automatic destructor calls of automatic storage 
duration variables. So they have nothing to with the validity of an assertion.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87629

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

[PATCH] D87943: [clang] Remove profile availabile check for fsplit-machine-functions.

2020-09-18 Thread Snehasish Kumar via Phabricator via cfe-commits

snehasish marked 2 inline comments as done.
snehasish added a comment.

Thanks for the quick review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87943

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

[PATCH] D87943: [clang] Remove profile availabile check for fsplit-machine-functions.

2020-09-18 Thread Snehasish Kumar via Phabricator via cfe-commits

snehasish updated this revision to Diff 292899.
snehasish added a comment.

Drop braces, add a test.

- Remove braces from single line if.
- Add a test to make sure that option is passed through even if no profiles 
provided.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87943

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fsplit-machine-functions.c


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,8 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires 
profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for 
target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4916,16 +4916,8 @@
options::OPT_fno_split_machine_functions)) {
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
-  if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
-  A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
-  }
+  if (A->getOption().matches(options::OPT_fsplit_machine_functions))
+A->render(Args, CmdArgs);
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getAsString(Args) << TripleStr;


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,8 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4916,16 +4916,8 @@
options::OPT_fno_split_machine_functions)) {
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
-  if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
-  A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
-  }
+  if (A->getOption().matches(options::OPT_fsplit_machine_functions))
+A->render(Args, CmdArgs);
 } else {

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Artem Belevich via Phabricator via cfe-commits

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

In D84362#2282890 , @yaxunl wrote:

> I have a fix for the issue reported in D84364 
> . Would you like to try? Thanks.

I can try it on the internal test that crashed with the patch. I've reopened 
this review and will pick up the diff once you update it.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[PATCH] D87779: [SyntaxTree] Test `findFirstLeaf` and `findLastLeaf`

2020-09-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

gribozavr2 added inline comments.



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:9
+//
+// This file tests the Syntax Tree base API.
+//

Please elaborate what "base API" covers -- specifically, what classes and such. 
 However, I'm not sure it is necessary to have this comment at all. Up to you.



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:39
+return ::testing::AssertionSuccess();
+  }
+

Is this copied from somewhere? I feel like other tests have this function 
already. Can we share?



Comment at: clang/unittests/Tooling/Syntax/TreeTest.cpp:52
+
+  // Generate Forests by combining `Children` under `ParentCount` Trees.
+  //

under => into?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87779

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

[PATCH] D87648: [Coverage][NFC] Remove skipped region after added into MappingRegions

2020-09-18 Thread Vedant Kumar via Phabricator via cfe-commits

vsk added a comment.

(Depending on what the potential performance gains look like, it might be 
advisable to keep things simple with the current O(n^2) approach. Optimizing 
things can carry some risk -- not sure if we've already ruled this out, but 
e.g. perhaps there's some edge case with nested functions where we maybe don't 
want to erase skipped regions eagerly.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87648

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

[PATCH] D87904: [AIX][Clang][Driver] Add handling of nostartfiles option

2020-09-18 Thread Jason Liu via Phabricator via cfe-commits

jasonliu accepted this revision.
jasonliu 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/D87904/new/

https://reviews.llvm.org/D87904

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

[PATCH] D87943: [clang] Remove profile availabile check for fsplit-machine-functions.

2020-09-18 Thread Teresa Johnson via Phabricator via cfe-commits

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

lgtm with a couple of minor suggestions




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4919
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
   if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
   A->render(Args, CmdArgs);

nit, remove braces per coding convention.



Comment at: clang/test/Driver/fsplit-machine-functions.c:3
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s

Might want to check that we get the option despite not having fprofile-use


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87943

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

[PATCH] D87648: [Coverage][NFC] Remove skipped region after added into MappingRegions

2020-09-18 Thread Vedant Kumar via Phabricator via cfe-commits

vsk added a comment.

Unfortunately it does look like the work done in gatherSkippedRegions is O(n^2) 
in the number of functions, at the moment. If the goal is to speed it up, it'd 
be good to grab some performance numbers for some representative compile unit 
(the sqlite3 amalgamation is my go-to for this sort of thing).




Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:353
+SkippedRanges.erase(
+std::remove_if(
+SkippedRanges.begin(), SkippedRanges.end(),

In the worst case, the work done in gatherSkippedRegions may still be n + (n-1) 
+ ... ~ O(n^2) (I'm subtracting 1 each time the skipped regions for a function 
are erased).



Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:356
+[&](SkippedRange I) {
+  SourceRange Range = I.Range;
+  auto LocStart = Range.getBegin();

It'd probably be good to split the lambda out into a separate/named helper.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87648

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

[PATCH] D87943: [clang] Remove profile availabile check for fsplit-machine-functions.

2020-09-18 Thread Snehasish Kumar via Phabricator via cfe-commits

snehasish created this revision.
snehasish added reviewers: tejohnson, davidxl.
Herald added subscribers: cfe-commits, dexonsmith.
Herald added a project: clang.
snehasish requested review of this revision.

Enforcing a profile available check in the driver does not work with
incremental LTO builds where the LTO backend invocation does not include
the profile flags. At this point the profiles have already been consumed
and the IR contains profile metadata. Instead we always pass through the
-fsplit-machine-functions flag on user request. The pass itself contains
a check to return early if no profile information is available.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87943

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fsplit-machine-functions.c


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,7 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata 
-fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck 
-check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires 
profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for 
target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4917,14 +4917,7 @@
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
   if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
   A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
   }
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)


Index: clang/test/Driver/fsplit-machine-functions.c
===
--- clang/test/Driver/fsplit-machine-functions.c
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -1,9 +1,7 @@
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
 // RUN: %clang -### -target x86_64 -fprofile-use=default.profdata -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
-// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
 // RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
 
 // CHECK-OPT:   "-fsplit-machine-functions"
 // CHECK-NOOPT-NOT: "-fsplit-machine-functions"
-// CHECK-WARN:  warning: argument '-fsplit-machine-functions' requires profile-guided optimization information
 // CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4917,14 +4917,7 @@
 // This codegen pass is only available on x86-elf targets.
 if (Triple.isX86() && Triple.isOSBinFormatELF()) {
   if (A->getOption().matches(options::OPT_fsplit_machine_functions)) {
-// If the flag is enabled but no profile information is available then
-// emit a warning.
-if (getLastProfileUseArg(Args) || getLastProfileSampleUseArg(Args)) {
   A->render(Args, CmdArgs);
-} else {
-  D.Diag(diag::warn_drv_diagnostics_hotness_requires_pgo)
-  << A->getAsString(Args);
-}
   }
 } else {
   D.Diag(diag::err_drv_unsupported_opt_for_target)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87942: [Analyzer] GNU named variadic macros in Plister

2020-09-18 Thread Chris Hamilton via Phabricator via cfe-commits

chrish_ericsson_atx created this revision.
chrish_ericsson_atx added reviewers: NoQ, Szelethus, dcoughlin.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, 
xazax.hun.
Herald added a project: clang.
chrish_ericsson_atx requested review of this revision.

Added support for GNU named variadic macros in
macro expansion for plist generation.

Fix for https://bugs.llvm.org/show_bug.cgi?id=44493


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87942

Files:
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  
clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
  clang/test/Analysis/plist-macros-with-expansion.cpp

Index: clang/test/Analysis/plist-macros-with-expansion.cpp
===
--- clang/test/Analysis/plist-macros-with-expansion.cpp
+++ clang/test/Analysis/plist-macros-with-expansion.cpp
@@ -529,3 +529,17 @@
 // FIXME: Stringify and escape __VA_ARGS__ correctly.
 // CHECK: nameSTRINGIFIED_VA_ARGS
 // CHECK-NEXT: expansionvariadicCFunction(x, Additional supply depots required., );x = 0;
+
+// bz44493: Support GNU-style named variadic arguments in plister
+#define bz44493_log(args...) \
+  do {   \
+  } while (0)
+
+int bz44493(void) {
+  int x = 1;
+  bz44493_log("arg");
+  bz44493_log("arg", "arg2");
+  int a;
+  a & 0xffc0; // expected-warning{{expression result unused}}
+  return 0;
+}
Index: clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
===
--- clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
+++ clang/test/Analysis/Inputs/expected-plists/plist-macros-with-expansion.cpp.plist
@@ -6787,6 +6787,221 @@

   
   
+  
+   path
+   
+
+ kindcontrol
+ edges
+  
+   
+start
+ 
+  
+   line539
+   col3
+   file0
+  
+  
+   line539
+   col5
+   file0
+  
+ 
+end
+ 
+  
+   line540
+   col3
+   file0
+  
+  
+   line540
+   col13
+   file0
+  
+ 
+   
+  
+
+
+ kindevent
+ location
+ 
+  line542
+  col3
+  file0
+ 
+ ranges
+ 
+   
+
+ line542
+ col3
+ file0
+
+
+ line542
+ col7
+ file0
+
+   
+ 
+ depth0
+ extended_message
+ a declared without an initial value
+ message
+ a declared without an initial value
+
+
+ kindcontrol
+ edges
+  
+   
+start
+ 
+  
+   line542
+   col3
+   file0
+  
+  
+   line542
+   col5
+   file0
+  
+ 
+end
+ 
+  
+   line543
+   col3
+   file0
+  
+  
+   line543
+   col3
+   file0
+  
+ 
+   
+  
+
+
+ kindcontrol
+ edges
+  
+   
+start
+ 
+  
+   line543
+   col3
+   file0
+  
+  
+   line543
+   col3
+   file0
+  
+ 
+end
+ 
+  
+   line543
+   col5
+   file0
+  
+  
+   line543
+   col5
+   file0
+  
+ 
+   
+  
+
+
+ kindevent
+ location
+ 
+  line543
+  col5
+  file0
+ 
+ ranges
+ 
+   
+
+ line543
+ col3
+ file0
+
+
+ line543
+ col3
+ file0
+
+   
+ 
+ depth0
+ extended_message
+ The left operand of  is a garbage value
+ message
+ The left operand of  is a garbage value
+
+   
+   macro_expansions
+   
+
+ location
+ 
+  line540
+  col3
+  file0
+ 
+ namebz44493_log
+ expansiondo { } while(0)
+
+
+ location
+ 
+  line541
+  col3
+  file0
+ 
+ namebz44493_log
+ expansiondo { } while(0)
+
+   
+   descriptionThe left operand of  is a garbage value
+   categoryLogic error
+   typeResult of operation is garbage or undefined
+   check_namecore.UndefinedBinaryOperatorResult
+   
+   issue_hash_content_of_line_in_context7515419ef7ac803c938efbeaf5ed1c6f
+  issue_context_kindfunction
+  issue_contextbz44493
+  issue_hash_function_offset5
+  location
+  
+   line543
+   col5
+   file0
+  
+  ExecutedLines
+  
+   0
+   
+538
+539
+540
+541
+542
+543
+   
+  
+  
  
  files
  
Index:

[PATCH] D87534: Sema: introduce `attribute((__swift_name__))`

2020-09-18 Thread Dmitri Gribenko via Phabricator via cfe-commits

gribozavr2 accepted this revision.
gribozavr2 added a comment.

> This introduces the new swift_name attribute that allows annotating
> interfaces with an alternate spelling for Swift. This is used as part
> of the importing mechanism to allow interfaces to be imported with a new

s/interfaces/APIs/ (to not confuse with Objective-C `@interface`)




Comment at: clang/include/clang/Basic/AttrDocs.td:3579-3580
+  let Content = [{
+The ``swift_name`` attribute provides the spelling for the transformed name 
when
+the interface is imported into the Swift language.
+

WDYT about:

The ``swift_name`` attribute specifies the name of the declaration in Swift. If 
this attribute is absent, the name is transformed according to the algorithm 
built into the Swift compiler.



Comment at: clang/include/clang/Basic/AttrDocs.td:3582
+
+The argument is the single string representation of the Swift function name.
+The name may be a compound Swift name.  For a type, enum constant, property, or

The argument is a string literal that contains the Swift name of the function, 
variable, or type. When renaming a function, the  name may be a compound Swift 
name.



Comment at: clang/include/clang/Basic/AttrDocs.td:3593
+void __attribute__((__swift_name__("function()"))) f(void) {
+}
+  }];

Could we try a more realistic example?

```
@interface URL
- (void) initWithString:(NSString*)s 
__attribute__((__swift_name__("URL.init(_:)")))
@end

double __attribute__((__swift_name__("squareRoot()"))) sqrt(double) {
}
```



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3982
+def warn_attr_swift_name_invalid_identifier
+  : Warning<"%0 attribute has invalid identifier for 
%select{base|context|parameter}1 name">,
+InGroup;

for => for the



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3988
+def warn_attr_swift_name_subscript_invalid_parameter
+  : Warning<"%0 attribute for 'subscript' must %select{be a getter or 
setter|have at least one parameter|have a 'self:' parameter}1">,
+InGroup;

80 columns.



Comment at: clang/include/clang/Sema/Sema.h:1837-1838
 
+  /// Do a check to make sure \p Name looks like a legal swift_name
+  /// attribute for the decl \p D. Raise a diagnostic if the name is invalid
+  /// for the given declaration.

"a legal argument for the swift_name attribute applied to decl \p D."



Comment at: clang/include/clang/Sema/Sema.h:1843-1844
+  /// e.g. init(foo:bar:baz:) or 
controllerForName(_:),
+  /// and the function will output the number of parameter names, and whether
+  /// this is a single-arg initializer.
+  ///

WDYM by "the function will output"? Which function, `DiagnoseSwiftName`? I 
think this part of the comment is about `validateSwiftFunctionName`.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:4282
+StringRef Name, bool Override) {
+  if (const auto *Inline = D->getAttr()) {
+if (Override) {

Why is the variable called `Inline`? Unless there's a reason, I'd suggest 
something that has a stronger connection, like `PreviousSNA`.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:5717
+  }
+  Parameters = Parameters.drop_back();  // ')'
+

Could you add an assert that the character being dropped is indeed ')'? There 
is an error above, but it is sort of far away and the connection between that 
line and this one is not obvious.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87534

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

[PATCH] D84362: [NFC] Refactor DiagnosticBuilder and PartialDiagnostic

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D84362#2279845 , @tra wrote:

> In D84362#2279688 , @tra wrote:
>
>> Apparently this patch triggers compiler crashes on some of our code. I'll 
>> try to create a reproducer, but it would be great to revert the patch for 
>> now.
>
> It's likely the same issue as the one reported in D84364 
> , but we probably triggered it independently.

I have a fix for the issue reported in D84364 
. Would you like to try? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84362

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

[PATCH] D84968: [PowerPC] Legalize v256i1 and v512i1 and implement load and store of these types

2020-09-18 Thread Amy Kwan via Phabricator via cfe-commits

amyk added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCInstrPrefix.td:846
+
+let Predicates = [MMA] in {
+  def : Pat<(v512i1 (PPCAccBuild v4i32:$vs1, v4i32:$vs0, v4i32:$vs3, 
v4i32:$vs2)),

Just my opinion but maybe we can put this block under the anonymous patterns. 


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

https://reviews.llvm.org/D84968

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

[PATCH] D84364: [CUDA][HIP] Defer overloading resolution diagnostics for host device functions

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D84364#2282458 , @hctim wrote:

> Not a known issue - no, but MSan doesn't play nice with uninistrumented 
> libraries (including things like libcxx) - and so it can be tricky to ensure 
> your build is properly sanitized, which is why I'd recommend the build script 
> :).

Thanks for the suggestion. I reproduced the issue with the build script and 
fixed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84364

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

[PATCH] D87702: [Frontend] Add pragma align natural and sort out pragma pack stack effect

2020-09-18 Thread Jason Liu via Phabricator via cfe-commits

jasonliu added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:66
 #include "llvm/Frontend/OpenMP/OMPConstants.h"
+#include 
 #include 

Do we need cmath?



Comment at: clang/include/clang/Sema/Sema.h:488
+AlignPackInfo(AlignPackInfo::Mode M, int Num, bool IsAIX)
+: PackAttr(true), AlignMode(M), PackNumber(Num), AIXStack(IsAIX) {}
+

I noticed PackNumber is an unsigned char and we are passing an int type into it.
Could we add an assertion in the constructor to make sure Num would never be 
something that's going to get truncated when it converts to an unsigned char?



Comment at: clang/include/clang/Sema/Sema.h:504
+unsigned getPackNumber() const { return PackNumber; }
+void setPackNumber(int Num) { PackNumber = Num; }
+

I don't see this function gets referenced in this patch. 



Comment at: clang/include/clang/Sema/Sema.h:514
+
+bool operator==(AlignPackInfo Info) const {
+  return AlignMode == Info.AlignMode && PackNumber == Info.PackNumber;

I think a normal operator== signature would look like this:
bool operator==(const AlignPackInfo ) const;



Comment at: clang/include/clang/Sema/Sema.h:515
+bool operator==(AlignPackInfo Info) const {
+  return AlignMode == Info.AlignMode && PackNumber == Info.PackNumber;
+}

This could return true when `PackAttr` in AlignPackInfo are not the same. 
Wouldn't that cause an issue?



Comment at: clang/include/clang/Sema/Sema.h:519
+bool operator!=(AlignPackInfo Info) const {
+  return AlignMode != Info.AlignMode || PackNumber != Info.PackNumber;
+}

You should be able to implement this using "operator==" right?
e.g. return !(*this == Info);




Comment at: clang/include/clang/Sema/Sema.h:524
+/// \brief True if this is a pragma pack attribute,
+// not a pragma align attribute.
+bool PackAttr;





Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:697
 InferAlignment(false), Packed(false), IsUnion(false),
-IsMac68kAlign(false), IsMsStruct(false), UnfilledBitsInLastUnit(0),
-LastBitfieldTypeSize(0), MaxFieldAlignment(CharUnits::Zero()),
-DataSize(0), NonVirtualSize(CharUnits::Zero()),
+IsMac68kAlign(false), IsNaturalAlign(false), IsMsStruct(false),
+UnfilledBitsInLastUnit(0), LastBitfieldTypeSize(0),

This could probably confuse people, as natural alignment is the default on most 
target except AIX.



Comment at: clang/lib/Sema/SemaAttr.cpp:403
   // Warn about modified alignment after #includes.
   if (PrevPackState.CurrentValue != PackStack.CurrentValue) {
 Diag(IncludeLoc, diag::warn_pragma_pack_modified_after_include);

Since we changed the PackStack for it to contain AlignPackInfo instead of 
unsigned. 
This stack no longer only contains Pack information. So we need to rethink 
about how this diagnostic and the one follows should work.
i.e. What's the purpose of these diagnostic? Is it still only for pragma pack 
report? If so, what we are doing here is not correct, since the `CurrentValue` 
could be different, not because of the pragma pack change, but because of the 
pragma align change.
If it's not only for pragma pack any more, but also intend to detect the pragma 
align interaction, then possibly function name and diagnostic needs some 
modification, as they don't match the intent any more.


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

https://reviews.llvm.org/D87702

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

[PATCH] D84988: [Coverage] Add empty line regions to SkippedRegions

2020-09-18 Thread Vedant Kumar via Phabricator via cfe-commits

vsk added a comment.

@zequanwu FTR, I don't have any outstanding concerns (I understand you might be 
asking for a second reviewer to chime in though).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84988

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

[PATCH] D68364: Implement C++20's P0784 (More constexpr containers)

2020-09-18 Thread Louis Dionne via Phabricator via cfe-commits

ldionne added a subscriber: jwakely.
ldionne added inline comments.



Comment at: libcxx/include/new:243
 # ifdef _LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE
 return ::operator new(__size, __align_val);
 # else

This breaks GCC (as of GCC 9). I don't know what mechanism GCC uses to tie into 
constexpr allocation, so I don't know what the fix is.

@jwakely Can you throw some hints at me?



Comment at: libcxx/include/version:254
 // # define __cpp_lib_concepts 201806L
+# define __cpp_lib_constexpr_dynamic_alloc  201907L
 // # define __cpp_lib_constexpr_misc   201811L

rsmith wrote:
> ldionne wrote:
> > rsmith wrote:
> > > ldionne wrote:
> > > > rsmith wrote:
> > > > > Should this be conditioned on compiler support being available?
> > > > So.. I've decided not to do that in this patch so far.
> > > > 
> > > > The support for constexpr allocation was checked into Clang about a 
> > > > year ago, right? I actually expect this to be a slightly contentious 
> > > > point, but I'd like to assume that we're using a reasonably recent 
> > > > Clang. I don't see a strong point for being able to use new libc++ 
> > > > headers with an old Clang anyway, since vendors usually release the two 
> > > > together. IOW, supporting this would add complexity for virtually no 
> > > > benefit. I do agree it's a slightly more aggressive stance than we've 
> > > > had so far, but this sort of reasonable assumption makes it so much 
> > > > easier to write stuff for libc++.
> > > OK, just a few thoughts then I'm going to bow out of this; this seems 
> > > like a policy decision for the libc++ maintainers to make.
> > > 
> > > In favor of dropping support for new libc++ + old clang: we generally 
> > > don't permit version skew between different components of LLVM. It seems 
> > > reasonable to expect all wanted parts of a particular LLVM release to be 
> > > built together.
> > > 
> > > Against dropping support for new libc++ + old clang: we do support 
> > > installing more than one version of LLVM (and in particular more than one 
> > > version of Clang) on the same system, but because libc++ defaults to 
> > > being installed in `/usr/include/c++/v1`, we don't seem to encourage 
> > > installing more than one version of libc++, so -- even assuming we only 
> > > support the *newest* version of libc++ going into `/usr/include/c++/v1` 
> > > -- new versions of libc++ need to work with old versions of Clang.
> > > 
> > > I think (largely by accident) Clang will prefer a libc++ installed into 
> > > `/usr/lib/clang/$VER/include` over one from `/usr/include/c++/v1`. If we 
> > > switched to installing libc++ there, I don't see any technical barrier to 
> > > version-locking them, though I'm not sure what story that leaves for use 
> > > of libc++ with GCC and other compilers. It seems worth noting that this 
> > > is exactly what libstdc++ does in order to need to support only one 
> > > version of GCC.
> > > OK, just a few thoughts then I'm going to bow out of this; this seems 
> > > like a policy decision for the libc++ maintainers to make.
> > 
> > Hear hear!
> > 
> > 
> > > I think (largely by accident) Clang will prefer a libc++ installed into 
> > > `/usr/lib/clang/$VER/include` over one from `/usr/include/c++/v1`. If we 
> > > switched to installing libc++ there, I don't see any technical barrier to 
> > > version-locking them, though I'm not sure what story that leaves for use 
> > > of libc++ with GCC and other compilers. It seems worth noting that this 
> > > is exactly what libstdc++ does in order to need to support only one 
> > > version of GCC.
> > 
> > I think it would be great to do that. Honestly, this is a huge 
> > simplification and makes implementing new features much easier. Also, I 
> > think it's reasonable to support not-trunk compilers, like 6 months old or 
> > something like that. But not several years back.
> > 
> > One last question: do you know what controls where the libc++ headers are 
> > installed as part of the LLVM distribution?
> Install paths are set in `libcxx/include/CMakeLists.txt` for the headers and 
> in `libcxx/src/CMakeLists.txt` for the libraries (search for `install(`) 
> based on cmake variables LIBCXX_INSTALL_HEADER_PREFIX, LIBCXX_INSTALL_PREFIX, 
> and LIBCXX_INSTALL_LIBRARY_DIR.
> 
> It would probably make sense to put the libc++ headers into somewhere like 
> `/usr/lib/clang/$VER/include/c++` instead of directly in 
> `/usr/lib/clang/$VER/include`; that'll need some changes to the clang driver 
> to make sure we look there. But of course that's doable if the two are 
> version-locked :)
Oh, I thought it was more complicated than that for the LLVM distribution. Ok, 
thanks for the info.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68364

[clang-tools-extra] 8077779 - CompletionModelCodegen: Remove unused import

2020-09-18 Thread Nico Weber via cfe-commits


Author: Nico Weber
Date: 2020-09-18T16:24:58-04:00
New Revision: 80913e82bece68a2f929ae17bd0e9ba38ab0

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

LOG: CompletionModelCodegen: Remove unused import

The unused import is 3.4+, so it also breaks py2.7 compat.
But this is easy to fix :)

Added: 


Modified: 
clang-tools-extra/clangd/quality/CompletionModelCodegen.py

Removed: 




diff  --git a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py 
b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
index 3fd3872f423d..20bfccd8806f 100644
--- a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
+++ b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
@@ -9,7 +9,6 @@
 import argparse
 import json
 import struct
-from enum import Enum
 
 
 class CppClass:



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

[PATCH] D87931: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread Miklos Vajna via Phabricator via cfe-commits

vmiklos added a comment.

Thanks for the quick feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87931

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

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

2020-09-18 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo added a comment.

In D87188#2282502 , @nikic wrote:

> Based on an initial look, the changes in comparison predicates here are 
> probably a red herring. If I understand right, those predicates are switching 
> from signed to unsigned comparison (e.g. gt to hi). I also see similar 
> changes in IR. However, all the cases I looked at are actually correct (e.g. 
> abs(x) > abs(y) can be compared signed or unsigned for poisoning abs). 
> Assuming that this code is clean under ubsan, the problem is likely something 
> else.

I just checked, and the code is indeed clean under ubsan.

The changes in the asm is more than just a few places, so it's quite a bit of 
work to dissect which one of them (if the changes are localized into smaller 
individual changes) is the one that's causing the error...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[PATCH] D87931: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread Miklos Vajna 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 rGb168bbfae42e: [clang-format] Recognize hxx as a 
C++ header in clang-format-diff.py (authored by vmiklos).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87931

Files:
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  
r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|m|mm|inc|js|ts|proto'
-  r'|protodevel|java|cs)',
+  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
+  r'|proto|protodevel|java|cs)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|m|mm|inc|js|ts|proto'
-  r'|protodevel|java|cs)',
+  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
+  r'|proto|protodevel|java|cs)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b168bbf - [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread Miklos Vajna via cfe-commits


Author: Miklos Vajna
Date: 2020-09-18T21:43:18+02:00
New Revision: b168bbfae42e792542b4ced8729599524b9759c5

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

LOG: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

And shift "proto" to the next line to avoid a too long line.

Reviewed By: MyDeveloperDay

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

Added: 


Modified: 
clang/tools/clang-format/clang-format-diff.py

Removed: 




diff  --git a/clang/tools/clang-format/clang-format-
diff .py b/clang/tools/clang-format/clang-format-
diff .py
index c5331202fc1b..6e653a134289 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -47,8 +47,8 @@ def main():
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  
r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|m|mm|inc|js|ts|proto'
-  r'|protodevel|java|cs)',
+  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
+  r'|proto|protodevel|java|cs)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,



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

[PATCH] D87931: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay accepted this revision.
MyDeveloperDay 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/D87931/new/

https://reviews.llvm.org/D87931

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

[PATCH] D87931: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread Miklos Vajna via Phabricator via cfe-commits

vmiklos added a comment.

Mydeveloperday, Sam: could you please take a look? Hopefully a trivial one. 
Thanks :-)

There are some larger codebases like LibreOffice that use .hxx as their header 
file extension, it's a bit inconsistent that .cxx is recognized but .hxx is 
not. This is meant to fix the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87931

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

[PATCH] D87931: [clang-format] Recognize "hxx" as a C++ header in clang-format-diff.py

2020-09-18 Thread Miklos Vajna via Phabricator via cfe-commits

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

And shift "proto" to the next line to avoid a too long line.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87931

Files:
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  
r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|m|mm|inc|js|ts|proto'
-  r'|protodevel|java|cs)',
+  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
+  r'|proto|protodevel|java|cs)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|m|mm|inc|js|ts|proto'
-  r'|protodevel|java|cs)',
+  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
+  r'|proto|protodevel|java|cs)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 0ea2a57 - clangd: Make ompletionModelCodegen.py tpy2.7 compatible

2020-09-18 Thread Nico Weber via cfe-commits


Author: Nico Weber
Date: 2020-09-18T15:26:58-04:00
New Revision: 0ea2a57274225066ad81e971659222cf9ee1d12d

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

LOG: clangd:  Make ompletionModelCodegen.py tpy2.7 compatible

LLVM still supports Python 2.7, so unbreak bots that still run that.
In a separate commit so that this is easy to revert once we drop
support :)

Added: 


Modified: 
clang-tools-extra/clangd/quality/CompletionModelCodegen.py

Removed: 




diff  --git a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py 
b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
index 8f8234f6ebbc..3fd3872f423d 100644
--- a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
+++ b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
@@ -24,25 +24,26 @@ def __init__(self, cpp_class):
 
 def ns_begin(self):
 """Returns snippet for opening namespace declarations."""
-open_ns = [f"namespace {ns} {{" for ns in self.ns]
+open_ns = ["namespace %s {" % ns for ns in self.ns]
 return "\n".join(open_ns)
 
 def ns_end(self):
 """Returns snippet for closing namespace declarations."""
 close_ns = [
-f"}} // namespace {ns}" for ns in reversed(self.ns)]
+"} // namespace %s" % ns for ns in reversed(self.ns)]
 return "\n".join(close_ns)
 
 
 def header_guard(filename):
 '''Returns the header guard for the generated header.'''
-return f"GENERATED_DECISION_FOREST_MODEL_{filename.upper()}_H"
+return "GENERATED_DECISION_FOREST_MODEL_%s_H" % filename.upper()
 
 
 def boost_node(n, label, next_label):
 """Returns code snippet for a leaf/boost node.
 Adds value of leaf to the score and jumps to the root of the next tree."""
-return f"{label}: Score += {n['score']}; goto {next_label};"
+return "%s: Score += %s; goto %s;" % (
+label, n['score'], next_label)
 
 
 def if_greater_node(n, label, next_label):
@@ -52,7 +53,8 @@ def if_greater_node(n, label, next_label):
 are represented as IEEE 754, it order-encodes the floats to integers 
before comparing them.
 Control falls through if condition is evaluated to false."""
 threshold = n["threshold"]
-return f"{label}: if (E.{n['feature']} >= {order_encode(threshold)} 
/*{threshold}*/) goto {next_label};"
+return "%s: if (E.%s >= %s /*%s*/) goto %s;" % (
+label, n['feature'], order_encode(threshold), threshold, 
next_label)
 
 
 def if_member_node(n, label, next_label):
@@ -61,10 +63,11 @@ def if_member_node(n, label, next_label):
 described in the node.
 Control falls through if condition is evaluated to false."""
 members = '|'.join([
-f"BIT({n['feature']}_type::{member})"
+"BIT(%s_type::%s)" % (n['feature'], member)
 for member in n["set"]
 ])
-return f"{label}: if (E.{n['feature']} & ({members})) goto {next_label};"
+return "%s: if (E.%s & (%s)) goto %s;" % (
+label, n['feature'], members, next_label)
 
 
 def node(n, label, next_label):
@@ -76,7 +79,7 @@ def node(n, label, next_label):
 }[n['operation']](n, label, next_label)
 
 
-def tree(t, tree_num: int, node_num: int):
+def tree(t, tree_num, node_num):
 """Returns code for inferencing a Decision Tree.
 Also returns the size of the decision tree.
 
@@ -90,20 +93,20 @@ def tree(t, tree_num: int, node_num: int):
 immediately next label.
 -   Leaf node adds the value to the score and jumps to the next tree.
 """
-label = f"t{tree_num}_n{node_num}"
+label = "t%d_n%d" % (tree_num, node_num)
 code = []
 if node_num == 0:
-code.append(f"t{tree_num}:")
+code.append("t%d:" % tree_num)
 
 if t["operation"] == "boost":
-code.append(node(t, label=label, next_label=f"t{tree_num+1}"))
+code.append(node(t, label=label, next_label="t%d" % (tree_num + 1)))
 return code, 1
 
 false_code, false_size = tree(
 t['else'], tree_num=tree_num, node_num=node_num+1)
 
 true_node_num = node_num+false_size+1
-true_label = f"t{tree_num}_n{true_node_num}"
+true_label = "t%d_n%d" % (tree_num, true_node_num)
 
 true_code, true_size = tree(
 t['then'], tree_num=tree_num, node_num=true_node_num)
@@ -113,7 +116,7 @@ def tree(t, tree_num: int, node_num: int):
 return code+false_code+true_code, 1+false_size+true_size
 
 
-def gen_header_code(features_json: list, cpp_class, filename: str):
+def gen_header_code(features_json, cpp_class, filename):
 """Returns code for header declaring the inference runtime.
 
 Declares the Example class named {cpp_class} inside relevant namespaces.
@@ -127,43 +130,46 @@ class can be used to represent a code completion 
candidate.

[PATCH] D87928: Provide -fsource-dir flag in Clang

2020-09-18 Thread Petr Hosek via Phabricator via cfe-commits

phosek added a comment.

This change is trying to address the issues raised in D83154 
. There are still some open questions:

- Is `-fsource-dir` the best name for this flag?
- I'm not sure if `make_relative` should be applied to all source paths, or 
only paths that start with `SourceDir` which would exclude system paths outside 
of the source directory (e.g. it's probably undesirable to relativize paths to 
`/usr/include`)?
- If we decide to exclude source paths outside of the source directory, should 
we support `-fsource-dir` to be specified more then once to handle multiple 
source directories?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87928

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

[PATCH] D83154: clang: Add -fcoverage-prefix-map

2020-09-18 Thread Petr Hosek via Phabricator via cfe-commits

phosek added a comment.

In D83154#2277712 , @phosek wrote:

> In D83154#2277539 , @rnk wrote:
>
>> Yeah, my goal is for the build system to be able to avoid having to embed 
>> PWD into the compiler flags. For example, I believe it is a goal of the LLVM 
>> gn build system for the build tree to be relocatable. If the compiler 
>> command lines need to contain absolute paths to make the paths in the 
>> coverage relative, we won't be able to achieve that goal.
>>
>> Based on all the comments that have gone before, it sounds like we want a 
>> `-fprofile-compilation-dir=` flag. Once we have that, would this logic work?
>>
>> - if profile compilation dir set, absolutize with that as the root
>> - if no profile compilation dir, absolutize with CWD
>> - apply profile prefix map
>>
>> Should `-no-canonical-prefixes` also be involved here? Unclear.
>
> I originally considered `-fprofile-compilation-dir=` and perhaps 
> `-ffile-compilation-dir=` to also handle cases like `__FILE__` macro 
> (`-ffile-prefix-map` and `-fmacro-prefix-map` suffer from the same issue as 
> `-fprofile-prefix-map`), but I'm not sure if specifying compilation dir is 
> the right approach. It makes sense for debug info because 
> `-fdebug-compilation-dir` is used directly as `DW_AT_comp_dir` and also 
> because it's a convention for source file paths in debug info to be relative 
> to build directory, but it's not the case for paths in coverage mapping or 
> `__FILE__`.
>
> So what I'm considering now and started prototyping is a `-fsource-dir`flag 
> (or maybe `-fsource-root-dir`, I'm open to suggestions for the name) where 
> the semantics would be that if this flag is set, all source paths will be 
> made relative to this directory. There's an open question whether this should 
> also apply to sources outside of that directory, for example system header 
> paths.
>
> The example use case, assuming source is in `/path/to/source` and build is in 
> `/path/to/build`, would be: `clang -fdebug-compilation-dir . -fsource-dir 
> ../source ../source/dir/file.c`. In this case `__FILE__` would expand to 
> `dir/file.c` and that path would be also stored in coverage mapping.

D87928  is the implementation of that idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83154

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

[PATCH] D87928: Provide -fsource-dir flag in Clang

2020-09-18 Thread Petr Hosek via Phabricator via cfe-commits

phosek created this revision.
Herald added subscribers: llvm-commits, cfe-commits, dang, hiraditya.
Herald added projects: clang, LLVM.
phosek requested review of this revision.
Herald added a subscriber: ormris.

This flag can be used to relativize source paths againts a given
directory.  Compared to -f*-prefix-map flags, it avoids the absolute
path on the compiler command line analogously to -fdebug-compile-dir,
which is important  distributed compilation scenarios.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87928

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/PreprocessorOptions.h
  clang/lib/CodeGen/CoverageMappingGen.cpp
  clang/lib/CodeGen/CoverageMappingGen.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/test/CoverageMapping/source_dir.c
  clang/test/Preprocessor/file_test.c
  llvm/include/llvm/Support/Path.h
  llvm/lib/Support/Path.cpp
  llvm/unittests/Support/Path.cpp

Index: llvm/unittests/Support/Path.cpp
===
--- llvm/unittests/Support/Path.cpp
+++ llvm/unittests/Support/Path.cpp
@@ -1521,6 +1521,35 @@
   EXPECT_EQ(Path, "C:\\old/foo\\bar");
 }
 
+static std::string make_relative(StringRef from, StringRef to,
+ path::Style style) {
+  SmallString<256> buffer;
+  path::make_relative(from, to, buffer, style);
+  return std::string(buffer.str());
+}
+
+TEST(Support, MakeRelative) {
+  EXPECT_EQ("", make_relative("/a/b/c/d", "/a/b/c/d", path::Style::posix));
+  EXPECT_EQ("d", make_relative("/a/b/c/d", "/a/b/c", path::Style::posix));
+  EXPECT_EQ("c/d", make_relative("/a/b/c/d", "/a/b", path::Style::posix));
+  EXPECT_EQ("../../c/d",
+make_relative("/a/b/c/d", "/a/b/e/f", path::Style::posix));
+  EXPECT_EQ("../../../../a/b/c/d",
+make_relative("/a/b/c/d", "/e/f/g/h", path::Style::posix));
+
+  EXPECT_EQ("", make_relative("C:\\a\\b\\c\\d", "C:\\a\\b\\c\\d",
+  path::Style::windows));
+  EXPECT_EQ("d", make_relative("C:\\a\\b\\c\\d", "C:\\a\\b\\c",
+   path::Style::windows));
+  EXPECT_EQ("c\\d",
+make_relative("C:\\a\\b\\c\\d", "C:\\a\\b", path::Style::windows));
+  EXPECT_EQ("..\\..\\c\\d", make_relative("C:\\a\\b\\c\\d", "C:\\a\\b\\e\\f",
+  path::Style::windows));
+  EXPECT_EQ(
+  "..\\..\\..\\..\\a\\b\\c\\d",
+  make_relative("C:\\a\\b\\c\\d", "C:\\e\\f\\g\\h", path::Style::windows));
+}
+
 TEST_F(FileSystemTest, OpenFileForRead) {
   // Create a temp file.
   int FileDescriptor;
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -763,6 +763,22 @@
   return true;
 }
 
+void make_relative(StringRef from, StringRef to, SmallVectorImpl ,
+   Style style) {
+  SmallString<256> buffer;
+  auto fromIt = begin(from, style), fromE = end(from);
+  auto toIt = begin(to, style), toE = end(to);
+  // Find a common base.
+  for (; fromIt != fromE && toIt != toE && *fromIt == *toIt; ++fromIt, ++toIt)
+;
+  // Navigate backwards to the base.
+  for (; toIt != toE; ++toIt)
+if (*toIt != ".")
+  append(buffer, style, "..");
+  append(buffer, fromIt, fromE, style);
+  result.swap(buffer);
+}
+
 } // end namespace path
 
 namespace fs {
Index: llvm/include/llvm/Support/Path.h
===
--- llvm/include/llvm/Support/Path.h
+++ llvm/include/llvm/Support/Path.h
@@ -476,6 +476,10 @@
 bool remove_dots(SmallVectorImpl , bool remove_dot_dot = false,
  Style style = Style::native);
 
+/// Return a path that when appeneded to from resolves to the same as to.
+void make_relative(StringRef from, StringRef to, SmallVectorImpl ,
+   Style style = Style::native);
+
 } // end namespace path
 } // end namespace sys
 } // end namespace llvm
Index: clang/test/Preprocessor/file_test.c
===
--- clang/test/Preprocessor/file_test.c
+++ clang/test/Preprocessor/file_test.c
@@ -3,6 +3,7 @@
 // RUN: %clang -E -fmacro-prefix-map=%p=/UNLIKELY_PATH/empty -c -o - %s | FileCheck %s
 // RUN: %clang -E -fmacro-prefix-map=%p=/UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
 // RUN: %clang -E -fmacro-prefix-map=%p/= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+// RUN: %clang -E -fsource-dir %S -c -o - %s | FileCheck %s --check-prefix CHECK-RELATIVE
 
 filename: __FILE__
 #include "Inputs/include-file-test/file_test.h"
@@ -21,3 +22,8 @@
 // CHECK-REMOVE: filename: "Inputs/include-file-test/file_test.h"
 // CHECK-REMOVE: basefile: "file_test.c"
 // CHECK-REMOVE-NOT: filename:
+
+// CHECK-RELATIVE: filename: "file_test.c"

[PATCH] D86137: Add -Wno-error=unknown flag to clang-format.

2020-09-18 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

it certainly LGTM, like I said I've had met this issue before and I think this 
does get around that situation where perhaps your not even using the option 
it's complaining about (especially if its a C++ option and you are using 
clang-format for C#)

So yes I think it's good. Thank you for the patch and getting the commit access.

When you commit don't forget to keep an eye on the build_bots at 
http://lab.llvm.org:8011/ this was something I didn't learn about until after 
my first commit... (to my cost)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86137

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

[PATCH] D87927: [AIX][clang][driver] Make sure ctri.o is linked in C++ mode

2020-09-18 Thread David Tenty via Phabricator via cfe-commits

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

since crti is required for functional static initialization.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87927

Files:
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/test/Driver/aix-ld.c

Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -199,6 +199,7 @@
 // CHECK-LD32-CXX-ARG-ORDER: "-b32"
 // CHECK-LD32-CXX-ARG-ORDER: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-CXX-ARG-ORDER: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-CXX-ARG-ORDER: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-CXX-ARG-ORDER: "-bcdtors:all:0:s"
 // CHECK-LD32-CXX-ARG-ORDER: "-bnocdtors"
 // CHECK-LD32-CXX-ARG-ORDER-NOT: "-bcdtors:all:0:s"
@@ -216,6 +217,7 @@
 // CHECK-LD32-CXX-ARG-LCXX: "-b32"
 // CHECK-LD32-CXX-ARG-LCXX: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-CXX-ARG-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-CXX-ARG-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-CXX-ARG-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD32-CXX-ARG-LCXX: "-lc++"
 // CHECK-LD32-CXX-ARG-LCXX: "-lc"
@@ -231,6 +233,7 @@
 // CHECK-LD64-CXX-ARG-LCXX: "-b64"
 // CHECK-LD64-CXX-ARG-LCXX: "-bpT:0x1" "-bpD:0x11000"
 // CHECK-LD64-CXX-ARG-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+// CHECK-LD64-CXX-ARG-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti_64.o"
 // CHECK-LD64-CXX-ARG-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD64-CXX-ARG-LCXX: "-lc++"
 // CHECK-LD64-CXX-ARG-LCXX: "-lc"
@@ -247,6 +250,7 @@
 // CHECK-LD32-NODEFLIB-LCXX: "-b32"
 // CHECK-LD32-NODEFLIB-LCXX: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-NODEFLIB-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-NODEFLIB-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-NODEFLIB-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD32-NODEFLIB-LCXX-NOT: "-lc++"
 // CHECK-LD32-NODEFLIB-LCXX-NOT: "-lc"
@@ -263,6 +267,7 @@
 // CHECK-LD64-NODEFLIB-LCXX: "-b64"
 // CHECK-LD64-NODEFLIB-LCXX: "-bpT:0x1" "-bpD:0x11000"
 // CHECK-LD64-NODEFLIB-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+// CHECK-LD64-NODEFLIB-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti_64.o"
 // CHECK-LD64-NODEFLIB-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD64-NODEFLIB-LCXX-NOT: "-lc++"
 // CHECK-LD64-NODEFLIB-LCXX-NOT: "-lc"
@@ -279,6 +284,7 @@
 // CHECK-LD32-NOSTDLIB-LCXX: "-b32"
 // CHECK-LD32-NOSTDLIB-LCXX: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-NOSTDLIB-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-NOSTDLIB-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-NOSTDLIB-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD32-NOSTDLIB-LCXX-NOT: "-lc++"
 // CHECK-LD32-NOSTDLIB-LCXX-NOT: "-lc"
@@ -295,6 +301,7 @@
 // CHECK-LD64-NOSTDLIB-LCXX: "-b64"
 // CHECK-LD64-NOSTDLIB-LCXX: "-bpT:0x1" "-bpD:0x11000"
 // CHECK-LD64-NOSTDLIB-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+// CHECK-LD64-NOSTDLIB-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crti_64.o"
 // CHECK-LD64-NOSTDLIB-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD64-NOSTDLIB-LCXX-NOT: "-lc++"
 // CHECK-LD64-NOSTDLIB-LCXX-NOT: "-lc"
@@ -311,6 +318,7 @@
 // CHECK-LD32-NOSTDLIBXX-LCXX: "-b32"
 // CHECK-LD32-NOSTDLIBXX-LCXX: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-NOSTDLIBXX-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-NOSTDLIBXX-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-NOSTDLIBXX-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD32-NOSTDLIBXX-LCXX-NOT: "-lc++"
 // CHECK-LD32-NOSTDLIBXX-LCXX: "-lc"
@@ -327,6 +335,7 @@
 // CHECK-LD64-NOSTDLIBXX-LCXX: "-b64"
 // CHECK-LD64-NOSTDLIBXX-LCXX: "-bpT:0x1" "-bpD:0x11000"
 // CHECK-LD64-NOSTDLIBXX-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+// CHECK-LD64-NOSTDLIBXX-LCXX: "[[SYSROOT]]/usr/lib{{/|}}crti_64.o"
 // CHECK-LD64-NOSTDLIBXX-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD64-NOSTDLIBXX-LCXX-NOT: "-lc++"
 // CHECK-LD64-NOSTDLIBXX-LCXX: "-lc"
@@ -343,6 +352,7 @@
 // CHECK-LD32-NOSTARTFILES-LCXX: "-b32"
 // CHECK-LD32-NOSTARTFILES-LCXX: "-bpT:0x1000" "-bpD:0x2000"
 // CHECK-LD32-NOSTARTFILES-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-NOSTARTFILES-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crti.o"
 // CHECK-LD32-NOSTARTFILES-LCXX: "-L[[SYSROOT]]/usr/lib"
 // CHECK-LD32-NOSTARTFILES-LCXX  "-lc++"
 // CHECK-LD32-NOSTARTFILES-LCXX: "-lc"
@@ -359,6 +369,7 @@
 // CHECK-LD64-NOSTARTFILES-LCXX: "-b64"
 // CHECK-LD64-NOSTARTFILES-LCXX: "-bpT:0x1" "-bpD:0x11000"
 // CHECK-LD64-NOSTARTFILES-LCXX-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+//

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

2020-09-18 Thread Nikita Popov via Phabricator via cfe-commits

nikic added a comment.

In D87188#2281093 , @mstorsjo wrote:

> This broke a few tests for me (generating code that now gives the fail result 
> at runtime).
>
> I'm not entirely sure which bit is the culprit, but the difference in output 
> (that breaks tests) for one object file is available at 
> https://martin.st/temp/vc1_block-diff-aarch64.txt, and 
> https://martin.st/temp/vc1_block-diff-armv7.txt. For the aarch64 version, it 
> looks like some conditionals are inverted, like these changes:
>
>   -   b.ge.LBB1_124
>   +   b.hs.LBB1_124
>
> and
>
>   -   cselw14, w15, w14, gt
>   +   cselw14, w15, w14, hi
>
> (with no seemingly related changes that would change the roles of the 
> registers).
>
> The input files for reproducing the issues are available at 
> https://martin.st/temp/vc1_block-aarch64.c and 
> https://martin.st/temp/vc1_block-armv7.c, which can be compiled with `clang 
> -target {aarch64,armv7}-w64-mingw32 -c -O2 vc1_block-{aarch64,armv7}.c`.

Based on an initial look, the changes in comparison predicates here are 
probably a red herring. If I understand right, those predicates are switching 
from signed to unsigned comparison (e.g. gt to hi). I also see similar changes 
in IR. However, all the cases I looked at are actually correct (e.g. abs(x) > 
abs(y) can be compared signed or unsigned for poisoning abs). Assuming that 
this code is clean under ubsan, the problem is likely something else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[PATCH] D87925: [Synthesis] Fix: `createTree` only from children that are not backed by source code

2020-09-18 Thread Eduardo Caldas via Phabricator via cfe-commits

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87925

Files:
  clang/include/clang/Tooling/Syntax/BuildTree.h
  clang/lib/Tooling/Syntax/Synthesis.cpp


Index: clang/lib/Tooling/Syntax/Synthesis.cpp
===
--- clang/lib/Tooling/Syntax/Synthesis.cpp
+++ clang/lib/Tooling/Syntax/Synthesis.cpp
@@ -8,6 +8,7 @@
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Tooling/Syntax/BuildTree.h"
 #include "clang/Tooling/Syntax/Tree.h"
+#include 
 
 using namespace clang;
 
@@ -184,12 +185,48 @@
   }
   llvm_unreachable("unknown node kind");
 }
+
+bool canModifyAllDescendants(const syntax::Node *N) {
+  if (const auto *L = dyn_cast(N))
+return L->canModify();
+
+  const auto *T = cast(N);
+
+  if (!T->canModify())
+return false;
+  for (const auto *Child = T->getFirstChild(); Child;
+   Child = Child->getNextSibling())
+if (!Child->canModify())
+  return false;
+
+  return true;
+}
+
+bool areAllSynthesized(const syntax::Node *N) {
+  if (const auto *L = dyn_cast(N))
+return !L->isOriginal();
+
+  const auto *T = cast(N);
+
+  if (T->isOriginal())
+return false;
+  for (const auto *Child = T->getFirstChild(); Child;
+   Child = Child->getNextSibling())
+if (Child->isOriginal())
+  return false;
+
+  return true;
+}
 } // namespace
 
 syntax::Tree *clang::syntax::createTree(
 syntax::Arena ,
 std::vector> Children,
 syntax::NodeKind K) {
+  if (std::all_of(Children.begin(), Children.end(),
+  [](auto p) { return areAllSynthesized(p.first); }))
+return nullptr;
+
   auto *T = allocateTree(A, K);
   FactoryImpl::setCanModify(T);
   for (auto ChildIt = Children.rbegin(); ChildIt != Children.rend();
Index: clang/include/clang/Tooling/Syntax/BuildTree.h
===
--- clang/include/clang/Tooling/Syntax/BuildTree.h
+++ clang/include/clang/Tooling/Syntax/BuildTree.h
@@ -37,6 +37,9 @@
 // Synthesis of Trees
 /// Creates the concrete syntax node according to the specified `NodeKind` `K`.
 /// Returns it as a pointer to the base class `Tree`.
+///
+/// EXPECT: Nodes in `Children` are all synthesized, i.e. not backed by source
+/// code.
 syntax::Tree *
 createTree(syntax::Arena ,
std::vector> Children,


Index: clang/lib/Tooling/Syntax/Synthesis.cpp
===
--- clang/lib/Tooling/Syntax/Synthesis.cpp
+++ clang/lib/Tooling/Syntax/Synthesis.cpp
@@ -8,6 +8,7 @@
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Tooling/Syntax/BuildTree.h"
 #include "clang/Tooling/Syntax/Tree.h"
+#include 
 
 using namespace clang;
 
@@ -184,12 +185,48 @@
   }
   llvm_unreachable("unknown node kind");
 }
+
+bool canModifyAllDescendants(const syntax::Node *N) {
+  if (const auto *L = dyn_cast(N))
+return L->canModify();
+
+  const auto *T = cast(N);
+
+  if (!T->canModify())
+return false;
+  for (const auto *Child = T->getFirstChild(); Child;
+   Child = Child->getNextSibling())
+if (!Child->canModify())
+  return false;
+
+  return true;
+}
+
+bool areAllSynthesized(const syntax::Node *N) {
+  if (const auto *L = dyn_cast(N))
+return !L->isOriginal();
+
+  const auto *T = cast(N);
+
+  if (T->isOriginal())
+return false;
+  for (const auto *Child = T->getFirstChild(); Child;
+   Child = Child->getNextSibling())
+if (Child->isOriginal())
+  return false;
+
+  return true;
+}
 } // namespace
 
 syntax::Tree *clang::syntax::createTree(
 syntax::Arena ,
 std::vector> Children,
 syntax::NodeKind K) {
+  if (std::all_of(Children.begin(), Children.end(),
+  [](auto p) { return areAllSynthesized(p.first); }))
+return nullptr;
+
   auto *T = allocateTree(A, K);
   FactoryImpl::setCanModify(T);
   for (auto ChildIt = Children.rbegin(); ChildIt != Children.rend();
Index: clang/include/clang/Tooling/Syntax/BuildTree.h
===
--- clang/include/clang/Tooling/Syntax/BuildTree.h
+++ clang/include/clang/Tooling/Syntax/BuildTree.h
@@ -37,6 +37,9 @@
 // Synthesis of Trees
 /// Creates the concrete syntax node according to the specified `NodeKind` `K`.
 /// Returns it as a pointer to the base class `Tree`.
+///
+/// EXPECT: Nodes in `Children` are all synthesized, i.e. not backed by source
+/// code.
 syntax::Tree *
 createTree(syntax::Arena ,
std::vector> Children,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D84364: [CUDA][HIP] Defer overloading resolution diagnostics for host device functions

2020-09-18 Thread Mitch Phillips via Phabricator via cfe-commits

hctim added a comment.

Not a known issue - no, but MSan doesn't play nice with uninistrumented 
libraries (including things like libcxx) - and so it can be tricky to ensure 
your build is properly sanitized, which is why I'd recommend the build script 
:).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84364

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

[PATCH] D87923: [MS] On x86_32, pass overaligned, non-copyable arguments indirectly

2020-09-18 Thread Reid Kleckner via Phabricator via cfe-commits

rnk created this revision.
rnk added reviewers: aeubanks, craig.topper.
Herald added a project: clang.
rnk requested review of this revision.

This updates the C++ ABI argument classification code to use the logic
from D72114 , fixing an ABI incompatibility 
with MSVC.

Part of PR44395.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87923

Files:
  clang/lib/CodeGen/MicrosoftCXXABI.cpp
  clang/test/CodeGenCXX/inalloca-overaligned.cpp


Index: clang/test/CodeGenCXX/inalloca-overaligned.cpp
===
--- clang/test/CodeGenCXX/inalloca-overaligned.cpp
+++ clang/test/CodeGenCXX/inalloca-overaligned.cpp
@@ -4,11 +4,6 @@
 // MSVC passes overaligned types indirectly since MSVC 2015. Make sure that
 // works with inalloca.
 
-// FIXME: Pass non-trivial *and* overaligned types indirectly. Right now the 
C++
-// ABI rules say to use inalloca, and they take precedence, so it's not easy to
-// implement this.
-
-
 struct NonTrivial {
   NonTrivial();
   NonTrivial(const NonTrivial );
@@ -20,6 +15,12 @@
   int buf[16];
 };
 
+struct __declspec(align(8)) Both {
+  Both();
+  Both(const Both );
+  int x, y;
+};
+
 extern int gvi32;
 
 int receive_inalloca_overaligned(NonTrivial nt, OverAligned o) {
@@ -50,3 +51,37 @@
 // CHECK: getelementptr inbounds <{ %struct.NonTrivial, %struct.OverAligned* 
}>, <{ %struct.NonTrivial, %struct.OverAligned* }>* %{{.*}}, i32 0, i32 1
 // CHECK: store %struct.OverAligned* [[TMP]], %struct.OverAligned** %{{.*}}, 
align 4
 // CHECK: call i32 @"?receive_inalloca_overaligned@@Y{{.*}}"(<{ 
%struct.NonTrivial, %struct.OverAligned* }>* inalloca %argmem)
+
+int receive_both(Both o) {
+  return o.x + o.y;
+}
+
+// CHECK-LABEL: define dso_local i32 @"?receive_both@@Y{{.*}}"
+// CHECK-SAME: (%struct.Both* %o)
+
+int pass_both() {
+  gvi32 = receive_both(Both());
+  return gvi32;
+}
+
+// CHECK-LABEL: define dso_local i32 @"?pass_both@@Y{{.*}}"
+// CHECK: [[TMP:%[^ ]*]] = alloca %struct.Both, align 8
+// CHECK: call x86_thiscallcc %struct.Both* @"??0Both@@QAE@XZ"(%struct.Both* 
[[TMP]])
+// CHECK: call i32 @"?receive_both@@Y{{.*}}"(%struct.Both* [[TMP]])
+
+int receive_inalloca_both(NonTrivial nt, Both o) {
+  return nt.x + o.x + o.y;
+}
+
+// CHECK-LABEL: define dso_local i32 @"?receive_inalloca_both@@Y{{.*}}"
+// CHECK-SAME: (<{ %struct.NonTrivial, %struct.Both* }>* inalloca %0)
+
+int pass_inalloca_both() {
+  gvi32 = receive_inalloca_both(NonTrivial(), Both());
+  return gvi32;
+}
+
+// CHECK-LABEL: define dso_local i32 @"?pass_inalloca_both@@Y{{.*}}"
+// CHECK: [[TMP:%[^ ]*]] = alloca %struct.Both, align 8
+// CHECK: call x86_thiscallcc %struct.Both* @"??0Both@@QAE@XZ"(%struct.Both* 
[[TMP]])
+// CHECK: call i32 @"?receive_inalloca_both@@Y{{.*}}"(<{ %struct.NonTrivial, 
%struct.Both* }>* inalloca %argmem)
Index: clang/lib/CodeGen/MicrosoftCXXABI.cpp
===
--- clang/lib/CodeGen/MicrosoftCXXABI.cpp
+++ clang/lib/CodeGen/MicrosoftCXXABI.cpp
@@ -827,10 +827,14 @@
 // copy ctor.
 return !RD->canPassInRegisters() ? RAA_Indirect : RAA_Default;
 
-  case llvm::Triple::x86:
-// All record arguments are passed in memory on x86.  Decide whether to
-// construct the object directly in argument memory, or to construct the
-// argument elsewhere and copy the bytes during the call.
+  case llvm::Triple::x86: {
+// If the argument has *required* alignment greater than four bytes, pass
+// it indirectly. Prior to MSVC version 19.14, passing overaligned
+// arguments was not supported and resulted in a compiler error. In 19.14
+// and later versions, such arguments are now passed indirectly.
+TypeInfo Info = getContext().getTypeInfo(RD->getTypeForDecl());
+if (Info.AlignIsRequired && Info.Align > 4)
+  return RAA_Indirect;
 
 // If C++ prohibits us from making a copy, construct the arguments directly
 // into argument memory.
@@ -840,6 +844,7 @@
 // Otherwise, construct the argument into a temporary and copy the bytes
 // into the outgoing argument memory.
 return RAA_Default;
+  }
 
   case llvm::Triple::x86_64:
   case llvm::Triple::aarch64:


Index: clang/test/CodeGenCXX/inalloca-overaligned.cpp
===
--- clang/test/CodeGenCXX/inalloca-overaligned.cpp
+++ clang/test/CodeGenCXX/inalloca-overaligned.cpp
@@ -4,11 +4,6 @@
 // MSVC passes overaligned types indirectly since MSVC 2015. Make sure that
 // works with inalloca.
 
-// FIXME: Pass non-trivial *and* overaligned types indirectly. Right now the C++
-// ABI rules say to use inalloca, and they take precedence, so it's not easy to
-// implement this.
-
-
 struct NonTrivial {
   NonTrivial();
   NonTrivial(const NonTrivial );
@@ -20,6 +15,12 @@
   int buf[16];
 };
 
+struct __declspec(align(8)) Both {
+  Both();
+  Both(const Both );
+  int x, y;
+};
+
 extern int

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread John McCall via Phabricator via cfe-commits

rjmccall added a comment.

Oh, I didn't notice that this only did work conditionally based on the builtin 
ID.  Yes, please make a function like `lookupNecessaryTypesForBuiltin` that 
takes the builtin ID.  Maybe we can generalize this to solve the problem with 
that other builtin, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

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

[PATCH] D87822: [FPEnv] Evaluate constant expressions under non-default rounding modes

2020-09-18 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:2462
+  return true;
+}
+

Thanks, these look good.



Comment at: clang/lib/AST/ExprConstant.cpp:2427
+FPOptions FPFeatures = Cast->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
+RM = FPFeatures.getRoundingMode();
+  }

sepavloff wrote:
> rjmccall wrote:
> > I think the options really need to be passed in or else correctness is 
> > somewhat doomed here.
> > 
> > For example, the call to CompoundAssignSubobjectHandler needs to propagate 
> > this down from the operator expression.
> It is guaranteed by the way AST is built, no?
> 
> As FP options may be changed only by pragmas and the pragmas can be specified 
> only at file or block level, all sub-expression are evaluated at the same 
> options.
Yes, but you can't actually reliably recover those settings from E unless 
you're sure E is one of a few kinds of expression.  The concern is that E might 
end up being some closely-related expression that isn't actually the expression 
that carries the current settings, and then we'll fall back on using the global 
defaults.  It's much more correct-by-construction to pass the settings down 
from the caller based on the caller's static knowledge of which expression is 
under consideration, and I think you'll see that that's pretty straightforward 
in practice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87822

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

[PATCH] D84988: [Coverage] Add empty line regions to SkippedRegions

2020-09-18 Thread Zequan Wu via Phabricator via cfe-commits

zequanwu added a comment.

Friendly ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84988

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

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

tambre added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9674
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);

rjmccall wrote:
> Can we avoid doing this except for the small number of builtins that use 
> `struct objc_super`?  We already have the BuiltinID.
`LookupPredefedObjCSuperType()` already checks if the identifier is 
`"objc_msgSendSuper"`. But it'd probably be more efficient to check the 
`BuiltinID`. I'll follow this up tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

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

[PATCH] D84364: [CUDA][HIP] Defer overloading resolution diagnostics for host device functions

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D84364#2279684 , @hctim wrote:

> Looks like this patch broke the MSan buildbots, PTAL (repro instructions 
> https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild):
>
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/46239/steps/check-clang%20msan/logs/stdio
>
>   FAIL: Clang :: SemaCUDA/deferred-oeverload.cu (11308 of 26387)
>    TEST 'Clang :: SemaCUDA/deferred-oeverload.cu' FAILED 
> 
>   Script:
>   --
>   : 'RUN: at line 1';   
> /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 
> -internal-isystem 
> /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include 
> -nostdsysteminc -fcuda-is-device -fsyntax-only -verify=dev,com 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu
> -std=c++11 -fgpu-defer-diag
>   : 'RUN: at line 3';   
> /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/bin/clang -cc1 
> -internal-isystem 
> /b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/lib/clang/12.0.0/include 
> -nostdsysteminc -fsyntax-only -verify=host,com 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/test/SemaCUDA/deferred-oeverload.cu
> -std=c++11 -fgpu-defer-diag
>   --
>   Exit Code: 77
>   
>   Command Output (stderr):
>   --
>   ==41680==WARNING: MemorySanitizer: use-of-uninitialized-value
>   #0 0xddfbf73 in 
> clang::OverloadCandidateSet::CompleteCandidates(clang::Sema&, 
> clang::OverloadCandidateDisplayKind, llvm::ArrayRef, 
> clang::SourceLocation, llvm::function_ref) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11484:9
>   #1 0xde4e7ca in 
> clang::OverloadCandidateSet::NoteCandidates(std::__1::pair  clang::PartialDiagnostic>, clang::Sema&, 
> clang::OverloadCandidateDisplayKind, llvm::ArrayRef, 
> llvm::StringRef, clang::SourceLocation, llvm::function_ref (clang::OverloadCandidate&)>) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:11529:9
>   #2 0xde6316f in FinishOverloadedCallExpr(clang::Sema&, clang::Scope*, 
> clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, 
> llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, 
> clang::OverloadCandidateSet*, clang::OverloadCandidate**, 
> clang::OverloadingResult, bool) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:12959:19
>   #3 0xde6296b in clang::Sema::BuildOverloadedCallExpr(clang::Scope*, 
> clang::Expr*, clang::UnresolvedLookupExpr*, clang::SourceLocation, 
> llvm::MutableArrayRef, clang::SourceLocation, clang::Expr*, 
> bool, bool) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaOverload.cpp:13032:10
>   #4 0xd4e126b in clang::Sema::BuildCallExpr(clang::Scope*, clang::Expr*, 
> clang::SourceLocation, llvm::MutableArrayRef, 
> clang::SourceLocation, clang::Expr*, bool) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6378:16
>   #5 0xd53e073 in clang::Sema::ActOnCallExpr(clang::Scope*, clang::Expr*, 
> clang::SourceLocation, llvm::MutableArrayRef, 
> clang::SourceLocation, clang::Expr*) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Sema/SemaExpr.cpp:6275:7
>   #6 0xcaa957f in 
> clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult true>) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:2066:23
>   #7 0xcaaf03e in 
> clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&, 
> clang::Parser::TypeCastState, bool, bool*) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:1811:9
>   #8 0xcaa5f3e in 
> clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, 
> clang::Parser::TypeCastState, bool, bool*) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:681:20
>   #9 0xcaa15f3 in 
> clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:173:20
>   #10 0xcaa13ad in 
> clang::Parser::ParseExpression(clang::Parser::TypeCastState) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseExpr.cpp:124:18
>   #11 0xcbc8288 in 
> clang::Parser::ParseExprStatement(clang::Parser::ParsedStmtContext) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:446:19
>   #12 0xcbc2183 in 
> clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector  32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, 
> clang::Parser::ParsedAttributesWithRange&) 
> /b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:234:12
>   #13 0xcbc119d in 
> clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector 32u>&,

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread dmajor via Phabricator via cfe-commits

dmajor added a comment.

Thanks, this fixes the specific translation unit I was looking at today. It's 
going to take some time before I have full build results but I don't expect any 
problems.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

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

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread John McCall via Phabricator via cfe-commits

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9674
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);

Can we avoid doing this except for the small number of builtins that use 
`struct objc_super`?  We already have the BuiltinID.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

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

[PATCH] D87822: [FPEnv] Evaluate constant expressions under non-default rounding modes

2020-09-18 Thread Serge Pavlov via Phabricator via cfe-commits

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



Comment at: clang/lib/AST/ExprConstant.cpp:2427
+FPOptions FPFeatures = Cast->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
+RM = FPFeatures.getRoundingMode();
+  }

rjmccall wrote:
> I think the options really need to be passed in or else correctness is 
> somewhat doomed here.
> 
> For example, the call to CompoundAssignSubobjectHandler needs to propagate 
> this down from the operator expression.
It is guaranteed by the way AST is built, no?

As FP options may be changed only by pragmas and the pragmas can be specified 
only at file or block level, all sub-expression are evaluated at the same 
options.



Comment at: clang/lib/AST/ExprConstant.cpp:2678
+// operation. If the result is exact, it does not depend on rounding mode.
+RM = llvm::RoundingMode::NearestTiesToEven;
+  APFloat::opStatus St;

rjmccall wrote:
> Feels like you should have a helper function like 
> `getActiveRoundingMode(Info, FPFeatures)`
It required implementation of statically polymorphic method 
`Expr::getFPFeaturesInEffect` but finally code looks better.



Comment at: clang/lib/AST/ExprConstant.cpp:2712
+  //   initializer,
+  // the evaluation probably need to be rejected.
+

rjmccall wrote:
> Is this processing something you can extract meaningfully into a common 
> function that works with an opStatus, so that you can just write `if 
> (!checkFloatingPointFailure(Info, E, status, fpFeatures)) return false;` in 
> all these places?
Good idea, thank you. I used a bit different name to have positive semantics.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87822

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

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa1aa330b202f: [Sema] Handle objc_super special lookup when 
checking builtin compatibility (authored by tambre).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaObjCXX/builtin-objcsuper.mm


Index: clang/test/SemaObjCXX/builtin-objcsuper.mm
===
--- /dev/null
+++ clang/test/SemaObjCXX/builtin-objcsuper.mm
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+// expected-no-diagnostics
+
+// objc_super has special lookup rules for compatibility with macOS headers, so
+// the following should compile.
+struct objc_super {};
+extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
+extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, ...);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9671,6 +9671,7 @@
 NewFD->addAttr(BuiltinAttr::CreateImplicit(Context, BuiltinID));
   } else {
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);
 
 if (!Error && !BuiltinType.isNull() &&


Index: clang/test/SemaObjCXX/builtin-objcsuper.mm
===
--- /dev/null
+++ clang/test/SemaObjCXX/builtin-objcsuper.mm
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+// expected-no-diagnostics
+
+// objc_super has special lookup rules for compatibility with macOS headers, so
+// the following should compile.
+struct objc_super {};
+extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
+extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, ...);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9671,6 +9671,7 @@
 NewFD->addAttr(BuiltinAttr::CreateImplicit(Context, BuiltinID));
   } else {
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);
 
 if (!Error && !BuiltinType.isNull() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a1aa330 - [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread Raul Tambre via cfe-commits


Author: Raul Tambre
Date: 2020-09-18T20:51:55+03:00
New Revision: a1aa330b202f97ecd243ea9ef0c7ac00a80ea653

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

LOG: [Sema] Handle objc_super special lookup when checking builtin compatibility

objc_super is special and needs LookupPredefedObjCSuperType() called before 
performing builtin type comparisons.
This fixes an error when compiling macOS headers. A test is added.

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

Added: 
clang/test/SemaObjCXX/builtin-objcsuper.mm

Modified: 
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 20fb5a4d27e7..81d377cebb32 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -9671,6 +9671,7 @@ Sema::ActOnFunctionDeclarator(Scope *S, Declarator , 
DeclContext *DC,
 NewFD->addAttr(BuiltinAttr::CreateImplicit(Context, BuiltinID));
   } else {
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);
 
 if (!Error && !BuiltinType.isNull() &&

diff  --git a/clang/test/SemaObjCXX/builtin-objcsuper.mm 
b/clang/test/SemaObjCXX/builtin-objcsuper.mm
new file mode 100644
index ..a6baf3c5165a
--- /dev/null
+++ b/clang/test/SemaObjCXX/builtin-objcsuper.mm
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+// expected-no-diagnostics
+
+// objc_super has special lookup rules for compatibility with macOS headers, so
+// the following should compile.
+struct objc_super {};
+extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
+extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, ...);



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

[PATCH] D87822: [FPEnv] Evaluate constant expressions under non-default rounding modes

2020-09-18 Thread Serge Pavlov via Phabricator via cfe-commits

sepavloff updated this revision to Diff 292841.
sepavloff added a comment.

Updated patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87822

Files:
  clang/include/clang/AST/Expr.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/AST/const-fpfeatures-diag.c
  clang/test/AST/const-fpfeatures.c

Index: clang/test/AST/const-fpfeatures.c
===
--- /dev/null
+++ clang/test/AST/const-fpfeatures.c
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -S -emit-llvm -Wno-unknown-pragmas %s -o - | FileCheck %s
+
+// nextUp(1.F) == 0x1.02p0F
+
+#pragma STDC FENV_ROUND FE_UPWARD
+
+float F1u = 1.0F + 0x0.02p0F;
+float F2u = 1.0F + 0x0.01p0F;
+float F3u = 0x1.01p0;
+// CHECK: @F1u = {{.*}} float 0x3FF02000
+// CHECK: @F2u = {{.*}} float 0x3FF02000
+// CHECK: @F3u = {{.*}} float 0x3FF02000
+
+#pragma STDC FENV_ROUND FE_DOWNWARD
+
+float F1d = 1.0F + 0x0.02p0F;
+float F2d = 1.0F + 0x0.01p0F;
+float F3d = 0x1.01p0;
+
+// CHECK: @F1d = {{.*}} float 0x3FF02000
+// CHECK: @F2d = {{.*}} float 1.00e+00
+// CHECK: @F3d = {{.*}} float 1.00e+00
Index: clang/test/AST/const-fpfeatures-diag.c
===
--- /dev/null
+++ clang/test/AST/const-fpfeatures-diag.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify -ffp-exception-behavior=strict -Wno-unknown-pragmas %s
+
+#pragma STDC FENV_ROUND FE_DYNAMIC
+
+// nextUp(1.F) == 0x1.02p0F
+
+float F1 = 0x1.00p0F + 0x0.02p0F;
+float F2 = 0x1.00p0F + 0x0.01p0F; // expected-error{{initializer element is not a compile-time constant}}
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -981,7 +981,9 @@
 void Sema::setRoundingMode(SourceLocation Loc, llvm::RoundingMode FPR) {
   // C2x: 7.6.2p3  If the FE_DYNAMIC mode is specified and FENV_ACCESS is "off",
   // the translator may assume that the default rounding mode is in effect.
-  if (FPR == llvm::RoundingMode::Dynamic && !CurFPFeatures.getAllowFEnvAccess())
+  if (FPR == llvm::RoundingMode::Dynamic &&
+  !CurFPFeatures.getAllowFEnvAccess() &&
+  CurFPFeatures.getFPExceptionMode() == LangOptions::FPE_Ignore)
 FPR = llvm::RoundingMode::NearestTiesToEven;
 
   FPOptionsOverride NewFPFeatures = CurFPFeatureOverrides();
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2418,14 +2418,59 @@
   return true;
 }
 
+/// Get rounding mode used for evaluation of the specified expression.
+/// \param[out] DynamicRM Is set to true is the requested rounding mode is
+///   dynamic.
+/// If rounding mode is unknown at compile time, still try to evaluate the
+/// expression. If the result is exact, it does not depend on rounding mode.
+/// So return "tonearest" mode instead of "dynamic".
+static llvm::RoundingMode getActiveRoundingMode(EvalInfo , const Expr *E,
+bool ) {
+  llvm::RoundingMode RM =
+  E->getFPFeaturesInEffect(Info.Ctx.getLangOpts()).getRoundingMode();
+  DynamicRM = (RM == llvm::RoundingMode::Dynamic);
+  if (DynamicRM)
+RM = llvm::RoundingMode::NearestTiesToEven;
+  return RM;
+}
+
+/// Check if the given evaluation result is allowed for constant evaluation.
+static bool checkFloatingPointResult(EvalInfo , const Expr *E,
+ APFloat::opStatus St) {
+  FPOptions FPO = E->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
+  if ((St & APFloat::opInexact) &&
+  FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {
+// Inexact result means that it depends on rounding mode. If the requested
+// mode is dynamic, the evaluation cannot be made in compile time.
+Info.FFDiag(E);
+return false;
+  }
+
+  if (St & APFloat::opStatus::opInvalidOp) {
+// There is no usefully definable result.
+Info.FFDiag(E);
+return false;
+  }
+
+  // FIXME: if:
+  // - evaluation triggered other FP exception, and
+  // - exception mode is not "ignore", and
+  // - the expression being evaluated is not a part of global variable
+  //   initializer,
+  // the evaluation probably need to be rejected.
+  return true;
+}
+
 static bool HandleFloatToFloatCast(EvalInfo , const Expr *E,
QualType SrcType, QualType DestType,
APFloat ) {
+  bool DynamicRM;
+  llvm::RoundingMode RM = getActiveRoundingMode(Info, E, DynamicRM);
+  APFloat::opStatus St;
   APFloat Value = Result;
   bool ignored;
-  Result.convert(Info.Ctx.getFloatTypeSemantics(DestType),
- APFloat::rmNearestTiesToEven, );

[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-18 Thread UTKARSH SAXENA 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 rG9b6765e784b3: [clangd] Add Random Forest runtime for code 
completion. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83814

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/quality/CompletionModel.cmake
  clang-tools-extra/clangd/quality/CompletionModelCodegen.py
  clang-tools-extra/clangd/quality/README.md
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
  clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
  clang-tools-extra/clangd/unittests/decision_forest_model/features.json
  clang-tools-extra/clangd/unittests/decision_forest_model/forest.json

Index: clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
@@ -0,0 +1,52 @@
+[
+{
+"operation": "if_greater",
+"feature": "ANumber",
+"threshold": 200.0,
+"then": {
+"operation": "if_greater",
+"feature": "AFloat",
+"threshold": -1,
+"then": {
+"operation": "boost",
+"score": 10.0
+},
+"else": {
+"operation": "boost",
+"score": -20.0
+}
+},
+"else": {
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"C"
+],
+"then": {
+"operation": "boost",
+"score": 3.0
+},
+"else": {
+"operation": "boost",
+"score": -4.0
+}
+}
+},
+{
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"B"
+],
+"then": {
+"operation": "boost",
+"score": 5.0
+},
+"else": {
+"operation": "boost",
+"score": -6.0
+}
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/features.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/features.json
@@ -0,0 +1,16 @@
+[
+{
+"name": "ANumber",
+"kind": "NUMBER"
+},
+{
+"name": "AFloat",
+"kind": "NUMBER"
+},
+{
+"name": "ACategorical",
+"kind": "ENUM",
+"type": "ns1::ns2::TestEnum",
+"header": "decision_forest_model/CategoricalFeature.h"
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
@@ -0,0 +1,5 @@
+namespace ns1 {
+namespace ns2 {
+enum TestEnum { A, B, C, D };
+} // namespace ns2
+} // namespace ns1
Index: clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
@@ -0,0 +1,29 @@
+#include "DecisionForestRuntimeTest.h"
+#include "decision_forest_model/CategoricalFeature.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+
+TEST(DecisionForestRuntime, Evaluate) {
+  using Example = ::ns1::ns2::test::Example;
+  using Cat = ::ns1::ns2::TestEnum;
+  using ::ns1::ns2::test::Evaluate;
+
+  Example E;
+  E.setANumber(200); // True
+  E.setAFloat(0);// True: +10.0
+  E.setACategorical(Cat::A); // True: +5.0
+  EXPECT_EQ(Evaluate(E), 15.0);
+
+  E.setANumber(200); // True
+  E.setAFloat(-2.5); // False: -20.0
+  E.setACategorical(Cat::B); // True: +5.0
+  EXPECT_EQ(Evaluate(E), -15.0);
+
+  E.setANumber(100); // False
+  E.setACategorical(Cat::C); // True: +3.0, False: -6.0
+  EXPECT_EQ(Evaluate(E), -3.0);
+}
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -10,6 +10,7 @@
 #include "ClangdServer.h"
 #include "CodeComplete.h"
 #include "Compiler.h"
+#include

[clang-tools-extra] 9b6765e - [clangd] Add Random Forest runtime for code completion.

2020-09-18 Thread Utkarsh Saxena via cfe-commits


Author: Utkarsh Saxena
Date: 2020-09-18T19:25:56+02:00
New Revision: 9b6765e784b39c88cb8cdb85ab083e6c95a997ed

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

LOG: [clangd] Add Random Forest runtime for code completion.

Summary:
[WIP]
- Proposes a json format for representing Random Forest model.
- Proposes a way to test the generated runtime using a test model.

TODO:
- Add generated source code snippet for easier review.
- Fix unused label warning.
- Figure out required using declarations for CATEGORICAL columns from 
Features.json.
- Necessary Google3 internal modifications for blaze before landing.
- Add documentation for format of the model.
- Document more.

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, 
cfe-commits

Tags: #clang

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

Added: 
clang-tools-extra/clangd/quality/CompletionModel.cmake
clang-tools-extra/clangd/quality/CompletionModelCodegen.py
clang-tools-extra/clangd/quality/README.md
clang-tools-extra/clangd/quality/model/features.json
clang-tools-extra/clangd/quality/model/forest.json
clang-tools-extra/clangd/unittests/DecisionForestTests.cpp

clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
clang-tools-extra/clangd/unittests/decision_forest_model/features.json
clang-tools-extra/clangd/unittests/decision_forest_model/forest.json

Modified: 
clang-tools-extra/clangd/CMakeLists.txt
clang-tools-extra/clangd/unittests/CMakeLists.txt
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 3a1a034ed17b..9d2ab5be222a 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -28,6 +28,9 @@ set(LLVM_LINK_COMPONENTS
   FrontendOpenMP
   Option
   )
+  
+include(${CMAKE_CURRENT_SOURCE_DIR}/quality/CompletionModel.cmake)
+gen_decision_forest(${CMAKE_CURRENT_SOURCE_DIR}/quality/model CompletionModel 
clang::clangd::Example)
 
 if(MSVC AND NOT CLANG_CL)
  set_source_files_properties(CompileCommands.cpp PROPERTIES COMPILE_FLAGS 
-wd4130) # disables C4130: logical operation on address of string constant
@@ -77,6 +80,7 @@ add_clang_library(clangDaemon
   TUScheduler.cpp
   URI.cpp
   XRefs.cpp
+  ${CMAKE_CURRENT_BINARY_DIR}/CompletionModel.cpp
 
   index/Background.cpp
   index/BackgroundIndexLoader.cpp
@@ -117,6 +121,11 @@ add_clang_library(clangDaemon
   omp_gen
   )
 
+# Include generated CompletionModel headers.
+target_include_directories(clangDaemon PUBLIC
+  $
+)
+
 clang_target_link_libraries(clangDaemon
   PRIVATE
   clangAST

diff  --git a/clang-tools-extra/clangd/quality/CompletionModel.cmake 
b/clang-tools-extra/clangd/quality/CompletionModel.cmake
new file mode 100644
index ..60c6d2aa8433
--- /dev/null
+++ b/clang-tools-extra/clangd/quality/CompletionModel.cmake
@@ -0,0 +1,37 @@
+# Run the Completion Model Codegenerator on the model present in the 
+# ${model} directory.
+# Produces a pair of files called ${filename}.h and  ${filename}.cpp in the 
+# ${CMAKE_CURRENT_BINARY_DIR}. The generated header
+# will define a C++ class called ${cpp_class} - which may be a
+# namespace-qualified class name.
+function(gen_decision_forest model filename cpp_class)
+  set(model_compiler 
${CMAKE_SOURCE_DIR}/../clang-tools-extra/clangd/quality/CompletionModelCodegen.py)
+  
+  set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
+  set(header_file ${output_dir}/${filename}.h)
+  set(cpp_file ${output_dir}/${filename}.cpp)
+
+  add_custom_command(OUTPUT ${header_file} ${cpp_file}
+COMMAND "${Python3_EXECUTABLE}" ${model_compiler}
+  --model ${model}
+  --output_dir ${output_dir}
+  --filename ${filename}
+  --cpp_class ${cpp_class}
+COMMENT "Generating code completion model runtime..."
+DEPENDS ${model_compiler} ${model}/forest.json ${model}/features.json
+VERBATIM )
+
+  set_source_files_properties(${header_file} PROPERTIES
+GENERATED 1)
+  set_source_files_properties(${cpp_file} PROPERTIES
+GENERATED 1)
+
+  # Disable unused label warning for generated files.
+  if (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+set_source_files_properties(${cpp_file} PROPERTIES
+  COMPILE_FLAGS /wd4102)
+  else()
+set_source_files_properties(${cpp_file} PROPERTIES
+  COMPILE_FLAGS -Wno-unused)
+  endif()
+endfunction()

diff  --git a/clang-tools-extra/clangd/quality/CompletionModelCodegen.py 
b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
new file mode 100644
index ..8f8234f6ebbc
--- /dev/null
+++ b/clang-tools-extra/clangd/quality/CompletionModelCodegen.py
@@ -0,0 +1,283 @@
+"""Code generator for Code

[clang] a16e4a6 - [clang-format] NFC ensure the clang-format tests remain clang-formatted

2020-09-18 Thread via cfe-commits


Author: mydeveloperday
Date: 2020-09-18T18:16:02+01:00
New Revision: a16e4a63ae7c1933291577723324e412e087dc8e

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

LOG: [clang-format] NFC ensure the clang-format tests remain clang-formatted

Added: 


Modified: 
clang/unittests/Format/FormatTestCSharp.cpp

Removed: 




diff  --git a/clang/unittests/Format/FormatTestCSharp.cpp 
b/clang/unittests/Format/FormatTestCSharp.cpp
index ae4cdda1c845..b5c6f0522d6a 100644
--- a/clang/unittests/Format/FormatTestCSharp.cpp
+++ b/clang/unittests/Format/FormatTestCSharp.cpp
@@ -721,7 +721,7 @@ class TimePeriod {
   }
 })",
Style);
- 
+
   // Microsoft style trivial property accessors have no line break before the
   // opening brace.
   auto MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
@@ -731,7 +731,6 @@ public class SaleItem
 public decimal Price { get; set; }
 })",
MicrosoftStyle);
-
 }
 
 TEST_F(FormatTestCSharp, CSharpSpaces) {



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

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

tambre added a comment.

I'll go ahead and commit this, as it's affecting an user and the fix is simple 
and obvious. Hopefully post-commit review is acceptable per my understanding of 
the rules.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87917

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

[PATCH] D87201: [clang-format] Add a option for the position of Java static import

2020-09-18 Thread MyDeveloperDay via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2e7add812eb7: [clang-format] Add a option for the position 
of Java static import (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87201

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

Index: clang/unittests/Format/SortImportsTestJava.cpp
===
--- clang/unittests/Format/SortImportsTestJava.cpp
+++ clang/unittests/Format/SortImportsTestJava.cpp
@@ -250,6 +250,62 @@
  "import org.c;\n"));
 }
 
+TEST_F(SortImportsTestJava, SortJavaStaticImport) {
+  FmtStyle.SortJavaStaticImport = FormatStyle::SJSIO_Before;
+  EXPECT_EQ("import static com.test.a;\n"
+"\n"
+"import static org.a;\n"
+"\n"
+"import static com.a;\n"
+"\n"
+"import com.test.b;\n"
+"\n"
+"import org.b;\n"
+"\n"
+"import com.b;\n",
+sort("import static com.test.a;\n"
+ "import static org.a;\n"
+ "import static com.a;\n"
+ "import com.test.b;\n"
+ "import org.b;\n"
+ "import com.b;\n"));
+
+  FmtStyle.SortJavaStaticImport = FormatStyle::SJSIO_After;
+  EXPECT_EQ("import com.test.b;\n"
+"import com.test.c;\n"
+"\n"
+"import org.b;\n"
+"\n"
+"import com.b;\n"
+"\n"
+"import static com.test.a;\n"
+"\n"
+"import static org.a;\n"
+"\n"
+"import static com.a;\n",
+sort("import static com.test.a;\n"
+ "import static org.a;\n"
+ "import static com.a;\n"
+ "import com.test.b;\n"
+ "import org.b;\n"
+ "import com.b;\n"
+ "import com.test.c;\n"));
+}
+
+TEST_F(SortImportsTestJava, SortJavaStaticImportAsGroup) {
+  FmtStyle.SortJavaStaticImport = FormatStyle::SJSIO_After;
+
+  EXPECT_EQ("import com.test.a;\n"
+"import com.test.b;\n"
+"\n"
+"import static org.a;\n"
+"import static org.b;\n",
+sort("import com.test.a;\n"
+ "import static org.a;\n"
+ "import com.test.b;\n"
+ "import static org.b;\n"));
+}
+
 TEST_F(SortImportsTestJava, DeduplicateImports) {
   EXPECT_EQ("import org.a;\n", sort("import org.a;\n"
 "import org.a;\n"));
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -14328,6 +14328,12 @@
   CHECK_PARSE("BitFieldColonSpacing: After", BitFieldColonSpacing,
   FormatStyle::BFCS_After);
 
+  Style.SortJavaStaticImport = FormatStyle::SJSIO_Before;
+  CHECK_PARSE("SortJavaStaticImport: After", SortJavaStaticImport,
+  FormatStyle::SJSIO_After);
+  CHECK_PARSE("SortJavaStaticImport: Before", SortJavaStaticImport,
+  FormatStyle::SJSIO_Before);
+
   // FIXME: This is required because parsing a configuration simply overwrites
   // the first N elements of the list instead of resetting it.
   Style.ForEachMacros.clear();
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -377,6 +377,15 @@
   }
 };
 
+template <>
+struct ScalarEnumerationTraits {
+  static void enumeration(IO ,
+  FormatStyle::SortJavaStaticImportOptions ) {
+IO.enumCase(Value, "Before", FormatStyle::SJSIO_Before);
+IO.enumCase(Value, "After", FormatStyle::SJSIO_After);
+  }
+};
+
 template <> struct MappingTraits {
   static void mapping(IO , FormatStyle ) {
 // When reading, read the language first, we need it for getPredefinedStyle.
@@ -574,6 +583,7 @@
 IO.mapOptional("RawStringFormats", Style.RawStringFormats);
 IO.mapOptional("ReflowComments", Style.ReflowComments);
 IO.mapOptional("SortIncludes", Style.SortIncludes);
+IO.mapOptional("SortJavaStaticImport", Style.SortJavaStaticImport);
 IO.mapOptional("SortUsingDeclarations", Style.SortUsingDeclarations);
 IO.mapOptional("SpaceAfterCStyleCast", Style.SpaceAfterCStyleCast);
 IO.mapOptional("SpaceAfterLogicalNot", Style.SpaceAfterLogicalNot);
@@ -947,6 +957,7 @@
 
   LLVMStyle.DisableFormat = false;
   LLVMStyle.SortIncludes = true;
+  LLVMStyle.SortJavaStaticImport = FormatStyle::SJSIO_Before;
   LLVMStyle.SortUsingDeclarations = true;

[clang] 2e7add8 - [clang-format] Add a option for the position of Java static import

2020-09-18 Thread via cfe-commits


Author: mydeveloperday
Date: 2020-09-18T18:12:21+01:00
New Revision: 2e7add812eb7bdd90bd0f0fc3b633515edd55f27

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

LOG: [clang-format] Add a option for the position of Java static import

 Some Java style guides and IDEs group Java static imports after
 non-static imports. This patch allows clang-format to control
 the location of static imports.

Patch by: @bc-lee

Reviewed By: MyDeveloperDay, JakeMerdichAMD

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

Added: 


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

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 20e829135b33..0c3ed9f4ab84 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -1964,10 +1964,12 @@ the configuration (without a prefix: ``Auto``).
 **JavaImportGroups** (``std::vector``)
   A vector of prefixes ordered by the desired groups for Java imports.
 
-  Each group is separated by a newline. Static imports will also follow the
-  same grouping convention above all non-static imports. One group's prefix
-  can be a subset of another - the longest prefix is always matched. Within
-  a group, the imports are ordered lexicographically.
+  One group's prefix can be a subset of another - the longest prefix is
+  always matched. Within a group, the imports are ordered lexicographically.
+  Static imports are grouped separately and follow the same group rules.
+  By default, static imports are placed before non-static imports,
+  but this behavior is changed by another option,
+  ``SortJavaStaticImport``.
 
   In the .clang-format configuration file, this can be configured like
   in the following yaml example. This will result in imports being
@@ -2393,6 +2395,33 @@ the configuration (without a prefix: ``Auto``).
  #include "b.h" vs. #include "a.h"
  #include "a.h" #include "b.h"
 
+**SortJavaStaticImport** (``SortJavaStaticImportOptions``)
+  When sorting Java imports, by default static imports are placed before
+  non-static imports. If ``JavaStaticImportAfterImport`` is ``After``,
+  static imports are placed after non-static imports.
+
+  Possible values:
+
+  * ``SJSIO_Before`` (in configuration: ``Before``)
+Static imports are placed before non-static imports.
+
+.. code-block:: java
+
+  import static org.example.function1;
+
+  import org.example.ClassA;
+
+  * ``SJSIO_After`` (in configuration: ``After``)
+Static imports are placed after non-static imports.
+
+.. code-block:: java
+
+  import org.example.ClassA;
+
+  import static org.example.function1;
+
+
+
 **SortUsingDeclarations** (``bool``)
   If ``true``, clang-format will sort using declarations.
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index c6c182b7bdce..2840a6846018 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -1618,10 +1618,12 @@ struct FormatStyle {
 
   /// A vector of prefixes ordered by the desired groups for Java imports.
   ///
-  /// Each group is separated by a newline. Static imports will also follow the
-  /// same grouping convention above all non-static imports. One group's prefix
-  /// can be a subset of another - the longest prefix is always matched. Within
-  /// a group, the imports are ordered lexicographically.
+  /// One group's prefix can be a subset of another - the longest prefix is
+  /// always matched. Within a group, the imports are ordered 
lexicographically.
+  /// Static imports are grouped separately and follow the same group rules.
+  /// By default, static imports are placed before non-static imports,
+  /// but this behavior is changed by another option,
+  /// ``SortJavaStaticImport``.
   ///
   /// In the .clang-format configuration file, this can be configured like
   /// in the following yaml example. This will result in imports being
@@ -2016,6 +2018,29 @@ struct FormatStyle {
   /// \endcode
   bool SortIncludes;
 
+  /// Position for Java Static imports.
+  enum SortJavaStaticImportOptions {
+/// Static imports are placed before non-static imports.
+/// \code{.java}
+///   import static org.example.function1;
+///
+///   import org.example.ClassA;
+/// \endcode
+SJSIO_Before,
+/// Static imports are placed after non-static imports.
+/// \code{.java}
+///   import org.example.ClassA;
+///
+///   import static org.example.function1;
+/// \endcode

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

tambre added a comment.

In D77491#2282219 , @tambre wrote:

> In D77491#2282166 , @dmajor wrote:
>
>> This commit broke Firefox builds on Mac with an error in the SDK headers. 
>> Could you please revert if a fix is not readily available?
>>
>> Reproducer:
>>
>>   struct objc_super {};
>>   extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
>>   extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
>> ...);
>>
>> Result:
>>
>>   $ clang -c test.mm
>>   test.mm:3:48: error: reference to 'objc_super' is ambiguous
>>   extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
>> ...);
>>  ^
>>   test.mm:1:8: note: candidate found by name lookup is 'objc_super'
>>   struct objc_super {};
>>  ^
>>   note: candidate found by name lookup is 'objc_super'
>>   1 error generated.
>
> Looking into this, got an idea what might be wrong. Gimme an hour or two. :)

Fix in D87917 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

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

[PATCH] D87917: [Sema] Handle objc_super special lookup when checking builtin compatibility

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

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

objc_super is special and needs LookupPredefedObjCSuperType() called before 
performing builtin type comparisons.
This fixes an error when compiling macOS headers. A test is added.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87917

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaObjCXX/builtin-objcsuper.mm


Index: clang/test/SemaObjCXX/builtin-objcsuper.mm
===
--- /dev/null
+++ clang/test/SemaObjCXX/builtin-objcsuper.mm
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+// expected-no-diagnostics
+
+// objc_super has special lookup rules for compatibility with macOS headers, so
+// the following should compile.
+struct objc_super {};
+extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
+extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, ...);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9671,6 +9671,7 @@
 NewFD->addAttr(BuiltinAttr::CreateImplicit(Context, BuiltinID));
   } else {
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);
 
 if (!Error && !BuiltinType.isNull() &&


Index: clang/test/SemaObjCXX/builtin-objcsuper.mm
===
--- /dev/null
+++ clang/test/SemaObjCXX/builtin-objcsuper.mm
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+// expected-no-diagnostics
+
+// objc_super has special lookup rules for compatibility with macOS headers, so
+// the following should compile.
+struct objc_super {};
+extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
+extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, ...);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9671,6 +9671,7 @@
 NewFD->addAttr(BuiltinAttr::CreateImplicit(Context, BuiltinID));
   } else {
 ASTContext::GetBuiltinTypeError Error;
+LookupPredefedObjCSuperType(*this, S, NewFD->getIdentifier());
 QualType BuiltinType = Context.GetBuiltinType(BuiltinID, Error);
 
 if (!Error && !BuiltinType.isNull() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78075: [WIP][Clang][OpenMP] Added support for nowait target in CodeGen

2020-09-18 Thread Shilei Tian via Phabricator via cfe-commits

tianshilei1992 updated this revision to Diff 292835.
tianshilei1992 added a comment.

Fixed the test case `target_parallel_codegen.cpp`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78075

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp

Index: clang/test/OpenMP/target_parallel_codegen.cpp
===
--- clang/test/OpenMP/target_parallel_codegen.cpp
+++ clang/test/OpenMP/target_parallel_codegen.cpp
@@ -74,8 +74,11 @@
 #ifndef HEADER
 #define HEADER
 
-// CHECK-DAG: %struct.ident_t = type { i32, i32, i32, i32, i8* }
+// CHECK-DAG: [[IDENT_T:%.+]] = type { i32, i32, i32, i32, i8* }
 // CHECK-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00"
+// CHECK-DAG: [[ANON_T:%.+]] = type { i8 }
+// CHECK-DAG: [[KMP_TASK_T_WITH_PRIVATES:%.+]] = type { [[KMP_TASK_T:%.+]] }
+// CHECK-DAG: [[KMP_TASK_T]] = type { i8*, i32 (i32, i8*)*, i32, {{%[^,]+}}, {{%[^,]+}} }
 // CHECK-DAG: [[DEF_LOC:@.+]] = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* [[STR]], i32 0, i32 0) }
 
 // CHECK-DAG: [[TT:%.+]] = type { i64, i8 }
@@ -134,13 +137,9 @@
   double cn[5][n];
   TT d;
 
-  // CHECK:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(i64 -1, i8* @{{[^,]+}}, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i32 1, i32 0)
-  // CHECK-NEXT:  [[ERROR:%.+]] = icmp ne i32 [[RET]], 0
-  // CHECK-NEXT:  br i1 [[ERROR]], label %[[FAIL:[^,]+]], label %[[END:[^,]+]]
-  // CHECK:   [[FAIL]]
-  // CHECK:   call void [[HVT0:@.+]]()
-  // CHECK-NEXT:  br label %[[END]]
-  // CHECK:   [[END]]
+  // CHECK-32:[[TASK:%.+]] = call i8* @__kmpc_omp_target_task_alloc([[IDENT_T]]* {{[^,]+}}, i32 %0, i32 1, i32 20, i32 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T_WITH_PRIVATES:%.+]]*)* [[OMP_TASK_ENTRY:@.+]] to i32 (i32, i8*)*), i64 -1)
+  // CHECK-64:[[TASK:%.+]] = call i8* @__kmpc_omp_target_task_alloc([[IDENT_T]]* {{[^,]+}}, i32 %0, i32 1, i64 40, i64 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T_WITH_PRIVATES:%.+]]*)* [[OMP_TASK_ENTRY:@.+]] to i32 (i32, i8*)*), i64 -1)
+  // CHECK:   call i32 @__kmpc_omp_task([[IDENT_T]]* {{[^,]+}}, i32 {{%[^,]+}}, i8* [[TASK]])
   #pragma omp target parallel nowait
   {
   }
@@ -346,7 +345,7 @@
 // Check that the offloading functions are emitted and that the arguments are
 // correct and loaded correctly for the target regions in foo().
 
-// CHECK:   define internal void [[HVT0]]()
+// CHECK:   define internal void [[HVT0:@.+]]()
 // CHECK:   call {{.*}}void (%struct.ident_t*, i32, void (i32*, i32*, ...)*, ...) @__kmpc_fork_call(%struct.ident_t* [[DEF_LOC]], i32 0, void (i32*, i32*, ...)* bitcast (void (i32*, i32*)* [[OMP_OUTLINED:@.+]] to void (i32*, i32*, ...)*))
 //
 //
@@ -354,6 +353,14 @@
 // CHECK:   ret void
 // CHECK-NEXT:  }
 
+// CHECK:   define internal {{.*}}i32 [[OMP_TASK_ENTRY]](i32 {{.*}}%0, [[KMP_TASK_T_WITH_PRIVATES]]* noalias %1)
+// CHECK-DAG:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(i64 -1, i8* {{@[^,]+}}, i32 0, i8** null, i8** null, i64* null, i64* null, i8** null, i32 1, i32 0)
+// CHECK:   [[ERROR:%.+]] = icmp ne i32 [[RET]], 0
+// CHECK-NEXT:  br i1 [[ERROR]], label %[[FAIL:[^,]+]], label %[[END:[^,]+]]
+// CHECK:   [[FAIL]]
+// CHECK:   call void [[HVT0]]()
+// CHECK-NEXT:  br label %[[END]]
+// CHECK:   [[END]]
 
 // CHECK:   define internal void [[HVT1]](i[[SZ]] %{{.+}})
 // Create stack storage and store argument in there.
Index: clang/test/OpenMP/target_codegen.cpp
===
--- clang/test/OpenMP/target_codegen.cpp
+++ clang/test/OpenMP/target_codegen.cpp
@@ -54,10 +54,16 @@
 #ifndef HEADER
 #define HEADER
 
+// CHECK-DAG: [[IDENT_T:%.+]] = type { i32, i32, i32, i32, i8* }
+// CHECK-DAG: [[KMP_TASK_T_WITH_PRIVATES:%.+]] = type { [[KMP_TASK_T:%.+]], [[KMP_PRIVATES_T:%.+]] }
+// CHECK-DAG: [[KMP_TASK_T]] = type { i8*, i32 (i32, i8*)*, i32, {{%.+}}, {{%.+}} }
 // CHECK-DAG: [[TT:%.+]] = type { i64, i8 }
 // CHECK-DAG: [[S1:%.+]] = type { double }
 // CHECK-DAG: [[S2:%.+]] = type { i32, i32, i32 }
 // CHECK-DAG: [[ENTTY:%.+]] = type { i8*, i8*, i[[SZ:32|64]], i32, i32 }
+// CHECK-DAG: [[ANON_T:%.+]] = type { i[[SZ]]*, i32, i32 }
+// CHECK-32-DAG: [[KMP_PRIVATES_T]] = type { [2 x i64], i32*, i32, [2 x i8*], [2 x i8*], [2 x i8*] }
+// CHECK-64-DAG: [[KMP_PRIVATES_T]] = type { i64*, [2 x i8*], [2 x i8*], [2 x i64], [2 x i8*], i32 }
 
 // TCHECK: [[ENTTY:%.+]] = type { i8*, i8*, i{{32|64}}, i32, i32 }
 
@@ -114,6 +120,9 @@
 
 // CHECK: define {{.*}}[[FOO:@.+]](
 int foo(int n) {
+  // CHECK: [[OFFLOADBPTR:%.+]] = alloca [2 x i8*],

[PATCH] D87808: [DebugInfo] Fix bug in constructor homing where it would use ctor homing when a class only has copy/move constructors

2020-09-18 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

In D87808#2280197 , @dblaikie wrote:

> @rsmith What's the deal with these anonymous structs/unions? Why do they have 
> copy/move constructors (are those technically called from the enclosing 
> class's copy/move constructors?) but no default constructor to be called from 
> the other ctors of the enclosing class?

Yes, I'm curious: copy and move constructors require an object of this type to 
already exist in memory. Is there a well-defined way of creating an object of 
this type in memory when it has no other constructors?

Maybe the issue is that this code is running into the lazy implicit special 
member declaration optimization. Maybe the class in question has an implicit, 
trivial, default constructor, but we there is no CXXConstructorDecl present in 
the ctors list for the loop to find.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87808

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

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-09-18 Thread Raul Tambre via Phabricator via cfe-commits

tambre added a comment.

In D77491#2282166 , @dmajor wrote:

> This commit broke Firefox builds on Mac with an error in the SDK headers. 
> Could you please revert if a fix is not readily available?
>
> Reproducer:
>
>   struct objc_super {};
>   extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
>   extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
> ...);
>
> Result:
>
>   $ clang -c test.mm
>   test.mm:3:48: error: reference to 'objc_super' is ambiguous
>   extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
> ...);
>  ^
>   test.mm:1:8: note: candidate found by name lookup is 'objc_super'
>   struct objc_super {};
>  ^
>   note: candidate found by name lookup is 'objc_super'
>   1 error generated.

Looking into this, got an idea what might be wrong. Gimme an hour or two. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

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

[PATCH] D86790: [FE] Use preferred alignment instead of ABI alignment for complete object when applicable

2020-09-18 Thread James Y Knight via Phabricator via cfe-commits

jyknight added inline comments.



Comment at: clang/include/clang/AST/ASTContext.h:256
 
-  /// A cache from types to size and alignment information.
   using TypeInfoMap = llvm::DenseMap;
+  /// A cache from types to size and ABI-specified alignment information.

Please undo all the changes to the ASTContext API (both in this file and in 
ASTContext.cpp) which add the boolean NeedsPreferredAlignment to 
getTypeInfo/getTypeAlign and related functions; it's not necessary. (OK to 
leave the change to getAlignmentIfKnown).



Comment at: clang/include/clang/AST/ASTContext.h:2165
+  /// from alignment attributes).
+  unsigned getTypeAlignIfKnown(QualType T,
+   bool NeedsPreferredAlignment = false) const;

The change to this function is OK. The wording of the comment change is 
confusing, though.

How-about:
Return the alignment of a type, in bits, or 0 if the type is incomplete and we 
cannot determine the alignment (for example, from alignment attributes). The 
returned alignment is the Preferred alignment if UsePreferredAlignment is true, 
otherwise is the ABI alignment.



Comment at: clang/lib/AST/ASTContext.cpp:1850
   if (!T->isIncompleteType())
-return getTypeAlign(T);
+return getTypeAlign(T, NeedsPreferredAlignment);
 

return NeedsPreferredAlignment ? getPreferredTypeAlign(T) : getTypeAlign(T);



Comment at: clang/lib/AST/ASTContext.cpp:2106
   Width = Target->getDoubleWidth();
-  Align = Target->getDoubleAlign();
+  setAlign(Width, Target->getDoubleAlign());
   break;

jasonliu wrote:
> I have two concerns here:
> 1. I feel like we are having duplicate logic between here and 
> ASTContext::getPreferredTypeAlign for how to get preferred alignment. 
> 2.  These logic are too AIX-centric and only modified the places for where 
> types are affected by preferred alignment on AIX. What if on some platforms, 
> BuiltinType::Float have different preferred alignments? Or Width is not the 
> preferred alignment on certain platform for double/long double.
This becomes moot, if my comments are resolved.



Comment at: clang/lib/AST/ASTContext.cpp:2501
   uint64_t TypeSize = getTypeSize(T.getTypePtr());
-  return std::max(getTypeAlign(T), 
getTargetInfo().getMinGlobalAlign(TypeSize));
+  return std::max(getTypeAlign(T, true /* NeedsPreferredAlignment */),
+  getTargetInfo().getMinGlobalAlign(TypeSize));

Can just call getPreferredTypeAlign here. (Add a QualType overload to 
getPreferredTypeAlign).



Comment at: clang/lib/CodeGen/CGAtomic.cpp:814
+  std::tie(sizeChars, alignChars) = getContext().getTypeInfoInChars(
+  AtomicTy, true /* NeedsPreferredAlignment */);
   uint64_t Size = sizeChars.getQuantity();

Xiangling_L wrote:
> jyknight wrote:
> > This is wrong.
> Can you explain a bit why it's wrong?
It's not allocating new memory, it's accessing a pointer to memory somewhere 
else, so if alignChars was used, this change would be actively wrong -- using 
the wrong value.

However, alignChars is unused, so it's wrong only in a way that ultimately 
makes no difference.



Comment at: clang/lib/CodeGen/CGExprCXX.cpp:1573
 allocSizeWithoutCookie);
-  CharUnits allocAlign = getContext().getTypeAlignInChars(allocType);
+  CharUnits allocAlign = getContext().getTypeAlignInChars(
+  allocType, true /* NeedsPreferredAlignment */);

I'd add the 1-line getPreferredTypeAlignInChars function, and call it.



Comment at: clang/lib/CodeGen/CGExprCXX.cpp:1826
+getContext().toCharUnitsFromBits(getContext().getTypeAlignIfKnown(
+DeleteTy, true /* NeedsPreferredAlignment */));
 llvm::Value *Align = llvm::ConstantInt::get(ConvertType(AlignValType),

The "getTypeAlignIfKnown" function is so special-purpose, it's probably fine to 
have this 1 function keep the "Preferred" boolean. This can stay.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2114
   return std::max(CharUnits::fromQuantity(CGM.SizeSizeInBytes),
-  CGM.getContext().getTypeAlignInChars(elementType));
+  CGM.getContext().getTypeAlignInChars(
+  elementType, true /* NeedsPreferredAlignment */));

getPreferredTypeAlignInChars.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2133
+  SizeSize,
+  Ctx.getTypeAlignInChars(ElementType, true /* NeedsPreferredAlignment 
*/));
   assert(CookieSize == getArrayCookieSizeImpl(ElementType));

getPreferredTypeAlignInChars.


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

https://reviews.llvm.org/D86790

___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D87858: [hip] Add HIP scope atomic ops.

2020-09-18 Thread JF Bastien via Phabricator via cfe-commits

jfb added a comment.

In D87858#2282150 , @yaxunl wrote:

> In D87858#2280429 , @jfb wrote:
>
>> Please provide documentation in this patch.
>
> opencl atomic builtins are documented as notes to `__c11_atomic builtins` 
> part of 
> https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions. These 
> new atomic builtins can be documented in a similar way after that.

I'd like to see the documentation added to this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87858

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

[PATCH] D87895: [SyntaxTree] Test for '\' inside token.

2020-09-18 Thread Eduardo Caldas via Phabricator via cfe-commits

eduucaldas updated this revision to Diff 292832.
eduucaldas added a comment.

Fix typo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87895

Files:
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -167,6 +167,23 @@
 )txt"));
 }
 
+TEST_P(BuildSyntaxTreeTest, Simple_BackslashInsideToken) {
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+in\
+t a;
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-SimpleDeclaration
+  |-'in\
+t'
+  |-SimpleDeclarator Declarator
+  | `-'a'
+  `-';'
+)txt"));
+}
+
 TEST_P(BuildSyntaxTreeTest, If) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(


Index: clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -167,6 +167,23 @@
 )txt"));
 }
 
+TEST_P(BuildSyntaxTreeTest, Simple_BackslashInsideToken) {
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+in\
+t a;
+)cpp",
+  R"txt(
+TranslationUnit Detached
+`-SimpleDeclaration
+  |-'in\
+t'
+  |-SimpleDeclarator Declarator
+  | `-'a'
+  `-';'
+)txt"));
+}
+
 TEST_P(BuildSyntaxTreeTest, If) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87896: [SyntaxTree][Synthesis] Improve testing `createLeaf`

2020-09-18 Thread Eduardo Caldas via Phabricator via cfe-commits

eduucaldas updated this revision to Diff 292831.
eduucaldas added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87896

Files:
  clang/unittests/Tooling/Syntax/SynthesisTest.cpp


Index: clang/unittests/Tooling/Syntax/SynthesisTest.cpp
===
--- clang/unittests/Tooling/Syntax/SynthesisTest.cpp
+++ clang/unittests/Tooling/Syntax/SynthesisTest.cpp
@@ -51,6 +51,19 @@
   )txt"));
 }
 
+TEST_P(SynthesisTest, Leaf_Punctuation_CXX) {
+  if (!GetParam().isCXX())
+return;
+
+  buildTree("", GetParam());
+
+  auto *Leaf = createLeaf(*Arena, tok::coloncolon);
+
+  EXPECT_TRUE(treeDumpEqual(Leaf, R"txt(
+'::' Detached synthesized
+  )txt"));
+}
+
 TEST_P(SynthesisTest, Leaf_Keyword) {
   buildTree("", GetParam());
 
@@ -61,6 +74,19 @@
   )txt"));
 }
 
+TEST_P(SynthesisTest, Leaf_Keyword_CXX11) {
+  if (!GetParam().isCXX11OrLater())
+return;
+
+  buildTree("", GetParam());
+
+  auto *Leaf = createLeaf(*Arena, tok::kw_nullptr);
+
+  EXPECT_TRUE(treeDumpEqual(Leaf, R"txt(
+'nullptr' Detached synthesized
+  )txt"));
+}
+
 TEST_P(SynthesisTest, Leaf_Identifier) {
   buildTree("", GetParam());
 


Index: clang/unittests/Tooling/Syntax/SynthesisTest.cpp
===
--- clang/unittests/Tooling/Syntax/SynthesisTest.cpp
+++ clang/unittests/Tooling/Syntax/SynthesisTest.cpp
@@ -51,6 +51,19 @@
   )txt"));
 }
 
+TEST_P(SynthesisTest, Leaf_Punctuation_CXX) {
+  if (!GetParam().isCXX())
+return;
+
+  buildTree("", GetParam());
+
+  auto *Leaf = createLeaf(*Arena, tok::coloncolon);
+
+  EXPECT_TRUE(treeDumpEqual(Leaf, R"txt(
+'::' Detached synthesized
+  )txt"));
+}
+
 TEST_P(SynthesisTest, Leaf_Keyword) {
   buildTree("", GetParam());
 
@@ -61,6 +74,19 @@
   )txt"));
 }
 
+TEST_P(SynthesisTest, Leaf_Keyword_CXX11) {
+  if (!GetParam().isCXX11OrLater())
+return;
+
+  buildTree("", GetParam());
+
+  auto *Leaf = createLeaf(*Arena, tok::kw_nullptr);
+
+  EXPECT_TRUE(treeDumpEqual(Leaf, R"txt(
+'nullptr' Detached synthesized
+  )txt"));
+}
+
 TEST_P(SynthesisTest, Leaf_Identifier) {
   buildTree("", GetParam());
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87804: [PowerPC][Power10] Implement Vector signed/unsigned __int128 overloads for the comparison builtins

2020-09-18 Thread Amy Kwan via Phabricator via cfe-commits

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

Forgot to approve this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87804

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

[PATCH] D87671: [PowerPC] Implement Vector String Isolate Builtins in Clang/LLVM

2020-09-18 Thread Amy Kwan via Phabricator via cfe-commits

amyk updated this revision to Diff 292830.
amyk added a comment.

Address clang-format concerns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87671

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-p10vector.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/test/CodeGen/PowerPC/p10-string-ops.ll

Index: llvm/test/CodeGen/PowerPC/p10-string-ops.ll
===
--- llvm/test/CodeGen/PowerPC/p10-string-ops.ll
+++ llvm/test/CodeGen/PowerPC/p10-string-ops.ll
@@ -2,6 +2,9 @@
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
 ; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
 ; RUN:   FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr10 -ppc-asm-full-reg-names -ppc-vsr-nums-as-vr < %s | \
+; RUN:   FileCheck %s
 
 ; These test cases aim to test the vector string isolate builtins on Power10.
 
@@ -27,3 +30,97 @@
   %tmp = tail call <16 x i8> @llvm.ppc.altivec.vclrrb(<16 x i8> %a, i32 %n)
   ret <16 x i8> %tmp
 }
+
+declare <16 x i8> @llvm.ppc.altivec.vstribr(<16 x i8>)
+declare <16 x i8> @llvm.ppc.altivec.vstribl(<16 x i8>)
+declare <8 x i16> @llvm.ppc.altivec.vstrihr(<8 x i16>)
+declare <8 x i16> @llvm.ppc.altivec.vstrihl(<8 x i16>)
+
+declare i32 @llvm.ppc.altivec.vstribr.p(i32, <16 x i8>)
+declare i32 @llvm.ppc.altivec.vstribl.p(i32, <16 x i8>)
+declare i32 @llvm.ppc.altivec.vstrihr.p(i32, <8 x i16>)
+declare i32 @llvm.ppc.altivec.vstrihl.p(i32, <8 x i16>)
+
+define <16 x i8> @test_vstribr(<16 x i8> %a) {
+; CHECK-LABEL: test_vstribr:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstribr v2, v2
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <16 x i8> @llvm.ppc.altivec.vstribr(<16 x i8> %a)
+  ret <16 x i8> %tmp
+}
+
+define <16 x i8> @test_vstribl(<16 x i8> %a) {
+; CHECK-LABEL: test_vstribl:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstribl v2, v2
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <16 x i8> @llvm.ppc.altivec.vstribl(<16 x i8>%a)
+  ret <16 x i8> %tmp
+}
+
+define <8 x i16> @test_vstrihr(<8 x i16> %a) {
+; CHECK-LABEL: test_vstrihr:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstrihr v2, v2
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <8 x i16> @llvm.ppc.altivec.vstrihr(<8 x i16> %a)
+  ret <8 x i16> %tmp
+}
+
+define <8 x i16> @test_vstrihl(<8 x i16> %a) {
+; CHECK-LABEL: test_vstrihl:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstrihl v2, v2
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call <8 x i16> @llvm.ppc.altivec.vstrihl(<8 x i16> %a)
+  ret <8 x i16> %tmp
+}
+
+define i32 @test_vstribr_p(<16 x i8> %a) {
+; CHECK-LABEL: test_vstribr_p:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstribr. v2, v2
+; CHECK-NEXT:setbc r3, 4*cr6+eq
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i32 @llvm.ppc.altivec.vstribr.p(i32 1, <16 x i8> %a)
+  ret i32 %tmp
+}
+
+define i32 @test_vstribl_p(<16 x i8> %a) {
+; CHECK-LABEL: test_vstribl_p:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstribl. v2, v2
+; CHECK-NEXT:setbc r3, 4*cr6+eq
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i32 @llvm.ppc.altivec.vstribl.p(i32 1, <16 x i8> %a)
+  ret i32 %tmp
+}
+
+define i32 @test_vstrihr_p(<8 x i16> %a) {
+; CHECK-LABEL: test_vstrihr_p:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstrihr. v2, v2
+; CHECK-NEXT:setbc r3, 4*cr6+eq
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i32 @llvm.ppc.altivec.vstrihr.p(i32 1, <8 x i16> %a)
+  ret i32 %tmp
+}
+
+define i32 @test_vstrihl_p(<8 x i16> %a) {
+; CHECK-LABEL: test_vstrihl_p:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:vstrihl. v2, v2
+; CHECK-NEXT:setbc r3, 4*cr6+eq
+; CHECK-NEXT:blr
+entry:
+  %tmp = tail call i32 @llvm.ppc.altivec.vstrihl.p(i32 1, <8 x i16> %a)
+  ret i32 %tmp
+}
Index: llvm/lib/Target/PowerPC/PPCInstrPrefix.td
===
--- llvm/lib/Target/PowerPC/PPCInstrPrefix.td
+++ llvm/lib/Target/PowerPC/PPCInstrPrefix.td
@@ -921,13 +921,21 @@
   v16i8:$VRB, 
   i32:$SH))]>;
   defm VSTRIBR : VXForm_VTB5_RCr<13, 1, (outs vrrc:$vT), (ins vrrc:$vB),
- "vstribr", "$vT, $vB", IIC_VecGeneral, []>;
+ "vstribr", "$vT, $vB", IIC_VecGeneral,
+ [(set v16i8:$vT,
+   (int_ppc_altivec_vstribr v16i8:$vB))]>;
   defm VSTRIBL : VXForm_VTB5_RCr<13, 0, (outs vrrc:$vT), (ins vrrc:$vB),
- "vstribl", "$vT, $vB", IIC_VecGeneral, []>;
+ "vstribl",

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-09-18 Thread dmajor via Phabricator via cfe-commits

dmajor added a comment.

This commit broke Firefox builds on Mac with an error in the SDK headers. Could 
you please revert if a fix is not readily available?

Reproducer:

  struct objc_super {};
  extern "C" id objc_msgSendSuper(struct objc_super *super, SEL op, ...);
  extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
...);

Result:

  $ clang -c test.mm
  test.mm:3:48: error: reference to 'objc_super' is ambiguous
  extern "C" void objc_msgSendSuper_stret(struct objc_super *super, SEL op, 
...);
 ^
  test.mm:1:8: note: candidate found by name lookup is 'objc_super'
  struct objc_super {};
 ^
  note: candidate found by name lookup is 'objc_super'
  1 error generated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

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

[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-18 Thread UTKARSH SAXENA via Phabricator via cfe-commits

usaxena95 updated this revision to Diff 292828.
usaxena95 added a comment.

Fixed output_dir cmake variable. Clean build succeeds now.
Ready to land.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83814

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/quality/CompletionModel.cmake
  clang-tools-extra/clangd/quality/CompletionModelCodegen.py
  clang-tools-extra/clangd/quality/README.md
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
  clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
  clang-tools-extra/clangd/unittests/decision_forest_model/features.json
  clang-tools-extra/clangd/unittests/decision_forest_model/forest.json

Index: clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
@@ -0,0 +1,52 @@
+[
+{
+"operation": "if_greater",
+"feature": "ANumber",
+"threshold": 200.0,
+"then": {
+"operation": "if_greater",
+"feature": "AFloat",
+"threshold": -1,
+"then": {
+"operation": "boost",
+"score": 10.0
+},
+"else": {
+"operation": "boost",
+"score": -20.0
+}
+},
+"else": {
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"C"
+],
+"then": {
+"operation": "boost",
+"score": 3.0
+},
+"else": {
+"operation": "boost",
+"score": -4.0
+}
+}
+},
+{
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"B"
+],
+"then": {
+"operation": "boost",
+"score": 5.0
+},
+"else": {
+"operation": "boost",
+"score": -6.0
+}
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/features.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/features.json
@@ -0,0 +1,16 @@
+[
+{
+"name": "ANumber",
+"kind": "NUMBER"
+},
+{
+"name": "AFloat",
+"kind": "NUMBER"
+},
+{
+"name": "ACategorical",
+"kind": "ENUM",
+"type": "ns1::ns2::TestEnum",
+"header": "decision_forest_model/CategoricalFeature.h"
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
@@ -0,0 +1,5 @@
+namespace ns1 {
+namespace ns2 {
+enum TestEnum { A, B, C, D };
+} // namespace ns2
+} // namespace ns1
Index: clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
@@ -0,0 +1,29 @@
+#include "DecisionForestRuntimeTest.h"
+#include "decision_forest_model/CategoricalFeature.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+
+TEST(DecisionForestRuntime, Evaluate) {
+  using Example = ::ns1::ns2::test::Example;
+  using Cat = ::ns1::ns2::TestEnum;
+  using ::ns1::ns2::test::Evaluate;
+
+  Example E;
+  E.setANumber(200); // True
+  E.setAFloat(0);// True: +10.0
+  E.setACategorical(Cat::A); // True: +5.0
+  EXPECT_EQ(Evaluate(E), 15.0);
+
+  E.setANumber(200); // True
+  E.setAFloat(-2.5); // False: -20.0
+  E.setACategorical(Cat::B); // True: +5.0
+  EXPECT_EQ(Evaluate(E), -15.0);
+
+  E.setANumber(100); // False
+  E.setACategorical(Cat::C); // True: +3.0, False: -6.0
+  EXPECT_EQ(Evaluate(E), -3.0);
+}
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -10,6 +10,7 @@
 #include "ClangdServer.h"
 #include "CodeComplete.h"
 #include "Compiler.h"
+#include "CompletionModel.h"
 #include "Matchers.h"
 #include "Protocol.h"
 #include "Quality.h"
@@ -47,6 +48,7 @@

[PATCH] D87858: [hip] Add HIP scope atomic ops.

2020-09-18 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added a comment.

In D87858#2280429 , @jfb wrote:

> Please provide documentation in this patch.

opencl atomic builtins are documented as notes to `__c11_atomic builtins` part 
of https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions. These 
new atomic builtins can be documented in a similar way after that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87858

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

[PATCH] D87164: Extending Baremetal toolchain's support for the rtlib option.

2020-09-18 Thread Jon Roelofs via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG51c5add8547a: Extending Baremetal toolchains support 
for the rtlib option. (authored by jroelofs).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87164

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


Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -83,3 +83,7 @@
 // RUN: %clangxx -target arm-none-eabi -mthread-model posix -v 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-THREAD-MODEL-POSIX
 // CHECK-THREAD-MODEL-POSIX: Thread model: posix
+
+// RUN: %clang -### -target arm-none-eabi -rtlib=libgcc -v %s 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RTLIB-GCC
+// CHECK-RTLIB-GCC: -lgcc
Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -156,8 +156,17 @@
 
 void BareMetal::AddLinkRuntimeLib(const ArgList ,
   ArgStringList ) const {
-  CmdArgs.push_back(Args.MakeArgString("-lclang_rt.builtins-" +
-   getTriple().getArchName()));
+  ToolChain::RuntimeLibType RLT = GetRuntimeLibType(Args);
+  switch (RLT) {
+  case ToolChain::RLT_CompilerRT:
+CmdArgs.push_back(
+Args.MakeArgString("-lclang_rt.builtins-" + 
getTriple().getArchName()));
+return;
+  case ToolChain::RLT_Libgcc:
+CmdArgs.push_back("-lgcc");
+return;
+  }
+  llvm_unreachable("Unhandled RuntimeLibType.");
 }
 
 void baremetal::Linker::ConstructJob(Compilation , const JobAction ,


Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -83,3 +83,7 @@
 // RUN: %clangxx -target arm-none-eabi -mthread-model posix -v 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-THREAD-MODEL-POSIX
 // CHECK-THREAD-MODEL-POSIX: Thread model: posix
+
+// RUN: %clang -### -target arm-none-eabi -rtlib=libgcc -v %s 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RTLIB-GCC
+// CHECK-RTLIB-GCC: -lgcc
Index: clang/lib/Driver/ToolChains/BareMetal.cpp
===
--- clang/lib/Driver/ToolChains/BareMetal.cpp
+++ clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -156,8 +156,17 @@
 
 void BareMetal::AddLinkRuntimeLib(const ArgList ,
   ArgStringList ) const {
-  CmdArgs.push_back(Args.MakeArgString("-lclang_rt.builtins-" +
-   getTriple().getArchName()));
+  ToolChain::RuntimeLibType RLT = GetRuntimeLibType(Args);
+  switch (RLT) {
+  case ToolChain::RLT_CompilerRT:
+CmdArgs.push_back(
+Args.MakeArgString("-lclang_rt.builtins-" + getTriple().getArchName()));
+return;
+  case ToolChain::RLT_Libgcc:
+CmdArgs.push_back("-lgcc");
+return;
+  }
+  llvm_unreachable("Unhandled RuntimeLibType.");
 }
 
 void baremetal::Linker::ConstructJob(Compilation , const JobAction ,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 51c5add - Extending Baremetal toolchain's support for the rtlib option.

2020-09-18 Thread Jon Roelofs via cfe-commits


Author: Jon Roelofs
Date: 2020-09-18T09:19:37-07:00
New Revision: 51c5add8547a66caa5fbc9a19a91cd7976944229

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

LOG: Extending Baremetal toolchain's support for the rtlib option.

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

Patch by Manuel Carrasco!

Added: 


Modified: 
clang/lib/Driver/ToolChains/BareMetal.cpp
clang/test/Driver/baremetal.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/BareMetal.cpp 
b/clang/lib/Driver/ToolChains/BareMetal.cpp
index 97cfa7d0e156..61839a9e31b0 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.cpp
+++ b/clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -156,8 +156,17 @@ void BareMetal::AddCXXStdlibLibArgs(const ArgList ,
 
 void BareMetal::AddLinkRuntimeLib(const ArgList ,
   ArgStringList ) const {
-  CmdArgs.push_back(Args.MakeArgString("-lclang_rt.builtins-" +
-   getTriple().getArchName()));
+  ToolChain::RuntimeLibType RLT = GetRuntimeLibType(Args);
+  switch (RLT) {
+  case ToolChain::RLT_CompilerRT:
+CmdArgs.push_back(
+Args.MakeArgString("-lclang_rt.builtins-" + 
getTriple().getArchName()));
+return;
+  case ToolChain::RLT_Libgcc:
+CmdArgs.push_back("-lgcc");
+return;
+  }
+  llvm_unreachable("Unhandled RuntimeLibType.");
 }
 
 void baremetal::Linker::ConstructJob(Compilation , const JobAction ,

diff  --git a/clang/test/Driver/baremetal.cpp b/clang/test/Driver/baremetal.cpp
index 3ef5a56425a3..3a5c1555dc2c 100644
--- a/clang/test/Driver/baremetal.cpp
+++ b/clang/test/Driver/baremetal.cpp
@@ -83,3 +83,7 @@
 // RUN: %clangxx -target arm-none-eabi -mthread-model posix -v 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-THREAD-MODEL-POSIX
 // CHECK-THREAD-MODEL-POSIX: Thread model: posix
+
+// RUN: %clang -### -target arm-none-eabi -rtlib=libgcc -v %s 2>&1 \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RTLIB-GCC
+// CHECK-RTLIB-GCC: -lgcc



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

[PATCH] D87914: [AIX][Clang][Driver] Add handling of shared option

2020-09-18 Thread David Tenty via Phabricator via cfe-commits

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87914

Files:
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/test/Driver/aix-ld.c


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -377,3 +377,37 @@
 // RUN:--sysroot %S/Inputs/aix_ppc_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-LD-LIBSTDCXX %s
 // CHECK-LD-LIBSTDCXX: LLVM ERROR: linking libstdc++ unimplemented on AIX
+
+// Check powerpc64-ibm-aix7.1.0.0, 32-bit. -shared.
+// RUN: %clang -no-canonical-prefixes %s 2>&1 -### \
+// RUN:-shared \
+// RUN:-target powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD32-SHARED %s
+// CHECK-LD32-SHARED: {{.*}}clang{{.*}}" "-cc1" "-triple" 
"powerpc-ibm-aix7.1.0.0"
+// CHECK-LD32-SHARED: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD32-SHARED: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD32-SHARED: "-bM:SRE"
+// CHECK-LD32-SHARED: "-bnoentry"
+// CHECK-LD32-SHARED: "-b32"
+// CHECK-LD32-SHARED: "-bpT:0x1000" "-bpD:0x2000"
+// CHECK-LD32-SHARED-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-SHARED: "-L[[SYSROOT]]/usr/lib"
+// CHECK-LD32-SHARED: "-lc"
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit. -shared.
+// RUN: %clang -no-canonical-prefixes %s 2>&1 -### \
+// RUN:-shared \
+// RUN:-target powerpc64-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD64-SHARED %s
+// CHECK-LD64-SHARED: {{.*}}clang{{.*}}" "-cc1" "-triple" 
"powerpc64-ibm-aix7.1.0.0"
+// CHECK-LD64-SHARED: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD64-SHARED: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD64-SHARED: "-bM:SRE"
+// CHECK-LD64-SHARED: "-bnoentry"
+// CHECK-LD64-SHARED: "-b64"
+// CHECK-LD64-SHARED: "-bpT:0x1" "-bpD:0x11000"
+// CHECK-LD64-SHARED-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0_64.o"
+// CHECK-LD64-SHARED: "-L[[SYSROOT]]/usr/lib"
+// CHECK-LD64-SHARED: "-lc"
Index: clang/lib/Driver/ToolChains/AIX.cpp
===
--- clang/lib/Driver/ToolChains/AIX.cpp
+++ clang/lib/Driver/ToolChains/AIX.cpp
@@ -92,6 +92,12 @@
   if (Args.hasArg(options::OPT_static))
 CmdArgs.push_back("-bnso");
 
+  // Add options for shared libraries.
+  if (Args.hasArg(options::OPT_shared)) {
+CmdArgs.push_back("-bM:SRE");
+CmdArgs.push_back("-bnoentry");
+  }
+
   // Specify linker output file.
   assert((Output.isFilename() || Output.isNothing()) && "Invalid output.");
   if (Output.isFilename()) {
@@ -123,7 +129,8 @@
   return IsArch32Bit ? "crt0.o" : "crt0_64.o";
   };
 
-  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
+  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles,
+   options::OPT_shared)) {
 CmdArgs.push_back(
 Args.MakeArgString(ToolChain.GetFilePath(getCrt0Basename(;
   }


Index: clang/test/Driver/aix-ld.c
===
--- clang/test/Driver/aix-ld.c
+++ clang/test/Driver/aix-ld.c
@@ -377,3 +377,37 @@
 // RUN:--sysroot %S/Inputs/aix_ppc_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-LD-LIBSTDCXX %s
 // CHECK-LD-LIBSTDCXX: LLVM ERROR: linking libstdc++ unimplemented on AIX
+
+// Check powerpc64-ibm-aix7.1.0.0, 32-bit. -shared.
+// RUN: %clang -no-canonical-prefixes %s 2>&1 -### \
+// RUN:-shared \
+// RUN:-target powerpc-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD32-SHARED %s
+// CHECK-LD32-SHARED: {{.*}}clang{{.*}}" "-cc1" "-triple" "powerpc-ibm-aix7.1.0.0"
+// CHECK-LD32-SHARED: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD32-SHARED: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD32-SHARED: "-bM:SRE"
+// CHECK-LD32-SHARED: "-bnoentry"
+// CHECK-LD32-SHARED: "-b32"
+// CHECK-LD32-SHARED: "-bpT:0x1000" "-bpD:0x2000"
+// CHECK-LD32-SHARED-NOT: "[[SYSROOT]]/usr/lib{{/|}}crt0.o"
+// CHECK-LD32-SHARED: "-L[[SYSROOT]]/usr/lib"
+// CHECK-LD32-SHARED: "-lc"
+
+// Check powerpc64-ibm-aix7.1.0.0, 64-bit. -shared.
+// RUN: %clang -no-canonical-prefixes %s 2>&1 -### \
+// RUN:-shared \
+// RUN:-target powerpc64-ibm-aix7.1.0.0 \
+// RUN:--sysroot %S/Inputs/aix_ppc_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-LD64-SHARED %s
+// CHECK-LD64-SHARED: {{.*}}clang{{.*}}" "-cc1" "-triple" "powerpc64-ibm-aix7.1.0.0"
+// CHECK-LD64-SHARED: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-LD64-SHARED: "{{.*}}ld{{(.exe)?}}"
+// CHECK-LD64-SHARED: "-bM:SRE"
+// CHECK-LD64-SHARED:

[PATCH] D87188: [InstCombine] Canonicalize SPF to abs intrinc

2020-09-18 Thread Sanjay Patel via Phabricator via cfe-commits

spatel added a comment.

In D87188#2281957 , @sanwou01 wrote:

> I know this has already been reverted but just FYI that I've bisected a ~2% 
> regression in SPEC2017 x264_r on AArch64 to this commit. Presumably this is 
> due to the extra unrolling / cost modelling issue already mentioned?

That would be my guess. I'm not familiar with the unroller or inliner, but I 
don't even see them using the cost model at 1st glance. Are they purely 
counting IR instructions?

If I missed the cost model calls, the cost model is still not correct for 
`code-size`:

  $ cat cost.ll
  declare i32@llvm.abs.i32(i32, i1)
  define i32 @abs(i32 %x, i32 %y) {
%I32 = call i32 @llvm.abs.i32(i32 %x, i1 false)
%negx = sub i32 0, %x
%cmp = icmp sgt i32 %x, -1
%sel = select i1 %cmp, i32 %x, i32 %negx 
ret i32 %I32
  }
  
  $ opt  -cost-model -cost-kind=code-size -analyze -mtriple=aarch64--  cost.ll 
  Printing analysis 'Cost Model Analysis' for function 'abs':
  Cost Model: Found an estimated cost of 1 for instruction:   %I32 = call i32 
@llvm.abs.i32(i32 %x, i1 false)
  Cost Model: Found an estimated cost of 1 for instruction:   %negx = sub i32 
0, %x
  Cost Model: Found an estimated cost of 1 for instruction:   %cmp = icmp sgt 
i32 %x, -1
  Cost Model: Found an estimated cost of 1 for instruction:   %sel = select i1 
%cmp, i32 %x, i32 %negx

So we're assuming the size cost is either 1 or 3 depending on how we encoded 
abs() in IR, but neither is correct for AArch64 IIUC:

  $ llc -o - -mtriple=aarch64-- cost.ll 
cmp w0, #0  // =0
cnegw0, w0, mi
ret


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87188

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

[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-18 Thread UTKARSH SAXENA via Phabricator via cfe-commits

usaxena95 updated this revision to Diff 292818.
usaxena95 added a comment.

Removed generated (for review) files.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83814

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/quality/CompletionModel.cmake
  clang-tools-extra/clangd/quality/CompletionModelCodegen.py
  clang-tools-extra/clangd/quality/README.md
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
  clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
  clang-tools-extra/clangd/unittests/decision_forest_model/features.json
  clang-tools-extra/clangd/unittests/decision_forest_model/forest.json

Index: clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/forest.json
@@ -0,0 +1,52 @@
+[
+{
+"operation": "if_greater",
+"feature": "ANumber",
+"threshold": 200.0,
+"then": {
+"operation": "if_greater",
+"feature": "AFloat",
+"threshold": -1,
+"then": {
+"operation": "boost",
+"score": 10.0
+},
+"else": {
+"operation": "boost",
+"score": -20.0
+}
+},
+"else": {
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"C"
+],
+"then": {
+"operation": "boost",
+"score": 3.0
+},
+"else": {
+"operation": "boost",
+"score": -4.0
+}
+}
+},
+{
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"B"
+],
+"then": {
+"operation": "boost",
+"score": 5.0
+},
+"else": {
+"operation": "boost",
+"score": -6.0
+}
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/features.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/features.json
@@ -0,0 +1,16 @@
+[
+{
+"name": "ANumber",
+"kind": "NUMBER"
+},
+{
+"name": "AFloat",
+"kind": "NUMBER"
+},
+{
+"name": "ACategorical",
+"kind": "ENUM",
+"type": "ns1::ns2::TestEnum",
+"header": "decision_forest_model/CategoricalFeature.h"
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/decision_forest_model/CategoricalFeature.h
@@ -0,0 +1,5 @@
+namespace ns1 {
+namespace ns2 {
+enum TestEnum { A, B, C, D };
+} // namespace ns2
+} // namespace ns1
Index: clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
@@ -0,0 +1,29 @@
+#include "DecisionForestRuntimeTest.h"
+#include "decision_forest_model/CategoricalFeature.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+
+TEST(DecisionForestRuntime, Evaluate) {
+  using Example = ::ns1::ns2::test::Example;
+  using Cat = ::ns1::ns2::TestEnum;
+  using ::ns1::ns2::test::Evaluate;
+
+  Example E;
+  E.setANumber(200); // True
+  E.setAFloat(0);// True: +10.0
+  E.setACategorical(Cat::A); // True: +5.0
+  EXPECT_EQ(Evaluate(E), 15.0);
+
+  E.setANumber(200); // True
+  E.setAFloat(-2.5); // False: -20.0
+  E.setACategorical(Cat::B); // True: +5.0
+  EXPECT_EQ(Evaluate(E), -15.0);
+
+  E.setANumber(100); // False
+  E.setACategorical(Cat::C); // True: +3.0, False: -6.0
+  EXPECT_EQ(Evaluate(E), -3.0);
+}
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -10,6 +10,7 @@
 #include "ClangdServer.h"
 #include "CodeComplete.h"
 #include "Compiler.h"
+#include "CompletionModel.h"
 #include "Matchers.h"
 #include "Protocol.h"
 #include "Quality.h"
@@ -47,6 +48,7 @@
 using ::testing::IsEmpty;
 using

[PATCH] D87534: Sema: introduce `attribute((__swift_name__))`

2020-09-18 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, though you may want to get a second set of eyes on the swift name 
validation bits for a more thorough review of that part.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3997
+def warn_attr_swift_name_setter_parameters
+  : Warning<"%0 attribute for setter must take one parameter for new value">,
+InGroup;

compnerd wrote:
> aaron.ballman wrote:
> > take -> have
> > 
> > elsewhere `new value` is spelled `'newValue:`, should that be the same here?
> `newValue:` is the argument label spelling and "new value" is the argument 
> value, which is the reason for the difference.
That makes sense to me, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87534

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

1 2 >

1 - 100 of 170 matches

Mail list logo