[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D69825#1827826 , @xazax.hun wrote:

> This patch breaks scan-build-py which parses the output of "-###" to get -cc1 
> command.


Uh-oh, thanks for catching this. The same applies to the regular `scan-build`. 
Unfortunately, neither is properly tested. We really need to get this fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D71612: [analyzer] Add PlacementNewChecker

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

This looks fantastic. Let's enable by it default!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71612



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

[PATCH] D72635: Allow arbitrary capability name in Thread Safety Analysis

[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 with a minor testing request, thank you!




Comment at: clang/test/Sema/attr-capabilities.c:12
-// Test an invalid capability name
-struct __attribute__((capability("wrong"))) IncorrectName {}; // 
expected-warning {{invalid capability name 'wrong'; capability name must be 
'mutex' or 'role'}}
-

I think it would be beneficial to have a test with an arbitrary capability name 
other than role or mutex just to show that it's now explicitly allowed.


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

https://reviews.llvm.org/D72635



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

[PATCH] D28955: [analyzer] Enable support for symbolic extension/truncation

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

@ddcc, sure, np!


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

https://reviews.llvm.org/D28955



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

[PATCH] D71607: [clang-tidy] Add unsigned subtraction warning, with suggestion to convert to unsigned literals.

[Jeffrey Sorensen via Phabricator via cfe-commits]

sorenj added a comment.

Okay, but as you can see the majority of my test cases are intentionally false 
negatives `- -Wsign-conversion` triggers so often than many people don't use 
it. And, `unsigned x = 2;` does not trigger a sign conversion warning despite 
there being a conversion form 2 to 2u. This check is targeting a very specific 
but frequent case of functions that do not guard against containers that might 
be empty.

Regarding the false positives - I think you are focusing on the semantics of 
the fix-it which is literally a no-op. The code before and after may be just as 
wrong, but the salience of the implied conversion is a bit higher. Maybe that's 
not a good idea for a change that may be applied automatically, even if safe.

In short I'm not sure if you are objecting the principle here, or the 
implementation. Is this something that can be refined further? I understand the 
objection in the first case, but what about the second case makes you think 
this is not a good diagnostic and a false positive? It's the specific case I 
was targeting: the unprotected subtraction of a non-zero value from a 
potentially smaller value.

This check was used across our very large code base and was evaluated by 
examining the code by looking at the context where these warning fired. The 
vast majority were judged to be true positives. Unfortunately it's not possible 
to share those results. I will try to run this check on some fraction of the 
llvm code base and follow up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71607



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

[PATCH] D50360: [Concepts] Requires Expressions

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

This breaks tests on non-Win, see e.g. http://45.33.8.238/linux/7846/step_7.txt 
http://45.33.8.238/mac/6120/step_7.txt

Please watch http://lab.llvm.org:8011/console for a bit after landing changes.

Please take a look, and if the fix isn't obvious please revert while you 
investigate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50360



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

@thakis landed a patch to control this behavior on the cmd-line, adding 
`-fno-integrated-cc1` would solve your issue (ie. revert to old behavior). @NoQ 
@xazax.hun is that an acceptable solution?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added a comment.

There might be other tools parsing the output of `-###`. I think adding a line 
break in the output is better/easier than updating all those tools (amd making 
them potentially slower, not profiting from this patch).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D69585: PerformPendingInstatiations() already in the PCH

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:984
+
+PerformPendingInstantiations();
   }

All tests pass if you add `if (LangOpts.BuildingPCHWithObjectFile)` here. But 
if a specialization occurs inside a .CPP which includes the .PCH, not sure what 
would/should happen, and if that'S handled. Definitely needs a test for that. 
@rsmith WDYT?


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

https://reviews.llvm.org/D69585



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

[clang] 80146fc - [test] clang/test/InterfaceStubs/externstatic.c requires x86-registered-target

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2020-01-18T09:54:35-08:00
New Revision: 80146fc13adaf3a523c03a1ff8693ed157a29138

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

LOG: [test] clang/test/InterfaceStubs/externstatic.c requires 
x86-registered-target

Added: 


Modified: 
clang/test/InterfaceStubs/externstatic.c

Removed: 




diff  --git a/clang/test/InterfaceStubs/externstatic.c 
b/clang/test/InterfaceStubs/externstatic.c
index 503f04e28f0e..298dd24a013f 100644
--- a/clang/test/InterfaceStubs/externstatic.c
+++ b/clang/test/InterfaceStubs/externstatic.c
@@ -1,3 +1,4 @@
+// REQUIRES: x86-registered-target
 // RUN: %clang -cc1 -fvisibility default -DSTORAGE="extern" -o - 
-emit-interface-stubs -std=c99 -xc %s | \
 // RUN: FileCheck -check-prefix=CHECK-EXTERN %s
 



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

[PATCH] D72979: [Codegen] Emit both AssumeAlignedAttr and AllocAlignAttr assumptions if they exist

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri created this revision.
lebedev.ri added reviewers: erichkeane, jdoerfert, aaron.ballman.
lebedev.ri added a project: clang.
lebedev.ri edited the summary of this revision.

We shouldn't be just giving up if we find one of them
(like we currently do with `AssumeAlignedAttr`),
we should emit them all.

As the tests show, even if we materialized good knowledge
from `__attribute__((assume_aligned(32)`, it doesn't mean
`__attribute__((alloc_align([...])))` info won't be useful.
It might be, but that isn't given.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72979

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c


Index: clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c
===
--- /dev/null
+++ clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c
@@ -0,0 +1,77 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | 
FileCheck %s
+
+void *my_aligned_alloc(int size, int alignment) 
__attribute__((assume_aligned(32), alloc_align(2)));
+
+// CHECK-LABEL: @t0_immediate0(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[CALL:%.*]] = call i8* @my_aligned_alloc(i32 320, i32 16)
+// CHECK-NEXT:[[PTRINT:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR:%.*]] = and i64 [[PTRINT]], 31
+// CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
+// CHECK-NEXT:[[PTRINT1:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR2:%.*]] = and i64 [[PTRINT1]], 15
+// CHECK-NEXT:[[MASKCOND3:%.*]] = icmp eq i64 [[MASKEDPTR2]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND3]])
+// CHECK-NEXT:ret i8* [[CALL]]
+//
+void *t0_immediate0() {
+  return my_aligned_alloc(320, 16);
+};
+
+// CHECK-LABEL: @t1_immediate1(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[CALL:%.*]] = call i8* @my_aligned_alloc(i32 320, i32 32)
+// CHECK-NEXT:[[PTRINT:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR:%.*]] = and i64 [[PTRINT]], 31
+// CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
+// CHECK-NEXT:[[PTRINT1:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR2:%.*]] = and i64 [[PTRINT1]], 31
+// CHECK-NEXT:[[MASKCOND3:%.*]] = icmp eq i64 [[MASKEDPTR2]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND3]])
+// CHECK-NEXT:ret i8* [[CALL]]
+//
+void *t1_immediate1() {
+  return my_aligned_alloc(320, 32);
+};
+
+// CHECK-LABEL: @t2_immediate2(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[CALL:%.*]] = call i8* @my_aligned_alloc(i32 320, i32 64)
+// CHECK-NEXT:[[PTRINT:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR:%.*]] = and i64 [[PTRINT]], 31
+// CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
+// CHECK-NEXT:[[PTRINT1:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR2:%.*]] = and i64 [[PTRINT1]], 63
+// CHECK-NEXT:[[MASKCOND3:%.*]] = icmp eq i64 [[MASKEDPTR2]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND3]])
+// CHECK-NEXT:ret i8* [[CALL]]
+//
+void *t2_immediate2() {
+  return my_aligned_alloc(320, 64);
+};
+
+// CHECK-LABEL: @t3_variable(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[ALIGNMENT_ADDR:%.*]] = alloca i32, align 4
+// CHECK-NEXT:store i32 [[ALIGNMENT:%.*]], i32* [[ALIGNMENT_ADDR]], align 4
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, i32* [[ALIGNMENT_ADDR]], align 4
+// CHECK-NEXT:[[CALL:%.*]] = call i8* @my_aligned_alloc(i32 320, i32 
[[TMP0]])
+// CHECK-NEXT:[[PTRINT:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR:%.*]] = and i64 [[PTRINT]], 31
+// CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
+// CHECK-NEXT:[[ALIGNMENTCAST:%.*]] = zext i32 [[TMP0]] to i64
+// CHECK-NEXT:[[MASK:%.*]] = sub i64 [[ALIGNMENTCAST]], 1
+// CHECK-NEXT:[[PTRINT1:%.*]] = ptrtoint i8* [[CALL]] to i64
+// CHECK-NEXT:[[MASKEDPTR2:%.*]] = and i64 [[PTRINT1]], [[MASK]]
+// CHECK-NEXT:[[MASKCOND3:%.*]] = icmp eq i64 [[MASKEDPTR2]], 0
+// CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND3]])
+// CHECK-NEXT:ret i8* [[CALL]]
+//
+void *t3_variable(int alignment) {
+  return my_aligned_alloc(320, alignment);
+};
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -4629,7 +4629,8 @@
   llvm::ConstantInt *AlignmentCI = cast(Alignment);
   EmitAlignmentAssumption(Ret.getScalarVal(), RetTy, Loc, 
AA->getLocation(),
   AlignmentCI, OffsetValue)

[PATCH] D69585: PerformPendingInstatiations() already in the PCH

[Luboš Luňák via Phabricator via cfe-commits]

llunak added inline comments.



Comment at: clang/lib/Sema/Sema.cpp:984
+
+PerformPendingInstantiations();
   }

aganea wrote:
> All tests pass if you add `if (LangOpts.BuildingPCHWithObjectFile)` here. But 
> if a specialization occurs inside a .CPP which includes the .PCH, not sure 
> what would/should happen, and if that'S handled. Definitely needs a test for 
> that. @rsmith WDYT?
> All tests pass if you add if (LangOpts.BuildingPCHWithObjectFile) here.

That is because BuildingPCHWithObjectFile is almost unused by tests, so this 
just disables the change. But the change should be enabled for everything, it 
doesn't depend on whether PCH's object file is used.

> But if a specialization occurs inside a .CPP which includes the .PCH, not 
> sure what would/should happen, and if that'S handled. 

You mean this?

```
a.h:
#pragma once
template< typename T >
struct A { int foo() const; };
int bar(A* a) { return a->foo(); }
a.cpp:
#include "a.h"
template<> int A::foo() const { return 10; }

```
That errors out with "explicit specialization of 'foo' after instantiation" 
with or without PCH used, with or without my patch. I don't know about tests 
for it though. I can add this as one.



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

https://reviews.llvm.org/D69585



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

[PATCH] D71966: [Wdocumentation][RFC] Improve identifier's of \param

[Mark de Wever via Phabricator via cfe-commits]

Mordante marked 14 inline comments as done.
Mordante added a comment.

Thanks for the review!

I only answered to the larger issues to get a better feeling of the direction 
the patch should go. Once that's clear I'll make a new patch and also address 
the smaller issues.




Comment at: clang/include/clang-c/Documentation.h:383
 CINDEX_LINKAGE
-CXString clang_ParamCommandComment_getParamName(CXComment Comment);
 

gribozavr2 wrote:
> Please don't modify existing APIs in libclang -- it provides a stable API and 
> ABI, and what has shipped, can't be changed. New functionality has to be 
> exposed as new functions, while old functions should be kept working to the 
> extent possible. It means that the resulting API can be subpar, but oh well, 
> a stable ABI is a contract of libclang.
I thought I had read this API was allowed to change, but required adding 
information to the release notes. (I can't find it quickly.)
I'll undo the changes to the existing functions and add new functions instead.



Comment at: clang/include/clang/AST/Comment.h:781
+  /// @param Idx The index of the identifier in the \\param command.
+  StringRef getParamName(unsigned Idx) const LLVM_READONLY {
+return getArgText(Idx);

gribozavr2 wrote:
> Users can already call getArgText, do we need a second function that does the 
> same?
I thought it made sense to offer these helper functions. `getParamName` seems 
clearer than `getArgText`. Of course it's also possible to add documentation 
instead of a helper function. What do you prefer?

Note: This function is the replacement of `getParamNameAsWritten`, so I can 
also reinstate its former name.



Comment at: clang/include/clang/AST/Comment.h:804
+assert(Idx < ParamIndex.size());
+return !isVarArgParam(Idx) && ParamIndex[Idx] != InvalidParamIndex;
   }

gribozavr2 wrote:
> Why does vararg have an invalid index? Previously it was considered valid.
Before a lot of code first tested whether the index was valid and then 
depending on the vararg state do a different codepath. I thought it was very 
confusing that if the function returned `true` it was no guarantee it was safe 
to access `DeclInfo::ParamVars[Idx]`.



Comment at: clang/include/clang/Basic/DiagnosticCommentKinds.td:113
+def warn_doc_param_undocumented : Warning<
+  "parameter '%0' is not documented">,
+  InGroup, DefaultIgnore;

gribozavr2 wrote:
> This warning should be in a separate group. `-Wdocumentation` contains 
> generally useful, non-controversial stuff (that would have been an error if 
> documentation comments were a part of the language). Warning about every 
> undocumented parameter is only useful for certain style guides.
> 
> (Digression: And even then, I personally question the value of a style rule 
> that requires every parameter (or every public API, or every file, or every 
> whatever else) to be documented. Unless there's a tech writer on the team, in 
> response to a such rule engineers are highly likely just to write useless 
> comments like "\param frobnicator The Frobnicator necessary for this call." 
> Engineers are already doing the best they can when writing comments. The 
> choice we have is not between "no comments for some parameters" and "good 
> comments for every parameter because the warning reminded you", it is between 
> "no comments for some parameters" and "placeholder stuff that people will 
> write to make the warning go away".)
> 
> I'd also suggest to implement this functionality in a separate patch.
I'll move it to its own patch.



Comment at: clang/lib/AST/Comment.cpp:376
+  case InvalidParamIndex:
+return getParamName(Idx);
+

gribozavr2 wrote:
> Previously, it was necessary for the index to be valid. Why relax the 
> contract? (This change also makes things in consistent with, say, TParam).
IMO it makes it easier on the caller site. If it wants the name of the variable 
in the current `FullComment` context they can simply call this function. Then 
they don't need to validate whether the index is valid or not. (I intend to do 
a similar patch for TParam.)



Comment at: clang/lib/AST/CommentSema.cpp:758
+WarnUndocumentedParameters = true;
+StringRef ParamName = PCC->getParamName(Idx);
 

gribozavr2 wrote:
> Here's one reason why I find the fallback in `getParamName` to be 
> questionable -- with the fallback, the function does different things 
> depending on the phase of processing. Sometimes it returns the original name 
> as written (before the index is set), and sometimes it returns the name from 
> the function declaration (which can be different, as far as I understand). 
> I'd much prefer to call `getParamNameAsWritten` here.
The difference is now in the `FullComment` argument instead of the name. But it 
seems that is not clear.



Comment at:

[PATCH] D68912: Adds -Wrange-loop-analysis to -Wall

[Mark de Wever via Phabricator via cfe-commits]

Mordante added a comment.

Thanks for your report. I think it's similar to 
https://bugs.llvm.org/show_bug.cgi?id=44556. I'll look for a fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68912



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

[PATCH] D72982: [Clang] Un-break scan-build after integrated-cc1 change

[Alexandre Ganea via Phabricator via cfe-commits]

aganea created this revision.
aganea added reviewers: xazax.hun, NoQ, thakis, hans.
Herald added subscribers: cfe-commits, Charusso, rnkovacs.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72982

Files:
  clang/lib/Driver/Job.cpp
  clang/test/Driver/cuda-simple.cu
  clang/test/Driver/offloading-interoperability.c
  clang/test/Driver/option-aliases.c


Index: clang/test/Driver/option-aliases.c
===
--- clang/test/Driver/option-aliases.c
+++ clang/test/Driver/option-aliases.c
@@ -3,12 +3,12 @@
 // RUN: --param=FOO --output=FOO %s 2>&1 | \
 // RUN: FileCheck %s
 
-// CHECK: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-E"
 // CHECK: "-U" "FOO"
 // CHECK: "-U" "BAR"
 // CHECK: "-o" "option-aliases.i"
 
-// CHECK-NEXT: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-S"
 // CHECK: "-o" "FOO"
Index: clang/test/Driver/offloading-interoperability.c
===
--- clang/test/Driver/offloading-interoperability.c
+++ clang/test/Driver/offloading-interoperability.c
@@ -8,10 +8,10 @@
 // RUN: %clang -no-canonical-prefixes -### -x cuda -target 
powerpc64le-linux-gnu -std=c++11 --cuda-gpu-arch=sm_35 -fopenmp=libomp %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix NO-OPENMP-FLAGS-FOR-CUDA-DEVICE
 //
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NOT:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: ptxas" "-m64"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: fatbinary"{{( "--cuda")?}} "-64"
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: {{ld(.exe)?"}} {{.*}}"-m" "elf64lppc"
Index: clang/test/Driver/cuda-simple.cu
===
--- clang/test/Driver/cuda-simple.cu
+++ clang/test/Driver/cuda-simple.cu
@@ -5,10 +5,10 @@
 // Verify that we pass -x cuda-cpp-output to compiler after
 // preprocessing a CUDA file
 // RUN: %clang  -Werror -### -save-temps -c %s 2>&1 | FileCheck %s
-// CHECK: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-E"
 // CHECK: "-x" "cuda"
-// CHECK-NEXT: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-x" "cuda-cpp-output"
 //
 // Verify that compiler accepts CUDA syntax with "-x cuda-cpp-output".
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -373,7 +373,7 @@
 
 void CC1Command::Print(raw_ostream &OS, const char *Terminator, bool Quote,
CrashReportInfo *CrashInfo) const {
-  OS << " (in-process)";
+  OS << " (in-process)\n";
   Command::Print(OS, Terminator, Quote, CrashInfo);
 }
 


Index: clang/test/Driver/option-aliases.c
===
--- clang/test/Driver/option-aliases.c
+++ clang/test/Driver/option-aliases.c
@@ -3,12 +3,12 @@
 // RUN: --param=FOO --output=FOO %s 2>&1 | \
 // RUN: FileCheck %s
 
-// CHECK: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-E"
 // CHECK: "-U" "FOO"
 // CHECK: "-U" "BAR"
 // CHECK: "-o" "option-aliases.i"
 
-// CHECK-NEXT: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-S"
 // CHECK: "-o" "FOO"
Index: clang/test/Driver/offloading-interoperability.c
===
--- clang/test/Driver/offloading-interoperability.c
+++ clang/test/Driver/offloading-interoperability.c
@@ -8,10 +8,10 @@
 // RUN: %clang -no-canonical-prefixes -### -x cuda -target powerpc64le-linux-gnu -std=c++11 --cuda-gpu-arch=sm_35 -fopenmp=libomp %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix NO-OPENMP-FLAGS-FOR-CUDA-DEVICE
 //
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  clang{{.*}}" "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" "nvptx64-nvidia-cuda"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NOT:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: ptxas" "-m64"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: fatbinary"{{( "--cuda")?}} "-64"
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: clang{{.*}}" "-cc1" "-triple" "powerpc64le-unknown-linux-gnu"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" "powerpc64le-unknown-linux-gnu"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: {{ld(.exe)?"}} {{.*}}"-m" "elf64lppc"
Index: clang/test/Driver/cuda-simple.cu
===
--- clang/test/Driver/cuda-simple.cu
+++ clang/test/Driver/cuda-simple.cu
@@ -5,10 +5,10 @@
 // Verify that we pa

[PATCH] D67161: [clang,ARM] Initial ACLE intrinsics for MVE.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I posted a patch to speed things up:
https://reviews.llvm.org/D72984
The numbers are different, since 9 seconds is measured in a local linux build 
with no debug info, vs. 28s I measured when building at work, on Windows, with 
debug info.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67161



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

[PATCH] D72984: [TableGen] Use a table to lookup MVE intrinsic names

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.
rnk added reviewers: simon_tatham, dmgreen, ostannard, MarkMurrayARM.
Herald added a project: clang.

Speeds up compilation of SemaDeclAttr.cpp by nine seconds:

  0m49.555s - > 0m40.249s


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D72984

Files:
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/utils/TableGen/MveEmitter.cpp


Index: clang/utils/TableGen/MveEmitter.cpp
===
--- clang/utils/TableGen/MveEmitter.cpp
+++ clang/utils/TableGen/MveEmitter.cpp
@@ -64,6 +64,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
+#include "llvm/TableGen/StringToOffsetTable.h"
 #include 
 #include 
 #include 
@@ -1846,14 +1847,46 @@
 }
 
 void MveEmitter::EmitBuiltinAliases(raw_ostream &OS) {
+  // Build a sorted table of:
+  // - intrinsic id number
+  // - full name
+  // - polymorphic name or -1
+  StringToOffsetTable StringTable;
+  OS << "struct IntrinToName {\n"
+"  uint32_t Id;\n"
+"  int32_t FullName;\n"
+"  int32_t ShortName;\n"
+"};\n";
+  OS << "static const IntrinToName Map[] = {\n";
   for (const auto &kv : ACLEIntrinsics) {
 const ACLEIntrinsic &Int = *kv.second;
-OS << "case ARM::BI__builtin_arm_mve_" << Int.fullName() << ":\n"
-   << "  return AliasName == \"" << Int.fullName() << "\"";
-if (Int.polymorphic())
-  OS << " || AliasName == \"" << Int.shortName() << "\"";
-OS << ";\n";
-  }
+int32_t ShortNameOffset =
+Int.polymorphic() ? StringTable.GetOrAddStringOffset(Int.shortName())
+  : -1;
+OS << "  { ARM::BI__builtin_arm_mve_" << Int.fullName() << ", "
+   << StringTable.GetOrAddStringOffset(Int.fullName()) << ", "
+   << ShortNameOffset << "},\n";
+  }
+  OS << "};\n\n";
+
+  OS << "static const char IntrinNames[] = {\n";
+  StringTable.EmitString(OS);
+  OS << "};\n\n";
+
+  OS << "auto It = std::lower_bound(std::begin(Map), "
+"std::end(Map), BuiltinID,\n"
+"  [](const IntrinToName &L, unsigned Id) {\n"
+"return L.Id < Id;\n"
+"  });\n";
+  OS << "if (It == std::end(Map) || It->Id != BuiltinID)\n"
+"  return false;\n";
+  OS << "StringRef FullName(&IntrinNames[It->FullName]);\n";
+  OS << "if (AliasName == FullName)\n"
+"  return true;\n";
+  OS << "if (It->ShortName == -1)\n"
+"  return false;\n";
+  OS << "StringRef ShortName(&IntrinNames[It->ShortName]);\n";
+  OS << "return AliasName == ShortName;\n";
 }
 
 } // namespace
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -4937,11 +4937,7 @@
 static bool ArmMveAliasValid(unsigned BuiltinID, StringRef AliasName) {
   if (AliasName.startswith("__arm_"))
 AliasName = AliasName.substr(6);
-  switch (BuiltinID) {
 #include "clang/Basic/arm_mve_builtin_aliases.inc"
-  default:
-return false;
-  }
 }
 
 static void handleArmMveAliasAttr(Sema &S, Decl *D, const ParsedAttr &AL) {


Index: clang/utils/TableGen/MveEmitter.cpp
===
--- clang/utils/TableGen/MveEmitter.cpp
+++ clang/utils/TableGen/MveEmitter.cpp
@@ -64,6 +64,7 @@
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
+#include "llvm/TableGen/StringToOffsetTable.h"
 #include 
 #include 
 #include 
@@ -1846,14 +1847,46 @@
 }
 
 void MveEmitter::EmitBuiltinAliases(raw_ostream &OS) {
+  // Build a sorted table of:
+  // - intrinsic id number
+  // - full name
+  // - polymorphic name or -1
+  StringToOffsetTable StringTable;
+  OS << "struct IntrinToName {\n"
+"  uint32_t Id;\n"
+"  int32_t FullName;\n"
+"  int32_t ShortName;\n"
+"};\n";
+  OS << "static const IntrinToName Map[] = {\n";
   for (const auto &kv : ACLEIntrinsics) {
 const ACLEIntrinsic &Int = *kv.second;
-OS << "case ARM::BI__builtin_arm_mve_" << Int.fullName() << ":\n"
-   << "  return AliasName == \"" << Int.fullName() << "\"";
-if (Int.polymorphic())
-  OS << " || AliasName == \"" << Int.shortName() << "\"";
-OS << ";\n";
-  }
+int32_t ShortNameOffset =
+Int.polymorphic() ? StringTable.GetOrAddStringOffset(Int.shortName())
+  : -1;
+OS << "  { ARM::BI__builtin_arm_mve_" << Int.fullName() << ", "
+   << StringTable.GetOrAddStringOffset(Int.fullName()) << ", "
+   << ShortNameOffset << "},\n";
+  }
+  OS << "};\n\n";
+
+  OS << "static const char IntrinNames[] = {\n";
+  StringTable.EmitString(OS);
+  OS << "};\n\n";
+
+  OS << "auto It = std::lower_bound(std::begin(Map), "
+"std::end(Map), BuiltinID,\n"
+"  [](const IntrinToName &L, unsigned Id) {\n"
+"return L.Id < Id;\n"
+"  });\n";
+  OS << "if (It == std::end(Map) |

[PATCH] D72984: [TableGen] Use a table to lookup MVE intrinsic names

[pre-merge checks [bot] via Phabricator via cfe-commits]

merge_guards_bot added a comment.

{icon check-circle color=green} Unit tests: pass. 61989 tests passed, 0 failed 
and 783 were skipped.

{icon question-circle color=gray} clang-tidy: unknown.

{icon check-circle color=green} clang-format: pass.

Build artifacts 
: 
diff.json 
,
 clang-format.patch 
,
 CMakeCache.txt 
,
 console-log.txt 
,
 test-results.xml 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72984



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

[clang] e68c1e0 - [Concepts] Fix name-type conflict compilation issues

[Saar Raz via cfe-commits]

Author: Saar Raz
Date: 2020-01-19T00:45:25+02:00
New Revision: e68c1e00eba4ae64d38e62eebebd581e3d3d6bd4

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

LOG: [Concepts] Fix name-type conflict compilation issues

D50360 caused some platforms to not compile due to a parameter with the name of 
a type.

Rename the parameter.

Added: 


Modified: 
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index 178cb1b661c7..065a82b9298a 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -6612,7 +6612,7 @@ void Parser::ParseFunctionDeclaratorIdentifierList(
 /// [C++11] attribute-specifier-seq parameter-declaration
 ///
 void Parser::ParseParameterDeclarationClause(
-   DeclaratorContext DeclaratorContext,
+   DeclaratorContext DeclaratorCtx,
ParsedAttributes &FirstArgAttrs,
SmallVectorImpl &ParamInfo,
SourceLocation &EllipsisLoc) {
@@ -6661,9 +6661,9 @@ void Parser::ParseParameterDeclarationClause(
 // "LambdaExprParameterContext", because we must accept either
 // 'declarator' or 'abstract-declarator' here.
 Declarator ParmDeclarator(
-DS, DeclaratorContext == DeclaratorContext::RequiresExprContext
+DS, DeclaratorCtx == DeclaratorContext::RequiresExprContext
 ? DeclaratorContext::RequiresExprContext
-: DeclaratorContext == DeclaratorContext::LambdaExprContext
+: DeclaratorCtx == DeclaratorContext::LambdaExprContext
   ? DeclaratorContext::LambdaExprParameterContext
   : DeclaratorContext::PrototypeContext);
 ParseDeclarator(ParmDeclarator);
@@ -6719,7 +6719,7 @@ void Parser::ParseParameterDeclarationClause(
 SourceLocation EqualLoc = Tok.getLocation();
 
 // Parse the default argument
-if (DeclaratorContext == DeclaratorContext::MemberContext) {
+if (DeclaratorCtx == DeclaratorContext::MemberContext) {
   // If we're inside a class definition, cache the tokens
   // corresponding to the default argument. We'll actually parse
   // them when we see the end of the class definition.



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

[PATCH] D50360: [Concepts] Requires Expressions

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Doesn't this still break check-clang everywhere? See e.g. 
http://45.33.8.238/linux/7860/step_7.txt


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D50360



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

[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

[Wenlei He via Phabricator via cfe-commits]

wenlei added a comment.

@aganea, @hans This patch broke response file expansion for preprocessor via 
`-Wp` - all our internal builds failed with this patch because we invoke clang 
with response file passed to preprocessor, e.g. `clang++ ... -Wp,@pp.rsp 
@cc.rsp`. Looks like we can't just call `ExecuteCC1Tool` directly, because 
response file expansion happens in `main`, so with this patch, `-Wp,@pp.rsp` 
won't be expanded properly.

repo:

  CLANG_SPAWN_CC1=0  clang++ -c  -Wp,@a.rsp  @a.rsp test.cpp
  
  error: error reading '@rr.rsp'
  1 error generated.

and it works with `CLANG_SPAWN_CC1=1`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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