[PATCH] D68682: Clang-tidy fix removals removing all non-blank text from a line should remove the line

[Jonathan Meier via Phabricator via cfe-commits]

jonathanmeier added a comment.

In D68682#1702025 , @poelmanc wrote:

> In D68682#1700908 , @Eugene.Zelenko 
> wrote:
>
> > You may be interested to also look on PR43583 related to 
> > readability-redundant-member-init.
>
>
> Thanks Eugene, I'm having trouble finding that. 
> https://reviews.llvm.org/D43583 seems related to MIPS instructions rather 
> than readability-redundant-member-init. Could you please post a link? Thanks.


PRs are bug reports. You can access them like this: https://llvm.org/PR43583


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68682



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

[PATCH] D40221: [clang-format] Parse blocks in braced lists

[Manuel Klimek via Phabricator via cfe-commits]

klimek added inline comments.



Comment at: lib/Format/UnwrappedLineParser.cpp:1324
+  nextToken();
+  if (!Style.isCpp()) {
+// Blocks are only supported in C++ and Objective-C.

benhamilton wrote:
> Style: Remove curly braces for one-line if blocks.
> 
Isn't this only an Obj-C/Obj-C++ thing?
If it is, I'd call it tryToParseObjCBlockLiteral.


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

https://reviews.llvm.org/D40221



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

[PATCH] D68767: [clang-format] NFC - Move functionality into functions to help code structure

[Owen Pan via Phabricator via cfe-commits]

owenpan added inline comments.



Comment at: clang/tools/clang-format/ClangFormat.cpp:245
+// Returns an invalid BOM
+static const char *hasInValidBOM(StringRef BufStr) {
+  // Check to see if the buffer has a UTF Byte Order Mark (BOM).

owenpan wrote:
> This code was copied from `clang/lib/Basic/SourceManager.cpp`. I suggest that 
> you move this function to there and export it through 
> `clang/include/clang/Basic/SourceManager.h`.
May I suggest `getInvalidBOM(const StringRef)` for the function name and 
parameter type?



Comment at: clang/tools/clang-format/ClangFormat.cpp:245-266
+static const char *hasInValidBOM(StringRef BufStr) {
+  // Check to see if the buffer has a UTF Byte Order Mark (BOM).
+  // We only support UTF-8 with and without a BOM right now.  See
+  // https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding
+  // for more information.
+  const char *InvalidBOM =
+  llvm::StringSwitch(BufStr)

This code was copied from `clang/lib/Basic/SourceManager.cpp`. I suggest that 
you move this function to there and export it through 
`clang/include/clang/Basic/SourceManager.h`.



Comment at: clang/tools/clang-format/ClangFormat.cpp:381
+// Dump the configuration.
+static unsigned dumpConfig(StringRef AssumeFileName) {
+  StringRef FileName;

`AssumeFileName` is a file-scope global, so the file-scope function doesn't 
need to make it a parameter? Also, a `bool` or `int` may be a better return 
type than `unsigned`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D68767



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

r374527 - Insert module constructors in a module pass

[Vitaly Buka via cfe-commits]

Author: vitalybuka
Date: Fri Oct 11 01:47:03 2019
New Revision: 374527

URL: http://llvm.org/viewvc/llvm-project?rev=374527&view=rev
Log:
Insert module constructors in a module pass

Summary:
If we insert them from function pass some analysis may be missing or invalid.
Fixes PR42877.

Reviewers: eugenis, leonardchan

Reviewed By: leonardchan

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 374481
Signed-off-by: Vitaly Buka 

Added:
cfe/trunk/test/CodeGen/sanitizer-module-constructor.c
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=374527&r1=374526&r2=374527&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Fri Oct 11 01:47:03 2019
@@ -974,6 +974,7 @@ static void addSanitizersAtO0(ModulePass
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
+MPM.addPass(MemorySanitizerPass({}));
 MPM.addPass(createModuleToFunctionPassAdaptor(MemorySanitizerPass({})));
   }
 
@@ -983,6 +984,7 @@ static void addSanitizersAtO0(ModulePass
   }
 
   if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
+MPM.addPass(ThreadSanitizerPass());
 MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
   }
 }
@@ -1162,16 +1164,23 @@ void EmitAssemblyHelper::EmitAssemblyWit
 [](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) 
{
   FPM.addPass(BoundsCheckingPass());
 });
-  if (LangOpts.Sanitize.has(SanitizerKind::Memory))
+  if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
+PB.registerPipelineStartEPCallback([](ModulePassManager &MPM) {
+  MPM.addPass(MemorySanitizerPass({}));
+});
 PB.registerOptimizerLastEPCallback(
 [](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) 
{
   FPM.addPass(MemorySanitizerPass({}));
 });
-  if (LangOpts.Sanitize.has(SanitizerKind::Thread))
+  }
+  if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
+PB.registerPipelineStartEPCallback(
+[](ModulePassManager &MPM) { MPM.addPass(ThreadSanitizerPass()); 
});
 PB.registerOptimizerLastEPCallback(
 [](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level) 
{
   FPM.addPass(ThreadSanitizerPass());
 });
+  }
   if (LangOpts.Sanitize.has(SanitizerKind::Address)) {
 PB.registerPipelineStartEPCallback([&](ModulePassManager &MPM) {
   MPM.addPass(

Added: cfe/trunk/test/CodeGen/sanitizer-module-constructor.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sanitizer-module-constructor.c?rev=374527&view=auto
==
--- cfe/trunk/test/CodeGen/sanitizer-module-constructor.c (added)
+++ cfe/trunk/test/CodeGen/sanitizer-module-constructor.c Fri Oct 11 01:47:03 
2019
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsanitize=address -emit-llvm -O3 
-fdebug-pass-manager -fexperimental-new-pass-manager -o - %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsanitize=thread -emit-llvm -O3 
-fdebug-pass-manager -fexperimental-new-pass-manager -o - %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsanitize=memory -emit-llvm -O3 
-fdebug-pass-manager -fexperimental-new-pass-manager -o - %s 2>&1 | FileCheck %s
+
+// This is regression test for PR42877
+
+typedef struct a *b;
+struct a {
+  int c;
+};
+int d;
+b e;
+static void f(b g) {
+  for (d = g->c;;)
+;
+}
+void h() { f(e); }
+
+// CHECK: Running pass: {{.*}}SanitizerPass on 
{{.*}}sanitizer-module-constructor.c
+// CHECK-NOT: Running pass: LoopSimplifyPass on {{.*}}san.module_ctor
+// CHECK: Running analysis: DominatorTreeAnalysis on {{.*}}san.module_ctor
+// CHECK: Running pass: LoopSimplifyPass on {{.*}}san.module_ctor


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

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

[Anna Welker via Phabricator via cfe-commits]

anwel created this revision.
anwel added reviewers: carwil, amilendra_arm, phosek, michaelplatings, efriedma.
anwel added projects: LLVM, clang.
Herald added subscribers: llvm-commits, cfe-commits, hiraditya, kristof.beyls.

This patch combines two earlier patches aiming at providing the same support 
(https://reviews.llvm.org/D56003 for clang, https://reviews.llvm.org/D56005 for 
LLVM). It enables reservation of allocatable registers via command line 
options, which in turn allows them to be used as global named register 
variables. They will then not be used by the register allocator nor spilled to 
the stack.

More information is available in the original RFC: 
http://lists.llvm.org/pipermail/llvm-dev/2018-December/128706.html

Changes from the previous patches include:

- adding a constraint to specify -ffixed-rN if rN is used as named register 
variable.
- upgrading the frame-pointer warning to an error and throwing an error in 
LLVM, as well as clang.*

Additionally this patch now only supports r6-r11. r4 and r5 are excluded from 
this patch as r4 is used as hard-coded scratch register in various parts of the 
ARM backend. r4 also appears to be used as an input register for a Windows asm 
routine (__chkstk). Similarly, the ABI of the segmented stack prologue for 
Android and Linux seems to use r4 and r5 as input registers. A separate patch 
could follow to add the support for r4 and/or r5, such that the whole range of 
allocatable registers (r4-r11) is available.

As before it should be noted that this also changes the behaviour of the old 
-ffixed-r9 option. This option will now prevent the register from being spilled 
to the stack.

*This was originally a warning, but we don't seem to have the necessary 
information to determine frame-pointer usage in the given context. Any insight 
here would be welcome.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D68862

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Driver/arm-reserved-reg-options.c
  clang/test/Sema/arm-global-regs.c
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMAsmPrinter.cpp
  llvm/lib/Target/ARM/ARMBaseRegisterInfo.cpp
  llvm/lib/Target/ARM/ARMFrameLowering.cpp
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMSubtarget.cpp
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/lib/Target/ARM/ARMTargetTransformInfo.h
  llvm/test/CodeGen/ARM/reg-alloc-fixed-r6-vla.ll
  llvm/test/CodeGen/ARM/reg-alloc-with-fixed-reg-r6-modified.ll
  llvm/test/CodeGen/ARM/reg-alloc-with-fixed-reg-r6.ll
  llvm/test/CodeGen/ARM/reg-alloc-wout-fixed-regs.ll
  llvm/test/CodeGen/Thumb/callee_save_reserved.ll
  llvm/test/Feature/reserve_global_reg.ll

Index: llvm/test/Feature/reserve_global_reg.ll
===
--- /dev/null
+++ llvm/test/Feature/reserve_global_reg.ll
@@ -0,0 +1,29 @@
+; RUN: not llc < %s -mtriple=thumbv7-apple-darwin -mattr=+reserve-r7 -o - 2>&1 | FileCheck -check-prefix=CHECK-RESERVE-FP7 %s
+; RUN: not llc < %s -mtriple=armv7-windows-msvc -mattr=+reserve-r11 -o - 2>&1 | FileCheck -check-prefix=CHECK-RESERVE-FP11 %s
+; RUN: not llc < %s -mtriple=thumbv7-windows -mattr=+reserve-r11 -o - 2>&1 | FileCheck -check-prefix=CHECK-RESERVE-FP11-2 %s
+
+; int test(int a, int b, int c) {
+;   return a+b+c;
+; }
+
+; Function Attrs: noinline nounwind optnone
+define hidden i32 @_Z4testiii(i32 %a, i32 %b, i32 %c) #0 {
+entry:
+  %a.addr = alloca i32, align 4
+  %b.addr = alloca i32, align 4
+  %c.addr = alloca i32, align 4
+  store i32 %a, i32* %a.addr, align 4
+  store i32 %b, i32* %b.addr, align 4
+  store i32 %c, i32* %c.addr, align 4
+  %0 = load i32, i32* %a.addr, align 4
+  %1 = load i32, i32* %b.addr, align 4
+  %add = add nsw i32 %0, %1
+  %2 = load i32, i32* %c.addr, align 4
+  %add1 = add nsw i32 %add, %2
+  ret i32 %add1
+}
+
+; CHECK-RESERVE-FP7: Register r7 has been specified but is used as a frame pointer on this target.
+; CHECK-RESERVE-FP11: Register r11 has been specified but is used as a frame pointer on this target.
+; CHECK-RESERVE-FP11-2: Register r11 has been specified but is used as a frame pointer on this target.
+
Index: llvm/test/CodeGen/Thumb/callee_save_reserved.ll
===
--- /dev/null
+++ llvm/test/CodeGen/Thumb/callee_save_reserved.ll
@@ -0,0 +1,15 @@
+; RUN: llc < %s -mtriple=thumbv6m-none-eabi -verify-machineinstrs -frame-pointer=none -mattr=+reserve-r6,+reserve-r8 \
+; RUN: -asm-verbose=false | FileCheck --check-prefix=CHECK-INVALID %s
+
+; Reserved low registers should not be used to correct reg d

[PATCH] D56003: [RFC] [CFE] Allocatable Global Register Variables for ARM

[Carey Williams via Phabricator via cfe-commits]

carwil abandoned this revision.
carwil added a comment.

Superseded by https://reviews.llvm.org/D68862.


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

https://reviews.llvm.org/D56003



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

[PATCH] D61663: [clang-format] Fix a JavaScript import order bug.

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Are you waiting for someone to land this?


Repository:
  rC Clang

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

https://reviews.llvm.org/D61663



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

[PATCH] D68074: [clang-tidy] Add readability-make-member-function-const

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/readability-make-member-function-const.rst:10
+The check conservatively tries to preserve logical costness in favor of
+physical costness. The only operations on ``this`` that this check considers
+to preserve logical constness are

mgehre wrote:
> gribozavr wrote:
> > Sorry, it is unclear to me what it means: "the check [...] tries to do X in 
> > favor of Y"
> > 
> > Also unclear what logical/physical constness mean.
> I guess it should read `tries to preserve logical constness instead of 
> physical constness.`
> 
> logical/physical constness is from here: 
> https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-state
> Are there more common terms for this or should I link or copy the explanation?
I think you should add a link, and change "in favor of" to "not" -- "This check 
tries to annotate methods according to logical constness (not physical 
constness)."



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/readability-make-member-function-const.rst:49
+}
+  };
+

It is not enough to just show this example. Please explain why calling private 
member functions is not considered to preserve logical constness.



Comment at: 
clang-tools-extra/test/clang-tidy/readability-make-member-function-const.cpp:311
+  // This member function must stay non-const, even though
+  // it only calls other private const member functions.
+  int &get() {

mgehre wrote:
> gribozavr wrote:
> > Is it because the const version already exists? Then that should be the 
> > rule (not calling a private helper function).
> Let me try to explain. If it make senses what I say, I'll then update the 
> documentation.
> The terms logical const and physical const are from here: 
> https://isocpp.org/wiki/faq/const-correctness#logical-vs-physical-const
> 
> The const version is just here to illustrate how this pattern works. The 
> important fact is that a private member function is not part of the public 
> interface of the class. 
> I.e. users of the class were not able to call `data()` with a const object 
> before (even though data() is declared as const) because `data()` is at the 
> same time `private`.
> We thus cannot assume that the `constness` of `data()` reflects the interface 
> contract the the author of the class had in mind.
> 
> Here, e.g. the author clearly wanted to only give access to a non-const 
> `int&` to users that possses a non-const version of *this.
> 
> The rule "don't make the method const if it already has a const overload" 
> seems appealing, but its neither sufficient (we still need the rule we 
> currently have about private data)
> nor is is necessary once we have all other rules. I have successfully run 
> this check on the LLVM code base, and there were not issues with clashing 
> overloads after fix-its. (It found multiple hundred of valid fixits)
> 
> The second example how to see the issue with private data members is the 
> Pimpl idiom:
> ```
> class S {
>   struct Impl {
>int d;
>   };
>   Impl *I;
> public:
>   void set(int v) {
> I->d = v;
>   }
> };
> ```
> A human would not make the `set()` function const because we consider the 
> value of `Impl->d` to be part of the value of the instance. Technically, we 
> can make `set()` const because
> it does not modify `I`. But that is not the author's intention. I try to have 
> no false-positives in this check,
> so I conservatively assume that an access to a private member that is not of 
> builtin type does not preserve logical constness.
> Note that the same happens when the type of I is changed to 
> `unique_ptr`. `unique_ptr::operator->` is a const member function but 
> returns a reference to non-const `Impl`,
> and so does not preserve logical constness
> 
> We might be able to extend the check by tracking pointer use, but that's 
> pretty difficult.
> The only extension I did is for builtin types, i.e.`int`. When we read an int 
> (in the AST that's an LvalueToRvalue conversion), then there is no way that 
> this can eventually lead to a modification
> of the state of the int, so it preserves logical constness.
> 
> Const use of public members is also ok because the user of the class already 
> has access to them. We are not widening the contract by making a member 
> function const that
> (only) contains const use of public members.
> I.e. users of the class were not able to call data() with a const object 
> before (even though data() is declared as const) because data() is at the 
> same time private.

Agreed.

> We thus cannot assume that the constness of data() reflects the interface 
> contract the the author of the class had in mind.

I don't see how this follows. Many other, public, aspects of the class might 
also not reflect the interface that the author had in mind -- because people 
write bugs, because C++ is complex 

[PATCH] D68554: [clang-format] Proposal for clang-format to give compiler style warnings

[Manuel Klimek via Phabricator via cfe-commits]

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

lg




Comment at: clang/tools/clang-format/ClangFormat.cpp:293
 
+// Returns an invalid BOM
+static const char *hasInValidBOM(StringRef BufStr) {

I'd name this getInvalidBOM and make the comment
// If BufStr has an invalid BOM, returns the BOM name; otherwise, returns 
nullptr.


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

https://reviews.llvm.org/D68554



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

[PATCH] D16066: [clang-format] Add BeforeWhileInDoWhile BraceWrapping option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

This change need unit tests


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

https://reviews.llvm.org/D16066



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

[PATCH] D67901: [clangd] Improve semantic highlighting in dependent contexts (fixes #154)

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

In D67901#1704639 , @nridge wrote:

> I like how we went from using heuristics, to not using heuristics, to using 
> heuristics again :)
>
> But admittedly, the new heuristics are more accurate because they're based on 
> phase 1 lookup results rather than just syntax, so I'm happy with the outcome!


I also liked the irony of it :-)

Mostly LG, just NITs from my side. Happy to LGTM when they're addressed.




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:105
+  for (NamedDecl *Decl : Decls) {
+if (TemplateDecl *TD = dyn_cast(Decl)) {
+  Decl = TD->getTemplatedDecl();

Could we do this in `kindForDecl` instead?
I suspect we want to be consistent in other cases this might potentially called 
in.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:108
+}
+llvm::Optional Kind = kindForDecl(Decl);
+if (!Kind)

Maybe simplify the rest of the loop body to the following code?
```
auto Kind = ...;
if (!Kind || Result && Result != Kind)
  return llvm::None;
Result = Kind;
```

If you want to have fewer assignments, we could also do:
```
if (!Result) Result = Kind;
```
at the end. But I'd just keep it a tad simpler instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67901



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

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

Bit of a drive-by comment, but I can't say I am big fan of all the string 
matching on the register names. Not sure if this is a fair comment, because I 
haven't looked closely at it yet, but could we use more the `ARM::R[0-9]` 
values more? Perhaps that's difficult from the Clang parts?




Comment at: clang/lib/Basic/Targets/ARM.cpp:902
+  std::vector &Features = getTargetOpts().Features;
+  std::string SearchFeature = "+reserve-" + RegName.str();
+  for (std::string &Feature : Features) {

I was pointed at something similar myself recently, but if I am not mistaken 
then I think this is a use-after-free:

   "+reserve-" + RegName.str()

this will allocate a temp `std::string` that `SearchFeature` points to, which 
then gets released, and `SearchFeature` is still pointing at it.



Comment at: llvm/test/CodeGen/ARM/reg-alloc-with-fixed-reg-r6-modified.ll:15
+; r6 = 10;
+; unsigned int result = i + j + k + l +m + n + o + p;
+; }

nit: `+m` -> ` + m`



Comment at: llvm/test/CodeGen/ARM/reg-alloc-with-fixed-reg-r6.ll:13
+; {
+; unsigned int result = i + j + k + l +m + n + o + p;
+; }

same nit



Comment at: llvm/test/CodeGen/ARM/reg-alloc-wout-fixed-regs.ll:3
+;
+; Equivalent C source code
+; void bar(unsigned int i,

As all these tests (this file and the ones above) are the same, the "equivalent 
C source code" is the same, perhaps move all these cases into 1 file.



Comment at: llvm/test/CodeGen/ARM/reg-alloc-wout-fixed-regs.ll:13
+; {
+; unsigned int result = i + j + k + l +m + n + o + p;
+; }

same nit here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68862



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

[PATCH] D66049: [analyzer] PR41729: Fix some false positives and improve strlcat and strlcpy modeling

[Daniel Krupp via Phabricator via cfe-commits]

dkrupp added a comment.

Thanks for the reviews!
Could you pls commit this for me?


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

https://reviews.llvm.org/D66049



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

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun updated this revision to Diff 224557.
vladimir.plyashkun added a comment.

Provide additional option to preserve current inspection behaviour


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694

Files:
  clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
  clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
  clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp


Index: 
clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s hicpp-signed-bitwise %t -- \
+// RUN:   -config="{CheckOptions: [{key: 
hicpp-signed-bitwise.IgnorePositiveIntegerLiterals, value: 1 }]}" \
+// RUN: -- -std=c++11
+
+void examples() {
+  unsigned UValue = 40u;
+  unsigned URes;
+  
+  URes = UValue & 1u; //Ok
+  URes = UValue & -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use of a signed integer operand 
with a binary bitwise operator
+  
+  int IResult;
+  IResult = 10 & 2; //Ok
+  IResult = 3 << -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator
+  
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator
+  IResult = ~0; //Ok
+}
+
+enum EnumConstruction {
+  one = 1,
+  two = 2,
+  test1 = 1 << 12, //Ok
+  test2 = one << two,
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: use of a signed integer operand 
with a binary bitwise operator
+  test3 = 1u << 12, //Ok
+};
Index: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
===
--- clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
+++ clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
@@ -22,10 +22,13 @@
 /// http://clang.llvm.org/extra/clang-tidy/checks/hicpp-signed-bitwise.html
 class SignedBitwiseCheck : public ClangTidyCheck {
 public:
-  SignedBitwiseCheck(StringRef Name, ClangTidyContext *Context)
-  : ClangTidyCheck(Name, Context) {}
+  SignedBitwiseCheck(StringRef Name, ClangTidyContext *Context);
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+  void storeOptions(ClangTidyOptions::OptionMap &Options) override;
+
+private:
+  bool IgnorePositiveIntegerLiterals;
 };
 
 } // namespace hicpp
Index: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
===
--- clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
+++ clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
@@ -17,9 +17,24 @@
 namespace tidy {
 namespace hicpp {
 
+SignedBitwiseCheck::SignedBitwiseCheck(StringRef Name,
+   ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.getLocalOrGlobal("IgnorePositiveIntegerLiterals", false)) {}
+
+void SignedBitwiseCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
+  Options.store(Opts, "IgnorePositiveIntegerLiterals",
+IgnorePositiveIntegerLiterals);
+}
+
 void SignedBitwiseCheck::registerMatchers(MatchFinder *Finder) {
   const auto SignedIntegerOperand =
-  
expr(ignoringImpCasts(hasType(isSignedInteger(.bind("signed-operand");
+  (IgnorePositiveIntegerLiterals
+   ? expr(ignoringImpCasts(hasType(isSignedInteger())),
+  unless(integerLiteral()))
+   : expr(ignoringImpCasts(hasType(isSignedInteger()
+  .bind("signed-operand");
 
   // The standard [bitmask.types] allows some integral types to be implemented
   // as signed types. Exclude these types from diagnosing for bitwise or(|) and


Index: clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s hicpp-signed-bitwise %t -- \
+// RUN:   -config="{CheckOptions: [{key: hicpp-signed-bitwise.IgnorePositiveIntegerLiterals, value: 1 }]}" \
+// RUN: -- -std=c++11
+
+void examples() {
+  unsigned UValue = 40u;
+  unsigned URes;
+  
+  URes = UValue & 1u; //Ok
+  URes = UValue & -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use of a signed integer operand with a binary bitwise operator
+  
+  int IResult;
+  IResult = 10 & 2; //Ok
+  IResult = 3 << -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand with a binary bitwise operator
+  
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun added a comment.

@aaron.ballman
@JonasToth
Thanks, i agree too! I've prepared new revision with additional option to 
preserve old inspection behaviour.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp:23-24
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.getLocalOrGlobal("IgnorePositiveIntegerLiterals", false)) {}
+

i'm not sure this should look for a global option with such name?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D67550: [AArch64][SVE] Implement unpack intrinsics

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin updated this revision to Diff 224558.
kmclaughlin added a comment.

Removed unused //SDPatternOperator op// from sve_int_perm_unpk class


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

https://reviews.llvm.org/D67550

Files:
  include/llvm/IR/IntrinsicsAArch64.td
  lib/Target/AArch64/AArch64ISelLowering.cpp
  lib/Target/AArch64/AArch64ISelLowering.h
  lib/Target/AArch64/AArch64InstrInfo.td
  lib/Target/AArch64/AArch64SVEInstrInfo.td
  lib/Target/AArch64/SVEInstrFormats.td
  test/CodeGen/AArch64/sve-intrinsics-perm-select.ll

Index: test/CodeGen/AArch64/sve-intrinsics-perm-select.ll
===
--- /dev/null
+++ test/CodeGen/AArch64/sve-intrinsics-perm-select.ll
@@ -0,0 +1,129 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; SUNPKHI
+;
+
+define  @sunpkhi_i16( %a) {
+; CHECK-LABEL: sunpkhi_i16
+; CHECK: sunpkhi z0.h, z0.b
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpkhi.nxv8i16( %a)
+  ret  %res
+}
+
+define  @sunpkhi_i32( %a) {
+; CHECK-LABEL: sunpkhi_i32
+; CHECK: sunpkhi z0.s, z0.h
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpkhi.nxv4i32( %a)
+  ret  %res
+}
+
+define  @sunpkhi_i64( %a) {
+; CHECK-LABEL:  sunpkhi_i64
+; CHECK: sunpkhi z0.d, z0.s
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpkhi.nxv2i64( %a)
+  ret  %res
+}
+
+;
+; SUNPKLO
+;
+
+define  @sunpklo_i16( %a) {
+; CHECK-LABEL: sunpklo_i16
+; CHECK: sunpklo z0.h, z0.b
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpklo.nxv8i16( %a)
+  ret  %res
+}
+
+define  @sunpklo_i32( %a) {
+; CHECK-LABEL: sunpklo_i32
+; CHECK: sunpklo z0.s, z0.h
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpklo.nxv4i32( %a)
+  ret  %res
+}
+
+define  @sunpklo_i64( %a) {
+; CHECK-LABEL:  sunpklo_i64
+; CHECK: sunpklo z0.d, z0.s
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.sunpklo.nxv2i64( %a)
+  ret  %res
+}
+
+;
+; UUNPKHI
+;
+
+define  @uunpkhi_i16( %a) {
+; CHECK-LABEL: uunpkhi_i16
+; CHECK: uunpkhi z0.h, z0.b
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpkhi.nxv8i16( %a)
+  ret  %res
+}
+
+define  @uunpkhi_i32( %a) {
+; CHECK-LABEL: uunpkhi_i32
+; CHECK: uunpkhi z0.s, z0.h
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpkhi.nxv4i32( %a)
+  ret  %res
+}
+
+define  @uunpkhi_i64( %a) {
+; CHECK-LABEL:  uunpkhi_i64
+; CHECK: uunpkhi z0.d, z0.s
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpkhi.nxv2i64( %a)
+  ret  %res
+}
+
+;
+; UUNPKLO
+;
+
+define  @uunpklo_i16( %a) {
+; CHECK-LABEL: uunpklo_i16
+; CHECK: uunpklo z0.h, z0.b
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpklo.nxv8i16( %a)
+  ret  %res
+}
+
+define  @uunpklo_i32( %a) {
+; CHECK-LABEL: uunpklo_i32
+; CHECK: uunpklo z0.s, z0.h
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpklo.nxv4i32( %a)
+  ret  %res
+}
+
+define  @uunpklo_i64( %a) {
+; CHECK-LABEL:  uunpklo_i64
+; CHECK: uunpklo z0.d, z0.s
+; CHECK-NEXT: ret
+  %res = call  @llvm.aarch64.sve.uunpklo.nxv2i64( %a)
+  ret  %res
+}
+
+declare  @llvm.aarch64.sve.sunpkhi.nxv8i16()
+declare  @llvm.aarch64.sve.sunpkhi.nxv4i32()
+declare  @llvm.aarch64.sve.sunpkhi.nxv2i64()
+
+declare  @llvm.aarch64.sve.sunpklo.nxv8i16()
+declare  @llvm.aarch64.sve.sunpklo.nxv4i32()
+declare  @llvm.aarch64.sve.sunpklo.nxv2i64()
+
+declare  @llvm.aarch64.sve.uunpkhi.nxv8i16()
+declare  @llvm.aarch64.sve.uunpkhi.nxv4i32()
+declare  @llvm.aarch64.sve.uunpkhi.nxv2i64()
+
+declare  @llvm.aarch64.sve.uunpklo.nxv8i16()
+declare  @llvm.aarch64.sve.uunpklo.nxv4i32()
+declare  @llvm.aarch64.sve.uunpklo.nxv2i64()
Index: lib/Target/AArch64/SVEInstrFormats.td
===
--- lib/Target/AArch64/SVEInstrFormats.td
+++ lib/Target/AArch64/SVEInstrFormats.td
@@ -848,10 +848,14 @@
   let Inst{4-0}   = Zd;
 }
 
-multiclass sve_int_perm_unpk opc, string asm> {
+multiclass sve_int_perm_unpk opc, string asm, SDPatternOperator op> {
   def _H : sve_int_perm_unpk<0b01, opc, asm, ZPR16, ZPR8>;
   def _S : sve_int_perm_unpk<0b10, opc, asm, ZPR32, ZPR16>;
   def _D : sve_int_perm_unpk<0b11, opc, asm, ZPR64, ZPR32>;
+
+  def : SVE_1_Op_Pat(NAME # _H)>;
+  def : SVE_1_Op_Pat(NAME # _S)>;
+  def : SVE_1_Op_Pat(NAME # _D)>;
 }
 
 class sve_int_perm_insrs sz8_64, string asm, ZPRRegOp zprty,
Index: lib/Target/AArch64/AArch64SVEInstrInfo.td
===
--- lib/Target/AArch64/AArch64SVEInstrInfo.td
+++ lib/Target/AArch64/AArch64SVEInstrInfo.td
@@ -211,10 +211,10 @@
   defm REV_PP : sve_int_perm_reverse_p<"rev">;
   defm REV_ZZ : sve_int_perm_reverse_z<"rev">;
 
-  defm SUNPKLO_ZZ : sve_int_perm_unpk<0b00, "sunpklo">;
-  defm SUNPKHI_ZZ : sve_int_perm_unpk<0b01, "sunpkhi">;
-  defm UUNPKLO_ZZ : sve_int_perm_unpk<0b10, "uunpklo">;
-  defm UUNPKHI_ZZ : sve_int_perm_unpk<0b11, "uunpkhi">;
+  defm SUNPKLO_ZZ : sve_int_perm_unpk<0b00, "sunpklo", AArch64sunpklo>;
+  defm SUNPKHI_ZZ : 

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

The new switch needs documentation as well, and maybe even a note in the 
release notes (as it is publicly discussed as issue?).
Otherwise I am fine with the changes!




Comment at: 
clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp:19
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator

Could you please add `URes << 1` as well? I believe that was problematic in the 
stack-overflow-question, wasn't it?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

Re: r374133 - [c++20] Implement most of P1152R4.

[David Zarzycki via cfe-commits]

Hi Richard,

This breaks libcxx and libcxxabi my local stage two build bot (Fedora 31 
x86_64). Is this expected? Can we revert this?

FAIL: libc++ :: std/utilities/meta/meta.rel/is_invocable.pass.cpp (55505 of 
58603)
 TEST 'libc++ :: 
std/utilities/meta/meta.rel/is_invocable.pass.cpp' FAILED 
Command: ['/p/tllvm/bin/clang++', '-o', 
'/tmp/_update_lc/t/projects/libcxx/test/std/utilities/meta/meta.rel/Output/is_invocable.pass.cpp.o',
 '-x', 'c++', 
'/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.rel/is_invocable.pass.cpp',
 '-c', '-v', '-ftemplate-depth=270', '-Werror=thread-safety', '-std=c++2a', 
'-include', '/home/dave/s/lp/libcxx/test/support/nasty_macros.h', 
'-nostdinc++', '-I/home/dave/s/lp/libcxx/include', 
'-I/tmp/_update_lc/t/projects/libcxx/include/c++build', 
'-D__STDC_FORMAT_MACROS', '-D__STDC_LIMIT_MACROS', '-D__STDC_CONSTANT_MACROS', 
'-I/home/dave/s/lp/libcxx/test/support', 
'-DLIBCXX_FILESYSTEM_STATIC_TEST_ROOT="/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env"',
 
'-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT="/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env"',
 '-DLIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER="/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py"', 
'-D_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER', '-Wall', '-Wextra', '-Werror', 
'-Wuser-defined-warnings', '-Wshadow', '-Wno-unused-command-line-argument', 
'-Wno-attributes', '-Wno-pessimizing-move', '-Wno-c++11-extensions', 
'-Wno-user-defined-literals', '-Wno-noexcept-type', '-Wsign-compare', 
'-Wunused-variable', '-Wunused-parameter', '-Wunreachable-code', '-c']
Exit Code: 1
Standard Error:
--
clang version 10.0.0 (/home/dave/s/lp/clang 
0746aafd89754a2ae9992c4d6394e3b4f3623b1d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /p/tllvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
 "/p/tllvm/bin/clang-10" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj 
-mrelax-all -disable-free -disable-llvm-verifier -discard-value-names 
-main-file-name is_invocable.pass.cpp -mrelocation-model static -mthread-model 
posix -mframe-pointer=all -fmath-errno -masm-verbose -mconstructor-aliases 
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info 
-debugger-tuning=gdb -v -nostdinc++ -resource-dir /p/tllvm/lib64/clang/10.0.0 
-include /home/dave/s/lp/libcxx/test/support/nasty_macros.h -I 
/home/dave/s/lp/libcxx/include -I 
/tmp/_update_lc/t/projects/libcxx/include/c++build -D __STDC_FORMAT_MACROS -D 
__STDC_LIMIT_MACROS -D __STDC_CONSTANT_MACROS -I 
/home/dave/s/lp/libcxx/test/support -D 
"LIBCXX_FILESYSTEM_STATIC_TEST_ROOT=\"/home/dave/s/lp/libcxx/test/std/input.output/filesystems/Inputs/static_test_env\""
 -D 
"LIBCXX_FILESYSTEM_DYNAMIC_TEST_ROOT=\"/tmp/_update_lc/t/projects/libcxx/test/filesystem/Output/dynamic_env\""
 -D "LIBCXX_FILESYSTEM_DYNAMIC_TEST_HELPER=\"/usr/bin/python 
/home/dave/s/lp/libcxx/test/support/filesystem_dynamic_test_helper.py\"" -D 
_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER -internal-isystem /usr/local/include 
-internal-isystem /p/tllvm/lib64/clang/10.0.0/include -internal-externc-isystem 
/include -internal-externc-isystem /usr/include -Werror=thread-safety -Wall 
-Wextra -Werror -Wuser-defined-warnings -Wshadow 
-Wno-unused-command-line-argument -Wno-attributes -Wno-pessimizing-move 
-Wno-c++11-extensions -Wno-user-defined-literals -Wno-noexcept-type 
-Wsign-compare -Wunused-variable -Wunused-parameter -Wunreachable-code 
-std=c++2a -fdeprecated-macro -fdebug-compilation-dir 
/tmp/_update_lc/t/projects/libcxx/test/std/utilities/meta/meta.rel 
-ftemplate-depth 270 -ferror-limit 19 -fmessage-length 0 -fno-implicit-modules 
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option 
-faddrsig -o 
/tmp/_update_lc/t/projects/libcxx/test/std/utilities/meta/meta.rel/Output/is_invocable.pass.cpp.o
 -x c++ 
/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.rel/is_invocable.pass.cpp
clang -cc1 version 10.0.0 based upon LLVM 10.0.0svn default target 
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/dave/s/lp/libcxx/include
 /tmp/_update_lc/t/projects/libcxx/include/c++build
 /home/dave/s/lp/libcxx/test/support
 /usr/local/include
 /p/tllvm/lib64/clang/10.0.0/include
 /usr/include
End of search list.
In file included from 
/home/dave/s/lp/libcxx/test/std/utilities/meta/meta.rel/is_invocable.pass.cpp:21:
/home/dave/s/lp/libcxx/include/type_traits:1123:22: error: volatile-qualified 
return type 'volatile void' is deprecated [-Werror,-Wdeprecated-volatile]
template  _Tp   __declval(long);
 ^
/home/dave/s/lp/libcxx/include/type_traits:3640:31: note: in instantiation of 
template class 'std::__1::_

[PATCH] D67550: [AArch64][SVE] Implement unpack intrinsics

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin marked 2 inline comments as done.
kmclaughlin added inline comments.



Comment at: lib/Target/AArch64/SVEInstrFormats.td:836
 class sve_int_perm_unpk sz16_64, bits<2> opc, string asm,
-ZPRRegOp zprty1, ZPRRegOp zprty2>
+ZPRRegOp zprty1, ZPRRegOp zprty2, SDPatternOperator op>
 : I<(outs zprty1:$Zd), (ins zprty2:$Zn),

greened wrote:
> Where is `op` used?  I assume that comes later but it would help to 
> understand where this is going.
Thanks for pointing this out, op isn't actually used here!


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

https://reviews.llvm.org/D67550



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

[PATCH] D68845: Don't emit unwanted constructor calls in co_return statements

[Aaron Puchert via Phabricator via cfe-commits]

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

In D51741#1702038 , @Quuxplusone wrote:

> Both of these should first do overload resolution for one parameter of type 
> `MoveOnly&&`, and then, only if that overload resolution fails, should they 
> fall back to overload resolution for one parameter of type `MoveOnly&`.


Still need to address that. With this change we're only doing the first step, 
we still need the fallback.




Comment at: clang/lib/Sema/SemaCoroutine.cpp:869
   if (E) {
-auto NRVOCandidate = this->getCopyElisionCandidate(E->getType(), E, 
CES_AsIfByStdMove);
-if (NRVOCandidate) {
-  InitializedEntity Entity =
-  InitializedEntity::InitializeResult(Loc, E->getType(), 
NRVOCandidate);
-  ExprResult MoveResult = this->PerformMoveOrCopyInitialization(
-  Entity, NRVOCandidate, E->getType(), E);
-  if (MoveResult.get())
-E = MoveResult.get();
-}
+VarDecl *NRVOCandidate =
+getCopyElisionCandidate(E->getType(), E, CES_Default);

Quuxplusone wrote:
> aaronpuchert wrote:
> > Should be renamed to `RVOCandidate`, I don't think NRVO can happen here.
> (Btw, I have no comment on the actual code change in this patch. I'm here in 
> my capacity as 
> [RVO-explainer](https://www.youtube.com/watch?v=hA1WNtNyNbo)-and-[P1155](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1155r2.html)-author,
>  not code-understander. ;))
> 
> What's happening here is never technically "RVO" at all, because there is no 
> "RV". However, the "N" is accurate. (See [my acronym 
> glossary](https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/#rvo-nrvo-urvo)
>  for details.)
> The important thing here is that when you say `co_return x;` the `x` is 
> //named//, and it //would be// a candidate for NRVO if we were in a situation 
> where NRVO was possible at all.
> 
> The actual optimization that is happening here is "implicit move."
> 
> I would strongly prefer to keep the name `NRVOCandidate` here, because that 
> is the name that is used for the exact same purpose — computing "implicit 
> move" candidates — in `BuildReturnStmt`. Ideally this code would be factored 
> out so that it appeared in only one place; but until then, gratuitous 
> differences between the two sites should be minimized IMO.
Hmm, you're completely right. What do you think about `ImplicitMoveCandidate`? 
Otherwise I'll stick with the current name, as you suggested.

> Ideally this code would be factored out so that it appeared in only one 
> place; but until then, gratuitous differences between the two sites should be 
> minimized IMO.

Isn't it already factored out? I let `getCopyElisionCandidate` do all the heavy 
lifting. (Except filtering out lvalue references...)



Comment at: clang/test/SemaCXX/coroutine-rvo.cpp:71
+task param2val(MoveOnly value) {
+  co_return value;
 }

Quuxplusone wrote:
> This should work equally well with `NoCopyNoMove`, right? It should just call 
> `task::return_value(NCNM&&)`. I don't think you need `MoveOnly` in this 
> test file anymore.
I thought so, too, but there is some code that probably constructs the 
coroutine and that needs a move constructor. If you look at the AST:

```
FunctionDecl 0xee2e08  line:70:16 param2val 
'task (MoveOnly)'
|-ParmVarDecl 0xee2cf0  col:35 used value 'MoveOnly'
`-CoroutineBodyStmt 0xee7df8 
  |-CompoundStmt 0xee71b8 
  | `-CoreturnStmt 0xee7190 
  |   |-ImplicitCastExpr 0xee7100  'MoveOnly' xvalue 
  |   | `-DeclRefExpr 0xee3088  'MoveOnly' lvalue ParmVar 0xee2cf0 
'value' 'MoveOnly'
  |   `-CXXMemberCallExpr 0xee7168  'void'
  | |-MemberExpr 0xee7138  '' 
.return_value 0xee5408
  | | `-DeclRefExpr 0xee7118  
'std::experimental::traits_sfinae_base, 
void>::promise_type':'task::promise_type' lvalue Var 0xee54e8 
'__promise' 'std::experimental::traits_sfinae_base, 
void>::promise_type':'task::promise_type'
  | `-ImplicitCastExpr 0xee7100  'MoveOnly' xvalue 
  |   `-DeclRefExpr 0xee3088  'MoveOnly' lvalue ParmVar 0xee2cf0 
'value' 'MoveOnly'
```

So no move constructor here. But then comes a bunch of other stuff, and finally,

```
`-CoroutineBodyStmt 0xee7df8 
  [...]
  `-DeclStmt 0xee31f0 
`-VarDecl 0xee3118  col:3 implicit used value 'MoveOnly' listinit
  `-CXXConstructExpr 0xee31c0  'MoveOnly' 'void (MoveOnly &&) 
noexcept'
`-CXXStaticCastExpr 0xee30d8  'MoveOnly' xvalue 
static_cast 
  `-DeclRefExpr 0xee30a8  'MoveOnly' lvalue ParmVar 0xee2cf0 
'value' 'MoveOnly'
```



Comment at: clang/test/SemaCXX/coroutine-rvo.cpp:74
 
-// expected-no-diagnostics
+task lvalue2val(Default& value) {
+  co_return value; // expected-error{{rvalue reference to type 'Default' 
cannot bind to lvalue of type 'Default'}}

Quuxplusone wrote:
> Ditto here, could you use `NoCopyNoMove` instead of `Default`?
I used 

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun marked an inline comment as done.
vladimir.plyashkun added inline comments.



Comment at: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp:23-24
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.getLocalOrGlobal("IgnorePositiveIntegerLiterals", false)) {}
+

lebedev.ri wrote:
> i'm not sure this should look for a global option with such name?
I think that this method is common and used in so many inspections. 
For example this [[ 
https://clang.llvm.org/extra/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.html
  | check ]] also have option called `IgnoreMacros` which is retrieved in same 
way (by calling getLocalOrGlobal method)


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp:23-24
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.getLocalOrGlobal("IgnorePositiveIntegerLiterals", false)) {}
+

vladimir.plyashkun wrote:
> lebedev.ri wrote:
> > i'm not sure this should look for a global option with such name?
> I think that this method is common and used in so many inspections. 
> For example this [[ 
> https://clang.llvm.org/extra/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.html
>   | check ]] also have option called `IgnoreMacros` which is retrieved in 
> same way (by calling getLocalOrGlobal method)
I'm very specifically discriminating against `"IgnorePositiveIntegerLiterals"` 
here.
I know `getLocalOrGlobal()` is widely used, because in those places the same 
flag
is used in multiple modules with same meaning.
Is that the case here?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D68807: [ClangTidy] Separate tests for infrastructure and checkers

[Alexander Kornienko via Phabricator via cfe-commits]

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

I agree that the test/clang-tidy directory has become hard to navigate. 
Splitting tests for checks and for infrastructure seems reasonable to me. I 
personally don't care about specific directory names and file moves/renames are 
also not a concern, since git is rather good at handling those. I personally 
strongly prefer long-term improvements over desire to minimize churn.

My only concern is that the add_new_check.py script is updated to put new tests 
to the right place - totally fine for a follow up though.

One more thing is that having all checker tests in one directory is still not 
particularly nice, but the alternatives I thought of are not clearly superior:
0. test/clang-tidy/modernize-blah-blah.cpp - current state

1. test/clang-tidy/checkers/modernize-blah-blah.cpp - this patch
2. test/clang-tidy/checkers/modernize/blah-blah.cpp - test names don't have the 
check name substring, which makes them slightly harder to find with eyes
3. test/clang-tidy/checkers/modernize/modernize-blah-blah.cpp - a bit 
tautological, even longer full file names

I'm fine with any of 1-3, since there's no clear winner among the three options.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68807



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

r374539 - Dead Virtual Function Elimination

[Oliver Stannard via cfe-commits]

Author: ostannard
Date: Fri Oct 11 04:59:55 2019
New Revision: 374539

URL: http://llvm.org/viewvc/llvm-project?rev=374539&view=rev
Log:
Dead Virtual Function Elimination

Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.

This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.

To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.

The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.

This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.

To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.

I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.

On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.

I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.

I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).

Differential revision: https://reviews.llvm.org/D63932

Added:
cfe/trunk/test/CodeGenCXX/vcall-visibility-metadata.cpp
cfe/trunk/test/CodeGenCXX/virtual-function-elimination.cpp
cfe/trunk/test/Driver/virtual-function-elimination.cpp
Modified:
cfe/trunk/include/clang/Basic/CodeGenOptions.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp

Modified: cfe/trunk/include/clang/Basic/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CodeGenOptions.def?rev=374539&r1=374538&r2=374539&view=diff
==
--- cfe/trunk/include/clang/Basic/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Basic/CodeGenOptions.def Fri Oct 11 04:59:55 2019
@@ -278

[PATCH] D63932: [GlobalDCE] Dead Virtual Function Elimination

[Oliver Stannard (Linaro) via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG9f6a873268e1: Dead Virtual Function Elimination (authored by 
ostannard).

Changed prior to commit:
  https://reviews.llvm.org/D63932?vs=218363&id=224568#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63932

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
  clang/test/CodeGenCXX/virtual-function-elimination.cpp
  clang/test/Driver/virtual-function-elimination.cpp
  llvm/docs/LangRef.rst
  llvm/docs/TypeMetadata.rst
  llvm/include/llvm/Analysis/TypeMetadataUtils.h
  llvm/include/llvm/IR/FixedMetadataKinds.def
  llvm/include/llvm/IR/GlobalObject.h
  llvm/include/llvm/Transforms/IPO/GlobalDCE.h
  llvm/lib/Analysis/TypeMetadataUtils.cpp
  llvm/lib/IR/Metadata.cpp
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/GlobalDCE.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/LTO/ARM/lto-linking-metadata.ll
  llvm/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-post-lto.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-pre-lto.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions.ll
  llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
  llvm/test/Transforms/Internalize/vcall-visibility.ll

Index: llvm/test/Transforms/Internalize/vcall-visibility.ll
===
--- /dev/null
+++ llvm/test/Transforms/Internalize/vcall-visibility.ll
@@ -0,0 +1,64 @@
+; RUN: opt < %s -internalize -S | FileCheck %s
+
+%struct.A = type { i32 (...)** }
+%struct.B = type { i32 (...)** }
+%struct.C = type { i32 (...)** }
+
+; Class A has default visibility, so has no !vcall_visibility metadata before
+; or after LTO.
+; CHECK-NOT: @_ZTV1A = {{.*}}!vcall_visibility
+@_ZTV1A = dso_local unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.A*)* @_ZN1A3fooEv to i8*)] }, align 8, !type !0, !type !1
+
+; Class B has hidden visibility but public LTO visibility, so has no
+; !vcall_visibility metadata before or after LTO.
+; CHECK-NOT: @_ZTV1B = {{.*}}!vcall_visibility
+@_ZTV1B = hidden unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.B*)* @_ZN1B3fooEv to i8*)] }, align 8, !type !2, !type !3
+
+; Class C has hidden visibility, so the !vcall_visibility metadata is set to 1
+; (linkage unit) before LTO, and 2 (translation unit) after LTO.
+; CHECK: @_ZTV1C ={{.*}}!vcall_visibility [[MD_TU_VIS:![0-9]+]]
+@_ZTV1C = hidden unnamed_addr constant { [3 x i8*] } { [3 x i8*] [i8* null, i8* null, i8* bitcast (void (%struct.C*)* @_ZN1C3fooEv to i8*)] }, align 8, !type !4, !type !5, !vcall_visibility !6
+
+; Class D has translation unit visibility before LTO, and this is not changed
+; by LTO.
+; CHECK: @_ZTVN12_GLOBAL__N_11DE = {{.*}}!vcall_visibility [[MD_TU_VIS:![0-9]+]]
+@_ZTVN12_GLOBAL__N_11DE = internal unnamed_addr constant { [3 x i8*] } zeroinitializer, align 8, !type !7, !type !9, !vcall_visibility !11
+
+define dso_local void @_ZN1A3fooEv(%struct.A* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden void @_ZN1B3fooEv(%struct.B* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden void @_ZN1C3fooEv(%struct.C* nocapture %this) {
+entry:
+  ret void
+}
+
+define hidden noalias nonnull i8* @_Z6make_dv() {
+entry:
+  %call = tail call i8* @_Znwm(i64 8) #3
+  %0 = bitcast i8* %call to i32 (...)***
+  store i32 (...)** bitcast (i8** getelementptr inbounds ({ [3 x i8*] }, { [3 x i8*] }* @_ZTVN12_GLOBAL__N_11DE, i64 0, inrange i32 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8
+  ret i8* %call
+}
+
+declare dso_local noalias nonnull i8* @_Znwm(i64)
+
+; CHECK: [[MD_TU_VIS]] = !{i64 2}
+!0 = !{i64 16, !"_ZTS1A"}
+!1 = !{i64 16, !"_ZTSM1AFvvE.virtual"}
+!2 = !{i64 16, !"_ZTS1B"}
+!3 = !{i64 16, !"_ZTSM1BFvvE.virtual"}
+!4 = !{i64 16, !"_ZTS1C"}
+!5 = !{i64 16, !"_ZTSM1CFvvE.virtual"}
+!6 = !{i64 1}
+!7 = !{i64 16, !8}
+!8 = distinct !{}
+!9 = !{i64 16, !10}
+!10 = distinct !{}
+!11 = !{i64 2}
Index: llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
===
--- /dev/null
+++ llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
@@ -0,0 +1,47 @@
+; RUN: opt < %s -globaldce -S 

[PATCH] D68807: [ClangTidy] Separate tests for infrastructure and checkers

[Dmitri Gribenko via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG885c559369fe: [ClangTidy] Separate tests for infrastructure 
and checkers (authored by gribozavr).

Changed prior to commit:
  https://reviews.llvm.org/D68807?vs=224378&id=224569#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68807

Files:
  clang-tools-extra/test/clang-tidy/Inputs/Headers/a.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/b.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/clang-c/c.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/clang/b.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/cross-file-a.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/cross-file-b.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/cross-file-c.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/gtest/foo.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/i.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/j.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/llvm-c/d.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/llvm/a.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/s.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/stdio.h
  clang-tools-extra/test/clang-tidy/Inputs/Headers/system-header-simulation.h
  clang-tools-extra/test/clang-tidy/Inputs/absl/external-file.h
  clang-tools-extra/test/clang-tidy/Inputs/absl/flags/internal-file.h
  clang-tools-extra/test/clang-tidy/Inputs/absl/strings/internal-file.h
  clang-tools-extra/test/clang-tidy/Inputs/absl/time/time.h
  clang-tools-extra/test/clang-tidy/Inputs/compilation-database/template.json
  clang-tools-extra/test/clang-tidy/Inputs/config-files/.clang-tidy
  clang-tools-extra/test/clang-tidy/Inputs/config-files/1/.clang-tidy
  clang-tools-extra/test/clang-tidy/Inputs/empty-database/compile_commands.json
  
clang-tools-extra/test/clang-tidy/Inputs/expand-modular-headers-ppcallbacks/a.h
  
clang-tools-extra/test/clang-tidy/Inputs/expand-modular-headers-ppcallbacks/b.h
  
clang-tools-extra/test/clang-tidy/Inputs/expand-modular-headers-ppcallbacks/c.h
  
clang-tools-extra/test/clang-tidy/Inputs/expand-modular-headers-ppcallbacks/module.modulemap
  clang-tools-extra/test/clang-tidy/Inputs/explain-config/.clang-tidy
  clang-tools-extra/test/clang-tidy/Inputs/file-filter/header1.h
  clang-tools-extra/test/clang-tidy/Inputs/file-filter/header2.h
  clang-tools-extra/test/clang-tidy/Inputs/file-filter/system/system-header.h
  clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/a.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/cstdarg.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/cstdlib.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/j.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/r.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/s.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/t.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/system/transitive.h
  
clang-tools-extra/test/clang-tidy/Inputs/fuchsia-restrict-system-includes/transitive2.h
  clang-tools-extra/test/clang-tidy/Inputs/google-namespaces.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/gtest.h
  
clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest-typed-test.h
  clang-tools-extra/test/clang-tidy/Inputs/gtest/nosuite/gtest/gtest.h
  clang-tools-extra/test/clang-tidy/Inputs/line-filter/header1.h
  clang-tools-extra/test/clang-tidy/Inputs/line-filter/header2.h
  clang-tools-extra/test/clang-tidy/Inputs/line-filter/header3.h
  clang-tools-extra/test/clang-tidy/Inputs/mock-libcxx/bin/clang
  
clang-tools-extra/test/clang-tidy/Inputs/mock-libcxx/include/c++/v1/mock_vector
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/assert.h
  
clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/complex.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/ctype.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/errno.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/fenv.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/float.h
  
clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/inttypes.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/iso646.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/limits.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/locale.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/math.h
  clang-tools-extra/test/clang-tidy/Inputs/modernize-deprecated-headers/setjmp.h
  clang-to

r374543 - [MS ABI]: Fix mangling function arguments for template types to be compatible with MSVC

[Nico Weber via cfe-commits]

Author: nico
Date: Fri Oct 11 05:27:51 2019
New Revision: 374543

URL: http://llvm.org/viewvc/llvm-project?rev=374543&view=rev
Log:
[MS ABI]: Fix mangling function arguments for template types to be compatible 
with MSVC

MS name mangling supports cache for first 10 distinct function
arguments.  The error was when non cached template type occurred twice
(e.g. 11th and 12th).  For such case in code there is another cache
table TemplateArgStrings (for performance reasons).  Then one '@'
character at the end of the mangled name taken from this table was
missing.  For other cases the missing '@' character was added in
the call to mangleSourceName(TemplateMangling) in the cache miss code,
but the cache hit code didn't add it.

This fixes a regression from r362560.

Patch by Adam Folwarczny !

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

Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/test/CodeGenCXX/mangle-ms-back-references.cpp

Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=374543&r1=374542&r2=374543&view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Fri Oct 11 05:27:51 2019
@@ -846,7 +846,7 @@ void MicrosoftCXXNameMangler::mangleUnqu
   TemplateArgStringStorage.save(TemplateMangling.str());
 }
   } else {
-Out << Found->second; // Outputs a StringRef.
+Out << Found->second << '@'; // Outputs a StringRef.
   }
 } else {
   Out << Found->second; // Outputs a back reference (an int).

Modified: cfe/trunk/test/CodeGenCXX/mangle-ms-back-references.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-ms-back-references.cpp?rev=374543&r1=374542&r2=374543&view=diff
==
--- cfe/trunk/test/CodeGenCXX/mangle-ms-back-references.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-ms-back-references.cpp Fri Oct 11 05:27:51 
2019
@@ -66,3 +66,20 @@ namespace foo {
 void foo() { }
 // CHECK: "?foo@0@YAXXZ"
 }
+
+class T01;
+class T02;
+class T03;
+class T04;
+class T05;
+class T06;
+class T07;
+class T08;
+class T09;
+class T10;
+class T11;
+template 
+class H;
+
+void ManyParams(T01 &, T02 &, T03 &, T04 &, T05 &, T06 &, T07 &, T08 &, T09 &, 
T10 &, H &, H &) {}
+// CHECK: 
"?ManyParams@@YAXAAVT01@@AAVT02@@AAVT03@@AAVT04@@AAVT05@@AAVT06@@AAVT07@@AAVT08@@AAVT09@@AAVT10@@AAV?$H@VT11AAV?$H@VT11@Z"


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

[PATCH] D68099: [MS ABI]: Fix mangling function arguments for template types to be compatible with MSVC

[Nico Weber via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb95713784a3c: [MS ABI]: Fix mangling function arguments for 
template types to be compatible… (authored by thakis).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68099

Files:
  clang/lib/AST/MicrosoftMangle.cpp
  clang/test/CodeGenCXX/mangle-ms-back-references.cpp


Index: clang/test/CodeGenCXX/mangle-ms-back-references.cpp
===
--- clang/test/CodeGenCXX/mangle-ms-back-references.cpp
+++ clang/test/CodeGenCXX/mangle-ms-back-references.cpp
@@ -66,3 +66,20 @@
 void foo() { }
 // CHECK: "?foo@0@YAXXZ"
 }
+
+class T01;
+class T02;
+class T03;
+class T04;
+class T05;
+class T06;
+class T07;
+class T08;
+class T09;
+class T10;
+class T11;
+template 
+class H;
+
+void ManyParams(T01 &, T02 &, T03 &, T04 &, T05 &, T06 &, T07 &, T08 &, T09 &, 
T10 &, H &, H &) {}
+// CHECK: 
"?ManyParams@@YAXAAVT01@@AAVT02@@AAVT03@@AAVT04@@AAVT05@@AAVT06@@AAVT07@@AAVT08@@AAVT09@@AAVT10@@AAV?$H@VT11AAV?$H@VT11@Z"
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -846,7 +846,7 @@
   TemplateArgStringStorage.save(TemplateMangling.str());
 }
   } else {
-Out << Found->second; // Outputs a StringRef.
+Out << Found->second << '@'; // Outputs a StringRef.
   }
 } else {
   Out << Found->second; // Outputs a back reference (an int).


Index: clang/test/CodeGenCXX/mangle-ms-back-references.cpp
===
--- clang/test/CodeGenCXX/mangle-ms-back-references.cpp
+++ clang/test/CodeGenCXX/mangle-ms-back-references.cpp
@@ -66,3 +66,20 @@
 void foo() { }
 // CHECK: "?foo@0@YAXXZ"
 }
+
+class T01;
+class T02;
+class T03;
+class T04;
+class T05;
+class T06;
+class T07;
+class T08;
+class T09;
+class T10;
+class T11;
+template 
+class H;
+
+void ManyParams(T01 &, T02 &, T03 &, T04 &, T05 &, T06 &, T07 &, T08 &, T09 &, T10 &, H &, H &) {}
+// CHECK: "?ManyParams@@YAXAAVT01@@AAVT02@@AAVT03@@AAVT04@@AAVT05@@AAVT06@@AAVT07@@AAVT08@@AAVT09@@AAVT10@@AAV?$H@VT11AAV?$H@VT11@Z"
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -846,7 +846,7 @@
   TemplateArgStringStorage.save(TemplateMangling.str());
 }
   } else {
-Out << Found->second; // Outputs a StringRef.
+Out << Found->second << '@'; // Outputs a StringRef.
   }
 } else {
   Out << Found->second; // Outputs a back reference (an int).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D14927: clang-format: Add SpaceBeforeTemplateParameterList option

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

This revision would require unit tests to proceed


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

https://reviews.llvm.org/D14927



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

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

TBH, I quite dislike  the creeping abuse of `SubtargetFeature`s as code 
generation options.

cf. Target.td:1477

  
//===--===//
  // SubtargetFeature - A characteristic of the chip set.
  //

IMHO, since reserved registes are per-function, this strongly suggests 
implementation as function attribute(s), rather than subtarget features (also 
for the pre-existing r9).
It also opens the path towards possible future `__attribute__`.




Comment at: clang/include/clang/Basic/TargetInfo.h:944
+  /// using the corresponding -ffixed-RegName option.
+  virtual bool isRegisterReservedGlobally(StringRef RegName) const {
+return true;

Parameter name can be omitted if unused; that would remove a potential warning.



Comment at: clang/lib/Basic/Targets/ARM.cpp:884
+StringRef RegName, unsigned RegSize, bool &HasSizeMismatch) const {
+  if (RegName.equals("r6") || RegName.equals("r7") || RegName.equals("r8") ||
+  RegName.equals("r9") || RegName.equals("r10") || RegName.equals("r11") ||

Perhaps you can use here `RegName == "r6"` or string switch ?



Comment at: clang/lib/Basic/Targets/ARM.cpp:890
+  }
+  return false;
+}

`HasSizeMismatch`  is not set along all possible paths.




Comment at: clang/lib/Basic/Targets/ARM.cpp:895
+  // The "sp" register does not have a -ffixed-sp option,
+  // so enable it unconditionally.
+  if (RegName.equals("sp"))

s/enable/reserve/ ?



Comment at: clang/lib/Basic/Targets/ARM.cpp:899
+
+  // enable rN (N:6-11) registers only if the corresponding
+  // +reserve-rN feature is found

Likewise ?



Comment at: clang/lib/Basic/Targets/ARM.cpp:901-902
+  // +reserve-rN feature is found
+  std::vector &Features = getTargetOpts().Features;
+  std::string SearchFeature = "+reserve-" + RegName.str();
+  for (std::string &Feature : Features) {

These variables can be `const`.



Comment at: clang/lib/Basic/Targets/ARM.cpp:903-907
+  for (std::string &Feature : Features) {
+if (Feature.compare(SearchFeature) == 0)
+  return true;
+  }
+  return false;

This explicit loop can be written like:
```
return llvm::any_of(getTargetOpts().Features(),
   [&](auto &P) { return P == SearchFeature; });
```




Comment at: llvm/lib/Target/ARM/ARMSubtarget.h:236
+  // ReservedRRegisters[i] - R#i is not available as a general purpose 
register.
+  BitVector ReservedRRegisters;
 

The usual designation for these registers is "GPR". Suggestion either 
`ReservedGPRegisters` or just `ReservedRegisters`,
here and elsewhere.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68862



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

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

[Momchil Velikov via Phabricator via cfe-commits]

chill added inline comments.



Comment at: clang/lib/Basic/Targets/ARM.cpp:902
+  std::vector &Features = getTargetOpts().Features;
+  std::string SearchFeature = "+reserve-" + RegName.str();
+  for (std::string &Feature : Features) {

SjoerdMeijer wrote:
> I was pointed at something similar myself recently, but if I am not mistaken 
> then I think this is a use-after-free:
> 
>"+reserve-" + RegName.str()
> 
> this will allocate a temp `std::string` that `SearchFeature` points to, which 
> then gets released, and `SearchFeature` is still pointing at it.
Any temporaries would be destructed at the end of the full expression. By that 
time, the `SearchString` would be constructed and stand on its own.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68862



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

[PATCH] D56345: [clang-format] Assert that filenames are not empty

[MyDeveloperDay via Phabricator via cfe-commits]

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

Thanks for the patch, I'm sorry it's taken so long sometimes items get 
lost...This looks to still be relevant, I think you'll need to rebase but it 
LGTM

  $ clang-format --assume-filename= < ../clang-format-examples/test.cpp
  Assertion failed: !HasError && "Cannot get value when an error exists!", file 
C:\llvm/llvm-project/llvm/include\llvm/Support/ErrorOr.h, line 243
  Stack dump:
  0.  Program arguments: C:\llvm\build\bin\clang-format.exe 
--assume-filename=
   #0 0x7ff64d041b55 (C:\llvm\build\bin\clang-format.exe+0x41b55)
   #1 0x7ff8efdcda2d (C:\WINDOWS\System32\ucrtbase.dll+0x6da2d)
   #2 0x7ff8efdce901 (C:\WINDOWS\System32\ucrtbase.dll+0x6e901)
   #3 0x7ff8efdd0261 (C:\WINDOWS\System32\ucrtbase.dll+0x70261)
   #4 0x7ff8efdd0591 (C:\WINDOWS\System32\ucrtbase.dll+0x70591)
   #5 0x7ff64d065cdd (C:\llvm\build\bin\clang-format.exe+0x65cdd)
   #6 0x7ff64d0a11f3 (C:\llvm\build\bin\clang-format.exe+0xa11f3)
   #7 0x7ff64d081dc3 (C:\llvm\build\bin\clang-format.exe+0x81dc3)
   #8 0x7ff64d0817bb (C:\llvm\build\bin\clang-format.exe+0x817bb)
   #9 0x7ff64d00b17c (C:\llvm\build\bin\clang-format.exe+0xb17c)
  #10 0x7ff64d00d515 (C:\llvm\build\bin\clang-format.exe+0xd515)
  #11 0x7ff64d12cc30 (C:\llvm\build\bin\clang-format.exe+0x12cc30)
  #12 0x7ff8efe77974 (C:\WINDOWS\System32\KERNEL32.DLL+0x17974)
  #13 0x7ff8f2caa271 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x6a271)




Repository:
  rC Clang

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

https://reviews.llvm.org/D56345



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

[PATCH] D68824: Fix __builtin_assume_aligned with too large values.

[Erich Keane via Phabricator via cfe-commits]

erichkeane marked 5 inline comments as done.
erichkeane added subscribers: majnemer, aaron.ballman.
erichkeane added a comment.

In D68824#1704942 , @rsmith wrote:

> This seems to be missing a CodeGen test for what IR we generate on an 
> overly-large alignment. (The warning says the alignment is ignored, but I 
> don't see where you're actually doing anything different in that case when 
> generating IR.)


My intent was to just let the value through, and let LLVM ignore it (while 
alerting the developer).  I'll add a CodeGen test as well when relanding, it 
seems to have been lost in the process of developing the patch.  Thanks for 
your attention here.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2857-2859
+: Warning<"requested alignment must be %0 bytes or smaller; assumption "
+  "ignored">,
+  InGroup>;

rsmith wrote:
> Ignoring the assumption in this case seems unnecessarily user-hostile (and 
> would require hard-coding an arbitrary LLVM limit in the source code to work 
> around). Couldn't we just assume the highest alignment that we do support 
> instead?
This more closely fit GCCs behavior (of ignoring any invalid value, though 
their top limit is int64-max).  We can definitely just assume highest 
alignment, I'll do that in my re-land.



Comment at: clang/lib/Sema/SemaChecking.cpp:6067-6070
+// Alignment calculations can wrap around if it's greater than 2**28.
+unsigned MaximumAlignment =
+Context.getTargetInfo().getTriple().isOSBinFormatCOFF() ? 8192
+: 268435456;

rsmith wrote:
> Why is there a different limit depending on bin format? We can support this 
> at the IR level regardless, can't we? (I don't see how the binary format is 
> relevant.)
I'd copied it from the Sema::AddAlignedAttr implementation, but I cannot seem 
to figure out the origin of that.  @majnemer added the 2**28 business back in 
2015, but @aaron.ballman put the limit of 8192 in here: 
https://reviews.llvm.org/rL158717#change-N0HH8qtBJv7d
(note it was reverted and relanded).

I don't see sufficient justification in that history now that I've looked back 
to keep that log in here, so I'll keep us at 2**28.



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

https://reviews.llvm.org/D68824



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

[clang-tools-extra] r374549 - [ClangTidy] Separate tests for infrastructure and checkers, fixup

[Dmitri Gribenko via cfe-commits]

Author: gribozavr
Date: Fri Oct 11 06:16:49 2019
New Revision: 374549

URL: http://llvm.org/viewvc/llvm-project?rev=374549&view=rev
Log:
[ClangTidy] Separate tests for infrastructure and checkers, fixup

Renamed a file that I missed in r374540.

Added:
clang-tools-extra/trunk/test/clang-tidy/checkers/Inputs/Headers/stdio.h
Removed:

clang-tools-extra/trunk/test/clang-tidy/infrastructure/Inputs/Headers/stdio.h

Added: clang-tools-extra/trunk/test/clang-tidy/checkers/Inputs/Headers/stdio.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/checkers/Inputs/Headers/stdio.h?rev=374549&view=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/checkers/Inputs/Headers/stdio.h 
(added)
+++ clang-tools-extra/trunk/test/clang-tidy/checkers/Inputs/Headers/stdio.h Fri 
Oct 11 06:16:49 2019
@@ -0,0 +1,18 @@
+//===--- stdio.h - Stub header for tests *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _STDIO_H_
+#define _STDIO_H_
+
+// A header intended to contain C standard input and output library
+// declarations.
+
+int printf(const char *, ...);
+
+#endif // _STDIO_H_
+

Removed: 
clang-tools-extra/trunk/test/clang-tidy/infrastructure/Inputs/Headers/stdio.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/infrastructure/Inputs/Headers/stdio.h?rev=374548&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/infrastructure/Inputs/Headers/stdio.h 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/infrastructure/Inputs/Headers/stdio.h 
(removed)
@@ -1,18 +0,0 @@
-//===--- stdio.h - Stub header for tests *- C++ 
-*-===//
-//
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-//
-//===--===//
-
-#ifndef _STDIO_H_
-#define _STDIO_H_
-
-// A header intended to contain C standard input and output library
-// declarations.
-
-int printf(const char *, ...);
-
-#endif // _STDIO_H_
-


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

[PATCH] D68818: [hip][cuda] Fix the extended lambda name mangling issue.

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

PING for review, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68818



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

[PATCH] D68862: [ARM] Allocatable Global Register Variables for ARM

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/lib/Basic/Targets/ARM.cpp:902
+  std::vector &Features = getTargetOpts().Features;
+  std::string SearchFeature = "+reserve-" + RegName.str();
+  for (std::string &Feature : Features) {

chill wrote:
> SjoerdMeijer wrote:
> > I was pointed at something similar myself recently, but if I am not 
> > mistaken then I think this is a use-after-free:
> > 
> >"+reserve-" + RegName.str()
> > 
> > this will allocate a temp `std::string` that `SearchFeature` points to, 
> > which then gets released, and `SearchFeature` is still pointing at it.
> Any temporaries would be destructed at the end of the full expression. By 
> that time, the `SearchString` would be constructed and stand on its own.
Ah yes, true. This is a std::string, not stringref as in my case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68862



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

[PATCH] D67160: [clang, ARM] Default to -fno-lax-vector-conversions in ARM v8.1-M.

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added a comment.

Hmmm. I take your point, and so I backed out my local version of this patch in 
order to try to solve the problem a different way in overload resolution.

But in fact overloading on different vector types already seems to work fine: 
my in-progress patch series still passes all the clang tests even without this 
change to the defaults. So unless there's been a fix to overload resolution 
since I started developing all of this (I looked, and didn't find one), I can't 
quite work out why I needed this patch in the first place now. It may be that 
it's completely unnecessary, and that I managed to fool myself early in 
development by misinterpreting some other kind of mistake I'd made.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67160



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

[PATCH] D67216: [cfi] Add flag to always generate .debug_frame

[David Candler via Phabricator via cfe-commits]

dcandler updated this revision to Diff 224581.
dcandler retitled this revision from "[cfi] Add flag to always generate call 
frame information" to "[cfi] Add flag to always generate .debug_frame".
dcandler edited the summary of this revision.
dcandler added reviewers: rengolin, joerg.
dcandler added a comment.
Herald added subscribers: jsji, MaskRay, kbarton, nemanjai.

I've modified the patch so that the new flag will ensure the cfi instructions 
are actually present to be emitted as well. I went ahead and renamed the flag 
-gdwarf-frame too, to better reflect that it's dealing with the debug 
information you'd otherwise get with -g, and is meant to specifically put the 
information in a .debug_frame section and not .eh_frame.

Currently, two things signal for need for cfi: exceptions (via the function's 
needsUnwindTableEntry()), and debug (via the machine module information's 
hasDebugInfo()). At frame lowering, both trigger the same thing. But when the 
assembly printer decides on which section to use, needsUnwindTableEntry() is 
checked first and triggers the need for .eh_frame, while hasDebugInfo() is 
checked afterwards for whether .debug_frame is needed. So .debug_frame is only 
present when any level of debug is requested, and no functions need unwinding 
for exceptions.

It wouldn't be appropriate to change either needsUnwindTableEntry() or 
hasDebugInfo(), so I've added a check for my flag alongside them. Because the 
same logic is used in multiple places, I've wrapped all three checks into one 
function to try and clean things up slightly. When deciding on which section to 
emit, the new flag means .debug_frame is produced instead of nothing. If 
.eh_frame would have been needed, rather than replace it, the new flag simply 
emits both .debug_frame and .eh_frame.

The end result is that -gdwarf-frame should only provide a .debug_frame section 
as additional information, without otherwise modifying anything. The existing 
-funwind-tables (and -fasynchronous-unwind-tables) flag can be used to provide 
similar information, but because it takes the exception angle, it alters 
function attributes and ultimately produces .eh_frame instead.


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

https://reviews.llvm.org/D67216

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/gdwarf-frame.c
  llvm/include/llvm/CodeGen/CommandFlags.inc
  llvm/include/llvm/CodeGen/MachineFunction.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/AsmPrinter/DwarfCFIException.cpp
  llvm/lib/CodeGen/CFIInstrInserter.cpp
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
  llvm/lib/Target/ARC/ARCRegisterInfo.cpp
  llvm/lib/Target/Hexagon/HexagonFrameLowering.cpp
  llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86InstrInfo.cpp
  llvm/lib/Target/XCore/XCoreRegisterInfo.cpp
  llvm/test/CodeGen/ARM/dwarf-frame.ll

Index: llvm/test/CodeGen/ARM/dwarf-frame.ll
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/dwarf-frame.ll
@@ -0,0 +1,38 @@
+; RUN: llc -mtriple armv7-unknown -frame-pointer=all -filetype=asm -o - %s | FileCheck %s --check-prefix=CHECK-NO-CFI
+; RUN: llc -mtriple armv7-unknown -frame-pointer=all -filetype=asm -dwarf-frame-section -o - %s | FileCheck %s --check-prefix=CHECK-ALWAYS-CFI
+
+declare void @dummy_use(i32*, i32)
+
+define void @test_basic() #0 {
+%mem = alloca i32, i32 10
+call void @dummy_use (i32* %mem, i32 10)
+  ret void
+}
+
+; CHECK-NO-CFI-LABEL: test_basic:
+; CHECK-NO-CFI:   .fnstart
+; CHECK-NO-CFI-NOT:   .cfi_sections .debug_frame
+; CHECK-NO-CFI-NOT:   .cfi_startproc
+; CHECK-NO-CFI:   @ %bb.0:
+; CHECK-NO-CFI:   push {r11, lr}
+; CHECK-NO-CFI-NOT:   .cfi_def_cfa_offset 8
+; CHECK-NO-CFI-NOT:   .cfi_offset lr, -4
+; CHECK-NO-CFI-NOT:   .cfi_offset r11, -8
+; CHECK-NO-CFI:   mov r11, sp
+; CHECK-NO-CFI-NOT:   .cfi_def_cfa_register r11
+; CHECK-NO-CFI-NOT:   .cfi_endproc
+; CHECK-NO-CFI:   .fnend
+
+; CHECK-ALWAYS-CFI-LABEL: test_basic:
+; CHECK-ALWAYS-CFI:   .fnstart
+; CHECK-ALWAYS-CFI:   .cfi_sections .debug_frame
+; CHECK-ALWAYS-CFI:   .cfi_startproc
+; CHECK-ALWAYS-CFI:   @ %bb.0:
+; CHECK-ALWAYS-CFI:   push {r11, lr}
+; CHECK-ALWAYS-CFI:   .cfi_def_cfa_offset 8
+; CHECK-ALWAYS-CFI:   .cfi_offset lr, -4
+; CHECK-ALWAYS-CFI:   .cfi_offset r11, -8
+; CHECK-ALWAYS-CFI:   mov r11, sp
+; CHECK-ALWAYS-CFI:   .cfi_def_cfa_register r11
+; CHECK-ALWAYS-CFI:   .cfi_endproc
+; CHECK-ALWAYS-CFI:   .fnend
Index: llvm/lib/Target/XCore/XCoreRegisterInfo.cpp
===
--- llvm/lib/Target/XCore/XCoreRegisterInfo.c

[PATCH] D27377: clang-format: Support the Java 8 'default' method modifier

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

While reviewing old revisions either not landed or unreviewed I stumbled across 
this accepted review. Looking at the current code I think its not needed 
anymore.  Perhaps if we merge your test in with the current trunk we can 
determine if this is still needed


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

https://reviews.llvm.org/D27377



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

[PATCH] D68682: Clang-tidy fix removals removing all non-blank text from a line should remove the line

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

> I guess here's the high-level question: should all removals that remove all 
> non-blank text from a line also delete the line?

I see your point, but as https://llvm.org/PR43583 shows, we have a much larger 
problem: textual replacements don't compose. So, whatever we do, it will only 
be hacky workarounds for specific high-value cases.

About how exactly to do it. It would be preferred if checkers that already know 
that they are deleting a full line, just deleted the newline characters. 
However, for other cases, I feel like the place where this patch implements 
newline deletion is not ideal. It implements newline deletion while applying 
all fixes. Applying fixes is not the only client of fixit information. Probably 
it is one of the least-important ones, to be honest. I don't know who will run 
clang-tidy and just trust it to apply whatever fixes it wants. More likely, the 
user will want to see a preview of findings and fixes, and fixit application 
will be done by some other tool. Therefore, implementing newline deletion in 
the code that applies all fixes is not going to be helpful for most workflows.

Therefore, I think the most appropriate place to do this cleanup is 
`cleanupAroundReplacements`. What do you think?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68682



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

[PATCH] D68682: Clang-tidy fix removals removing all non-blank text from a line should remove the line

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

In D68682#1705505 , @jonathanmeier 
wrote:

> In D68682#1702025 , @poelmanc wrote:
>
> > In D68682#1700908 , 
> > @Eugene.Zelenko wrote:
> >
> > > You may be interested to also look on PR43583 related to 
> > > readability-redundant-member-init.
> >
> >
> > Thanks Eugene, I'm having trouble finding that. 
> > https://reviews.llvm.org/D43583 seems related to MIPS instructions rather 
> > than readability-redundant-member-init. Could you please post a link? 
> > Thanks.
>
>
> PRs are bug reports. You can access them like this: https://llvm.org/PR43583


Or direct link to LLVM Bugzilla 
(https://bugs.llvm.org/show_bug.cgi?id=). Ideally Phabricator should 
recognize PR prefixes in same way as it recognize D.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68682



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

[clang-tools-extra] r374551 - Updated add_new_check.py to create checker tests in the new directory

[Dmitri Gribenko via cfe-commits]

Author: gribozavr
Date: Fri Oct 11 06:46:55 2019
New Revision: 374551

URL: http://llvm.org/viewvc/llvm-project?rev=374551&view=rev
Log:
Updated add_new_check.py to create checker tests in the new directory

Modified:
clang-tools-extra/trunk/clang-tidy/add_new_check.py

Modified: clang-tools-extra/trunk/clang-tidy/add_new_check.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/add_new_check.py?rev=374551&r1=374550&r2=374551&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/add_new_check.py (original)
+++ clang-tools-extra/trunk/clang-tidy/add_new_check.py Fri Oct 11 06:46:55 2019
@@ -269,7 +269,7 @@ def add_release_notes(module_path, modul
 # Adds a test for the check.
 def write_test(module_path, module, check_name, test_extension):
   check_name_dashes = module + '-' + check_name
-  filename = os.path.normpath(os.path.join(module_path, 
'../../test/clang-tidy',
+  filename = os.path.normpath(os.path.join(module_path, 
'../../test/clang-tidy/checkers',
check_name_dashes + '.' + 
test_extension))
   print('Creating %s...' % filename)
   with open(filename, 'w') as f:


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

r374552 - [libTooling] Change Stencil equality to use `toString()`

[Yitzhak Mandelbaum via cfe-commits]

Author: ymandel
Date: Fri Oct 11 07:02:03 2019
New Revision: 374552

URL: http://llvm.org/viewvc/llvm-project?rev=374552&view=rev
Log:
[libTooling] Change Stencil equality to use `toString()`

Summary:
Removes the `isEqual` method from StencilPartInterface and modifies equality to
use the string representation returned by the `toString` method for comparison.

This means the `run` and `selection` stencils return true by default, and
clients should be cautious in relying on equality operator for comparison of
stencils containing parts generated by these functions.

It also means we no longer need the custom RTTI support (typeId() and
down_cast()), so it has been removed.

Patch by Harshal T. Lehri.

Reviewers: gribozavr

Subscribers: cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/include/clang/Tooling/Transformer/Stencil.h
cfe/trunk/lib/Tooling/Transformer/Stencil.cpp
cfe/trunk/unittests/Tooling/StencilTest.cpp

Modified: cfe/trunk/include/clang/Tooling/Transformer/Stencil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Transformer/Stencil.h?rev=374552&r1=374551&r2=374552&view=diff
==
--- cfe/trunk/include/clang/Tooling/Transformer/Stencil.h (original)
+++ cfe/trunk/include/clang/Tooling/Transformer/Stencil.h Fri Oct 11 07:02:03 
2019
@@ -48,26 +48,18 @@ public:
   virtual llvm::Error eval(const ast_matchers::MatchFinder::MatchResult &Match,
std::string *Result) const = 0;
 
-  virtual bool isEqual(const StencilPartInterface &other) const = 0;
-
   /// Constructs a string representation of the StencilPart. StencilParts
   /// generated by the `selection` and `run` functions do not have a unique
   /// string representation.
   virtual std::string toString() const = 0;
 
-  const void *typeId() const { return TypeId; }
-
 protected:
-  StencilPartInterface(const void *DerivedId) : TypeId(DerivedId) {}
+  StencilPartInterface() = default;
 
   // Since this is an abstract class, copying/assigning only make sense for
   // derived classes implementing `clone()`.
   StencilPartInterface(const StencilPartInterface &) = default;
   StencilPartInterface &operator=(const StencilPartInterface &) = default;
-
-  /// Unique identifier of the concrete type of this instance.  Supports safe
-  /// downcasting.
-  const void *TypeId;
 };
 
 /// A copyable facade for a std::unique_ptr. Copies 
result
@@ -83,14 +75,6 @@ public:
 return Impl->eval(Match, Result);
   }
 
-  bool operator==(const StencilPart &Other) const {
-if (Impl == Other.Impl)
-  return true;
-if (Impl == nullptr || Other.Impl == nullptr)
-  return false;
-return Impl->isEqual(*Other.Impl);
-  }
-
   std::string toString() const {
 if (Impl == nullptr)
   return "";
@@ -142,7 +126,6 @@ public:
   }
 
 private:
-  friend bool operator==(const Stencil &A, const Stencil &B);
   static StencilPart wrap(llvm::StringRef Text);
   static StencilPart wrap(RangeSelector Selector);
   static StencilPart wrap(StencilPart Part) { return Part; }
@@ -150,12 +133,6 @@ private:
   std::vector Parts;
 };
 
-inline bool operator==(const Stencil &A, const Stencil &B) {
-  return A.Parts == B.Parts;
-}
-
-inline bool operator!=(const Stencil &A, const Stencil &B) { return !(A == B); 
}
-
 // Functions for conveniently building stencils.
 namespace stencil {
 /// Convenience wrapper for Stencil::cat that can be imported with a using 
decl.

Modified: cfe/trunk/lib/Tooling/Transformer/Stencil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Transformer/Stencil.cpp?rev=374552&r1=374551&r2=374552&view=diff
==
--- cfe/trunk/lib/Tooling/Transformer/Stencil.cpp (original)
+++ cfe/trunk/lib/Tooling/Transformer/Stencil.cpp Fri Oct 11 07:02:03 2019
@@ -31,14 +31,6 @@ using llvm::Error;
 using llvm::Expected;
 using llvm::StringError;
 
-// A down_cast function to safely down cast a StencilPartInterface to a 
subclass
-// D. Returns nullptr if P is not an instance of D.
-template  const D *down_cast(const StencilPartInterface *P) {
-  if (P == nullptr || D::typeId() != P->typeId())
-return nullptr;
-  return static_cast(P);
-}
-
 static llvm::Expected
 getNode(const ast_matchers::BoundNodes &Nodes, StringRef Id) {
   auto &NodesMap = Nodes.getMap();
@@ -100,35 +92,6 @@ struct IfBoundData {
   StencilPart FalsePart;
 };
 
-bool isEqualData(const RawTextData &A, const RawTextData &B) {
-  return A.Text == B.Text;
-}
-
-bool isEqualData(const DebugPrintNodeData &A, const DebugPrintNodeData &B) {
-  return A.Id == B.Id;
-}
-
-bool isEqualData(const UnaryOperationData &A, const UnaryOperationData &B) {
-  return A.Op == B.Op && A.Id == B.Id;
-}
-
-// Equality is not (yet) defined for \c RangeSelector.
-bool isEqualData(const SelectorData &, const SelectorData &) { r

[PATCH] D68825: [libTooling] Change Stencil equality to use `toString()`

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGcf2438ec1309: [libTooling] Change Stencil equality to use 
`toString()` (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68825

Files:
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/unittests/Tooling/StencilTest.cpp

Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -357,39 +357,6 @@
   testExpr(Id, "3;", cat(run(SimpleFn)), "Bound");
 }
 
-TEST(StencilEqualityTest, Equality) {
-  auto Lhs = cat("foo", dPrint("dprint_id"));
-  auto Rhs = cat("foo", dPrint("dprint_id"));
-  EXPECT_EQ(Lhs, Rhs);
-}
-
-TEST(StencilEqualityTest, InEqualityDifferentOrdering) {
-  auto Lhs = cat("foo", dPrint("node"));
-  auto Rhs = cat(dPrint("node"), "foo");
-  EXPECT_NE(Lhs, Rhs);
-}
-
-TEST(StencilEqualityTest, InEqualityDifferentSizes) {
-  auto Lhs = cat("foo", dPrint("node"), "bar", "baz");
-  auto Rhs = cat("foo", dPrint("node"), "bar");
-  EXPECT_NE(Lhs, Rhs);
-}
-
-// node is opaque and therefore cannot be examined for equality.
-TEST(StencilEqualityTest, InEqualitySelection) {
-  auto S1 = cat(node("node"));
-  auto S2 = cat(node("node"));
-  EXPECT_NE(S1, S2);
-}
-
-// `run` is opaque.
-TEST(StencilEqualityTest, InEqualityRun) {
-  auto F = [](const MatchResult &R) { return "foo"; };
-  auto S1 = cat(run(F));
-  auto S2 = cat(run(F));
-  EXPECT_NE(S1, S2);
-}
-
 TEST(StencilToStringTest, RawTextOp) {
   auto S = cat("foo bar baz");
   StringRef Expected = R"("foo bar baz")";
@@ -426,6 +393,11 @@
   EXPECT_EQ(S.toString(), Expected);
 }
 
+TEST(StencilToStringTest, SelectionOp) {
+  auto S1 = cat(node("node1"));
+  EXPECT_EQ(S1.toString(), "selection(...)");
+}
+
 TEST(StencilToStringTest, AccessOp) {
   auto S = cat(access("Id", text("memberData")));
   StringRef Expected = R"repr(access("Id", "memberData"))repr";
@@ -445,6 +417,12 @@
   EXPECT_EQ(S.toString(), Expected);
 }
 
+TEST(StencilToStringTest, RunOp) {
+  auto F1 = [](const MatchResult &R) { return "foo"; };
+  auto S1 = cat(run(F1));
+  EXPECT_EQ(S1.toString(), "run(...)");
+}
+
 TEST(StencilToStringTest, MultipleOp) {
   auto S = cat("foo", access("x", "m()"), "bar",
ifBound("x", text("t"), access("e", "f")));
Index: clang/lib/Tooling/Transformer/Stencil.cpp
===
--- clang/lib/Tooling/Transformer/Stencil.cpp
+++ clang/lib/Tooling/Transformer/Stencil.cpp
@@ -31,14 +31,6 @@
 using llvm::Expected;
 using llvm::StringError;
 
-// A down_cast function to safely down cast a StencilPartInterface to a subclass
-// D. Returns nullptr if P is not an instance of D.
-template  const D *down_cast(const StencilPartInterface *P) {
-  if (P == nullptr || D::typeId() != P->typeId())
-return nullptr;
-  return static_cast(P);
-}
-
 static llvm::Expected
 getNode(const ast_matchers::BoundNodes &Nodes, StringRef Id) {
   auto &NodesMap = Nodes.getMap();
@@ -100,35 +92,6 @@
   StencilPart FalsePart;
 };
 
-bool isEqualData(const RawTextData &A, const RawTextData &B) {
-  return A.Text == B.Text;
-}
-
-bool isEqualData(const DebugPrintNodeData &A, const DebugPrintNodeData &B) {
-  return A.Id == B.Id;
-}
-
-bool isEqualData(const UnaryOperationData &A, const UnaryOperationData &B) {
-  return A.Op == B.Op && A.Id == B.Id;
-}
-
-// Equality is not (yet) defined for \c RangeSelector.
-bool isEqualData(const SelectorData &, const SelectorData &) { return false; }
-
-bool isEqualData(const AccessData &A, const AccessData &B) {
-  return A.BaseId == B.BaseId && A.Member == B.Member;
-}
-
-bool isEqualData(const IfBoundData &A, const IfBoundData &B) {
-  return A.Id == B.Id && A.TruePart == B.TruePart && A.FalsePart == B.FalsePart;
-}
-
-// Equality is not defined over MatchConsumers, which are opaque.
-bool isEqualData(const MatchConsumer &A,
- const MatchConsumer &B) {
-  return false;
-}
-
 std::string toStringData(const RawTextData &Data) {
   std::string Result;
   llvm::raw_string_ostream OS(Result);
@@ -159,7 +122,7 @@
   return (OpName + "(\"" + Data.Id + "\")").str();
 }
 
-std::string toStringData(const SelectorData &) { return "SelectorData()"; }
+std::string toStringData(const SelectorData &) { return "selection(...)"; }
 
 std::string toStringData(const AccessData &Data) {
   return (llvm::Twine("access(\"") + Data.BaseId + "\", " +
@@ -174,7 +137,7 @@
 }
 
 std::string toStringData(const MatchConsumer &) {
-  return "MatchConsumer()";
+  return "run(...)";
 }
 
 // The `evalData()` overloads evaluate the given stencil data to a string, given
@@ -275,28 +238,13 @@
 
 public:
   template 
-  explicit StencilPartImpl(Ps &&... Args)
-  : StencilPartInterface(StencilPa

[PATCH] D68795: [libTooling] Move `RewriteRule` abstraction into its own header and impl.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

updated title & description to match the changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68795



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

[PATCH] D63960: [C++20] Add consteval-specific semantic for functions

[Tyker via Phabricator via cfe-commits]

Tyker updated this revision to Diff 224588.
Tyker added a comment.

improve performance in a bad case


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

https://reviews.llvm.org/D63960

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -12,6 +12,7 @@
 }
 
 constexpr auto l_eval = [](int i) consteval {
+// expected-note@-1+ {{declared here}}
 
   return i;
 };
@@ -23,6 +24,7 @@
 
 struct A {
   consteval int f1(int i) const {
+// expected-note@-1 {{declared here}}
 return i;
   }
   consteval A(int i);
@@ -62,3 +64,203 @@
 consteval int main() { // expected-error {{'main' is not allowed to be declared consteval}}
   return 0;
 }
+
+consteval int f_eval(int i) {
+// expected-note@-1+ {{declared here}}
+  return i;
+}
+
+namespace taking_address {
+
+using func_type = int(int);
+
+func_type* p1 = (&f_eval);
+// expected-error@-1 {{take address}}
+func_type* p7 = __builtin_addressof(f_eval);
+// expected-error@-1 {{take address}}
+
+auto p = f_eval;
+// expected-error@-1 {{take address}}
+
+auto m1 = &basic_sema::A::f1;
+// expected-error@-1 {{take address}}
+auto l1 = &decltype(basic_sema::l_eval)::operator();
+// expected-error@-1 {{take address}}
+
+consteval int f(int i) {
+// expected-note@-1+ {{declared here}}
+  return i;
+}
+
+auto ptr = &f;
+// expected-error@-1 {{take address}}
+
+auto f1() {
+  return &f;
+// expected-error@-1 {{take address}}
+}
+
+}
+
+namespace invalid_function {
+using size_t = unsigned long;
+struct A {
+  consteval void *operator new(size_t count);
+  // expected-error@-1 {{'operator new' cannot be declared consteval}}
+  consteval void *operator new[](size_t count);
+  // expected-error@-1 {{'operator new[]' cannot be declared consteval}}
+  consteval void operator delete(void* ptr);
+  // expected-error@-1 {{'operator delete' cannot be declared consteval}}
+  consteval void operator delete[](void* ptr);
+  // expected-error@-1 {{'operator delete[]' cannot be declared consteval}}
+};
+
+}
+
+namespace nested {
+consteval int f() {
+  return 0;
+}
+
+consteval int f1(...) {
+  return 1;
+}
+
+enum E {};
+
+using T = int(&)();
+
+consteval auto operator+ (E, int(*a)()) {
+  return 0;
+}
+
+void d() {
+  auto i = f1(E() + &f);
+}
+
+auto l0 = [](auto) consteval {
+  return 0;
+};
+
+int i0 = l0(&f1);
+
+int i1 = f1(l0(4));
+
+int i2 = f1(&f1, &f1, &f1, &f1, &f1, &f1, &f1);
+
+int i3 = f1(f1(f1(&f1, &f1), f1(&f1, &f1), f1(f1(&f1, &f1), &f1)));
+
+}
+
+namespace user_defined_literal {
+
+consteval int operator"" _test(unsigned long long i) {
+// expected-note@-1+ {{declared here}}
+  return 0;
+}
+
+int i = 0_test;
+
+auto ptr = &operator"" _test;
+// expected-error@-1 {{take address}}
+
+}
+
+namespace return_address {
+
+consteval int f() {
+  return 0;
+}
+
+consteval int(*ret1(int i))() {
+  return &f;
+}
+
+auto ptr = ret1(0);
+// expected-error@-1 {{could not be evaluated}}
+// expected-note@-2 {{pointer to a consteval}}
+
+struct A {
+  consteval int f(int) {
+return 0;
+  }
+};
+
+using mem_ptr_type = int (A::*)(int);
+
+template
+struct C {};
+
+C<&A::f> c;
+// expected-error@-1 {{is not a constant expression}}
+// expected-note@-2 {{pointer to a consteval}}
+
+consteval mem_ptr_type ret2() {
+  return &A::f;
+}
+
+C c1;
+// expected-error@-1 {{is not a constant expression}}
+// expected-note@-2 {{pointer to a consteval}}
+
+}
+
+namespace context {
+
+int g_i;
+// expected-note@-1 {{declared here}}
+
+consteval int f(int) {
+  return 0;
+}
+
+constexpr int c_i = 0;
+
+int t1 = f(g_i);
+// expected-error@-1 {{could not be evaluated}}
+// expected-note@-2 {{read of non-const variable}}
+int t3 = f(c_i);
+
+constexpr int f_c(int i) {
+// expected-note@-1 {{declared here}}
+  int t = f(i);
+// expected-error@-1 {{could not be evaluated}}
+// expected-note@-2 {{read of non-const variable}}
+  return f(0);  
+}
+
+consteval int f_eval(int i) {
+  return f(i);
+}
+
+auto l0 = [](int i) consteval {
+  return f(i);
+};
+
+auto l1 = [](int i) constexpr {
+// expected-note@-1 {{declared here}}
+  int t = f(i);
+// expected-error@-1 {{could not be evaluated}}
+// expected-note@-2 {{read of non-const variable}}
+  return f(0);  
+};
+
+}
+
+namespace cleanup {
+
+struct A {
+ 

[PATCH] D68162: [analyzer][MallocChecker][NFC] Communicate the allocation family to auxiliary functions with parameters

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

I forgot to emphasise that the entire point of the patch was to get rid of 
`getAllocationFamily`, at least the way it used to work, because it was a mess 
and prevented me from moving forward with changing things to a 
`CallDescriptionMap`.

In D68162#1693110 , 
@baloghadamsoftware wrote:

> I like this change. If we can retrieve something with a simple getter, then 
> do not carry extra parameters all over the code. However, if we have to 
> recalculate something over and over again then it is much better to determine 
> it once and pass it around as a parameter. Especially in this case where we 
> have the information statically at top level and do not have to calculate it 
> all if we use that.




In D68162#1686810 , @NoQ wrote:

> My mental model for this sort of stuff is something like this:
>
>   CallDescriptionMap M = {
> "malloc", {&MallocChecker::MallocMemAux, AF_Malloc},
> "alloca", {&MallocChecker::MallocMemAux, AF_Alloca},
>   };
>  
>   void checkPostCall(const CallEvent &Call, CheckerContext &C) {
> if (Info *I = M.lookup(Call))
>   I->first(I->second, C, Call);
>   }
>


I guess you two are right. Maybe the best solution would be collapse `const 
CallExpr *` and `AllocationFamily` parameters into `CallEvent`, and just query 
the relevant information. Sure, its a query every time we need it, but nothing 
impacts performance as much as months of hair pulling trying to understand what 
this file does :^)


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

https://reviews.llvm.org/D68162



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

[PATCH] D67706: [clang][analyzer] Using CallDescription in StreamChecker.

[Balázs Kéri via Phabricator via cfe-commits]

balazske added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67706



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

r374558 - [libTooling] Move `RewriteRule` abstraction into its own header and impl.

[Yitzhak Mandelbaum via cfe-commits]

Author: ymandel
Date: Fri Oct 11 07:43:46 2019
New Revision: 374558

URL: http://llvm.org/viewvc/llvm-project?rev=374558&view=rev
Log:
[libTooling] Move `RewriteRule` abstraction into its own header and impl.

Summary: Move the `RewriteRule` class and related declarations into its own set
of files (header, implementation). Only the `Transformer` class is left in the
Transformer-named files. This change clarifies the distinction between the
`RewriteRule` class, which is essential to the Transformer library, and the
`Transformer` class, which is only one possible `RewriteRule` interpreter
(compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter).

Reviewers: gribozavr

Subscribers: jfb, cfe-commits

Tags: #clang

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

Added:
cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h
cfe/trunk/lib/Tooling/Transformer/RewriteRule.cpp
Modified:
cfe/trunk/include/clang/Tooling/Transformer/Transformer.h
cfe/trunk/lib/Tooling/Transformer/CMakeLists.txt
cfe/trunk/lib/Tooling/Transformer/Transformer.cpp

Added: cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h?rev=374558&view=auto
==
--- cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h (added)
+++ cfe/trunk/include/clang/Tooling/Transformer/RewriteRule.h Fri Oct 11 
07:43:46 2019
@@ -0,0 +1,288 @@
+//===--- RewriteRule.h - RewriteRule class --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+///
+///  \file
+///  Defines the RewriteRule class and related functions for creating,
+///  modifying and interpreting RewriteRules.
+///
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_TRANSFORMER_REWRITE_RULE_H_
+#define LLVM_CLANG_TOOLING_TRANSFORMER_REWRITE_RULE_H_
+
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/ASTMatchers/ASTMatchersInternal.h"
+#include "clang/Tooling/Refactoring/AtomicChange.h"
+#include "clang/Tooling/Transformer/MatchConsumer.h"
+#include "clang/Tooling/Transformer/RangeSelector.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/Support/Error.h"
+#include 
+#include 
+#include 
+
+namespace clang {
+namespace tooling {
+using TextGenerator = MatchConsumer;
+
+/// Wraps a string as a TextGenerator.
+inline TextGenerator text(std::string M) {
+  return [M](const ast_matchers::MatchFinder::MatchResult &)
+ -> Expected { return M; };
+}
+
+// Description of a source-code edit, expressed in terms of an AST node.
+// Includes: an ID for the (bound) node, a selector for source related to the
+// node, a replacement and, optionally, an explanation for the edit.
+//
+// * Target: the source code impacted by the rule. This identifies an AST node,
+//   or part thereof (\c Part), whose source range indicates the extent of the
+//   replacement applied by the replacement term.  By default, the extent is 
the
+//   node matched by the pattern term (\c NodePart::Node). Target's are typed
+//   (\c Kind), which guides the determination of the node extent.
+//
+// * Replacement: a function that produces a replacement string for the target,
+//   based on the match result.
+//
+// * Note: (optional) a note specifically for this edit, potentially 
referencing
+//   elements of the match.  This will be displayed to the user, where 
possible;
+//   for example, in clang-tidy diagnostics.  Use of notes should be rare --
+//   explanations of the entire rewrite should be set in the rule
+//   (`RewriteRule::Explanation`) instead.  Notes serve the rare cases wherein
+//   edit-specific diagnostics are required.
+//
+// `ASTEdit` should be built using the `change` convenience functions. For
+// example,
+// \code
+//   change(name(fun), text("Frodo"))
+// \endcode
+// Or, if we use Stencil for the TextGenerator:
+// \code
+//   using stencil::cat;
+//   change(statement(thenNode), cat("{", thenNode, "}"))
+//   change(callArgs(call), cat(x, ",", y))
+// \endcode
+// Or, if you are changing the node corresponding to the rule's matcher, you 
can
+// use the single-argument override of \c change:
+// \code
+//   change(cat("different_expr"))
+// \endcode
+struct ASTEdit {
+  RangeSelector TargetRange;
+  TextGenerator Replacement;
+  TextGenerator Note;
+};
+
+/// Format of the path in an include directive -- angle brackets or quotes.
+enum class IncludeFormat {
+  Quoted,
+  Angled,
+};
+
+/// Description of a source-code transformation.
+//
+// A *rewrit

[PATCH] D68795: [libTooling] Move `RewriteRule` abstraction into its own header and impl.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe38c36b7b0ab: [libTooling] Move `RewriteRule` abstraction 
into its own header and impl. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68795

Files:
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Transformer.h
  clang/lib/Tooling/Transformer/CMakeLists.txt
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Transformer.cpp

Index: clang/lib/Tooling/Transformer/Transformer.cpp
===
--- clang/lib/Tooling/Transformer/Transformer.cpp
+++ clang/lib/Tooling/Transformer/Transformer.cpp
@@ -7,20 +7,11 @@
 //===--===//
 
 #include "clang/Tooling/Transformer/Transformer.h"
-#include "clang/AST/Expr.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/ASTMatchers/ASTMatchers.h"
-#include "clang/Basic/Diagnostic.h"
+#include "clang/ASTMatchers/ASTMatchersInternal.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Rewrite/Core/Rewriter.h"
 #include "clang/Tooling/Refactoring/AtomicChange.h"
-#include "clang/Tooling/Transformer/SourceCode.h"
-#include "llvm/ADT/Optional.h"
-#include "llvm/ADT/StringRef.h"
-#include "llvm/Support/Errc.h"
 #include "llvm/Support/Error.h"
-#include 
-#include 
 #include 
 #include 
 
@@ -28,168 +19,13 @@
 using namespace tooling;
 
 using ast_matchers::MatchFinder;
-using ast_matchers::internal::DynTypedMatcher;
-using ast_type_traits::ASTNodeKind;
-using ast_type_traits::DynTypedNode;
-using llvm::Error;
-using llvm::StringError;
-
-using MatchResult = MatchFinder::MatchResult;
-
-Expected>
-tooling::detail::translateEdits(const MatchResult &Result,
-llvm::ArrayRef Edits) {
-  SmallVector Transformations;
-  for (const auto &Edit : Edits) {
-Expected Range = Edit.TargetRange(Result);
-if (!Range)
-  return Range.takeError();
-llvm::Optional EditRange =
-getRangeForEdit(*Range, *Result.Context);
-// FIXME: let user specify whether to treat this case as an error or ignore
-// it as is currently done.
-if (!EditRange)
-  return SmallVector();
-auto Replacement = Edit.Replacement(Result);
-if (!Replacement)
-  return Replacement.takeError();
-tooling::detail::Transformation T;
-T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-Transformations.push_back(std::move(T));
-  }
-  return Transformations;
-}
-
-ASTEdit tooling::change(RangeSelector S, TextGenerator Replacement) {
-  ASTEdit E;
-  E.TargetRange = std::move(S);
-  E.Replacement = std::move(Replacement);
-  return E;
-}
-
-RewriteRule tooling::makeRule(DynTypedMatcher M, SmallVector Edits,
-  TextGenerator Explanation) {
-  return RewriteRule{{RewriteRule::Case{
-  std::move(M), std::move(Edits), std::move(Explanation), {;
-}
-
-void tooling::addInclude(RewriteRule &Rule, StringRef Header,
- IncludeFormat Format) {
-  for (auto &Case : Rule.Cases)
-Case.AddedIncludes.emplace_back(Header.str(), Format);
-}
-
-#ifndef NDEBUG
-// Filters for supported matcher kinds. FIXME: Explicitly list the allowed kinds
-// (all node matcher types except for `QualType` and `Type`), rather than just
-// banning `QualType` and `Type`.
-static bool hasValidKind(const DynTypedMatcher &M) {
-  return !M.canConvertTo();
-}
-#endif
-
-// Binds each rule's matcher to a unique (and deterministic) tag based on
-// `TagBase` and the id paired with the case.
-static std::vector taggedMatchers(
-StringRef TagBase,
-const SmallVectorImpl> &Cases) {
-  std::vector Matchers;
-  Matchers.reserve(Cases.size());
-  for (const auto &Case : Cases) {
-std::string Tag = (TagBase + Twine(Case.first)).str();
-// HACK: Many matchers are not bindable, so ensure that tryBind will work.
-DynTypedMatcher BoundMatcher(Case.second.Matcher);
-BoundMatcher.setAllowBind(true);
-auto M = BoundMatcher.tryBind(Tag);
-Matchers.push_back(*std::move(M));
-  }
-  return Matchers;
-}
-
-// Simply gathers the contents of the various rules into a single rule. The
-// actual work to combine these into an ordered choice is deferred to matcher
-// registration.
-RewriteRule tooling::applyFirst(ArrayRef Rules) {
-  RewriteRule R;
-  for (auto &Rule : Rules)
-R.Cases.append(Rule.Cases.begin(), Rule.Cases.end());
-  return R;
-}
-
-std::vector
-tooling::detail::buildMatchers(const RewriteRule &Rule) {
-  // Map the cases into buckets of matchers -- one for each "root" AST kind,
-  // which guarantees that they can be combined in a single anyOf matcher. Each
-  // case is paired with an identifying number that is converted to a string id
-  // in `taggedMatchers`.

r374562 - Reland r374450 with Richard Smith's comments and test fixed.

[Erich Keane via cfe-commits]

Author: erichkeane
Date: Fri Oct 11 07:59:44 2019
New Revision: 374562

URL: http://llvm.org/viewvc/llvm-project?rev=374562&view=rev
Log:
Reland r374450 with Richard Smith's comments and test fixed.

The behavior from the original patch has changed, since we're no longer
allowing LLVM to just ignore the alignment.  Instead, we're just
assuming the maximum possible alignment.

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/CodeGen/builtin-assume-aligned.c

cfe/trunk/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-three-params-variable.cpp

cfe/trunk/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-three-params.cpp

cfe/trunk/test/CodeGen/catch-alignment-assumption-builtin_assume_aligned-two-params.cpp
cfe/trunk/test/Sema/builtin-assume-aligned.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=374562&r1=374561&r2=374562&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Oct 11 07:59:44 
2019
@@ -2853,6 +2853,10 @@ def err_alignment_dependent_typedef_name
 
 def err_attribute_aligned_too_great : Error<
   "requested alignment must be %0 bytes or smaller">;
+def warn_assume_aligned_too_great
+: Warning<"requested alignment must be %0 bytes or smaller; maximum "
+  "alignment assumed">,
+  InGroup>;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,
   InGroup;

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=374562&r1=374561&r2=374562&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Oct 11 07:59:44 2019
@@ -2048,11 +2048,13 @@ RValue CodeGenFunction::EmitBuiltinExpr(
 
 Value *AlignmentValue = EmitScalarExpr(E->getArg(1));
 ConstantInt *AlignmentCI = cast(AlignmentValue);
-unsigned Alignment = (unsigned)AlignmentCI->getZExtValue();
+if (AlignmentCI->getValue().ugt(llvm::Value::MaximumAlignment))
+  AlignmentCI = ConstantInt::get(AlignmentCI->getType(),
+ llvm::Value::MaximumAlignment);
 
 EmitAlignmentAssumption(PtrValue, Ptr,
 /*The expr loc is sufficient.*/ SourceLocation(),
-Alignment, OffsetValue);
+AlignmentCI, OffsetValue);
 return RValue::get(PtrValue);
   }
   case Builtin::BI__assume:

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=374562&r1=374561&r2=374562&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Oct 11 07:59:44 2019
@@ -4569,7 +4569,7 @@ RValue CodeGenFunction::EmitCall(const C
   llvm::Value *Alignment = EmitScalarExpr(AA->getAlignment());
   llvm::ConstantInt *AlignmentCI = cast(Alignment);
   EmitAlignmentAssumption(Ret.getScalarVal(), RetTy, Loc, 
AA->getLocation(),
-  AlignmentCI->getZExtValue(), OffsetValue);
+  AlignmentCI, OffsetValue);
 } else if (const auto *AA = TargetDecl->getAttr()) {
   llvm::Value *AlignmentVal = CallArgs[AA->getParamIndex().getLLVMIndex()]
   .getRValue(*this)

Modified: cfe/trunk/lib/CodeGen/CGExprScalar.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExprScalar.cpp?rev=374562&r1=374561&r2=374562&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExprScalar.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExprScalar.cpp Fri Oct 11 07:59:44 2019
@@ -294,8 +294,7 @@ public:
 
 Value *AlignmentValue = CGF.EmitScalarExpr(AVAttr->getAlignment());
 llvm::ConstantInt *AlignmentCI = cast(AlignmentValue);
-CGF.EmitAlignmentAssumption(V, E, AVAttr->getLocation(),
-AlignmentCI->getZExtValue());
+CGF.EmitAlignmentAssumption(V, E, AVAttr->getLocation(), AlignmentCI);
   }
 
   /// EmitLoadOfLValue - Given an expression with complex type that represents 
a

Modified: cf

[PATCH] D67706: [clang][analyzer] Using CallDescription in StreamChecker.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:288-290
+  SymbolRef Sym = RetVal.getAsSymbol();
+  stateNotNull = stateNotNull->set(Sym, StreamState::getOpened());
+  stateNull = stateNull->set(Sym, StreamState::getOpenFailed());

Aha, so we're no longer checking whether `Sym` is null, because why would we, 
we literally made created it as a symbol a couple lines up. Is it worth 
`assert()`ing though?



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:296-297
 
-ProgramStateRef StreamChecker::CheckNullStream(SVal SV, ProgramStateRef state,
-CheckerContext &C) const {
+Optional
+StreamChecker::CheckNullStream(SVal SV, CheckerContext &C) const {
   Optional DV = SV.getAs();

Why is there a need to use an `Optional`? Why not just return a `nullptr`? As I 
saw it, each time we check both whether the optional has a value //and// 
whether the state within it is null.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:319-320
 
-ProgramStateRef StreamChecker::CheckDoubleClose(const CallExpr *CE,
-   ProgramStateRef state,
-   CheckerContext &C) const {
-  SymbolRef Sym = C.getSVal(CE->getArg(0)).getAsSymbol();
+Optional
+StreamChecker::CheckDoubleClose(const CallEvent &Call,
+CheckerContext &C) const {

And here too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67706



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

[PATCH] D67551: [AArch64][SVE] Implement sdot and udot (lane) intrinsics

[Sander de Smalen via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D67551



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

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun marked 2 inline comments as done.
vladimir.plyashkun added inline comments.



Comment at: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp:23-24
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.getLocalOrGlobal("IgnorePositiveIntegerLiterals", false)) {}
+

lebedev.ri wrote:
> vladimir.plyashkun wrote:
> > lebedev.ri wrote:
> > > i'm not sure this should look for a global option with such name?
> > I think that this method is common and used in so many inspections. 
> > For example this [[ 
> > https://clang.llvm.org/extra/clang-tidy/checks/readability-inconsistent-declaration-parameter-name.html
> >   | check ]] also have option called `IgnoreMacros` which is retrieved in 
> > same way (by calling getLocalOrGlobal method)
> I'm very specifically discriminating against 
> `"IgnorePositiveIntegerLiterals"` here.
> I know `getLocalOrGlobal()` is widely used, because in those places the same 
> flag
> is used in multiple modules with same meaning.
> Is that the case here?
Ok, i agree. Fixed.



Comment at: 
clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp:19
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator

JonasToth wrote:
> Could you please add `URes << 1` as well? I believe that was problematic in 
> the stack-overflow-question, wasn't it?
Yes, sure.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun updated this revision to Diff 224597.

Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694

Files:
  clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
  clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
  clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp


Index: 
clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
@@ -0,0 +1,33 @@
+// RUN: %check_clang_tidy %s hicpp-signed-bitwise %t -- \
+// RUN:   -config="{CheckOptions: [{key: 
hicpp-signed-bitwise.IgnorePositiveIntegerLiterals, value: 1 }]}" \
+// RUN: -- -std=c++11
+
+void examples() {
+  unsigned UValue = 40u;
+  unsigned URes;
+  
+  URes = UValue & 1u; //Ok
+  URes = UValue & -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use of a signed integer operand 
with a binary bitwise operator
+  
+  unsigned URes2 = URes << 1; //Ok
+  
+  int IResult;
+  IResult = 10 & 2; //Ok
+  IResult = 3 << -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator
+  
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand 
with a binary bitwise operator
+  IResult = ~0; //Ok
+}
+
+enum EnumConstruction {
+  one = 1,
+  two = 2,
+  test1 = 1 << 12, //Ok
+  test2 = one << two,
+  // CHECK-MESSAGES: :[[@LINE-1]]:11: warning: use of a signed integer operand 
with a binary bitwise operator
+  test3 = 1u << 12, //Ok
+};
Index: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
===
--- clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
+++ clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.h
@@ -22,10 +22,13 @@
 /// http://clang.llvm.org/extra/clang-tidy/checks/hicpp-signed-bitwise.html
 class SignedBitwiseCheck : public ClangTidyCheck {
 public:
-  SignedBitwiseCheck(StringRef Name, ClangTidyContext *Context)
-  : ClangTidyCheck(Name, Context) {}
+  SignedBitwiseCheck(StringRef Name, ClangTidyContext *Context);
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+  void storeOptions(ClangTidyOptions::OptionMap &Options) override;
+
+private:
+  bool IgnorePositiveIntegerLiterals;
 };
 
 } // namespace hicpp
Index: clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
===
--- clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
+++ clang-tools-extra/clang-tidy/hicpp/SignedBitwiseCheck.cpp
@@ -17,9 +17,24 @@
 namespace tidy {
 namespace hicpp {
 
+SignedBitwiseCheck::SignedBitwiseCheck(StringRef Name,
+   ClangTidyContext *Context)
+: ClangTidyCheck(Name, Context),
+  IgnorePositiveIntegerLiterals(
+  Options.get("IgnorePositiveIntegerLiterals", false)) {}
+
+void SignedBitwiseCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
+  Options.store(Opts, "IgnorePositiveIntegerLiterals",
+IgnorePositiveIntegerLiterals);
+}
+
 void SignedBitwiseCheck::registerMatchers(MatchFinder *Finder) {
   const auto SignedIntegerOperand =
-  
expr(ignoringImpCasts(hasType(isSignedInteger(.bind("signed-operand");
+  (IgnorePositiveIntegerLiterals
+   ? expr(ignoringImpCasts(hasType(isSignedInteger())),
+  unless(integerLiteral()))
+   : expr(ignoringImpCasts(hasType(isSignedInteger()
+  .bind("signed-operand");
 
   // The standard [bitmask.types] allows some integral types to be implemented
   // as signed types. Exclude these types from diagnosing for bitwise or(|) and


Index: clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/hicpp-signed-bitwise-integer-literals.cpp
@@ -0,0 +1,33 @@
+// RUN: %check_clang_tidy %s hicpp-signed-bitwise %t -- \
+// RUN:   -config="{CheckOptions: [{key: hicpp-signed-bitwise.IgnorePositiveIntegerLiterals, value: 1 }]}" \
+// RUN: -- -std=c++11
+
+void examples() {
+  unsigned UValue = 40u;
+  unsigned URes;
+  
+  URes = UValue & 1u; //Ok
+  URes = UValue & -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: use of a signed integer operand with a binary bitwise operator
+  
+  unsigned URes2 = URes << 1; //Ok
+  
+  int IResult;
+  IResult = 10 & 2; //Ok
+  IResult = 3 << -1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer operand with a binary bitwise operator
+  
+  int Int = 30;
+  IResult = Int << 1;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: use of a signed integer o

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Vladimir Plyashkun via Phabricator via cfe-commits]

vladimir.plyashkun added a comment.

In D68694#1705668 , @JonasToth wrote:

> The new switch needs documentation as well, and maybe even a note in the 
> release notes (as it is publicly discussed as issue?).


Do you know who is responsible for it? Because i haven't worked with 
documentation before and don't know what i need to do to update it.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D67156: [Analyzer] Debug Checkers for Container and Iterator Inspection

[Kristóf Umann via Phabricator via cfe-commits]

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

This is amazing, thanks!! LGTM.


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

https://reviews.llvm.org/D67156



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

[PATCH] D68746: [Clang][OpenMP Offload] Move offload registration code to the wrapper

[Sergey Dmitriev via Phabricator via cfe-commits]

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



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:74
+  IntegerType *getSizeTTy() {
+switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {
+case 4u:

grokos wrote:
> sdmitriev wrote:
> > ABataev wrote:
> > > sdmitriev wrote:
> > > > ABataev wrote:
> > > > > Same question as before: maybe better to make the size of size_t type 
> > > > > a parameter of a tool?
> > > > As I remember you also had another suggestion - change size_t to 
> > > > intptr_t. That will eliminate the need to an additional parameter for 
> > > > size type. Will it be better?
> > > In thi case we'll need to change the type in the libomptarget.
> > Right. @grokos , do you see any potential problems in changing 
> > __tgt_offload_entry::size type from size_t to intptr_t?
> As long as `intptr_t` has the same size as `size_t` it should be fine. Of 
> course, if this is not the case, then if libomptarget tries to load an older 
> image where `sizeof(__tgt_offload_entry::size) != sizeof(intptr_t)` then 
> backwards compatibility will have been broken. Fortunately, on all platforms 
> supported by released versions of libomptarget so far (x86_64, ppc64, 
> aarch64) if I'm not mistaken `sizeof(size_t) == sizeof(initptr_t)`, so I 
> don't think we'll break anything.
@ABataev, as I understand clang CG assumes that intptr_t, size_t, and ptrdiff_t 
are the same types.
Please look at clang/lib/CodeGen/CodeGenTypeCache.h, lines 44-49

```
  /// intptr_t, size_t, and ptrdiff_t, which we assume are the same size.
  union {
llvm::IntegerType *IntPtrTy;
llvm::IntegerType *SizeTy;
llvm::IntegerType *PtrDiffTy;
  };
```
So, I guess what we have here is Ok.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68746



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

[PATCH] D67706: [clang][analyzer] Using CallDescription in StreamChecker.

[Balázs Kéri via Phabricator via cfe-commits]

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



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:288-290
+  SymbolRef Sym = RetVal.getAsSymbol();
+  stateNotNull = stateNotNull->set(Sym, StreamState::getOpened());
+  stateNull = stateNull->set(Sym, StreamState::getOpenFailed());

Szelethus wrote:
> Aha, so we're no longer checking whether `Sym` is null, because why would we, 
> we literally made created it as a symbol a couple lines up. Is it worth 
> `assert()`ing though?
Probably better to have the assert.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:296-297
 
-ProgramStateRef StreamChecker::CheckNullStream(SVal SV, ProgramStateRef state,
-CheckerContext &C) const {
+Optional
+StreamChecker::CheckNullStream(SVal SV, CheckerContext &C) const {
   Optional DV = SV.getAs();

Szelethus wrote:
> Why is there a need to use an `Optional`? Why not just return a `nullptr`? As 
> I saw it, each time we check both whether the optional has a value //and// 
> whether the state within it is null.
The idea was that there are 3 kind of return values: Change to a new state, do 
not change to new state, or error was found. In the first and last case we 
should return `true` from `evalCall` but not if there is no state to change 
into and the analysis can proceed in default way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67706



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

[PATCH] D67551: [AArch64][SVE] Implement sdot and udot (lane) intrinsics

[Kerry McLaughlin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGee0a0a34646f: [AArch64][SVE] Implement sdot and udot (lane) 
intrinsics (authored by kmclaughlin).
Herald added a subscriber: hiraditya.
Herald added a project: LLVM.

Changed prior to commit:
  https://reviews.llvm.org/D67551?vs=220096&id=224608#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67551

Files:
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/test/CodeGen/AArch64/sve-intrinsics-int-arith.ll

Index: llvm/test/CodeGen/AArch64/sve-intrinsics-int-arith.ll
===
--- llvm/test/CodeGen/AArch64/sve-intrinsics-int-arith.ll
+++ llvm/test/CodeGen/AArch64/sve-intrinsics-int-arith.ll
@@ -88,6 +88,87 @@
   ret  %out
 }
 
+; SDOT
+
+define  @sdot_i32( %a,  %b,  %c) {
+; CHECK-LABEL: sdot_i32:
+; CHECK: sdot z0.s, z1.b, z2.b
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.sdot.nxv4i32( %a,
+ %b,
+ %c)
+  ret  %out
+}
+
+define  @sdot_i64( %a,  %b,  %c) {
+; CHECK-LABEL: sdot_i64:
+; CHECK: sdot z0.d, z1.h, z2.h
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.sdot.nxv2i64( %a,
+ %b,
+ %c)
+  ret  %out
+}
+
+; SDOT (Indexed)
+
+define  @sdot_lane_i32( %a,  %b,  %c) {
+; CHECK-LABEL: sdot_lane_i32:
+; CHECK: sdot z0.s, z1.b, z2.b[2]
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.sdot.lane.nxv4i32( %a,
+  %b,
+  %c,
+ i32 2)
+  ret  %out
+}
+
+define  @sdot_lane_i64( %a,  %b,  %c) {
+; CHECK-LABEL: sdot_lane_i64:
+; CHECK: sdot z0.d, z1.h, z2.h[1]
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.sdot.lane.nxv2i64( %a,
+  %b,
+  %c,
+ i32 1)
+  ret  %out
+}
+
+; UDOT
+
+define  @udot_i32( %a,  %b,  %c) {
+; CHECK-LABEL: udot_i32:
+; CHECK: udot z0.s, z1.b, z2.b
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.udot.nxv4i32( %a,
+ %b,
+ %c)
+  ret  %out
+}
+
+define  @udot_i64( %a,  %b,  %c) {
+; CHECK-LABEL: udot_i64:
+; CHECK: udot z0.d, z1.h, z2.h
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.udot.nxv2i64( %a,
+ %b,
+ %c)
+  ret  %out
+}
+
+; UDOT (Indexed)
+
+define  @udot_lane_i32( %a,  %b,  %c) {
+; CHECK-LABEL: udot_lane_i32:
+; CHECK: udot z0.s, z1.b, z2.b[2]
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.udot.lane.nxv4i32( %a,
+  %b,
+  %c,
+ i32 2)
+  ret  %out
+}
+
 declare  @llvm.aarch64.sve.abs.nxv16i8(, , )
 declare  @llvm.aarch64.sve.abs.nxv8i16(, , )
 declare  @llvm.aarch64.sve.abs.nxv4i32(, , )
@@ -97,3 +178,15 @@
 declare  @llvm.aarch64.sve.neg.nxv8i16(, , )
 declare  @llvm.aarch64.sve.neg.nxv4i32(, , )
 declare  @llvm.aarch64.sve.neg.nxv2i64(, , )
+
+declare  @llvm.aarch64.sve.sdot.nxv4i32(, , )
+declare  @llvm.aarch64.sve.sdot.nxv2i64(, , )
+
+declare  @llvm.aarch64.sve.sdot.lane.nxv4i32(, , , i32)
+declare  @llvm.aarch64.sve.sdot.lane.nxv2i64(, , , i32)
+
+declare  @llvm.aarch64.sve.udot.nxv4i32(, , )
+declare  @llvm.aarch64.sve.udot.nxv2i64(, , )
+
+declare  @llvm.aarch64.sve.udot.lane.nxv4i32(, , , i32)
+declare  @llvm.aarch64.sve.udot.lane.nxv2i64(, , , i32)
Index: llvm/lib/Target/AArch64/SVEInstrFormats.td
===
--- llvm/lib/Target/AArch64/SVEInstrFormats.td
+++ llvm/lib/Target/AArch64/SVEInstrFormats.td
@@ -2024,12 +2024,14 @@
 
   let Constraints = "$Zda = $_Zda";
   let DestructiveInstType = Destructive;
-  let ElementSize = zprty1.ElementSize;
 }
 
-multiclass sve_intx_dot {
+multiclass sve_intx_dot {
   def _S : sve_intx_dot<0b0, opc, asm, ZPR32, ZPR8>;
   def _D : sve_intx_dot<0b1, opc, asm, ZPR64, ZPR16>;
+
+  def : SVE_3_Op_Pat(NAME # _S)>;
+  def : SVE_3_Op_Pat(NAME # _D)>;
 }
 
 //===--

[PATCH] D68746: [Clang][OpenMP Offload] Move offload registration code to the wrapper

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/tools/clang-offload-wrapper/ClangOffloadWrapper.cpp:74
+  IntegerType *getSizeTTy() {
+switch (M.getDataLayout().getPointerTypeSize(Type::getInt8PtrTy(C))) {
+case 4u:

sdmitriev wrote:
> grokos wrote:
> > sdmitriev wrote:
> > > ABataev wrote:
> > > > sdmitriev wrote:
> > > > > ABataev wrote:
> > > > > > Same question as before: maybe better to make the size of size_t 
> > > > > > type a parameter of a tool?
> > > > > As I remember you also had another suggestion - change size_t to 
> > > > > intptr_t. That will eliminate the need to an additional parameter for 
> > > > > size type. Will it be better?
> > > > In thi case we'll need to change the type in the libomptarget.
> > > Right. @grokos , do you see any potential problems in changing 
> > > __tgt_offload_entry::size type from size_t to intptr_t?
> > As long as `intptr_t` has the same size as `size_t` it should be fine. Of 
> > course, if this is not the case, then if libomptarget tries to load an 
> > older image where `sizeof(__tgt_offload_entry::size) != sizeof(intptr_t)` 
> > then backwards compatibility will have been broken. Fortunately, on all 
> > platforms supported by released versions of libomptarget so far (x86_64, 
> > ppc64, aarch64) if I'm not mistaken `sizeof(size_t) == sizeof(initptr_t)`, 
> > so I don't think we'll break anything.
> @ABataev, as I understand clang CG assumes that intptr_t, size_t, and 
> ptrdiff_t are the same types.
> Please look at clang/lib/CodeGen/CodeGenTypeCache.h, lines 44-49
> 
> ```
>   /// intptr_t, size_t, and ptrdiff_t, which we assume are the same size.
>   union {
> llvm::IntegerType *IntPtrTy;
> llvm::IntegerType *SizeTy;
> llvm::IntegerType *PtrDiffTy;
>   };
> ```
> So, I guess what we have here is Ok.
Ok, fix at least other comment(s)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68746



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

r374569 - Fix test failure with 374562 on Hexagon

[Erich Keane via cfe-commits]

Author: erichkeane
Date: Fri Oct 11 09:30:45 2019
New Revision: 374569

URL: http://llvm.org/viewvc/llvm-project?rev=374569&view=rev
Log:
Fix test failure with 374562 on Hexagon

__builtin_assume_aligned takes a size_t which is a 32 bit int on
hexagon.  Thus, the constant gets converted to a 32 bit value, resulting
in 0 not being a power of 2.  This patch changes the constant being
passed to 2**30 so that it fails, but doesnt exceed 30 bits.

Modified:
cfe/trunk/test/Sema/builtin-assume-aligned.c

Modified: cfe/trunk/test/Sema/builtin-assume-aligned.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtin-assume-aligned.c?rev=374569&r1=374568&r2=374569&view=diff
==
--- cfe/trunk/test/Sema/builtin-assume-aligned.c (original)
+++ cfe/trunk/test/Sema/builtin-assume-aligned.c Fri Oct 11 09:30:45 2019
@@ -59,6 +59,6 @@ void *test_no_fn_proto() __attribute__((
 void *test_no_fn_proto() __attribute__((assume_aligned(32, 45, 37))); // 
expected-error {{'assume_aligned' attribute takes no more than 2 arguments}}
 
 int pr43638(int *a) {
-  a = __builtin_assume_aligned(a, 4294967296); // expected-warning {{requested 
alignment must be 536870912 bytes or smaller; maximum alignment assumed}}
+  a = __builtin_assume_aligned(a, 1073741824); // expected-warning {{requested 
alignment must be 536870912 bytes or smaller; maximum alignment assumed}}
 return a[0];
 }


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

[PATCH] D68876: [libTooling] Group all Transformer combinators in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added a reviewer: gribozavr.
Herald added a project: clang.

This revision introduces a new namespace, `clang::tooling::transformer`, to hold
the combinators that together compose the embedded "DSL" provided by
Transformer.  It moves all Transformer-related combinators into this namespace,
while leaving other Transformer declarations in the `clang::tooling` namespace.
This structure mirrors that of `clang::ast_matchers`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D68876

Files:
  clang/include/clang/Tooling/Transformer/MatchConsumer.h
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/lib/Tooling/Transformer/RangeSelector.cpp
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/unittests/Tooling/StencilTest.cpp

Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -17,6 +17,7 @@
 
 using namespace clang;
 using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -27,15 +28,6 @@
 using ::testing::Eq;
 using ::testing::HasSubstr;
 using MatchResult = MatchFinder::MatchResult;
-using stencil::access;
-using stencil::addressOf;
-using stencil::cat;
-using stencil::deref;
-using stencil::dPrint;
-using stencil::expression;
-using stencil::ifBound;
-using stencil::run;
-using stencil::text;
 
 // Create a valid translation-unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
Index: clang/lib/Tooling/Transformer/Stencil.cpp
===
--- clang/lib/Tooling/Transformer/Stencil.cpp
+++ clang/lib/Tooling/Transformer/Stencil.cpp
@@ -250,11 +250,11 @@
 } // namespace
 
 StencilPart Stencil::wrap(StringRef Text) {
-  return stencil::text(Text);
+  return transformer::text(Text);
 }
 
 StencilPart Stencil::wrap(RangeSelector Selector) {
-  return stencil::selection(std::move(Selector));
+  return transformer::selection(std::move(Selector));
 }
 
 void Stencil::append(Stencil OtherStencil) {
@@ -271,46 +271,46 @@
   return Result;
 }
 
-StencilPart stencil::text(StringRef Text) {
+StencilPart transformer::text(StringRef Text) {
   return StencilPart(std::make_shared>(Text));
 }
 
-StencilPart stencil::selection(RangeSelector Selector) {
+StencilPart transformer::selection(RangeSelector Selector) {
   return StencilPart(
   std::make_shared>(std::move(Selector)));
 }
 
-StencilPart stencil::dPrint(StringRef Id) {
+StencilPart transformer::dPrint(StringRef Id) {
   return StencilPart(std::make_shared>(Id));
 }
 
-StencilPart stencil::expression(llvm::StringRef Id) {
+StencilPart transformer::expression(llvm::StringRef Id) {
   return StencilPart(std::make_shared>(
   UnaryNodeOperator::Parens, Id));
 }
 
-StencilPart stencil::deref(llvm::StringRef ExprId) {
+StencilPart transformer::deref(llvm::StringRef ExprId) {
   return StencilPart(std::make_shared>(
   UnaryNodeOperator::Deref, ExprId));
 }
 
-StencilPart stencil::addressOf(llvm::StringRef ExprId) {
+StencilPart transformer::addressOf(llvm::StringRef ExprId) {
   return StencilPart(std::make_shared>(
   UnaryNodeOperator::Address, ExprId));
 }
 
-StencilPart stencil::access(StringRef BaseId, StencilPart Member) {
+StencilPart transformer::access(StringRef BaseId, StencilPart Member) {
   return StencilPart(
   std::make_shared>(BaseId, std::move(Member)));
 }
 
-StencilPart stencil::ifBound(StringRef Id, StencilPart TruePart,
+StencilPart transformer::ifBound(StringRef Id, StencilPart TruePart,
  StencilPart FalsePart) {
   return StencilPart(std::make_shared>(
   Id, std::move(TruePart), std::move(FalsePart)));
 }
 
-StencilPart stencil::run(MatchConsumer Fn) {
+StencilPart transformer::run(MatchConsumer Fn) {
   return StencilPart(
   std::make_shared>>(
   std::move(Fn)));
Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -54,20 +54,20 @@
   return Transformations;
 }
 
-ASTEdit tooling::change(RangeSelector S, TextGenerator Replacement) {
+ASTEdit transformer::change(RangeSelector S, TextGenerator Replacement) {
   ASTEdit E;
   E.TargetRange = std::move(S);
   E.Replacement = std::move(Replacement);
   return E;
 }
 
-RewriteRule tooling::makeRule(DynTypedMatcher M, SmallVector Edits,
+RewriteRule transformer::makeRule(DynTypedMatcher M, SmallVector Edits,
   TextGenerator Explanation) {
   return RewriteRule{{RewriteRule::Case{
   std::move(M), std::move(Edits), std::move(Explanation), {}}}

[PATCH] D68876: [libTooling] Group all Transformer combinators in a single namespace.

[Dmitri Gribenko via Phabricator via cfe-commits]

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

WDYT about `clang::transformer`? I don't see much point in the intermediate 
namespace. However, LGTM either way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

r374571 - Update clang module map for new excluded .def file.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri Oct 11 10:00:34 2019
New Revision: 374571

URL: http://llvm.org/viewvc/llvm-project?rev=374571&view=rev
Log:
Update clang module map for new excluded .def file.

Modified:
cfe/trunk/include/clang/module.modulemap

Modified: cfe/trunk/include/clang/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/module.modulemap?rev=374571&r1=374570&r2=374571&view=diff
==
--- cfe/trunk/include/clang/module.modulemap (original)
+++ cfe/trunk/include/clang/module.modulemap Fri Oct 11 10:00:34 2019
@@ -18,6 +18,7 @@ module Clang_AST {
   umbrella "AST"
 
   textual header "AST/BuiltinTypes.def"
+  textual header "AST/CXXRecordDeclDefinitionBits.def"
   textual header "AST/OperationKinds.def"
   textual header "AST/TypeLocNodes.def"
 


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

Re: r374449 - Add -fgnuc-version= to control __GNUC__ and other GCC macros

[Nico Weber via cfe-commits]

It's cool we finally have a flag for this, but overloading its meaning with
the =0 behavior seems a bit strange to me. Maybe we should have a separate
-fno-gnu-extensions for that part instead?

On Thu, Oct 10, 2019 at 5:02 PM Reid Kleckner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rnk
> Date: Thu Oct 10 14:04:25 2019
> New Revision: 374449
>
> URL: http://llvm.org/viewvc/llvm-project?rev=374449&view=rev
> Log:
> Add -fgnuc-version= to control __GNUC__ and other GCC macros
>
> I noticed that compiling on Windows with -fno-ms-compatibility had the
> side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and
> a number of other macros for GCC compatibility. This is undesirable and
> causes Chromium to do things like mix __attribute__ and __declspec,
> which doesn't work. We should have a positive language option to enable
> GCC compatibility features so that we can experiment with
> -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be
> that option.
>
> My issue aside, users have, for a long time, reported that __GNUC__
> doesn't match their expectations in one way or another. We have
> encouraged users to migrate code away from this macro, but new code
> continues to be written assuming a GCC-only environment. There's really
> nothing we can do to stop that. By adding this flag, we can allow them
> to choose their own adventure with __GNUC__.
>
> This overlaps a bit with the "GNUMode" language option from -std=gnu*.
> The gnu language mode tends to enable non-conforming behaviors that we'd
> rather not enable by default, but the we want to set things like
> __GXX_RTTI__ by default, so I've kept these separate.
>
> Helps address PR42817
>
> Reviewed By: hans, nickdesaulniers, MaskRay
>
> Differential Revision: https://reviews.llvm.org/D68055
>
> Added:
> cfe/trunk/test/Driver/fgnuc-version.c
> Modified:
> cfe/trunk/docs/ReleaseNotes.rst
> cfe/trunk/docs/UsersManual.rst
> cfe/trunk/include/clang/Basic/LangOptions.def
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> cfe/trunk/test/Driver/rewrite-legacy-objc.m
> cfe/trunk/test/Driver/rewrite-objc.m
> cfe/trunk/test/Frontend/gnu-inline.c
> cfe/trunk/test/Headers/stdbool.cpp
> cfe/trunk/test/Preprocessor/init.c
> cfe/trunk/test/Sema/atomic-ops.c
>
> Modified: cfe/trunk/docs/ReleaseNotes.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=374449&r1=374448&r2=374449&view=diff
>
> ==
> --- cfe/trunk/docs/ReleaseNotes.rst (original)
> +++ cfe/trunk/docs/ReleaseNotes.rst Thu Oct 10 14:04:25 2019
> @@ -80,7 +80,10 @@ Non-comprehensive list of changes in thi
>  New Compiler Flags
>  --
>
> -- ...
> +- The -fgnuc-version= flag now controls the value of ``__GNUC__`` and
> related
> +  macros. This flag does not enable or disable any GCC extensions
> implemented in
> +  Clang. Setting the version to zero causes Clang to leave ``__GNUC__``
> and
> +  other GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined.
>
>  Deprecated Compiler Flags
>  -
>
> Modified: cfe/trunk/docs/UsersManual.rst
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=374449&r1=374448&r2=374449&view=diff
>
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Thu Oct 10 14:04:25 2019
> @@ -701,6 +701,13 @@ Other Options
>  -
>  Clang options that don't fit neatly into other categories.
>
> +.. option:: -fgnuc-version=
> +
> +  This flag controls the value of ``__GNUC__`` and related macros. This
> flag
> +  does not enable or disable any GCC extensions implemented in Clang.
> Setting
> +  the version to zero causes Clang to leave ``__GNUC__`` and other
> +  GNU-namespaced macros, such as ``__GXX_WEAK__``, undefined.
> +
>  .. option:: -MV
>
>When emitting a dependency file, use formatting conventions appropriate
>
> Modified: cfe/trunk/include/clang/Basic/LangOptions.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=374449&r1=374448&r2=374449&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/LangOptions.def (original)
> +++ cfe/trunk/include/clang/Basic/LangOptions.def Thu Oct 10 14:04:25 2019
> @@ -111,6 +111,7 @@ BENIGN_LANGOPT(DollarIdents   , 1, 1, "'
>  BENIGN_LANGOPT(AsmPreprocessor, 1, 0, "preprocessor in asm mode")
>  LANGOPT(GNUMode   , 1, 1, "GNU extensions")
>  LANGOPT(GNUKeywords   , 1, 1, "GNU keywords")
> +VALUE_LANGOPT(GNUCVersion , 32, 0, "GNU C compatibility version")
>  BENIGN_LANGOPT(ImplicitInt, 1,

[PATCH] D68746: [Clang][OpenMP Offload] Move offload registration code to the wrapper

[Alexey Bataev via Phabricator via cfe-commits]

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

LG


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

https://reviews.llvm.org/D68746



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

[PATCH] D68877: [AArch64][SVE] Implement masked load intrinsics

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin created this revision.
kmclaughlin added reviewers: huntergr, rovka, greened.
Herald added subscribers: psnobl, rkruppe, hiraditya, kristof.beyls, tschuett.
Herald added a project: LLVM.
kmclaughlin added a parent revision: D47775: [AArch64][SVE] Add SPLAT_VECTOR 
ISD Node.

Adds support for codegen of masked loads, with non-extending,
zero-extending and sign-extending variants.

Depends on the changes in D47775  for 
isConstantSplatVectorMaskForType


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D68877

Files:
  llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/TargetLoweringBase.cpp
  llvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/test/CodeGen/AArch64/sve-masked-ldst-nonext.ll
  llvm/test/CodeGen/AArch64/sve-masked-ldst-sext.ll
  llvm/test/CodeGen/AArch64/sve-masked-ldst-zext.ll

Index: llvm/test/CodeGen/AArch64/sve-masked-ldst-zext.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-masked-ldst-zext.ll
@@ -0,0 +1,72 @@
+; RUN: llc -mtriple=aarch64--linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; Masked Loads
+;
+
+define  @masked_zload_nxv2i8(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv2i8:
+; CHECK-NOT: ld1sb
+; CHECK: ld1b { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i8(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+define  @masked_zload_nxv2i16(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv2i16:
+; CHECK-NOT: ld1sh
+; CHECK: ld1h { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i16(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+define  @masked_zload_nxv2i32(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv2i32:
+; CHECK-NOT: ld1sw
+; CHECK: ld1w { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i32(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+define  @masked_zload_nxv4i8(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv4i8:
+; CHECK-NOT: ld1sb
+; CHECK: ld1b { [[IN:z[0-9]+]].s }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv4i8(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+define  @masked_zload_nxv4i16(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv4i16:
+; CHECK-NOT: ld1sh
+; CHECK: ld1h { [[IN:z[0-9]+]].s }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv4i16(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+define  @masked_zload_nxv8i8(* %src,  %mask) {
+; CHECK-LABEL: masked_zload_nxv8i8:
+; CHECK-NOT: ld1sb
+; CHECK: ld1b { [[IN:z[0-9]+]].h }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv8i8(* %src, i32 1,  %mask,  undef)
+  %ext = zext  %load to 
+  ret  %ext
+}
+
+declare  @llvm.masked.load.nxv2i8(*, i32, , )
+declare  @llvm.masked.load.nxv2i16(*, i32, , )
+declare  @llvm.masked.load.nxv2i32(*, i32, , )
+declare  @llvm.masked.load.nxv4i8(*, i32, , )
+declare  @llvm.masked.load.nxv4i16(*, i32, , )
+declare  @llvm.masked.load.nxv8i8(*, i32, , )
Index: llvm/test/CodeGen/AArch64/sve-masked-ldst-sext.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-masked-ldst-sext.ll
@@ -0,0 +1,66 @@
+; RUN: llc -mtriple=aarch64--linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; Masked Loads
+;
+
+define  @masked_sload_nxv2i8( *%a,  %mask) {
+; CHECK-LABEL: masked_sload_nxv2i8:
+; CHECK: ld1sb { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i8( *%a, i32 1,  %mask,  undef)
+  %ext = sext  %load to 
+  ret  %ext
+}
+
+define  @masked_sload_nxv2i16( *%a,  %mask) {
+; CHECK-LABEL: masked_sload_nxv2i16:
+; CHECK: ld1sh { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i16( *%a, i32 1,  %mask,  undef)
+  %ext = sext  %load to 
+  ret  %ext
+}
+
+define  @masked_sload_nxv2i32( *%a,  %mask) {
+; CHECK-LABEL: masked_sload_nxv2i32:
+; CHECK: ld1sw { [[IN:z[0-9]+]].d }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv2i32( *%a, i32 1,  %mask,  undef)
+  %ext = sext  %load to 
+  ret  %ext
+}
+
+define  @masked_sload_nxv4i8( *%a,  %mask) {
+; CHECK-LABEL: masked_sload_nxv4i8:
+; CHECK: ld1sb { [[IN:z[0-9]+]].s }, [[PG:p[0-9]+]]/z, [x0]
+; CHECK-NEXT: ret
+  %load = call  @llvm.masked.load.nxv4i8( *%a, i32 1,  %mask,  undef)
+  %ext = sext  %load to 
+  ret  %ext
+}
+
+define  @masked_sload_nxv4i16( *%

[PATCH] D68876: [libTooling] Group all Transformer combinators in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

In D68876#1706131 , @gribozavr wrote:

> WDYT about `clang::transformer`? I don't see much point in the intermediate 
> namespace. However, LGTM either way.


Thanks for the review. I prefer `clang::transformer` but wasn't sure about 
ettiquete of introducing new namespaces under `clang`. If that's ok, then I'm 
happy to update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

r374573 - [clang][IFS] Fixing assert in clang interface stubs for enums, records, typedefs

[Puyan Lotfi via cfe-commits]

Author: zer0
Date: Fri Oct 11 10:24:11 2019
New Revision: 374573

URL: http://llvm.org/viewvc/llvm-project?rev=374573&view=rev
Log:
[clang][IFS] Fixing assert in clang interface stubs for enums, records, typedefs

The clang IFS ASTConsumer was asserting on enums, records (struct definitions in
C), and typedefs. All it needs to do is skip them because the stub just needs to
expose global object instances and functions.

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

Added:
cfe/trunk/test/InterfaceStubs/noninstancetypes.c
Modified:
cfe/trunk/lib/Frontend/InterfaceStubFunctionsConsumer.cpp

Modified: cfe/trunk/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InterfaceStubFunctionsConsumer.cpp?rev=374573&r1=374572&r2=374573&view=diff
==
--- cfe/trunk/lib/Frontend/InterfaceStubFunctionsConsumer.cpp (original)
+++ cfe/trunk/lib/Frontend/InterfaceStubFunctionsConsumer.cpp Fri Oct 11 
10:24:11 2019
@@ -177,6 +177,10 @@ class InterfaceStubFunctionsConsumer : p
   HandleTemplateSpecializations(*cast(ND), Symbols,
 RDO);
   return true;
+case Decl::Kind::Record:
+case Decl::Kind::Typedef:
+case Decl::Kind::Enum:
+case Decl::Kind::EnumConstant:
 case Decl::Kind::TemplateTypeParm:
   return true;
 case Decl::Kind::Var:

Added: cfe/trunk/test/InterfaceStubs/noninstancetypes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/InterfaceStubs/noninstancetypes.c?rev=374573&view=auto
==
--- cfe/trunk/test/InterfaceStubs/noninstancetypes.c (added)
+++ cfe/trunk/test/InterfaceStubs/noninstancetypes.c Fri Oct 11 10:24:11 2019
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -o - -emit-interface-stubs %s | FileCheck %s
+// TODO: Change clang_cc1 to clang when llvm-ifs can accept empty symbol lists.
+
+// CHECK:  Symbols:
+// CHECK-NEXT: ...
+
+struct a;
+enum { b };
+typedef int c;
+


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

[PATCH] D68720: Support -fstack-clash-protection for x86

[serge via Phabricator via cfe-commits]

serge-sans-paille updated this revision to Diff 224606.
serge-sans-paille added a comment.

Ensure the distance between two probes is at max PAGE_SIZE.
Use Calls as free probes.
Fix alignment for dynamic alloca

This passes the llvm-test suite, and thanks to the use of calls, no inserted 
probe are needed to compile sqlite!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68720

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/stack-clash-protection.c
  clang/test/Driver/stack-clash-protection.c
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/CodeGen/TargetLowering.h
  llvm/lib/Target/X86/X86CallFrameOptimization.cpp
  llvm/lib/Target/X86/X86FrameLowering.cpp
  llvm/lib/Target/X86/X86FrameLowering.h
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/lib/Target/X86/X86ISelLowering.h
  llvm/lib/Target/X86/X86InstrCompiler.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/test/CodeGen/X86/stack-clash-dynamic-alloca.ll
  llvm/test/CodeGen/X86/stack-clash-medium-natural-probes.ll
  llvm/test/CodeGen/X86/stack-clash-medium.ll
  llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
  llvm/test/CodeGen/X86/stack-clash-small.ll

Index: llvm/test/CodeGen/X86/stack-clash-small.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-small.ll
@@ -0,0 +1,19 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: foo:
+define i32 @foo() local_unnamed_addr #0 {
+; only one stack growth
+; CHECK: subq
+; CHECK-NOT: subq
+  %a = alloca i32, i64 100, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 98
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-no-free-probe.ll
@@ -0,0 +1,20 @@
+; RUN: llc < %s | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: foo:
+define i32 @foo(i64 %i) local_unnamed_addr #0 {
+; CHECK: subq   $4096, %rsp
+; the store location is not statically known, no free probe
+; CHECK: movq   $0, (%rsp)
+; CHECK: subq   ${{[0-9]+}}, %rsp
+  %a = alloca i32, i32 2000, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 %i
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
+
Index: llvm/test/CodeGen/X86/stack-clash-medium.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-medium.ll
@@ -0,0 +1,21 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: foo:
+define i32 @foo() local_unnamed_addr #0 {
+; two stack growth, with a natural probe inbetween and an extra probe afterward
+; CHECK: subq
+; CHECK: movl
+; CHECK: subq
+; CHECK: movq $0
+  %a = alloca i32, i64 2000, align 16
+  %b = getelementptr inbounds i32, i32* %a, i64 1198
+  store volatile i32 1, i32* %b
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-medium-natural-probes.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/stack-clash-medium-natural-probes.ll
@@ -0,0 +1,25 @@
+; RUN: llc < %s | FileCheck %s
+
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+; CHECK-LABEL: foo:
+define i32 @foo() local_unnamed_addr #0 {
+; two stack growth, with an extra probe inbetween and a natural probe afterward
+; CHECK: subq
+; CHECK-NOT: movq $0
+; CHECK: mov
+; CHECK: subq
+; CHECK-NOT: movq $0
+; CHECK: mov
+  %a = alloca i32, i64 2000, align 16
+  %b0 = getelementptr inbounds i32, i32* %a, i64 98
+  %b1 = getelementptr inbounds i32, i32* %a, i64 1198
+  store volatile i32 1, i32* %b0
+  store volatile i32 1, i32* %b1
+  %c = load volatile i32, i32* %a
+  ret i32 %c
+}
+
+attributes #0 =  {"probe-stack"="inline-asm"}
Index: llvm/test/CodeGen/X86/stack-clash-dynamic-alloca.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X

[PATCH] D68845: Don't emit unwanted constructor calls in co_return statements

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

Quuxplusone added a subscriber: lewissbaker.
Quuxplusone added a comment.

One more test to add:

  struct Widget {
  task foo() && {
  co_return *this;  // IIUC this should call return_value(Widget&), not 
return_value(Widget&&)
  }
  };




Comment at: clang/lib/Sema/SemaCoroutine.cpp:869
   if (E) {
-auto NRVOCandidate = this->getCopyElisionCandidate(E->getType(), E, 
CES_AsIfByStdMove);
-if (NRVOCandidate) {
-  InitializedEntity Entity =
-  InitializedEntity::InitializeResult(Loc, E->getType(), 
NRVOCandidate);
-  ExprResult MoveResult = this->PerformMoveOrCopyInitialization(
-  Entity, NRVOCandidate, E->getType(), E);
-  if (MoveResult.get())
-E = MoveResult.get();
-}
+VarDecl *NRVOCandidate =
+getCopyElisionCandidate(E->getType(), E, CES_Default);

aaronpuchert wrote:
> Quuxplusone wrote:
> > aaronpuchert wrote:
> > > Should be renamed to `RVOCandidate`, I don't think NRVO can happen here.
> > (Btw, I have no comment on the actual code change in this patch. I'm here 
> > in my capacity as 
> > [RVO-explainer](https://www.youtube.com/watch?v=hA1WNtNyNbo)-and-[P1155](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1155r2.html)-author,
> >  not code-understander. ;))
> > 
> > What's happening here is never technically "RVO" at all, because there is 
> > no "RV". However, the "N" is accurate. (See [my acronym 
> > glossary](https://quuxplusone.github.io/blog/2019/08/02/the-tough-guide-to-cpp-acronyms/#rvo-nrvo-urvo)
> >  for details.)
> > The important thing here is that when you say `co_return x;` the `x` is 
> > //named//, and it //would be// a candidate for NRVO if we were in a 
> > situation where NRVO was possible at all.
> > 
> > The actual optimization that is happening here is "implicit move."
> > 
> > I would strongly prefer to keep the name `NRVOCandidate` here, because that 
> > is the name that is used for the exact same purpose — computing "implicit 
> > move" candidates — in `BuildReturnStmt`. Ideally this code would be 
> > factored out so that it appeared in only one place; but until then, 
> > gratuitous differences between the two sites should be minimized IMO.
> Hmm, you're completely right. What do you think about 
> `ImplicitMoveCandidate`? Otherwise I'll stick with the current name, as you 
> suggested.
> 
> > Ideally this code would be factored out so that it appeared in only one 
> > place; but until then, gratuitous differences between the two sites should 
> > be minimized IMO.
> 
> Isn't it already factored out? I let `getCopyElisionCandidate` do all the 
> heavy lifting. (Except filtering out lvalue references...)
> What do you think about `ImplicitMoveCandidate`?

I think that would be more correct in this case, but it wouldn't be parallel 
with the one in `BuildReturnStmt`, and I'm not sure whether it would be correct 
to change it over there too.

> Isn't it already factored out?

I see some parallelism in the two other places that call 
`getCopyElisionCandidate` followed by `PerformMoveOrCopyInitialization`. Maybe 
this is as factored-out as it can get, but it still looks remarkably parallel. 
(And I wish `NRVOVariable` was named `NRVOCandidate` in the latter case.)

In `BuildReturnStmt`:

if (RetValExp)
  NRVOCandidate = getCopyElisionCandidate(FnRetType, RetValExp, CES_Strict);
if (!HasDependentReturnType && !RetValExp->isTypeDependent()) {
  // we have a non-void function with an expression, continue checking
  InitializedEntity Entity = InitializedEntity::InitializeResult(ReturnLoc,
 RetType,
  NRVOCandidate != nullptr);
  ExprResult Res = PerformMoveOrCopyInitialization(Entity, NRVOCandidate,
   RetType, RetValExp);

In `BuildCXXThrow`:

const VarDecl *NRVOVariable = nullptr;
if (IsThrownVarInScope)
  NRVOVariable = getCopyElisionCandidate(QualType(), Ex, CES_Strict);

InitializedEntity Entity = InitializedEntity::InitializeException(
OpLoc, ExceptionObjectTy,
/*NRVO=*/NRVOVariable != nullptr);
ExprResult Res = PerformMoveOrCopyInitialization(
Entity, NRVOVariable, QualType(), Ex, IsThrownVarInScope);

Naming-wise, I also offer that David Stone's 
[P1825](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1825r0.html) 
introduces the name "implicitly movable entity" for these things, and //maybe// 
we should call this variable `ImplicitlyMovableEntity`; however, I am not yet 
sure.



Comment at: clang/test/SemaCXX/coroutine-rvo.cpp:71
+task param2val(MoveOnly value) {
+  co_return value;
 }

aaronpuchert wrote:
> Quuxplusone wrote:
> > This should work equally well with `NoCopyNoMove`, right? It should just 
> > call `task::return_value(NCNM&&)`. I don't think you need `MoveOnly`

[PATCH] D68859: Fixing crash in clang IFS for enum, record, and typedef decls.

[Puyan Lotfi via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe3388c42f39b: [clang][IFS] Fixing assert in clang interface 
stubs for enums, records, typedefs (authored by plotfi).

Changed prior to commit:
  https://reviews.llvm.org/D68859?vs=224547&id=224629#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68859

Files:
  clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
  clang/test/InterfaceStubs/noninstancetypes.c


Index: clang/test/InterfaceStubs/noninstancetypes.c
===
--- /dev/null
+++ clang/test/InterfaceStubs/noninstancetypes.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -o - -emit-interface-stubs %s | FileCheck %s
+// TODO: Change clang_cc1 to clang when llvm-ifs can accept empty symbol lists.
+
+// CHECK:  Symbols:
+// CHECK-NEXT: ...
+
+struct a;
+enum { b };
+typedef int c;
+
Index: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
===
--- clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
+++ clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
@@ -177,6 +177,10 @@
   HandleTemplateSpecializations(*cast(ND), Symbols,
 RDO);
   return true;
+case Decl::Kind::Record:
+case Decl::Kind::Typedef:
+case Decl::Kind::Enum:
+case Decl::Kind::EnumConstant:
 case Decl::Kind::TemplateTypeParm:
   return true;
 case Decl::Kind::Var:


Index: clang/test/InterfaceStubs/noninstancetypes.c
===
--- /dev/null
+++ clang/test/InterfaceStubs/noninstancetypes.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -o - -emit-interface-stubs %s | FileCheck %s
+// TODO: Change clang_cc1 to clang when llvm-ifs can accept empty symbol lists.
+
+// CHECK:  Symbols:
+// CHECK-NEXT: ...
+
+struct a;
+enum { b };
+typedef int c;
+
Index: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
===
--- clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
+++ clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp
@@ -177,6 +177,10 @@
   HandleTemplateSpecializations(*cast(ND), Symbols,
 RDO);
   return true;
+case Decl::Kind::Record:
+case Decl::Kind::Typedef:
+case Decl::Kind::Enum:
+case Decl::Kind::EnumConstant:
 case Decl::Kind::TemplateTypeParm:
   return true;
 case Decl::Kind::Var:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68694: [clang-tidy] hicpp-signed-bitwise: Do not show "use of a signed integer operand with a binary bitwise operator" for positive integer operands

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

> Do you know who is responsible for it? Because i haven't worked with 
> documentation before and don't know what i need to do to update it.

The files reside in `clang-tools-extra/docs/ReleaseNotes.rst` and 
`clang-tools-extra/docs/clang-tidy/checks/hicpp-signed-bitwise.rst`.

You can check other files for reference, e.g. `readability-magic-numbers.rst`.
In the Release Notes you can add one entry at the end of the clang-tidy section.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68694



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

[PATCH] D47111: : Implement monotonic_buffer_resource.

[strager via Phabricator via cfe-commits]

strager added inline comments.



Comment at: include/experimental/memory_resource:427
+static _LIBCPP_CONSTEXPR const size_t __default_buffer_capacity = 1024;
+static _LIBCPP_CONSTEXPR const size_t __default_buffer_alignment = 16;
+

Nit: Why isn't `__default_buffer_alignment` set to `alignof(max_align_t)` 
(which I think is 16)? I think `alignof(max_align_t)` is a good, portable 
default.



Comment at: include/experimental/memory_resource:431-432
+__chunk_header *__next_;
+char *__start_;
+char *__cur_;
+size_t __align_;

Nit: Would it make sense to use `std::byte` instead of `char`?



Comment at: 
test/libcxx/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_in_geometric_progression.pass.cpp:32
+assert(globalMemCounter.checkOutstandingNewEq(0));
+}
+

Nit: This test is named allocate_in_geometric_progression. I don't see any 
multiplication or anything happening in this test case. Did you mean to call 
this test something else, like release_deletes_upstream_memory?



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_deallocate.pass.cpp:28
+std::experimental::pmr::monotonic_buffer_resource 
mono1(std::experimental::pmr::new_delete_resource());
+std::experimental::pmr::memory_resource & r1 = mono1;
+

Nit: What is the purpose of the `r1` variable? Why not use `mono1` everywhere 
instead (and rename `mono1` to `r1` if you like `r1` better than `mono1` as a 
name)?



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_exception_safety.pass.cpp:48-49
+void *res = r1.allocate(64, 16);
+assert(res == buffer);
+assert(globalMemCounter.checkNewCalledEq(0));
+

Nit: These assertions look unrelated to exception safety to me. (The test is 
named allocate_exception_safety.) I'd delete these assertions.



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_exception_safety.pass.cpp:52-54
+assert(res != buffer);
+assert(globalMemCounter.checkNewCalledEq(1));
+assert(globalMemCounter.checkDeleteCalledEq(0));

(Same comment as on lines 48-49 above. I'd delete these assertions.)



Comment at: 
test/std/experimental/memory/memory.resource.monotonic.buffer/monotonic.buffer.mem/allocate_exception_safety.pass.cpp:67-68
+
+upstream.which = std::experimental::pmr::new_delete_resource();
+res = r1.allocate(last_new_size, 16);
+assert(res != buffer);

Question about the intended behavior of `monotonic_buffer_resource`:

If line 68 instead allocated 1 byte, and the byte could fit in the original 
heap allocation (line 51), should `monotonic_buffer_resource` return a byte 
from that original resource? In other words, should the following test pass?

```
repointable_resource upstream(std::experimental::pmr::new_delete_resource());
std::experimental::pmr::monotonic_buffer_resource mono1(&upstream);

globalMemCounter.reset();
mono1.allocate(1, 1);
const size_t first_new_size = globalMemCounter.last_new_size;
bool mono1_has_spare_capacity = first_new_size == 1;

upstream.which = std::experimental::pmr::null_memory_resource();
try {
mono1.allocate(first_new_size, 1); // Force allocation from upstream.
assert(false);
} catch (const std::bad_alloc&) {
// we expect this
}

globalMemCounter.reset();
mono1.allocate(1, 1);
if (mono1_has_spare_capacity) {
  assert(globalMemCounter.checkNewCalledEq(0));
} else {
  assert(globalMemCounter.checkNewCalledEq(1));
}
```

Similarly, if `monotonic_buffer_resource` was given a buffer, and that buffer 
still has spare capacity, should that capacity be reused? In other words, 
should the following test pass?

```
int first_allocation_size = 20;
int second_allocation_size = 30;

auto *upstream = std::experimental::pmr::null_memory_resource();
char buffer[64];
assert(sizeof buffer >= first_allocation_size + second_allocation_size);
std::experimental::pmr::monotonic_buffer_resource mono1(buffer, sizeof buffer, 
upstream);

globalMemCounter.reset();
void *first_allocation = mono1.allocate(first_allocation_size, 1);
assert(first_allocation == &buffer[0]);

try {
mono1.allocate(sizeof buffer, 1); // Force allocation from upstream.
assert(false);
} catch (const std::bad_alloc&) {
// we expect this
}

void *second_allocation = mono1.allocate(second_allocation_size, 1);
assert(second_allocation == &buffer[second_allocation_size]);
```

I think these scenarios would be useful to test, in addition to the scenario in 
your test here.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D47111

[PATCH] D47111: : Implement monotonic_buffer_resource.

[strager via Phabricator via cfe-commits]

strager added inline comments.



Comment at: include/experimental/memory_resource:433
+char *__cur_;
+size_t __align_;
+size_t __allocation_size() {

> Eric suggests replacing size_t __align_ with uint8_t __log2_align_. I'm 
> amenable to this idea, but I'd want to know what's the best way to compute 
> the log2 of a user-supplied number.

Perhaps `std::log2p1` could help: 
https://en.cppreference.com/w/cpp/numeric/log2p1


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D47111



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

r374580 - Suppress false-positive -Wdeprecated-volatile warning from __is_*_assignable(volatile T&, U).

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri Oct 11 10:59:09 2019
New Revision: 374580

URL: http://llvm.org/viewvc/llvm-project?rev=374580&view=rev
Log:
Suppress false-positive -Wdeprecated-volatile warning from 
__is_*_assignable(volatile T&, U).

Modified:
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/deprecated.cpp

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=374580&r1=374579&r2=374580&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Fri Oct 11 10:59:09 2019
@@ -5243,7 +5243,13 @@ static bool EvaluateBinaryTypeTrait(Sema
 Sema::ContextRAII TUContext(Self, Self.Context.getTranslationUnitDecl());
 ExprResult Result = Self.BuildBinOp(/*S=*/nullptr, KeyLoc, BO_Assign, &Lhs,
 &Rhs);
-if (Result.isInvalid() || SFINAE.hasErrorOccurred())
+if (Result.isInvalid())
+  return false;
+
+// Treat the assignment as unused for the purpose of -Wdeprecated-volatile.
+Self.CheckUnusedVolatileAssignment(Result.get());
+
+if (SFINAE.hasErrorOccurred())
   return false;
 
 if (BTT == BTT_IsAssignable)

Modified: cfe/trunk/test/SemaCXX/deprecated.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/deprecated.cpp?rev=374580&r1=374579&r2=374580&view=diff
==
--- cfe/trunk/test/SemaCXX/deprecated.cpp (original)
+++ cfe/trunk/test/SemaCXX/deprecated.cpp Fri Oct 11 10:59:09 2019
@@ -178,6 +178,8 @@ namespace DeprecatedVolatile {
 n /= 2; // cxx20-warning {{compound assignment to object of 
volatile-qualified type 'volatile int' is deprecated}}
 n %= 42; // cxx20-warning {{compound assignment to object of 
volatile-qualified type 'volatile int' is deprecated}}
 
+(void)__is_trivially_assignable(volatile int&, int); // no warning
+
 #if __cplusplus >= 201703L
 struct X { int a, b; };
 volatile auto [x, y] = X{1, 2}; // cxx20-warning {{volatile qualifier in 
structured binding declaration is deprecated}}


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

[PATCH] D68876: [libTooling] Group all Transformer combinators in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

I'm now starting to doubt the split into transformer (for combinators) and 
tooling (for the type decls).  I checked and `ast_matchers` contains both.  
What do you think of my just putting all of the Transformer types + combis in 
the single `clang::transformer` namespace?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

r374581 - [Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.

[Volodymyr Sapsai via cfe-commits]

Author: vsapsai
Date: Fri Oct 11 11:22:34 2019
New Revision: 374581

URL: http://llvm.org/viewvc/llvm-project?rev=374581&view=rev
Log:
[Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.

rdar://problem/55715134

Reviewers: dsanders, bogner, rtereshin

Reviewed By: dsanders

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits

Tags: #llvm

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

Modified:
cfe/trunk/include/clang/Basic/FileManager.h
cfe/trunk/include/clang/Lex/HeaderSearch.h
cfe/trunk/lib/Basic/FileManager.cpp
cfe/trunk/lib/Lex/HeaderSearch.cpp

Modified: cfe/trunk/include/clang/Basic/FileManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/FileManager.h?rev=374581&r1=374580&r2=374581&view=diff
==
--- cfe/trunk/include/clang/Basic/FileManager.h (original)
+++ cfe/trunk/include/clang/Basic/FileManager.h Fri Oct 11 11:22:34 2019
@@ -232,10 +232,6 @@ class FileManager : public RefCountedBas
   ///
   unsigned NextFileUID;
 
-  // Statistics.
-  unsigned NumDirLookups, NumFileLookups;
-  unsigned NumDirCacheMisses, NumFileCacheMisses;
-
   // Caching.
   std::unique_ptr StatCache;
 

Modified: cfe/trunk/include/clang/Lex/HeaderSearch.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderSearch.h?rev=374581&r1=374580&r2=374581&view=diff
==
--- cfe/trunk/include/clang/Lex/HeaderSearch.h (original)
+++ cfe/trunk/include/clang/Lex/HeaderSearch.h Fri Oct 11 11:22:34 2019
@@ -250,12 +250,6 @@ class HeaderSearch {
   /// Entity used to look up stored header file information.
   ExternalHeaderFileInfoSource *ExternalSource = nullptr;
 
-  // Various statistics we track for performance analysis.
-  unsigned NumIncluded = 0;
-  unsigned NumMultiIncludeFileOptzn = 0;
-  unsigned NumFrameworkLookups = 0;
-  unsigned NumSubFrameworkLookups = 0;
-
 public:
   HeaderSearch(std::shared_ptr HSOpts,
SourceManager &SourceMgr, DiagnosticsEngine &Diags,
@@ -544,8 +538,6 @@ public:
   const FileEntry *lookupModuleMapFile(const DirectoryEntry *Dir,
bool IsFramework);
 
-  void IncrementFrameworkLookupCount() { ++NumFrameworkLookups; }
-
   /// Determine whether there is a module map that may map the header
   /// with the given file name to a (sub)module.
   /// Always returns false if modules are disabled.

Modified: cfe/trunk/lib/Basic/FileManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/FileManager.cpp?rev=374581&r1=374580&r2=374581&view=diff
==
--- cfe/trunk/lib/Basic/FileManager.cpp (original)
+++ cfe/trunk/lib/Basic/FileManager.cpp Fri Oct 11 11:22:34 2019
@@ -18,9 +18,10 @@
 
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/FileSystemStatCache.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/Statistic.h"
 #include "llvm/Config/llvm-config.h"
-#include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
@@ -35,6 +36,14 @@
 
 using namespace clang;
 
+#define DEBUG_TYPE "file-search"
+
+ALWAYS_ENABLED_STATISTIC(NumDirLookups, "Number of directory lookups.");
+ALWAYS_ENABLED_STATISTIC(NumFileLookups, "Number of file lookups.");
+ALWAYS_ENABLED_STATISTIC(NumDirCacheMisses,
+ "Number of directory cache misses.");
+ALWAYS_ENABLED_STATISTIC(NumFileCacheMisses, "Number of file cache misses.");
+
 
//===--===//
 // Common logic.
 
//===--===//
@@ -43,9 +52,6 @@ FileManager::FileManager(const FileSyste
  IntrusiveRefCntPtr FS)
 : FS(std::move(FS)), FileSystemOpts(FSO), SeenDirEntries(64),
   SeenFileEntries(64), NextFileUID(0) {
-  NumDirLookups = NumFileLookups = 0;
-  NumDirCacheMisses = NumFileCacheMisses = 0;
-
   // If the caller doesn't provide a virtual file system, just grab the real
   // file system.
   if (!this->FS)

Modified: cfe/trunk/lib/Lex/HeaderSearch.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderSearch.cpp?rev=374581&r1=374580&r2=374581&view=diff
==
--- cfe/trunk/lib/Lex/HeaderSearch.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderSearch.cpp Fri Oct 11 11:22:34 2019
@@ -27,6 +27,7 @@
 #include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Capacity.h"
@@ -46,6 +47,16 @@
 
 using namespace clang;
 

[PATCH] D68876: [libTooling] Group all Transformer combinators in a single namespace.

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

> What do you think of my just putting all of the Transformer types + combis in 
> the single clang::transformer namespace?

That would make sense to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876



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

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 224650.
ymandel added a comment.

moved all decls to clang::transformer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876

Files:
  clang/include/clang/Tooling/Transformer/MatchConsumer.h
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/include/clang/Tooling/Transformer/Transformer.h
  clang/lib/Tooling/Transformer/RangeSelector.cpp
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/lib/Tooling/Transformer/Transformer.cpp
  clang/unittests/Tooling/RangeSelectorTest.cpp
  clang/unittests/Tooling/StencilTest.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -18,9 +18,10 @@
 using namespace clang;
 using namespace tooling;
 using namespace ast_matchers;
-
 namespace {
 using ::testing::IsEmpty;
+using transformer::RewriteRule;
+using transformer::value;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
@@ -208,7 +209,7 @@
 TEST_F(TransformerTest, AddIncludeAngled) {
   RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
   change(text("other()")));
-  addInclude(Rule, "clang/OtherLib.h", IncludeFormat::Angled);
+  addInclude(Rule, "clang/OtherLib.h", transformer::IncludeFormat::Angled);
 
   std::string Input = R"cc(
 int f(int x);
@@ -559,7 +560,7 @@
   change(name("fun"), text("DECL_RULE")));
 
   RewriteRule Rule = applyFirst({ReplaceF1, DeclRule, ReplaceF1OrF2});
-  EXPECT_EQ(tooling::detail::buildMatchers(Rule).size(), 2UL);
+  EXPECT_EQ(transformer::detail::buildMatchers(Rule).size(), 2UL);
   testRule(Rule, Input, Expected);
 }
 
@@ -795,11 +796,11 @@
 // rules.
 TEST(TransformerDeathTest, OrderedRuleTypes) {
   RewriteRule QualTypeRule = makeRule(qualType(), change(text("Q")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(QualTypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(QualTypeRule),
"Matcher must be.*node matcher");
 
   RewriteRule TypeRule = makeRule(arrayType(), change(text("T")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(TypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(TypeRule),
"Matcher must be.*node matcher");
 }
 #endif
Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -16,7 +16,7 @@
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -27,15 +27,6 @@
 using ::testing::Eq;
 using ::testing::HasSubstr;
 using MatchResult = MatchFinder::MatchResult;
-using stencil::access;
-using stencil::addressOf;
-using stencil::cat;
-using stencil::deref;
-using stencil::dPrint;
-using stencil::expression;
-using stencil::ifBound;
-using stencil::run;
-using stencil::text;
 
 // Create a valid translation-unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
@@ -64,7 +55,7 @@
 // `StatementCode` may contain other statements not described by `Matcher`.
 static llvm::Optional matchStmt(StringRef StatementCode,
StatementMatcher Matcher) {
-  auto AstUnit = buildASTFromCode(wrapSnippet(StatementCode));
+  auto AstUnit = tooling::buildASTFromCode(wrapSnippet(StatementCode));
   if (AstUnit == nullptr) {
 ADD_FAILURE() << "AST construction failed";
 return llvm::None;
Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -11,13 +11,14 @@
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Tooling/FixIt.h"
 #include "clang/Tooling/Tooling.h"
+#include "clang/Tooling/Transformer/SourceCode.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -40,7 +41,7 @@
 };
 
 template  TestMatch matchCode(StringRef Code, M Matcher) {
-  auto ASTUnit = buildASTFromCode(Code);
+  auto ASTUnit = tooling::buildASTFromCode(Code);
   assert(ASTUnit != nullptr && "AST construction failed");
 
   ASTContext &Context = ASTUnit->getASTContext();
@@ -59,7 +60,7 @@
   Expected Range = Selector(Match.Result);
   if (!Range)
 return Range.takeError();
-  

Attention bot owners

[Galina Kistanova via cfe-commits]

Hello all bots owners,

As all of you know we move to github monorepo very soon now.
We are actively working on the buildbot to prepare a solution to switch
from SVN to github when time comes.

It would require some activity on your bots.

At this point it is clear that you would need to

* Make sure you have reasonably recent version of git installed and in the
system path for the buildbot account,
* Once the transition to github is done, you would need to remove the old
source code and build directory. This could be done later assuming you have
enough room on that hard drive for two sets of the source and build files.

Thanks

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

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 224651.
ymandel edited the summary of this revision.
ymandel added a comment.

fix using decl.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876

Files:
  clang/include/clang/Tooling/Transformer/MatchConsumer.h
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/include/clang/Tooling/Transformer/Transformer.h
  clang/lib/Tooling/Transformer/RangeSelector.cpp
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/lib/Tooling/Transformer/Transformer.cpp
  clang/unittests/Tooling/RangeSelectorTest.cpp
  clang/unittests/Tooling/StencilTest.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -18,9 +18,10 @@
 using namespace clang;
 using namespace tooling;
 using namespace ast_matchers;
-
 namespace {
 using ::testing::IsEmpty;
+using transformer::RewriteRule;
+using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
@@ -208,7 +209,7 @@
 TEST_F(TransformerTest, AddIncludeAngled) {
   RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
   change(text("other()")));
-  addInclude(Rule, "clang/OtherLib.h", IncludeFormat::Angled);
+  addInclude(Rule, "clang/OtherLib.h", transformer::IncludeFormat::Angled);
 
   std::string Input = R"cc(
 int f(int x);
@@ -559,7 +560,7 @@
   change(name("fun"), text("DECL_RULE")));
 
   RewriteRule Rule = applyFirst({ReplaceF1, DeclRule, ReplaceF1OrF2});
-  EXPECT_EQ(tooling::detail::buildMatchers(Rule).size(), 2UL);
+  EXPECT_EQ(transformer::detail::buildMatchers(Rule).size(), 2UL);
   testRule(Rule, Input, Expected);
 }
 
@@ -795,11 +796,11 @@
 // rules.
 TEST(TransformerDeathTest, OrderedRuleTypes) {
   RewriteRule QualTypeRule = makeRule(qualType(), change(text("Q")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(QualTypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(QualTypeRule),
"Matcher must be.*node matcher");
 
   RewriteRule TypeRule = makeRule(arrayType(), change(text("T")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(TypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(TypeRule),
"Matcher must be.*node matcher");
 }
 #endif
Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -16,7 +16,7 @@
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -27,15 +27,6 @@
 using ::testing::Eq;
 using ::testing::HasSubstr;
 using MatchResult = MatchFinder::MatchResult;
-using stencil::access;
-using stencil::addressOf;
-using stencil::cat;
-using stencil::deref;
-using stencil::dPrint;
-using stencil::expression;
-using stencil::ifBound;
-using stencil::run;
-using stencil::text;
 
 // Create a valid translation-unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
@@ -64,7 +55,7 @@
 // `StatementCode` may contain other statements not described by `Matcher`.
 static llvm::Optional matchStmt(StringRef StatementCode,
StatementMatcher Matcher) {
-  auto AstUnit = buildASTFromCode(wrapSnippet(StatementCode));
+  auto AstUnit = tooling::buildASTFromCode(wrapSnippet(StatementCode));
   if (AstUnit == nullptr) {
 ADD_FAILURE() << "AST construction failed";
 return llvm::None;
Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -11,13 +11,14 @@
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Tooling/FixIt.h"
 #include "clang/Tooling/Tooling.h"
+#include "clang/Tooling/Transformer/SourceCode.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -40,7 +41,7 @@
 };
 
 template  TestMatch matchCode(StringRef Code, M Matcher) {
-  auto ASTUnit = buildASTFromCode(Code);
+  auto ASTUnit = tooling::buildASTFromCode(Code);
   assert(ASTUnit != nullptr && "AST construction failed");
 
   ASTContext &Context = ASTUnit->getASTContext();
@@ -59,7 +60,7 @@
   Expected Range = Selector(Match.Result);
   if (!Range)
 return R

[PATCH] D68876: [libTooling] Put all Transformer declarations in a single namespace.

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 224653.
ymandel added a comment.

remove stray newline and include.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68876

Files:
  clang/include/clang/Tooling/Transformer/MatchConsumer.h
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/include/clang/Tooling/Transformer/Stencil.h
  clang/include/clang/Tooling/Transformer/Transformer.h
  clang/lib/Tooling/Transformer/RangeSelector.cpp
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/lib/Tooling/Transformer/Stencil.cpp
  clang/lib/Tooling/Transformer/Transformer.cpp
  clang/unittests/Tooling/RangeSelectorTest.cpp
  clang/unittests/Tooling/StencilTest.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -18,9 +18,10 @@
 using namespace clang;
 using namespace tooling;
 using namespace ast_matchers;
-
 namespace {
 using ::testing::IsEmpty;
+using transformer::RewriteRule;
+using transformer::text;
 
 constexpr char KHeaderContents[] = R"cc(
   struct string {
@@ -208,7 +209,7 @@
 TEST_F(TransformerTest, AddIncludeAngled) {
   RewriteRule Rule = makeRule(callExpr(callee(functionDecl(hasName("f",
   change(text("other()")));
-  addInclude(Rule, "clang/OtherLib.h", IncludeFormat::Angled);
+  addInclude(Rule, "clang/OtherLib.h", transformer::IncludeFormat::Angled);
 
   std::string Input = R"cc(
 int f(int x);
@@ -559,7 +560,7 @@
   change(name("fun"), text("DECL_RULE")));
 
   RewriteRule Rule = applyFirst({ReplaceF1, DeclRule, ReplaceF1OrF2});
-  EXPECT_EQ(tooling::detail::buildMatchers(Rule).size(), 2UL);
+  EXPECT_EQ(transformer::detail::buildMatchers(Rule).size(), 2UL);
   testRule(Rule, Input, Expected);
 }
 
@@ -795,11 +796,11 @@
 // rules.
 TEST(TransformerDeathTest, OrderedRuleTypes) {
   RewriteRule QualTypeRule = makeRule(qualType(), change(text("Q")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(QualTypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(QualTypeRule),
"Matcher must be.*node matcher");
 
   RewriteRule TypeRule = makeRule(arrayType(), change(text("T")));
-  EXPECT_DEATH(tooling::detail::buildMatchers(TypeRule),
+  EXPECT_DEATH(transformer::detail::buildMatchers(TypeRule),
"Matcher must be.*node matcher");
 }
 #endif
Index: clang/unittests/Tooling/StencilTest.cpp
===
--- clang/unittests/Tooling/StencilTest.cpp
+++ clang/unittests/Tooling/StencilTest.cpp
@@ -16,7 +16,7 @@
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -27,15 +27,6 @@
 using ::testing::Eq;
 using ::testing::HasSubstr;
 using MatchResult = MatchFinder::MatchResult;
-using stencil::access;
-using stencil::addressOf;
-using stencil::cat;
-using stencil::deref;
-using stencil::dPrint;
-using stencil::expression;
-using stencil::ifBound;
-using stencil::run;
-using stencil::text;
 
 // Create a valid translation-unit from a statement.
 static std::string wrapSnippet(StringRef StatementCode) {
@@ -64,7 +55,7 @@
 // `StatementCode` may contain other statements not described by `Matcher`.
 static llvm::Optional matchStmt(StringRef StatementCode,
StatementMatcher Matcher) {
-  auto AstUnit = buildASTFromCode(wrapSnippet(StatementCode));
+  auto AstUnit = tooling::buildASTFromCode(wrapSnippet(StatementCode));
   if (AstUnit == nullptr) {
 ADD_FAILURE() << "AST construction failed";
 return llvm::None;
Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -9,15 +9,15 @@
 #include "clang/Tooling/Transformer/RangeSelector.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Frontend/ASTUnit.h"
-#include "clang/Tooling/FixIt.h"
 #include "clang/Tooling/Tooling.h"
+#include "clang/Tooling/Transformer/SourceCode.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 using namespace clang;
-using namespace tooling;
+using namespace transformer;
 using namespace ast_matchers;
 
 namespace {
@@ -40,7 +40,7 @@
 };
 
 template  TestMatch matchCode(StringRef Code, M Matcher) {
-  auto ASTUnit = buildASTFromCode(Code);
+  auto ASTUnit = tooling::buildASTFromCode(Code);
   assert(ASTUnit != nullptr && "AST construction failed");
 
   ASTContext &Context = ASTUnit->getASTContext();
@@ -59,7 +59,7 @@
   

[PATCH] D68882: [test] Fix test failure

[Christopher Tetreault via Phabricator via cfe-commits]

ctetreau created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The version mismatch symbol is version 9 on 32 bit android. Since
this test isn't actually testing any android specific functionality,
we force the target triple to x86_64-unknown-unknown in order to have
a consistent version number. It seems the test was already trying to
do this, just not doing it right


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D68882

Files:
  clang/test/CodeGen/asan-new-pm.ll


Index: clang/test/CodeGen/asan-new-pm.ll
===
--- clang/test/CodeGen/asan-new-pm.ll
+++ clang/test/CodeGen/asan-new-pm.ll
@@ -1,12 +1,10 @@
 ; Test that ASan runs with the new pass manager
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager 
-fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager 
-fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager 
-fsanitize=address -flto=thin %s | FileCheck %s --check-prefixes=CHECK,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager 
-fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager 
-fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager 
-fsanitize=address -flto=thin %s | FileCheck %s --check-prefixes=CHECK,THINLTO
-
-target triple = "x86_64-unknown-unknown"
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - 
-fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s 
--check-prefixes=CHECK,LTO,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - 
-fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s 
--check-prefixes=CHECK,LTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - 
-fexperimental-new-pass-manager -fsanitize=address -flto=thin %s | FileCheck %s 
--check-prefixes=CHECK,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 
-fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s 
--check-prefixes=CHECK,LTO,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 
-fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s 
--check-prefixes=CHECK,LTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 
-fexperimental-new-pass-manager -fsanitize=address -flto=thin %s | FileCheck %s 
--check-prefixes=CHECK,THINLTO
 
 ; DAG-CHECK: @llvm.global_ctors = {{.*}}@asan.module_ctor
 


Index: clang/test/CodeGen/asan-new-pm.ll
===
--- clang/test/CodeGen/asan-new-pm.ll
+++ clang/test/CodeGen/asan-new-pm.ll
@@ -1,12 +1,10 @@
 ; Test that ASan runs with the new pass manager
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address -flto=thin %s | FileCheck %s --check-prefixes=CHECK,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
-; RUN: %clang_cc1 -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsanitize=address -flto=thin %s | FileCheck %s --check-prefixes=CHECK,THINLTO
-
-target triple = "x86_64-unknown-unknown"
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -fexperimental-new-pass-manager -fsanitize=address -flto=thin %s | FileCheck %s --check-prefixes=CHECK,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsanitize=address %s | FileCheck %s --check-prefixes=CHECK,LTO,THINLTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsanitize=address -flto %s | FileCheck %s --check-prefixes=CHECK,LTO
+; RUN: %clang_cc1 -triple x86_64-unknown-unknown -S -emit-llvm -o - -O1 -fexperimental-new-pass-manager -fsan

[PATCH] D63978: Clang Interface Stubs merger plumbing for Driver

[James Nagurne via Phabricator via cfe-commits]

JamesNagurne added a comment.

Our team maintains a downstream embedded ARM clang distribution and some tests 
from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the 
top, which has now been removed. Specifically, externstatic.c, 
merge-conflict-test.c, object-float.c, and object.c are failing.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and 
externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these 
tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can 
make sense of it, I'd appreciate input on how we can fix or work around it:

  > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
/llvm-project/clang/test/InterfaceStubs/object.c | 
/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI 
/llvm-project/clang/test/InterfaceStubs/object.c
  /llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: 
CHECK-TAPI: expected string not found in input
  // CHECK-TAPI: data: { Type: Object, Size: 4 }
 ^
  :1:1: note: scanning from here
  --- !experimental-ifs-v1
  ^

And when run without FileCheck, our raw output:

  > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
/llvm-project/clang/test/InterfaceStubs/object.c
  --- !experimental-ifs-v1
  IfsVersion: 1.0
  Triple: thumbv7em-ti-none-eabihf
  ObjectFileFormat: ELF
  Symbols:
  ...


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63978



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

[PATCH] D68884: Add support to -Wa,-W in clang

[Jian Cai via Phabricator via cfe-commits]

jcai19 created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
jcai19 added a reviewer: bcain.
jcai19 added subscribers: nickdesaulniers, manojgupta, llozano.
jcai19 updated this revision to Diff 224663.
jcai19 added a comment.

Fix typos.


Currently clang does not support -Wa,-W, which suppresses warning
messsages in GNUassebembler. Add this option for gcc compability.
https://bugs.llvm.org/show_bug.cgi?id=43651


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D68884

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/as-w-option.c


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,--no-warn 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | 
FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 
| FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,--no-warn 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68884: Add support to -Wa,-W in clang

[Jian Cai via Phabricator via cfe-commits]

jcai19 updated this revision to Diff 224663.
jcai19 added a comment.

Fix typos.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68884

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/as-w-option.c


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,--no-warn 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | 
FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 
| FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,--no-warn 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D63978: Clang Interface Stubs merger plumbing for Driver

[Puyan Lotfi via Phabricator via cfe-commits]

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

In D63978#1706420 , @JamesNagurne 
wrote:

> Our team maintains a downstream embedded ARM clang distribution and some 
> tests from this commit have begun to fail for us.
>  For a number of these tests, there was a REQUIRES: x86-registered-target at 
> the top, which has now been removed. Specifically, externstatic.c, 
> merge-conflict-test.c, object-float.c, and object.c are failing.
>
> object* tests seem to be based on object.cpp, which had the REQUIRES line, 
> and externstatic.c also had that line prior to the change.
>  I see that @compnerd suggested the removal, but were you certain that these 
> tests would work on clang toolchains for which x86 is not a registered target?
>
> For a failure example, here the output of lit for our toolchain. If you can 
> make sense of it, I'd appreciate input on how we can fix or work around it:
>
>   > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
> /llvm-project/clang/test/InterfaceStubs/object.c | 
> /arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI 
> /llvm-project/clang/test/InterfaceStubs/object.c
>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: 
> CHECK-TAPI: expected string not found in input
>// CHECK-TAPI: data: { Type: Object, Size: 4 }
>   ^
>:1:1: note: scanning from here
>--- !experimental-ifs-v1
>^
>   
>
> And when run without FileCheck, our raw output:
>
>   > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
> /llvm-project/clang/test/InterfaceStubs/object.c
>--- !experimental-ifs-v1
>IfsVersion: 1.0
>Triple: thumbv7em-ti-none-eabihf
>ObjectFileFormat: ELF
>Symbols:
>...
>   


I am sorry for this James. I can add back the REQUIRES lines for now and 
coordinate with you on making sure your downstream bots are not affected again 
if the REQUIRES are removed again.
By chance are your bots accessible publicly?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63978



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

[PATCH] D68884: Add support to -Wa,-W in clang

[Jian Cai via Phabricator via cfe-commits]

jcai19 updated this revision to Diff 224664.
jcai19 added a comment.

Update test cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68884

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/as-w-option.c


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck 
-allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | 
FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 
| FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;


Index: clang/test/Driver/as-w-option.c
===
--- /dev/null
+++ clang/test/Driver/as-w-option.c
@@ -0,0 +1,14 @@
+// RUN: %clang -### %s -c -o tmp.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-NOIAS %s
+// RUN: %clang -### %s -c -o tmp.o -integrated-as -Wa,-W 2>&1 | FileCheck -check-prefix=CHECK-IAS %s
+// RUN: %clang %s -c -o %t.o -integrated-as -Wa,-W 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: %clang %s -c -o %t.o -fno-integrated-as -Wa,-W 2>&1 | FileCheck -allow-empty --check-prefix=CHECK-AS-NOWARN %s
+// RUN: not %clang %s -c -o %t.o -integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+// RUN: not %clang %s -c -o %t.o -fno-integrated-as -Wa,--fatal-warnings 2>&1 | FileCheck --check-prefix=CHECK-AS-FATAL %s
+
+// CHECK-IAS: "-cc1" {{.*}} "-massembler-no-warn"
+// CHECK-NOIAS: "-W"
+// CHECK-AS-NOWARN-NOT: warning:
+// CHECK-AS-FATAL-NOT: warning:
+// CHECK-AS-FATAL: error
+
+__asm(".warning");
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -2229,7 +2229,7 @@
 CmdArgs.push_back("-msave-temp-labels");
   } else if (Value == "--fatal-warnings") {
 CmdArgs.push_back("-massembler-fatal-warnings");
-  } else if (Value == "--no-warn") {
+  } else if (Value == "--no-warn" || Value == "-W") {
 CmdArgs.push_back("-massembler-no-warn");
   } else if (Value == "--noexecstack") {
 UseNoExecStack = true;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68885: Add a Ranges field to Diagnostic struct

[Joe Turner via Phabricator via cfe-commits]

compositeprimes created this revision.
compositeprimes added reviewers: clang, clang-tools-extra.
compositeprimes added projects: clang, clang-tools-extra.
Herald added a subscriber: cfe-commits.

Part 1 of the change:
The goal is instead of dropping all the ranges associated with a Diagnostic 
when converting them to a ClangTidy error, instead attach them to the 
ClangTidyError, so they can be consumed by other APIs.

I could move this to the ClangTidyError class itself, but I thought it could be 
useful here, as Diagnostic could use a concept of ranges not associated with a 
FixIt


Repository:
  rC Clang

https://reviews.llvm.org/D68885

Files:
  include/clang/Tooling/Core/Diagnostic.h


Index: include/clang/Tooling/Core/Diagnostic.h
===
--- include/clang/Tooling/Core/Diagnostic.h
+++ include/clang/Tooling/Core/Diagnostic.h
@@ -84,6 +84,13 @@
   ///
   /// Note: it is empty in unittest.
   std::string BuildDirectory;
+
+
+  /// Extra source ranges associated with the diagnostic. By default, the
+  /// diagnostic is only associated with the source location specified in the
+  /// `Message` field, but if `Ranges` is nonempty, they will be preferred
+  /// representation of the source code associated with the diagnostic.
+  ArrayRef Ranges;
 };
 
 /// Collection of Diagnostics generated from a single translation unit.


Index: include/clang/Tooling/Core/Diagnostic.h
===
--- include/clang/Tooling/Core/Diagnostic.h
+++ include/clang/Tooling/Core/Diagnostic.h
@@ -84,6 +84,13 @@
   ///
   /// Note: it is empty in unittest.
   std::string BuildDirectory;
+
+
+  /// Extra source ranges associated with the diagnostic. By default, the
+  /// diagnostic is only associated with the source location specified in the
+  /// `Message` field, but if `Ranges` is nonempty, they will be preferred
+  /// representation of the source code associated with the diagnostic.
+  ArrayRef Ranges;
 };
 
 /// Collection of Diagnostics generated from a single translation unit.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D68887: Copy the Ranges field from the Diagnostic when creating the ClangTidyError

[Joe Turner via Phabricator via cfe-commits]

compositeprimes created this revision.
compositeprimes added a reviewer: clang-tools-extra.
compositeprimes added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, mgehre.
Herald added a project: clang.

Part 2 of the change:
The goal is instead of dropping all the ranges associated with a Diagnostic 
when converting them to a ClangTidy error, instead attach them to the 
ClangTidyError, so they can be consumed by other APIs.

I could move this to the ClangTidyError class itself, but I thought it could be 
useful here, as Diagnostic could use a concept of ranges not associated with a 
FixIt


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D68887

Files:
  clang-tidy/ClangTidyDiagnosticConsumer.cpp


Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -61,6 +61,7 @@
 }
 assert(Error.Message.Message.empty() && "Overwriting a diagnostic 
message");
 Error.Message = TidyMessage;
+Error.Ranges = Ranges;
   }
 
   void emitDiagnosticLoc(FullSourceLoc Loc, PresumedLoc PLoc,


Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -61,6 +61,7 @@
 }
 assert(Error.Message.Message.empty() && "Overwriting a diagnostic message");
 Error.Message = TidyMessage;
+Error.Ranges = Ranges;
   }
 
   void emitDiagnosticLoc(FullSourceLoc Loc, PresumedLoc PLoc,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r374593 - Release notes: Add the option WarnForDeadNestedAssignments

[Sylvestre Ledru via cfe-commits]

Author: sylvestre
Date: Fri Oct 11 13:33:43 2019
New Revision: 374593

URL: http://llvm.org/viewvc/llvm-project?rev=374593&view=rev
Log:
Release notes: Add the option WarnForDeadNestedAssignments
https://reviews.llvm.org/D66733

Modified:
cfe/trunk/docs/ReleaseNotes.rst

Modified: cfe/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=374593&r1=374592&r2=374593&view=diff
==
--- cfe/trunk/docs/ReleaseNotes.rst (original)
+++ cfe/trunk/docs/ReleaseNotes.rst Fri Oct 11 13:33:43 2019
@@ -244,6 +244,9 @@ libclang
 Static Analyzer
 ---
 
+- The Clang analyzer checker ``DeadStores`` gets a new option called
+  ``WarnForDeadNestedAssignments`` to detect nested dead assignments
+  (enabled by default).
 - ...
 
 .. _release-notes-ubsan:


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

[PATCH] D63978: Clang Interface Stubs merger plumbing for Driver

[James Nagurne via Phabricator via cfe-commits]

JamesNagurne added a comment.

In D63978#1706448 , @plotfi wrote:

> In D63978#1706420 , @JamesNagurne 
> wrote:
>
> > Our team maintains a downstream embedded ARM clang distribution and some 
> > tests from this commit have begun to fail for us.
> >  For a number of these tests, there was a REQUIRES: x86-registered-target 
> > at the top, which has now been removed. Specifically, externstatic.c, 
> > merge-conflict-test.c, object-float.c, and object.c are failing.
> >
> > object* tests seem to be based on object.cpp, which had the REQUIRES line, 
> > and externstatic.c also had that line prior to the change.
> >  I see that @compnerd suggested the removal, but were you certain that 
> > these tests would work on clang toolchains for which x86 is not a 
> > registered target?
> >
> > For a failure example, here the output of lit for our toolchain. If you can 
> > make sense of it, I'd appreciate input on how we can fix or work around it:
> >
> >   > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
> > /llvm-project/clang/test/InterfaceStubs/object.c | 
> > /arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI 
> > /llvm-project/clang/test/InterfaceStubs/object.c
> >/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: 
> > CHECK-TAPI: expected string not found in input
> >// CHECK-TAPI: data: { Type: Object, Size: 4 }
> >   ^
> >:1:1: note: scanning from here
> >--- !experimental-ifs-v1
> >^
> >   
> >
> > And when run without FileCheck, our raw output:
> >
> >   > /arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs 
> > /llvm-project/clang/test/InterfaceStubs/object.c
> >--- !experimental-ifs-v1
> >IfsVersion: 1.0
> >Triple: thumbv7em-ti-none-eabihf
> >ObjectFileFormat: ELF
> >Symbols:
> >...
> >   
>
>
> I am sorry for this James. I can add back the REQUIRES lines for now and 
> coordinate with you on making sure your downstream bots are not affected 
> again if the REQUIRES are removed again.
>  By chance are your bots accessible publicly?


Sadly, they are not. It's on our list of things to investigate, but we don't 
have the resources to do such a thing quite yet.
I'm looking into the 'arm7*' buildbots to see if they are built similar to ours 
so I am not leaving you entirely without something to look at. However, if it 
seems to be common knowledge to always include an X86 target, I think I can 
talk to my team and change up what we do.

These buildbots seem to also do LLVM_TARGETS_TO_BUILD=ARM, and then set the 
default target triple to a non-x86 triple (the host's)

That could point towards us being in error here. I'll investigate things a 
little further, and update when I get the chance.
To be clear: this feature should work for any ELF target, correct?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63978



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

[PATCH] D66733: [analyzer] Add a checker option to detect nested dead stores

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru added a comment.

I added it to the release notes here : https://reviews.llvm.org/rC374593
I am wondering if the option( WarnForDeadNestedAssignments ) to disable it is 
really necessary?
I haven't seen any false positive while deadstore has some.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66733



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

[PATCH] D68849: [Parse] Don't speculatively parse an identifier in the wrong context.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

It looks like it's not actually all that complex to defer building the 
expression until we're ready to consume the annotation. I've got a 
mostly-complete patch for that, and I'd like to try finishing that before we 
add workarounds.


Repository:
  rC Clang

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

https://reviews.llvm.org/D68849



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

[PATCH] D67985: CFI: wrong type passed to llvm.type.test with multiple inheritance devirtualization

[Dmitry Mikulin via Phabricator via cfe-commits]

dmikulin added a comment.

@pcc : poke


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

https://reviews.llvm.org/D67985



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

[PATCH] D67985: CFI: wrong type passed to llvm.type.test with multiple inheritance devirtualization

[Peter Collingbourne via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D67985



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

[PATCH] D68682: Clang-tidy fix removals removing all non-blank text from a line should remove the line

[Conrad Poelman via Phabricator via cfe-commits]

poelmanc added a comment.

In D68682#1705865 , @Eugene.Zelenko 
wrote:

> In D68682#1705505 , @jonathanmeier 
> wrote:
>
> > In D68682#1702025 , @poelmanc 
> > wrote:
> >
> > > In D68682#1700908 , 
> > > @Eugene.Zelenko wrote:
> > >
> > > > You may be interested to also look on PR43583 related to 
> > > > readability-redundant-member-init.
> > >
> > >
> > > Thanks Eugene, I'm having trouble finding that. 
> > > https://reviews.llvm.org/D43583 seems related to MIPS instructions rather 
> > > than readability-redundant-member-init. Could you please post a link? 
> > > Thanks.
> >
> >
> > PRs are bug reports. You can access them like this: https://llvm.org/PR43583
>
>
> Or direct link to LLVM Bugzilla 
> (https://bugs.llvm.org/show_bug.cgi?id=). Ideally Phabricator should 
> recognize PR prefixes in same way as it recognize D.


Thanks @Eugene.Zelenko and @jonathanmeier. https://llvm.org/PR43583 now 
explains to me perfectly why my initial attempts to remove blank lines solely 
within readability-redundant-member-init failed: the final removal of ":" that 
in some cases left the line blank was not made in 
readability-redundant-member-init but higher up in the cleanup stage.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D68682



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