[PATCH] D113210: [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

This change caused the Polly build to fail: 
https://lab.llvm.org/buildbot/#/builders/10/builds/7501

  opt: 
/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.src/llvm/include/llvm/IR/PassManager.h:784:
 typename PassT::Result& llvm::AnalysisManager::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = 
llvm::OuterAnalysisManagerProxy, 
llvm::Function>; IRUnitT = llvm::Function; ExtraArgTs = {}; typename 
PassT::Result = 
llvm::OuterAnalysisManagerProxy, 
llvm::Function>::Result]: Assertion `AnalysisPasses.count(PassT::ID()) && "This 
analysis pass was not registered prior to being queried"' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace.
  Stack dump:
  0.Program arguments: 
/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/bin/opt 
-polly-process-unprofitable -polly-remarks-minimal -polly-use-llvm-names 
-polly-import-jscop-dir=/home/worker/src/llvm-project/polly/test/ScopInliner 
-polly-codegen-verify -polly-detect-full-functions -polly-scop-inliner 
-polly-scops -analyze
  1.Running pass 'CallGraph Pass Manager' on module ''.
   #0 0x7fcc7bb29644 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
   #1 0x7fcc7bb26d5e SignalHandler(int) Signals.cpp:0:0
   #2 0x7fcc7b541210 (/lib/x86_64-linux-gnu/libc.so.6+0x46210)
   #3 0x7fcc7b54118b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4618b)
   #4 0x7fcc7b520859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25859)
   #5 0x7fcc7b520729 (/lib/x86_64-linux-gnu/libc.so.6+0x25729)
   #6 0x7fcc7b531f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
   #7 0x7fcc7dbcb34f void 
llvm::AAManager::getModuleAAResultImpl(llvm::Function&, 
llvm::AnalysisManager&, llvm::AAResults&) PassBuilder.cpp:0:0
   #8 0x7fcc7c3c5363 llvm::AAManager::run(llvm::Function&, 
llvm::AnalysisManager&) 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/./lib/libLLVMAnalysis.so.14git+0x257363)
   #9 0x563487033358 llvm::detail::AnalysisPassModel::Invalidator>::run(llvm::Function&, 
llvm::AnalysisManager&) NewPMDriver.cpp:0:0
  #10 0x7fcc7bf95dd8 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/./lib/libLLVMCore.so.14git+0x450dd8)
  #11 0x7fcc7e84892a polly::ScopAnalysis::run(llvm::Function&, 
llvm::AnalysisManager&) 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/./lib/libPolly.so.14git+0x13c92a)
  #12 0x7fcc7e962aa4 llvm::detail::AnalysisPassModel::Invalidator>::run(llvm::Function&, 
llvm::AnalysisManager&) RegisterPasses.cpp:0:0
  #13 0x7fcc7bf95dd8 
llvm::AnalysisManager::getResultImpl(llvm::AnalysisKey*, 
llvm::Function&) 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/./lib/libLLVMCore.so.14git+0x450dd8)
  #14 0x7fcc7e9d7d7c (anonymous 
namespace)::ScopInliner::runOnSCC(llvm::CallGraphSCC&) ScopInliner.cpp:0:0
  #15 0x7fcc7c46dfef (anonymous 
namespace)::CGPassManager::runOnModule(llvm::Module&) CallGraphSCCPass.cpp:0:0
  #16 0x7fcc7bf4dee2 llvm::legacy::PassManagerImpl::run(llvm::Module&) 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/./lib/libLLVMCore.so.14git+0x408ee2)
  #17 0x563487054571 main 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/bin/opt+0x48571)
  #18 0x7fcc7b5220b3 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x270b3)
  #19 0x563487030c8e _start 
(/home/worker/buildbot-workers/polly-x86_64-gce1/rundir/llvm.obj/bin/opt+0x24c8e)

Polly is not using custom AliasAnalysis. Any idea how to fix this?

Btw, the pre-merge check failed because of this as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113210

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


[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-11-04 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

In D104601#3105044 , @manmanren wrote:

> It will fail the compilation on the preprocessed output with
> error: expected unqualified-id
> int test();#pragma clang assume_nonnull end

The handler for assume_nonull passes an invalid SourceLocation if embedded in 
in a _Pragma. Not sure whether this is already a bug, but we should insert 
semantically relevant newlines even if the line for the #pragma is unknown. 
Fixed in rG1606022fab2d90ed8ee6d15800ec1c2c293db20e 
. Thanks 
for the report.




Comment at: clang/lib/Frontend/PrintPreprocessedOutput.cpp:680
+if (RequireSpace || (!MinimizeWhitespace && Tok.hasLeadingSpace()) ||
+((EmittedTokensOnThisLine || EmittedTokensOnThisLine) &&
+ AvoidConcat(PrevPrevTok, PrevTok, Tok)))

RKSimon wrote:
> @Meinersbur Static analysis is warning that these are both the same - should 
> one be EmittedDirectiveOnThisLine ?
Fixed in rG8f099d17a1bee857ada3c5af032cfcb559252024. Thanks for the report and 
sorry for not seeing you comment until now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[clang] 8f099d1 - [Preprocessor] Fix warning: left and right subexpressions are identical. NFCI.

2021-11-04 Thread Michael Kruse via cfe-commits

Author: Michael Kruse
Date: 2021-11-05T00:43:40-05:00
New Revision: 8f099d17a1bee857ada3c5af032cfcb559252024

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

LOG: [Preprocessor] Fix warning: left and right subexpressions are identical. 
NFCI.

This is reported by msvc as
warning C6287: redundant code: the left and right subexpressions are identical

EmittedDirectiveOnThisLine implies EmittedTokensOnThisLine
making this an NFC change. To be on the safe side and because both of
them are checked at other places as well, we continue to check both.

Compiler warning reported here:
https://reviews.llvm.org/D104601#2957333

Added: 


Modified: 
clang/lib/Frontend/PrintPreprocessedOutput.cpp

Removed: 




diff  --git a/clang/lib/Frontend/PrintPreprocessedOutput.cpp 
b/clang/lib/Frontend/PrintPreprocessedOutput.cpp
index 360fa1448b128..fadf0c054310d 100644
--- a/clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ b/clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -700,7 +700,7 @@ void 
PrintPPOutputPPCallbacks::HandleWhitespaceBeforeTok(const Token &Tok,
 // - The whitespace is necessary to keep the tokens apart and there is not
 //   already a newline between them
 if (RequireSpace || (!MinimizeWhitespace && Tok.hasLeadingSpace()) ||
-((EmittedTokensOnThisLine || EmittedTokensOnThisLine) &&
+((EmittedTokensOnThisLine || EmittedDirectiveOnThisLine) &&
  AvoidConcat(PrevPrevTok, PrevTok, Tok)))
   OS << ' ';
   }



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


[clang] 1606022 - [Preprocessor] Fix newline before/after _Pragma.

2021-11-04 Thread Michael Kruse via cfe-commits

Author: Michael Kruse
Date: 2021-11-05T00:43:40-05:00
New Revision: 1606022fab2d90ed8ee6d15800ec1c2c293db20e

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

LOG: [Preprocessor] Fix newline before/after _Pragma.

The PragmaAssumeNonNullHandler (and maybe others) passes an invalid
SourceLocation to its callback, hence PrintPreprocessedOutput does not
know how many lines to insert between the previous token and the
pragma and does nothing.

With this patch we instead assume that the unknown token is on the same
line as the previous such that we can call the procedure that also emits
semantically significant whitespace.

Fixes bug reported here: https://reviews.llvm.org/D104601#3105044

Added: 
clang/test/Preprocessor/_Pragma-newline.c

Modified: 
clang/lib/Frontend/PrintPreprocessedOutput.cpp

Removed: 




diff  --git a/clang/lib/Frontend/PrintPreprocessedOutput.cpp 
b/clang/lib/Frontend/PrintPreprocessedOutput.cpp
index fadf0c054310d..45df86ef91cdb 100644
--- a/clang/lib/Frontend/PrintPreprocessedOutput.cpp
+++ b/clang/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -188,19 +188,17 @@ class PrintPPOutputPPCallbacks : public PPCallbacks {
   /// @return Whether column adjustments are necessary.
   bool MoveToLine(const Token &Tok, bool RequireStartOfLine) {
 PresumedLoc PLoc = SM.getPresumedLoc(Tok.getLocation());
-if (PLoc.isInvalid())
-  return false;
+unsigned TargetLine = PLoc.isValid() ? PLoc.getLine() : CurLine;
 bool IsFirstInFile = Tok.isAtStartOfLine() && PLoc.getLine() == 1;
-return MoveToLine(PLoc.getLine(), RequireStartOfLine) || IsFirstInFile;
+return MoveToLine(TargetLine, RequireStartOfLine) || IsFirstInFile;
   }
 
   /// Move to the line of the provided source location. Returns true if a new
   /// line was inserted.
   bool MoveToLine(SourceLocation Loc, bool RequireStartOfLine) {
 PresumedLoc PLoc = SM.getPresumedLoc(Loc);
-if (PLoc.isInvalid())
-  return false;
-return MoveToLine(PLoc.getLine(), RequireStartOfLine);
+unsigned TargetLine = PLoc.isValid() ? PLoc.getLine() : CurLine;
+return MoveToLine(TargetLine, RequireStartOfLine);
   }
   bool MoveToLine(unsigned LineNo, bool RequireStartOfLine);
 

diff  --git a/clang/test/Preprocessor/_Pragma-newline.c 
b/clang/test/Preprocessor/_Pragma-newline.c
new file mode 100644
index 0..43628eaef4674
--- /dev/null
+++ b/clang/test/Preprocessor/_Pragma-newline.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -E -o - %s | FileCheck %s
+// RUN: %clang_cc1 -E -P -o - %s | FileCheck %s
+// RUN: %clang_cc1 -E -fminimize-whitespace -o - %s | FileCheck %s
+// RUN: %clang_cc1 -E -fminimize-whitespace -P -o - %s | FileCheck %s
+
+// The PragmaAssumeNonNullHandler (and maybe others) passes an invalid
+// SourceLocation when inside a _Pragma. Ensure we still emit semantic
+// newlines.
+// See report at https://reviews.llvm.org/D104601#3105044
+
+_Pragma("clang assume_nonnull begin") test _Pragma("clang assume_nonnull end")
+
+// CHECK: {{^}}#pragma clang assume_nonnull begin{{$}}
+// CHECK: test
+// CHECK: {{^}}#pragma clang assume_nonnull end{{$}}



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


[PATCH] D113145: Remove two sema checkings as assertions introduced by D79719.

2021-11-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added a comment.

Yeah, that would be better. I just realized it earlier today. I'll attempt that 
instead. Thanks for the suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113145

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


[PATCH] D113145: Remove two sema checkings as assertions introduced by D79719.

2021-11-04 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added a comment.

@ychen, an alternative fix would be to avoid getting asking for the layout for 
a broken `union` like this. Would it be appropriate to mark the `RecordDecl` in 
Sema such that `isInvalidDecl` returns true? Is that already happening?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113145

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


[PATCH] D91949: [clang-format] Add BeforeStructInitialization option in BraceWrapping configuration

2021-11-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan added a comment.

In D91949#2747412 , @krasimir wrote:

> Do we have some widely used code style that requires the new option 
> (https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options)?

I have the same question.


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

https://reviews.llvm.org/D91949

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


[PATCH] D112903: [C++20] [Module] Fix front end crashes when trying to export a qualified entity which is already declared

2021-11-04 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu updated this revision to Diff 384968.
ChuanqiXu added a comment.

Updated diagnostic messages. It looks good to me to reject for exporting 
non-namespace-scope names in `diagnoseQualifiedDeclaration()`.


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

https://reviews.llvm.org/D112903

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/module/module.interface/p6.cpp


Index: clang/test/CXX/module/module.interface/p6.cpp
===
--- /dev/null
+++ clang/test/CXX/module/module.interface/p6.cpp
@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -std=c++20 %s -verify
+
+export module X;
+
+export template 
+struct X {
+  struct iterator {
+T node;
+  };
+  void foo() {}
+  template 
+  U bar();
+};
+
+export template  X::iterator;  // 
expected-error {{cannot export 'iterator' here since only the entities in 
namespace scope could be exported.}}
+export template  void X::foo();// 
expected-error {{cannot export 'foo' here since only the entities in namespace 
scope could be exported.}}
+export template  template  U X::bar(); // 
expected-error {{cannot export 'bar' here since only the entities in namespace 
scope could be exported.}}
+
+export struct Y {
+  struct iterator {
+int node;
+  };
+  void foo() {}
+  template 
+  U bar();
+};
+
+export struct Y::iterator;   // expected-error {{cannot export 
'iterator' here since only the entities in namespace scope could be exported.}}
+export void Y::foo();// expected-error {{cannot export 
'foo' here since only the entities in namespace scope could be exported.}}
+export template  U Y::bar(); // expected-error {{cannot export 
'bar' here since only the entities in namespace scope could be exported.}}
+
+export {
+  template  X::iterator; // expected-error {{cannot export 
'iterator' here since only the entities in namespace scope could be exported.}}
+  struct Y::iterator;   // expected-error {{cannot export 
'iterator' here since only the entities in namespace scope could be exported.}}
+}
+
+namespace A {
+export struct X;
+struct Y;
+export void foo();
+void bar();
+} // namespace A
+
+// [module.interface]/p6
+// A redeclaration of an entity X is implicitly exported if X was introduced 
by an exported declaration
+void A::foo();
+export struct A::X;   // expected-error {{cannot export redeclaration 'X' 
here.}}
+export struct A::Y;   // expected-error {{cannot export redeclaration 'Y' 
here.}}
+export void A::foo(); // expected-error {{cannot export redeclaration 'foo' 
here.}}
+// The compiler couldn't export A::bar() here since A::bar() is declared above 
without exported.
+// See [module.interface]/p6 for details.
+export void A::bar(); // expected-error {{cannot export redeclaration 'bar' 
here.}}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -5745,7 +5745,12 @@
 else if (isa(Cur))
   Diag(Loc, diag::err_invalid_declarator_in_block)
 << Name << SS.getRange();
-else
+else if (isa(Cur)) {
+  if (!isa(DC))
+Diag(Loc, diag::err_export_non_namespace_scope_name) << Name;
+  else
+Diag(Loc, diag::err_export_qualified_redeclaration) << Name;
+} else
   Diag(Loc, diag::err_invalid_declarator_scope)
   << Name << cast(Cur) << cast(DC) << SS.getRange();
 
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -7781,6 +7781,10 @@
   "%select{ or namespace|, namespace, or enumeration}1">;
 def err_invalid_declarator_scope : Error<"cannot define or redeclare %0 here "
   "because namespace %1 does not enclose namespace %2">;
+def err_export_non_namespace_scope_name : Error<"cannot export %0 here since "
+  "only the entities in namespace scope could be exported.">;
+def err_export_qualified_redeclaration : Error<"cannot export redeclaration "
+  "%0 here.">;
 def err_invalid_declarator_global_scope : Error<
   "definition or redeclaration of %0 cannot name the global scope">;
 def err_invalid_declarator_in_function : Error<


Index: clang/test/CXX/module/module.interface/p6.cpp
===
--- /dev/null
+++ clang/test/CXX/module/module.interface/p6.cpp
@@ -0,0 +1,52 @@
+// RUN: %clang_cc1 -std=c++20 %s -verify
+
+export module X;
+
+export template 
+struct X {
+  struct iterator {
+T node;
+  };
+  void foo() {}
+  template 
+  U bar();
+};
+
+export template  X::iterator;  // expected-error {{cannot export 'iterator' here since only the entities in namespace scope could be exported.}}
+export template  void X::foo

[PATCH] D112903: [C++20] [Module] Fix front end crashes when trying to export a qualified entity which is already declared

2021-11-04 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu requested review of this revision.
ChuanqiXu added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7784-7785
   "because namespace %1 does not enclose namespace %2">;
+def err_invalid_declarator_in_export : Error<"cannot export %0 here "
+  "because it had be declared in %1.">;
 def err_invalid_declarator_global_scope : Error<

ChuanqiXu wrote:
> urnathan wrote:
> > aaron.ballman wrote:
> > > ChuanqiXu wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > I think this diagnostic text is more clear based on the standards 
> > > > > > text you cited. This would also come with a note diagnostic to 
> > > > > > point to the previous declaration.
> > > > > Given that this is not intended for p6 specifically, I think my 
> > > > > suggestion is incorrect. But I am also not certain your diagnostic is 
> > > > > either, but it's really hard to tell given where our current support 
> > > > > is for modules. All of the other compilers suggest that an 
> > > > > unqualified id is expected to be found, and I tend to agree -- 
> > > > > there's no declaration there *to* export, just the type specifier for 
> > > > > a declaration. This makes me think the issue is elsewhere and perhaps 
> > > > > we shouldn't even be getting into `diagnoseQualifiedDeclaration()`.
> > > > I think we need to touch `diagnoseQualifiedDeclaration()` after all. 
> > > > Since there is a potential risk of crashing in it. If we didn't fix it 
> > > > in `diagnoseQualifiedDeclaration()` and find other place  to fix the 
> > > > issue, I think it may crash potentially one day in the process of 
> > > > developing or we might ignore some paths to  
> > > > diagnoseQualifiedDeclaration()`. It would be a disaster.
> > > > And you said "there's no declaration there *to* export". And I noticed 
> > > > that there is error/warning in `Sema::ParsedFreeStandingDeclSpec` which 
> > > > would emit this kind of error/warning. But as the title describes, it 
> > > > only works for free standing declaration, which is not the same with 
> > > > the issue in bug47715. And `diagnoseQualifiedDeclaration()` would 
> > > > handle the qualified redeclaration. So it looks a good place to me.
> > > > BTW, I found the current patch could handle [module.interface]/p6 
> > > > partially for qualified redeclaration surprisingly. See the newly added 
> > > > test case for example.
> > > > Finally, given that we need to touch `diagnoseQualifiedDeclaration()` 
> > > > to fix the crash, I think the patch should be good and we could try to 
> > > > cover [module.interface]/p6 in successive patches. Do you think so?
> > > > I think we need to touch diagnoseQualifiedDeclaration() after all. 
> > > > Since there is a potential risk of crashing in it. 
> > > 
> > > My point is that we may have wanted to reject this code before ever 
> > > needing to call `diagnoseQualifiedDeclaration()` in the first place. aka, 
> > > it might be just as valid to assert we never see an `ExportDecl` here 
> > > because the caller should have already handled that case.
> > > 
> > > > And you said "there's no declaration there *to* export". And I noticed 
> > > > that there is error/warning in Sema::ParsedFreeStandingDeclSpec which 
> > > > would emit this kind of error/warning. But as the title describes, it 
> > > > only works for free standing declaration, which is not the same with 
> > > > the issue in bug47715.
> > > 
> > > The declaration is invalid in C++20 because it does not declare anything 
> > > (this is the same example with the export keywords removed): 
> > > https://godbolt.org/z/8zc9q7fno
> > > 
> > > Clang fails the first one because we don't yet implement P0634R3, but the 
> > > presence of the export keyword should not change diagnostic behavior here.
> > > 
> > > 
> > Agreed, 'export' is only applicable to namespace-scope declarations.  We 
> > should reject it applying to non-namepace-scope entities.
> Got it. It is important to make the code semantics consistent with the spec.
@aaron.ballman @urnathan I have sent a draft to reject the codes before 
`diagnoseQualifiedDeclaration()`. The draft is here: 
https://reviews.llvm.org/D113239. The draft is not completed to review the 
details. The key idea is to insert checks for `ExportDecl` on the fly to 
construct the AST. Due to the complexity of semantics analysis , we might need 
to insert the checks many times. It may not be too terrible since I found many 
`Check*` functions in `Sema`. So may be this is what we used to do.

And the draft could reject the example in  
https://eel.is/c++draft/module.interface#6. It looks like not so hard as I 
imaged.

BTW, I have tried to let the compiler to emit "declaration does not declare 
anything" when it sees "export template  X::Y". But I failed. It 
is not easy for me. And I found that the compiler wouldn't emit "declaration 
does not declare anything" when the  declaration  is in a `Decl

[PATCH] D113096: [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

2021-11-04 Thread Kan Shengchen via Phabricator via cfe-commits
skan added a comment.

In D113096#3110546 , @skan wrote:

> In D113096#3110507 , @thakis wrote:
>
>> Looks like this breaks tests on Mac: http://45.33.8.238/mac/38266/step_11.txt
>>
>> Please take a look and revert for now if it takes a while to fix.
>
> I can quickly fix it.
>
> It's the issue of ambiguous triple.  You are using the 
> `-mtriple=x86_64-apple-mac*` while I am using 
> `-mtriple=x86_64-unknown-linux-gnu`

Fixed by 6d03227c16ee 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113096

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


[PATCH] D113096: [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

2021-11-04 Thread Kan Shengchen via Phabricator via cfe-commits
skan added a comment.

In D113096#3110507 , @thakis wrote:

> Looks like this breaks tests on Mac: http://45.33.8.238/mac/38266/step_11.txt
>
> Please take a look and revert for now if it takes a while to fix.

I can quickly fix it.

It's the issue of ambiguous triple.  You are using the 
`-mtriple=x86_64-apple-mac*` while I am using 
`-mtriple=x86_64-unknown-linux-gnu`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113096

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


[PATCH] D113096: [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

2021-11-04 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Looks like this breaks tests on Mac: http://45.33.8.238/mac/38266/step_11.txt

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113096

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


[PATCH] D112903: [C++20] [Module] Fix front end crashes when trying to export a qualified entity which is already declared

2021-11-04 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu planned changes to this revision.
ChuanqiXu added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7784-7785
   "because namespace %1 does not enclose namespace %2">;
+def err_invalid_declarator_in_export : Error<"cannot export %0 here "
+  "because it had be declared in %1.">;
 def err_invalid_declarator_global_scope : Error<

urnathan wrote:
> aaron.ballman wrote:
> > ChuanqiXu wrote:
> > > aaron.ballman wrote:
> > > > aaron.ballman wrote:
> > > > > I think this diagnostic text is more clear based on the standards 
> > > > > text you cited. This would also come with a note diagnostic to point 
> > > > > to the previous declaration.
> > > > Given that this is not intended for p6 specifically, I think my 
> > > > suggestion is incorrect. But I am also not certain your diagnostic is 
> > > > either, but it's really hard to tell given where our current support is 
> > > > for modules. All of the other compilers suggest that an unqualified id 
> > > > is expected to be found, and I tend to agree -- there's no declaration 
> > > > there *to* export, just the type specifier for a declaration. This 
> > > > makes me think the issue is elsewhere and perhaps we shouldn't even be 
> > > > getting into `diagnoseQualifiedDeclaration()`.
> > > I think we need to touch `diagnoseQualifiedDeclaration()` after all. 
> > > Since there is a potential risk of crashing in it. If we didn't fix it in 
> > > `diagnoseQualifiedDeclaration()` and find other place  to fix the issue, 
> > > I think it may crash potentially one day in the process of developing or 
> > > we might ignore some paths to  diagnoseQualifiedDeclaration()`. It would 
> > > be a disaster.
> > > And you said "there's no declaration there *to* export". And I noticed 
> > > that there is error/warning in `Sema::ParsedFreeStandingDeclSpec` which 
> > > would emit this kind of error/warning. But as the title describes, it 
> > > only works for free standing declaration, which is not the same with the 
> > > issue in bug47715. And `diagnoseQualifiedDeclaration()` would handle the 
> > > qualified redeclaration. So it looks a good place to me.
> > > BTW, I found the current patch could handle [module.interface]/p6 
> > > partially for qualified redeclaration surprisingly. See the newly added 
> > > test case for example.
> > > Finally, given that we need to touch `diagnoseQualifiedDeclaration()` to 
> > > fix the crash, I think the patch should be good and we could try to cover 
> > > [module.interface]/p6 in successive patches. Do you think so?
> > > I think we need to touch diagnoseQualifiedDeclaration() after all. Since 
> > > there is a potential risk of crashing in it. 
> > 
> > My point is that we may have wanted to reject this code before ever needing 
> > to call `diagnoseQualifiedDeclaration()` in the first place. aka, it might 
> > be just as valid to assert we never see an `ExportDecl` here because the 
> > caller should have already handled that case.
> > 
> > > And you said "there's no declaration there *to* export". And I noticed 
> > > that there is error/warning in Sema::ParsedFreeStandingDeclSpec which 
> > > would emit this kind of error/warning. But as the title describes, it 
> > > only works for free standing declaration, which is not the same with the 
> > > issue in bug47715.
> > 
> > The declaration is invalid in C++20 because it does not declare anything 
> > (this is the same example with the export keywords removed): 
> > https://godbolt.org/z/8zc9q7fno
> > 
> > Clang fails the first one because we don't yet implement P0634R3, but the 
> > presence of the export keyword should not change diagnostic behavior here.
> > 
> > 
> Agreed, 'export' is only applicable to namespace-scope declarations.  We 
> should reject it applying to non-namepace-scope entities.
Got it. It is important to make the code semantics consistent with the spec.


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

https://reviews.llvm.org/D112903

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


[PATCH] D110215: [C++2a] [Module] Support extern C/C++ semantics

2021-11-04 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

@rsmith @aaron.ballman gentle ping~


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

https://reviews.llvm.org/D110215

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


[clang-tools-extra] 6c6ccc7 - [NFC] Don't set rlimit in test with MSAN

2021-11-04 Thread Vitaly Buka via cfe-commits

Author: Vitaly Buka
Date: 2021-11-04T18:18:03-07:00
New Revision: 6c6ccc72a6124164df5b8445624d220d45cf4b6a

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

LOG: [NFC] Don't set rlimit in test with MSAN

Added: 


Modified: 
clang-tools-extra/clangd/unittests/SerializationTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/SerializationTests.cpp 
b/clang-tools-extra/clangd/unittests/SerializationTests.cpp
index f866635283e5f..548b027599650 100644
--- a/clang-tools-extra/clangd/unittests/SerializationTests.cpp
+++ b/clang-tools-extra/clangd/unittests/SerializationTests.cpp
@@ -306,8 +306,9 @@ TEST(SerializationTest, CmdlTest) {
 }
 
 // rlimit is part of POSIX.
-// ASan uses a lot of address space, so we can't apply strict limits.
-#if LLVM_ON_UNIX && !LLVM_ADDRESS_SANITIZER_BUILD
+// Sanitizers use a lot of address space, so we can't apply strict limits.
+#if LLVM_ON_UNIX && !LLVM_ADDRESS_SANITIZER_BUILD &&   
\
+!LLVM_MEMORY_SANITIZER_BUILD
 class ScopedMemoryLimit {
   struct rlimit OriginalLimit;
   bool Succeeded = false;



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


[PATCH] D113096: [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

2021-11-04 Thread Kan Shengchen via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe08e452f366: [X86][MS-InlineAsm] Add constraint *m for 
memory access w/ global var (authored by skan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113096

Files:
  clang/test/CodeGen/X86/ms_fmul.c
  clang/test/CodeGen/ms-inline-asm-static-variable.c
  clang/test/CodeGen/ms-inline-asm-variables.c
  llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
  llvm/test/CodeGen/X86/ms-inline-asm-array.ll

Index: llvm/test/CodeGen/X86/ms-inline-asm-array.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/ms-inline-asm-array.ll
@@ -0,0 +1,22 @@
+; RUN: llc < %s -mcpu=x86-64  | FileCheck %s
+
+@arr = internal global [10 x i32] zeroinitializer, align 16
+
+; CHECK: movl%edx, arr(,%rdx,4)
+define dso_local i32 @main() #0 {
+entry:
+  call void asm sideeffect inteldialect "mov dword ptr $0[rdx * $$4],edx", "=*m,~{dirflag},~{fpsr},~{flags}"([10 x i32]* @arr) #1, !srcloc !4
+  ret i32 0
+}
+
+attributes #0 = { noinline nounwind optnone uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
+attributes #1 = { nounwind }
+
+!llvm.module.flags = !{!0, !1, !2}
+!llvm.ident = !{!3}
+
+!0 = !{i32 1, !"wchar_size", i32 4}
+!1 = !{i32 7, !"uwtable", i32 1}
+!2 = !{i32 7, !"frame-pointer", i32 2}
+!3 = !{!"clang"}
+!4 = !{i64 63}
Index: llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
===
--- llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
+++ llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
@@ -1758,8 +1758,8 @@
   // It is widely common for MS InlineAsm to use a global variable and one/two
   // registers in a mmory expression, and though unaccessible via rip/eip.
   if (IsGlobalLV && (BaseReg || IndexReg)) {
-Operands.push_back(
-X86Operand::CreateMem(getPointerWidth(), Disp, Start, End, Size));
+Operands.push_back(X86Operand::CreateMem(getPointerWidth(), Disp, Start,
+ End, Size, Identifier, Decl));
 return false;
   }
   // Otherwise, we set the base register to a non-zero value
@@ -2551,6 +2551,8 @@
   StringRef ErrMsg;
   unsigned BaseReg = SM.getBaseReg();
   unsigned IndexReg = SM.getIndexReg();
+  if (IndexReg && BaseReg == X86::RIP)
+BaseReg = 0;
   unsigned Scale = SM.getScale();
   if (!PtrInOperand)
 Size = SM.getElementSize() << 3;
Index: clang/test/CodeGen/ms-inline-asm-variables.c
===
--- clang/test/CodeGen/ms-inline-asm-variables.c
+++ clang/test/CodeGen/ms-inline-asm-variables.c
@@ -3,19 +3,19 @@
 
 int gVar;
 void t1() {
-  // CHECK: add eax, dword ptr gVar[eax]
+  // CHECK: add eax, dword ptr ${{[0-9]}}[eax]
   __asm add eax, dword ptr gVar[eax]
-  // CHECK: add dword ptr gVar[eax], eax
+  // CHECK: add dword ptr ${{[0-9]}}[eax], eax
   __asm add dword ptr [eax+gVar], eax
-  // CHECK: add ebx, dword ptr gVar[ebx + $$270]
+  // CHECK: add ebx, dword ptr ${{[0-9]}}[ebx + $$270]
   __asm add ebx, dword ptr gVar[271 - 82 + 81 + ebx]
-  // CHECK: add dword ptr gVar[ebx + $$828], ebx
+  // CHECK: add dword ptr ${{[0-9]}}[ebx + $$828], ebx
   __asm add dword ptr [ebx + gVar + 828], ebx
-  // CHECK: add ecx, dword ptr gVar[ecx + ecx * $$4 + $$4590]
+  // CHECK: add ecx, dword ptr ${{[0-9]}}[ecx + ecx * $$4 + $$4590]
   __asm add ecx, dword ptr gVar[4590 + ecx + ecx*4]
-  // CHECK: add dword ptr gVar[ecx + ecx * $$8 + $$73], ecx
+  // CHECK: add dword ptr ${{[0-9]}}[ecx + ecx * $$8 + $$73], ecx
   __asm add dword ptr [gVar + ecx + 45 + 23 - 53 + 60 - 2 + ecx*8], ecx
-  // CHECK: add gVar[ecx + ebx + $$7], eax
+  // CHECK: add ${{[0-9]}}[ecx + ebx + $$7], eax
   __asm add 1 + 1 + 2 + 3[gVar + ecx + ebx], eax
 }
 
@@ -32,4 +32,3 @@
   // CHECK: mov ${{[0-9]}}[ebx + $$47], eax
   __asm mov 5 + 8 + 13 + 21[lVar + ebx], eax
 }
-
Index: clang/test/CodeGen/ms-inline-asm-static-variable.c
===
--- /dev/null
+++ clang/test/CodeGen/ms-inline-asm-static-variable.c
@@ -0,0 +1,10 @@
+// REQUIRES: x86-registered-target
+// Check the constraint "*m" of operand arr and the definition of arr is not removed by FE
+// RUN: %clang_cc1 %s -fasm-blocks -triple i386-apple-darwin10 -emit-llvm -o - | FileCheck %s
+
+static int arr[10];
+void t1() {
+  // CHECK: @arr = internal global [10 x i32]
+  // CHECK: call void asm sideeffect inteldialect "mov dword ptr $0[edx * $$4],edx", "=*m,{{.*}}([10 x i32]* @arr)
+  __asm mov  dword ptr arr[edx*4],edx
+}
Index: clang/test/CodeGen/X86/ms_fmul.c
===
--- clang/test/CodeGen/X86/ms_fmul.c
+++ 

[clang] be08e45 - [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

2021-11-04 Thread Shengchen Kan via cfe-commits

Author: Shengchen Kan
Date: 2021-11-05T09:11:41+08:00
New Revision: be08e452f36602cd73f816787bf16d1a0405ff09

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

LOG: [X86][MS-InlineAsm] Add constraint *m for memory access w/ global var

Constraint `*m` should be used when the address of a variable is passed
as a value. And the constraint is missing for MS inline assembly when sth
is written to the address of the variable.

The missing would cause FE delete the definition of the static varible,
and then result in "undefined reference to xxx" issue.

Reviewed By: xiangzhangllvm

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

Added: 
clang/test/CodeGen/ms-inline-asm-static-variable.c
llvm/test/CodeGen/X86/ms-inline-asm-array.ll

Modified: 
clang/test/CodeGen/X86/ms_fmul.c
clang/test/CodeGen/ms-inline-asm-variables.c
llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp

Removed: 




diff  --git a/clang/test/CodeGen/X86/ms_fmul.c 
b/clang/test/CodeGen/X86/ms_fmul.c
index a0a1be9e217c5..d1cfcef814625 100644
--- a/clang/test/CodeGen/X86/ms_fmul.c
+++ b/clang/test/CodeGen/X86/ms_fmul.c
@@ -18,4 +18,4 @@ void __attribute__ ((naked)) foo(void)
 }}
 
 // CHECK-LABEL: foo
-// CHECK: call void asm sideeffect inteldialect "fmul qword ptr 
static_const_table[edx + $$240]\0A\09ret"
+// CHECK: call void asm sideeffect inteldialect "fmul qword ptr $0[edx + 
$$240]\0A\09ret"

diff  --git a/clang/test/CodeGen/ms-inline-asm-static-variable.c 
b/clang/test/CodeGen/ms-inline-asm-static-variable.c
new file mode 100644
index 0..fb80bf7b2f74f
--- /dev/null
+++ b/clang/test/CodeGen/ms-inline-asm-static-variable.c
@@ -0,0 +1,10 @@
+// REQUIRES: x86-registered-target
+// Check the constraint "*m" of operand arr and the definition of arr is not 
removed by FE
+// RUN: %clang_cc1 %s -fasm-blocks -triple i386-apple-darwin10 -emit-llvm -o - 
| FileCheck %s
+
+static int arr[10];
+void t1() {
+  // CHECK: @arr = internal global [10 x i32]
+  // CHECK: call void asm sideeffect inteldialect "mov dword ptr $0[edx * 
$$4],edx", "=*m,{{.*}}([10 x i32]* @arr)
+  __asm mov  dword ptr arr[edx*4],edx
+}

diff  --git a/clang/test/CodeGen/ms-inline-asm-variables.c 
b/clang/test/CodeGen/ms-inline-asm-variables.c
index f8fd227610b64..7d0cb3fbcc8f8 100644
--- a/clang/test/CodeGen/ms-inline-asm-variables.c
+++ b/clang/test/CodeGen/ms-inline-asm-variables.c
@@ -3,19 +3,19 @@
 
 int gVar;
 void t1() {
-  // CHECK: add eax, dword ptr gVar[eax]
+  // CHECK: add eax, dword ptr ${{[0-9]}}[eax]
   __asm add eax, dword ptr gVar[eax]
-  // CHECK: add dword ptr gVar[eax], eax
+  // CHECK: add dword ptr ${{[0-9]}}[eax], eax
   __asm add dword ptr [eax+gVar], eax
-  // CHECK: add ebx, dword ptr gVar[ebx + $$270]
+  // CHECK: add ebx, dword ptr ${{[0-9]}}[ebx + $$270]
   __asm add ebx, dword ptr gVar[271 - 82 + 81 + ebx]
-  // CHECK: add dword ptr gVar[ebx + $$828], ebx
+  // CHECK: add dword ptr ${{[0-9]}}[ebx + $$828], ebx
   __asm add dword ptr [ebx + gVar + 828], ebx
-  // CHECK: add ecx, dword ptr gVar[ecx + ecx * $$4 + $$4590]
+  // CHECK: add ecx, dword ptr ${{[0-9]}}[ecx + ecx * $$4 + $$4590]
   __asm add ecx, dword ptr gVar[4590 + ecx + ecx*4]
-  // CHECK: add dword ptr gVar[ecx + ecx * $$8 + $$73], ecx
+  // CHECK: add dword ptr ${{[0-9]}}[ecx + ecx * $$8 + $$73], ecx
   __asm add dword ptr [gVar + ecx + 45 + 23 - 53 + 60 - 2 + ecx*8], ecx
-  // CHECK: add gVar[ecx + ebx + $$7], eax
+  // CHECK: add ${{[0-9]}}[ecx + ebx + $$7], eax
   __asm add 1 + 1 + 2 + 3[gVar + ecx + ebx], eax
 }
 
@@ -32,4 +32,3 @@ void t2() {
   // CHECK: mov ${{[0-9]}}[ebx + $$47], eax
   __asm mov 5 + 8 + 13 + 21[lVar + ebx], eax
 }
-

diff  --git a/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp 
b/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
index 511d263abbaab..88b993fb827c8 100644
--- a/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
+++ b/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
@@ -1758,8 +1758,8 @@ bool X86AsmParser::CreateMemForMSInlineAsm(
   // It is widely common for MS InlineAsm to use a global variable and one/two
   // registers in a mmory expression, and though unaccessible via rip/eip.
   if (IsGlobalLV && (BaseReg || IndexReg)) {
-Operands.push_back(
-X86Operand::CreateMem(getPointerWidth(), Disp, Start, End, Size));
+Operands.push_back(X86Operand::CreateMem(getPointerWidth(), Disp, Start,
+ End, Size, Identifier, Decl));
 return false;
   }
   // Otherwise, we set the base register to a non-zero value
@@ -2551,6 +2551,8 @@ bool X86AsmParser::ParseIntelOperand(OperandVector 
&Operands) {
   StringRef ErrMsg;
   unsigned BaseReg = SM.getBaseReg();
   unsigned IndexReg = SM.getIndexReg();
+  if (IndexReg && BaseReg == X86::RIP)
+BaseReg = 0

[PATCH] D109496: [clang] deprecate frelaxed-template-template-args, make it on by default

2021-11-04 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 384929.
mizvekov added a comment.

.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109496

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/Driver/frelaxed-template-template-args.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/SemaTemplate/default-arguments.cpp
  clang/test/SemaTemplate/instantiate-template-template-parm.cpp
  clang/test/SemaTemplate/nested-template.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp
  clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -596,7 +596,7 @@
 You can use Clang in C++17 mode with the -std=c++17 option
 (use -std=c++1z in Clang 4 and earlier).
 
-
+
 List of features and minimum Clang version with support
 
 
@@ -813,8 +813,8 @@
 
 
   Matching template template parameters to compatible arguments
-  https://wg21.link/p0522r0";>P0522R0
-  Partial (10)
+  https://wg21.link/p0522r0";>P0522R0 (DR)
+  Clang 4 (10)
 
 
   Removing deprecated dynamic exception specifications
@@ -842,13 +842,10 @@
 reverse construction order in that ABI.
 This is not fully supported during constant expression evaluation until Clang 12.
 
-(10): Despite being the resolution to a Defect Report, this
-feature is disabled by default in all language versions, and can be enabled
-explicitly with the flag -frelaxed-template-template-args in Clang 4
-onwards.
-The change to the standard lacks a corresponding change for template partial
-ordering, resulting in ambiguity errors for reasonable and previously-valid
-code. This issue is expected to be rectified soon.
+(10): Prior to Clang 14, this feature is not enabled by
+default, but can be enabled with -frelaxed-template-template-args.
+Starting from Clang 14, the flag is deprecated and will be removed in a future
+version.
 
 
 
Index: clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z -frelaxed-template-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z %s
 
 // expected-note@temp_arg_template_cxx1z.cpp:* 1+{{}}
 
Index: clang/test/SemaTemplate/temp_arg_template.cpp
===
--- clang/test/SemaTemplate/temp_arg_template.cpp
+++ clang/test/SemaTemplate/temp_arg_template.cpp
@@ -6,11 +6,11 @@
 
 template class X> struct B; // expected-note{{previous template template parameter is here}}
 
-template class X> struct C;  // expected-note 2{{previous non-type template parameter with type 'int' is here}}
+template class X> struct C;  // expected-note {{previous non-type template parameter with type 'int' is here}}
 
 template struct X; // expected-note{{too few template parameters in template template argument}}
 template struct Y; // expected-note{{template parameter has a different kind in template argument}}
-template struct Ylong; // expected-note{{template non-type parameter has a different type 'long' in template argument}}
+template struct Ylong;
 template struct Yref; // expected-note{{template non-type parameter has a different type 'const int &' in template argument}}
 
 namespace N {
@@ -27,7 +27,7 @@
 A *a5; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 B *a6; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 C *a7;
-C *a8; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
+C *a8;
 C *a9; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 
 template void f(int);
Index: clang/test/SemaTemplate/nested-template.cpp
===
--- clang/test/SemaTemplate/nested-template.cpp
+++ clang/test/SemaTemplate/nested-template.cpp
@@ -112,18 +112,16 @@
 // Template template parameters
 template
 struct X2 {
-  template class>  // expected-error{{cannot have type 'float'}} \
-   

[PATCH] D112098: [ASan] Added stack safety support in address sanitizer.

2021-11-04 Thread Kirill Stoimenov via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
kstoimenov marked an inline comment as done.
Closed by commit rG3f1aca58df8f: [ASan] Added stack safety support in address 
sanitizer. (authored by kstoimenov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112098

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
@@ -0,0 +1,19 @@
+; REQUIRES: x86-registered-target
+
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=0  -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=0 -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; NOSAFETY: call void @__asan_load1
+; SAFETY-NOT: call void @__asan_load1
+
+define i32 @stack-safety() sanitize_address {
+  %buf = alloca [10 x i8], align 1
+  %arrayidx = getelementptr inbounds [10 x i8], [10 x i8]* %buf, i64 0, i64 0
+  %1 = load i8, i8* %arrayidx, align 1
+  ret i32 0
+}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -26,6 +26,7 @@
 #include "llvm/ADT/Triple.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/Analysis/MemoryBuiltins.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/BinaryFormat/MachO.h"
@@ -47,6 +48,7 @@
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/InlineAsm.h"
+#include "llvm/IR/InstIterator.h"
 #include "llvm/IR/InstVisitor.h"
 #include "llvm/IR/InstrTypes.h"
 #include "llvm/IR/Instruction.h"
@@ -211,6 +213,11 @@
 "asan-instrument-writes", cl::desc("instrument write instructions"),
 cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("asan-use-stack-safety", cl::Hidden, cl::init(false),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClInstrumentAtomics(
 "asan-instrument-atomics",
 cl::desc("instrument atomic instructions (rmw, cmpxchg)"), cl::Hidden,
@@ -647,6 +654,7 @@
 /// AddressSanitizer: instrument the code in module to find memory bugs.
 struct AddressSanitizer {
   AddressSanitizer(Module &M, const GlobalsMetadata *GlobalsMD,
+   const StackSafetyGlobalInfo *SSGI,
bool CompileKernel = false, bool Recover = false,
bool UseAfterScope = false,
AsanDetectStackUseAfterReturnMode UseAfterReturn =
@@ -657,7 +665,7 @@
 UseAfterScope(UseAfterScope || ClUseAfterScope),
 UseAfterReturn(ClUseAfterReturn.getNumOccurrences() ? ClUseAfterReturn
 : UseAfterReturn),
-GlobalsMD(*GlobalsMD) {
+GlobalsMD(*GlobalsMD), SSGI(SSGI) {
 C = &(M.getContext());
 LongSize = M.getDataLayout().getPointerSizeInBits();
 IntptrTy = Type::getIntNTy(*C, LongSize);
@@ -686,7 +694,7 @@
   /// Check if we want (and can) handle this alloca.
   bool isInterestingAlloca(const AllocaInst &AI);
 
-  bool ignoreAccess(Value *Ptr);
+  bool ignoreAccess(Instruction *Inst, Value *Ptr);
   void getInterestingMemoryOperands(
   Instruction *I, SmallVectorImpl &Interesting);
 
@@ -771,6 +779,7 @@
   FunctionCallee AsanMemmove, AsanMemcpy, AsanMemset;
   Value *LocalDynamicShadow = nullptr;
   const GlobalsMetadata &GlobalsMD;
+  const StackSafetyGlobalInfo *SSGI;
   DenseMap ProcessedAllocas;
 
   FunctionCallee AMDGPUAddressShared;
@@ -797,16 +806,22 @@
 
   void getAnalysisUsage(AnalysisUsage &AU) const override {
 AU.addRequired();
+if (ClUseStackSafety)
+  AU.addRequired();
 AU.addRequired();
   }
 
   bool runOnFunction(Function &F) override {
 GlobalsMetadata &GlobalsMD =
 getAnalysis().getGlobalsMD();
+const StackSafetyGlobalInfo *const SSGI =
+ClUseStackSafety
+? &getAn

[PATCH] D112914: Misleading identifier detection

2021-11-04 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.

In D112914#3102728 , @carlosgalvezp 
wrote:

> I don't know how to remove the "Requested changes" from here so I'll just 
> remove myself from reviewer.

Marking the change as accepted should overwrite the "requested changes" state.


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

https://reviews.llvm.org/D112914

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


[PATCH] D112491: Add `LambdaCapture`-related matchers.

2021-11-04 Thread James King via Phabricator via cfe-commits
jcking1034 marked an inline comment as done.
jcking1034 added a comment.

@fowles @aaron.ballman I'll take a look at `forEachCapture` in the next patch. 
Also, I've discovered that the `VarDecl` node has a member function 
`isInitCapture` that seems like it could allow us to distinguish between 
captures with and without initializers (link 
)
 - I want to play around with that, as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

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


[PATCH] D112098: [ASan] Added stack safety support in address sanitizer.

2021-11-04 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov updated this revision to Diff 384902.
kstoimenov added a comment.

Moved AddressSanitizer back to the loop.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112098

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
@@ -0,0 +1,19 @@
+; REQUIRES: x86-registered-target
+
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=0  -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=0 -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; NOSAFETY: call void @__asan_load1
+; SAFETY-NOT: call void @__asan_load1
+
+define i32 @stack-safety() sanitize_address {
+  %buf = alloca [10 x i8], align 1
+  %arrayidx = getelementptr inbounds [10 x i8], [10 x i8]* %buf, i64 0, i64 0
+  %1 = load i8, i8* %arrayidx, align 1
+  ret i32 0
+}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -26,6 +26,7 @@
 #include "llvm/ADT/Triple.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/Analysis/MemoryBuiltins.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/BinaryFormat/MachO.h"
@@ -47,6 +48,7 @@
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/InlineAsm.h"
+#include "llvm/IR/InstIterator.h"
 #include "llvm/IR/InstVisitor.h"
 #include "llvm/IR/InstrTypes.h"
 #include "llvm/IR/Instruction.h"
@@ -211,6 +213,11 @@
 "asan-instrument-writes", cl::desc("instrument write instructions"),
 cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("asan-use-stack-safety", cl::Hidden, cl::init(false),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClInstrumentAtomics(
 "asan-instrument-atomics",
 cl::desc("instrument atomic instructions (rmw, cmpxchg)"), cl::Hidden,
@@ -647,6 +654,7 @@
 /// AddressSanitizer: instrument the code in module to find memory bugs.
 struct AddressSanitizer {
   AddressSanitizer(Module &M, const GlobalsMetadata *GlobalsMD,
+   const StackSafetyGlobalInfo *SSGI,
bool CompileKernel = false, bool Recover = false,
bool UseAfterScope = false,
AsanDetectStackUseAfterReturnMode UseAfterReturn =
@@ -657,7 +665,7 @@
 UseAfterScope(UseAfterScope || ClUseAfterScope),
 UseAfterReturn(ClUseAfterReturn.getNumOccurrences() ? ClUseAfterReturn
 : UseAfterReturn),
-GlobalsMD(*GlobalsMD) {
+GlobalsMD(*GlobalsMD), SSGI(SSGI) {
 C = &(M.getContext());
 LongSize = M.getDataLayout().getPointerSizeInBits();
 IntptrTy = Type::getIntNTy(*C, LongSize);
@@ -686,7 +694,7 @@
   /// Check if we want (and can) handle this alloca.
   bool isInterestingAlloca(const AllocaInst &AI);
 
-  bool ignoreAccess(Value *Ptr);
+  bool ignoreAccess(Instruction *Inst, Value *Ptr);
   void getInterestingMemoryOperands(
   Instruction *I, SmallVectorImpl &Interesting);
 
@@ -771,6 +779,7 @@
   FunctionCallee AsanMemmove, AsanMemcpy, AsanMemset;
   Value *LocalDynamicShadow = nullptr;
   const GlobalsMetadata &GlobalsMD;
+  const StackSafetyGlobalInfo *SSGI;
   DenseMap ProcessedAllocas;
 
   FunctionCallee AMDGPUAddressShared;
@@ -797,16 +806,22 @@
 
   void getAnalysisUsage(AnalysisUsage &AU) const override {
 AU.addRequired();
+if (ClUseStackSafety)
+  AU.addRequired();
 AU.addRequired();
   }
 
   bool runOnFunction(Function &F) override {
 GlobalsMetadata &GlobalsMD =
 getAnalysis().getGlobalsMD();
+const StackSafetyGlobalInfo *const SSGI =
+ClUseStackSafety
+? &getAnalysis().getResult()
+: nullptr;
 const TargetLibraryInfo *TLI =
 &getAnalysis().getTLI(F);
-AddressSanitizer ASan(*F.getParent(), &GlobalsMD, 

[PATCH] D112098: [ASan] Added stack safety support in address sanitizer.

2021-11-04 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka accepted this revision.
vitalybuka added inline comments.
This revision is now accepted and ready to land.



Comment at: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp:1328
+  ClUseStackSafety ? &MAM.getResult(M) : 
nullptr;
+  AddressSanitizer FunctionSanitizer(M, &GlobalsMD, SSGI, 
Options.CompileKernel,
+ Options.Recover, Options.UseAfterScope,

There is ::ProcessedAllocas which will be unnececary overpopulated with 
irrelevand allocas
Maybe add FunctionSanitizer.Reset()

But please do that  in a separate patch, this optimization is unrelated to SSGI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112098

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


[PATCH] D113211: [NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/

2021-11-04 Thread Jan Korous via Phabricator via cfe-commits
jkorous requested changes to this revision.
jkorous added a comment.
This revision now requires changes to proceed.

Hi! Thank you for the clean-up :)

I feel there might be a bit of work still left. While renaming filenames and 
function names should be mostly inconsequential renaming command line options 
and sanitizer ignorelist content (and by that changing the syntax) most likely 
need accompanying changes in clang itself.

I noticed you have at least one other similar patch but I don't see the changes 
I'd expect there - please let me know if I'm just missing something!

Do the tests actually pass with this patch?




Comment at: clang/test/CodeGen/address-safety-attr.cpp:9
 
-// RUN: echo "fun:*BlacklistedFunction*" > %t.func.blacklist
-// RUN: %clang_cc1 -std=c++11 -triple x86_64-apple-darwin -disable-O0-optnone 
-emit-llvm -o - %s -include %t.extra-source.cpp -fsanitize=address 
-fsanitize-blacklist=%t.func.blacklist | FileCheck -check-prefix=BLFUNC %s
+// RUN: echo "fun:*IgnorelistedFunction*" > %t.func.ignorelist
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-apple-darwin -disable-O0-optnone 
-emit-llvm -o - %s -include %t.extra-source.cpp -fsanitize=address 
-fsanitize-ignorelist=%t.func.ignorelist | FileCheck -check-prefix=BLFUNC %s

Shouldn't we teach ASan about the new syntax of ignorelist as well 
`fun:*IgnorelistedFunction*`?



Comment at: clang/test/CodeGen/address-safety-attr.cpp:10
+// RUN: echo "fun:*IgnorelistedFunction*" > %t.func.ignorelist
+// RUN: %clang_cc1 -std=c++11 -triple x86_64-apple-darwin -disable-O0-optnone 
-emit-llvm -o - %s -include %t.extra-source.cpp -fsanitize=address 
-fsanitize-ignorelist=%t.func.ignorelist | FileCheck -check-prefix=BLFUNC %s
 

Shouldn't the change of the option name to `-fsanitize-ignorelist` in tests be 
accompanied with analogous change in driver and/or cc1 options definition?



Comment at: clang/test/CodeGenCXX/cfi-ignorelist.cpp:3
 
-// Check that blacklisting cfi and cfi-vcall work correctly
+// Check that ignore listing cfi and cfi-vcall work correctly
 // RUN: echo "[cfi-vcall]" > %t.vcall.txt

We should use the verb "to ignorelist smth" (without the space) consistently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113211

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


[PATCH] D108479: [Clang] Add __builtin_addressof_nocfi

2021-11-04 Thread Sami Tolvanen via Phabricator via cfe-commits
samitolvanen updated this revision to Diff 384897.
samitolvanen added a comment.

Keep a `void *` return type for the nocfi variant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108479

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/APValue.h
  clang/include/clang/Basic/Builtins.def
  clang/lib/AST/APValue.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp
  clang/test/CodeGen/builtin-addressof-nocfi.c
  clang/test/SemaCXX/builtins.cpp

Index: clang/test/SemaCXX/builtins.cpp
===
--- clang/test/SemaCXX/builtins.cpp
+++ clang/test/SemaCXX/builtins.cpp
@@ -39,6 +39,15 @@
   S *ptmp = __builtin_addressof(S{}); // expected-error {{taking the address of a temporary}}
 }
 
+namespace addressof_nocfi {
+void a(void) {}
+static_assert(__builtin_addressof_nocfi(a) == a, "");
+
+struct S {
+} s;
+static_assert(__builtin_addressof_nocfi(s) == &s, "");
+} // namespace addressof_nocfi
+
 void no_ms_builtins() {
   __assume(1); // expected-error {{use of undeclared}}
   __noop(1); // expected-error {{use of undeclared}}
Index: clang/test/CodeGen/builtin-addressof-nocfi.c
===
--- /dev/null
+++ clang/test/CodeGen/builtin-addressof-nocfi.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -fsanitize=cfi-icall -o - %s | FileCheck %s
+
+#if !__has_builtin(__builtin_addressof_nocfi)
+#error "missing __builtin_addressof_nocfi"
+#endif
+
+void a(void) {}
+void b(void) {}
+void c(void (*p)(void)) {
+  p();
+}
+
+// CHECK: @e = constant void ()* no_cfi @a
+void (*const e)(void) = __builtin_addressof_nocfi(a);
+// CHECK: @f = global [2 x void ()*] [void ()* @b, void ()* no_cfi @b]
+void (*f[])(void) = {b, __builtin_addressof_nocfi(b)};
+
+void d(void) {
+  // CHECK: store void ()* no_cfi @b, void ()** %g
+  void (*g)(void) = __builtin_addressof_nocfi(b);
+  // CHECK: call void @c(void ()* no_cfi @a)
+  c(__builtin_addressof_nocfi(a));
+  e();
+  f[1]();
+  g();
+}
Index: clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp
@@ -66,7 +66,8 @@
   case Builtin::BI__builtin_expect:
   case Builtin::BI__builtin_expect_with_probability:
   case Builtin::BI__builtin_assume_aligned:
-  case Builtin::BI__builtin_addressof: {
+  case Builtin::BI__builtin_addressof:
+  case Builtin::BI__builtin_addressof_nocfi: {
 // For __builtin_unpredictable, __builtin_expect,
 // __builtin_expect_with_probability and __builtin_assume_aligned,
 // just return the value of the subexpression.
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -179,9 +179,10 @@
   return false;
 }
 
-/// Check that the argument to __builtin_addressof is a glvalue, and set the
-/// result type to the corresponding pointer type.
-static bool SemaBuiltinAddressof(Sema &S, CallExpr *TheCall) {
+/// Check that the argument to __builtin_addressof(_nocfi)? is a glvalue, and
+/// set the result type to the corresponding pointer type for the nocfi variant.
+static bool SemaBuiltinAddressof(Sema &S, CallExpr *TheCall,
+ unsigned BuiltinID) {
   if (checkArgCount(S, TheCall, 1))
 return true;
 
@@ -191,7 +192,8 @@
 return true;
 
   TheCall->setArg(0, Arg.get());
-  TheCall->setType(ResultType);
+  if (BuiltinID == Builtin::BI__builtin_addressof)
+TheCall->setType(ResultType);
   return false;
 }
 
@@ -1749,7 +1751,8 @@
   return ExprError();
 break;
   case Builtin::BI__builtin_addressof:
-if (SemaBuiltinAddressof(*this, TheCall))
+  case Builtin::BI__builtin_addressof_nocfi:
+if (SemaBuiltinAddressof(*this, TheCall, BuiltinID))
   return ExprError();
 break;
   case Builtin::BI__builtin_is_aligned:
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -1889,8 +1889,12 @@
 if (D->hasAttr())
   return CGM.GetWeakRefReference(D).getPointer();
 
-if (auto FD = dyn_cast(D))
-  return CGM.GetAddrOfFunction(FD);
+if (const auto *FD = dyn_cast(D)) {
+  llvm::Constant *C = CGM.GetAddrOfFunction(FD);
+  if (base.isNoCFIValue())
+return llvm::NoCFIValue::get(cast(C));
+  return C;
+}
 
 if (auto VD = dyn_cast(D)) {
   // We can never refer to a variable with local storage.
Index

[PATCH] D106585: Fix clang debug info irgen of i128 enums

2021-11-04 Thread Mike Hommey via Phabricator via cfe-commits
glandium added a comment.

This broke determinism when building Firefox.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106585

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


[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson updated this revision to Diff 384890.
CJ-Johnson added a comment.

Change static_cast suggested edit to use parens instead of braces


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-stringview-nullptr.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
@@ -0,0 +1,1030 @@
+// RUN: %check_clang_tidy %s bugprone-stringview-nullptr -std=c++17 %t
+
+namespace std {
+
+using nullptr_t = decltype(nullptr);
+
+template 
+T &&declval();
+
+template 
+struct type_identity { using type = T; };
+template 
+using type_identity_t = typename type_identity::type;
+
+template 
+class basic_string_view {
+public:
+  basic_string_view();
+  basic_string_view(const C *);
+  basic_string_view(const basic_string_view &);
+  basic_string_view &operator=(const basic_string_view &);
+};
+
+template 
+bool operator<(basic_string_view, basic_string_view);
+template 
+bool operator<(type_identity_t>, basic_string_view);
+template 
+bool operator<(basic_string_view, type_identity_t>);
+
+template 
+bool operator<=(basic_string_view, basic_string_view);
+template 
+bool operator<=(type_identity_t>, basic_string_view);
+template 
+bool operator<=(basic_string_view, type_identity_t>);
+
+template 
+bool operator>(basic_string_view, basic_string_view);
+template 
+bool operator>(type_identity_t>, basic_string_view);
+template 
+bool operator>(basic_string_view, type_identity_t>);
+
+template 
+bool operator>=(basic_string_view, basic_string_view);
+template 
+bool operator>=(type_identity_t>, basic_string_view);
+template 
+bool operator>=(basic_string_view, type_identity_t>);
+
+template 
+bool operator==(basic_string_view, basic_string_view);
+template 
+bool operator==(type_identity_t>, basic_string_view);
+template 
+bool operator==(basic_string_view, type_identity_t>);
+
+template 
+bool operator!=(basic_string_view, basic_string_view);
+template 
+bool operator!=(type_identity_t>, basic_string_view);
+template 
+bool operator!=(basic_string_view, type_identity_t>);
+
+using string_view = basic_string_view;
+
+} // namespace std
+
+void function(std::string_view);
+void function(std::string_view, std::string_view);
+
+void temporary_construction() /* a */ {
+  // Functional Cast
+  {
+(void)(std::string_view(nullptr)) /* a1 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a1 */;{{$}}
+
+(void)(std::string_view((nullptr))) /* a2 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a2 */;{{$}}
+
+(void)(std::string_view({nullptr})) /* a3 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a3 */;{{$}}
+
+(void)(std::string_view({(nullptr)})) /* a4 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a4 */;{{$}}
+
+// (void)(const std::string_view(nullptr)) /* a5 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view((nullptr))) /* a6 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({nullptr})) /* a7 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({(nullptr)})) /* a8 */;
+// CV qualifiers do not compile in this context
+  }
+
+  // Temporary Object
+  {
+(void)(std::string_view{nullptr}) /* a9 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view{}) /* a9 */;{{$}}
+
+(void)(std::string_view{(nullptr)}) /* a10 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+   

[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

Sorry for being late to the party. Itay's explanation is correct to me.
I don't know much about multiversioned functions. My reply below if for ifunc.

- On ELF, an alias is just a symbol sharing st_shndx/st_value with another 
symbol. It is not by name. The target symbol can be overridden (say STB_WEAK 
overridden by STB_GLOBAL) while the alias itself remains unchanged.
- GNU indirect function is an ELF specific feature. Mach-O has a similar 
feature `N_SYMBOL_RESOLVER` but it is not modeled by an LLVM IR construct.
- While an assembler can create an "undefined ifunc" (`{st_shndx=0, 
st_info=STB_GLOBAL<<4 | STT_GNU_IFUNC}`), it is no different from a regular 
undefined symbol (`{st_shndx=0, st_info=STB_GLOBAL<<4 | STT_NOTYPE}`). You can 
check that the linker just ignore the STT_GNU_IFUNC type when replacing it with 
a definition. [1]
- For the GNU function attribute `__attribute__((ifunc(...)))`, GCC requires 
that the target is defined. The LLVM IR construct models the C/C++ syntax, so 
it makes sense to enforce the same requirement.

[1]:

  echo '.type foo, @gnu_indirect_function' > a.s
  echo '.globl foo; .type foo, @function; foo: ret' > b.s
  gcc -c a.s b.s
  ld a.o b.o
  readelf -Ws a.out



> ... If no translation unit in the EXE/DSO had an ifunc with the same name and 
> a defined resolver, you'd end up with a peculiar undefined symbol of type 
> ifunc in the EXE/DSO (same as the .o).

This is the ld.lld behavior. 
GNU ld appears to leave a STT_FUNC undefined symbol. The idea may be that when 
cross-DSO, STT_GNU_IFUNC loses meaning.

In this case using "undefined ifunc" in the first place is a user error.

---

GNU indirect functions are largely under-specified. glibc implemented it and 
FreeBSD adopted it.
Few years ago, glibc folks wrote https://sourceware.org/glibc/wiki/GNU_IFUNC to 
specify some behaviors they expected to work.
You can see

> Requirement (a): Resolver must be defined in the same translation unit as the 
> implementations.

An undefined STT_GNU_IFUNC violates this requirement.

The second requirement says

> Requirement (b): Cannot be weakly defined functions.

It mostly wants to warn you that STB_GLOBAL overriding STB_WEAK can have weird 
behaviors, so users should move away that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson updated this revision to Diff 384881.
CJ-Johnson marked an inline comment as done.
CJ-Johnson added a comment.

Fix spelling error


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-stringview-nullptr.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
@@ -0,0 +1,1030 @@
+// RUN: %check_clang_tidy %s bugprone-stringview-nullptr -std=c++17 %t
+
+namespace std {
+
+using nullptr_t = decltype(nullptr);
+
+template 
+T &&declval();
+
+template 
+struct type_identity { using type = T; };
+template 
+using type_identity_t = typename type_identity::type;
+
+template 
+class basic_string_view {
+public:
+  basic_string_view();
+  basic_string_view(const C *);
+  basic_string_view(const basic_string_view &);
+  basic_string_view &operator=(const basic_string_view &);
+};
+
+template 
+bool operator<(basic_string_view, basic_string_view);
+template 
+bool operator<(type_identity_t>, basic_string_view);
+template 
+bool operator<(basic_string_view, type_identity_t>);
+
+template 
+bool operator<=(basic_string_view, basic_string_view);
+template 
+bool operator<=(type_identity_t>, basic_string_view);
+template 
+bool operator<=(basic_string_view, type_identity_t>);
+
+template 
+bool operator>(basic_string_view, basic_string_view);
+template 
+bool operator>(type_identity_t>, basic_string_view);
+template 
+bool operator>(basic_string_view, type_identity_t>);
+
+template 
+bool operator>=(basic_string_view, basic_string_view);
+template 
+bool operator>=(type_identity_t>, basic_string_view);
+template 
+bool operator>=(basic_string_view, type_identity_t>);
+
+template 
+bool operator==(basic_string_view, basic_string_view);
+template 
+bool operator==(type_identity_t>, basic_string_view);
+template 
+bool operator==(basic_string_view, type_identity_t>);
+
+template 
+bool operator!=(basic_string_view, basic_string_view);
+template 
+bool operator!=(type_identity_t>, basic_string_view);
+template 
+bool operator!=(basic_string_view, type_identity_t>);
+
+using string_view = basic_string_view;
+
+} // namespace std
+
+void function(std::string_view);
+void function(std::string_view, std::string_view);
+
+void temporary_construction() /* a */ {
+  // Functional Cast
+  {
+(void)(std::string_view(nullptr)) /* a1 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a1 */;{{$}}
+
+(void)(std::string_view((nullptr))) /* a2 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a2 */;{{$}}
+
+(void)(std::string_view({nullptr})) /* a3 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a3 */;{{$}}
+
+(void)(std::string_view({(nullptr)})) /* a4 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a4 */;{{$}}
+
+// (void)(const std::string_view(nullptr)) /* a5 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view((nullptr))) /* a6 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({nullptr})) /* a7 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({(nullptr)})) /* a8 */;
+// CV qualifiers do not compile in this context
+  }
+
+  // Temporary Object
+  {
+(void)(std::string_view{nullptr}) /* a9 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view{}) /* a9 */;{{$}}
+
+(void)(std::string_view{(nullptr)}) /* a10 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+/

[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson marked an inline comment as done.
CJ-Johnson added a comment.

Thanks for the additional info, @aaron.ballman! I had not considered the issues 
with duplicate warnings. I agree that it would be annoying for users. That 
being the case, the second option ("remove the string_view nullptr checking 
functionality from bugprone-string-constructor so it only lives in the new 
check") sounds the most appealing to me, personally.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp:84
+
+(void)(std::string_view({nullptr})) /* a3 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing 
basic_string_view from null is undefined; replace with the default constructor

aaron.ballman wrote:
> This (and many others) also generates `-Wbraced-scalar-init`, is that 
> intentional?
My goal was just to be thorough in the cases tested. It's not an endorsement of 
the source patterns. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

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


[PATCH] D113210: [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Arthur Eubanks via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG13317286f829: [NewPM] Use the default AA pipeline by default 
(authored by aeubanks).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113210

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before 
calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   
\
   FAM.registerPass([&] { return CREATE_PASS; });
 #include "PassRegistry.def"
Index: llvm/lib/LTO/ThinLTOCodeGenerator.cpp
===
--- llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -291,11 +291,6 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA = PB.buildDefaultAAPipeline();
-
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
-
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -251,18 +251,16 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA;
   // Parse a custom AA pipeline if asked to.
   if (!Conf.AAPipeline.empty()) {
+AAManager AA;
 if (auto Err = PB.parseAAPipeline(AA, Conf.AAPipeline)) {
   report_fatal_error(Twine("unable to parse AA pipeline description '") +
  Conf.AAPipeline + "': " + toString(std::move(Err)));
 }
-  } else {
-AA = PB.buildDefaultAAPipeline();
+// Register the AA manager first so that our version is the one used.
+FAM.registerPass([&] { return std::move(AA); });
   }
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
 
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1312,9 +1312,6 @@
   get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
 #include "llvm/Support/Extension.def"
 
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
-
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline();

[clang] 1331728 - [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Arthur Eubanks via cfe-commits

Author: Arthur Eubanks
Date: 2021-11-04T15:10:34-07:00
New Revision: 13317286f8298eb3bafa9ddebd1c03bef4918948

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

LOG: [NewPM] Use the default AA pipeline by default

We almost always want to use the default AA pipeline. It's very easy for
users of PassBuilder to forget to customize the AAManager to use the
default AA pipeline (for example, the NewPM C API forgets to do this).

If somebody wants a custom AA pipeline, similar to what is being done
now with the default AA pipeline registration, they can

  FAM.registerPass([&] { return std::move(MyAA); });

before calling

  PB.registerFunctionAnalyses(FAM);

For example, LTOBackend.cpp and NewPMDriver.cpp do this.

Reviewed By: asbirlea

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/lib/LTO/LTOBackend.cpp
llvm/lib/LTO/ThinLTOCodeGenerator.cpp
llvm/lib/Passes/PassBuilder.cpp
llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index e7ed77bcb60f..2d467e8dea81 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1312,9 +1312,6 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
   get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
 #include "llvm/Support/Extension.def"
 
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
-
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());

diff  --git a/llvm/lib/LTO/LTOBackend.cpp b/llvm/lib/LTO/LTOBackend.cpp
index d0e3b45d2bc1..be06556b0c3b 100644
--- a/llvm/lib/LTO/LTOBackend.cpp
+++ b/llvm/lib/LTO/LTOBackend.cpp
@@ -251,18 +251,16 @@ static void runNewPMPasses(const Config &Conf, Module 
&Mod, TargetMachine *TM,
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA;
   // Parse a custom AA pipeline if asked to.
   if (!Conf.AAPipeline.empty()) {
+AAManager AA;
 if (auto Err = PB.parseAAPipeline(AA, Conf.AAPipeline)) {
   report_fatal_error(Twine("unable to parse AA pipeline description '") +
  Conf.AAPipeline + "': " + toString(std::move(Err)));
 }
-  } else {
-AA = PB.buildDefaultAAPipeline();
+// Register the AA manager first so that our version is the one used.
+FAM.registerPass([&] { return std::move(AA); });
   }
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
 
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);

diff  --git a/llvm/lib/LTO/ThinLTOCodeGenerator.cpp 
b/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
index b4c1836c678d..9474d8c9dafb 100644
--- a/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ b/llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -291,11 +291,6 @@ static void optimizeModuleNewPM(Module &TheModule, 
TargetMachine &TM,
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA = PB.buildDefaultAAPipeline();
-
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
-
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);

diff  --git a/llvm/lib/Passes/PassBuilder.cpp b/llvm/lib/Passes/PassBuilder.cpp
index baf150190026..74d96c732acd 100644
--- a/llvm/lib/Passes/PassBuilder.cpp
+++ b/llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@ void 
PassBuilder::registerCGSCCAnalyses(CGSCCAnalysisManager &CGAM) {
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a 
diff erent one, they can register their own before calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   
\
   FAM.registerPass([&] { return CREATE_PASS; });
 #include "PassRegistry.def"

diff  --git a/llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp 
b/llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
index 7cf7b1feb3b7..265c8ac47fb6 100644
--- a/llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ b/llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@ extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, 
size_t Size) {
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&

[PATCH] D112098: [ASan] Added stack safety support in address sanitizer.

2021-11-04 Thread Kirill Stoimenov via Phabricator via cfe-commits
kstoimenov updated this revision to Diff 384877.
kstoimenov marked 2 inline comments as done.
kstoimenov added a comment.

Fixed tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112098

Files:
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll

Index: llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/AddressSanitizer/asan-stack-safety.ll
@@ -0,0 +1,19 @@
+; REQUIRES: x86-registered-target
+
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=0  -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=0 -asan-instrumentation-with-call-threshold=0 -asan \
+; RUN: -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=0 -o - | FileCheck %s --check-prefixes=NOSAFETY
+; RUN: opt < %s -S -enable-new-pm=1 -asan-instrumentation-with-call-threshold=0 \
+; RUN: -passes='asan-pipeline' -asan-use-stack-safety=1 -o - | FileCheck %s --check-prefixes=SAFETY
+; NOSAFETY: call void @__asan_load1
+; SAFETY-NOT: call void @__asan_load1
+
+define i32 @stack-safety() sanitize_address {
+  %buf = alloca [10 x i8], align 1
+  %arrayidx = getelementptr inbounds [10 x i8], [10 x i8]* %buf, i64 0, i64 0
+  %1 = load i8, i8* %arrayidx, align 1
+  ret i32 0
+}
Index: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
@@ -26,6 +26,7 @@
 #include "llvm/ADT/Triple.h"
 #include "llvm/ADT/Twine.h"
 #include "llvm/Analysis/MemoryBuiltins.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/ValueTracking.h"
 #include "llvm/BinaryFormat/MachO.h"
@@ -47,6 +48,7 @@
 #include "llvm/IR/GlobalVariable.h"
 #include "llvm/IR/IRBuilder.h"
 #include "llvm/IR/InlineAsm.h"
+#include "llvm/IR/InstIterator.h"
 #include "llvm/IR/InstVisitor.h"
 #include "llvm/IR/InstrTypes.h"
 #include "llvm/IR/Instruction.h"
@@ -211,6 +213,11 @@
 "asan-instrument-writes", cl::desc("instrument write instructions"),
 cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("asan-use-stack-safety", cl::Hidden, cl::init(false),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClInstrumentAtomics(
 "asan-instrument-atomics",
 cl::desc("instrument atomic instructions (rmw, cmpxchg)"), cl::Hidden,
@@ -647,6 +654,7 @@
 /// AddressSanitizer: instrument the code in module to find memory bugs.
 struct AddressSanitizer {
   AddressSanitizer(Module &M, const GlobalsMetadata *GlobalsMD,
+   const StackSafetyGlobalInfo *SSGI,
bool CompileKernel = false, bool Recover = false,
bool UseAfterScope = false,
AsanDetectStackUseAfterReturnMode UseAfterReturn =
@@ -657,7 +665,7 @@
 UseAfterScope(UseAfterScope || ClUseAfterScope),
 UseAfterReturn(ClUseAfterReturn.getNumOccurrences() ? ClUseAfterReturn
 : UseAfterReturn),
-GlobalsMD(*GlobalsMD) {
+GlobalsMD(*GlobalsMD), SSGI(SSGI) {
 C = &(M.getContext());
 LongSize = M.getDataLayout().getPointerSizeInBits();
 IntptrTy = Type::getIntNTy(*C, LongSize);
@@ -686,7 +694,7 @@
   /// Check if we want (and can) handle this alloca.
   bool isInterestingAlloca(const AllocaInst &AI);
 
-  bool ignoreAccess(Value *Ptr);
+  bool ignoreAccess(Instruction *Inst, Value *Ptr);
   void getInterestingMemoryOperands(
   Instruction *I, SmallVectorImpl &Interesting);
 
@@ -771,6 +779,7 @@
   FunctionCallee AsanMemmove, AsanMemcpy, AsanMemset;
   Value *LocalDynamicShadow = nullptr;
   const GlobalsMetadata &GlobalsMD;
+  const StackSafetyGlobalInfo *SSGI;
   DenseMap ProcessedAllocas;
 
   FunctionCallee AMDGPUAddressShared;
@@ -797,16 +806,22 @@
 
   void getAnalysisUsage(AnalysisUsage &AU) const override {
 AU.addRequired();
+if (ClUseStackSafety)
+  AU.addRequired();
 AU.addRequired();
   }
 
   bool runOnFunction(Function &F) override {
 GlobalsMetadata &GlobalsMD =
 getAnalysis().getGlobalsMD();
+const StackSafetyGlobalInfo *const SSGI =
+ClUseStackSafety
+? &getAnalysis().getResult()
+: nullptr;
 const TargetLibraryInfo *TLI =
 &getAnalysis().getTLI(F);
-AddressSanitizer ASan(*F.getParen

[PATCH] D108479: [Clang] Add __builtin_addressof_nocfi

2021-11-04 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

`std::addressof(&someFunction)` certainly ought to return a signed pointer 
under ptrauth, so if your goal here is to get a completely unadorned symbol 
address, I think you do need a different builtin, and it probably ought to 
return a `void*` to emphasize that it shouldn't be used as a normal value.  
Maybe it should even be semantically restricted to require a constant decl 
reference as its operand?  Related and perhaps illuminating question: if it 
were implementable, would you also want to force the suppression of 
lazy-binding thunks and/or decorations like the THUMB bit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108479

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Itay Bookstein via Phabricator via cfe-commits
ibookstein added a comment.

I see. What is the guiding principle there, though? Generating correct IR "up 
front" / "the first time" rather than "fixing it up as you go via 
manipulations"? (could you give a link?)
I can see the engineering consideration in not letting IR manipulations creep 
into the CFE, I just want to make sure that's the principle that we're asked to 
follow.
In the end this isn't the first instance where the "streaming" design of 
GlobalDecl emission forces a fixup/rewrite of a previous decision, as can be 
evidenced by a close sibling of this feature, 
`CodeGenModule::EmitAliasDefinition` (which uses exactly that idiom, for a very 
similar use-case)...
It will always be either a fixup or an accumulate/commit idiom, since there 
will always be a GlobalDecl ordering where the information to make 'the perfect 
module-global decision' isn't available upon having to act on partial 
information.

In the end, I would like to have the verification of IFuncs having a defined 
resolver restored (and avoid more dependencies being taken on this being 
'allowed' at the IR level), since having LLVM emit an object file with an 
undefined STT_GNU_IFUNC is probably just trouble and confusion waiting to 
happen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D109496: [clang] deprecate frelaxed-template-template-args, make it on by default

2021-11-04 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 384873.
mizvekov edited the summary of this revision.
mizvekov added a comment.
This revision is now accepted and ready to land.

Implement workaround.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109496

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/SanitizerArgs.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/Driver/frelaxed-template-template-args.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/SemaTemplate/default-arguments.cpp
  clang/test/SemaTemplate/instantiate-template-template-parm.cpp
  clang/test/SemaTemplate/nested-template.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp
  clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -596,7 +596,7 @@
 You can use Clang in C++17 mode with the -std=c++17 option
 (use -std=c++1z in Clang 4 and earlier).
 
-
+
 List of features and minimum Clang version with support
 
 
@@ -813,8 +813,8 @@
 
 
   Matching template template parameters to compatible arguments
-  https://wg21.link/p0522r0";>P0522R0
-  Partial (10)
+  https://wg21.link/p0522r0";>P0522R0 (DR)
+  Clang 4 (10)
 
 
   Removing deprecated dynamic exception specifications
@@ -842,13 +842,10 @@
 reverse construction order in that ABI.
 This is not fully supported during constant expression evaluation until Clang 12.
 
-(10): Despite being the resolution to a Defect Report, this
-feature is disabled by default in all language versions, and can be enabled
-explicitly with the flag -frelaxed-template-template-args in Clang 4
-onwards.
-The change to the standard lacks a corresponding change for template partial
-ordering, resulting in ambiguity errors for reasonable and previously-valid
-code. This issue is expected to be rectified soon.
+(10): Prior to Clang 14, this feature is not enabled by
+default, but can be enabled with -frelaxed-template-template-args.
+Starting from Clang 14, the flag is deprecated and will be removed in a future
+version.
 
 
 
Index: clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
===
--- clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
+++ clang/test/SemaTemplate/temp_arg_template_cxx1z.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z -frelaxed-template-template-args %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++1z %s
 
 // expected-note@temp_arg_template_cxx1z.cpp:* 1+{{}}
 
Index: clang/test/SemaTemplate/temp_arg_template.cpp
===
--- clang/test/SemaTemplate/temp_arg_template.cpp
+++ clang/test/SemaTemplate/temp_arg_template.cpp
@@ -6,11 +6,11 @@
 
 template class X> struct B; // expected-note{{previous template template parameter is here}}
 
-template class X> struct C;  // expected-note 2{{previous non-type template parameter with type 'int' is here}}
+template class X> struct C;  // expected-note {{previous non-type template parameter with type 'int' is here}}
 
 template struct X; // expected-note{{too few template parameters in template template argument}}
 template struct Y; // expected-note{{template parameter has a different kind in template argument}}
-template struct Ylong; // expected-note{{template non-type parameter has a different type 'long' in template argument}}
+template struct Ylong;
 template struct Yref; // expected-note{{template non-type parameter has a different type 'const int &' in template argument}}
 
 namespace N {
@@ -27,7 +27,7 @@
 A *a5; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 B *a6; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 C *a7;
-C *a8; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
+C *a8;
 C *a9; // expected-error{{template template argument has different template parameters than its corresponding template template parameter}}
 
 template void f(int);
Index: clang/test/SemaTemplate/nested-template.cpp
===
--- clang/test/SemaTemplate/nested-template.cpp
+++ clang/test/SemaTemplate/nested-template.cpp
@@ -112,18 +112,16 @@
 // Template template

[PATCH] D113154: [OpenMP] Add parsing/sema/serialization for 'bind' clause

2021-11-04 Thread Mike Rice via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4eac7bcf1af1: [OpenMP] Add parsing/sema/serialization for 
'bind' clause. (authored by mikerice).
Herald added projects: clang, Flang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113154

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/OpenMPKinds.def
  clang/include/clang/Basic/OpenMPKinds.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/generic_loop_ast_print.cpp
  clang/test/OpenMP/generic_loop_messages.cpp
  clang/tools/libclang/CIndex.cpp
  flang/lib/Semantics/check-omp-structure.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -365,6 +365,10 @@
 }
 def OMPC_When: Clause<"when"> {}
 
+def OMPC_Bind : Clause<"bind"> {
+  let clangClass = "OMPBindClause";
+}
+
 //===--===//
 // Definition of OpenMP directives
 //===--===//
@@ -1739,6 +1743,7 @@
 VersionedClause,
   ];
   let allowedOnceClauses = [
+VersionedClause,
 VersionedClause,
 VersionedClause,
   ];
Index: flang/lib/Semantics/check-omp-structure.cpp
===
--- flang/lib/Semantics/check-omp-structure.cpp
+++ flang/lib/Semantics/check-omp-structure.cpp
@@ -1480,6 +1480,7 @@
 CHECK_SIMPLE_CLAUSE(AdjustArgs, OMPC_adjust_args)
 CHECK_SIMPLE_CLAUSE(AppendArgs, OMPC_append_args)
 CHECK_SIMPLE_CLAUSE(MemoryOrder, OMPC_memory_order)
+CHECK_SIMPLE_CLAUSE(Bind, OMPC_bind)
 
 CHECK_REQ_SCALAR_INT_CLAUSE(Grainsize, OMPC_grainsize)
 CHECK_REQ_SCALAR_INT_CLAUSE(NumTasks, OMPC_num_tasks)
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2581,6 +2581,8 @@
   for (const Expr *E : C->varlists())
 Visitor->AddStmt(E);
 }
+void OMPClauseEnqueue::VisitOMPBindClause(const OMPBindClause *C) {}
+
 } // namespace
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: clang/test/OpenMP/generic_loop_messages.cpp
===
--- clang/test/OpenMP/generic_loop_messages.cpp
+++ clang/test/OpenMP/generic_loop_messages.cpp
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=51 -Wuninitialized %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -verify -fopenmp \
+// RUN:  -fopenmp-version=51 -Wuninitialized %s
 
 void foo()
 {
@@ -6,7 +7,7 @@
   int z;
 
   // expected-error@+2 {{statement after '#pragma omp loop' must be a for loop}}
-  #pragma omp loop
+  #pragma omp loop bind(thread)
   i = 0;
 
   // OpenMP 5.1 [2.22 Nesting of regions]
@@ -15,7 +16,7 @@
   // task, taskloop, critical, ordered, atomic, or masked region.
 
   // expected-error@+3 {{region cannot be closely nested inside 'loop' region}}
-  #pragma omp loop
+  #pragma omp loop bind(thread)
   for (i=0; i<1000; ++i) {
 #pragma omp barrier
   }
@@ -24,7 +25,7 @@
   // atomic, task, or taskloop region.
 
   // expected-error@+3 {{region cannot be closely nested inside 'loop' region}}
-  #pragma omp loop
+  #pragma omp loop bind(thread)
   for (i=0; i<1000; ++i) {
 #pragma omp masked filter(2)
 { }
@@ -35,37 +36,56 @@
   // inside a critical, ordered, loop, atomic, task, or taskloop region.
 
   // expected-error@+3 {{region cannot be closely nested inside 'loop' region; perhaps you forget to enclose 'omp ordered' directive into a for or a parallel for region with 'ordered' clause?}}
-  #pragma omp loop
+  #pragma omp loop bind(thread)
   for (i=0; i<1000; ++i) {
 #pragma omp ordered
 { }
   }
 
   // expected-error@+3 {{region cannot be closely nested inside 'loop' region; perhaps you forget to enclose 'omp ordered' directive into a for or a parallel for region with 'ordered' clause?}}
-  #pragma omp loop
+  #pragma omp loop bind(thread)
   for (i=0; i<1000; ++i) {
 #pragma omp ordered threads
 { }
   }
 
   // expected-error@+3 {{region cannot be closely nested inside 'loop' region; perhaps you forget to enclose 'omp ordered' directive into a for or a parallel for region with 'ordered' claus

[clang] 4eac7bc - [OpenMP] Add parsing/sema/serialization for 'bind' clause.

2021-11-04 Thread Mike Rice via cfe-commits

Author: Mike Rice
Date: 2021-11-04T14:40:30-07:00
New Revision: 4eac7bcf1af1a94d76aec8d54f4a0f0014dd121c

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

LOG: [OpenMP] Add parsing/sema/serialization for 'bind' clause.

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

Added: 


Modified: 
clang/include/clang/AST/OpenMPClause.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Basic/OpenMPKinds.def
clang/include/clang/Basic/OpenMPKinds.h
clang/include/clang/Sema/Sema.h
clang/lib/AST/OpenMPClause.cpp
clang/lib/AST/StmtProfile.cpp
clang/lib/Basic/OpenMPKinds.cpp
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/test/OpenMP/generic_loop_ast_print.cpp
clang/test/OpenMP/generic_loop_messages.cpp
clang/tools/libclang/CIndex.cpp
flang/lib/Semantics/check-omp-structure.cpp
llvm/include/llvm/Frontend/OpenMP/OMP.td

Removed: 




diff  --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 749eff57313a..99554641a64b 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -8405,6 +8405,96 @@ class OMPFilterClause final : public OMPClause, public 
OMPClauseWithPreInit {
   }
 };
 
+/// This represents 'bind' clause in the '#pragma omp ...' directives.
+///
+/// \code
+/// #pragma omp loop bind(parallel)
+/// \endcode
+class OMPBindClause final : public OMPClause {
+  friend class OMPClauseReader;
+
+  /// Location of '('.
+  SourceLocation LParenLoc;
+
+  /// The binding kind of 'bind' clause.
+  OpenMPBindClauseKind Kind = OMPC_BIND_unknown;
+
+  /// Start location of the kind in source code.
+  SourceLocation KindLoc;
+
+  /// Sets the location of '('.
+  void setLParenLoc(SourceLocation Loc) { LParenLoc = Loc; }
+
+  /// Set the binding kind.
+  void setBindKind(OpenMPBindClauseKind K) { Kind = K; }
+
+  /// Set the binding kind location.
+  void setBindKindLoc(SourceLocation KLoc) { KindLoc = KLoc; }
+
+  /// Build 'bind' clause with kind \a K ('teams', 'parallel', or 'thread').
+  ///
+  /// \param K Binding kind of the clause ('teams', 'parallel' or 'thread').
+  /// \param KLoc Starting location of the binding kind.
+  /// \param StartLoc Starting location of the clause.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLoc Ending location of the clause.
+  OMPBindClause(OpenMPBindClauseKind K, SourceLocation KLoc,
+SourceLocation StartLoc, SourceLocation LParenLoc,
+SourceLocation EndLoc)
+  : OMPClause(llvm::omp::OMPC_bind, StartLoc, EndLoc), 
LParenLoc(LParenLoc),
+Kind(K), KindLoc(KLoc) {}
+
+  /// Build an empty clause.
+  OMPBindClause()
+  : OMPClause(llvm::omp::OMPC_bind, SourceLocation(), SourceLocation()) {}
+
+public:
+  /// Build 'bind' clause with kind \a K ('teams', 'parallel', or 'thread').
+  ///
+  /// \param C AST context
+  /// \param K Binding kind of the clause ('teams', 'parallel' or 'thread').
+  /// \param KLoc Starting location of the binding kind.
+  /// \param StartLoc Starting location of the clause.
+  /// \param LParenLoc Location of '('.
+  /// \param EndLoc Ending location of the clause.
+  static OMPBindClause *Create(const ASTContext &C, OpenMPBindClauseKind K,
+   SourceLocation KLoc, SourceLocation StartLoc,
+   SourceLocation LParenLoc, SourceLocation 
EndLoc);
+
+  /// Build an empty 'bind' clause.
+  ///
+  /// \param C AST context
+  static OMPBindClause *CreateEmpty(const ASTContext &C);
+
+  /// Returns the location of '('.
+  SourceLocation getLParenLoc() const { return LParenLoc; }
+
+  /// Returns kind of the clause.
+  OpenMPBindClauseKind getBindKind() const { return Kind; }
+
+  /// Returns location of clause kind.
+  SourceLocation getBindKindLoc() const { return KindLoc; }
+
+  child_range children() {
+return child_range(child_iterator(), child_iterator());
+  }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  child_range used_children() {
+return child_range(child_iterator(), child_iterator());
+  }
+  const_child_range used_children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  static bool classof(const OMPClause *T) {
+return T->getClauseKind() == llvm::omp::OMPC_bind;
+  }
+};
+
 /// This class implements a simple visitor for OMPClause
 /// subclasses.
 template class Ptr, typename RetTy>

diff  --git a/clang/include/clang/AST/RecursiveASTVis

[clang] 737e421 - [Attr] support btf_type_tag attribute

2021-11-04 Thread Yonghong Song via cfe-commits

Author: Yonghong Song
Date: 2021-11-04T14:23:31-07:00
New Revision: 737e4216c537c33aab8ec51880f06b8a54325b94

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

LOG: [Attr] support btf_type_tag attribute

This patch added clang codegen and llvm support
for btf_type_tag support. Currently, btf_type_tag
attribute info is preserved in DebugInfo IR only for
pointer types associated with typedef, global variable
and function declaration. Eventually, such information
is emitted to dwarf.

The following is an example:
  $ cat test.c
  #define __tag __attribute__((btf_type_tag("tag")))
  int __tag *g;
  $ clang -O2 -g -c test.c
  $ llvm-dwarfdump --debug-info test.o
  ...
  0x001e:   DW_TAG_variable
  DW_AT_name  ("g")
  DW_AT_type  (0x0033 "int *")
  DW_AT_external  (true)
  DW_AT_decl_file ("/home/yhs/test.c")
  DW_AT_decl_line (2)
  DW_AT_location  (DW_OP_addr 0x0)

  0x0033:   DW_TAG_pointer_type
  DW_AT_type  (0x0042 "int")

  0x0038: DW_TAG_LLVM_annotation
DW_AT_name("btf_type_tag")
DW_AT_const_value ("tag")

  0x0041: NULL

  0x0042:   DW_TAG_base_type
  DW_AT_name  ("int")
  DW_AT_encoding  (DW_ATE_signed)
  DW_AT_byte_size (0x04)

  0x0049:   NULL

Basically, a DW_TAG_LLVM_annotation tag will be inserted
under DW_TAG_pointer_type tag if that pointer has a btf_type_tag
associated with it.

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

Added: 
clang/test/CodeGen/attr-btf_type_tag-func.c
clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
clang/test/CodeGen/attr-btf_type_tag-var.c
llvm/test/Bitcode/attr-btf_type_tag.ll
llvm/test/DebugInfo/attr-btf_type_tag.ll

Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CGDebugInfo.h
llvm/include/llvm/IR/DIBuilder.h
llvm/lib/IR/DIBuilder.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 64dd70f837f7..9813c01beef3 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -929,8 +929,28 @@ static llvm::dwarf::Tag getNextQualifier(Qualifiers &Q) {
   return (llvm::dwarf::Tag)0;
 }
 
-llvm::DIType *CGDebugInfo::CreateQualifiedType(QualType Ty,
-   llvm::DIFile *Unit) {
+// Strip MacroQualifiedTypeLoc and AttributedTypeLoc
+// as their corresponding types will be ignored
+// during code generation. Stripping them allows
+// to maintain proper TypeLoc for a given type
+// during code generation.
+static TypeLoc StripMacroAttributed(TypeLoc TL) {
+  if (!TL)
+return TL;
+
+  while (true) {
+if (auto MTL = TL.getAs())
+  TL = MTL.getInnerLoc();
+else if (auto ATL = TL.getAs())
+  TL = ATL.getModifiedLoc();
+else
+  break;
+  }
+  return TL;
+}
+
+llvm::DIType *CGDebugInfo::CreateQualifiedType(QualType Ty, llvm::DIFile *Unit,
+   TypeLoc TL) {
   QualifierCollector Qc;
   const Type *T = Qc.strip(Ty);
 
@@ -944,7 +964,15 @@ llvm::DIType *CGDebugInfo::CreateQualifiedType(QualType Ty,
 return getOrCreateType(QualType(T, 0), Unit);
   }
 
-  auto *FromTy = getOrCreateType(Qc.apply(CGM.getContext(), T), Unit);
+  QualType NextTy = Qc.apply(CGM.getContext(), T);
+  TypeLoc NextTL;
+  if (NextTy.hasQualifiers())
+NextTL = TL;
+  else if (TL) {
+if (auto QTL = TL.getAs())
+  NextTL = StripMacroAttributed(QTL.getNextTypeLoc());
+  }
+  auto *FromTy = getOrCreateType(NextTy, Unit, NextTL);
 
   // No need to fill in the Name, Line, Size, Alignment, Offset in case of
   // CVR derived types.
@@ -988,10 +1016,10 @@ llvm::DIType *CGDebugInfo::CreateType(const 
ObjCObjectPointerType *Ty,
Ty->getPointeeType(), Unit);
 }
 
-llvm::DIType *CGDebugInfo::CreateType(const PointerType *Ty,
-  llvm::DIFile *Unit) {
+llvm::DIType *CGDebugInfo::CreateType(const PointerType *Ty, llvm::DIFile 
*Unit,
+  TypeLoc TL) {
   return CreatePointerLikeType(llvm::dwarf::DW_TAG_pointer_type, Ty,
-   Ty->getPointeeType(), Unit);
+   Ty->getPointeeType(), Unit, TL);
 }
 
 /// \return whether a C++ mangling exists for the type defined by TD.
@@ -1132,7 +1160,8 @@ CGDebugInfo::getOrCreateRecordFwdDecl(const RecordType 
*Ty,
 llvm::DIType *CGDebugInfo::CreatePointerLikeType(llvm::dwarf::Tag Tag,
  const Type *Ty,

[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D113148#3109190 , @CJ-Johnson 
wrote:

> As for "we should be careful we're not too onerous when users enable all 
> `bugprone` checks together.", these fixes are about preventing UB. While I 
> did put this in the "bugprone" module, perhaps "prone" is the wrong way to 
> think about it. It's unconditionally UB in all cases, not just a potential 
> bug. The suggested fixes are important for preventing crashes in the short 
> term, but more importantly for allowing the code to build in the future, 
> since the constructor overload `basic_string_view(nullptr_t) = delete;` is 
> being added.

The concern I have is that a user passes `-checks=-*, bugprone-*` and gets two 
diagnostics on the same line for the same issue. There is precedence, but 
usually clang-tidy only gets in this situation when the user enables checks 
from different modules (I don't know of any case where it happens within the 
same module). Your existing test cases have significant coverage already: 
https://godbolt.org/z/49nGYEGzq so this isn't a theoretical concern -- anyone 
checking against all bugprone (which is pretty typical) will get duplicate 
diagnostics. So we're in a bit of a novel situation with this patch, and I'm 
not certain what the correct answer is. I see a few paths:

- accept that there are two diagnostics for the same code construct
- remove the string_view nullptr checking functionality from 
bugprone-string-constructor so it only lives in the new check
- remove the constructor checking functionality from the new check so it only 
lives in bugprone-string-constructor
- have both of the checks look to see whether the other check is enabled before 
issuing the diagnostic and pick one of them to be the "winner" so there's only 
one diagnostic

There's pros and cons to all of these approaches (and maybe there are other 
approaches to consider as well). I sort of lean towards the last option, but 
that could be confusing for people trying to suppress diagnostics. e.g., they 
could write `NOLINT(bugprone-string-constructor)` to silence the diagnostic and 
then they get a different diagnostic they also have to silence. However, I also 
sort of think that confusion is not likely to happen in practice because 1) 
users are more likely to fix their code than silence *this* warning, 2) users 
are more likely to write `NOLINT` without a specific check, so all tidy 
diagnostics would be suppressed. But it's still a bit of concern as a precedent.

@alexfh -- as code owner, do you have thoughts here?




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp:84
+
+(void)(std::string_view({nullptr})) /* a3 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing 
basic_string_view from null is undefined; replace with the default constructor

This (and many others) also generates `-Wbraced-scalar-init`, is that 
intentional?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

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


[PATCH] D112285: [PowerPC] PPC backend optimization to lower int_ppc_tdw/int_ppc_tw intrinsics to TDI/TWI machine instructions

2021-11-04 Thread Victor Huang via Phabricator via cfe-commits
NeHuang updated this revision to Diff 384768.
NeHuang marked 3 inline comments as done.
NeHuang added a comment.

Address review comments from @nemanjai


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112285

Files:
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCInstr64Bit.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-trap-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-trap.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-trap.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-trap.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-trap.ll
@@ -127,6 +127,213 @@
   ret void
 }
 
+; tw -> twi
+define dso_local void @test__twi_boundary_reg_imm(i32 %a) {
+; CHECK-LABEL: test__twi_boundary_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twi 3, r3, 32767
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 32767, i32 3)
+  ret void
+}
+
+define dso_local void @test__twi_boundary_imm_reg(i32 %a) {
+; CHECK-LABEL: test__twi_boundary_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twi 3, r3, 32767
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 32767, i32 %a, i32 3)
+  ret void
+}
+
+define dso_local void @test__twi_boundary1_reg_imm(i32 %a) {
+; CHECK-LABEL: test__twi_boundary1_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twi 3, r3, -32768
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 -32768, i32 3)
+  ret void
+}
+
+define dso_local void @test__twi_boundary1_imm_reg(i32 %a) {
+; CHECK-LABEL: test__twi_boundary1_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twi 3, r3, -32768
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 -32768, i32 %a, i32 3)
+  ret void
+}
+
+define dso_local void @test__tw_boundary2_reg_imm(i32 %a) {
+; CHECK-LABEL: test__tw_boundary2_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:lis r4, 0
+; CHECK-NEXT:ori r4, r4, 32768
+; CHECK-NEXT:tw 3, r3, r4
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 32768, i32 3)
+  ret void
+}
+
+define dso_local void @test__tw_boundary2_imm_reg(i32 %a) {
+; CHECK-LABEL: test__tw_boundary2_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:lis r4, 0
+; CHECK-NEXT:ori r4, r4, 32768
+; CHECK-NEXT:tw 3, r4, r3
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 32768, i32 %a, i32 3)
+  ret void
+}
+
+define dso_local void @test__tw_boundary3_reg_imm(i32 %a) {
+; CHECK-LABEL: test__tw_boundary3_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:lis r4, -1
+; CHECK-NEXT:ori r4, r4, 32767
+; CHECK-NEXT:tw 3, r3, r4
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 -32769, i32 3)
+  ret void
+}
+
+define dso_local void @test__tw_boundary3_imm_reg(i32 %a) {
+; CHECK-LABEL: test__tw_boundary3_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:lis r4, -1
+; CHECK-NEXT:ori r4, r4, 32767
+; CHECK-NEXT:tw 3, r4, r3
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 -32769, i32 %a, i32 3)
+  ret void
+}
+
+define dso_local void @test__twlgti_reg_imm(i32 %a) {
+; CHECK-LABEL: test__twlgti_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twlgti r3, 0
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 0, i32 1)
+  ret void
+}
+
+define dso_local void @test__twllti_imm_reg(i32 %a) {
+; CHECK-LABEL: test__twllti_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twllti r3, 0
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 0, i32 %a, i32 1)
+  ret void
+}
+
+define dso_local void @test__twllti_reg_imm(i32 %a) {
+; CHECK-LABEL: test__twllti_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twllti r3, 1
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 1, i32 2)
+  ret void
+}
+
+define dso_local void @test__twlgti_imm_reg(i32 %a) {
+; CHECK-LABEL: test__twlgti_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twlgti r3, 1
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 1, i32 %a, i32 2)
+  ret void
+}
+
+define dso_local void @test__tweqi_reg_imm(i32 %a) {
+; CHECK-LABEL: test__tweqi_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:tweqi r3, 2
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 2, i32 4)
+  ret void
+}
+
+define dso_local void @test__tweqi_imm_reg(i32 %a) {
+; CHECK-LABEL: test__tweqi_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:tweqi r3, 2
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 2, i32 %a, i32 4)
+  ret void
+}
+
+define dso_local void @test__twgti_reg_imm(i32 %a) {
+; CHECK-LABEL: test__twgti_reg_imm:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twgti r3, 16
+; CHECK-NEXT:blr
+  call void @llvm.ppc.tw(i32 %a, i32 16, i32 8)
+  ret void
+}
+
+define dso_local void @test__twlti_imm_reg(i32 %a) {
+; CHECK-LABEL: test__twlti_imm_reg:
+; CHECK:   # %bb.0:
+; CHECK-NEXT:twlti r3, 16
+; CHECK-NEXT:blr
+  call void @llvm.pp

Re: [PATCH] D65019: [ARM] push LR before __gnu_mcount_nc

2021-11-04 Thread Angela Webb via cfe-commits

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


[PATCH] D113186: [NFC] Inclusive language: Remove instances of master in URLs

2021-11-04 Thread Quinn Pham via Phabricator via cfe-commits
quinnp created this revision.
Herald added subscribers: wenzhicui, wrengr, Chia-hungDuan, dcaballe, cota, 
teijeong, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, 
Joonsoo, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, antiagainst, 
shauheen, rriddle, mehdi_amini, usaxena95, kadircet, arphaman, hiraditya, 
jgravelle-google, arichardson, sbc100, mgorny, dschuff.
Herald added a reviewer: MaskRay.
Herald added a reviewer: ftynse.
quinnp requested review of this revision.
Herald added subscribers: cfe-commits, llvm-commits, libcxx-commits, 
lldb-commits, stephenneuendorffer, nicolasvasilache, aheejin.
Herald added projects: clang, LLDB, libc++, MLIR, LLVM, clang-tools-extra.
Herald added a reviewer: libc++.

[NFC] This patch fixes URLs containing "master". Old URLs were either broken or
redirecting to the new URL.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113186

Files:
  clang-tools-extra/clangd/Protocol.h
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/LibFormat.rst
  clang/docs/UsersManual.rst
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/TokenAnnotator.cpp
  clang/test/OpenMP/aarch64_vfabi_NarrowestDataSize.c
  clang/test/OpenMP/aarch64_vfabi_WidestDataSize.c
  clang/www/related.html
  libcxx/utils/ci/Dockerfile
  lld/docs/WebAssembly.rst
  lld/wasm/Driver.cpp
  lld/wasm/SyntheticSections.h
  lldb/unittests/Process/minidump/Inputs/linux-x86_64.cpp
  llvm/CMakeLists.txt
  llvm/docs/CompileCudaWithLLVM.rst
  llvm/docs/Proposals/TestSuite.rst
  llvm/include/llvm/BinaryFormat/Wasm.h
  llvm/include/llvm/Object/Wasm.h
  llvm/lib/MC/WasmObjectWriter.cpp
  llvm/lib/Object/WasmObjectFile.cpp
  llvm/lib/Target/WebAssembly/README.txt
  llvm/tools/vfabi-demangle-fuzzer/vfabi-demangler-fuzzer.cpp
  llvm/utils/gn/README.rst
  mlir/docs/Dialects/SPIR-V.md
  mlir/docs/LangRef.md
  mlir/docs/Rationale/Rationale.md
  mlir/docs/Rationale/RationaleGenericDAGRewriter.md
  mlir/include/mlir/Dialect/LLVMIR/ROCDLDialect.h
  mlir/lib/Tools/mlir-lsp-server/lsp/Protocol.h
  utils/bazel/.bazelrc
  utils/bazel/README.md

Index: utils/bazel/README.md
===
--- utils/bazel/README.md
+++ utils/bazel/README.md
@@ -28,7 +28,7 @@
you don't have a checkout yet.
 2. Install Bazel at the version indicated by [.bazelversion](./.bazelversion),
following the official instructions, if you don't have it installed yet:
-   https://docs.bazel.build/versions/master/install.html.
+   https://docs.bazel.build/versions/main/install.html.
 3. `cd utils/bazel`
 4. `bazel build --config=generic_clang @llvm-project//...` (if building on Unix
with Clang). `--config=generic_gcc` and `--config=msvc` are also available.
@@ -45,7 +45,7 @@
 ```
 
 You can enable
-[disk caching](https://docs.bazel.build/versions/master/remote-caching.html#disk-cache),
+[disk caching](https://docs.bazel.build/versions/main/remote-caching.html#disk-cache),
 which will cache build results
 
 ```.bazelrc
@@ -53,7 +53,7 @@
 ```
 
 You can instruct Bazel to use a ramdisk for its sandboxing operations via
-[--sandbox_base](https://docs.bazel.build/versions/master/command-line-reference.html#flag--sandbox_base),
+[--sandbox_base](https://docs.bazel.build/versions/main/command-line-reference.html#flag--sandbox_base),
 which can help avoid IO bottlenecks for the symlink stragegy used for
 sandboxing. This is especially important with many inputs and many cores (see
 https://github.com/bazelbuild/bazel/issues/11868):
Index: utils/bazel/.bazelrc
===
--- utils/bazel/.bazelrc
+++ utils/bazel/.bazelrc
@@ -158,7 +158,7 @@
 # Platform flags:
 # The toolchain container used for execution is defined in the target indicated
 # by "extra_execution_platforms", "host_platform" and "platforms".
-# More about platforms: https://docs.bazel.build/versions/master/platforms.html
+# More about platforms: https://docs.bazel.build/versions/main/platforms.html
 build:rbe --extra_toolchains=@rbe_default//config:cc-toolchain
 build:rbe --extra_execution_platforms=@rbe_default//config:platform
 build:rbe --host_platform=@rbe_default//config:platform
Index: mlir/lib/Tools/mlir-lsp-server/lsp/Protocol.h
===
--- mlir/lib/Tools/mlir-lsp-server/lsp/Protocol.h
+++ mlir/lib/Tools/mlir-lsp-server/lsp/Protocol.h
@@ -7,7 +7,7 @@
 //===--===//
 //
 // This file contains structs based on the LSP specification at
-// https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md
+// https://github.com/Microsoft/language-server-protocol/blob/main/protocol.md
 //
 // This is not meant to be a complete implementation, new interfaces are added
 // when they're needed.
Index: mlir/include/mlir/Dialect/LLVMIR/ROCDLDialect.h
==

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

2021-11-04 Thread Yonghong Song via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGeb0fa8bfa356: [Clang][Attr] Support btf_type_tag attribute 
(authored by yonghong-song).

Changed prior to commit:
  https://reviews.llvm.org/D99?vs=384843&id=384862#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Sema/attr-btf_type_tag.c

Index: clang/test/Sema/attr-btf_type_tag.c
===
--- /dev/null
+++ clang/test/Sema/attr-btf_type_tag.c
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -x c -triple x86_64-pc-linux-gnu -dwarf-version=4 -fsyntax-only -verify %s
+
+#define __tag1 __attribute__((btf_type_tag("tag1")))
+#define __tag2 __attribute__((btf_type_tag("tag2")))
+#define __tag3 __attribute__((btf_type_tag("tag3")))
+#define __tag4 __attribute__((btf_type_tag("tag4")))
+#define __tag5 __attribute__((btf_type_tag("tag5")))
+#define __tag6 __attribute__((btf_type_tag("tag6")))
+
+int __attribute__((btf_type_tag("tag1", "tag2"))) *invalid1; // expected-error {{'btf_type_tag' attribute takes one argument}}
+int __attribute__((btf_type_tag(2))) *invalid2; // expected-error {{'btf_type_tag' attribute requires a string}}
+
+int * __tag1 __tag2 * __tag3 __tag4 * __tag5 __tag6 *g;
+
+typedef void __fn_t(int);
+typedef __fn_t __tag1 __tag2 * __tag3 __tag4 *__fn2_t;
+struct t {
+  int __tag1 * __tag2 * __tag3 *a;
+  int __tag1 __tag2 __tag3 *b;
+  __fn2_t c;
+  long d;
+};
+int __tag4 * __tag5 * __tag6 *foo1(struct t __tag1 * __tag2 * __tag3 *a1) {
+  return (int __tag4 * __tag5 * __tag6 *)a1[0][0]->d;
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5900,6 +5900,9 @@
 void VisitQualifiedTypeLoc(QualifiedTypeLoc TL) {
   Visit(TL.getUnqualifiedLoc());
 }
+// Allow to fill pointee's type locations, e.g.,
+//   int __attr * __attr * __attr *p;
+void VisitPointerTypeLoc(PointerTypeLoc TL) { Visit(TL.getNextTypeLoc()); }
 void VisitTypedefTypeLoc(TypedefTypeLoc TL) {
   TL.setNameLoc(DS.getTypeSpecTypeLoc());
 }
@@ -6500,6 +6503,34 @@
   return BuildAddressSpaceAttr(T, ASIdx, AddrSpace, AttrLoc);
 }
 
+static void HandleBTFTypeTagAttribute(QualType &Type, const ParsedAttr &Attr,
+  TypeProcessingState &State) {
+  Sema &S = State.getSema();
+
+  // Check the number of attribute arguments.
+  if (Attr.getNumArgs() != 1) {
+S.Diag(Attr.getLoc(), diag::err_attribute_wrong_number_arguments)
+<< Attr << 1;
+Attr.setInvalid();
+return;
+  }
+
+  // Ensure the argument is a string.
+  auto *StrLiteral = dyn_cast(Attr.getArgAsExpr(0));
+  if (!StrLiteral) {
+S.Diag(Attr.getLoc(), diag::err_attribute_argument_type)
+<< Attr << AANT_ArgumentString;
+Attr.setInvalid();
+return;
+  }
+
+  ASTContext &Ctx = S.Context;
+  StringRef BTFTypeTag = StrLiteral->getString();
+  Type = State.getAttributedType(
+  ::new (Ctx) BTFTypeTagAttr(Ctx, Attr, BTFTypeTag), Type, Type);
+  return;
+}
+
 /// HandleAddressSpaceTypeAttribute - Process an address_space attribute on the
 /// specified type.  The attribute contains 1 argument, the id of the address
 /// space for the type.
@@ -8129,6 +8160,11 @@
 case ParsedAttr::IgnoredAttribute:
   break;
 
+case ParsedAttr::AT_BTFTypeTag:
+  HandleBTFTypeTagAttribute(type, attr, state);
+  attr.setUsedAsTypeAttr();
+  break;
+
 case ParsedAttr::AT_MayAlias:
   // FIXME: This attribute needs to actually be handled, but if we ignore
   // it it breaks large amounts of Linux software.
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -1746,6 +1746,9 @@
   case attr::ArmMveStrictPolymorphism:
 OS << "__clang_arm_mve_strict_polymorphism";
 break;
+  case attr::BTFTypeTag:
+OS << "btf_type_tag";
+break;
   }
   OS << "))";
 }
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -2023,6 +2023,23 @@
   }];
 }
 
+def BTFTypeTagDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+Clang supports the ``__attribute__((btf_type_tag("ARGUMENT")))`` attribute for
+all targets. It only has effect when ``-g`` is specified on the command line and
+is currently silently ignored when not applied to a pointer type (note: this
+scenario may be diagnosed in the future).
+
+The ``ARGUMENT`` string 

[clang] eb0fa8b - [Clang][Attr] Support btf_type_tag attribute

2021-11-04 Thread Yonghong Song via cfe-commits

Author: Yonghong Song
Date: 2021-11-04T13:59:18-07:00
New Revision: eb0fa8bfa356d49198f98b878b004bce59232bb0

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

LOG: [Clang][Attr] Support btf_type_tag attribute

This patch introduced btf_type_tag attribute. The attribute
is a type attribute and intends to address the below
linux use cases.
typedef int __user *__intp;
int foo(int __user *arg, ...)
static int do_execve(struct filename *filename,
const char __user *const __user *__argv,
const char __user *const __user *__envp)

Here __user in the kernel defined as
__attribute__((noderef, address_space(__user)))
for sparse ([1]) type checking mode.

For normal clang compilation, we intend to replace it with
__attribute__((btf_type_tag("user")))
and record such informaiton in dwarf and BTF so such
information later can be used in kernel for bpf verification
or for other tracing functionalities.

  [1] https://www.kernel.org/doc/html/v4.11/dev-tools/sparse.html

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

Added: 
clang/test/Sema/attr-btf_type_tag.c

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/lib/AST/TypePrinter.cpp
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 31ca7d21b902..a5443c967bf6 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -1845,6 +1845,13 @@ def BTFDeclTag : InheritableAttr {
   let LangOpts = [COnly];
 }
 
+def BTFTypeTag : TypeAttr {
+  let Spellings = [Clang<"btf_type_tag">];
+  let Args = [StringArgument<"BTFTypeTag">];
+  let Documentation = [BTFTypeTagDocs];
+  let LangOpts = [COnly];
+}
+
 def WebAssemblyExportName : InheritableAttr,
 TargetSpecificAttr {
   let Spellings = [Clang<"export_name">];

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 09477d6c4423..e7afb3699eb1 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -2023,6 +2023,23 @@ section too.
   }];
 }
 
+def BTFTypeTagDocs : Documentation {
+  let Category = DocCatType;
+  let Content = [{
+Clang supports the ``__attribute__((btf_type_tag("ARGUMENT")))`` attribute for
+all targets. It only has effect when ``-g`` is specified on the command line 
and
+is currently silently ignored when not applied to a pointer type (note: this
+scenario may be diagnosed in the future).
+
+The ``ARGUMENT`` string will be preserved in IR and emitted to DWARF for the
+types used in variable declarations, function declarations, or typedef
+declarations.
+
+For BPF targets, the ``ARGUMENT`` string will also be emitted to .BTF ELF
+section.
+  }];
+}
+
 def MipsInterruptDocs : Documentation {
   let Category = DocCatFunction;
   let Heading = "interrupt (MIPS)";

diff  --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index 40127f18ce46..eca9af3e5f36 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -1746,6 +1746,9 @@ void TypePrinter::printAttributedAfter(const 
AttributedType *T,
   case attr::ArmMveStrictPolymorphism:
 OS << "__clang_arm_mve_strict_polymorphism";
 break;
+  case attr::BTFTypeTag:
+OS << "btf_type_tag";
+break;
   }
   OS << "))";
 }

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index 5918876c02bf..3512165ffdbf 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -5900,6 +5900,9 @@ namespace {
 void VisitQualifiedTypeLoc(QualifiedTypeLoc TL) {
   Visit(TL.getUnqualifiedLoc());
 }
+// Allow to fill pointee's type locations, e.g.,
+//   int __attr * __attr * __attr *p;
+void VisitPointerTypeLoc(PointerTypeLoc TL) { Visit(TL.getNextTypeLoc()); }
 void VisitTypedefTypeLoc(TypedefTypeLoc TL) {
   TL.setNameLoc(DS.getTypeSpecTypeLoc());
 }
@@ -6500,6 +6503,34 @@ QualType Sema::BuildAddressSpaceAttr(QualType &T, Expr 
*AddrSpace,
   return BuildAddressSpaceAttr(T, ASIdx, AddrSpace, AttrLoc);
 }
 
+static void HandleBTFTypeTagAttribute(QualType &Type, const ParsedAttr &Attr,
+  TypeProcessingState &State) {
+  Sema &S = State.getSema();
+
+  // Check the number of attribute arguments.
+  if (Attr.getNumArgs() != 1) {
+S.Diag(Attr.getLoc(), diag::err_attribute_wrong_number_arguments)
+<< Attr << 1;
+Attr.setInvalid();
+return;
+  }
+
+  // Ensure the argument is a string.
+  auto *StrLiteral = dyn_cast(Attr.getArgAsExpr(0));
+  if (!StrLiteral) {
+S.Diag(Attr.getLoc(), diag::err_attribute_argument_type)
+<< Attr << AANT_ArgumentString;
+A

[PATCH] D108479: [Clang] Add __builtin_addressof_nocfi

2021-11-04 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc requested changes to this revision.
pcc added subscribers: rjmccall, rsmith.
pcc added a comment.
This revision now requires changes to proceed.

In D108479#3108360 , @ardb wrote:

> I would argue that the existing __builtin_addressof() should absorb this 
> behavior, rather than adding a special builtin related to CFI.
>
> As is documented for __builtin_addressof(), its intended use is in cases 
> where the & operator may return something other than the address of the 
> object, which is exactly the case we are dealing with here.

Maybe. It does imply two slightly orthogonal use cases for 
`__builtin_addressof`, one for implementing std::addressof and the other for 
the no-CFI use case. One question is then whether these two use cases will 
conflict. In libc++ we have

  template 
  inline _LIBCPP_CONSTEXPR_AFTER_CXX14
  _LIBCPP_NO_CFI _LIBCPP_INLINE_VISIBILITY
  _Tp*
  addressof(_Tp& __x) _NOEXCEPT
  {
  return __builtin_addressof(__x);
  }

So as long as the additional use case for `__builtin_addressof` is only 
activated when the argument is (syntactically) a reference to a function I 
don't think this libc++ code will be affected. I guess it's possible that there 
could be other users of `__builtin_addressof` that could be relying on the 
existing behavior, although it seems unlikely to me.

A similar use case that we may want to consider is for removing the pointer 
authentication bits when using the proposed PAuth ABI. D112941 
 proposes adding a separate builtin 
`__builtin_ptrauth_strip` for this purpose, although I believe that it cannot 
be used in constant expressions. If we decide to let `__builtin_addressof` 
absorb the no-CFI behavior then it seems reasonable for it to absorb the PAuth 
stripping behavior as well, but again only if the argument is a syntactic 
function reference. I personally would find this somewhat confusing though 
because stripping in the PAuth ABI can be performed at runtime on any pointer 
value and not just syntactic function references.

Should the builtin return a value of type `void*` instead of a pointer to the 
type of its argument? This would make it clear that the value returned by the 
builtin is not meant to be called in the usual way (this applies to both CFI 
and the PAuth ABI) and I suppose is another point in favor of this being a 
separate builtin.

Adding @rsmith and @rjmccall who may have opinions on the above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108479

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


[PATCH] D113146: Fix the assertion in Sema::ActOnDependentMemberExpr

2021-11-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 384858.
ychen added a comment.

- Check that TemplateArgs maybe null.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113146

Files:
  clang/lib/Sema/SemaExprMember.cpp
  clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -394,6 +394,18 @@
 template static int n; // expected-note {{here}}
   }
   int &t = B::template n; // expected-error {{use of variable template 'n' 
requires template arguments}}
+
+  struct C {
+template  static T G;
+  };
+  template T C::G = T(6);
+
+  template  T F() {
+C c;
+return c.G;
+  }
+
+  int cf() { return F(); }
 }
 
 #ifndef PRECXX11
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -504,9 +504,12 @@
 }
   }
 
-  assert(BaseType->isDependentType() ||
- NameInfo.getName().isDependentName() ||
- isDependentScopeSpecifier(SS));
+  assert(BaseType->isDependentType() || NameInfo.getName().isDependentName() ||
+ isDependentScopeSpecifier(SS) ||
+ (TemplateArgs && llvm::any_of(TemplateArgs->arguments(),
+   [](const TemplateArgumentLoc &Arg) {
+ return 
Arg.getArgument().isDependent();
+   })));
 
   // Get the type being accessed in BaseType.  If this is an arrow, the 
BaseExpr
   // must have pointer type, and the accessed type is the pointee.


Index: clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
===
--- clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
+++ clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
@@ -394,6 +394,18 @@
 template static int n; // expected-note {{here}}
   }
   int &t = B::template n; // expected-error {{use of variable template 'n' requires template arguments}}
+
+  struct C {
+template  static T G;
+  };
+  template T C::G = T(6);
+
+  template  T F() {
+C c;
+return c.G;
+  }
+
+  int cf() { return F(); }
 }
 
 #ifndef PRECXX11
Index: clang/lib/Sema/SemaExprMember.cpp
===
--- clang/lib/Sema/SemaExprMember.cpp
+++ clang/lib/Sema/SemaExprMember.cpp
@@ -504,9 +504,12 @@
 }
   }
 
-  assert(BaseType->isDependentType() ||
- NameInfo.getName().isDependentName() ||
- isDependentScopeSpecifier(SS));
+  assert(BaseType->isDependentType() || NameInfo.getName().isDependentName() ||
+ isDependentScopeSpecifier(SS) ||
+ (TemplateArgs && llvm::any_of(TemplateArgs->arguments(),
+   [](const TemplateArgumentLoc &Arg) {
+ return Arg.getArgument().isDependent();
+   })));
 
   // Get the type being accessed in BaseType.  If this is an arrow, the BaseExpr
   // must have pointer type, and the accessed type is the pointee.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D113080: [Support] Improve Caching conformance with Support library behavior

2021-11-04 Thread Petr Hosek via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd788c44f5cdd: [Support] Improve Caching conformance with 
Support library behavior (authored by noajshu, committed by phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113080

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  lld/COFF/LTO.cpp
  lld/ELF/LTO.cpp
  lld/MachO/LTO.cpp
  lld/wasm/LTO.cpp
  llvm/include/llvm/LTO/LTO.h
  llvm/include/llvm/Support/Caching.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/Support/Caching.cpp
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/llvm-lto/llvm-lto.cpp
  llvm/tools/llvm-lto2/llvm-lto2.cpp

Index: llvm/tools/llvm-lto2/llvm-lto2.cpp
===
--- llvm/tools/llvm-lto2/llvm-lto2.cpp
+++ llvm/tools/llvm-lto2/llvm-lto2.cpp
@@ -362,20 +362,20 @@
   if (HasErrors)
 return 1;
 
-  auto AddStream = [&](size_t Task) -> std::unique_ptr {
+  auto AddStream = [&](size_t Task) -> std::unique_ptr {
 std::string Path = OutputFilename + "." + utostr(Task);
 
 std::error_code EC;
 auto S = std::make_unique(Path, EC, sys::fs::OF_None);
 check(EC, Path);
-return std::make_unique(std::move(S));
+return std::make_unique(std::move(S));
   };
 
   auto AddBuffer = [&](size_t Task, std::unique_ptr MB) {
 *AddStream(Task)->OS << MB->getBuffer();
   };
 
-  NativeObjectCache Cache;
+  FileCache Cache;
   if (!CacheDir.empty())
 Cache = check(localCache("ThinLTO", "Thin", CacheDir, AddBuffer),
   "failed to create cache");
Index: llvm/tools/llvm-lto/llvm-lto.cpp
===
--- llvm/tools/llvm-lto/llvm-lto.cpp
+++ llvm/tools/llvm-lto/llvm-lto.cpp
@@ -1097,7 +1097,7 @@
 error("writing merged module failed.");
 }
 
-auto AddStream = [&](size_t Task) -> std::unique_ptr {
+auto AddStream = [&](size_t Task) -> std::unique_ptr {
   std::string PartFilename = OutputFilename;
   if (Parallelism != 1)
 PartFilename += "." + utostr(Task);
@@ -1107,7 +1107,7 @@
   std::make_unique(PartFilename, EC, sys::fs::OF_None);
   if (EC)
 error("error opening the file '" + PartFilename + "': " + EC.message());
-  return std::make_unique(std::move(S));
+  return std::make_unique(std::move(S));
 };
 
 if (!CodeGen.compileOptimized(AddStream, Parallelism))
Index: llvm/tools/gold/gold-plugin.cpp
===
--- llvm/tools/gold/gold-plugin.cpp
+++ llvm/tools/gold/gold-plugin.cpp
@@ -1081,11 +1081,11 @@
   size_t MaxTasks = Lto->getMaxTasks();
   std::vector, bool>> Files(MaxTasks);
 
-  auto AddStream = [&](size_t Task) -> std::unique_ptr {
+  auto AddStream = [&](size_t Task) -> std::unique_ptr {
 Files[Task].second = !SaveTemps;
 int FD = getOutputFileName(Filename, /* TempOutFile */ !SaveTemps,
Files[Task].first, Task);
-return std::make_unique(
+return std::make_unique(
 std::make_unique(FD, true));
   };
 
@@ -1093,7 +1093,7 @@
 *AddStream(Task)->OS << MB->getBuffer();
   };
 
-  NativeObjectCache Cache;
+  FileCache Cache;
   if (!options::cache_dir.empty())
 Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer));
 
Index: llvm/lib/Support/Caching.cpp
===
--- llvm/lib/Support/Caching.cpp
+++ llvm/lib/Support/Caching.cpp
@@ -1,4 +1,4 @@
-//===-Caching.cpp - LLVM File Cache Handling --===//
+//===-Caching.cpp - LLVM Local File Cache -===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -6,18 +6,17 @@
 //
 //===--===//
 //
-// This file implements the Caching used by ThinLTO.
+// This file implements the localCache function, which simplifies creating,
+// adding to, and querying a local file system cache. localCache takes care of
+// periodically pruning older files from the cache using a CachePruningPolicy.
 //
 //===--===//
 
 #include "llvm/Support/Caching.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Errc.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
-#include "llvm/Support/Process.h"
-#include "llvm/Support/raw_ostream.h"
 
 #if !defined(_MSC_VER) && !defined(__MINGW32__)
 #include 
@@ -27,10 +26,10 @@
 
 using namespace llvm;
 
-Expected llvm::localCache(Twine CacheNameRef,
- Twine TempFilePrefixRef,
- 

[clang] d788c44 - [Support] Improve Caching conformance with Support library behavior

2021-11-04 Thread Petr Hosek via cfe-commits

Author: Noah Shutty
Date: 2021-11-04T13:00:44-07:00
New Revision: d788c44f5cddb3e73069cd4d965bbf55b0d602d5

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

LOG: [Support] Improve Caching conformance with Support library behavior

This diff makes several amendments to the local file caching mechanism
which was migrated from ThinLTO to Support in
rGe678c51177102845c93529d457b020f969125373 in response to follow-up
discussion on that commit.

Patch By: noajshu

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

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
lld/COFF/LTO.cpp
lld/ELF/LTO.cpp
lld/MachO/LTO.cpp
lld/wasm/LTO.cpp
llvm/include/llvm/LTO/LTO.h
llvm/include/llvm/Support/Caching.h
llvm/lib/LTO/LTO.cpp
llvm/lib/LTO/LTOBackend.cpp
llvm/lib/LTO/LTOCodeGenerator.cpp
llvm/lib/Support/Caching.cpp
llvm/tools/gold/gold-plugin.cpp
llvm/tools/llvm-lto/llvm-lto.cpp
llvm/tools/llvm-lto2/llvm-lto2.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index cc4eb539f94a..e7ed77bcb60f 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -1559,7 +1559,7 @@ static void runThinLTOBackend(
 return;
 
   auto AddStream = [&](size_t Task) {
-return std::make_unique(std::move(OS));
+return std::make_unique(std::move(OS));
   };
   lto::Config Conf;
   if (CGOpts.SaveTempsFilePrefix != "") {

diff  --git a/lld/COFF/LTO.cpp b/lld/COFF/LTO.cpp
index 505360663f4f..f117b62192c8 100644
--- a/lld/COFF/LTO.cpp
+++ b/lld/COFF/LTO.cpp
@@ -164,7 +164,7 @@ std::vector 
BitcodeCompiler::compile(COFFLinkerContext &ctx) {
   // The /lldltocache option specifies the path to a directory in which to 
cache
   // native object files for ThinLTO incremental builds. If a path was
   // specified, configure LTO to use it as the cache directory.
-  NativeObjectCache cache;
+  FileCache cache;
   if (!config->ltoCache.empty())
 cache =
 check(localCache("ThinLTO", "Thin", config->ltoCache,
@@ -174,7 +174,7 @@ std::vector 
BitcodeCompiler::compile(COFFLinkerContext &ctx) {
 
   checkError(ltoObj->run(
   [&](size_t task) {
-return std::make_unique(
+return std::make_unique(
 std::make_unique(buf[task]));
   },
   cache));

diff  --git a/lld/ELF/LTO.cpp b/lld/ELF/LTO.cpp
index 5f206fc97b3c..a42d216e4e77 100644
--- a/lld/ELF/LTO.cpp
+++ b/lld/ELF/LTO.cpp
@@ -304,7 +304,7 @@ std::vector BitcodeCompiler::compile() {
   // The --thinlto-cache-dir option specifies the path to a directory in which
   // to cache native object files for ThinLTO incremental builds. If a path was
   // specified, configure LTO to use it as the cache directory.
-  NativeObjectCache cache;
+  FileCache cache;
   if (!config->thinLTOCacheDir.empty())
 cache =
 check(localCache("ThinLTO", "Thin", config->thinLTOCacheDir,
@@ -315,7 +315,7 @@ std::vector BitcodeCompiler::compile() {
   if (!bitcodeFiles.empty())
 checkError(ltoObj->run(
 [&](size_t task) {
-  return std::make_unique(
+  return std::make_unique(
   std::make_unique(buf[task]));
 },
 cache));

diff  --git a/lld/MachO/LTO.cpp b/lld/MachO/LTO.cpp
index d1eef6a6f8f8..c71ea33d2896 100644
--- a/lld/MachO/LTO.cpp
+++ b/lld/MachO/LTO.cpp
@@ -105,7 +105,7 @@ std::vector BitcodeCompiler::compile() {
   // The -cache_path_lto option specifies the path to a directory in which
   // to cache native object files for ThinLTO incremental builds. If a path was
   // specified, configure LTO to use it as the cache directory.
-  NativeObjectCache cache;
+  FileCache cache;
   if (!config->thinLTOCacheDir.empty())
 cache =
 check(localCache("ThinLTO", "Thin", config->thinLTOCacheDir,
@@ -115,7 +115,7 @@ std::vector BitcodeCompiler::compile() {
 
   checkError(ltoObj->run(
   [&](size_t task) {
-return std::make_unique(
+return std::make_unique(
 std::make_unique(buf[task]));
   },
   cache));

diff  --git a/lld/wasm/LTO.cpp b/lld/wasm/LTO.cpp
index 4659278be753..68d29eee6d5b 100644
--- a/lld/wasm/LTO.cpp
+++ b/lld/wasm/LTO.cpp
@@ -127,7 +127,7 @@ std::vector BitcodeCompiler::compile() {
   // The --thinlto-cache-dir option specifies the path to a directory in which
   // to cache native object files for ThinLTO incremental builds. If a path was
   // specified, configure LTO to use it as the cache directory.
-  NativeObjectCache cache;
+  FileCache cache;
   if (!config->thinLTOCacheDir.empty())
 cache =
 check(localCache("ThinLTO", "Thin", config->thinLTOCacheDir,
@@ -137,7 +137,7 @@ std::vector BitcodeCompiler::compile() {
 
   checkError(ltoObj->run(
   [&](

[PATCH] D112916: Confusable identifiers detection

2021-11-04 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 384854.
serge-sans-paille added a comment.

Portable `confusable.txt` parsing


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

https://reviews.llvm.org/D112916

Files:
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableTable/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/ConfusableTable/build_confusable_table.cpp
  clang-tools-extra/clang-tidy/misc/ConfusableTable/confusables.txt
  clang-tools-extra/clang-tidy/misc/Homoglyph.cpp
  clang-tools-extra/clang-tidy/misc/Homoglyph.h
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-homoglyph.rst
  clang-tools-extra/test/clang-tidy/check_clang_tidy.py
  clang-tools-extra/test/clang-tidy/checkers/misc-homoglyph.cpp

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


[PATCH] D95168: [clang-format] Add Insert/Remove Braces option

2021-11-04 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/include/clang/Format/Format.h:946
+/// Remove if there is no comment
+BIS_RemoveNoComment
+  };

MyDeveloperDay wrote:
> HazardyKnusperkeks wrote:
> > Maybe differentiate between single line and multi line comments?
> do you think we might want do remove braces from:
> 
> ```
> if (x) {
>   // Remove the braces
>   return true;
> }
> ```
> 
> but not from?
> 
> ```
> if (x) {
>   // Don't Remove the braces
>   // As the comment it longer
>   return true;
> }
> ```
> 
> I could see that
Basically yeah. I for one will only turn on insert, but I think a 
differentiation here is good.



Comment at: clang/include/clang/Format/Format.h:3675
R.AlwaysBreakTemplateDeclarations &&
AttributeMacros == R.AttributeMacros &&
BinPackArguments == R.BinPackArguments &&

MyDeveloperDay wrote:
> HazardyKnusperkeks wrote:
> > Add it here
> So I notice we don't do this for BraceWrapping, I was going to swing by on 
> this one and see why not.
Most likely a bug.



Comment at: clang/include/clang/Format/Format.h:3696
IndentRequires == R.IndentRequires && IndentWidth == R.IndentWidth 
&&
-   Language == R.Language &&
+   AutomaticBraces == R.AutomaticBraces && Language == R.Language &&
IndentWrappedFunctionNames == R.IndentWrappedFunctionNames &&

MyDeveloperDay wrote:
> HazardyKnusperkeks wrote:
> > Resort ;)
> ouch! thats someone elses bug... but I can look at it.
I wrote that when AutomaticBraces was after Language.

Yeah one could and should resort the whole list, but that was not what I meant.



Comment at: clang/lib/Format/BraceInserter.h:1
+//===--- BraceInserter.h - Format C++ code 
===//
+//

MyDeveloperDay wrote:
> HazardyKnusperkeks wrote:
> > Inserter is misleading, if we want it to be able to remove.
> Yes I'm going to rename the files, AutomaticBraces.cpp/.h  
> AutomaticBracesTests.cpp what do you think?
Sounds good.


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

https://reviews.llvm.org/D95168

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


[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

2021-11-04 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song updated this revision to Diff 384843.
yonghong-song added a comment.

- Change TypeLoc.isNull() check to !TypeLoc


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/AST/TypePrinter.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/attr-btf_type_tag-func.c
  clang/test/CodeGen/attr-btf_type_tag-typedef-field.c
  clang/test/CodeGen/attr-btf_type_tag-var.c
  clang/test/Sema/attr-btf_type_tag.c
  llvm/include/llvm/IR/DIBuilder.h
  llvm/lib/IR/DIBuilder.cpp
  llvm/test/Bitcode/attr-btf_type_tag.ll
  llvm/test/DebugInfo/attr-btf_type_tag.ll

Index: llvm/test/DebugInfo/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/attr-btf_type_tag.ll
@@ -0,0 +1,62 @@
+; REQUIRES: x86-registered-target
+; RUN: llc -filetype=obj -o %t %s
+; RUN: llvm-dwarfdump -debug-info %t | FileCheck %s
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   #define __tag2 __attribute__((btf_type_tag("tag2")))
+;
+;   int * __tag1 * __tag2 *g;
+; Compilation flag:
+;   clang -target x86_64 -g -S -emit-llvm t.c
+
+@g = dso_local global i32*** null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!13, !14, !15, !16, !17}
+!llvm.ident = !{!18}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 4, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "t.c", directory: "/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !11)
+!6 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !7, size: 64, annotations: !9)
+!7 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !8, size: 64)
+!8 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!9 = !{!10}
+!10 = !{!"btf_type_tag", !"tag1"}
+!11 = !{!12}
+!12 = !{!"btf_type_tag", !"tag2"}
+
+; CHECK:  DW_TAG_variable
+; CHECK-NEXT:   DW_AT_name  ("g")
+; CHECK-NEXT:   DW_AT_type  (0x[[T1:[0-9]+]] "int ***")
+
+; CHECK:  0x[[T1]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T2:[0-9]+]] "int **")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag2")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T2]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[T3:[0-9]+]] "int *")
+
+; CHECK:DW_TAG_LLVM_annotation
+; CHECK-NEXT: DW_AT_name("btf_type_tag")
+; CHECK-NEXT: DW_AT_const_value ("tag1")
+
+; CHECK:NULL
+
+; CHECK:  0x[[T3]]: DW_TAG_pointer_type
+; CHECK-NEXT:   DW_AT_type  (0x[[#]] "int")
+
+!13 = !{i32 7, !"Dwarf Version", i32 4}
+!14 = !{i32 2, !"Debug Info Version", i32 3}
+!15 = !{i32 1, !"wchar_size", i32 4}
+!16 = !{i32 7, !"uwtable", i32 1}
+!17 = !{i32 7, !"frame-pointer", i32 2}
+!18 = !{!"clang version 14.0.0 (https://github.com/llvm/llvm-project.git 2c240a5eefae1a945dfd36cdaa0c677eca90dd82)"}
Index: llvm/test/Bitcode/attr-btf_type_tag.ll
===
--- /dev/null
+++ llvm/test/Bitcode/attr-btf_type_tag.ll
@@ -0,0 +1,36 @@
+; RUN: llvm-as < %s | llvm-dis | FileCheck %s
+;
+; Source:
+;   #define __tag1 __attribute__((btf_type_tag("tag1")))
+;   int __tag1 *g;
+; Compilation flag:
+;   clang -S -g -emit-llvm test.c
+
+@g = dso_local global i32* null, align 8, !dbg !0
+
+!llvm.dbg.cu = !{!2}
+!llvm.module.flags = !{!9, !10, !11, !12, !13}
+!llvm.ident = !{!14}
+
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "g", scope: !2, file: !3, line: 2, type: !5, isLocal: false, isDefinition: true)
+!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 14.0.0 (https://github.com/llvm/llvm-project.git 248122328bfefe82608a2e110af3a3ff04279ddf)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
+!3 = !DIFile(filename: "test.c", directory: "/tmp/home/yhs/work/tests/llvm/btf_tag_type")
+!4 = !{!0}
+!5 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !6, size: 64, annotations: !7)
+!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!7 = !{!8}
+!8 = !{!"btf_type_tag", !"tag1"}
+
+; CHECK:   distinct !DIGlobalVariable(name: "g", scope: 

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

2021-11-04 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic added a comment.

@nickdesaulniers, thanks a lot for reporting this!
Unfortunately it is not easy to keep compatibility with GCC in this case. GCC 
has this diagnostic very late in the pipeline, and trivial uses of `long 
double` type (e.g. unused variables, constant expressions) can be optimized 
away before that. We cannot do the same with LLVM, because there is no way to 
emit a nice source-level diagnostic from the codegen.
I suggest to fix the kernel, because it looks like the `long double` literal is 
not intentional and can be replaced with just `double`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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


[PATCH] D113210: [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 384842.
aeubanks added a comment.

update LTOBackend.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113210

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before 
calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   
\
   FAM.registerPass([&] { return CREATE_PASS; });
 #include "PassRegistry.def"
Index: llvm/lib/LTO/ThinLTOCodeGenerator.cpp
===
--- llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -291,11 +291,6 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA = PB.buildDefaultAAPipeline();
-
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
-
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -251,18 +251,16 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA;
   // Parse a custom AA pipeline if asked to.
   if (!Conf.AAPipeline.empty()) {
+AAManager AA;
 if (auto Err = PB.parseAAPipeline(AA, Conf.AAPipeline)) {
   report_fatal_error(Twine("unable to parse AA pipeline description '") +
  Conf.AAPipeline + "': " + toString(std::move(Err)));
 }
-  } else {
-AA = PB.buildDefaultAAPipeline();
+// Register the AA manager first so that our version is the one used.
+FAM.registerPass([&] { return std::move(AA); });
   }
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
 
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1312,9 +1312,6 @@
   get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
 #include "llvm/Support/Extension.def"
 
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
-
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   \
   FAM.registerPass([&] { return CREATE_PASS; });

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

2021-11-04 Thread Yonghong Song via Phabricator via cfe-commits
yonghong-song added inline comments.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1426
+  TypeLoc RetTL;
+  if (!TL.isNull()) {
+if (auto FTL = TL.getAs())

dblaikie wrote:
> I'm /guessing/ this can be rewritten as:
> ```
> if (TL)
> ```
> ? (similarly elsewhere in this patch)
Yes. Indeed. Thanks for the suggestion! Will make changes in the next revision.



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1440-1441
+bool DoneWithTL = false;
+if (!TL.isNull()) {
+  if (auto FTL = TL.getAs()) {
+DoneWithTL = true;

dblaikie wrote:
> Is this null check necessary, or does "getAs" return null if the underlying 
> value is null already anyway? (oh, and this would apply above as well)
Yes. null check is necessary. Otherwise, we will get an assertion error like
```
clang: /home/yhs/work/llvm-project/clang/include/clang/AST/Type.h:689: const 
clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() const: Assertion 
`!isNull() && "Cannot retrieve 
a NULL type pointer"' failed.   


PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.  
 
Stack dump: 


0.  Program arguments: clang -g -D__TARGET_ARCH_x86 -mlittle-endian 
-I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include 
-I/home/yhs/work/bpf-next/tools/testing/selftest
s/bpf -I/home/yhs/work/bpf-next/tools/include/uapi 
-I/home/yhs/work/bpf-next/tools/testing/selftests/usr/include -idirafter 
/home/yhs/work/llvm-project/llvm/build.cur/install/lib/clang/14.
0.0/include -idirafter /usr/local/include -idirafter /usr/include 
-Wno-compare-distinct-pointer-types -DENABLE_ATOMICS_TESTS -O2 -target bpf -c 
progs/btf_dump_test_case_multidim.c -o /home
/yhs/work/bpf-next/tools/testing/selftests/bpf/btf_dump_test_case_multidim.o 
-mcpu=v3
   
1.   parser at end of file 


2.  progs/btf_dump_test_case_multidim.c:32:5: LLVM IR generation of 
declaration 'f' 

3.  progs/btf_dump_test_case_multidim.c:32:5: Generating code for 
declaration 'f' 
  
 #0 0x01e9e03f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0  


 #1 0x01e9be7c llvm::sys::CleanupOnSignal(unsigned long) 
(/home/yhs/work/llvm-project/llvm/build.cur/install/bin/clang-14+0x1e9be7c) 
   
 #2 0x01dea448 CrashRecoverySignalHandler(int) 
CrashRecoveryContext.cpp:0:0
 
 #3 0x7f7b08be4c20 __restore_rt sigaction.c:0:0 


 #4 0x7f7b078dc37f raise (/lib64/libc.so.6+0x3737f) 


 #5 0x7f7b078c6db5 abort (/lib64/libc.so.6+0x21db5) 


 #6 0x7f7b078c6c89 _nl_load_domain.cold.0 loadmsgcat.c:0:0  


 #7 0x7f7b078d4a76 .annobin___GI___assert_fail.end assert.c:0:0 


 #8 0x02193ba3 
(/home/yhs/work/llvm-project/llvm/build.cur/install/bin/clang-14+0x2193ba3) 

 
 #9 0x021b4981 
clang::CodeGen::CGDebugInfo::CreateType(clang::FunctionType const*, 
llvm::DIFile*, clang::TypeLoc) 
(/home/yhs/work/llvm-project/llvm/build.cur/install/bin/clang-14+0
x21b4981)   

[PATCH] D113210: [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Alina Sbirlea via Phabricator via cfe-commits
asbirlea added a comment.

Can you also update `lib/LTO/LTOBackend.cpp` to something like:

  // Parse a custom AA pipeline if asked to, otherwise the default will be used.
  if (!Conf.AAPipeline.empty()) {
AAManager AA;
if (auto Err = PB.parseAAPipeline(AA, Conf.AAPipeline)) {
  report_fatal_error(Twine("unable to parse AA pipeline description '") +
 Conf.AAPipeline + "': " + toString(std::move(Err)));
}
// Register the AA manager first so that our version is the one used.
FAM.registerPass([&] { return std::move(AA); });
  } 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113210

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


[PATCH] D113211: [NFC][clang] Inclusive terms: replace uses of blacklist in clang/test/

2021-11-04 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA created this revision.
ZarkoCA added reviewers: kcc, samsonov, jkorous, lebedev.ri, pcc, 
vlad.tsyrklevich.
ZarkoCA requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Replace filenames, variable names, check prefixes uses of blacklist with ignore 
list.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113211

Files:
  clang/test/CodeGen/Inputs/sanitizer-blacklist-vfsoverlay.yaml
  clang/test/CodeGen/Inputs/sanitizer-ignorelist-vfsoverlay.yaml
  clang/test/CodeGen/address-safety-attr.cpp
  clang/test/CodeGen/asan-globals.cpp
  clang/test/CodeGen/catch-alignment-assumption-blacklist.c
  clang/test/CodeGen/catch-alignment-assumption-ignorelist.c
  clang/test/CodeGen/catch-implicit-integer-sign-changes-true-negatives.c
  clang/test/CodeGen/catch-implicit-integer-truncations-basics-negatives.c
  clang/test/CodeGen/catch-implicit-integer-truncations.c
  
clang/test/CodeGen/catch-implicit-signed-integer-truncations-basics-negatives.c
  
clang/test/CodeGen/catch-implicit-unsigned-integer-truncations-basics-negatives.c
  clang/test/CodeGen/catch-nullptr-and-nonzero-offset-blacklist.c
  clang/test/CodeGen/catch-nullptr-and-nonzero-offset-ignorelist.c
  clang/test/CodeGen/cfi-check-fail2.c
  clang/test/CodeGen/sanitize-thread-attr.cpp
  clang/test/CodeGen/ubsan-blacklist.c
  clang/test/CodeGen/ubsan-ignorelist-vfs.c
  clang/test/CodeGen/ubsan-ignorelist.c
  clang/test/CodeGenCXX/catch-implicit-integer-sign-changes-true-negatives.cpp
  clang/test/CodeGenCXX/cfi-blacklist.cpp
  clang/test/CodeGenCXX/cfi-ignorelist.cpp

Index: clang/test/CodeGenCXX/cfi-ignorelist.cpp
===
--- clang/test/CodeGenCXX/cfi-ignorelist.cpp
+++ clang/test/CodeGenCXX/cfi-ignorelist.cpp
@@ -1,18 +1,18 @@
 // RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOBL %s
 
-// Check that blacklisting cfi and cfi-vcall work correctly
+// Check that ignore listing cfi and cfi-vcall work correctly
 // RUN: echo "[cfi-vcall]" > %t.vcall.txt
 // RUN: echo "type:std::*" >> %t.vcall.txt
-// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-blacklist=%t.vcall.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOSTD %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-ignorelist=%t.vcall.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOSTD %s
 //
 // RUN: echo "[cfi]" > %t.cfi.txt
 // RUN: echo "type:std::*" >> %t.cfi.txt
-// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-blacklist=%t.cfi.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOSTD %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-ignorelist=%t.cfi.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOSTD %s
 
-// Check that blacklisting non-vcall modes does not affect vcalls
+// Check that ignore listing non-vcall modes does not affect vcalls
 // RUN: echo "[cfi-icall|cfi-nvcall|cfi-cast-strict|cfi-derived-cast|cfi-unrelated-cast]" > %t.other.txt
 // RUN: echo "type:std::*" >> %t.other.txt
-// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-blacklist=%t.other.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOBL %s
+// RUN: %clang_cc1 -triple %itanium_abi_triple -fvisibility hidden -fms-extensions -fsanitize=cfi-vcall -fsanitize-ignorelist=%t.other.txt -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=NOBL %s
 
 struct S1 {
   virtual void f();
Index: clang/test/CodeGenCXX/catch-implicit-integer-sign-changes-true-negatives.cpp
===
--- clang/test/CodeGenCXX/catch-implicit-integer-sign-changes-true-negatives.cpp
+++ clang/test/CodeGenCXX/catch-implicit-integer-sign-changes-true-negatives.cpp
@@ -12,30 +12,30 @@
 // Sanitization is explicitly disabled.
 // == //
 
-// CHECK-LABEL: @blacklist_0
-__attribute__((no_sanitize("undefined"))) unsigned int blacklist_0(signed int src) {
+// CHECK-LABEL: @ignorelist_0
+__attribute__((no_sanitize("undefined"))) unsigned int ignorelist_0(signed int src) {
   // We are not in "undefined" group, so that doesn't work.
   // CHECK-SANITIZE: call
   // CHECK: }
   return src;
 }
 
-// CHECK-LABEL: @blacklist_1
-__attribute__((no_sanitize("integer"))) unsigned int blacklist_1(signed int src) {
+// CHECK-LABEL: @ignorelist_1
+__attribute__((no_sanitize("integer"))) unsigned int ignorelist_1(signed int src) {
   // CHECK-SANITIZE-NOT: call

[PATCH] D112850: [clang] 'unused-but-set-variable' warning should not apply to __block objective-c pointers

2021-11-04 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

The lifetime of an object won't be extended in the following case since the 
variable isn't captured by a block:

  void foo(id);
  
  void test(id a) {
  __block id t = a;
  foo(a);
  t = 0;
  }

clang should probably warn if a variable marked `__block` isn't captured by a 
block, but I don't think `-Wunused-but-set-variable` should catch that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112850

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


[PATCH] D112732: [ASan] Process functions in Asan module pass

2021-11-04 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added a comment.

In D112732#3107387 , @aeubanks wrote:

> can we rename "asan-module" to "asan" after this change? and remove the extra 
> "asan-pipeline"/"asan-function-pipeline" parsing callbacks in 
> NewPMDriver.cpp? and previously we had `-passes=require` 
> because a function pass couldn't invoke a module analysis, but that's no 
> longer relevant, so cleaning those up from RUN lines would also be good

That was idea, but I changed my mind and recommended to do that in a separate 
patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112732

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


[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

2021-11-04 Thread Thorsten via Phabricator via cfe-commits
tschuett added a comment.

The `avxintrin.h` header has more structured documentation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

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


[PATCH] D112732: [ASan] Process functions in Asan module pass

2021-11-04 Thread Vitaly Buka via Phabricator via cfe-commits
vitalybuka added inline comments.



Comment at: llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp:1289
+  }
+  Modified |= ModuleSanitizer.instrumentModule(M);
+  if (Modified)

vitalybuka wrote:
> kstoimenov wrote:
> > At first I had module sanitizer run first, but some tests failed. Is it 
> > possible that the function pass has some side effects, which are used by 
> > the module pass? 
> That's OK.
> 
> NewPMDriver.cpp was wrong, BackendUtil.cpp was wrong
> 
> if we put module in-front of function  the following with disable globals 
> instrumentation:
> ```
>  if (G && (!ClInitializers || GlobalIsLinkerInitialized(G)) &&
> isSafeAccess(ObjSizeVis, Addr, O.TypeSize)) {
> ```
> 
Fixing typo in the comment.
>> NewPMDriver.cpp was wrong, BackendUtil.cpp was wrong
NewPMDriver.cpp was correct, BackendUtil.cpp was wrong


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112732

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


[PATCH] D112491: Add `LambdaCapture`-related matchers.

2021-11-04 Thread James King via Phabricator via cfe-commits
jcking1034 marked an inline comment as done.
jcking1034 added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:223-229
+- ``LambdaCapture`` AST Matchers are now available. These matchers allow for
+  the binding of ``LambdaCapture`` nodes, and include the ``lambdaCapture``,
+  ``capturesVar``, and ``capturesThis`` matchers. In addition, the
+  ``hasAnyCapture`` matcher has been updated to accept an inner matcher of
+  type ``Matcher`` - its original interface accepted an inner
+  matcher of type ``Matcher`` or ``Matcher``, but did
+  not allow for the binding of ``LambdaCapture`` nodes.

aaron.ballman wrote:
> We should have an additional note about the removal of the old matchers.
I believe that the only change made to the old matchers is that `hasAnyCapture` 
now accepts an inner matcher of type `Matcher`, and no longer 
accepts inner matchers of type `Matcher` or `Matcher`. 
I've revised this note and broken it up into two points for clarity.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

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


[PATCH] D112850: [clang] 'unused-but-set-variable' warning should not apply to __block objective-c pointers

2021-11-04 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak accepted this revision.
ahatanak added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112850

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


[PATCH] D112491: Add `LambdaCapture`-related matchers.

2021-11-04 Thread James King via Phabricator via cfe-commits
jcking1034 updated this revision to Diff 384835.
jcking1034 added a comment.

Update release notes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112491

Files:
  clang/docs/LibASTMatchersReference.html
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ASTTypeTraits.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/AST/ASTTypeTraits.cpp
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -563,26 +563,6 @@
   objcMessageExpr(hasReceiver(declRefExpr(to(varDecl(hasName("x";
 }
 
-TEST(Matcher, HasAnyCapture) {
-  auto HasCaptureX = lambdaExpr(hasAnyCapture(varDecl(hasName("x";
-  EXPECT_TRUE(matches("void f() { int x = 3; [x](){}; }", HasCaptureX));
-  EXPECT_TRUE(matches("void f() { int x = 3; [&x](){}; }", HasCaptureX));
-  EXPECT_TRUE(notMatches("void f() { [](){}; }", HasCaptureX));
-  EXPECT_TRUE(notMatches("void f() { int z = 3; [&z](){}; }", HasCaptureX));
-  EXPECT_TRUE(
-  notMatches("struct a { void f() { [this](){}; }; };", HasCaptureX));
-}
-
-TEST(Matcher, CapturesThis) {
-  auto HasCaptureThis = lambdaExpr(hasAnyCapture(cxxThisExpr()));
-  EXPECT_TRUE(
-  matches("struct a { void f() { [this](){}; }; };", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { [](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int x = 3; [x](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int x = 3; [&x](){}; }", HasCaptureThis));
-  EXPECT_TRUE(notMatches("void f() { int z = 3; [&z](){}; }", HasCaptureThis));
-}
-
 TEST(Matcher, MatchesMethodsOnLambda) {
   StringRef Code = R"cpp(
 struct A {
Index: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -2237,6 +2237,65 @@
  varDecl(hasName("ss"), hasTypeLoc(elaboratedTypeLoc();
 }
 
+TEST_P(ASTMatchersTest, LambdaCaptureTest) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  lambdaExpr(hasAnyCapture(lambdaCapture();
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_BindsToCaptureOfVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(capturesVar(varDecl(hasName("cc"));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(matches("int main() { int cc; auto f = [&cc](){ return cc; }; }",
+  matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [=](){ return cc; }; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc; auto f = [&](){ return cc; }; }", matcher));
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_BindsToCaptureWithInitializer) {
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(
+  varDecl(hasName("cc"), hasInitializer(integerLiteral(equals(1;
+  EXPECT_TRUE(
+  matches("int main() { auto lambda = [cc = 1] {return cc;}; }", matcher));
+  EXPECT_TRUE(
+  matches("int main() { int cc = 2; auto lambda = [cc = 1] {return cc;}; }",
+  matcher));
+}
+
+TEST_P(ASTMatchersTest, LambdaCaptureTest_DoesNotBindToCaptureOfVarDecl) {
+  if (!GetParam().isCXX11OrLater()) {
+return;
+  }
+  auto matcher = lambdaExpr(
+  hasAnyCapture(lambdaCapture(capturesVar(varDecl(hasName("cc"));
+  EXPECT_FALSE(matches("int main() { auto f = [](){ return 5; }; }", matcher));
+  EXPECT_FALSE(matches("int main() { int xx; auto f = [xx](){ return xx; }; }",
+   matcher));
+}
+
+TEST_P(ASTMatchersTest,
+   LambdaCaptureTest_DoesNotBindToCaptureWithInitializerAndDifferentName) {
+  if (!GetParam().isCXX14OrLater()) {
+return;
+  }
+  EXPECT_FALSE(matches(
+  "int main() { auto lambda = [xx = 1] {return xx;}; }",
+  lambdaExpr(hasAnyCapture(lambdaCapture(capturesVar(varDecl(
+  hasName("cc"), hasInitializer(integerLiteral(equals(1));
+}
+
 TEST(ASTMatchersTestObjC, ObjCMessageExpr) {
   // Don't find ObjCMessageExpr where none are present.
   EXPECT_TRUE(notMatchesObjC("", objcMessageExpr(anything(;
Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

2021-11-04 Thread Ahmed Bougacha via Phabricator via cfe-commits
ab added a comment.

In D112941#3105297 , @tschuett wrote:

> The original `ptrauth.h` has the same comment style. Would doxygen style be 
> an improvement?

Hmm, what do you have in mind?  Markup for the builtin arguments/returns?  The 
need for `__` prefixes makes that a bit awkward, but I suppose that's not a big 
deal (and we do live with that for x86 intrins already)




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:839
+def err_ptrauth_disabled :
+  Error<"pointer authentication is disabled for the current target">;
+def err_ptrauth_invalid_key :

rjmccall wrote:
> apazos wrote:
> > These two error types are confusing. 
> > In which situation would err_ptrauth_disabled be printed?
> > With this patch, it is only supported with arm64e triple, all other targets 
> > it is unsupported.
> We could probably just have one of these, yes.
With this patch you'd get `err_ptrauth_disabled` with `-target arm64e- 
-fno-ptrauth-intrinsics`, instead of `err_ptrauth_disabled_target` with say 
`-target x86_64`.  But yeah, I suppose we could live with only one of the two, 
with a less accurate message (either `err_ptrauth_disabled_target` renamed to 
`err_ptrauth_disabled`, or another more vague message altogether, say "pointer 
authentication is not supported")

This mostly removes the need for `Sema::diagnosePointerAuthDisabled` and 
`TargetInfo::isPointerAuthSupported` and lets us just rely on the individual 
langopts, which seems okay.



Comment at: clang/lib/Basic/Targets/AArch64.cpp:847
+const llvm::APSInt &value) const {
+  return 0 <= value && value <= 3;
+}

rjmccall wrote:
> There's an LLVM constants header for this now, right?
Hmm, I don't think so, do you have something in mind?  The AArch64 backend has 
helpers for this, but that's confined there.  IR doesn't know anything about 
keys (for instance, the IR verifier doesn't have the same validation done here)

There's a related latent concern I have: currently, nothing prevents 
optimizations from moving ptrauth ops into global constant initializers, and 
since we don't support global initializers with process-specific keys (at least 
on darwin), we may need to expose this knowledge somehow (undoing this in the 
backend is not straightforward, but is an option). 

Knowing which keys are used in what way would need to be triple-specific, 
though I guess that's not an obstacle.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

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


[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

2021-11-04 Thread Ahmed Bougacha via Phabricator via cfe-commits
ab updated this revision to Diff 384827.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression of type}}
+}
+
+void test_sign_unauthenticated(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY); // expected-error {{too few arguments}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, dp, dp); // expected-error {{too many arguments}}
+
+  __builtin_ptrauth_sign_unauthenticated(mismatched_type, VALID_DATA_KEY, 0); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, mismatched_type, 0); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, mismatched_type); // expected-error {{extra discriminator must have pointer or integer type; type here is 'struct A'}}
+
+  (void) __builtin_ptrauth_sign_unauthenticated(NULL, VALID_DATA_KEY, 0); // expected-warning {{signing a null pointer wil

[PATCH] D112941: [clang] Add support for the new pointer authentication builtins.

2021-11-04 Thread Ahmed Bougacha via Phabricator via cfe-commits
ab updated this revision to Diff 384825.
ab marked 3 inline comments as done.
ab added a comment.

Simplify `err_ptrauth_disabled` diagnostic, rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112941

Files:
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Module.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/module.modulemap
  clang/lib/Headers/ptrauth.h
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/ptrauth-intrinsics.c
  clang/test/Driver/arch-arm64e.c
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/module.modulemap
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/ptrauth.h
  clang/test/Modules/Inputs/ptrauth-include-from-darwin/stddef.h
  clang/test/Modules/ptrauth-include-from-darwin.m
  clang/test/Preprocessor/ptrauth_feature.c
  clang/test/Sema/ptrauth-intrinsics-macro.c
  clang/test/Sema/ptrauth.c

Index: clang/test/Sema/ptrauth.c
===
--- /dev/null
+++ clang/test/Sema/ptrauth.c
@@ -0,0 +1,126 @@
+// RUN: %clang_cc1 -triple arm64-apple-ios -fsyntax-only -verify -fptrauth-intrinsics %s
+
+#if __has_feature(ptrauth_intrinsics)
+#warning Pointer authentication enabled!
+// expected-warning@-1 {{Pointer authentication enabled!}}
+#endif
+
+#if __aarch64__
+#define VALID_CODE_KEY 0
+#define VALID_DATA_KEY 2
+#define INVALID_KEY 200
+#else
+#error Provide these constants if you port this test
+#endif
+
+#define NULL ((void*) 0)
+struct A { int x; } mismatched_type;
+
+extern int dv;
+extern int fv(int);
+
+void test_strip(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_strip(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_strip(dp, VALID_DATA_KEY, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_strip(NULL, VALID_DATA_KEY); // no warning
+
+  __builtin_ptrauth_strip(mismatched_type, VALID_DATA_KEY); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_strip(dp, mismatched_type); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+
+  int *dr = __builtin_ptrauth_strip(dp, VALID_DATA_KEY);
+  dr = __builtin_ptrauth_strip(dp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  int (*fr)(int) = __builtin_ptrauth_strip(fp, VALID_CODE_KEY);
+  fr = __builtin_ptrauth_strip(fp, INVALID_KEY); // expected-error {{does not identify a valid pointer authentication key for the current target}}
+
+  float *mismatch = __builtin_ptrauth_strip(dp, VALID_DATA_KEY); // expected-warning {{incompatible pointer types initializing 'float *' with an expression of type 'int *'}}
+}
+
+void test_blend_discriminator(int *dp, int (*fp)(int), int value) {
+  __builtin_ptrauth_blend_discriminator(dp); // expected-error {{too few arguments}}
+  __builtin_ptrauth_blend_discriminator(dp, dp, dp); // expected-error {{too many arguments}}
+  (void) __builtin_ptrauth_blend_discriminator(dp, value); // no warning
+
+  __builtin_ptrauth_blend_discriminator(mismatched_type, value); // expected-error {{blended pointer must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_blend_discriminator(dp, mismatched_type); // expected-error {{blended integer must have integer type; type here is 'struct A'}}
+
+  float *mismatch = __builtin_ptrauth_blend_discriminator(dp, value); // expected-warning {{incompatible integer to pointer conversion initializing 'float *' with an expression of type}}
+}
+
+void test_sign_unauthenticated(int *dp, int (*fp)(int)) {
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY); // expected-error {{too few arguments}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, dp, dp); // expected-error {{too many arguments}}
+
+  __builtin_ptrauth_sign_unauthenticated(mismatched_type, VALID_DATA_KEY, 0); // expected-error {{signed value must have pointer type; type here is 'struct A'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, mismatched_type, 0); // expected-error {{passing 'struct A' to parameter of incompatible type 'int'}}
+  __builtin_ptrauth_sign_unauthenticated(dp, VALID_DATA_KEY, mismatched_type); // expected-error {{extra discriminator must have pointer or integer type; type here is 'struct A'}}
+
+  (void) __

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

2021-11-04 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

This seems to be causing build errors for the linux kernel (which uses 
`-mno-x87`) for expressions like: `unsigned long foo = 300L * 1E6L;`
https://github.com/ClangBuiltLinux/linux/issues/1497

  // clang -O2 -mno-x87
  void foo (unsigned long);
  void bar (void) { foo(1 * 1E6L); }

  :3:25: error: expression requires  'long double' type support, but 
target 'x86_64-unknown-linux-gnu' does not support it
  void bar (void) { foo(1 * 1E6L); }
  ^

While we can change kernel sources to not use `L` suffixes for floating point 
literals, this is a curious difference from GCC and may lead to compatibility 
issues with other code bases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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


[PATCH] D113210: [NewPM] Use the default AA pipeline by default

2021-11-04 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks created this revision.
aeubanks added a reviewer: asbirlea.
Herald added subscribers: ormris, steven_wu, hiraditya.
Herald added a reviewer: ctetreau.
Herald added a reviewer: ctetreau.
aeubanks requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

We almost always want to use the default AA pipeline. It's very easy for
users of PassBuilder to forget to customize the AAManager to use the
default AA pipeline (for example, the NewPM C API forgets to do this).

If somebody wants a custom AA pipeline, similar to what is being done
now with the default AA pipeline registration, they can

  FAM.registerPass([&] { return std::move(MyAA); });

before calling

  PB.registerFunctionAnalyses(FAM);

For example, LTOBackend.cpp and NewPMDriver.cpp do this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113210

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before 
calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   
\
   FAM.registerPass([&] { return CREATE_PASS; });
 #include "PassRegistry.def"
Index: llvm/lib/LTO/ThinLTOCodeGenerator.cpp
===
--- llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -291,11 +291,6 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA = PB.buildDefaultAAPipeline();
-
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return std::move(AA); });
-
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1312,9 +1312,6 @@
   get##Ext##PluginInfo().RegisterPassBuilderCallbacks(PB);
 #include "llvm/Support/Extension.def"
 
-  // Register the AA manager first so that our version is the one used.
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
-
   // Register the target library analysis directly and give it a customized
   // preset TLI.
   Triple TargetTriple(TheModule->getTargetTriple());


Index: llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
===
--- llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
+++ llvm/tools/llvm-opt-fuzzer/llvm-opt-fuzzer.cpp
@@ -144,7 +144,6 @@
   ModulePassManager MPM;
   ModuleAnalysisManager MAM;
 
-  FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
   PB.registerFunctionAnalyses(FAM);
Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -413,6 +413,11 @@
 }
 
 void PassBuilder::registerFunctionAnalyses(FunctionAnalysisManager &FAM) {
+  // We almost always want the default alias analysis pipeline.
+  // If a user wants a different one, they can register their own before calling
+  // registerFunctionAnalyses().
+  FAM.registerPass([&] { return buildDefaultAAPipeline(); });
+
 #define FUNCTION_ANALYSIS(NAME, CREATE_PASS)   \
   FAM.registerPass([&] { return CREATE_PASS; });
 #include "PassRegistry.def"
Index: llvm/lib/LTO/ThinLTOCodeGenerator.cpp
===
--- llvm/lib/LTO/ThinLTOCodeGenerator.cpp
+++ llvm/lib/LTO/ThinLTOCodeGenerator.cpp
@@ -291,11 +291,6 @@
 TLII->disableAllFunctions();
   FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
 
-  AAManager AA = PB.buildDefaultAAPipeline();
-

[PATCH] D111654: [analyzer] Retrieve a value from list initialization of multi-dimensional array declaration.

2021-11-04 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

@steakhal Thank you for your suggestion. I'll make corresponding changes.

> I'm still worried about the fact that you assume that there is a 
> correspondence between `ElementRegions` and `InitListExprs`.
> I cannot see why this assumption holds, since reinterpret casts might 
> introduce `ElementRegions` which could mess with this assumption.

Currently in practice `ElementRegions` for array element access expression look 
like `InitListExprs` structure. But you are right about mess with different 
casts. That's why I have //FIXME's//  in `glob_ptr_index2` and 
`glob_invalid_index6`.
Right now I'm working on fixing this stuff. I'm gonna refactor 
`StoreManager::castRegion` in a part of `ElementRegions` to distinguish between 
array indirections and casts.


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

https://reviews.llvm.org/D111654

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

>> If the result wasn't null (call it F), use GI->takeName(F); 
>> F->replaceAllUsesWith(GI);

When I wrote the multiversioning support in the first place, I was told that 
the above was unacceptable and the CFE doesn't wish to do that anymore.  There 
ARE some examples, but I was instructed to not make it worse.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D106823: [analyzer][solver] Iterate to a fixpoint during symbol simplification with constants

2021-11-04 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> As of diff 5, line 1767 and all the code in the block at line 2184 are 
> uncovered by the tests you provided.

Thanks, I've added new tests that cover the re-assume logic (the block of line 
2184).

However, I was unable to add a test that covers  the case when the 
simplification of a trivial symbol in the disequality info results an 
infeasible state (line 1767). Here is how I tried: I had changed the line to an 
assertion and then initiated the static analysis of the following opensource 
projects: 
memcached,tmux,curl,twin,redis,vim,openssl,sqlite,ffmpeg,postgresql,tinyxml2,libwebm,xerces,bitcoin,protobuf.
 My idea had been, if the assertion would fired then I would use creduce to the 
create the test case (btw, this is how I added the other infeasible state test 
case). However, it did not fired.

IMHO, having a defensive check at L1767 is correct b/c there is a slight chance 
of reaching an infeasible state there. Although the chance is minimal, I cannot 
prove that is 0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106823

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


[PATCH] D106823: [analyzer][solver] Iterate to a fixpoint during symbol simplification with constants

2021-11-04 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 384802.
martong added a comment.

- Add new tests to cover missing line coverage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106823

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/expr-inspection-printState-eq-classes.c
  clang/test/Analysis/symbol-simplification-disequality-info.cpp
  
clang/test/Analysis/symbol-simplification-fixpoint-iteration-unreachable-code.cpp
  clang/test/Analysis/symbol-simplification-fixpoint-one-iteration.cpp
  clang/test/Analysis/symbol-simplification-fixpoint-two-iterations.cpp
  clang/test/Analysis/symbol-simplification-reassume.cpp

Index: clang/test/Analysis/symbol-simplification-reassume.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbol-simplification-reassume.cpp
@@ -0,0 +1,37 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -verify
+
+// In this test we check whether the solver's symbol simplification mechanism
+// is capable of re-assuming simiplified symbols.
+
+void clang_analyzer_eval(bool);
+void clang_analyzer_warnIfReached();
+
+void test_reassume_false_range(int x, int y) {
+  if (x + y != 0) // x + y == 0
+return;
+  if (x != 1) // x == 1
+return;
+  clang_analyzer_eval(y == -1); // expected-warning{{TRUE}}
+}
+
+void test_reassume_true_range(int x, int y) {
+  if (x + y != 1) // x + y == 1
+return;
+  if (x != 1) // x == 1
+return;
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+}
+
+void test_reassume_inclusive_range(int x, int y) {
+  if (x + y < 0 || x + y > 1) // x + y: [0, 1]
+return;
+  if (x != 1) // x == 1
+return;
+  // y: [-1, 0]
+  clang_analyzer_eval(y > 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval(y < -1);// expected-warning{{FALSE}}
+}
Index: clang/test/Analysis/symbol-simplification-fixpoint-two-iterations.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbol-simplification-fixpoint-two-iterations.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   2>&1 | FileCheck %s
+
+// In this test we check whether the solver's symbol simplification mechanism
+// is capable of reaching a fixpoint. This should be done after TWO iterations.
+
+void clang_analyzer_printState();
+
+void test(int a, int b, int c, int d) {
+  if (a + b + c != d)
+return;
+  if (c + b != 0)
+return;
+  clang_analyzer_printState();
+  // CHECK:  "constraints": [
+  // CHECK-NEXT:   { "symbol": "(((reg_$0) + (reg_$1)) + (reg_$2)) != (reg_$3)", "range": "{ [0, 0] }" },
+  // CHECK-NEXT:   { "symbol": "(reg_$2) + (reg_$1)", "range": "{ [0, 0] }" }
+  // CHECK-NEXT: ],
+  // CHECK-NEXT: "equivalence_classes": [
+  // CHECK-NEXT:   [ "((reg_$0) + (reg_$1)) + (reg_$2)", "reg_$3" ]
+  // CHECK-NEXT: ],
+  // CHECK-NEXT: "disequality_info": null,
+
+  // Simplification starts here.
+  if (b != 0)
+return;
+  clang_analyzer_printState();
+  // CHECK:   "constraints": [
+  // CHECK-NEXT:{ "symbol": "(reg_$0) != (reg_$3)", "range": "{ [0, 0] }" },
+  // CHECK-NEXT:{ "symbol": "reg_$1", "range": "{ [0, 0] }" },
+  // CHECK-NEXT:{ "symbol": "reg_$2", "range": "{ [0, 0] }" }
+  // CHECK-NEXT:  ],
+  // CHECK-NEXT:  "equivalence_classes": [
+  // CHECK-NEXT:[ "(reg_$0) != (reg_$3)" ],
+  // CHECK-NEXT:[ "reg_$0", "reg_$3" ],
+  // CHECK-NEXT:[ "reg_$2" ]
+  // CHECK-NEXT:  ],
+  // CHECK-NEXT:  "disequality_info": null,
+
+  // Keep the symbols and the constraints! alive.
+  (void)(a * b * c * d);
+  return;
+}
Index: clang/test/Analysis/symbol-simplification-fixpoint-one-iteration.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbol-simplification-fixpoint-one-iteration.cpp
@@ -0,0 +1,40 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   2>&1 | FileCheck %s
+
+// In this test we check whether the solver's symbol simplification mechanism
+// is capable of reaching a fixpoint. This should be done after one iteration.
+
+void clang_analyzer_printState();
+
+void test(int a, int b, int c) {
+  if (a + b != c)
+return;
+  clang_analyzer_printState();
+  // CHECK:  "constraints": [
+  // CHECK-NEXT:   { "symbol": "((reg_$0) + (reg_$1)) != (reg_$2)", "range": "{ [0, 0] }" }
+  // CHECK-NEXT: ],
+  // CHECK-NEXT: "equivalence_classes": [
+  // CHECK-NEXT:   [ "(reg_$0) + (reg_$1)", "reg_$2" ]
+  // CH

[PATCH] D113195: [clang-tidy] Add check for initialization of `absl::Cleanup`.

2021-11-04 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel accepted this revision.
ymandel added a comment.
This revision is now accepted and ready to land.

Nice!




Comment at: clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.cpp:19
+
+using namespace clang::ast_matchers;
+using namespace ::clang::transformer;





Comment at: clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.cpp:46-49
+bool CleanupCtadCheck::isLanguageVersionSupported(
+const LangOptions &LangOpts) const {
+  return LangOpts.CPlusPlus17;
+}

nit: move this inline into the class declaration. Serves as documentation for 
the class then as well (in that a reader can look in the header and see the 
target language).



Comment at: clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.h:20
+/// instances from the factory function to class template argument
+/// deduction (CTAD) in C++17 and higher.
+///





Comment at: 
clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp:7-20
+template 
+class Cleanup {
+public:
+  Cleanup(T) {}
+  Cleanup(Cleanup &&) {}
+};
+

Since the tests depend on the mock of the `Cleanup` declaration, have you run 
this on real code examples to double-check that it works as expected? Sometimes 
the divergence means real code can have unexpected implicit nodes that subtly 
impact the results, so it's always good to verify the mocks themselves in some 
way.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp:41
+
+  auto b = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class 
template argument deduction pattern in C++17 and higher

nit: this subtle, i'd add a comment pointing out the parens.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp:42
+  auto b = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class 
template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup b = [] {};{{$}}

Here and below: you can truncate to 80 chars, any repeated message. We 
typically only check the whole message for the first appearance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113195

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


[PATCH] D112492: [HIP] Do not use kernel handle for MSVC target

2021-11-04 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

> With these changes, we should have consistent name mangling for kernel stubs 
> and kernel launching mechanism on Linux and Windows.

Nice! Thank you for figuring out the root causes.


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

https://reviews.llvm.org/D112492

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


[PATCH] D112024: [clang] diagnose_as attribute for Fortify diagnosing like builtins.

2021-11-04 Thread Michael Benfield via Phabricator via cfe-commits
mbenfield marked 8 inline comments as done.
mbenfield added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:3822
+def DiagnoseAs : InheritableAttr {
+  let Spellings = [Clang<"diagnose_as">];
+  let Args = [ExprArgument<"Function">,

serge-sans-paille wrote:
> aaron.ballman wrote:
> > george.burgess.iv wrote:
> > > purely subjective nit: `diagnose_as` feels a bit too generic. if you 
> > > agree, does `diagnose_as_builtin` sound potentially better?
> > Agreed on it being a bit generic -- it sounds like this is only useful for 
> > Fortify, so I wonder if I'm wrong about that or whether we should name it 
> > `fortify_diagnose_as_builtin` or `fortify_diagnostic`, etc.
> (Jumping in a  bit late) I second the `diagnose_as_builtin` name. But then we 
> should check that the attribute is only set on inline builtin declaration (as 
> in `Decl::isInlineBuiltinDeclaration`) and state so in the documentation.
I think `Decl::isInlineBuiltinDeclaration` may be the wrong thing to check; it 
fails for some builtin functions. Instead I'm checking against `getBuiltinID`. 
Let me know if you feel this is incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112024

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


[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

2021-11-04 Thread David Blaikie via Phabricator via cfe-commits
dblaikie accepted this revision.
dblaikie added a comment.

Seems unfortunate that attributes on types are only available through TypeLocs 
rather than through sugar (like if we used a typedef it'd be visible in the 
type sugar, but not if it's written on the type usage itself) - but that's 
above my domain knowledge here & I'll take it there are some good reasons for 
that to be the way it is.




Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1426
+  TypeLoc RetTL;
+  if (!TL.isNull()) {
+if (auto FTL = TL.getAs())

I'm /guessing/ this can be rewritten as:
```
if (TL)
```
? (similarly elsewhere in this patch)



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1440-1441
+bool DoneWithTL = false;
+if (!TL.isNull()) {
+  if (auto FTL = TL.getAs()) {
+DoneWithTL = true;

Is this null check necessary, or does "getAs" return null if the underlying 
value is null already anyway? (oh, and this would apply above as well)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99

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


[PATCH] D113201: [clang-tidy] Fix a crash in modernize-loop-convert around conversion operators

2021-11-04 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus created this revision.
Szelethus added reviewers: aaron.ballman, alexfh, steakhal, whisperity.
Szelethus added a project: clang-tools-extra.
Herald added subscribers: carlosgalvezp, martong, gamesh411, dkrupp, rnkovacs, 
xazax.hun.
Szelethus requested review of this revision.
Herald added a subscriber: cfe-commits.

When an iterator is initialized with a conversion operator (e.g. `for 
(const_iterator it = non_const_container.begin(); ...)`, 
`getContainerFromBeginEndCall()` failed with an assert. It attempts to retrieve 
the name of the initializer expression, which in the case of a conversion 
operator doesn't exist.

I fixed this by making `digThroughConstructors` dig through conversion 
operators as well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113201

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-loop-convert/structures.h
  clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-basic.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-basic.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-basic.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-basic.cpp
@@ -273,6 +273,16 @@
   // CHECK-FIXES: for (int & It : Tt)
   // CHECK-FIXES-NEXT: printf("I found %d\n", It);
 
+  // Do not crash because of Qt.begin() converting. Q::converting_iterator
+  // converts with a conversion iterator, which has no name.
+  Q Qt;
+  for (Q::iterator It = Qt.begin(), E = Qt.end(); It != E; ++It) {
+printf("I found %d\n", *It);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int & It : Qt)
+  // CHECK-FIXES-NEXT: printf("I found %d\n", It);
+
   T *Pt;
   for (T::iterator It = Pt->begin(), E = Pt->end(); It != E; ++It) {
 printf("I found %d\n", *It);
Index: clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-loop-convert/structures.h
===
--- clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-loop-convert/structures.h
+++ clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-loop-convert/structures.h
@@ -53,6 +53,23 @@
   iterator end();
 };
 
+struct Q {
+  typedef int value_type;
+  struct iterator {
+value_type &operator*();
+const value_type &operator*() const;
+iterator &operator++();
+bool operator!=(const iterator &other);
+void insert(value_type);
+value_type X;
+  };
+  struct converting_iterator {
+operator iterator() const;
+  };
+  converting_iterator begin();
+  converting_iterator end();
+};
+
 struct U {
   struct iterator {
 Val& operator*();
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
@@ -275,7 +275,7 @@
 typedef llvm::SmallVector UsageResult;
 
 // General functions used by ForLoopIndexUseVisitor and LoopConvertCheck.
-const Expr *digThroughConstructors(const Expr *E);
+const Expr *digThroughConstructorsConversions(const Expr *E);
 bool areSameExpr(ASTContext *Context, const Expr *First, const Expr *Second);
 const DeclRefExpr *getDeclRef(const Expr *E);
 bool areSameVariable(const ValueDecl *First, const ValueDecl *Second);
Index: clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
===
--- clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
+++ clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.cpp
@@ -7,6 +7,8 @@
 //===--===//
 
 #include "LoopConvertUtils.h"
+#include "clang/AST/Expr.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Basic/IdentifierTable.h"
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/Lambda.h"
@@ -152,7 +154,7 @@
   return true;
 }
 
-/// Look through conversion/copy constructors to find the explicit
+/// Look through conversion/copy constructors and operators to find the explicit
 /// initialization expression, returning it is found.
 ///
 /// The main idea is that given
@@ -165,7 +167,7 @@
 ///   vector::iterator it;
 ///   vector::iterator it(v.begin(), 0); // if this constructor existed
 /// as being initialized from `v.begin()`
-const Expr *digThroughConstructors(const Expr *E) {
+const Expr *digThroughConstructorsConversions(const Expr *E) {
   if (!E)
 return nullptr;
   E = E->IgnoreImplicit();
@@ -178,8 +180,13 @@
 E = ConstructExpr->getArg(0);
 if (const auto *Temp = dyn_cast(E))
   E = Temp->getSubExpr(

[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein added a comment.

That feature already exists - use a plain old function declaration :)

My mental model for this is like this:
memcpy one of the is the most widely popular APIs commonly implemented as an 
ifunc. In clients of this API, it's just a plain old function declaration. In 
the implementer of this API, it's an ifunc with a defined resolver. Nothing new 
here.
It's true that this usage usually crosses a dynamic-linking boundary (rather 
than static linking), but a lot of the times dynamic linking and static linking 
are set up to mirror each other in behavior.

What I'm proposing is as follows. I really haven't read the existing 
implementation yet, so I'm not sure if it makes 100% sense in terms of it, but 
bear with me:

- When processing cpu_specific, emit a plain old function declaration "x.ifunc";
- When processing cpu_dispatch:
  1. Create an unnamed ifunc (call it `GI`)
  2. Call CodeGenModule::GetGlobalValue
  3. If the result was null, set the name of the ifunc and continue
  4. If the result wasn't null (call it `F`), use `GI->takeName(F); 
F->replaceAllUsesWith(GI);`
- Throughout, references against the multiversioned symbol are bound against 
the correctly named global. It just so happens that it could either begin its 
life as an ifunc and remain that way, begin its life as function declaration 
and remain that way, or begin its life as a function declaration and get 
upgraded (by RAUW) to an ifunc.

You can think of this as mirroring the behavior of the IR linker - linking a 
bitcode module containing an ifunc definition into an existing module where 
there's a function declaration with the same name as the ifunc simply tramples 
over the function declaration (RAUWs it with the linked-in ifunc). This is 
exactly what happens in `llvm/test/Linker/ifunc.ll` for `bar`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D112915: WIP: [clang][modules] Granular tracking of includes

2021-11-04 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 384791.
jansvoboda11 added a comment.

Call `getFileInfo` in `Preprocessor::EnterMainSourceFile`. This ensures 
deserialization of `HeaderFileInfo`, which seems to be necessary with 
modules-ts enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112915

Files:
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPLexerChange.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/Inputs/import-submodule-visibility/A.framework/Headers/A.h
  
clang/test/Modules/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Headers/B1.h
  clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Headers/B2.h
  
clang/test/Modules/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/C/C.h
  clang/test/Modules/Inputs/import-submodule-visibility/C/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/D/D1.h
  clang/test/Modules/Inputs/import-submodule-visibility/D/D2.h
  clang/test/Modules/Inputs/import-submodule-visibility/D/module.modulemap
  clang/test/Modules/Inputs/import-submodule-visibility/Textual.h
  clang/test/Modules/import-submodule-visibility.c

Index: clang/test/Modules/import-submodule-visibility.c
===
--- /dev/null
+++ clang/test/Modules/import-submodule-visibility.c
@@ -0,0 +1,58 @@
+// RUN: rm -rf %t && mkdir -p %t
+
+// This test checks that imports of headers that appeared in a different submodule than
+// what is imported by the current TU don't affect the compilation.
+
+// Framework "A" includes "Textual.h" in the top-level module.
+// This test checks that simply specifying the PCM file on the command line (without actually importing "A") does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap -fmodule-name=A -o %t/A.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DA \
+// RUN:   -fmodule-file=%t/A.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/A.framework/Modules/module.modulemap
+
+// Framework "B" includes "Textual.h" in the "B1" submodule and its "B2" submodule does not include "Textual.h" at all.
+// This test checks that specifying the PCM file on the command line and importing "B2" in the source does not
+// prevent "Textual.h" to be included in the TU.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap -fmodule-name=B -o %t/B.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DB -iframework %S/Inputs/import-submodule-visibility \
+// RUN:   -fmodule-file=%t/B.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/B.framework/Modules/module.modulemap
+
+// Module "C" includes "Textual.h" in the top level module.
+// This is a module-only version of the test with framework A.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/C/module.modulemap -fmodule-name=C -o %t/C.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DC \
+// RUN:   -fmodule-file=%t/C.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/C/module.modulemap
+
+// Module "D" includes "Textual.h" in the "D1" submodule and its "D2" submodules does not include "Textual.h" at all.
+// This is a module-only version of the test with framework B.
+//
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility \
+// RUN:   -emit-module %S/Inputs/import-submodule-visibility/D/module.modulemap -fmodule-name=D -o %t/D.pcm
+// RUN: %clang_cc1 -fmodules -I %S/Inputs/import-submodule-visibility -fsyntax-only %s -DD \
+// RUN:   -fmodule-file=%t/D.pcm -fmodule-map-file=%S/Inputs/import-submodule-visibility/D/module.modulemap
+
+#ifdef A
+//
+#endif
+
+#ifdef B
+#import 
+#endif
+
+#ifdef C
+//
+#endif
+
+#ifdef D
+#import "D/D2.h"
+#endif
+
+#import "Textual.h"
+
+static int x = MACRO_TEXTUAL;
Index: clang/test/Modules/Inputs/import-submodule-visibility/Textual.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/import-submodule-visibility/Textual.h
@@ -0,0 +1 @@
+#defi

[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D112349#3109211 , 
@nextsilicon-itay-bookstein wrote:

>> I don't know much about the ELF format... but this works today?  We can 
>> define a resolver in a different TU and it WORKS thanks to the linker?  So 
>> there is perhaps something?
>
> The ifunc symbol that is emitted in the TU with the undefined resolver loses 
> its connection to the resolver and the calls to the ifunc are instead bound 
> against the resolver itself (which is absolutely not what you want).
>
>   itay> cat specific.c
>   #include 
>   
>   __attribute__((cpu_specific(generic)))
>   void single_version(void){
> puts("In single_version generic");
>   }
>   
>   void useage() {
> single_version();
>   }
>   
>   itay> cat dispatch_main.c
>   void useage(void);
>   
>   __attribute__((cpu_dispatch(generic)))
>   void single_version(void);
>   
>   int main()
>   {
> useage();
> single_version();
> return 0;
>   }
>   
>   itay> clang -c dispatch_main.c -o dispatch_main.c.o
>   itay> clang -c specific.c -o specific.c.o
>   itay> clang specific.c.o dispatch_main.c.o -o main
>   itay> ./main
>   In single_version generic
>
> This line should have been printed twice, not once.

I see... thank you for your patience, my knowledge of ELF (or, that is, 
basically everything after Clang LLVM-IR generation) is pretty slim.

I think what I would need to be able to correctly implement this is some level 
of 'forward declarable' ifunc.  I have to be able to process declarations as we 
reach them, so just doing a function declaration then rewriting it wouldn't be 
allowed.

Is it possible to get some IR-level 'ifunc' declaration implemented?  If so, I 
think I have a good idea on how to implement that in the CFE.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein added a comment.

> I don't know much about the ELF format... but this works today?  We can 
> define a resolver in a different TU and it WORKS thanks to the linker?  So 
> there is perhaps something?

The ifunc symbol that is emitted in the TU with the undefined resolver loses 
its connection to the resolver and the calls to the ifunc are instead bound 
against the resolver itself (which is absolutely not what you want).

  itay> cat specific.c
  #include 
  
  __attribute__((cpu_specific(generic)))
  void single_version(void){
puts("In single_version generic");
  }
  
  void useage() {
single_version();
  }
  
  itay> cat dispatch_main.c
  void useage(void);
  
  __attribute__((cpu_dispatch(generic)))
  void single_version(void);
  
  int main()
  {
useage();
single_version();
return 0;
  }
  
  itay> clang -c dispatch_main.c -o dispatch_main.c.o
  itay> clang -c specific.c -o specific.c.o
  itay> clang specific.c.o dispatch_main.c.o -o main
  itay> ./main
  In single_version generic

This line should have been printed twice, not once.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson added a comment.

In D113148#3108993 , @aaron.ballman 
wrote:

> Generally speaking, we prefer to improve the existing checks. I think 
> `bugprone-string-constructor` would probably be a better place for the 
> constructor-related functionality. But that still means we don't have a good 
> place for things like the assignment and comparison functionality, and it 
> seems more useful to keep all of the `string_view`-with-`nullptr` logic in 
> one place. That said, we should be careful we're not too onerous when users 
> enable all `bugprone` checks together.

I agree with the statement "it seems more useful to keep all of the 
`string_view`-with-`nullptr` logic in one place". To me, these are very 
logically related. The fact that some of it is constructor based is not as 
useful from a user perspective. The relationship between `nullptr` and 
`string_view` is more important, in my view.

As for "we should be careful we're not too onerous when users enable all 
`bugprone` checks together.", these fixes are about preventing UB. While I did 
put this in the "bugprone" module, perhaps "prone" is the wrong way to think 
about it. It's unconditionally UB in all cases, not just a potential bug. The 
suggested fixes are important for preventing crashes in the short term, but 
more importantly for allowing the code to build in the future, since the 
constructor overload `basic_string_view(nullptr_t) = delete;` is being added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Hmm... we've never had any problems with cpu-dispatch/specific on this before?  
An example just like that works in all my internal tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein added a comment.

It sort-of-works only because you define the ifunc in both translation units 
(with the same name). But looks like it behaves incorrectly for references to 
the ifunc in the translation unit where the resolver is only declared, not 
defined:

  > cat example1.ll
  @single_version_ifunc = weak_odr dso_local ifunc void (), void ()* ()* 
@single_version_resolver
  define void ()* @single_version_resolver() {
ret void ()* null
  }
  
  define dso_local void @useage() local_unnamed_addr {
  entry:
tail call void @single_version_ifunc()
ret void
  }
  > clang -c example1.ll -o example1.ll.o
  > llvm-readobj --relocations example1.ll.o
  
  File: example1.ll.o
  Format: elf64-x86-64
  Arch: x86_64
  AddressSize: 64bit
  LoadName: 
  Relocations [
Section (3) .rela.text {
  0x11 R_X86_64_PLT32 single_version_ifunc 0xFFFC <-- FINE
}
Section (6) .rela.eh_frame {
  0x20 R_X86_64_PC32 .text 0x0
  0x34 R_X86_64_PC32 .text 0x10
}
  ]
  
  > cat example2.ll
  @single_version_ifunc = weak_odr dso_local ifunc void (), void ()* ()* 
@single_version_resolver
  declare void ()* @single_version_resolver()
  
  define dso_local void @useage() local_unnamed_addr {
  entry:
tail call void @single_version_ifunc()
ret void
  }
  > clang -c example2.ll -o example2.ll.o
  > llvm-readobj --relocations example2.ll.o
  
  File: example2.ll.o
  Format: elf64-x86-64
  Arch: x86_64
  AddressSize: 64bit
  LoadName: 
  Relocations [
Section (3) .rela.text {
  0x1 R_X86_64_PLT32 single_version_resolver 0xFFFC  <-- WHOOPS
}
Section (6) .rela.eh_frame {
  0x20 R_X86_64_PC32 .text 0x0
}
  ]


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson updated this revision to Diff 384775.
CJ-Johnson added a comment.

Remove trailing whitespace


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/StringviewNullptrCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-stringview-nullptr.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-stringview-nullptr.cpp
@@ -0,0 +1,1030 @@
+// RUN: %check_clang_tidy %s bugprone-stringview-nullptr -std=c++17 %t
+
+namespace std {
+
+using nullptr_t = decltype(nullptr);
+
+template 
+T &&declval();
+
+template 
+struct type_identity { using type = T; };
+template 
+using type_identity_t = typename type_identity::type;
+
+template 
+class basic_string_view {
+public:
+  basic_string_view();
+  basic_string_view(const C *);
+  basic_string_view(const basic_string_view &);
+  basic_string_view &operator=(const basic_string_view &);
+};
+
+template 
+bool operator<(basic_string_view, basic_string_view);
+template 
+bool operator<(type_identity_t>, basic_string_view);
+template 
+bool operator<(basic_string_view, type_identity_t>);
+
+template 
+bool operator<=(basic_string_view, basic_string_view);
+template 
+bool operator<=(type_identity_t>, basic_string_view);
+template 
+bool operator<=(basic_string_view, type_identity_t>);
+
+template 
+bool operator>(basic_string_view, basic_string_view);
+template 
+bool operator>(type_identity_t>, basic_string_view);
+template 
+bool operator>(basic_string_view, type_identity_t>);
+
+template 
+bool operator>=(basic_string_view, basic_string_view);
+template 
+bool operator>=(type_identity_t>, basic_string_view);
+template 
+bool operator>=(basic_string_view, type_identity_t>);
+
+template 
+bool operator==(basic_string_view, basic_string_view);
+template 
+bool operator==(type_identity_t>, basic_string_view);
+template 
+bool operator==(basic_string_view, type_identity_t>);
+
+template 
+bool operator!=(basic_string_view, basic_string_view);
+template 
+bool operator!=(type_identity_t>, basic_string_view);
+template 
+bool operator!=(basic_string_view, type_identity_t>);
+
+using string_view = basic_string_view;
+
+} // namespace std
+
+void function(std::string_view);
+void function(std::string_view, std::string_view);
+
+void temporary_construction() /* a */ {
+  // Functional Cast
+  {
+(void)(std::string_view(nullptr)) /* a1 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a1 */;{{$}}
+
+(void)(std::string_view((nullptr))) /* a2 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a2 */;{{$}}
+
+(void)(std::string_view({nullptr})) /* a3 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a3 */;{{$}}
+
+(void)(std::string_view({(nullptr)})) /* a4 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view()) /* a4 */;{{$}}
+
+// (void)(const std::string_view(nullptr)) /* a5 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view((nullptr))) /* a6 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({nullptr})) /* a7 */;
+// CV qualifiers do not compile in this context
+
+// (void)(const std::string_view({(nullptr)})) /* a8 */;
+// CV qualifiers do not compile in this context
+  }
+
+  // Temporary Object
+  {
+(void)(std::string_view{nullptr}) /* a9 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::string_view{}) /* a9 */;{{$}}
+
+(void)(std::string_view{(nullptr)}) /* a10 */;
+// CHECK-MESSAGES: :[[@LINE-1]]:29: warning: constructing basic_string_view from null is undefined; replace with the default constructor
+// CHECK-FIXES: {{^}}(void)(std::s

[PATCH] D113195: Suggests switching the initialization pattern of absl::Cleanup instances from the factory function to class template argument deduction (CTAD) in C++17 and higher.

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson updated this revision to Diff 384774.
CJ-Johnson added a comment.

Add trailing newline


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113195

Files:
  clang-tools-extra/clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tools-extra/clang-tidy/abseil/CMakeLists.txt
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.cpp
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
@@ -0,0 +1,68 @@
+// RUN: %check_clang_tidy %s abseil-cleanup-ctad -std=c++17 %t
+
+namespace absl {
+
+struct Tag {};
+
+template 
+class Cleanup {
+public:
+  Cleanup(T) {}
+  Cleanup(Cleanup &&) {}
+};
+
+template 
+Cleanup(Callback callback) -> Cleanup;
+
+template 
+absl::Cleanup MakeCleanup(T t) {
+  return absl::Cleanup(t);
+}
+
+} // namespace absl
+
+namespace std {
+
+template 
+class function {
+public:
+  template 
+  function(T) {}
+  function(const function &) {}
+};
+
+} // namespace std
+
+void test() {
+  auto a = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup a = [] {};{{$}}
+
+  auto b = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup b = [] {};{{$}}
+
+  const auto c = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup c = [] {};{{$}}
+
+  const auto d = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup d = [] {};{{$}}
+
+  auto e = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup e = std::function([] {});{{$}}
+
+  auto f = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup f = std::function([] {});{{$}}
+
+  const auto g = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup g = std::function([] {});{{$}}
+
+  const auto h = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup h = std::function([] {});{{$}}
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -12,6 +12,7 @@
 .. csv-table::
:header: "Name", "Offers fixes"
 
+   `abseil-cleanup-ctad `_, "Yes"
`abseil-duration-addition `_, "Yes"
`abseil-duration-comparison `_, "Yes"
`abseil-duration-conversion-cast `_, "Yes"
@@ -448,3 +449,4 @@
`hicpp-vararg `_, `cppcoreguidelines-pro-type-vararg `_,
`llvm-else-after-return `_, `readability-else-after-return `_, "Yes"
`llvm-qualified-auto `_, `readability-qualified-auto `_, "Yes"
+   
\ No newline at end of file
Index: clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
@@ -0,0 +1,22 @@
+.. title:: clang-tidy - abseil-cleanup-ctad
+
+abseil-cleanup-ctad
+===
+
+Suggests switching the initialization pattern of ``absl::Cleanup``
+instances from the factory function to class template argument
+deduction (CTAD) in C++17 and higher.
+
+.. code-block:: c++
+
+  auto c1 = absl::MakeCleanup([] {});
+
+  const auto c2 = absl::MakeCleanup(std::function([] {}));
+
+becomes
+
+.. code-block:: c++
+
+  absl::Cleanup c1 = [] {};
+
+  const absl::Cleanup c2 = std::function([] {});
Index: clang-tools-extra/docs/ReleaseNotes.rst

[PATCH] D113195: Suggests switching the initialization pattern of absl::Cleanup instances from the factory function to class template argument deduction (CTAD) in C++17 and higher.

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson updated this revision to Diff 384773.
CJ-Johnson added a comment.

Remove unwanted changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113195

Files:
  clang-tools-extra/clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tools-extra/clang-tidy/abseil/CMakeLists.txt
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.cpp
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
@@ -0,0 +1,68 @@
+// RUN: %check_clang_tidy %s abseil-cleanup-ctad -std=c++17 %t
+
+namespace absl {
+
+struct Tag {};
+
+template 
+class Cleanup {
+public:
+  Cleanup(T) {}
+  Cleanup(Cleanup &&) {}
+};
+
+template 
+Cleanup(Callback callback) -> Cleanup;
+
+template 
+absl::Cleanup MakeCleanup(T t) {
+  return absl::Cleanup(t);
+}
+
+} // namespace absl
+
+namespace std {
+
+template 
+class function {
+public:
+  template 
+  function(T) {}
+  function(const function &) {}
+};
+
+} // namespace std
+
+void test() {
+  auto a = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup a = [] {};{{$}}
+
+  auto b = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup b = [] {};{{$}}
+
+  const auto c = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup c = [] {};{{$}}
+
+  const auto d = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup d = [] {};{{$}}
+
+  auto e = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup e = std::function([] {});{{$}}
+
+  auto f = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup f = std::function([] {});{{$}}
+
+  const auto g = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup g = std::function([] {});{{$}}
+
+  const auto h = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup h = std::function([] {});{{$}}
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -12,6 +12,7 @@
 .. csv-table::
:header: "Name", "Offers fixes"
 
+   `abseil-cleanup-ctad `_, "Yes"
`abseil-duration-addition `_, "Yes"
`abseil-duration-comparison `_, "Yes"
`abseil-duration-conversion-cast `_, "Yes"
@@ -447,4 +448,4 @@
`hicpp-use-override `_, `modernize-use-override `_, "Yes"
`hicpp-vararg `_, `cppcoreguidelines-pro-type-vararg `_,
`llvm-else-after-return `_, `readability-else-after-return `_, "Yes"
-   `llvm-qualified-auto `_, `readability-qualified-auto `_, "Yes"
+   `llvm-qualified-auto `_, `readability-qualified-auto `_, "Yes"
\ No newline at end of file
Index: clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
@@ -0,0 +1,22 @@
+.. title:: clang-tidy - abseil-cleanup-ctad
+
+abseil-cleanup-ctad
+===
+
+Suggests switching the initialization pattern of ``absl::Cleanup``
+instances from the factory function to class template argument
+deduction (CTAD) in C++17 and higher.
+
+.. code-block:: c++
+
+  auto c1 = absl::MakeCleanup([] {});
+
+  const auto c2 = absl::MakeCleanup(std::function([] {}));
+
+becomes
+
+.. code-block:: c++
+
+  absl::Cleanup c1 = [] 

[PATCH] D112453: [Sema] When dereferencing a pointer of dependent type, infer the result type.

2021-11-04 Thread Clement Courbet via Phabricator via cfe-commits
courbet added a comment.

> Is this change observable in some way?

With the new changes, we are now catching more typing errors before 
instantiation. I've added more tests to show that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112453

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


[PATCH] D113195: Suggests switching the initialization pattern of absl::Cleanup instances from the factory function to class template argument deduction (CTAD) in C++17 and higher.

2021-11-04 Thread CJ Johnson via Phabricator via cfe-commits
CJ-Johnson created this revision.
CJ-Johnson added a reviewer: ymandel.
Herald added subscribers: carlosgalvezp, mgorny.
CJ-Johnson requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Suggests switching the initialization pattern of absl::Cleanup instances from 
the factory function to class template argument deduction (CTAD) in C++17 and 
higher.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113195

Files:
  clang-tools-extra/clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tools-extra/clang-tidy/abseil/CMakeLists.txt
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.cpp
  clang-tools-extra/clang-tidy/abseil/CleanupCtadCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/abseil-cleanup-ctad.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/abseil-cleanup-ctad.cpp
@@ -0,0 +1,68 @@
+// RUN: %check_clang_tidy %s abseil-cleanup-ctad -std=c++17 %t
+
+namespace absl {
+
+struct Tag {};
+
+template 
+class Cleanup {
+public:
+  Cleanup(T) {}
+  Cleanup(Cleanup &&) {}
+};
+
+template 
+Cleanup(Callback callback) -> Cleanup;
+
+template 
+absl::Cleanup MakeCleanup(T t) {
+  return absl::Cleanup(t);
+}
+
+} // namespace absl
+
+namespace std {
+
+template 
+class function {
+public:
+  template 
+  function(T) {}
+  function(const function &) {}
+};
+
+} // namespace std
+
+void test() {
+  auto a = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup a = [] {};{{$}}
+
+  auto b = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup b = [] {};{{$}}
+
+  const auto c = absl::MakeCleanup([] {});
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup c = [] {};{{$}}
+
+  const auto d = absl::MakeCleanup(([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup d = [] {};{{$}}
+
+  auto e = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup e = std::function([] {});{{$}}
+
+  auto f = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  absl::Cleanup f = std::function([] {});{{$}}
+
+  const auto g = absl::MakeCleanup(std::function([] {}));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup g = std::function([] {});{{$}}
+
+  const auto h = absl::MakeCleanup((std::function([] {})));
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: prefer absl::Cleanup's class template argument deduction pattern in C++17 and higher
+  // CHECK-FIXES: {{^}}  const absl::Cleanup h = std::function([] {});{{$}}
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -12,6 +12,7 @@
 .. csv-table::
:header: "Name", "Offers fixes"
 
+   `abseil-cleanup-ctad `_, "Yes"
`abseil-duration-addition `_, "Yes"
`abseil-duration-comparison `_, "Yes"
`abseil-duration-conversion-cast `_, "Yes"
@@ -114,13 +115,12 @@
`cert-dcl50-cpp `_,
`cert-dcl58-cpp `_,
`cert-env33-c `_,
+   `cert-err33-c `_,
`cert-err34-c `_,
`cert-err52-cpp `_,
`cert-err58-cpp `_,
`cert-err60-cpp `_,
-   `cert-exp42-c `_,
`cert-flp30-c `_,
-   `cert-flp37-c `_,
`cert-mem57-cpp `_,
`cert-msc50-cpp `_,
`cert-msc51-cpp `_,
@@ -288,6 +288,7 @@
`readability-const-return-type `_, "Yes"
`readability-container-size-empty `_, "Yes"
`readability-convert-member-functions-to-static `_,
+   `readability-data-pointer `_,
`readability-delete-null-pointer `_, "Yes"
`readability-else-after-return `_, "Yes"
`readability-function-cognitive-complexity `_,
@@ -333,13 +334,14 @@
`cert-dcl03-c `_, `misc-static-assert `_, "Yes"
`cert-dcl16-c `_, `readability-uppercase-literal-

[PATCH] D112453: [Sema] When dereferencing a pointer of dependent type, infer the result type.

2021-11-04 Thread Clement Courbet via Phabricator via cfe-commits
courbet updated this revision to Diff 384771.
courbet added a comment.

Implement the proposed changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112453

Files:
  clang/include/clang/AST/Type.h
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/AST/ast-dump-expr-json.cpp
  clang/test/AST/ast-dump-expr.cpp
  clang/test/AST/ast-dump-lambda.cpp
  clang/test/CXX/over/over.built/ast.cpp
  clang/test/CXX/over/over.built/p10.cpp
  clang/test/CXX/over/over.built/p11.cpp
  clang/test/CXX/over/over.built/p13.cpp
  clang/test/CXX/over/over.built/p14.cpp
  clang/test/CXX/over/over.built/p18.cpp
  clang/test/CXX/over/over.built/p19.cpp
  clang/test/CXX/over/over.built/p20.cpp
  clang/test/CXX/over/over.built/p22.cpp
  clang/test/CXX/over/over.built/p23.cpp
  clang/test/CXX/over/over.built/p4.cpp
  clang/test/CXX/over/over.built/p5.cpp
  clang/test/CXX/over/over.built/p7.cpp
  clang/test/Frontend/noderef_templates.cpp
  clang/test/SemaTemplate/dependent-type-identity.cpp

Index: clang/test/SemaTemplate/dependent-type-identity.cpp
===
--- clang/test/SemaTemplate/dependent-type-identity.cpp
+++ clang/test/SemaTemplate/dependent-type-identity.cpp
@@ -69,6 +69,16 @@
   void f8(typename N::X2::template apply *);
   void f8(typename N::X2::template apply *);
   void f8(typename ::Nalias::X2::template apply *); // expected-error{{redeclar}}
+
+  // (17.4.2): If an expression e is type-dependent (17.6.2.2), decltype(e)
+  // denotes a unique dependent type. Two such decltype-specifiers refer to the
+  // same type only if their expressions are equivalent (17.5.6.1)
+  T* a;
+  T* b;
+  using V = decltype(*a);
+  void f9(decltype(*a)); // expected-note{{previous}}
+  void f9(decltype(*b));
+  void f9(V); // expected-error{{redeclar}}
 };
 
 namespace PR6851 {
Index: clang/test/Frontend/noderef_templates.cpp
===
--- clang/test/Frontend/noderef_templates.cpp
+++ clang/test/Frontend/noderef_templates.cpp
@@ -3,8 +3,8 @@
 #define NODEREF __attribute__((noderef))
 
 template 
-int func(T NODEREF *a) { // expected-note 2 {{a declared here}}
-  return *a + 1; // expected-warning 2 {{dereferencing a; was declared with a 'noderef' type}}
+int func(T NODEREF *a) { // expected-note 3 {{a declared here}}
+  return *a + 1; // expected-warning 3 {{dereferencing a; was declared with a 'noderef' type}}
 }
 
 void func() {
Index: clang/test/CXX/over/over.built/p7.cpp
===
--- clang/test/CXX/over/over.built/p7.cpp
+++ clang/test/CXX/over/over.built/p7.cpp
@@ -3,10 +3,11 @@
 struct A{};
 
 template 
-void f(int* pi, A* pa, T* pt) {
+void f(int* pi, A* pa, T* pt, T t) {
   (void)*pi;
   (void)*pa;
   (void)*pt;
+  (void)*t;  // `T` might be a `U*`.
 }
 // expected-no-diagnostics
 
Index: clang/test/CXX/over/over.built/p5.cpp
===
--- clang/test/CXX/over/over.built/p5.cpp
+++ clang/test/CXX/over/over.built/p5.cpp
@@ -1,10 +1,14 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s -Wno-tautological-compare
 
-void f(int i, bool b) {
+template 
+void f(int i, bool b, T t) {
   (void)--i;
   (void)i--;
 
   (void)--b; // expected-error {{cannot decrement expression of type bool}}
   (void)b--; // expected-error {{cannot decrement expression of type bool}}
+
+  (void)--t;
+  (void)t--;
 }
 
Index: clang/test/CXX/over/over.built/p4.cpp
===
--- clang/test/CXX/over/over.built/p4.cpp
+++ clang/test/CXX/over/over.built/p4.cpp
@@ -1,10 +1,14 @@
 // RUN: %clang_cc1 -std=c++17 -verify %s -Wno-tautological-compare
 
-void f(int i, bool b) {
+template 
+void f(int i, bool b, T t) {
   (void)++i;
   (void)i++;
 
   (void)++b; // expected-error {{ISO C++17 does not allow incrementing expression of type bool}}
   (void)b++; // expected-error {{ISO C++17 does not allow incrementing expression of type bool}}
+
+  (void)++t;
+  (void)t++;
 }
 
Index: clang/test/CXX/over/over.built/p23.cpp
===
--- clang/test/CXX/over/over.built/p23.cpp
+++ clang/test/CXX/over/over.built/p23.cpp
@@ -6,41 +6,41 @@
   f %= 3;  // expected-error {{invalid operands}}
   b %= 3;
   pi %= 3; // expected-error {{invalid operands}}
-  pt %= 3; // FIXME
+  pt %= 3; // expected-error {{invalid operands}}
   t %= 3;
 
   i &= 3;
   f &= 3;  // expected-error {{invalid operands}}
   b &= 3;
   pi &= 3; // expected-error {{invalid operands}}
-  pt &= 3; // FIXME
+  pt &= 3; // expected-error {{invalid operands}}
   t &= 3;
 
   i ^= 3;
   f ^= 3;  // expected-error {{invalid operands}}
   b ^= 3;
   pi ^= 3; // expected-error {{invalid operands}}
-  pt ^= 3; // FIXME
+  pt ^= 3; // expected-error {{inva

[PATCH] D108392: [OpenCL] Fix parsing of opencl-c.h in CL 3.0 with device-scope atomics enabled

2021-11-04 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added inline comments.



Comment at: clang/include/clang/Basic/OpenCLExtensions.def:114
+OPENCL_OPTIONALCOREFEATURE(__opencl_c_atomic_scope_device, false, 300, 
OCL_C_30)
+OPENCL_OPTIONALCOREFEATURE(__opencl_c_atomic_scope_all_devices, false, 300, 
OCL_C_30)
 OPENCL_OPTIONALCOREFEATURE(__opencl_c_subgroups, false, 300, OCL_C_30)

Oops, sorry I missed that. @Anastasia, I think this one is header only. We 
discussed that here: https://reviews.llvm.org/D103241. We should either extend 
//-cl-ext// for unknown features (finally) or use it //as 
-D__opencl_c_atomic_scope_all_devices //


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108392

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D112349#3109065 , 
@nextsilicon-itay-bookstein wrote:

> I'm referring you again to the start of my explanation (the first three 
> paragraphs); the object file format (ELF) literally cannot express the 
> semantics you're asking for. You're asking for it to support a symbol in a 
> special kind of undefined state: 
> ABC = "undefined, but becomes defined to the value of a different symbol XYZ 
> if it ever becomes defined".
>
> In other words, the logical type of **the value** of a symbol is either 
> **empty/undefined** or **offset-into-some-section**. It is never 
> **name-of-another-symbol**.
>
> That is, unless I'm completely missing some special-sauce in the 
> `Elf32_Sym`/`Elf64_Sym` documentation which allows for `st_value` to somehow 
> point at the name of a different undefined symbol (am I missing something? 
> can you point me at documentation that allows for this use-case?).

I don't know much about the ELF format... but this works today?  We can define 
a resolver in a different TU and it WORKS thanks to the linker?  So there is 
perhaps something?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

2021-11-04 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein added a comment.

I'm referring you again to the start of my explanation (the first three 
paragraphs); the object file format (ELF) literally cannot express the 
semantics you're asking for. You're asking for it to support a symbol in a 
special kind of undefined state: 
ABC = "undefined, but becomes defined to the value of a different symbol XYZ if 
it ever becomes defined".

In other words, the logical type of **the value** of a symbol is either 
**empty/undefined** or **offset-into-some-section**. It is never 
**name-of-another-symbol**.

That is, unless I'm completely missing some special-sauce in the 
`Elf32_Sym`/`Elf64_Sym` documentation which allows for `st_value` to somehow 
point at the name of a different undefined symbol (am I missing something? can 
you point me at documentation that allows for this use-case?).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349

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


[PATCH] D112492: [HIP] Do not use kernel handle for MSVC target

2021-11-04 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D112492#3101090 , @tra wrote:

> As phrased, the summary would likely be rather confusing for anyone other 
> than you and me.
>
>> Currently Visual Studio 2019 has a linker issue which causes linking error
>> when a template kernel is instantiated in different compilation units.
>
> It's not clear what exactly is the issue and what causes it.

Currently, the identical instantiation of a template kernel in different TU 
causes linking error about duplicate symbols on Windows.

In the beginning, I thought it was due to a bug in MSVC linker. However, 
further investigation shows that it is not a MSVC linker bug, but a bug of 
clang.

Basically, it is not sufficient to set linkonce_odr linkage to let MSVC linker 
merge symbols. The symbol needs to be in comdat sections. This is not required 
on Linux. However, it would be more consistent to always put kernel stubs and 
kernel handles with linkonce_odr linkage into comdat if the target supports it.

I will update this patch to fix the comdat for kernel stub and kernel handle.

>> On the other hand, it is unnecessary to prefix kernel stub for MSVC
>> target since the host and device compilation uses different mangling
>> ABI.
>
> This could use more details on why different mangling matters here. IIRC, on 
> Linux where both host and device use the same mangling and HIP needed a way 
> to tell apart the GPU-side kernels and their host-side stub. Different 
> mangling makes it a non-issue.
>
>> This patch let clang not emit kernel handle for MSVC target to work around 
>> the linker issue.
>
> Again, without the back-story the jump from linking error to mangling 
> differences to "let's not emit a handle" does not make much sense.
>
> I'd restructure it along the line of:
>
> - we emit host-side handles to match GPU-side kernels
> - the handles cause linking issues on windows because of X/Y/Z.
> - handles are not necessary on Windows, because of the different host/device 
> mangling
> - not generating the handles avoids the linking issue on Windows.
>
> This prompts the question -- should/could handle generation be improved 
> instead? Having identical behavior on all platforms would arguably be better 
> than a platform-specific workaround.

With the fix of comdat issue, we should be able to use a consistent kernel 
launching mechanism for Linux and Windows. Since the debugger requests kernel 
stub to have a different name than the kernel, we have to let the kernel stub 
and kernel handle have different names. That mechanism will stay unchanged.

I also found that MSVC name mangling currently does not add device_stub prefix 
to the mangled name of kernel stubs. I will update this patch to fix that.

With these changes, we should have consistent name mangling for kernel stubs 
and kernel launching mechanism on Linux and Windows.


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

https://reviews.llvm.org/D112492

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


[PATCH] D112903: [C++20] [Module] Fix front end crashes when trying to export a qualified entity which is already declared

2021-11-04 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7784-7785
   "because namespace %1 does not enclose namespace %2">;
+def err_invalid_declarator_in_export : Error<"cannot export %0 here "
+  "because it had be declared in %1.">;
 def err_invalid_declarator_global_scope : Error<

aaron.ballman wrote:
> ChuanqiXu wrote:
> > aaron.ballman wrote:
> > > aaron.ballman wrote:
> > > > I think this diagnostic text is more clear based on the standards text 
> > > > you cited. This would also come with a note diagnostic to point to the 
> > > > previous declaration.
> > > Given that this is not intended for p6 specifically, I think my 
> > > suggestion is incorrect. But I am also not certain your diagnostic is 
> > > either, but it's really hard to tell given where our current support is 
> > > for modules. All of the other compilers suggest that an unqualified id is 
> > > expected to be found, and I tend to agree -- there's no declaration there 
> > > *to* export, just the type specifier for a declaration. This makes me 
> > > think the issue is elsewhere and perhaps we shouldn't even be getting 
> > > into `diagnoseQualifiedDeclaration()`.
> > I think we need to touch `diagnoseQualifiedDeclaration()` after all. Since 
> > there is a potential risk of crashing in it. If we didn't fix it in 
> > `diagnoseQualifiedDeclaration()` and find other place  to fix the issue, I 
> > think it may crash potentially one day in the process of developing or we 
> > might ignore some paths to  diagnoseQualifiedDeclaration()`. It would be a 
> > disaster.
> > And you said "there's no declaration there *to* export". And I noticed that 
> > there is error/warning in `Sema::ParsedFreeStandingDeclSpec` which would 
> > emit this kind of error/warning. But as the title describes, it only works 
> > for free standing declaration, which is not the same with the issue in 
> > bug47715. And `diagnoseQualifiedDeclaration()` would handle the qualified 
> > redeclaration. So it looks a good place to me.
> > BTW, I found the current patch could handle [module.interface]/p6 partially 
> > for qualified redeclaration surprisingly. See the newly added test case for 
> > example.
> > Finally, given that we need to touch `diagnoseQualifiedDeclaration()` to 
> > fix the crash, I think the patch should be good and we could try to cover 
> > [module.interface]/p6 in successive patches. Do you think so?
> > I think we need to touch diagnoseQualifiedDeclaration() after all. Since 
> > there is a potential risk of crashing in it. 
> 
> My point is that we may have wanted to reject this code before ever needing 
> to call `diagnoseQualifiedDeclaration()` in the first place. aka, it might be 
> just as valid to assert we never see an `ExportDecl` here because the caller 
> should have already handled that case.
> 
> > And you said "there's no declaration there *to* export". And I noticed that 
> > there is error/warning in Sema::ParsedFreeStandingDeclSpec which would emit 
> > this kind of error/warning. But as the title describes, it only works for 
> > free standing declaration, which is not the same with the issue in bug47715.
> 
> The declaration is invalid in C++20 because it does not declare anything 
> (this is the same example with the export keywords removed): 
> https://godbolt.org/z/8zc9q7fno
> 
> Clang fails the first one because we don't yet implement P0634R3, but the 
> presence of the export keyword should not change diagnostic behavior here.
> 
> 
Agreed, 'export' is only applicable to namespace-scope declarations.  We should 
reject it applying to non-namepace-scope entities.


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

https://reviews.llvm.org/D112903

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


[PATCH] D112579: Allow non-variadic functions to be attributed with `__attribute__((format))`

2021-11-04 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

> Agreed. This should be checking the instantiations, so by that point, the 
> variadic template is really more like a fixed parameter list anyway.

FWIW, in my own mental model, there's a big semantic difference between 
(varargs functions, variadic templates) on the one hand and (non-template 
functions) on the other. In my experience, there's //nothing// you can do with 
a varargs ellipsis except forward it along as a `va_list`; and it's 
//uncommon// to do anything with a variadic parameter pack except forward it 
along via `std::forward`; but messing with fixed arguments is quite common. 
Technically, you can mess with a parameter pack too:

  void apple(const char *fmt, int x, int y) __attribute__((format(printf, 1, 
2))) {
  printf(fmt, double(x), double(y));
  }
  void banana(const char *fmt, auto... args) __attribute__((format(printf, 1, 
2))) {
  printf(fmt, double(args)...);
  }
  int main() {
  apple("%g %g", 17, 42);  // well-defined; shall we warn anyway? (My gut 
feeling is that this is relatively common)
  banana("%g %g", 17, 42);  // well-defined; shall we warn anyway? (My gut 
feeling is that this is extremely rare)
  }

This morning I am leaning in favor of this PR as written. If a programmer wants 
`apple`/`banana` to be callable like that, without any diagnostics, then their 
appropriate course of action is simply not to apply the 
`__attribute__((format(printf, 1, 2)))` annotation.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:4051
+def warn_gcc_requires_variadic_function : Warning<
+  "GCC requires functions with %0 attribute to be variadic">,
+  InGroup;

I'd say `with the %0 attribute` (add "the")



Comment at: clang/lib/AST/FormatString.cpp:325-329
+  // When using the format attribute with variadic templates in C++, you can
+  // receive an array that will necessarily decay to a pointer when passed to
+  // the final format consumer. Apply decay before type comparison.
+  if (C.getAsArrayType(argTy))
+argTy = C.getArrayDecayedType(argTy);

Also, function references will decay to function pointers.  I have no idea if 
you need to do anything special here to get the "right behavior" for function 
references.  But please add a (compile-only?) test case for the 
function-pointer codepath, just to prove it doesn't crash or anything. 



Comment at: clang/test/Sema/attr-format.cpp:5-7
+template
+void format(const char *fmt, Args &&... args) // expected-warning{{GCC 
requires functions with 'format' attribute to be variadic}}
+__attribute__((format(printf, 1, 2)));

Can we also do an example of a //member function// variadic template?
```
struct S {
  template
  void format(const char *fmt, Args&&... args)
__attribute__((format(printf, 2, 3)));
};
```
Also, I believe that this entire file should be removed from `Sema/` and 
combined into `SemaCXX/attr-format.cpp`.

I also notice that we have literally zero test coverage for cases where the 
format string is not the first argument to the function; but that 
can-and-should be addressed in a separate PR.



Comment at: clang/test/Sema/attr-format.cpp:14
+  format("bare string");
+  format("%s %s %u %d %i %p\n", "hello", s, 10u, x, y, &do_format);
+  format("bad format %s"); // expected-warning{{more '%' conversions than data 
arguments}}

Basically, add `, do_format` here.
(Aside: I'm surprised that Clang quietly lets you print a function pointer with 
`%p`. It'll work on sane architectures, but //in general// C and C++ don't 
require that function pointers even be the same size as `void*` — technically 
this should be UB or at least impl-defined behavior.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112579

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


[PATCH] D113148: Add new clang-tidy check for string_view(nullptr)

2021-11-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added reviewers: alexfh, njames93, hokein, whisperity.
aaron.ballman added a comment.
Herald added a subscriber: rnkovacs.

In D113148#3108960 , @Sockke wrote:

> In D113148#3108705 , @CJ-Johnson 
> wrote:
>
>> In D113148#3107897 , @Sockke wrote:
>>
>>> This seems to be an existing check. Have you compared it with 
>>> **bugprone-string-constructor**?
>>
>> Thanks for the suggestion! From what I can tell, bugprone-string-constructor 
>> check only has warnings and does not provide fixes in most cases. The goal 
>> of bugprone-stringview-nullptr is to robustly enumerate the many cases that 
>> it cares about and provide fixes. For that reason, I think making it a 
>> separate check is best.
>
> Yes, But i think that improving existing check is the best way. Because 
> improving bugprone-string-construct in a new check may make developers 
> confused and cause redundant overlap.
> Let's see if @aaron.ballman or @whisperity has any comments?

Generally speaking, we prefer to improve the existing checks. I think 
`bugprone-string-constructor` would probably be a better place for the 
constructor-related functionality. But that still means we don't have a good 
place for things like the assignment and comparison functionality, and it seems 
more useful to keep all of the `string_view`-with-`nullptr` logic in one place. 
That said, we should be careful we're not too onerous when users enable all 
`bugprone` checks together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113148

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


[PATCH] D113118: [clang][AST] Check context of record in structural equivalence.

2021-11-04 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

I very much like the code.
L1364 is uncovered according to my coverage results.




Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1360-1364
+// Special case: We allow a struct defined in a function to be equivalent
+// with a similar struct defined outside of a function.
+if ((DC1->isFunctionOrMethod() && DC2->isTranslationUnit()) ||
+(DC2->isFunctionOrMethod() && DC1->isTranslationUnit()))
+  return true;

Shouldn't you also check the name as well?



Comment at: clang/lib/AST/ASTStructuralEquivalence.cpp:1379
+
+DC1 = DC1->getParent()->getNonTransparentContext();
+DC2 = DC2->getParent()->getNonTransparentContext();

So, the previous `DC1->isTranslationUnit()` guards the `DC1->getParent()` to 
never be `NULL`; same for `DC2`.
Pretty neat.



Comment at: clang/unittests/AST/StructuralEquivalenceTest.cpp:982-988
+TEST_F(StructuralEquivalenceRecordContextTest, NamespaceNamedVsInline) {
+  auto Decls = makeDecls(
+  "namespace A { namespace A { class X; } }",
+  "namespace A { inline namespace A { class X; } }", Lang_CXX17,
+  cxxRecordDecl());
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}

The outer-most namespace could also be //inline//.
I'd love to see a test about that as well.



Comment at: clang/unittests/AST/StructuralEquivalenceTest.cpp:1004-1009
+TEST_F(StructuralEquivalenceRecordContextTest, TransparentContextNE) {
+  auto Decls = makeDecls("extern \"C\" { class X; }",
+"namespace { class X; }", Lang_CXX17,
+cxxRecordDecl());
+  EXPECT_FALSE(testStructuralMatch(Decls));
+}

`extern "C"` might be nested within other namespaces.
Probably worth testing that as well.



Comment at: clang/unittests/AST/StructuralEquivalenceTest.cpp:1025-1032
+TEST_F(StructuralEquivalenceTest, StructDefinitionInPrototype) {
+  auto Decls = makeDecls(
+  "struct Param { int a; }; void f(struct Param *p);",
+  "void f(struct Param { int a; } *p);", Lang_C89,
+  parmVarDecl(hasName("p")));
+  EXPECT_TRUE(testStructuralMatch(Decls));
+}

Please, also test if the name of the structs is mismatched.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113118

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


[PATCH] D112041: [InferAddressSpaces] Support assumed addrspaces from addrspace predicates.

2021-11-04 Thread Michael Liao via Phabricator via cfe-commits
hliao marked an inline comment as done.
hliao added inline comments.



Comment at: llvm/lib/Transforms/Scalar/InferAddressSpaces.cpp:196
   void inferAddressSpaces(ArrayRef Postorder,
-  ValueToAddrSpaceMapTy *InferredAddrSpace) const;
+  ValueToAddrSpaceMapTy *InferredAddrSpace,
+  PredicatedAddrSpaceMapTy &PredicatedAS) const;

tra wrote:
> hliao wrote:
> > tra wrote:
> > > I think this could've been a reference, too.
> > yeah, but we should address that in another change.
> You're already changing function signatures.It would be reasonable to 
> incorporate this cleanup, too.
revised in the latest patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112041

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


  1   2   >