[PATCH] D72841: [RFC] Add support for pragma float_control, to control precision and exception behavior at the source level

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

I don't see tests for correctness of the pragma stack (`pragma 
float_control(... push)`, `pragma float_control(pop)`). Can you add them?




Comment at: clang/lib/Parse/ParsePragma.cpp:2537
+if (!Actions.CurContext->isTranslationUnit()) {
+//FIXME this seems to be the wrong way to check file-scope
+//since the token immediately following a function definition

mibintc wrote:
> sepavloff wrote:
> > Probably using `Actions.getCurScope()` can help to recognize file scope.
> Thanks for the suggestion, I (Actions.getCurScope()==0) to test for file 
> scope, but that didn't work either. I put a workaround into the test case 
> CodeGen/fp-floatcontrol-pragma.cpp, the forward class declaration 
> ResetTUScope. If the reset is there, then the pragma is recognized to be at 
> file scope. 
`Scope` always exists, so the correct way to check if it refers to translation 
unit is something like: `Actions.getCurScope()->getParent() == nullptr`.



Comment at: clang/lib/Sema/SemaExpr.cpp:13129
 if (FunctionDecl *F = dyn_cast(CurContext)) {
+  // If the expression occurs inside an internal global_var_init_function
+  // then the FunctionDecl is not availble

mibintc wrote:
> sepavloff wrote:
> > mibintc wrote:
> > > sepavloff wrote:
> > > > The standard says that static initializers execute in default FP mode.
> > > > The standard says ...
> > > Are you sure about this one?  Can you please provide the standards 
> > > reference so I can study it?
> > >> The standard says ...
> > > Are you sure about this one? Can you please provide the standards 
> > > reference so I can study it?
> > 
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, F.8.5:
> > ```
> > ... All computation for initialization of objects that have static or 
> > thread storage duration is done (as if) at translation time.
> > ```
> > F.8.2:
> > ```
> > During translation the IEC 60559 default modes are in effect:
> > — The rounding direction mode is rounding to nearest.
> > — The rounding precision mode (if supported) is set so that results are not 
> > shortened.
> > — Trapping or stopping (if supported) is disabled on all floating-point 
> > exceptions.
> > ```
> Thanks for the pointer to the reference. The desired semantics of the pragma 
> may differ from the standard. For example I tried this test case with the 
> fp_contract pragma, and the pragma does modify the semantics of the floating 
> point expressions in the initializer.  So this issue is still a problem in 
> this patch. 
> 
> // RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
> 
> #pragma STDC FP_CONTRACT ON
> float y();
> float d();
> class ON {
> float z = y() * 1 + d();
> // CHECK-LABEL: define {{.*}} void @_ZN2ONC2Ev{{.*}}
> //CHECK: llvm.fmuladd.f32{{.*}}
> };
> ON on;
> 
> #pragma STDC FP_CONTRACT OFF
> class OFF {
> float w = y() * 1 + d();
> // CHECK-LABEL: define {{.*}} void @_ZN3OFFC2Ev{{.*}}
> //CHECK: fmul float
> };
> OFF off;
> 
This is an interesting example. However there is no contradiction with the 
standard. The standard speaks about floating point environment, which on most 
processors are represented by bits of some register(s). The pragma `STDC 
FP_CONTRACT` does not refer to the FPEnv, but is an instruction to the compiler 
how to generate code, so it affects code generation even in global var 
initializers.

What `TBD` here means? Do you think this code may be somehow improved?



Comment at: clang/test/CodeGen/fp-floatcontrol-pragma.cpp:2
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -fsyntax-only -verify -DCHECK_ERROR %s
+

You need to extract the tests that check error generation from this file and 
put them into `clang/test/Parser`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[PATCH] D72829: Implement -fsemantic-interposition

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D72829#1831017 , @serge-sans-paille 
wrote:

> > Linkages which were not interposable before and can be interposable now: 
> > available_externally, linkonce_odr, weak_odr, external, and appending.
>
> @MaskRay I understand the motivation behind that sentence, but do we want 
> that change to be non-conditional, i.e. not guarded by 
> -fsemantic-interposition ?


I tried modifying `GlobalValue::maybeSetDsoLocal`: `setDSOLocal(true)` for 
ExternalLinkage. Unfortunately that will break 1337 tests. If not so many tests 
need fixing, I wish we can place `getParent() && 
getParent()->getSemanticInterposition()` logic in `maybeSetDsoLocal` and 
simplify `isInterposable`.

  if (!isInterposableLinkage(getLinkage()))
return false;
  - return getParent() && getParent()->getSemanticInterposition() && 
!isDSOLocal();
  + return !isDSOLocal(); 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72829



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

[PATCH] D72703: Add a warning, flags and pragmas to limit the number of pre-processor tokens in a translation unit

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

I just want to say that finding the correlation between token count and compile 
time is a bit of a breakthrough! Could you expose a flag for printing token 
count so users can run their own analysis? Or does that already exist in 
baseline clang? It's easier to set a maximum for a codebase if the distribution 
is known.

Thanks!


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

https://reviews.llvm.org/D72703



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

[PATCH] D73090: [clang-tidy] Fix PR#44528 'modernize-use-using and enums'

[Karasev Nikita via Phabricator via cfe-commits]

f00kat updated this revision to Diff 239491.
f00kat added a comment.

Add new line in the end of file checkers/modernize-use-using.cpp


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

https://reviews.llvm.org/D73090

Files:
  clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp


Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
@@ -267,3 +267,7 @@
 // CHECK-MESSAGES: :[[@LINE-2]]:30: warning: use 'using' instead of 'typedef'
 // CHECK-FIXES: using R_t = struct { int a; };
 // CHECK-FIXES-NEXT: using R_p = R_t*;
+
+typedef enum { ea, eb } EnumT;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
+// CHECK-FIXES: using EnumT = enum { ea, eb };
Index: clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
===
--- clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
+++ clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
@@ -23,7 +23,7 @@
 
   const bool IgnoreMacros;
   SourceLocation LastReplacementEnd;
-  SourceRange LastCxxDeclRange;
+  SourceRange LastTagDeclRange;
   std::string FirstTypedefType;
   std::string FirstTypedefName;
 
Index: clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
@@ -25,18 +25,18 @@
 return;
   Finder->addMatcher(typedefDecl(unless(isInstantiated())).bind("typedef"),
  this);
-  // This matcher used to find structs defined in source code within typedefs.
+  // This matcher`s used to find structs/enums defined in source code within 
typedefs.
   // They appear in the AST just *prior* to the typedefs.
-  Finder->addMatcher(cxxRecordDecl(unless(isImplicit())).bind("struct"), this);
+  Finder->addMatcher(cxxRecordDecl(unless(isImplicit())).bind("tagdecl"), 
this);
+  Finder->addMatcher(enumDecl(unless(isImplicit())).bind("tagdecl"), this);
 }
 
 void UseUsingCheck::check(const MatchFinder::MatchResult ) {
   // Match CXXRecordDecl only to store the range of the last non-implicit full
   // declaration, to later check whether it's within the typdef itself.
-  const auto *MatchedCxxRecordDecl =
-  Result.Nodes.getNodeAs("struct");
-  if (MatchedCxxRecordDecl) {
-LastCxxDeclRange = MatchedCxxRecordDecl->getSourceRange();
+  const auto *MatchedTagDecl = Result.Nodes.getNodeAs("tagdecl");
+  if (MatchedTagDecl) {
+LastTagDeclRange = MatchedTagDecl->getSourceRange();
 return;
   }
 
@@ -96,10 +96,10 @@
   auto Diag = diag(ReplaceRange.getBegin(), UseUsingWarning);
 
   // If typedef contains a full struct/class declaration, extract its full 
text.
-  if (LastCxxDeclRange.isValid() && 
ReplaceRange.fullyContains(LastCxxDeclRange)) {
+  if (LastTagDeclRange.isValid() && 
ReplaceRange.fullyContains(LastTagDeclRange)) {
 bool Invalid;
 Type =
-Lexer::getSourceText(CharSourceRange::getTokenRange(LastCxxDeclRange),
+Lexer::getSourceText(CharSourceRange::getTokenRange(LastTagDeclRange),
  *Result.SourceManager, getLangOpts(), );
 if (Invalid)
   return;


Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
@@ -267,3 +267,7 @@
 // CHECK-MESSAGES: :[[@LINE-2]]:30: warning: use 'using' instead of 'typedef'
 // CHECK-FIXES: using R_t = struct { int a; };
 // CHECK-FIXES-NEXT: using R_p = R_t*;
+
+typedef enum { ea, eb } EnumT;
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
+// CHECK-FIXES: using EnumT = enum { ea, eb };
Index: clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
===
--- clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
+++ clang-tools-extra/clang-tidy/modernize/UseUsingCheck.h
@@ -23,7 +23,7 @@
 
   const bool IgnoreMacros;
   SourceLocation LastReplacementEnd;
-  SourceRange LastCxxDeclRange;
+  SourceRange LastTagDeclRange;
   std::string FirstTypedefType;
   std::string FirstTypedefName;
 
Index: clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
===
--- clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
+++ clang-tools-extra/clang-tidy/modernize/UseUsingCheck.cpp
@@ -25,18 +25,18 @@
 return;
   

[clang] b54aa05 - Update clang-interpreter example to incorporate changes in ce2207abaf9.

[Lang Hames via cfe-commits]

Author: Lang Hames
Date: 2020-01-21T22:00:50-08:00
New Revision: b54aa053d3aeeab0cdaecb6286419138b7da5ef4

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

LOG: Update clang-interpreter example to incorporate changes in ce2207abaf9.

Added: 


Modified: 
clang/examples/clang-interpreter/main.cpp

Removed: 




diff  --git a/clang/examples/clang-interpreter/main.cpp 
b/clang/examples/clang-interpreter/main.cpp
index db6b0cce4fd1..c0aae4722306 100644
--- a/clang/examples/clang-interpreter/main.cpp
+++ b/clang/examples/clang-interpreter/main.cpp
@@ -56,7 +56,8 @@ class SimpleJIT {
   MangleAndInterner Mangle{ES, DL};
   JITDylib {ES.createJITDylib("")};
   RTDyldObjectLinkingLayer ObjectLayer{ES, createMemMgr};
-  IRCompileLayer CompileLayer{ES, ObjectLayer, SimpleCompiler(*TM)};
+  IRCompileLayer CompileLayer{ES, ObjectLayer,
+  std::make_unique(*TM)};
 
   static std::unique_ptr createMemMgr() {
 return std::make_unique();



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

[PATCH] D68520: [cmake] Fix clang builds with BUILD_SHARED=ON and CLANG_LINK_CLANG_DYLIB=ON

[Michał Górny via Phabricator via cfe-commits]

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

Well, it looks correct to me. Not sure if it's the best approach but it can be 
refined in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68520



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

[PATCH] D68520: [cmake] Fix clang builds with BUILD_SHARED=ON and CLANG_LINK_CLANG_DYLIB=ON

[Tom Stellard via Phabricator via cfe-commits]

tstellar added a comment.

Ping. This bug is preventing upstream projects from using libclang-cpp.so, 
since building with -DENABLE_SHARED=ON is still common.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68520



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

[clang] c38e425 - [clang][IFS][test] Temporary work around for in-process cc1 ASAN issues.

[Puyan Lotfi via cfe-commits]

Author: Puyan Lotfi
Date: 2020-01-21T22:56:20-05:00
New Revision: c38e42527b21acee8d01a016d5bfa2fb83202e29

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

LOG: [clang][IFS][test] Temporary work around for in-process cc1 ASAN issues.

When using in-process cc1, the Clang Interface Stubs pipeline setup
exposes an ASAN bug. I am still investigating this issue but want to
green the bots for now. I don't think this is a huge issue since the
Clang Interface Stubs Driver setup code is the only code path that sets
up such a pipeline (ie N cc1's for N c files followed by another N cc1's
for to generate stub files for the same N c files).

This issue is being discussed in https://reviews.llvm.org/D69825.
If a resolution is not found soon, a bugzilla filling will be in order.

Added: 


Modified: 
clang/test/InterfaceStubs/driver-test.c
clang/test/InterfaceStubs/driver-test2.c

Removed: 




diff  --git a/clang/test/InterfaceStubs/driver-test.c 
b/clang/test/InterfaceStubs/driver-test.c
index 9ca5577a5c20..894d896bb219 100644
--- a/clang/test/InterfaceStubs/driver-test.c
+++ b/clang/test/InterfaceStubs/driver-test.c
@@ -1,8 +1,17 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: shell
 
+// NOTE: -fno-integrated-cc1 has been added to work around an ASAN failure
+//   caused by in-process cc1 invocation. Clang InterfaceStubs is not the
+//   culprit, but Clang Interface Stubs' Driver pipeline setup uncovers an
+//   existing ASAN issue when invoking multiple normal cc1 jobs along with
+//   multiple Clang Interface Stubs cc1 jobs together.
+//   There is currently a discussion of this going on at:
+// https://reviews.llvm.org/D69825
 // RUN: mkdir -p %t; cd %t
-// RUN: %clang -target x86_64-unknown-linux-gnu -x c -S -emit-interface-stubs 
%s %S/object.c %S/weak.cpp && \
+// RUN: %clang -target x86_64-unknown-linux-gnu -x c -S \
+// RUN:   -fno-integrated-cc1 \
+// RUN: -emit-interface-stubs %s %S/object.c %S/weak.cpp && \
 // RUN: llvm-nm %t/a.out.ifso 2>&1 | FileCheck --check-prefix=CHECK-IFS %s
 
 // CHECK-IFS-DAG: data

diff  --git a/clang/test/InterfaceStubs/driver-test2.c 
b/clang/test/InterfaceStubs/driver-test2.c
index c3a3b31b212d..905b27922264 100644
--- a/clang/test/InterfaceStubs/driver-test2.c
+++ b/clang/test/InterfaceStubs/driver-test2.c
@@ -1,10 +1,19 @@
 // REQUIRES: x86-registered-target
 // REQUIRES: shell
 
+// NOTE: -fno-integrated-cc1 has been added to work around an ASAN failure
+//   caused by in-process cc1 invocation. Clang InterfaceStubs is not the
+//   culprit, but Clang Interface Stubs' Driver pipeline setup uncovers an
+//   existing ASAN issue when invoking multiple normal cc1 jobs along with
+//   multiple Clang Interface Stubs cc1 jobs together.
+//   There is currently a discussion of this going on at:
+// https://reviews.llvm.org/D69825
 // RUN: mkdir -p %t; cd %t
 // RUN: %clang -target x86_64-unknown-linux-gnu -c -emit-interface-stubs \
+// RUN:   -fno-integrated-cc1 \
 // RUN:   %s %S/object.c %S/weak.cpp
 // RUN: %clang -emit-interface-stubs -emit-merged-ifs \
+// RUN:   -fno-integrated-cc1 \
 // RUN:   %t/driver-test2.o %t/object.o %t/weak.o -S -o - 2>&1 | FileCheck %s
 
 // CHECK-DAG: data



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

[PATCH] D73156: [clang] Build clang-shlib on mingw

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

merge_guards_bot added a comment.

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

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

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

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



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73156



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

[PATCH] D73156: [clang] Build clang-shlib on mingw

[Valentin Churavy via Phabricator via cfe-commits]

vchuravy added a comment.

Some additional context. We [Julia] is cross-compiling LLVM from Linux to 
mingw32
as part of an automatic buildsystem for our binary dependencies. The 
corresponding PR is https://github.com/JuliaPackaging/Yggdrasil/pull/417


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73156



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

[PATCH] D65042: [Concept] Placeholder constraints and abbreviated templates

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added a comment.

Hey Saar, I have temporarily reverted this because it broke the LLDB bots. 
Please run the LLDB test suite when you make changes to the AST importer & keep 
an eye on the bots when you re-land this. Thanks!

  commit 62e4b501ab3bc4c5815a179fdd2c4b49574506c1 (HEAD -> master, 
origin/master)
  Author: Jonas Devlieghere 
  Date:   Tue Jan 21 19:01:38 2020 -0800
  
  Revert "[Concepts] Placeholder constraints and abbreviated templates"
  
  This temporarily reverts commit e03ead6771fc97b11cb0c94b7f023142184ad25f
  because it breaks LLDB.
  
  http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/3356
  http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12872
  http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/6407/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65042



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

[PATCH] D72747: [objc_direct] Allow for direct messages be sent to `self` when it is a Class

[Pierre Habouzit via Phabricator via cfe-commits]

MadCoder updated this revision to Diff 239477.
MadCoder added a comment.

fixed @ahatanak feedback


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

https://reviews.llvm.org/D72747

Files:
  clang/lib/Sema/SemaExprObjC.cpp
  clang/test/SemaObjC/method-direct-arc.m


Index: clang/test/SemaObjC/method-direct-arc.m
===
--- /dev/null
+++ clang/test/SemaObjC/method-direct-arc.m
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -fobjc-arc -fsyntax-only -verify -Wselector-type-mismatch %s
+
+extern Class object_getClass(id);
+
+__attribute__((objc_root_class))
+@interface Root
+- (Class)class;
++ (void)directMethod __attribute__((objc_direct)); // expected-note {{direct 
method 'directMethod' declared here}}
++ (void)anotherDirectMethod __attribute__((objc_direct));
+@end
+
+@implementation Root
+- (Class)class
+{
+  return object_getClass(self);
+}
++ (void)directMethod {
+}
++ (void)anotherDirectMethod {
+  [self directMethod]; // this should not warn
+}
++ (void)regularMethod {
+  [self directMethod];// this should not warn
+  [self anotherDirectMethod]; // this should not warn
+}
+- (void)regularInstanceMethod {
+  [[self class] directMethod]; // expected-error {{messaging a Class with a 
method that is possibly direct}}
+}
+@end
+
+@interface Sub : Root
+@end
+
+@implementation Sub
++ (void)foo {
+  [self directMethod]; // this should not warn
+}
+@end
+
+__attribute__((objc_root_class))
+@interface Other
+@end
+
+@implementation Other
++ (void)bar {
+  [self directMethod]; // expected-error {{no known class method for selector 
'directMethod'}}
+}
+@end
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -3012,7 +3012,11 @@
   << Method->getDeclName();
 }
 
-if (ReceiverType->isObjCClassType() && !isImplicit) {
+// Under ARC, self can't be assigned, and doing a direct call to `self`
+// when it's a Class is hence safe.  For other cases, we can't trust `self`
+// is what we think it is, so we reject it.
+if (ReceiverType->isObjCClassType() && !isImplicit &&
+!(Receiver->isObjCSelfExpr() && getLangOpts().ObjCAutoRefCount)) {
   Diag(Receiver->getExprLoc(),
diag::err_messaging_class_with_direct_method);
   Diag(Method->getLocation(), diag::note_direct_method_declared_at)


Index: clang/test/SemaObjC/method-direct-arc.m
===
--- /dev/null
+++ clang/test/SemaObjC/method-direct-arc.m
@@ -0,0 +1,48 @@
+// RUN: %clang_cc1 -fobjc-arc -fsyntax-only -verify -Wselector-type-mismatch %s
+
+extern Class object_getClass(id);
+
+__attribute__((objc_root_class))
+@interface Root
+- (Class)class;
++ (void)directMethod __attribute__((objc_direct)); // expected-note {{direct method 'directMethod' declared here}}
++ (void)anotherDirectMethod __attribute__((objc_direct));
+@end
+
+@implementation Root
+- (Class)class
+{
+  return object_getClass(self);
+}
++ (void)directMethod {
+}
++ (void)anotherDirectMethod {
+  [self directMethod]; // this should not warn
+}
++ (void)regularMethod {
+  [self directMethod];// this should not warn
+  [self anotherDirectMethod]; // this should not warn
+}
+- (void)regularInstanceMethod {
+  [[self class] directMethod]; // expected-error {{messaging a Class with a method that is possibly direct}}
+}
+@end
+
+@interface Sub : Root
+@end
+
+@implementation Sub
++ (void)foo {
+  [self directMethod]; // this should not warn
+}
+@end
+
+__attribute__((objc_root_class))
+@interface Other
+@end
+
+@implementation Other
++ (void)bar {
+  [self directMethod]; // expected-error {{no known class method for selector 'directMethod'}}
+}
+@end
Index: clang/lib/Sema/SemaExprObjC.cpp
===
--- clang/lib/Sema/SemaExprObjC.cpp
+++ clang/lib/Sema/SemaExprObjC.cpp
@@ -3012,7 +3012,11 @@
   << Method->getDeclName();
 }
 
-if (ReceiverType->isObjCClassType() && !isImplicit) {
+// Under ARC, self can't be assigned, and doing a direct call to `self`
+// when it's a Class is hence safe.  For other cases, we can't trust `self`
+// is what we think it is, so we reject it.
+if (ReceiverType->isObjCClassType() && !isImplicit &&
+!(Receiver->isObjCSelfExpr() && getLangOpts().ObjCAutoRefCount)) {
   Diag(Receiver->getExprLoc(),
diag::err_messaging_class_with_direct_method);
   Diag(Method->getLocation(), diag::note_direct_method_declared_at)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73156: [clang] Build clang-shlib on mingw

[Valentin Churavy via Phabricator via cfe-commits]

vchuravy created this revision.
Herald added subscribers: cfe-commits, mstorsjo, mgorny.
Herald added a project: clang.
vchuravy added a reviewer: tstellar.
vchuravy added a comment.

Some additional context. We [Julia] is cross-compiling LLVM from Linux to 
mingw32
as part of an automatic buildsystem for our binary dependencies. The 
corresponding PR is https://github.com/JuliaPackaging/Yggdrasil/pull/417


Currently we exclude the libclang-cpp cmake files
on any non-unix platform, this excludes mingw32.

I suspect that the goal was to exclude MSVC only.
For the LLVM shlib we throw an error if someone tries
to build the shared library, whereas I stuck to the pattern
here that a misconfiguration causes an early return.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73156

Files:
  clang/tools/CMakeLists.txt
  clang/tools/clang-shlib/CMakeLists.txt


Index: clang/tools/clang-shlib/CMakeLists.txt
===
--- clang/tools/clang-shlib/CMakeLists.txt
+++ clang/tools/clang-shlib/CMakeLists.txt
@@ -3,6 +3,11 @@
   return()
 endif()
 
+# Building libclang-cpp.so may not work on MSVC
+if (MSVC)
+  return()
+endif()
+
 get_property(clang_libs GLOBAL PROPERTY CLANG_STATIC_LIBS)
 
 foreach (lib ${clang_libs})
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,9 +15,7 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX)
-  add_clang_subdirectory(clang-shlib)
-endif()
+add_clang_subdirectory(clang-shlib)
 
 if(CLANG_ENABLE_ARCMT)
   add_clang_subdirectory(arcmt-test)


Index: clang/tools/clang-shlib/CMakeLists.txt
===
--- clang/tools/clang-shlib/CMakeLists.txt
+++ clang/tools/clang-shlib/CMakeLists.txt
@@ -3,6 +3,11 @@
   return()
 endif()
 
+# Building libclang-cpp.so may not work on MSVC
+if (MSVC)
+  return()
+endif()
+
 get_property(clang_libs GLOBAL PROPERTY CLANG_STATIC_LIBS)
 
 foreach (lib ${clang_libs})
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,9 +15,7 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX)
-  add_clang_subdirectory(clang-shlib)
-endif()
+add_clang_subdirectory(clang-shlib)
 
 if(CLANG_ENABLE_ARCMT)
   add_clang_subdirectory(arcmt-test)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added a comment.

In D72552#1832875 , @JDevlieghere 
wrote:

> It looks like the concept changes broke the debugger (quite spectacularly 
> actually):
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/3356
>  http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12872
>  http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/6407/
>
> I'm rebuilding locally to see if I can reproduce


Most likely because of https://reviews.llvm.org/D65042 rather than this change, 
I see you made changes to the AST importer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552



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

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added a comment.

It looks like the concept changes broke the debugger (quite spectacularly 
actually):

http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/3356
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/12872
http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/6407/

I'm rebuilding locally to see if I can reproduce


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552



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

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

jdoerfert wrote:
> hfinkel wrote:
> > jdoerfert wrote:
> > > erichkeane wrote:
> > > > jdoerfert wrote:
> > > > > erichkeane wrote:
> > > > > > I thought we had this stored somewhere else?  We probably should 
> > > > > > have this be a constant somewhere in the frontend.  I THINK I 
> > > > > > remember doing a review where I pulled this value into clang 
> > > > > > somewhere...
> > > > > That was D72998, and I don't think Clang is the right place for this 
> > > > > constant. It is a property of the llvm alignment attribute and it 
> > > > > should live there. Thus, llvm/include/Attributes.h or some similar 
> > > > > place. Can't we "fix" the linker error by making it a constexpr 
> > > > > global or are the errors because of other file content? If the 
> > > > > latter, we could go with a llvm/include/magic_constants.h ;)
> > > > The one I was thinking of was this one: https://reviews.llvm.org/D68824
> > > > 
> > > > I don't remember what we came up with on the linking issue.  It would 
> > > > be really nice if it was just something included from LLVM, but I think 
> > > > SEMA typically doesn't include stuff from LLVM either.
> > > I'm not too happy with the duplication of the constant but defining it 
> > > once in clang is certainly better than having it in N places. For OpenMP 
> > > we look into LLVM during SEMA and here there is an argument to be made 
> > > that we should as well. I imagine more cases would pop up over time.
> > > 
> > > FWIW, if we allow to include LLVM headers, e.g., from IR or Frontend, we 
> > > could still have a wrapper in SEMA to get the information so it doesn't 
> > > expose the llvm:: namespace at the use sides (if that helps).
> > > For OpenMP we look into LLVM during SEMA 
> > 
> > How do we do that?
> > 
> > There's certainly an interesting philosophical issue around whether changes 
> > in LLVM should directly manifest as Clang behavioral changes, especially in 
> > -fsyntax-only. The answer to this question might be different for 
> > extensions vs. core language features (although alignment restrictions 
> > might implicate both). AFAIKT, historically , our answer has been to insist 
> > on separation.
> > > For OpenMP we look into LLVM during SEMA
> > How do we do that?
> 
> I was referring to code like this 
> https://reviews.llvm.org/D71830#C1739755NL11085 
> which is in CodeGen right now but has to move to SemaOverload. The code is 
> completely reusable between Clang and Flang so I put it in 
> lib/Frontend/OpenMP and I think that is the right place for it.
> 
> > There's certainly an interesting philosophical issue around whether changes 
> > in LLVM should directly manifest as Clang behavioral changes, especially in 
> > -fsyntax-only. The answer to this question might be different for 
> > extensions vs. core language features (although alignment restrictions 
> > might implicate both). AFAIKT, historically , our answer has been to insist 
> > on separation.
> 
> 
> I get that in a general sense. For the problem at hand, and as far as I 
> known, the restriction stems only from the LLVM-IR restriction, correct? If 
> so, what is the argument for separation? I mean, a change of the value in 
> LLVM might directly impact Clang behavior.
> 
> I could also see us clamping the alignment during codegen. While that might 
> have other problems they seem less practical to me.
> 
> 
> 
> 
> I was referring to code like this 
> https://reviews.llvm.org/D71830#C1739755NL11085
> which is in CodeGen right now but has to move to SemaOverload. The code is 
> completely reusable between Clang and Flang so I put it in 
> lib/Frontend/OpenMP and I think that is the right place for it.

Fair, but that's a library designed to be a home for cross-language frontend 
components. The variant-selection logic to which you're referring, itself, does 
not actually need to link to LLVM's IR library, correct?

> I get that in a general sense. For the problem at hand, and as far as I 
> known, the restriction stems only from the LLVM-IR restriction, correct? If 
> so, what is the argument for separation? I mean, a change of the value in 
> LLVM might directly impact Clang behavior.

Yes, I believe that the restriction is necessary because of an underlying LLVM 
IR restriction. From my perspective, your argument is perfectly rational. Clang 
only supports code generation using LLVM IR, and a restriction that comes from 
LLVM should be directly tied to the underlying LLVM threshold regardless of 
where it is surfaced. We have, however, avoided a linking dependence (I 
believe, primarily, to help the load times and file sizes of tools based on 
Clang which don't otherwise need to link to the LLVM IR 

[PATCH] D73155: [Concepts] Implement P1616R1 - Using unconstrained template template parameters with constrained templates

[Saar Raz via Phabricator via cfe-commits]

saar.raz created this revision.
saar.raz added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Allow unconstrained template template parameters to accept constrainted 
templates as arguments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73155

Files:
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp


Index: clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
===
--- clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
+++ clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
@@ -7,9 +7,9 @@
 // expected-note@-1{{similar constraint expressions not considered equivalent}}
 template class P> struct S1 { }; // expected-note 2{{'P' declared 
here}}
 
-template struct X { }; // expected-note{{'X' declared here}}
+template struct X { };
 
-template struct Y { }; // expected-note 2{{'Y' declared here}}
+template struct Y { }; // expected-note{{'Y' declared here}}
 template struct Z { };
 template struct W { }; // expected-note{{'W' declared here}}
 
@@ -18,10 +18,10 @@
 S1 s13;
 S1 s14; // expected-error{{template template argument 'W' is more 
constrained than template template parameter 'P'}}
 
-template class P> struct S2 { }; // expected-note 2{{'P' 
declared here}}
+template class P> struct S2 { };
 
-S2 s21; // expected-error{{template template argument 'X' is more 
constrained than template template parameter 'P'}}
-S2 s22; // expected-error{{template template argument 'Y' is more 
constrained than template template parameter 'P'}}
+S2 s21;
+S2 s22;
 S2 s23;
 
 template  class C>
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -7164,6 +7164,11 @@
   //   [temp.constr.order].
   SmallVector ParamsAC, TemplateAC;
   Params->getAssociatedConstraints(ParamsAC);
+  // C++2a[temp.arg.template]p3
+  //   [...] In this comparison, if P is unconstrained, the constraints on 
A
+  //   are not considered.
+  if (ParamsAC.empty())
+return false;
   Template->getAssociatedConstraints(TemplateAC);
   bool IsParamAtLeastAsConstrained;
   if (IsAtLeastAsConstrained(Param, ParamsAC, Template, TemplateAC,


Index: clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
===
--- clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
+++ clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
@@ -7,9 +7,9 @@
 // expected-note@-1{{similar constraint expressions not considered equivalent}}
 template class P> struct S1 { }; // expected-note 2{{'P' declared here}}
 
-template struct X { }; // expected-note{{'X' declared here}}
+template struct X { };
 
-template struct Y { }; // expected-note 2{{'Y' declared here}}
+template struct Y { }; // expected-note{{'Y' declared here}}
 template struct Z { };
 template struct W { }; // expected-note{{'W' declared here}}
 
@@ -18,10 +18,10 @@
 S1 s13;
 S1 s14; // expected-error{{template template argument 'W' is more constrained than template template parameter 'P'}}
 
-template class P> struct S2 { }; // expected-note 2{{'P' declared here}}
+template class P> struct S2 { };
 
-S2 s21; // expected-error{{template template argument 'X' is more constrained than template template parameter 'P'}}
-S2 s22; // expected-error{{template template argument 'Y' is more constrained than template template parameter 'P'}}
+S2 s21;
+S2 s22;
 S2 s23;
 
 template  class C>
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -7164,6 +7164,11 @@
   //   [temp.constr.order].
   SmallVector ParamsAC, TemplateAC;
   Params->getAssociatedConstraints(ParamsAC);
+  // C++2a[temp.arg.template]p3
+  //   [...] In this comparison, if P is unconstrained, the constraints on A
+  //   are not considered.
+  if (ParamsAC.empty())
+return false;
   Template->getAssociatedConstraints(TemplateAC);
   bool IsParamAtLeastAsConstrained;
   if (IsAtLeastAsConstrained(Param, ParamsAC, Template, TemplateAC,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72100: Allow matching "any file" in `VerifyDiagnosticConsumer`.

[Jan Korous via Phabricator via cfe-commits]

jkorous added inline comments.



Comment at: clang/test/Frontend/verify-any-file.c:1
+// RUN: %clang_cc1 -verify %s 2>&1
+

I feel that we should test the output with FileCheck to make it more robust.
Seems like other tests for `-verify` do that. For example here:
https://github.com/llvm/llvm-project/blob/master/clang/test/Frontend/verify-fatal.c



Comment at: clang/test/Frontend/verify-any-file.c:6
+#include "verify-any-file.h"
+// expected-error@*:* {{unknown type name 'unexpected'}}

Can we add some scenarios for expected diagnostics not produced?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72100



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

[PATCH] D71301: [clang][IFS] Prevent Clang-IFS from Leaking symbols from inside a block.

[Francis Visoiu Mistrih via Phabricator via cfe-commits]

thegameg added a comment.

In D71301#1832801 , @plotfi wrote:

> So, the culprit appears to be D69825 . The 
> way InterfaceStubs assembles the pipeline appears to trigger an asan bug. For 
> now I will alter the tests to get the bots green, but once I get my bugzilla 
> access sorted I intend to file a bug. -PL
>
> In D71301#1826928 , @thegameg wrote:
>
> > Hi @plotfi, this seems to cause failures with ASAN and UBSAN on green 
> > dragon: 
> > http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/6886/consoleFull
> >
> > The following tests are failing:
> >
> >   Clang :: InterfaceStubs/driver-test.c
> >   Clang :: InterfaceStubs/driver-test2.c
> >   
>


Great, thanks for taking a look!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71301



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

[clang] bb9b964 - [Concepts] Fix circular AST->Sema dependency in ASTConcept.cpp

[Saar Raz via cfe-commits]

Author: Saar Raz
Date: 2020-01-22T04:08:59+02:00
New Revision: bb9b964072eb42a09e76fe148b36eefcfff077b2

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

LOG: [Concepts] Fix circular AST->Sema dependency in ASTConcept.cpp

Remove inappropriate Sema include in ASTConcept.cpp introduced by D72552 for 
the finer-grained includes actually needed.

Added: 


Modified: 
clang/lib/AST/ASTConcept.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTConcept.cpp b/clang/lib/AST/ASTConcept.cpp
index 66d272da7049..c28a06bdf0b2 100644
--- a/clang/lib/AST/ASTConcept.cpp
+++ b/clang/lib/AST/ASTConcept.cpp
@@ -14,7 +14,10 @@
 
 #include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTContext.h"
-#include "clang/Sema/SemaConcept.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/TemplateBase.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/FoldingSet.h"
 using namespace clang;
 
 ASTConstraintSatisfaction::ASTConstraintSatisfaction(const ASTContext ,



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

[PATCH] D72972: [WebAssembly] Add experimental multivalue calling ABI

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:741
+  explicit WebAssemblyABIInfo(CodeGen::CodeGenTypes , ABIKind _Kind)
+  : SwiftABIInfo(CGT), defaultInfo(CGT), Kind(_Kind) {}
 

Nit: Do we need `_`?



Comment at: clang/test/CodeGen/wasm-arguments.c:19
+
 // Structs should be passed byval and not split up.
+// WEBASSEMBLY32: define void @struct_arg(%struct.s1* byval(%struct.s1) align 
4 %i)

The comment here includes only the MVP case. Shouldn't we update this? Ditto 
for the other comments below. 



Comment at: clang/test/CodeGen/wasm-arguments.c:98
+// WEBASSEMBLY64: define void @union_arg(%union.simple_union* 
byval(%union.simple_union) align 4 %s)
+// EXPERIMENTAL-MV: define void @union_arg(i32 %s.0)
+void union_arg(union simple_union s) {}

Why is the union passed as an int for MV?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72972



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

[PATCH] D73150: [Concepts] Remove -fconcepts-ts, enable concepts support under -std=c++2a

[Saar Raz via Phabricator via cfe-commits]

saar.raz updated this revision to Diff 239472.
saar.raz added a comment.

Readd -fconcepts-ts for deprecation diagnostic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73150

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/class.derived/class.virtual/p6.cpp
  clang/test/CXX/dcl/dcl.decl/p3.cpp
  clang/test/CXX/dcl/dcl.fct/p17.cpp
  clang/test/CXX/dcl/dcl.spec/dcl.type/dcl.spec.auto/p6.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.id/mixed-constraints.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.id/p4.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/expr.prim.lambda.closure/p3.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/equivalence.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/p3.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/requires-expr.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
  clang/test/CXX/over/over.match/over.match.best/p1-2a.cpp
  clang/test/CXX/over/over.match/over.match.viable/p3.cpp
  clang/test/CXX/over/over.over/p4-2a.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/function-templates.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/partial-specializations.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.decl/p3.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.normal/p1.cpp
  
clang/test/CXX/temp/temp.constr/temp.constr.order/class-template-partial-specializations.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.order/function-templates.cpp
  
clang/test/CXX/temp/temp.constr/temp.constr.order/var-template-partial-specializations.cpp
  clang/test/CXX/temp/temp.explicit/p8.cpp
  clang/test/CXX/temp/temp.param/p10-2a.cpp
  clang/test/CodeGenCXX/mangle-concept.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/keywords_test.cpp
  clang/test/PCH/cxx2a-requires-expr.cpp
  clang/test/Parser/cxx-concept-declaration.cpp
  clang/test/Parser/cxx-concepts-ambig-constraint-expr.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp
  clang/test/Parser/cxx2a-concept-declaration.cpp
  clang/test/Parser/cxx2a-concepts-requires-expr.cpp
  clang/test/Parser/cxx2a-constrained-template-param-with-partial-id.cpp
  clang/test/Parser/cxx2a-constrained-template-param.cpp
  clang/test/Parser/cxx2a-placeholder-type-constraint.cpp
  clang/test/SemaTemplate/cxx2a-constraint-caching.cpp
  clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
  clang/test/SemaTemplate/instantiate-requires-clause.cpp
  clang/test/SemaTemplate/instantiate-requires-expr.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -881,7 +881,7 @@
 
   Concepts
   https://wg21.link/p0734r0;>P0734R0
-  No
+  Clang 10
 

 https://wg21.link/p0857r0;>P0857R0
Index: clang/test/SemaTemplate/instantiate-requires-expr.cpp
===
--- clang/test/SemaTemplate/instantiate-requires-expr.cpp
+++ clang/test/SemaTemplate/instantiate-requires-expr.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ %s -verify -Wno-unused-value
+// RUN: %clang_cc1 -std=c++2a -x c++ %s -verify -Wno-unused-value
 
 template
 constexpr bool is_same_v = false;
Index: clang/test/SemaTemplate/instantiate-requires-clause.cpp
===
--- clang/test/SemaTemplate/instantiate-requires-clause.cpp
+++ clang/test/SemaTemplate/instantiate-requires-clause.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ %s -verify
+// RUN: %clang_cc1 -std=c++2a -x c++ %s -verify
 
 template  requires ((sizeof(Args) == 1), ...)
 // expected-note@-1 {{because '(sizeof(int) == 1) , (sizeof(char) == 1) , (sizeof(int) == 1)' evaluated to false}}
Index: clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
===
--- clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
+++ clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
@@ -1,4 +1,4 @@
-// RUN:  %clang_cc1 

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

[Richard Trieu via Phabricator via cfe-commits]

rtrieu added inline comments.



Comment at: clang/lib/AST/ASTConcept.cpp:17
 #include "clang/AST/ASTContext.h"
+#include "clang/Sema/SemaConcept.h"
 using namespace clang;

This causes a circular dependency between AST and Sema.  It looks like you are 
including this header to get access to some classes, but you should include the 
direct header instead.  These are the headers for the classes you are using in 
ConstraintSatisfaction::Profile:

NamedDecl -> clang/AST/Decl.h
TemplateArgument -> clang/AST/TemplateBase.h
ArrayRef -> llvm/ADT/ArrayRef.h
FoldingSetNodeID -> llvm/ADT/FoldingSet.h

Please update the header includes to resolve the circular dependency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552



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

[PATCH] D71301: [clang][IFS] Prevent Clang-IFS from Leaking symbols from inside a block.

[Puyan Lotfi via Phabricator via cfe-commits]

plotfi added a comment.

So, the culprit appears to be D69825 . The way 
InterfaceStubs assembles the pipeline appears to trigger an asan bug. For now I 
will alter the tests to get the bots green, but once I get my bugzilla access 
sorted I intend to file a bug. -PL

In D71301#1826928 , @thegameg wrote:

> Hi @plotfi, this seems to cause failures with ASAN and UBSAN on green dragon: 
> http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan/6886/consoleFull
>
> The following tests are failing:
>
>   Clang :: InterfaceStubs/driver-test.c
>   Clang :: InterfaceStubs/driver-test2.c
>   



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71301



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

[PATCH] D73151: [analyzer] Fix handle leak false positive when the handle dies too early

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

xazax.hun updated this revision to Diff 239469.
xazax.hun added a comment.

- Minor refactoring.


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

https://reviews.llvm.org/D73151

Files:
  clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
  clang/test/Analysis/fuchsia_handle.cpp


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -63,6 +63,14 @@
 zx_handle_close(sa);
 }
 
+void handleDieBeforeErrorSymbol() {
+  zx_handle_t sa, sb;
+  zx_status_t status = zx_channel_create(0, , );
+  if (status < 0)
+return;
+  __builtin_trap();
+}
+
 void checkNoCrash01() {
   zx_handle_t sa, sb;
   zx_channel_create(0, , );
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -130,6 +130,9 @@
   static HandleState getEscaped() {
 return HandleState(Kind::Escaped, nullptr);
   }
+  static HandleState getWithoutError(HandleState S) {
+return HandleState(S.K, nullptr);
+  }
 
   SymbolRef getErrorSym() const { return ErrorSym; }
 
@@ -149,6 +152,10 @@
   CASE(Kind::Released)
   CASE(Kind::Escaped)
 }
+if (ErrorSym) {
+  OS << " ErrorSym: ";
+  ErrorSym->dumpToStream(OS);
+}
   }
 
   LLVM_DUMP_METHOD void dump() const { dump(llvm::errs()); }
@@ -160,7 +167,7 @@
 
 class FuchsiaHandleChecker
 : public Checker {
+ check::LiveSymbols, check::PointerEscape, eval::Assume> {
   BugType LeakBugType{this, "Fuchsia handle leak", "Fuchsia Handle Error",
   /*SuppressOnSink=*/true};
   BugType DoubleReleaseBugType{this, "Fuchsia handle double release",
@@ -172,6 +179,7 @@
   void checkPreCall(const CallEvent , CheckerContext ) const;
   void checkPostCall(const CallEvent , CheckerContext ) const;
   void checkDeadSymbols(SymbolReaper , CheckerContext ) const;
+  void checkLiveSymbols(ProgramStateRef State, SymbolReaper ) const;
   ProgramStateRef evalAssume(ProgramStateRef State, SVal Cond,
  bool Assumption) const;
   ProgramStateRef checkPointerEscape(ProgramStateRef State,
@@ -381,6 +389,10 @@
   SmallVector LeakedSyms;
   HStateMapTy TrackedHandles = State->get();
   for (auto  : TrackedHandles) {
+SymbolRef ErrorSym = CurItem.second.getErrorSym();
+if (ErrorSym && SymReaper.isDead(ErrorSym))
+  State = State->set(
+  CurItem.first, HandleState::getWithoutError(CurItem.second));
 if (!SymReaper.isDead(CurItem.first))
   continue;
 if (CurItem.second.isAllocated() || CurItem.second.maybeAllocated())
@@ -395,6 +407,15 @@
   C.addTransition(State, N);
 }
 
+void FuchsiaHandleChecker::checkLiveSymbols(ProgramStateRef State,
+SymbolReaper ) const {
+  HStateMapTy TrackedHandles = State->get();
+  for (auto  : TrackedHandles) {
+if (CurItem.second.getErrorSym())
+  SymReaper.markLive(CurItem.first);
+  }
+}
+
 // Acquiring a handle is not always successful. In Fuchsia most functions
 // return a status code that determines the status of the handle.
 // When we split the path based on this status code we know that on one


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -63,6 +63,14 @@
 zx_handle_close(sa);
 }
 
+void handleDieBeforeErrorSymbol() {
+  zx_handle_t sa, sb;
+  zx_status_t status = zx_channel_create(0, , );
+  if (status < 0)
+return;
+  __builtin_trap();
+}
+
 void checkNoCrash01() {
   zx_handle_t sa, sb;
   zx_channel_create(0, , );
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -130,6 +130,9 @@
   static HandleState getEscaped() {
 return HandleState(Kind::Escaped, nullptr);
   }
+  static HandleState getWithoutError(HandleState S) {
+return HandleState(S.K, nullptr);
+  }
 
   SymbolRef getErrorSym() const { return ErrorSym; }
 
@@ -149,6 +152,10 @@
   CASE(Kind::Released)
   CASE(Kind::Escaped)
 }
+if (ErrorSym) {
+  OS << " ErrorSym: ";
+  ErrorSym->dumpToStream(OS);
+}
   }
 
   LLVM_DUMP_METHOD void dump() const { dump(llvm::errs()); }
@@ -160,7 +167,7 @@
 
 class FuchsiaHandleChecker
 : public Checker {
+ check::LiveSymbols, check::PointerEscape, eval::Assume> {
   BugType LeakBugType{this, "Fuchsia handle leak", "Fuchsia Handle Error",
   /*SuppressOnSink=*/true};
   BugType 

[PATCH] D73153: [Concepts] Update ReleaseNotes with Concepts support

[Saar Raz via Phabricator via cfe-commits]

saar.raz created this revision.
saar.raz added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Update Clang 10 release notes with news of Concepts support.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73153

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -51,7 +51,7 @@
   restores the former behavior. The ``-v`` and ``-###`` flags will print
   "(in-process)" when compilations are done in-process.
 
-- ...
+- Concepts support. Clang now supports C++2a Concepts under the -std=c++2a 
flag.
 
 Improvements to Clang's diagnostics
 ^^^
@@ -123,6 +123,10 @@
   You can also force vzeroupper insertion to be used on CPUs that normally
   wouldn't with -mvzeroupper.
 
+- The -fno-concept-satisfaction-caching can be used to disable caching for
+  satisfactions of Concepts. Using this flag might incur significant
+  compile-time costs.
+
 Deprecated Compiler Flags
 -
 
@@ -132,6 +136,8 @@
 - -mmpx used to enable the __MPX__ preprocessor define for the Intel MPX
   instructions. There were no MPX intrinsics.
 - -mno-mpx used to disable -mmpx and is the default behavior.
+- -fconcepts-ts previously used to enable experimental concepts support. Use
+  -std=c++2a instead to enable Concepts support.
 
 - ...
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -51,7 +51,7 @@
   restores the former behavior. The ``-v`` and ``-###`` flags will print
   "(in-process)" when compilations are done in-process.
 
-- ...
+- Concepts support. Clang now supports C++2a Concepts under the -std=c++2a flag.
 
 Improvements to Clang's diagnostics
 ^^^
@@ -123,6 +123,10 @@
   You can also force vzeroupper insertion to be used on CPUs that normally
   wouldn't with -mvzeroupper.
 
+- The -fno-concept-satisfaction-caching can be used to disable caching for
+  satisfactions of Concepts. Using this flag might incur significant
+  compile-time costs.
+
 Deprecated Compiler Flags
 -
 
@@ -132,6 +136,8 @@
 - -mmpx used to enable the __MPX__ preprocessor define for the Intel MPX
   instructions. There were no MPX intrinsics.
 - -mno-mpx used to disable -mmpx and is the default behavior.
+- -fconcepts-ts previously used to enable experimental concepts support. Use
+  -std=c++2a instead to enable Concepts support.
 
 - ...
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73151: [analyzer] Fix handle leak false positive when the handle dies too early

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

xazax.hun created this revision.
xazax.hun added reviewers: NoQ, haowei.
xazax.hun added a project: clang.
Herald added subscribers: Charusso, gamesh411, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware.

In case the handle symbol dies too early, even before we check the status, we 
might generate spurious leak warnings.

This pattern is not very common in production code but it is very common in 
unittests where we do know that certain syscall will fail.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73151

Files:
  clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
  clang/test/Analysis/fuchsia_handle.cpp


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -63,6 +63,14 @@
 zx_handle_close(sa);
 }
 
+void handleDieBeforeErrorSymbol() {
+  zx_handle_t sa, sb;
+  zx_status_t status = zx_channel_create(0, , );
+  if (status < 0)
+return;
+  __builtin_trap();
+}
+
 void checkNoCrash01() {
   zx_handle_t sa, sb;
   zx_channel_create(0, , );
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -130,6 +130,9 @@
   static HandleState getEscaped() {
 return HandleState(Kind::Escaped, nullptr);
   }
+  static HandleState getWithoutError(HandleState S) {
+return HandleState(S.K, nullptr);
+  }
 
   SymbolRef getErrorSym() const { return ErrorSym; }
 
@@ -149,6 +152,10 @@
   CASE(Kind::Released)
   CASE(Kind::Escaped)
 }
+if (ErrorSym) {
+  OS << " ErrorSym: ";
+  ErrorSym->dumpToStream(OS);
+}
   }
 
   LLVM_DUMP_METHOD void dump() const { dump(llvm::errs()); }
@@ -160,7 +167,7 @@
 
 class FuchsiaHandleChecker
 : public Checker {
+ check::LiveSymbols, check::PointerEscape, eval::Assume> {
   BugType LeakBugType{this, "Fuchsia handle leak", "Fuchsia Handle Error",
   /*SuppressOnSink=*/true};
   BugType DoubleReleaseBugType{this, "Fuchsia handle double release",
@@ -172,6 +179,7 @@
   void checkPreCall(const CallEvent , CheckerContext ) const;
   void checkPostCall(const CallEvent , CheckerContext ) const;
   void checkDeadSymbols(SymbolReaper , CheckerContext ) const;
+  void checkLiveSymbols(ProgramStateRef State, SymbolReaper ) const;
   ProgramStateRef evalAssume(ProgramStateRef State, SVal Cond,
  bool Assumption) const;
   ProgramStateRef checkPointerEscape(ProgramStateRef State,
@@ -381,6 +389,10 @@
   SmallVector LeakedSyms;
   HStateMapTy TrackedHandles = State->get();
   for (auto  : TrackedHandles) {
+SymbolRef ErrorSym = CurItem.second.getErrorSym();
+if (ErrorSym && SymReaper.isDead(ErrorSym))
+  State = State->set(
+  CurItem.first, HandleState::getWithoutError(CurItem.second));
 if (!SymReaper.isDead(CurItem.first))
   continue;
 if (CurItem.second.isAllocated() || CurItem.second.maybeAllocated())
@@ -395,6 +407,16 @@
   C.addTransition(State, N);
 }
 
+void FuchsiaHandleChecker::checkLiveSymbols(ProgramStateRef State,
+SymbolReaper ) const {
+  HStateMapTy TrackedHandles = State->get();
+  for (auto  : TrackedHandles) {
+SymbolRef ErrorSym = CurItem.second.getErrorSym();
+if (ErrorSym)
+  SymReaper.markLive(CurItem.first);
+  }
+}
+
 // Acquiring a handle is not always successful. In Fuchsia most functions
 // return a status code that determines the status of the handle.
 // When we split the path based on this status code we know that on one


Index: clang/test/Analysis/fuchsia_handle.cpp
===
--- clang/test/Analysis/fuchsia_handle.cpp
+++ clang/test/Analysis/fuchsia_handle.cpp
@@ -63,6 +63,14 @@
 zx_handle_close(sa);
 }
 
+void handleDieBeforeErrorSymbol() {
+  zx_handle_t sa, sb;
+  zx_status_t status = zx_channel_create(0, , );
+  if (status < 0)
+return;
+  __builtin_trap();
+}
+
 void checkNoCrash01() {
   zx_handle_t sa, sb;
   zx_channel_create(0, , );
Index: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp
@@ -130,6 +130,9 @@
   static HandleState getEscaped() {
 return HandleState(Kind::Escaped, nullptr);
   }
+  static HandleState getWithoutError(HandleState S) {
+return HandleState(S.K, nullptr);
+  }
 
   SymbolRef getErrorSym() const { return ErrorSym; }
 
@@ -149,6 +152,10 @@
   CASE(Kind::Released)
   CASE(Kind::Escaped)
 }
+if (ErrorSym) {
+  OS << " 

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

hfinkel wrote:
> jdoerfert wrote:
> > erichkeane wrote:
> > > jdoerfert wrote:
> > > > erichkeane wrote:
> > > > > I thought we had this stored somewhere else?  We probably should have 
> > > > > this be a constant somewhere in the frontend.  I THINK I remember 
> > > > > doing a review where I pulled this value into clang somewhere...
> > > > That was D72998, and I don't think Clang is the right place for this 
> > > > constant. It is a property of the llvm alignment attribute and it 
> > > > should live there. Thus, llvm/include/Attributes.h or some similar 
> > > > place. Can't we "fix" the linker error by making it a constexpr global 
> > > > or are the errors because of other file content? If the latter, we 
> > > > could go with a llvm/include/magic_constants.h ;)
> > > The one I was thinking of was this one: https://reviews.llvm.org/D68824
> > > 
> > > I don't remember what we came up with on the linking issue.  It would be 
> > > really nice if it was just something included from LLVM, but I think SEMA 
> > > typically doesn't include stuff from LLVM either.
> > I'm not too happy with the duplication of the constant but defining it once 
> > in clang is certainly better than having it in N places. For OpenMP we look 
> > into LLVM during SEMA and here there is an argument to be made that we 
> > should as well. I imagine more cases would pop up over time.
> > 
> > FWIW, if we allow to include LLVM headers, e.g., from IR or Frontend, we 
> > could still have a wrapper in SEMA to get the information so it doesn't 
> > expose the llvm:: namespace at the use sides (if that helps).
> > For OpenMP we look into LLVM during SEMA 
> 
> How do we do that?
> 
> There's certainly an interesting philosophical issue around whether changes 
> in LLVM should directly manifest as Clang behavioral changes, especially in 
> -fsyntax-only. The answer to this question might be different for extensions 
> vs. core language features (although alignment restrictions might implicate 
> both). AFAIKT, historically , our answer has been to insist on separation.
> > For OpenMP we look into LLVM during SEMA
> How do we do that?

I was referring to code like this 
https://reviews.llvm.org/D71830#C1739755NL11085 
which is in CodeGen right now but has to move to SemaOverload. The code is 
completely reusable between Clang and Flang so I put it in lib/Frontend/OpenMP 
and I think that is the right place for it.

> There's certainly an interesting philosophical issue around whether changes 
> in LLVM should directly manifest as Clang behavioral changes, especially in 
> -fsyntax-only. The answer to this question might be different for extensions 
> vs. core language features (although alignment restrictions might implicate 
> both). AFAIKT, historically , our answer has been to insist on separation.


I get that in a general sense. For the problem at hand, and as far as I known, 
the restriction stems only from the LLVM-IR restriction, correct? If so, what 
is the argument for separation? I mean, a change of the value in LLVM might 
directly impact Clang behavior.

I could also see us clamping the alignment during codegen. While that might 
have other problems they seem less practical to me.






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[PATCH] D73150: [Concepts] Remove -fconcepts-ts, enable concepts support under -std=c++2a

[Saar Raz via Phabricator via cfe-commits]

saar.raz created this revision.
saar.raz added a reviewer: rsmith.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Enable concepts support under normal -std=c++2a and not under -fconcepts-ts, 
which is now deprecated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73150

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Driver/CC1Options.td
  clang/lib/Basic/IdentifierTable.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/class.derived/class.virtual/p6.cpp
  clang/test/CXX/dcl/dcl.decl/p3.cpp
  clang/test/CXX/dcl/dcl.fct/p17.cpp
  clang/test/CXX/dcl/dcl.spec/dcl.type/dcl.spec.auto/p6.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.id/mixed-constraints.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.id/p4.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/expr.prim.lambda.closure/p3.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/compound-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/equivalence.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/nested-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/p3.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/requires-expr.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/simple-requirement.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
  clang/test/CXX/over/over.match/over.match.best/p1-2a.cpp
  clang/test/CXX/over/over.match/over.match.viable/p3.cpp
  clang/test/CXX/over/over.over/p4-2a.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.template/p3-2a.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/function-templates.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.constr/partial-specializations.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.decl/class-template-decl.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.decl/p3.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.normal/p1.cpp
  
clang/test/CXX/temp/temp.constr/temp.constr.order/class-template-partial-specializations.cpp
  clang/test/CXX/temp/temp.constr/temp.constr.order/function-templates.cpp
  
clang/test/CXX/temp/temp.constr/temp.constr.order/var-template-partial-specializations.cpp
  clang/test/CXX/temp/temp.explicit/p8.cpp
  clang/test/CXX/temp/temp.param/p10-2a.cpp
  clang/test/CodeGenCXX/mangle-concept.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/keywords_test.cpp
  clang/test/PCH/cxx2a-requires-expr.cpp
  clang/test/Parser/cxx-concept-declaration.cpp
  clang/test/Parser/cxx-concepts-ambig-constraint-expr.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp
  clang/test/Parser/cxx2a-concept-declaration.cpp
  clang/test/Parser/cxx2a-concepts-requires-expr.cpp
  clang/test/Parser/cxx2a-constrained-template-param-with-partial-id.cpp
  clang/test/Parser/cxx2a-constrained-template-param.cpp
  clang/test/Parser/cxx2a-placeholder-type-constraint.cpp
  clang/test/SemaTemplate/cxx2a-constraint-caching.cpp
  clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
  clang/test/SemaTemplate/instantiate-requires-clause.cpp
  clang/test/SemaTemplate/instantiate-requires-expr.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -881,7 +881,7 @@
 
   Concepts
   https://wg21.link/p0734r0;>P0734R0
-  No
+  Clang 10
 

 https://wg21.link/p0857r0;>P0857R0
Index: clang/test/SemaTemplate/instantiate-requires-expr.cpp
===
--- clang/test/SemaTemplate/instantiate-requires-expr.cpp
+++ clang/test/SemaTemplate/instantiate-requires-expr.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ %s -verify -Wno-unused-value
+// RUN: %clang_cc1 -std=c++2a -x c++ %s -verify -Wno-unused-value
 
 template
 constexpr bool is_same_v = false;
Index: clang/test/SemaTemplate/instantiate-requires-clause.cpp
===
--- clang/test/SemaTemplate/instantiate-requires-clause.cpp
+++ clang/test/SemaTemplate/instantiate-requires-clause.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++2a -fconcepts-ts -x c++ %s -verify
+// RUN: %clang_cc1 -std=c++2a -x c++ %s -verify
 
 template  requires ((sizeof(Args) == 1), ...)
 // expected-note@-1 {{because '(sizeof(int) == 1) , (sizeof(char) == 1) , (sizeof(int) == 1)' evaluated to false}}
Index: clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
===
--- clang/test/SemaTemplate/instantiate-expanded-type-constraint.cpp
+++ 

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

[Saar Raz via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGb933d37cd377: [Concepts] Constraint Satisfaction Caching 
(authored by saar.raz).

Changed prior to commit:
  https://reviews.llvm.org/D72552?vs=237474=239464#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552

Files:
  clang/include/clang/AST/ASTConcept.h
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/TemplateDeduction.h
  clang/lib/AST/ASTConcept.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/test/SemaTemplate/cxx2a-constraint-caching.cpp

Index: clang/test/SemaTemplate/cxx2a-constraint-caching.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/cxx2a-constraint-caching.cpp
@@ -0,0 +1,34 @@
+// RUN:  %clang_cc1 -std=c++2a -fconcepts-ts -verify %s
+// RUN:  %clang_cc1 -std=c++2a -fconcepts-ts -verify %s -fno-concept-satisfaction-caching -DNO_CACHE
+// expected-no-diagnostics
+
+template
+concept C = (f(T()), true);
+
+template
+constexpr bool foo() { return false; }
+
+template
+  requires (f(T()), true)
+constexpr bool foo() requires (f(T()), true) { return true; }
+
+namespace a {
+  struct A {};
+  void f(A a);
+}
+
+static_assert(C);
+static_assert(foo());
+
+namespace a {
+  // This makes calls to f ambiguous, but the second check will still succeed
+  // because the constraint satisfaction results are cached.
+  void f(A a, int = 2);
+}
+#ifdef NO_CACHE
+static_assert(!C);
+static_assert(!foo());
+#else
+static_assert(C);
+static_assert(foo());
+#endif
\ No newline at end of file
Index: clang/lib/Sema/SemaConcept.cpp
===
--- clang/lib/Sema/SemaConcept.cpp
+++ clang/lib/Sema/SemaConcept.cpp
@@ -272,36 +272,56 @@
   return false;
 }
 
-bool Sema::CheckConstraintSatisfaction(TemplateDecl *Template,
-   ArrayRef ConstraintExprs,
-   ArrayRef TemplateArgs,
-   SourceRange TemplateIDRange,
-   ConstraintSatisfaction ) {
-  return ::CheckConstraintSatisfaction(*this, Template, ConstraintExprs,
-   TemplateArgs, TemplateIDRange,
-   Satisfaction);
-}
+bool Sema::CheckConstraintSatisfaction(
+NamedDecl *Template, ArrayRef ConstraintExprs,
+ArrayRef TemplateArgs, SourceRange TemplateIDRange,
+ConstraintSatisfaction ) {
+  if (ConstraintExprs.empty()) {
+OutSatisfaction.IsSatisfied = true;
+return false;
+  }
 
-bool
-Sema::CheckConstraintSatisfaction(ClassTemplatePartialSpecializationDecl* Part,
-  ArrayRef ConstraintExprs,
-  ArrayRef TemplateArgs,
-  SourceRange TemplateIDRange,
-  ConstraintSatisfaction ) {
-  return ::CheckConstraintSatisfaction(*this, Part, ConstraintExprs,
-   TemplateArgs, TemplateIDRange,
-   Satisfaction);
-}
+  llvm::FoldingSetNodeID ID;
+  void *InsertPos;
+  ConstraintSatisfaction *Satisfaction = nullptr;
+  if (LangOpts.ConceptSatisfactionCaching) {
+ConstraintSatisfaction::Profile(ID, Context, Template, TemplateArgs);
+Satisfaction = SatisfactionCache.FindNodeOrInsertPos(ID, InsertPos);
+if (Satisfaction) {
+  OutSatisfaction = *Satisfaction;
+  return false;
+}
+Satisfaction = new ConstraintSatisfaction(Template, TemplateArgs);
+  } else {
+Satisfaction = 
+  }
+  bool Failed;
+  if (auto *T = dyn_cast(Template))
+Failed = ::CheckConstraintSatisfaction(*this, T, ConstraintExprs,
+   TemplateArgs, TemplateIDRange,
+   *Satisfaction);
+  else if (auto *P =
+   dyn_cast(Template))
+Failed = ::CheckConstraintSatisfaction(*this, P, ConstraintExprs,
+   TemplateArgs, TemplateIDRange,
+   *Satisfaction);
+  else
+Failed = ::CheckConstraintSatisfaction(
+*this, cast(Template),
+ConstraintExprs, TemplateArgs, TemplateIDRange, *Satisfaction);
+  if (Failed) {
+if (LangOpts.ConceptSatisfactionCaching)
+  delete Satisfaction;
+return true;
+  }
 
-bool
-Sema::CheckConstraintSatisfaction(VarTemplatePartialSpecializationDecl* Partial,
-  ArrayRef ConstraintExprs,
-  ArrayRef TemplateArgs,
-  SourceRange TemplateIDRange,
-  

[PATCH] D69933: [ASTImporter] Limit imports of structs

[Greg Clayton via Phabricator via cfe-commits]

clayborg added a comment.

Clang AST contexts know how to complete types and is done via the external AST 
source code that will ask a type to complete itself. Each object file has an 
AST that knows how to lazily complete a type when and only when it is needed. 
Each object file also only knows about the type information in the binary 
itself. So if we have a forward declaration to "Foo" with something like 
"struct Foo;" that is all the object file AST will ever know about this type. 
This is required because each module can be re-used on subsequent debug 
sessions if they haven't changed. So if we have a forward declaration for "Foo" 
in the AST for "bbb.so" that is ok. We don't want to copy some definition for 
"Foo" from "foo.so" over into bbb.so's AST context because if we run again and 
we get a new foo.so we would have to reload bbb.so because its copy of "Foo" 
might be out of date. And we would need to track these interactions.

When we run expressions, we create a new AST and copy types as needed. It would 
be great if the AST importer only copy over forward declarations of types that 
can be completed later and can also complete types only as needed when asked.

If I understand correctly that is what this patch is trying to do. Seems like 
we have a code path that is copying over the type and also completing it 
sometimes without being asked which should be fixed. If we do fix this, complex 
expressions become a lot faster. To do this right we should always import 
forward declarations from the source, and be able to complete the new types in 
the destination as needed. As teemperor said, the source AST should not be 
mutated in any way. We should track all of this in the importer and know where 
we should try to complete the type from.

When using expression AST contexts it **is** ok to try and import "Foo" from 
bbb.so since that where is where we first saw the type, and if we aren't 
successful, we can grab the definition from anywhere else in the debug session. 
Since each expression has its own AST, it **is** ok to get the type from 
anywhere. When searching for this type we should start in the current 
lldb_private::Block, their pareent blocks, then the file, then the module and 
then all modules. I think that works today already, but I am not sure if this 
works for a type "Foo" that is mentioned in a type from a file that doesn't 
have a complete definition. for example if bbb.so contains:

  struct Bar : public Foo {...};

Due to "-flimit-debug-info" the definition for Foo might be forward declared 
(if the vtable for Foo isn't in the current binary) and not included in this 
binary. This won't happen on darwin since the default is 
-fno-limit-debug-info". The DWARF parser knows how to work around this issue 
when creating the type in the AST for bbb.so, but when we run an expression 
with this type, we want to be able to have an AST type from bbb.so with an 
incomplete definition for "Foo" that we complete during AST import. To do this, 
we will need to use metadata in the bbb.so AST to indicate we have no 
definition for this type when we normally would require one and be able to 
complete the type from another source.

So quick things to stick to:

- no modification of the source AST context
- importer can track anything it needs to in order to complete types in complex 
situations as mentioned above
  - need metadata that tracks types that need to be complete but aren't in the 
debug info so they can be properly imported for expressions ("struct Bar: 
public Foo {}", not ok for Foo to not be complete but we allow it for object 
file AST contexts otherwise clang crashes us)
  - legal forward declarations should be able to be imported as needed even if 
the AST form the original source doesn't have a complete type ("struct Bar { 
Foo *foo_ptr; }", ok for Foo to be forward declared here)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69933



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

[clang] b933d37 - [Concepts] Constraint Satisfaction Caching

[Saar Raz via cfe-commits]

Author: Saar Raz
Date: 2020-01-22T03:09:53+02:00
New Revision: b933d37cd3774e5431b35e82187eebb59b1ff59e

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

LOG: [Concepts] Constraint Satisfaction Caching

Add a simple cache for constraint satisfaction results. Whether or not this 
simple caching
would be permitted in final C++2a is currently being discussed but it is 
required for
acceptable performance so we use it in the meantime, with the possibility of 
adding some
cache invalidation mechanisms later.

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

Added: 
clang/test/SemaTemplate/cxx2a-constraint-caching.cpp

Modified: 
clang/include/clang/AST/ASTConcept.h
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Driver/CC1Options.td
clang/include/clang/Sema/Sema.h
clang/include/clang/Sema/TemplateDeduction.h
clang/lib/AST/ASTConcept.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaConcept.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTConcept.h 
b/clang/include/clang/AST/ASTConcept.h
index 84a611c14e0b..30c4706d2a15 100644
--- a/clang/include/clang/AST/ASTConcept.h
+++ b/clang/include/clang/AST/ASTConcept.h
@@ -24,9 +24,23 @@ namespace clang {
 class ConceptDecl;
 class ConceptSpecializationExpr;
 
-/// \brief The result of a constraint satisfaction check, containing the
-/// necessary information to diagnose an unsatisfied constraint.
-struct ConstraintSatisfaction {
+/// The result of a constraint satisfaction check, containing the necessary
+/// information to diagnose an unsatisfied constraint.
+class ConstraintSatisfaction : public llvm::FoldingSetNode {
+  // The template-like entity that 'owns' the constraint checked here (can be a
+  // constrained entity or a concept).
+  NamedDecl *ConstraintOwner = nullptr;
+  llvm::SmallVector TemplateArgs;
+
+public:
+
+  ConstraintSatisfaction() = default;
+
+  ConstraintSatisfaction(NamedDecl *ConstraintOwner,
+ ArrayRef TemplateArgs) :
+  ConstraintOwner(ConstraintOwner), TemplateArgs(TemplateArgs.begin(),
+ TemplateArgs.end()) { }
+
   using SubstitutionDiagnostic = std::pair;
   using Detail = llvm::PointerUnion;
 
@@ -38,9 +52,13 @@ struct ConstraintSatisfaction {
   /// invalid expression.
   llvm::SmallVector, 4> Details;
 
-  // This can leak if used in an AST node, use ASTConstraintSatisfaction
-  // instead.
-  void *operator new(size_t bytes, ASTContext ) = delete;
+  void Profile(llvm::FoldingSetNodeID , const ASTContext ) {
+Profile(ID, C, ConstraintOwner, TemplateArgs);
+  }
+
+  static void Profile(llvm::FoldingSetNodeID , const ASTContext ,
+  NamedDecl *ConstraintOwner,
+  ArrayRef TemplateArgs);
 };
 
 /// Pairs of unsatisfied atomic constraint expressions along with the

diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index 068f206f4484..b8112eb26913 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -238,6 +238,7 @@ LANGOPT(AlignedAllocation , 1, 0, "aligned allocation")
 LANGOPT(AlignedAllocationUnavailable, 1, 0, "aligned allocation functions are 
unavailable")
 LANGOPT(NewAlignOverride  , 32, 0, "maximum alignment guaranteed by 
'::operator new(size_t)'")
 LANGOPT(ConceptsTS , 1, 0, "enable C++ Extensions for Concepts")
+LANGOPT(ConceptSatisfactionCaching , 1, 1, "enable satisfaction caching for 
C++2a Concepts")
 BENIGN_LANGOPT(ModulesCodegen , 1, 0, "Modules code generation")
 BENIGN_LANGOPT(ModulesDebugInfo , 1, 0, "Modules debug info")
 BENIGN_LANGOPT(ElideConstructors , 1, 1, "C++ copy constructor elision")

diff  --git a/clang/include/clang/Driver/CC1Options.td 
b/clang/include/clang/Driver/CC1Options.td
index deb588fa256e..9d6b381a32a1 100644
--- a/clang/include/clang/Driver/CC1Options.td
+++ b/clang/include/clang/Driver/CC1Options.td
@@ -557,6 +557,9 @@ def ftest_module_file_extension_EQ :
"The argument is parsed as blockname:major:minor:hashed:user info">;
 def fconcepts_ts : Flag<["-"], "fconcepts-ts">,
   HelpText<"Enable C++ Extensions for Concepts.">;
+def fno_concept_satisfaction_caching : Flag<["-"],
+
"fno-concept-satisfaction-caching">,
+  HelpText<"Disable satisfaction caching for C++2a Concepts.">;
 
 let Group = Action_Group in {
 

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 7dfc11315ddd..ebd24b0d71da 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -6232,6 +6232,9 @@ class Sema final {
   llvm::DenseMap
   

[PATCH] D69868: Allow "callbr" to return non-void values

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D69868#1832559 , @void wrote:

> @jyknight Do you think you'll have time to review this patch this week? I'd 
> like to get it into the 10.0 release if possible. :-)


I volunteer as a reviewer:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69868



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

[clang] a156da5 - [clang/Darwin] Remove __llvm_profile_counter_bias from export list for profiling

[Vedant Kumar via cfe-commits]

Author: Vedant Kumar
Date: 2020-01-21T16:52:01-08:00
New Revision: a156da5fb361fd38ba379ec20856626c9e35f829

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

LOG: [clang/Darwin] Remove __llvm_profile_counter_bias from export list for 
profiling

Do not export __llvm_profile_counter_bias when profiling is enabled
because this symbol is hidden and cannot be exported.

Should fix this bot error:

```
URL: http://green.lab.llvm.org/green/job/clang-stage1-RA/5678/consoleFull

Problem: Command Output (stdout):
--
ld: warning: cannot export hidden symbol ___llvm_profile_counter_bias
from
/Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/lib/clang/11.0.0/lib/darwin/libclang_rt.profile_osx.a(InstrProfilingBiasVar.c.o)
ld: warning: cannot export hidden symbol ___llvm_profile_counter_bias
from
/Users/buildslave/jenkins/workspace/clang-stage1-RA/clang-build/lib/clang/11.0.0/lib/darwin/libclang_rt.profile_osx.a(InstrProfilingBiasVar.c.o)
```

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index bc2a3e7ef61b..344a14fe1ea7 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1149,7 +1149,6 @@ void Darwin::addProfileRTLibs(const ArgList ,
 } else {
   addExportedSymbol(CmdArgs, "___llvm_profile_filename");
   addExportedSymbol(CmdArgs, "___llvm_profile_raw_version");
-  addExportedSymbol(CmdArgs, "___llvm_profile_counter_bias");
 }
 addExportedSymbol(CmdArgs, "_lprofDirMode");
   }



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

[PATCH] D70926: [clang-format] Add option for not breaking line before ObjC params

[Kanglei Fang via Phabricator via cfe-commits]

ghvg1313 updated this revision to Diff 239458.
ghvg1313 added a comment.

- rebase master
- formatting code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70926

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/unittests/Format/FormatTestObjC.cpp

Index: clang/unittests/Format/FormatTestObjC.cpp
===
--- clang/unittests/Format/FormatTestObjC.cpp
+++ clang/unittests/Format/FormatTestObjC.cpp
@@ -1398,6 +1398,37 @@
   "}");
 }
 
+TEST_F(FormatTestObjC, BreakLineBeforeNestedBlockParam) {
+  Style = getGoogleStyle(FormatStyle::LK_ObjC);
+  Style.ObjCBreakBeforeNestedBlockParam = false;
+  Style.ColumnLimit = 0;
+
+  verifyFormat("[self.test1 t:self callback:^(typeof(self) self, NSNumber *u, "
+   "NSNumber *v) {\n"
+   "  u = v;\n"
+   "}]");
+
+  verifyFormat("[self.test1 t:self w:self callback:^(typeof(self) self, "
+   "NSNumber *u, NSNumber *v) {\n"
+   "  u = v;\n"
+   "}]");
+
+  verifyFormat("[self.test1 t:self w:self callback:^(typeof(self) self, "
+   "NSNumber *u, NSNumber *v) {\n"
+   "  u = c;\n"
+   "} w:self callback2:^(typeof(self) self, NSNumber *a, NSNumber "
+   "*b, NSNumber *c) {\n"
+   "  b = c;\n"
+   "}]");
+
+  Style.ColumnLimit = 80;
+  verifyFormat(
+  "[self.test_method a:self b:self\n"
+  "   callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {\n"
+  " u = v;\n"
+  "   }]");
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -498,6 +498,8 @@
 IO.mapOptional("NamespaceMacros", Style.NamespaceMacros);
 IO.mapOptional("ObjCBinPackProtocolList", Style.ObjCBinPackProtocolList);
 IO.mapOptional("ObjCBlockIndentWidth", Style.ObjCBlockIndentWidth);
+IO.mapOptional("ObjCBreakBeforeNestedBlockParam",
+   Style.ObjCBreakBeforeNestedBlockParam);
 IO.mapOptional("ObjCSpaceAfterProperty", Style.ObjCSpaceAfterProperty);
 IO.mapOptional("ObjCSpaceBeforeProtocolList",
Style.ObjCSpaceBeforeProtocolList);
@@ -796,6 +798,7 @@
   LLVMStyle.NamespaceIndentation = FormatStyle::NI_None;
   LLVMStyle.ObjCBinPackProtocolList = FormatStyle::BPS_Auto;
   LLVMStyle.ObjCBlockIndentWidth = 2;
+  LLVMStyle.ObjCBreakBeforeNestedBlockParam = true;
   LLVMStyle.ObjCSpaceAfterProperty = false;
   LLVMStyle.ObjCSpaceBeforeProtocolList = true;
   LLVMStyle.PointerAlignment = FormatStyle::PAS_Right;
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -861,8 +861,10 @@
   // Any break on this level means that the parent level has been broken
   // and we need to avoid bin packing there.
   bool NestedBlockSpecialCase =
-  !Style.isCpp() && Current.is(tok::r_brace) && State.Stack.size() > 1 &&
-  State.Stack[State.Stack.size() - 2].NestedBlockInlined;
+  (!Style.isCpp() && Current.is(tok::r_brace) && State.Stack.size() > 1 &&
+   State.Stack[State.Stack.size() - 2].NestedBlockInlined) ||
+  (Style.Language == FormatStyle::LK_ObjC && Current.is(tok::r_brace) &&
+   State.Stack.size() > 1 && !Style.ObjCBreakBeforeNestedBlockParam);
   if (!NestedBlockSpecialCase)
 for (unsigned i = 0, e = State.Stack.size() - 1; i != e; ++i)
   State.Stack[i].BreakBeforeParameter = true;
@@ -1380,7 +1382,8 @@
   (!BinPackInconclusiveFunctions &&
Current.PackingKind == PPK_Inconclusive)));
 
-if (Current.is(TT_ObjCMethodExpr) && Current.MatchingParen) {
+if (Current.is(TT_ObjCMethodExpr) && Current.MatchingParen &&
+Style.ObjCBreakBeforeNestedBlockParam) {
   if (Style.ColumnLimit) {
 // If this '[' opens an ObjC call, determine whether all parameters fit
 // into one line and put one per line if they don't.
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1669,6 +1669,29 @@
   /// ``@property (readonly)`` instead of ``@property(readonly)``.
   bool ObjCSpaceAfterProperty;
 
+  /// Break parameters list into lines when there is nested block
+  /// parameters in a fuction call.
+  /// \code
+  ///   false:
+  ///- (void)_aMethod
+  ///{
+  ///[self.test1 t:self w:self callback:^(typeof(self) self, 

[clang-tools-extra] 5fdad8e - [clang-tidy] Fix check for generic lambda invented template parameters

[Saar Raz via cfe-commits]

Author: Saar Raz
Date: 2020-01-22T02:46:39+02:00
New Revision: 5fdad8e3f803adce501ca25118f325184e54018d

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

LOG: [clang-tidy] Fix check for generic lambda invented template parameters

clang-tidy previously relied on there being no identifier for a 
TemplateTypeParmDecl for checking
whether 'decltype(x)' should be inserted, instead of checking whether or not it 
is implicit.

D65042 added new names for invented generic lambda template parameters, 
rendering that check incorrect.

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/MoveForwardingReferenceCheck.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/MoveForwardingReferenceCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/MoveForwardingReferenceCheck.cpp
index bf6f2f6ed035..8953f95159a9 100644
--- a/clang-tools-extra/clang-tidy/bugprone/MoveForwardingReferenceCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/MoveForwardingReferenceCheck.cpp
@@ -33,7 +33,7 @@ static void replaceMoveWithForward(const UnresolvedLookupExpr 
*Callee,
 
   if (CallRange.isValid()) {
 const std::string TypeName =
-TypeParmDecl->getIdentifier()
+(TypeParmDecl->getIdentifier() && !TypeParmDecl->isImplicit())
 ? TypeParmDecl->getName().str()
 : (llvm::Twine("decltype(") + ParmVar->getName() + ")").str();
 



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

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

[David Stone via Phabricator via cfe-commits]

david_stone added a comment.

In D72552#1832293 , @rsmith wrote:

> Mechanically, this looks fine.
>
> There's an ongoing discussion in the committee as to whether this kind of 
> caching is permissible. But if this is necessary for acceptable performance, 
> let's take this for now and figure out how to invalidate the cache as 
> necessary later. Perhaps a `-f` flag to turn this off would be useful, so we 
> can demonstrate and measure the performance delta.


If there were a flag to turn this on and off, I would be happy to provide 
numbers for a real code base so we can understand how important of an 
optimization this is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552



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

[PATCH] D72703: Add a warning, flags and pragmas to limit the number of pre-processor tokens in a translation unit

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I waited to see if there was any other feedback, but I'm in favor of this.

Should we try to come up with better pragma names? `clang max_tokens` doesn't 
seem to call to mind what it does: warn if there have been more than this many 
tokens so far in the translation unit. `max_file_tokens` has to do with the 
number of tokens in the translation unit overall, but it uses the terminology 
"file" instead of "translation unit". The user could interpret that as being in 
the current source file, ignoring includes.

Some ideas for the immediate version:

- clang max_tokens_so_far
- clang max_tokens_lexed
- clang max_tokens_here

Some ideas for end-of-tu:

- clang max_translation_unit_tokens
- clang max_tu_tokens
- clang global_max_tokens


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

https://reviews.llvm.org/D72703



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

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

jdoerfert wrote:
> erichkeane wrote:
> > jdoerfert wrote:
> > > erichkeane wrote:
> > > > I thought we had this stored somewhere else?  We probably should have 
> > > > this be a constant somewhere in the frontend.  I THINK I remember doing 
> > > > a review where I pulled this value into clang somewhere...
> > > That was D72998, and I don't think Clang is the right place for this 
> > > constant. It is a property of the llvm alignment attribute and it should 
> > > live there. Thus, llvm/include/Attributes.h or some similar place. Can't 
> > > we "fix" the linker error by making it a constexpr global or are the 
> > > errors because of other file content? If the latter, we could go with a 
> > > llvm/include/magic_constants.h ;)
> > The one I was thinking of was this one: https://reviews.llvm.org/D68824
> > 
> > I don't remember what we came up with on the linking issue.  It would be 
> > really nice if it was just something included from LLVM, but I think SEMA 
> > typically doesn't include stuff from LLVM either.
> I'm not too happy with the duplication of the constant but defining it once 
> in clang is certainly better than having it in N places. For OpenMP we look 
> into LLVM during SEMA and here there is an argument to be made that we should 
> as well. I imagine more cases would pop up over time.
> 
> FWIW, if we allow to include LLVM headers, e.g., from IR or Frontend, we 
> could still have a wrapper in SEMA to get the information so it doesn't 
> expose the llvm:: namespace at the use sides (if that helps).
> For OpenMP we look into LLVM during SEMA 

How do we do that?

There's certainly an interesting philosophical issue around whether changes in 
LLVM should directly manifest as Clang behavioral changes, especially in 
-fsyntax-only. The answer to this question might be different for extensions 
vs. core language features (although alignment restrictions might implicate 
both). AFAIKT, historically , our answer has been to insist on separation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[clang] 6e73fee - List implicit operator== after implicit destructors in a vtable.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-01-21T15:54:40-08:00
New Revision: 6e73fee780839bfa95aff492864e93e79910380b

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

LOG: List implicit operator== after implicit destructors in a vtable.

Summary:
We previously listed first declared members, then implicit operator=,
then implicit operator==, then implicit destructors. Per discussion on
https://github.com/itanium-cxx-abi/cxx-abi/issues/88, put the implicit
equality comparison operators at the very end, after all special member
functions.

This reinstates add2b7e44ada46f30715b5c48823a9e9e317e0c3, reverted in
commit 89e43f04ba87a0da6e94863db149669c7536486b, with a fix for 32-bit
targets.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

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

Added: 
clang/test/CodeGenCXX/virtual-compare.cpp

Modified: 
clang/lib/AST/VTableBuilder.cpp

Removed: 




diff  --git a/clang/lib/AST/VTableBuilder.cpp b/clang/lib/AST/VTableBuilder.cpp
index 2b5b74be5961..0bff976905fc 100644
--- a/clang/lib/AST/VTableBuilder.cpp
+++ b/clang/lib/AST/VTableBuilder.cpp
@@ -1474,11 +1474,11 @@ void ItaniumVTableBuilder::AddMethods(
   llvm_unreachable("Found a duplicate primary base!");
   }
 
-  const CXXDestructorDecl *ImplicitVirtualDtor = nullptr;
-
   typedef llvm::SmallVector NewVirtualFunctionsTy;
   NewVirtualFunctionsTy NewVirtualFunctions;
 
+  llvm::SmallVector NewImplicitVirtualFunctions;
+
   // Now go through all virtual member functions and add them.
   for (const auto *MD : RD->methods()) {
 if (!MD->isVirtual())
@@ -1542,24 +1542,30 @@ void ItaniumVTableBuilder::AddMethods(
   }
 }
 
-if (const CXXDestructorDecl *DD = dyn_cast(MD)) {
-  if (MD->isImplicit()) {
-// Itanium C++ ABI 2.5.2:
-//   If a class has an implicitly-defined virtual destructor,
-//   its entries come after the declared virtual function pointers.
-
-assert(!ImplicitVirtualDtor &&
-   "Did already see an implicit virtual dtor!");
-ImplicitVirtualDtor = DD;
-continue;
-  }
-}
-
-NewVirtualFunctions.push_back(MD);
-  }
-
-  if (ImplicitVirtualDtor)
-NewVirtualFunctions.push_back(ImplicitVirtualDtor);
+if (MD->isImplicit())
+  NewImplicitVirtualFunctions.push_back(MD);
+else
+  NewVirtualFunctions.push_back(MD);
+  }
+
+  std::stable_sort(
+  NewImplicitVirtualFunctions.begin(), NewImplicitVirtualFunctions.end(),
+  [](const CXXMethodDecl *A, const CXXMethodDecl *B) {
+if (A->isCopyAssignmentOperator() != B->isCopyAssignmentOperator())
+  return A->isCopyAssignmentOperator();
+if (A->isMoveAssignmentOperator() != B->isMoveAssignmentOperator())
+  return A->isMoveAssignmentOperator();
+if (isa(A) != isa(B))
+  return isa(A);
+assert(A->getOverloadedOperator() == OO_EqualEqual &&
+   B->getOverloadedOperator() == OO_EqualEqual &&
+   "unexpected or duplicate implicit virtual function");
+// We rely on Sema to have declared the operator== members in the
+// same order as the corresponding operator<=> members.
+return false;
+  });
+  NewVirtualFunctions.append(NewImplicitVirtualFunctions.begin(),
+ NewImplicitVirtualFunctions.end());
 
   for (const CXXMethodDecl *MD : NewVirtualFunctions) {
 // Get the final overrider.

diff  --git a/clang/test/CodeGenCXX/virtual-compare.cpp 
b/clang/test/CodeGenCXX/virtual-compare.cpp
new file mode 100644
index ..ef75513ec0fe
--- /dev/null
+++ b/clang/test/CodeGenCXX/virtual-compare.cpp
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 -std=c++2a -triple %itanium_abi_triple -emit-llvm %s -o - | 
FileCheck %s
+
+#include "Inputs/std-compare.h"
+
+// CHECK: @_ZTV1A =
+struct A;
+struct X {
+  // CHECK-SAME: @_ZN1X1xEv
+  virtual void x();
+  friend auto operator<=>(X, X) = default;
+};
+struct Y {
+  virtual ~Y();
+  virtual A =(const A &);
+  friend auto operator<=>(Y, Y) = default;
+};
+struct A : X, Y {
+  // CHECK-SAME: @_ZN1A1fEv
+  virtual void f();
+  // CHECK-SAME: @_ZNKR1AssERKS_
+  virtual std::strong_ordering operator<=>(const A &) const & = default;
+  // CHECK-SAME: @_ZN1A1gEv
+  virtual void g();
+  // CHECK-SAME: @_ZNKO1AssERKS_
+  virtual std::strong_ordering operator<=>(const A &) const && = default;
+  // CHECK-SAME: @_ZN1A1hEv
+  virtual void h();
+
+  // CHECK-SAME: @_ZN1AaSERKS_
+  // implicit virtual A =(const A&) = default;
+
+  // CHECK-SAME: @_ZN1AD1Ev
+  // CHECK-SAME: @_ZN1AD0Ev
+  // implicit virtual ~A();
+
+  // CHECK-SAME: @_ZNKR1AeqERKS_
+  // implicit virtual A ==(const A&) const & = default;
+
+  // CHECK-SAME: @_ZNKO1AeqERKS_
+  // implicit virtual A 

[PATCH] D72897: List implicit operator== after implicit destructors in a vtable.

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

rsmith added a comment.

In D72897#1832234 , @vvereschaka wrote:

> Hi Richard,
>
> http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l builder has been 
> broken by this patch during few days (failed "Clang::virtual-compare.cpp" 
> test).
>  Sorry, but I'm going to revert these changes.


Thanks for the revert; fixed and re-landed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72897



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

[PATCH] D72901: [OpenMP] [DOCS] Update OMP5.0 feature status table [NFC]

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

@kkwli0 I propose you can merge the parts where discussion has reached a 
consensus while the other parts are resolved. I'm generally fine with this, we 
can always improve on it further.




Comment at: clang/docs/OpenMPSupport.rst:194
 
+--+--+--+---+
-| device extension | requires directive (unified shared memory)
   | :good:`done` | 
  |
+| device extension | requires directive
   | :good:`done` | 
  |
 
+--+--+--+---+

kkwli0 wrote:
> jdoerfert wrote:
> > ABataev wrote:
> > > We have support only for unified memory, so must be `partial`
> > Let's keep the explicit ` (unified shared memory) -> done ` line and add 
> > one for the others as not done.
> @abataev It makes sense to make it `partial`.
> 
> @jdoerfert  Keeping that line can be confusing.  Line 196 is clear to 
> indicate that the unified_address and unified_shared_memory parts of the 
> requires directive is done.
Fair point. thx.



Comment at: clang/docs/OpenMPSupport.rst:216
 
+--+--+--+---+
+| device extension | pointer attachment
   | :none:`unclaimed`| 
  |
++--+--+--+---+

ABataev wrote:
> Is this for Fortran?
No also C/C++.



Comment at: clang/docs/OpenMPSupport.rst:240
++--+--+--+---+
+| misc extension   | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+

ABataev wrote:
> kkwli0 wrote:
> > ABataev wrote:
> > > What is this?
> > This is a clarification. The spec add restrictions to declare new type on 
> > iterators, declare reduction and declare mapper [49:11; 308:17; 327:26]
> Would be good to put these links to the doc to make it clear
> Would be good to put these links to the doc to make it clear

Agreed. We have the HTML version of the standard online so we can do this 
"easily" but it will cost someone time and require to change the table layout. 
Let's postpone it for now until someone find some spare minutes.



Comment at: clang/docs/OpenMPSupport.rst:242
 
+--+--+--+---+
-| misc extensions  | prevent new type definitions in clauses   
   | :none:`unclaimed`| 
  |
+| memory model extension   | memory model update   
   | :none:`unclaimed`| 
  |
 
+--+--+--+---+

ABataev wrote:
> kkwli0 wrote:
> > ABataev wrote:
> > > What kind of memory model update?
> > We add five _memory-order-clause_s in the atomic directive - `seq_cst`, 
> > `acq_rel`, `release`, `acquire` and `relaxed` to support the memory model.
> I would add as much as possible info about expected features to the doc, if 
> possible
I guess if they are unclaimed or done we can just list them in the description:
  `memory model update (seq_cst, acq_rel, ...)`
and if we ever support a subset only we can make new rows for them.


CHANGES SINCE LAST ACTION
  

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

[Mitch Phillips via Phabricator via cfe-commits]

hctim added a comment.

In D69825#1831691 , @plotfi wrote:

> In the meantime I could  -fno-integrated-cc1 the driver.c InterfaceStubs 
> tests to quite the bots if that is what people want (and file a bug on 
> bugzilla).


Yes, please. A temporary workaround here that can be resolved later would be 
much appreciated to unblock our bots. Normally, I'd prefer a 
rollback-and-resubmit-with-fixes, but given that there have been multiple 
dependent changes submitted that would all have to be rolled back - whatever's 
the quickest way to get us back online without resorting to rolling back 
everything would be great :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69825



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

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

erichkeane wrote:
> jdoerfert wrote:
> > erichkeane wrote:
> > > I thought we had this stored somewhere else?  We probably should have 
> > > this be a constant somewhere in the frontend.  I THINK I remember doing a 
> > > review where I pulled this value into clang somewhere...
> > That was D72998, and I don't think Clang is the right place for this 
> > constant. It is a property of the llvm alignment attribute and it should 
> > live there. Thus, llvm/include/Attributes.h or some similar place. Can't we 
> > "fix" the linker error by making it a constexpr global or are the errors 
> > because of other file content? If the latter, we could go with a 
> > llvm/include/magic_constants.h ;)
> The one I was thinking of was this one: https://reviews.llvm.org/D68824
> 
> I don't remember what we came up with on the linking issue.  It would be 
> really nice if it was just something included from LLVM, but I think SEMA 
> typically doesn't include stuff from LLVM either.
I'm not too happy with the duplication of the constant but defining it once in 
clang is certainly better than having it in N places. For OpenMP we look into 
LLVM during SEMA and here there is an argument to be made that we should as 
well. I imagine more cases would pop up over time.

FWIW, if we allow to include LLVM headers, e.g., from IR or Frontend, we could 
still have a wrapper in SEMA to get the information so it doesn't expose the 
llvm:: namespace at the use sides (if that helps).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[PATCH] D69868: Allow "callbr" to return non-void values

[Bill Wendling via Phabricator via cfe-commits]

void added a comment.

@jyknight Do you think you'll have time to review this patch this week? I'd 
like to get it into the 10.0 release if possible. :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69868



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

[PATCH] D73005: [Codegen] If reasonable, materialize clang's `AssumeAlignedAttr` as llvm's Alignment Attribute on call-site function return value

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri marked 2 inline comments as done.
lebedev.ri added inline comments.



Comment at: clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c:12
 // CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
 // CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
 // CHECK-NEXT:ret i8* [[CALL]]

jdoerfert wrote:
> Why would we still emit the llvm.assume here?
Because it is for the second/other attribute - 
`__attribute__((alloc_align(2)))`.
This is **potentially** fixed by the next patch - D73006.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73005



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

[PATCH] D73005: [Codegen] If reasonable, materialize clang's `AssumeAlignedAttr` as llvm's Alignment Attribute on call-site function return value

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/test/CodeGen/assume-aligned-and-alloc-align-attributes.c:12
 // CHECK-NEXT:[[MASKCOND:%.*]] = icmp eq i64 [[MASKEDPTR]], 0
 // CHECK-NEXT:call void @llvm.assume(i1 [[MASKCOND]])
 // CHECK-NEXT:ret i8* [[CALL]]

Why would we still emit the llvm.assume here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73005



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

[PATCH] D71903: [Coroutines][6/6] Clang schedules new passes

[Brian Gesiak via Phabricator via cfe-commits]

modocache updated this revision to Diff 239437.
modocache added a comment.

Rebase past D72547 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71903

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
  llvm/include/llvm/Passes/PassBuilder.h
  llvm/lib/Passes/PassBuilder.cpp

Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -239,6 +239,7 @@
   SLPVectorization = RunSLPVectorization;
   LoopUnrolling = true;
   ForgetAllSCEVInLoopUnroll = ForgetSCEVInLoopUnroll;
+  Coroutines = false;
   LicmMssaOptCap = SetLicmMssaOptCap;
   LicmMssaNoAccForPromotionCap = SetLicmMssaNoAccForPromotionCap;
 }
@@ -718,6 +719,8 @@
   EarlyFPM.addPass(SROA());
   EarlyFPM.addPass(EarlyCSEPass());
   EarlyFPM.addPass(LowerExpectIntrinsicPass());
+  if (PTO.Coroutines)
+EarlyFPM.addPass(CoroEarlyPass());
   if (Level == OptimizationLevel::O3)
 EarlyFPM.addPass(CallSiteSplittingPass());
 
@@ -832,6 +835,11 @@
 IP.HotCallSiteThreshold = 0;
   MainCGPipeline.addPass(InlinerPass(IP));
 
+  if (PTO.Coroutines) {
+MainCGPipeline.addPass(CoroSplitPass());
+MainCGPipeline.addPass(createCGSCCToFunctionPassAdaptor(CoroElidePass()));
+  }
+
   // Now deduce any function attributes based in the current code.
   MainCGPipeline.addPass(PostOrderFunctionAttrsPass());
 
@@ -1026,6 +1034,9 @@
   // inserting redundancies into the program. This even includes SimplifyCFG.
   OptimizePM.addPass(SpeculateAroundPHIsPass());
 
+  if (PTO.Coroutines)
+OptimizePM.addPass(CoroCleanupPass());
+
   for (auto  : OptimizerLastEPCallbacks)
 C(OptimizePM, Level);
 
Index: llvm/include/llvm/Passes/PassBuilder.h
===
--- llvm/include/llvm/Passes/PassBuilder.h
+++ llvm/include/llvm/Passes/PassBuilder.h
@@ -92,6 +92,12 @@
   /// is that of the flag: `-forget-scev-loop-unroll`.
   bool ForgetAllSCEVInLoopUnroll;
 
+  /// Tuning option to enable/disable coroutine intrinsic lowering. Its default
+  /// value is false. Frontends such as Clang may enable this conditionally. For
+  /// example, Clang enables this option if the flags `-std=c++2a` or above, or
+  /// `-fcoroutines-ts`, have been specified.
+  bool Coroutines;
+
   /// Tuning option to cap the number of calls to retrive clobbering accesses in
   /// MemorySSA, in LICM.
   unsigned LicmMssaOptCap;
Index: clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/coro-newpm-pipeline.cpp
@@ -0,0 +1,57 @@
+// Tests that coroutine passes are added to and run by the new pass manager
+// pipeline, at -O0 and above.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -o /dev/null \
+// RUN:   -fexperimental-new-pass-manager -fdebug-pass-manager -fcoroutines-ts \
+// RUN:   -O0 %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -o /dev/null \
+// RUN:   -fexperimental-new-pass-manager -fdebug-pass-manager -fcoroutines-ts \
+// RUN:   -O1 %s 2>&1 | FileCheck %s
+//
+// CHECK: Starting llvm::Module pass manager run.
+// CHECK: Running pass:{{.*}}CoroEarlyPass
+//
+// The first coro-split pass enqueues a second run of the entire CGSCC pipeline.
+// CHECK: Starting CGSCC pass manager run.
+// CHECK: Running pass: CoroSplitPass on (_Z3foov)
+// CHECK: Running pass:{{.*}}CoroElidePass{{.*}} on (_Z3foov)
+// CHECK: Finished CGSCC pass manager run.
+//
+// The second coro-split pass splits coroutine 'foo' into funclets
+// 'foo.resume', 'foo.destroy', and 'foo.cleanup'.
+// CHECK: Starting CGSCC pass manager run.
+// CHECK: Running pass: CoroSplitPass on (_Z3foov)
+// CHECK: Running pass:{{.*}}CoroElidePass{{.*}} on (_Z3foov)
+// CHECK: Finished CGSCC pass manager run.
+//
+// CHECK: Running pass:{{.*}}CoroCleanupPass
+// CHECK: Finished llvm::Module pass manager run.
+
+namespace std {
+namespace experimental {
+
+struct handle {};
+
+struct awaitable {
+  bool await_ready() { return true; }
+  void await_suspend(handle) {}
+  bool await_resume() { return true; }
+};
+
+template  struct coroutine_handle {
+  static handle from_address(void *address) { return {}; }
+};
+
+template  struct coroutine_traits {
+  struct promise_type {
+awaitable initial_suspend() { return {}; }
+awaitable final_suspend() { return {}; }
+void return_void() {}
+T get_return_object() { return T(); }
+void unhandled_exception() {}
+  };
+};
+} // namespace experimental
+} // namespace std
+
+void foo() { co_return; }
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ 

[PATCH] D73098: [clang-tidy] readability-identifier-naming disregards parameters restrictions on main like functions

[Nathan James via Phabricator via cfe-commits]

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

In D73098#1832131 , @Mordante wrote:

> Would it make sense to also allow wmain with wchar_t? 
> https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=vs-2019


Does wmain get used in a lot of projects. If it's very niche then I don't feel 
it warrants a place in here. If it does I'll add it in.




Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:474
   if (const auto *Decl = dyn_cast(D)) {
+if (isParamInMainLikeFunction(*Decl))
+  return SK_Invalid;

aaron.ballman wrote:
> I think a better approach may be to look at the `DeclContext` for the 
> `ParmVarDecl` object to see if it is a `FunctionDecl`, and if it is, call 
> `FunctionDecl::isMain()` to check.
I specifically didn't want to do that as is I want to get functions that act 
like main, usually the case when main itself dispatches to other functions with 
the same signature. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73098



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

[PATCH] D73140: [clangd] Add C++20 concepts support to TargetFinder

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

merge_guards_bot added a comment.

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

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

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

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



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73140



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

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

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

In D72982#1832233 , @aganea wrote:

> In D72982#1832209 , @phosek wrote:
>
> > We're seeing `Driver/cc-print-options.c` test failures after this change:
>
>
> Yes, seeing it too, I will commit a fix in a minute!


Fixed by rG133a7e631cee97965e310f0d110739217427fd3d 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72982



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

[PATCH] D73007: [Sema] Avoid Wrange-loop-analysis false positives

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaStmt.cpp:2703-2704
 // suggest the const reference type that would do so.
 // For instance, given "for (const  : Range)", suggest
 // "for (const Foo : Range)" to denote a copy is made for the loop.  If
 // possible, also suggest "for (const  : Range)" if this type prevents

aaronpuchert wrote:
> Mordante wrote:
> > aaronpuchert wrote:
> > > That's the part the bothers me.
> > I think we shouldn't remove the warning, it is useful. We can consider to 
> > move this out of -Wall, but I first like to hear the opinion of the other 
> > reviewers in this matter. If we want this change I'll be happy to create a 
> > new patch.
> I don't see a problem with having this as an optional warning that can be 
> turned on for those who want it.
> 
> Note that this isn't my personal opinion, I'm actually fine with it. But I've 
> met considerable resistance to turning the warning on before, and it's 
> somewhat hard to argue against that. Binding references to temporaries is 
> perfectly normal C++, and we don't discourage it anywhere else.
> I think we shouldn't remove the warning, it is useful. 

Agreed.

> We can consider to move this out of -Wall, but I first like to hear the 
> opinion of the other reviewers in this matter. If we want this change I'll be 
> happy to create a new patch.

We typically want warnings to be enabled by default and have a low-false 
positive rate so that users get the benefit of the diagnostic without undue 
effort (like manually disabling it because they find the diagnostics 
low-value). I think the point @aaronpuchert raises is an interesting one in 
that binding a reference to a temp is not necessarily wrong, so I could see 
some users wanting to disable the diagnostic rather than change their code, 
which suggests that -Wall may not be the best place for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73007



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

[PATCH] D73098: [clang-tidy] readability-identifier-naming disregards parameters restrictions on main like functions

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:474
   if (const auto *Decl = dyn_cast(D)) {
+if (isParamInMainLikeFunction(*Decl))
+  return SK_Invalid;

I think a better approach may be to look at the `DeclContext` for the 
`ParmVarDecl` object to see if it is a `FunctionDecl`, and if it is, call 
`FunctionDecl::isMain()` to check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73098



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

[PATCH] D73140: [clangd] Add C++20 concepts support to TargetFinder

[Nathan Ridge via Phabricator via cfe-commits]

nridge created this revision.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D73140

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


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -331,6 +331,24 @@
{"struct Test", Rel::TemplatePattern});
 }
 
+TEST_F(TargetDeclTest, Concept) {
+  Code = R"cpp(
+template 
+concept Fooable = requires (T t) { t.foo(); };
+
+template  requires [[Fooable]]
+void bar(T t) {
+  t.foo();
+}
+  )cpp";
+  Flags.push_back("-std=c++2a");
+  EXPECT_DECLS(
+  "ConceptSpecializationExpr",
+  // FIXME: Should we truncate the pretty-printed form of a concept decl
+  // somewhere?
+  {"template  concept Fooable = requires (T t) { t.foo(); 
};"});
+}
+
 TEST_F(TargetDeclTest, FunctionTemplate) {
   Code = R"cpp(
 // Implicit specialization.
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -17,6 +17,7 @@
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/PrettyPrinter.h"
@@ -279,6 +280,9 @@
   void VisitCallExpr(const CallExpr *CE) {
 Outer.add(CE->getCalleeDecl(), Flags);
   }
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
+Outer.add(E->getNamedConcept(), Flags);
+  }
   void VisitDeclRefExpr(const DeclRefExpr *DRE) {
 const Decl *D = DRE->getDecl();
 // UsingShadowDecl allows us to record the UsingDecl.


Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -331,6 +331,24 @@
{"struct Test", Rel::TemplatePattern});
 }
 
+TEST_F(TargetDeclTest, Concept) {
+  Code = R"cpp(
+template 
+concept Fooable = requires (T t) { t.foo(); };
+
+template  requires [[Fooable]]
+void bar(T t) {
+  t.foo();
+}
+  )cpp";
+  Flags.push_back("-std=c++2a");
+  EXPECT_DECLS(
+  "ConceptSpecializationExpr",
+  // FIXME: Should we truncate the pretty-printed form of a concept decl
+  // somewhere?
+  {"template  concept Fooable = requires (T t) { t.foo(); };"});
+}
+
 TEST_F(TargetDeclTest, FunctionTemplate) {
   Code = R"cpp(
 // Implicit specialization.
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -17,6 +17,7 @@
 #include "clang/AST/DeclarationName.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/NestedNameSpecifier.h"
 #include "clang/AST/PrettyPrinter.h"
@@ -279,6 +280,9 @@
   void VisitCallExpr(const CallExpr *CE) {
 Outer.add(CE->getCalleeDecl(), Flags);
   }
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
+Outer.add(E->getNamedConcept(), Flags);
+  }
   void VisitDeclRefExpr(const DeclRefExpr *DRE) {
 const Decl *D = DRE->getDecl();
 // UsingShadowDecl allows us to record the UsingDecl.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72434: Support offset of member designator with the arrow for __builtin_offsetof

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Testcase?

I assume we give appropriate errors if you try to use "->" on a member that's 
not an array?




Comment at: clang/lib/Parse/ParseExpr.cpp:2168
 
-// FIXME: This loop leaks the index expressions on error.
 while (1) {

Did you fix this FIXME? Or does it no longer apply?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72434



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

[clang] 133a7e6 - [PATCH] Reland [Clang] Un-break scan-build after integrated-cc1 change

[Alexandre Ganea via cfe-commits]

Author: Alexandre Ganea
Date: 2020-01-21T17:03:00-05:00
New Revision: 133a7e631cee97965e310f0d110739217427fd3d

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

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

The issue was reported by @xazax.hun here: 
https://reviews.llvm.org/D69825#1827826

"This patch (D69825) breaks scan-build-py which parses the output of "-###" to 
get -cc1 command. There might be other tools with the same problems. Could we 
either remove (in-process) from CC1Command::Print or add a line break?

Having the last line as a valid invocation is valuable and there might be tools 
relying on that."

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

Added: 


Modified: 
clang/lib/Driver/Compilation.cpp
clang/lib/Driver/Job.cpp
clang/test/Driver/cc-print-options.c
clang/test/Driver/cuda-simple.cu
clang/test/Driver/offloading-interoperability.c
clang/test/Driver/option-aliases.c

Removed: 




diff  --git a/clang/lib/Driver/Compilation.cpp 
b/clang/lib/Driver/Compilation.cpp
index ba188f5c4083..25aec3690f21 100644
--- a/clang/lib/Driver/Compilation.cpp
+++ b/clang/lib/Driver/Compilation.cpp
@@ -172,7 +172,7 @@ int Compilation::ExecuteCommand(const Command ,
 }
 
 if (getDriver().CCPrintOptions)
-  *OS << "[Logging clang options]";
+  *OS << "[Logging clang options]\n";
 
 C.Print(*OS, "\n", /*Quote=*/getDriver().CCPrintOptions);
   }

diff  --git a/clang/lib/Driver/Job.cpp b/clang/lib/Driver/Job.cpp
index d57c3a1cdbb8..7dab2a022d92 100644
--- a/clang/lib/Driver/Job.cpp
+++ b/clang/lib/Driver/Job.cpp
@@ -373,7 +373,7 @@ int Command::Execute(ArrayRef> 
Redirects,
 
 void CC1Command::Print(raw_ostream , const char *Terminator, bool Quote,
CrashReportInfo *CrashInfo) const {
-  OS << " (in-process)";
+  OS << " (in-process)\n";
   Command::Print(OS, Terminator, Quote, CrashInfo);
 }
 

diff  --git a/clang/test/Driver/cc-print-options.c 
b/clang/test/Driver/cc-print-options.c
index 77dd0fef5f98..dc7f4a3ac35c 100644
--- a/clang/test/Driver/cc-print-options.c
+++ b/clang/test/Driver/cc-print-options.c
@@ -3,5 +3,6 @@
 // RUN: %clang -no-canonical-prefixes -S -o %t.s %s
 // RUN: FileCheck %s < %t.log
 
-// CHECK: [Logging clang options]{{.*}}clang{{.*}}"-S"
+// CHECK: [Logging clang options]
+// CHECK: {{.*}}clang{{.*}}"-S"
 

diff  --git a/clang/test/Driver/cuda-simple.cu 
b/clang/test/Driver/cuda-simple.cu
index b6840be4e2e5..54e18403108b 100644
--- a/clang/test/Driver/cuda-simple.cu
+++ b/clang/test/Driver/cuda-simple.cu
@@ -5,10 +5,10 @@
 // Verify that we pass -x cuda-cpp-output to compiler after
 // preprocessing a CUDA file
 // RUN: %clang  -Werror -### -save-temps -c %s 2>&1 | FileCheck %s
-// CHECK: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-E"
 // CHECK: "-x" "cuda"
-// CHECK-NEXT: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-x" "cuda-cpp-output"
 //
 // Verify that compiler accepts CUDA syntax with "-x cuda-cpp-output".

diff  --git a/clang/test/Driver/offloading-interoperability.c 
b/clang/test/Driver/offloading-interoperability.c
index 9c80d91d1d78..c3a72f0dfe2a 100644
--- a/clang/test/Driver/offloading-interoperability.c
+++ b/clang/test/Driver/offloading-interoperability.c
@@ -8,10 +8,10 @@
 // RUN: %clang -no-canonical-prefixes -### -x cuda -target 
powerpc64le-linux-gnu -std=c++11 --cuda-gpu-arch=sm_35 -fopenmp=libomp %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix NO-OPENMP-FLAGS-FOR-CUDA-DEVICE
 //
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NOT:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: ptxas" "-m64"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: fatbinary"{{( "--cuda")?}} "-64"
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: {{ld(.exe)?"}} {{.*}}"-m" "elf64lppc"

diff  --git a/clang/test/Driver/option-aliases.c 
b/clang/test/Driver/option-aliases.c
index 9cd9252a4832..e50289cc3bdf 100644
--- a/clang/test/Driver/option-aliases.c
+++ b/clang/test/Driver/option-aliases.c
@@ -3,12 +3,12 @@
 // RUN: --param=FOO --output=FOO %s 2>&1 | \
 // RUN: FileCheck %s
 
-// CHECK: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-E"
 // CHECK: "-U" "FOO"
 // CHECK: "-U" "BAR"
 // CHECK: "-o" "option-aliases.i"
 
-// CHECK-NEXT: "-cc1"
+// CHECK-LABEL: "-cc1"
 // CHECK: "-S"
 // CHECK: "-o" "FOO"

[PATCH] D71566: New checks for fortified sprintf

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

(There are still some minor whitespace nits to resolve as well.)




Comment at: clang/lib/Sema/SemaChecking.cpp:743
+  }
+  assert(UsedSize && "Found a size estimate");
+  if (UsedSize.getValue().ule(ObjectSize))

I think this assertion can be triggered in the case where no `UsedSize` was 
specified but then `UsedSizeArg` evaluates to `0`, can't it? Or does something 
catch that case and diagnose?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71566



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

[PATCH] D71913: [LTO/WPD] Enable aggressive WPD under LTO option

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson marked 5 inline comments as done.
tejohnson added inline comments.



Comment at: clang/test/CodeGenCXX/lto-visibility-inference.cpp:73
   c1->f();
-  // ITANIUM-NOT: type.test{{.*}}!"_ZTS2C2"
+  // ITANIUM: type.test{{.*}}!"_ZTS2C2"
   // MS: type.test{{.*}}!"?AUC2@@"

evgeny777 wrote:
> tejohnson wrote:
> > evgeny777 wrote:
> > > What caused this and other changes in this file?
> > Because we now will insert type tests for non-hidden vtables. This is 
> > enabled by the changes to LTO to interpret these based on the 
> > vcall_visibility metadata.
> The results of this test case
> ```
> %clang_cc1 -flto -triple x86_64-pc-windows-msvc -std=c++11 -fms-extensions 
> -fwhole-program-vtables -flto-visibility-public-std -emit-llvm -o - %s | 
> FileCheck --check-prefix=MS --check-prefix=MS-NOSTD %s
> ```
> look not correct to me. I think you shouldn't generate type tests for 
> standard library classes with  `-flto-visibility-public-std`. Currently if 
> this flag is given, clang doesn't do this either even with 
> `-fvisibility=hidden`
The associated vtables would get the vcall_visibility public metadata, so the 
type tests themselves aren't problematic. I tend to think that an application 
using such options should simply stick with -fvisibility=hidden to get WPD and 
not use the new LTO option to convert all public vcall_visibility metadata to 
hidden.



Comment at: clang/test/CodeGenCXX/thinlto-distributed-type-metadata.cpp:7
+// as expected.
+// RUN: %clang_cc1 -flto=thin -flto-unit -triple x86_64-unknown-linux 
-fvisibility hidden -fwhole-program-vtables -emit-llvm-bc -o %t.o %s
+// RUN: llvm-dis %t.o -o - | FileCheck --check-prefix=TT %s

evgeny777 wrote:
> I think, we no longer need `-fvisibility hidden` here, do we?
Right, we aren't relying on the visibility for this test which is just ensuring 
the type tests are lowered properly in the distributed backends. I removed it.



Comment at: llvm/lib/LTO/ThinLTOCodeGenerator.cpp:976
+  // via the internal option. Must be done before WPD below.
+  updateVCallVisibilityInIndex(*Index);
+

evgeny777 wrote:
> evgeny777 wrote:
> > ditto
> updateVCallVisibilityInIndex(*Index, /* WholeProgramVisibilityEnabledInLTO */ 
> false) ?
Missed this one before (did the InModule version but not InIndex), fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71913



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

[PATCH] D71913: [LTO/WPD] Enable aggressive WPD under LTO option

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson updated this revision to Diff 239428.
tejohnson marked 2 inline comments as done.
tejohnson added a comment.

Address comments and rebase. Also apply modified change to ItaniumCXXABI.cpp
and a change to an associated test (cfi-mfcall.cpp) here as discussed
in child revision D71907 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71913

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGenCXX/cfi-mfcall.cpp
  clang/test/CodeGenCXX/lto-visibility-inference.cpp
  clang/test/CodeGenCXX/thinlto-distributed-type-metadata.cpp
  clang/test/CodeGenCXX/type-metadata.cpp
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/LTO.cpp
  lld/ELF/Options.td
  lld/test/ELF/lto/devirt_vcall_vis_public.ll
  llvm/include/llvm/LTO/Config.h
  llvm/include/llvm/Transforms/IPO.h
  llvm/include/llvm/Transforms/IPO/LowerTypeTests.h
  llvm/include/llvm/Transforms/IPO/WholeProgramDevirt.h
  llvm/lib/LTO/LTO.cpp
  llvm/lib/LTO/LTOCodeGenerator.cpp
  llvm/lib/LTO/ThinLTOCodeGenerator.cpp
  llvm/lib/Transforms/IPO/LowerTypeTests.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/ThinLTO/X86/cache-typeid-resolutions.ll
  llvm/test/ThinLTO/X86/cfi-devirt.ll
  llvm/test/ThinLTO/X86/devirt-after-icp.ll
  llvm/test/ThinLTO/X86/devirt.ll
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/ThinLTO/X86/devirt_alias.ll
  llvm/test/ThinLTO/X86/devirt_available_externally.ll
  llvm/test/ThinLTO/X86/devirt_external_comdat_same_guid.ll
  llvm/test/ThinLTO/X86/devirt_promote.ll
  llvm/test/ThinLTO/X86/devirt_promote_legacy.ll
  llvm/test/ThinLTO/X86/devirt_single_hybrid.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_hidden.ll
  llvm/test/ThinLTO/X86/devirt_vcall_vis_public.ll
  llvm/test/Transforms/WholeProgramDevirt/bad-read-from-vtable.ll
  llvm/test/Transforms/WholeProgramDevirt/branch-funnel-threshold.ll
  llvm/test/Transforms/WholeProgramDevirt/branch-funnel.ll
  llvm/test/Transforms/WholeProgramDevirt/constant-arg.ll
  llvm/test/Transforms/WholeProgramDevirt/devirt-single-impl-check.ll
  llvm/test/Transforms/WholeProgramDevirt/devirt-single-impl.ll
  llvm/test/Transforms/WholeProgramDevirt/expand-check.ll
  llvm/test/Transforms/WholeProgramDevirt/export-nothing.ll
  llvm/test/Transforms/WholeProgramDevirt/export-single-impl.ll
  llvm/test/Transforms/WholeProgramDevirt/export-uniform-ret-val.ll
  llvm/test/Transforms/WholeProgramDevirt/export-unique-ret-val.ll
  llvm/test/Transforms/WholeProgramDevirt/export-unsuccessful-checked.ll
  llvm/test/Transforms/WholeProgramDevirt/export-vcp.ll
  llvm/test/Transforms/WholeProgramDevirt/non-constant-vtable.ll
  llvm/test/Transforms/WholeProgramDevirt/pointer-vtable.ll
  llvm/test/Transforms/WholeProgramDevirt/soa-vtable.ll
  llvm/test/Transforms/WholeProgramDevirt/struct-vtable.ll
  llvm/test/Transforms/WholeProgramDevirt/uniform-retval-invoke.ll
  llvm/test/Transforms/WholeProgramDevirt/uniform-retval.ll
  llvm/test/Transforms/WholeProgramDevirt/unique-retval.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-accesses-memory.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-decl.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-no-this.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-non-constant-arg.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-too-wide-ints.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-type-mismatch.ll
  llvm/test/Transforms/WholeProgramDevirt/vcp-uses-this.ll
  llvm/test/Transforms/WholeProgramDevirt/virtual-const-prop-begin.ll
  llvm/test/Transforms/WholeProgramDevirt/virtual-const-prop-check.ll
  llvm/test/Transforms/WholeProgramDevirt/virtual-const-prop-end.ll
  llvm/test/Transforms/WholeProgramDevirt/vtable-decl.ll
  llvm/test/tools/gold/X86/devirt_vcall_vis_public.ll
  llvm/tools/gold/gold-plugin.cpp
  llvm/tools/opt/opt.cpp

Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -54,6 +54,7 @@
 #include "llvm/Transforms/Coroutines.h"
 #include "llvm/Transforms/IPO/AlwaysInliner.h"
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
+#include "llvm/Transforms/IPO/WholeProgramDevirt.h"
 #include "llvm/Transforms/Utils/Cloning.h"
 #include "llvm/Transforms/Utils/Debugify.h"
 #include 
@@ -625,6 +626,13 @@
 return 1;
   }
 
+  // Enable testing of whole program devirtualization on this module by invoking
+  // the facility for updating public visibility to linkage unit visibility when
+  // specified by an internal option. This is normally done during LTO which is
+  // not performed via opt.
+  updateVCallVisibilityInModule(*M,
+/* WholeProgramVisibilityEnabledInLTO */ false);
+
   // Figure out what stream we are supposed to write to...
   std::unique_ptr Out;
   std::unique_ptr 

[PATCH] D72747: [objc_direct] Allow for direct messages be sent to `self` when it is a Class

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

Please add a test that exercises path without ARC enabled.




Comment at: clang/lib/Sema/SemaExprObjC.cpp:3019
+if (ReceiverType->isObjCClassType() && !isImplicit &&
+(!Receiver->isObjCSelfExpr() || !getLangOpts().ObjCAutoRefCount)) {
   Diag(Receiver->getExprLoc(),

NIT: It feels easier to read if the condition is `&& 
!(Receiver->isObjCSelfExpr() && getLangOpts().ObjCAutoRefCount)`.


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

https://reviews.llvm.org/D72747



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

[PATCH] D61365: [libcxx] [test] Suppress float->int narrowing warning in vector range-construction test.

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal abandoned this revision.
BillyONeal added a comment.

It looks like someone already fixed this.


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

https://reviews.llvm.org/D61365



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

[PATCH] D72717: [CMake] Disable libc++ filesystem tests in CrossWinToARMLinux cache file

[Vlad Vereschaka via Phabricator via cfe-commits]

vvereschaka added a comment.

> You mean, instead of ninja check-cxx just invoke LIT directly and pass this 
> argument?

No, a little bit different. 
Probably we need something like 'LIBCXX_LLVM_LIT_ARGS` and pass the LIT 
arguments into the libc++ tests through that kind of parameter (and most likely 
extend a common LIT_ARGS).
In that case we can pass  '--param enable_filesystem=False' using the buildbot 
configuration files.
Or through this cmake cache file if this is a common case for the arm cross 
builds on Windows.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72717



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

[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

cchen wrote:
> cchen wrote:
> > ABataev wrote:
> > > cchen wrote:
> > > > ABataev wrote:
> > > > > cchen wrote:
> > > > > > cchen wrote:
> > > > > > > ABataev wrote:
> > > > > > > > Why just the LHS is analyzed? Also, what about support for 
> > > > > > > > other expressions, like casting, call, choose etc., which may 
> > > > > > > > result in lvalue?
> > > > > > > 1. LHS: I'll fix that
> > > > > > > 2. I'll add support for casting, call, etc
> > > > > > > 3. For "choose" are you referring to something like (a < b ? b : 
> > > > > > > a)?
> > > > > > For the handling of BinaryOperator, I'm not sure why should we 
> > > > > > handle RHS since the possible source code I can imagine is 
> > > > > > `*(ptr+l)` or something like `(ptr+l)[3]`.
> > > > > `*(2+ptr)` is correct too. And, btw, `3[ptr+1]` too, especially in C. 
> > > > > Moreover, something like `*(b+c)` is also allowed. That's why I said 
> > > > > that better to avoid deep analysis of lvalues, there are too many 
> > > > > combinations and better to switch to something basic.
> > > > But at least we need the base declaration for motion/map clause, right? 
> > > > And to achieve this, we need to peel the expression to get the 
> > > > DeclRefExpr.
> > > What's the base declaration in `*(a+b)`?
> > I understand your point, I'm just not sure how to handle (do not analyze) 
> > this given that we need to fill VarDecl for OMPToClause/OMPFromClause.
> But is *(a+b) even valid? Clang and GCC both emit error message: 
> https://godbolt.org/z/jqDBx_
Yes, in this form it is not. But here is another form `*(a+*b)` or 
`*(a+(unsigned long long)b)`. You an try to filter rvalues out of all these 
forms, though and still try to find a base decl. But still, there are going to 
be some cases where you won't be possible to handle them correctly, like 
`foo()`.
If you still want to dig that deep, I would recommend to use 
RecursiseStmtVisitor. If an expression is rvalue - throw it out of analysis. If 
base decl is not single, not variable and not member decl - emit an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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

[PATCH] D73138: [libcxx] [test] Correct asserted type in subspan test; subspan with count should never produce dynamic_extent

[Billy Robert O'Neal III via Phabricator via cfe-commits]

BillyONeal created this revision.
BillyONeal added reviewers: ldionne, EricWF, mclow.lists.
Herald added subscribers: dexonsmith, christof.

I'm not sure if this was a change in the standard behavior or if it was a typo 
in libcxx from the beginning. http://eel.is/c++draft/span.sub#10 says that if a 
count is supplied, the returned span is always of that count, never of 
dynamic_extent, so these tests were asserting incorrectly.

I'm not sure what to do about this as fixing the test to assert correctly (and 
thus make msvc++ pass) is going to make libcxx fail.


https://reviews.llvm.org/D73138

Files:
  libcxx/test/std/containers/views/span.sub/subspan.pass.cpp


Index: libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
===
--- libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
+++ libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
@@ -37,7 +37,7 @@
 using S2 = decltype(s2);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S1::value_type);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S2::value_type);
-static_assert(S1::extent == (Span::extent == std::dynamic_extent ? 
std::dynamic_extent : Count), "");
+static_assert(S1::extent == Count, "");
 static_assert(S2::extent == std::dynamic_extent, "");
 return
 s1.data() == s2.data()
@@ -76,7 +76,7 @@
 using S2 = decltype(s2);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S1::value_type);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S2::value_type);
-static_assert(S1::extent == (Span::extent == std::dynamic_extent ? 
std::dynamic_extent : Count), "");
+static_assert(S1::extent == Count, "");
 static_assert(S2::extent == std::dynamic_extent, "");
 assert(s1.data() == s2.data());
 assert(s1.size() == s2.size());


Index: libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
===
--- libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
+++ libcxx/test/std/containers/views/span.sub/subspan.pass.cpp
@@ -37,7 +37,7 @@
 using S2 = decltype(s2);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S1::value_type);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S2::value_type);
-static_assert(S1::extent == (Span::extent == std::dynamic_extent ? std::dynamic_extent : Count), "");
+static_assert(S1::extent == Count, "");
 static_assert(S2::extent == std::dynamic_extent, "");
 return
 s1.data() == s2.data()
@@ -76,7 +76,7 @@
 using S2 = decltype(s2);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S1::value_type);
 ASSERT_SAME_TYPE(typename Span::value_type, typename S2::value_type);
-static_assert(S1::extent == (Span::extent == std::dynamic_extent ? std::dynamic_extent : Count), "");
+static_assert(S1::extent == Count, "");
 static_assert(S2::extent == std::dynamic_extent, "");
 assert(s1.data() == s2.data());
 assert(s1.size() == s2.size());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72998: [IR] Attribute/AttrBuilder: use Value::MaximumAlignment magic constant

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri updated this revision to Diff 239421.
lebedev.ri added a comment.

Add constants to `Sema` class.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72998

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  llvm/lib/IR/Attributes.cpp

Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -143,7 +143,7 @@
 }
 
 Attribute Attribute::getWithAlignment(LLVMContext , Align A) {
-  assert(A <= 0x4000 && "Alignment too large.");
+  assert(A <= llvm::Value::MaximumAlignment && "Alignment too large.");
   return get(Context, Alignment, A.value());
 }
 
@@ -1525,7 +1525,7 @@
   if (!Align)
 return *this;
 
-  assert(*Align <= 0x4000 && "Alignment too large.");
+  assert(*Align <= llvm::Value::MaximumAlignment && "Alignment too large.");
 
   Attrs[Attribute::Alignment] = true;
   Alignment = Align;
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1626,11 +1626,9 @@
   return;
 }
 
-// Alignment calculations can wrap around if it's greater than 2**29.
-unsigned MaximumAlignment = 536870912;
-if (I > MaximumAlignment)
+if (I > Sema::MaximumAlignment)
   Diag(CI.getLoc(), diag::warn_assume_aligned_too_great)
-  << CI.getRange() << MaximumAlignment;
+  << CI.getRange() << Sema::MaximumAlignment;
   }
 
   if (OE) {
@@ -3815,13 +3813,9 @@
 }
   }
 
-  // Alignment calculations can wrap around if it's greater than 2**28.
-  unsigned MaxValidAlignment =
-  Context.getTargetInfo().getTriple().isOSBinFormatCOFF() ? 8192
-  : 268435456;
-  if (AlignVal > MaxValidAlignment) {
-Diag(AttrLoc, diag::err_attribute_aligned_too_great) << MaxValidAlignment
- << E->getSourceRange();
+  if (AlignVal > Sema::MaximumAlignment) {
+Diag(AttrLoc, diag::err_attribute_aligned_too_great)
+<< Sema::MaximumAlignment << E->getSourceRange();
 return;
   }
 
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3665,11 +3665,9 @@
   return;
 }
 
-// Alignment calculations can wrap around if it's greater than 2**29.
-unsigned MaximumAlignment = 536870912;
-if (I > MaximumAlignment)
+if (I > Sema::MaximumAlignment)
   Diag(Arg->getExprLoc(), diag::warn_assume_aligned_too_great)
-  << Arg->getSourceRange() << MaximumAlignment;
+  << Arg->getSourceRange() << Sema::MaximumAlignment;
   }
 }
   }
@@ -5394,11 +5392,9 @@
   return Diag(TheCall->getBeginLoc(), diag::err_alignment_not_power_of_two)
  << Arg->getSourceRange();
 
-// Alignment calculations can wrap around if it's greater than 2**29.
-unsigned MaximumAlignment = 536870912;
-if (Result > MaximumAlignment)
+if (Result > Sema::MaximumAlignment)
   Diag(TheCall->getBeginLoc(), diag::warn_assume_aligned_too_great)
-  << Arg->getSourceRange() << MaximumAlignment;
+  << Arg->getSourceRange() << Sema::MaximumAlignment;
   }
 
   if (NumArgs > 2) {
Index: clang/include/clang/Sema/Sema.h
===
--- clang/include/clang/Sema/Sema.h
+++ clang/include/clang/Sema/Sema.h
@@ -372,6 +372,15 @@
   QualType ResultTy,
   ArrayRef Args);
 
+  /// The maximum alignment, same as in llvm::Value. We duplicate them here
+  /// because that allows us not to duplicate the constants in clang code,
+  /// which we must to since we can't directly use the llvm constants.
+  ///
+  /// This is the greatest alignment value supported by load, store, and alloca
+  /// instructions, and global values.
+  static const unsigned MaxAlignmentExponent = 29;
+  static const unsigned MaximumAlignment = 1u << MaxAlignmentExponent;
+
 public:
   typedef OpaquePtr DeclGroupPtrTy;
   typedef OpaquePtr TemplateTy;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D73120: [Clang] Alternate fix for "expansion of response files in -Wp after integrated-cc1 change"

[Alexandre Ganea via Phabricator via cfe-commits]

aganea updated this revision to Diff 239420.
aganea added a comment.

Remove `Reenter` flag as requested by @hans here 
.


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

https://reviews.llvm.org/D73120

Files:
  clang/include/clang/Driver/Driver.h
  clang/test/Driver/Wp-args.c
  clang/tools/driver/driver.cpp


Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -241,8 +241,6 @@
   *NumberSignPtr = '=';
 }
 
-static int ExecuteCC1Tool(ArrayRef argv);
-
 static void SetBackdoorDriverOutputsFromEnvVars(Driver ) {
   // Handle CC_PRINT_OPTIONS and CC_PRINT_OPTIONS_FILE.
   TheDriver.CCPrintOptions = !!::getenv("CC_PRINT_OPTIONS");
@@ -313,21 +311,27 @@
 TheDriver.setInstalledDir(InstalledPathParent);
 }
 
-static int ExecuteCC1Tool(ArrayRef argv) {
+static int ExecuteCC1Tool(SmallVectorImpl ) {
   // If we call the cc1 tool from the clangDriver library (through
   // Driver::CC1Main), we need to clean up the options usage count. The options
   // are currently global, and they might have been used previously by the
   // driver.
   llvm::cl::ResetAllOptionOccurrences();
-  StringRef Tool = argv[1];
-  void *GetExecutablePathVP = (void *)(intptr_t) GetExecutablePath;
+
+  llvm::BumpPtrAllocator A;
+  llvm::StringSaver Saver(A);
+  llvm::cl::ExpandResponseFiles(Saver, ::cl::TokenizeGNUCommandLine, ArgV,
+/*MarkEOLs=*/false);
+  StringRef Tool = ArgV[1];
+  void *GetExecutablePathVP = (void *)(intptr_t)GetExecutablePath;
   if (Tool == "-cc1")
-return cc1_main(argv.slice(2), argv[0], GetExecutablePathVP);
+return cc1_main(makeArrayRef(ArgV).slice(2), ArgV[0], GetExecutablePathVP);
   if (Tool == "-cc1as")
-return cc1as_main(argv.slice(2), argv[0], GetExecutablePathVP);
+return cc1as_main(makeArrayRef(ArgV).slice(2), ArgV[0],
+  GetExecutablePathVP);
   if (Tool == "-cc1gen-reproducer")
-return cc1gen_reproducer_main(argv.slice(2), argv[0], GetExecutablePathVP);
-
+return cc1gen_reproducer_main(makeArrayRef(ArgV).slice(2), ArgV[0],
+  GetExecutablePathVP);
   // Reject unknown tools.
   llvm::errs() << "error: unknown integrated tool '" << Tool << "'. "
<< "Valid tools include '-cc1' and '-cc1as'.\n";
Index: clang/test/Driver/Wp-args.c
===
--- clang/test/Driver/Wp-args.c
+++ clang/test/Driver/Wp-args.c
@@ -19,3 +19,9 @@
 // MMD: "-cc1"
 // MMD-NOT: -MMD
 // MMD: "-dependency-file" "Wp-args.d"
+
+// Ensure response files are properly expanded with -Wp
+// RUN: echo -rewrite-macros > %t.rsp
+// RUN: %clang -Wp,@%t.rsp -E %s | FileCheck -check-prefix RSP %s
+
+// RSP: inception
Index: clang/include/clang/Driver/Driver.h
===
--- clang/include/clang/Driver/Driver.h
+++ clang/include/clang/Driver/Driver.h
@@ -208,7 +208,7 @@
   /// When the clangDriver lib is used through clang.exe, this provides a
   /// shortcut for executing the -cc1 command-line directly, in the same
   /// process.
-  typedef int (*CC1ToolFunc)(ArrayRef argv);
+  typedef int (*CC1ToolFunc)(SmallVectorImpl );
   CC1ToolFunc CC1Main = nullptr;
 
 private:


Index: clang/tools/driver/driver.cpp
===
--- clang/tools/driver/driver.cpp
+++ clang/tools/driver/driver.cpp
@@ -241,8 +241,6 @@
   *NumberSignPtr = '=';
 }
 
-static int ExecuteCC1Tool(ArrayRef argv);
-
 static void SetBackdoorDriverOutputsFromEnvVars(Driver ) {
   // Handle CC_PRINT_OPTIONS and CC_PRINT_OPTIONS_FILE.
   TheDriver.CCPrintOptions = !!::getenv("CC_PRINT_OPTIONS");
@@ -313,21 +311,27 @@
 TheDriver.setInstalledDir(InstalledPathParent);
 }
 
-static int ExecuteCC1Tool(ArrayRef argv) {
+static int ExecuteCC1Tool(SmallVectorImpl ) {
   // If we call the cc1 tool from the clangDriver library (through
   // Driver::CC1Main), we need to clean up the options usage count. The options
   // are currently global, and they might have been used previously by the
   // driver.
   llvm::cl::ResetAllOptionOccurrences();
-  StringRef Tool = argv[1];
-  void *GetExecutablePathVP = (void *)(intptr_t) GetExecutablePath;
+
+  llvm::BumpPtrAllocator A;
+  llvm::StringSaver Saver(A);
+  llvm::cl::ExpandResponseFiles(Saver, ::cl::TokenizeGNUCommandLine, ArgV,
+/*MarkEOLs=*/false);
+  StringRef Tool = ArgV[1];
+  void *GetExecutablePathVP = (void *)(intptr_t)GetExecutablePath;
   if (Tool == "-cc1")
-return cc1_main(argv.slice(2), argv[0], GetExecutablePathVP);
+return cc1_main(makeArrayRef(ArgV).slice(2), ArgV[0], GetExecutablePathVP);
   if (Tool == "-cc1as")
-return cc1as_main(argv.slice(2), argv[0], GetExecutablePathVP);
+return 

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri marked an inline comment as done.
lebedev.ri added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4479
+const Expr *Arg = Args[AA->getParamIndex().getASTIndex()];
+if (!Arg->isTypeDependent() && !Arg->isValueDependent()) {
+  llvm::APSInt I(64);

erichkeane wrote:
> Does this need to be isInstantionDependent?
I'm not sure, should it be?
It seems there is no such check in `Sema::SemaBuiltinAssumeAligned()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

jdoerfert wrote:
> erichkeane wrote:
> > I thought we had this stored somewhere else?  We probably should have this 
> > be a constant somewhere in the frontend.  I THINK I remember doing a review 
> > where I pulled this value into clang somewhere...
> That was D72998, and I don't think Clang is the right place for this 
> constant. It is a property of the llvm alignment attribute and it should live 
> there. Thus, llvm/include/Attributes.h or some similar place. Can't we "fix" 
> the linker error by making it a constexpr global or are the errors because of 
> other file content? If the latter, we could go with a 
> llvm/include/magic_constants.h ;)
The one I was thinking of was this one: https://reviews.llvm.org/D68824

I don't remember what we came up with on the linking issue.  It would be really 
nice if it was just something included from LLVM, but I think SEMA typically 
doesn't include stuff from LLVM either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[PATCH] D73060: [Clang] Fix expansion of response files in -Wp after integrated-cc1 change

[Alexandre Ganea via Phabricator via cfe-commits]

aganea abandoned this revision.
aganea added a comment.

Abandoning this in favor of D73120 . Please 
take a look at the other patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73060



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

[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

[Chi Chun Chen via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

cchen wrote:
> ABataev wrote:
> > cchen wrote:
> > > ABataev wrote:
> > > > cchen wrote:
> > > > > cchen wrote:
> > > > > > ABataev wrote:
> > > > > > > Why just the LHS is analyzed? Also, what about support for other 
> > > > > > > expressions, like casting, call, choose etc., which may result in 
> > > > > > > lvalue?
> > > > > > 1. LHS: I'll fix that
> > > > > > 2. I'll add support for casting, call, etc
> > > > > > 3. For "choose" are you referring to something like (a < b ? b : a)?
> > > > > For the handling of BinaryOperator, I'm not sure why should we handle 
> > > > > RHS since the possible source code I can imagine is `*(ptr+l)` or 
> > > > > something like `(ptr+l)[3]`.
> > > > `*(2+ptr)` is correct too. And, btw, `3[ptr+1]` too, especially in C. 
> > > > Moreover, something like `*(b+c)` is also allowed. That's why I said 
> > > > that better to avoid deep analysis of lvalues, there are too many 
> > > > combinations and better to switch to something basic.
> > > But at least we need the base declaration for motion/map clause, right? 
> > > And to achieve this, we need to peel the expression to get the 
> > > DeclRefExpr.
> > What's the base declaration in `*(a+b)`?
> I understand your point, I'm just not sure how to handle (do not analyze) 
> this given that we need to fill VarDecl for OMPToClause/OMPFromClause.
But is *(a+b) even valid? Clang and GCC both emit error message: 
https://godbolt.org/z/jqDBx_


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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

[PATCH] D72552: [Concepts] Constraint Satisfaction Caching

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

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

Mechanically, this looks fine.

There's an ongoing discussion in the committee as to whether this kind of 
caching is permissible. But if this is necessary for acceptable performance, 
let's take this for now and figure out how to invalidate the cache as necessary 
later. Perhaps a `-f` flag to turn this off would be useful, so we can 
demonstrate and measure the performance delta.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72552



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

[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

[Chi Chun Chen via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

ABataev wrote:
> cchen wrote:
> > ABataev wrote:
> > > cchen wrote:
> > > > cchen wrote:
> > > > > ABataev wrote:
> > > > > > Why just the LHS is analyzed? Also, what about support for other 
> > > > > > expressions, like casting, call, choose etc., which may result in 
> > > > > > lvalue?
> > > > > 1. LHS: I'll fix that
> > > > > 2. I'll add support for casting, call, etc
> > > > > 3. For "choose" are you referring to something like (a < b ? b : a)?
> > > > For the handling of BinaryOperator, I'm not sure why should we handle 
> > > > RHS since the possible source code I can imagine is `*(ptr+l)` or 
> > > > something like `(ptr+l)[3]`.
> > > `*(2+ptr)` is correct too. And, btw, `3[ptr+1]` too, especially in C. 
> > > Moreover, something like `*(b+c)` is also allowed. That's why I said that 
> > > better to avoid deep analysis of lvalues, there are too many combinations 
> > > and better to switch to something basic.
> > But at least we need the base declaration for motion/map clause, right? And 
> > to achieve this, we need to peel the expression to get the DeclRefExpr.
> What's the base declaration in `*(a+b)`?
I understand your point, I'm just not sure how to handle (do not analyze) this 
given that we need to fill VarDecl for OMPToClause/OMPFromClause.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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

[clang] 89e43f0 - Revert "List implicit operator== after implicit destructors in a vtable."

[Vladimir Vereschaka via cfe-commits]

Author: Vladimir Vereschaka
Date: 2020-01-21T13:07:56-08:00
New Revision: 89e43f04ba87a0da6e94863db149669c7536486b

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

LOG: Revert "List implicit operator== after implicit destructors in a vtable."

This reverts commit add2b7e44ada46f30715b5c48823a9e9e317e0c3.

Failed "Clang::virtual-compare.cpp" test on the arm builders.
See
http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/3169
for details.

Added: 


Modified: 
clang/lib/AST/VTableBuilder.cpp

Removed: 
clang/test/CodeGenCXX/virtual-compare.cpp



diff  --git a/clang/lib/AST/VTableBuilder.cpp b/clang/lib/AST/VTableBuilder.cpp
index 0bff976905fc..2b5b74be5961 100644
--- a/clang/lib/AST/VTableBuilder.cpp
+++ b/clang/lib/AST/VTableBuilder.cpp
@@ -1474,11 +1474,11 @@ void ItaniumVTableBuilder::AddMethods(
   llvm_unreachable("Found a duplicate primary base!");
   }
 
+  const CXXDestructorDecl *ImplicitVirtualDtor = nullptr;
+
   typedef llvm::SmallVector NewVirtualFunctionsTy;
   NewVirtualFunctionsTy NewVirtualFunctions;
 
-  llvm::SmallVector NewImplicitVirtualFunctions;
-
   // Now go through all virtual member functions and add them.
   for (const auto *MD : RD->methods()) {
 if (!MD->isVirtual())
@@ -1542,30 +1542,24 @@ void ItaniumVTableBuilder::AddMethods(
   }
 }
 
-if (MD->isImplicit())
-  NewImplicitVirtualFunctions.push_back(MD);
-else
-  NewVirtualFunctions.push_back(MD);
-  }
-
-  std::stable_sort(
-  NewImplicitVirtualFunctions.begin(), NewImplicitVirtualFunctions.end(),
-  [](const CXXMethodDecl *A, const CXXMethodDecl *B) {
-if (A->isCopyAssignmentOperator() != B->isCopyAssignmentOperator())
-  return A->isCopyAssignmentOperator();
-if (A->isMoveAssignmentOperator() != B->isMoveAssignmentOperator())
-  return A->isMoveAssignmentOperator();
-if (isa(A) != isa(B))
-  return isa(A);
-assert(A->getOverloadedOperator() == OO_EqualEqual &&
-   B->getOverloadedOperator() == OO_EqualEqual &&
-   "unexpected or duplicate implicit virtual function");
-// We rely on Sema to have declared the operator== members in the
-// same order as the corresponding operator<=> members.
-return false;
-  });
-  NewVirtualFunctions.append(NewImplicitVirtualFunctions.begin(),
- NewImplicitVirtualFunctions.end());
+if (const CXXDestructorDecl *DD = dyn_cast(MD)) {
+  if (MD->isImplicit()) {
+// Itanium C++ ABI 2.5.2:
+//   If a class has an implicitly-defined virtual destructor,
+//   its entries come after the declared virtual function pointers.
+
+assert(!ImplicitVirtualDtor &&
+   "Did already see an implicit virtual dtor!");
+ImplicitVirtualDtor = DD;
+continue;
+  }
+}
+
+NewVirtualFunctions.push_back(MD);
+  }
+
+  if (ImplicitVirtualDtor)
+NewVirtualFunctions.push_back(ImplicitVirtualDtor);
 
   for (const CXXMethodDecl *MD : NewVirtualFunctions) {
 // Get the final overrider.

diff  --git a/clang/test/CodeGenCXX/virtual-compare.cpp 
b/clang/test/CodeGenCXX/virtual-compare.cpp
deleted file mode 100644
index 6ffbe8eb86ae..
--- a/clang/test/CodeGenCXX/virtual-compare.cpp
+++ /dev/null
@@ -1,53 +0,0 @@
-// RUN: %clang_cc1 -std=c++2a -triple %itanium_abi_triple -emit-llvm %s -o - | 
FileCheck %s
-
-#include "Inputs/std-compare.h"
-
-// CHECK: @_ZTV1A =
-struct A;
-struct X {
-  // CHECK-SAME: @_ZN1X1xEv
-  virtual void x();
-  friend auto operator<=>(X, X) = default;
-};
-struct Y {
-  virtual ~Y();
-  virtual A =(const A &);
-  friend auto operator<=>(Y, Y) = default;
-};
-struct A : X, Y {
-  // CHECK-SAME: @_ZN1A1fEv
-  virtual void f();
-  // CHECK-SAME: @_ZNKR1AssERKS_
-  virtual std::strong_ordering operator<=>(const A &) const & = default;
-  // CHECK-SAME: @_ZN1A1gEv
-  virtual void g();
-  // CHECK-SAME: @_ZNKO1AssERKS_
-  virtual std::strong_ordering operator<=>(const A &) const && = default;
-  // CHECK-SAME: @_ZN1A1hEv
-  virtual void h();
-
-  // CHECK-SAME: @_ZN1AaSERKS_
-  // implicit virtual A =(const A&) = default;
-
-  // CHECK-SAME: @_ZN1AD1Ev
-  // CHECK-SAME: @_ZN1AD0Ev
-  // implicit virtual ~A();
-
-  // CHECK-SAME: @_ZNKR1AeqERKS_
-  // implicit virtual A ==(const A&) const & = default;
-
-  // CHECK-SAME: @_ZNKO1AeqERKS_
-  // implicit virtual A ==(const A&) const && = default;
-};
-
-// For Y:
-// CHECK-SAME: @_ZTI1A
-
-// CHECK-SAME: @_ZThn8_N1AD1Ev
-// CHECK-SAME: @_ZThn8_N1AD0Ev
-// virtual ~Y();
-
-// CHECK-SAME: @_ZThn8_N1AaSERKS_
-// virtual A =(const A &);
-
-void A::f() {}



___
cfe-commits mailing list

[clang] b0b2b7e - Revert "[Clang] Un-break scan-build after integrated-cc1 change"

[Alexandre Ganea via cfe-commits]

Author: Alexandre Ganea
Date: 2020-01-21T16:06:36-05:00
New Revision: b0b2b7e09926cdde4d82978a7c14b5e2d38db35c

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

LOG: Revert "[Clang] Un-break scan-build after integrated-cc1 change"

This reverts commit a6883017ea9af529e89d7f89af2477378b6eafca.

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/Job.cpp b/clang/lib/Driver/Job.cpp
index 7dab2a022d92..d57c3a1cdbb8 100644
--- a/clang/lib/Driver/Job.cpp
+++ b/clang/lib/Driver/Job.cpp
@@ -373,7 +373,7 @@ int Command::Execute(ArrayRef> 
Redirects,
 
 void CC1Command::Print(raw_ostream , const char *Terminator, bool Quote,
CrashReportInfo *CrashInfo) const {
-  OS << " (in-process)\n";
+  OS << " (in-process)";
   Command::Print(OS, Terminator, Quote, CrashInfo);
 }
 

diff  --git a/clang/test/Driver/cuda-simple.cu 
b/clang/test/Driver/cuda-simple.cu
index 54e18403108b..b6840be4e2e5 100644
--- a/clang/test/Driver/cuda-simple.cu
+++ b/clang/test/Driver/cuda-simple.cu
@@ -5,10 +5,10 @@
 // Verify that we pass -x cuda-cpp-output to compiler after
 // preprocessing a CUDA file
 // RUN: %clang  -Werror -### -save-temps -c %s 2>&1 | FileCheck %s
-// CHECK-LABEL: "-cc1"
+// CHECK: "-cc1"
 // CHECK: "-E"
 // CHECK: "-x" "cuda"
-// CHECK-LABEL: "-cc1"
+// CHECK-NEXT: "-cc1"
 // CHECK: "-x" "cuda-cpp-output"
 //
 // Verify that compiler accepts CUDA syntax with "-x cuda-cpp-output".

diff  --git a/clang/test/Driver/offloading-interoperability.c 
b/clang/test/Driver/offloading-interoperability.c
index c3a72f0dfe2a..9c80d91d1d78 100644
--- a/clang/test/Driver/offloading-interoperability.c
+++ b/clang/test/Driver/offloading-interoperability.c
@@ -8,10 +8,10 @@
 // RUN: %clang -no-canonical-prefixes -### -x cuda -target 
powerpc64le-linux-gnu -std=c++11 --cuda-gpu-arch=sm_35 -fopenmp=libomp %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix NO-OPENMP-FLAGS-FOR-CUDA-DEVICE
 //
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  clang{{.*}}" "-cc1" "-triple" 
"nvptx64-nvidia-cuda"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NOT:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: ptxas" "-m64"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: fatbinary"{{( "--cuda")?}} "-64"
-// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-LABEL:clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
+// NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: clang{{.*}}" "-cc1" "-triple" 
"powerpc64le-unknown-linux-gnu"
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE:  -fopenmp
 // NO-OPENMP-FLAGS-FOR-CUDA-DEVICE-NEXT: {{ld(.exe)?"}} {{.*}}"-m" "elf64lppc"

diff  --git a/clang/test/Driver/option-aliases.c 
b/clang/test/Driver/option-aliases.c
index e50289cc3bdf..9cd9252a4832 100644
--- a/clang/test/Driver/option-aliases.c
+++ b/clang/test/Driver/option-aliases.c
@@ -3,12 +3,12 @@
 // RUN: --param=FOO --output=FOO %s 2>&1 | \
 // RUN: FileCheck %s
 
-// CHECK-LABEL: "-cc1"
+// CHECK: "-cc1"
 // CHECK: "-E"
 // CHECK: "-U" "FOO"
 // CHECK: "-U" "BAR"
 // CHECK: "-o" "option-aliases.i"
 
-// CHECK-LABEL: "-cc1"
+// CHECK-NEXT: "-cc1"
 // CHECK: "-S"
 // CHECK: "-o" "FOO"



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

[clang] a8c2f76 - Removing an accidentally duplicated line of test code to fix bots.

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2020-01-21T16:03:22-05:00
New Revision: a8c2f76cd258ea03f82a1fc12953ca8af6b7832b

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

LOG: Removing an accidentally duplicated line of test code to fix bots.

Added: 


Modified: 
clang/test/Sema/attr-capabilities.c

Removed: 




diff  --git a/clang/test/Sema/attr-capabilities.c 
b/clang/test/Sema/attr-capabilities.c
index 03cebe2f6596..b28c437935a1 100644
--- a/clang/test/Sema/attr-capabilities.c
+++ b/clang/test/Sema/attr-capabilities.c
@@ -1,6 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -Wthread-safety -verify %s
 
-typedef int __attribute__((capability("role"))) ThreadRole;
 typedef int __attribute__((capability("role"))) ThreadRole;
 struct __attribute__((shared_capability("mutex"))) Mutex {};
 struct NotACapability {};



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

[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

cchen wrote:
> ABataev wrote:
> > cchen wrote:
> > > cchen wrote:
> > > > ABataev wrote:
> > > > > Why just the LHS is analyzed? Also, what about support for other 
> > > > > expressions, like casting, call, choose etc., which may result in 
> > > > > lvalue?
> > > > 1. LHS: I'll fix that
> > > > 2. I'll add support for casting, call, etc
> > > > 3. For "choose" are you referring to something like (a < b ? b : a)?
> > > For the handling of BinaryOperator, I'm not sure why should we handle RHS 
> > > since the possible source code I can imagine is `*(ptr+l)` or something 
> > > like `(ptr+l)[3]`.
> > `*(2+ptr)` is correct too. And, btw, `3[ptr+1]` too, especially in C. 
> > Moreover, something like `*(b+c)` is also allowed. That's why I said that 
> > better to avoid deep analysis of lvalues, there are too many combinations 
> > and better to switch to something basic.
> But at least we need the base declaration for motion/map clause, right? And 
> to achieve this, we need to peel the expression to get the DeclRefExpr.
What's the base declaration in `*(a+b)`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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

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

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a comment.

In D72982#1832209 , @phosek wrote:

> We're seeing `Driver/cc-print-options.c` test failures after this change:


Yes, seeing it too, I will commit a fix in a minute!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72982



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

[PATCH] D72897: List implicit operator== after implicit destructors in a vtable.

[Vlad Vereschaka via Phabricator via cfe-commits]

vvereschaka added a comment.

Hi Richard,

http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l builder has been 
broken by this patch during few days (failed "Clang::virtual-compare.cpp" test).
Sorry, but I'm going to revert these changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72897



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

[PATCH] D71911: [ThinLTO] Summarize vcall_visibility metadata

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson updated this revision to Diff 239412.
tejohnson added a comment.

Address comment and rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71911

Files:
  clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/test/Assembler/thinlto-vtable-summary.ll

Index: llvm/test/Assembler/thinlto-vtable-summary.ll
===
--- llvm/test/Assembler/thinlto-vtable-summary.ll
+++ llvm/test/Assembler/thinlto-vtable-summary.ll
@@ -29,9 +29,9 @@
 
 ^0 = module: (path: "", hash: (0, 0, 0, 0, 0))
 ^1 = gv: (name: "_ZN1A1nEi") ; guid = 1621563287929432257
-^2 = gv: (name: "_ZTV1B", summaries: (variable: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), varFlags: (readonly: 0, writeonly: 0, constant: 0), vTableFuncs: ((virtFunc: ^3, offset: 16), (virtFunc: ^1, offset: 24)), refs: (^3, ^1 ; guid = 5283576821522790367
+^2 = gv: (name: "_ZTV1B", summaries: (variable: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), varFlags: (readonly: 0, writeonly: 0, constant: 0, vcall_visibility: 0), vTableFuncs: ((virtFunc: ^3, offset: 16), (virtFunc: ^1, offset: 24)), refs: (^3, ^1 ; guid = 5283576821522790367
 ^3 = gv: (name: "_ZN1B1fEi") ; guid = 7162046368816414394
-^4 = gv: (name: "_ZTV1C", summaries: (variable: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), varFlags: (readonly: 0, writeonly: 0, constant: 0), vTableFuncs: ((virtFunc: ^5, offset: 16), (virtFunc: ^1, offset: 24)), refs: (^1, ^5 ; guid = 1362402378846296
+^4 = gv: (name: "_ZTV1C", summaries: (variable: (module: ^0, flags: (linkage: external, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), varFlags: (readonly: 0, writeonly: 0, constant: 0, vcall_visibility: 0), vTableFuncs: ((virtFunc: ^5, offset: 16), (virtFunc: ^1, offset: 24)), refs: (^1, ^5 ; guid = 1362402378846296
 ^5 = gv: (name: "_ZN1C1fEi") ; guid = 14876272565662207556
 ^6 = typeidCompatibleVTable: (name: "_ZTS1A", summary: ((offset: 16, ^2), (offset: 16, ^4))) ; guid = 7004155349499253778
 ^7 = typeidCompatibleVTable: (name: "_ZTS1B", summary: ((offset: 16, ^2))) ; guid = 6203814149063363976
Index: llvm/lib/IR/AsmWriter.cpp
===
--- llvm/lib/IR/AsmWriter.cpp
+++ llvm/lib/IR/AsmWriter.cpp
@@ -2900,11 +2900,15 @@
 }
 
 void AssemblyWriter::printGlobalVarSummary(const GlobalVarSummary *GS) {
+  auto VTableFuncs = GS->vTableFuncs();
   Out << ", varFlags: (readonly: " << GS->VarFlags.MaybeReadOnly << ", "
   << "writeonly: " << GS->VarFlags.MaybeWriteOnly << ", "
-  << "constant: " << GS->VarFlags.Constant << ")";
+  << "constant: " << GS->VarFlags.Constant;
+  if (!VTableFuncs.empty())
+Out << ", "
+<< "vcall_visibility: " << GS->VarFlags.VCallVisibility;
+  Out << ")";
 
-  auto VTableFuncs = GS->vTableFuncs();
   if (!VTableFuncs.empty()) {
 Out << ", vTableFuncs: (";
 FieldSeparator FS;
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -1028,8 +1028,8 @@
 }
 
 static uint64_t getEncodedGVarFlags(GlobalVarSummary::GVarFlags Flags) {
-  uint64_t RawFlags =
-  Flags.MaybeReadOnly | (Flags.MaybeWriteOnly << 1) | (Flags.Constant << 2);
+  uint64_t RawFlags = Flags.MaybeReadOnly | (Flags.MaybeWriteOnly << 1) |
+  (Flags.Constant << 2) | Flags.VCallVisibility << 3;
   return RawFlags;
 }
 
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -985,9 +985,10 @@
 
 // Decode the flags for GlobalVariable in the summary
 static GlobalVarSummary::GVarFlags getDecodedGVarFlags(uint64_t RawFlags) {
-  return GlobalVarSummary::GVarFlags((RawFlags & 0x1) ? true : false,
- (RawFlags & 0x2) ? true : false,
- (RawFlags & 0x4) ? true : false);
+  return GlobalVarSummary::GVarFlags(
+  (RawFlags & 0x1) ? true : false, (RawFlags & 0x2) ? true : false,
+  (RawFlags & 0x4) ? true : false,
+  (GlobalObject::VCallVisibility)(RawFlags >> 3));
 }
 
 static GlobalValue::VisibilityTypes getDecodedVisibility(unsigned Val) {
@@ -5967,7 +5968,8 @@
   unsigned RefArrayStart = 

[PATCH] D72841: [RFC] Add support for pragma float_control, to control precision and exception behavior at the source level

[Melanie Blower via Phabricator via cfe-commits]

mibintc marked 5 inline comments as done.
mibintc added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:13129
 if (FunctionDecl *F = dyn_cast(CurContext)) {
+  // If the expression occurs inside an internal global_var_init_function
+  // then the FunctionDecl is not availble

sepavloff wrote:
> mibintc wrote:
> > sepavloff wrote:
> > > The standard says that static initializers execute in default FP mode.
> > > The standard says ...
> > Are you sure about this one?  Can you please provide the standards 
> > reference so I can study it?
> >> The standard says ...
> > Are you sure about this one? Can you please provide the standards reference 
> > so I can study it?
> 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf, F.8.5:
> ```
> ... All computation for initialization of objects that have static or thread 
> storage duration is done (as if) at translation time.
> ```
> F.8.2:
> ```
> During translation the IEC 60559 default modes are in effect:
> — The rounding direction mode is rounding to nearest.
> — The rounding precision mode (if supported) is set so that results are not 
> shortened.
> — Trapping or stopping (if supported) is disabled on all floating-point 
> exceptions.
> ```
Thanks for the pointer to the reference. The desired semantics of the pragma 
may differ from the standard. For example I tried this test case with the 
fp_contract pragma, and the pragma does modify the semantics of the floating 
point expressions in the initializer.  So this issue is still a problem in this 
patch. 

// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s

#pragma STDC FP_CONTRACT ON
float y();
float d();
class ON {
float z = y() * 1 + d();
// CHECK-LABEL: define {{.*}} void @_ZN2ONC2Ev{{.*}}
//CHECK: llvm.fmuladd.f32{{.*}}
};
ON on;

#pragma STDC FP_CONTRACT OFF
class OFF {
float w = y() * 1 + d();
// CHECK-LABEL: define {{.*}} void @_ZN3OFFC2Ev{{.*}}
//CHECK: fmul float
};
OFF off;



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

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

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

We're seeing `Driver/cc-print-options.c` test failures after this change:

   TEST 'Clang :: Driver/cc-print-options.c' FAILED 

  Script:
  --
  : 'RUN: at line 1';   env CC_PRINT_OPTIONS=1  
CC_PRINT_OPTIONS_FILE=/b/s/w/ir/k/recipe_cleanup/clangpfY9av/llvm_build_dir/tools/clang/test/Driver/Output/cc-print-options.c.tmp.log
  /b/s/w/ir/k/recipe_cleanup/clangpfY9av/llvm_build_dir/bin/clang 
-no-canonical-prefixes -S -o 
/b/s/w/ir/k/recipe_cleanup/clangpfY9av/llvm_build_dir/tools/clang/test/Driver/Output/cc-print-options.c.tmp.s
 /b/s/w/ir/k/llvm-project/clang/test/Driver/cc-print-options.c
  : 'RUN: at line 4';   
/b/s/w/ir/k/recipe_cleanup/clangpfY9av/llvm_build_dir/bin/FileCheck 
/b/s/w/ir/k/llvm-project/clang/test/Driver/cc-print-options.c < 
/b/s/w/ir/k/recipe_cleanup/clangpfY9av/llvm_build_dir/tools/clang/test/Driver/Output/cc-print-options.c.tmp.log
  --
  Exit Code: 1
  
  Command Output (stderr):
  --
  /b/s/w/ir/k/llvm-project/clang/test/Driver/cc-print-options.c:6:11: error: 
CHECK: expected string not found in input
  // CHECK: [Logging clang options]{{.*}}clang{{.*}}"-S"
^
  :1:1: note: scanning from here
  [Logging clang options] (in-process)
  ^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72982



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

[PATCH] D72811: [WIP][OPENMP5.0] allow lvalue for motion clause

[Chi Chun Chen via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaOpenMP.cpp:15442-15443
+  CurComponents.emplace_back(CurE, nullptr);
+} else if (auto *CurE = dyn_cast(E)) {
+  E = CurE->getLHS()->IgnoreParenImpCasts();
 } else {

ABataev wrote:
> cchen wrote:
> > cchen wrote:
> > > ABataev wrote:
> > > > Why just the LHS is analyzed? Also, what about support for other 
> > > > expressions, like casting, call, choose etc., which may result in 
> > > > lvalue?
> > > 1. LHS: I'll fix that
> > > 2. I'll add support for casting, call, etc
> > > 3. For "choose" are you referring to something like (a < b ? b : a)?
> > For the handling of BinaryOperator, I'm not sure why should we handle RHS 
> > since the possible source code I can imagine is `*(ptr+l)` or something 
> > like `(ptr+l)[3]`.
> `*(2+ptr)` is correct too. And, btw, `3[ptr+1]` too, especially in C. 
> Moreover, something like `*(b+c)` is also allowed. That's why I said that 
> better to avoid deep analysis of lvalues, there are too many combinations and 
> better to switch to something basic.
But at least we need the base declaration for motion/map clause, right? And to 
achieve this, we need to peel the expression to get the DeclRefExpr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72811



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

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

In D72635#1831782 , @eti-p-doray wrote:

> Thanks!
>  I don't I have commit access. Can you commit on my behalf?


Happy to do so! I've commit on your behalf in 
5260bc2497bb593ed4a01de5cfe84ed6f7b529b1 
, thank 
you for the patch!


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

https://reviews.llvm.org/D72635



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

[clang] 5260bc2 - Allow arbitrary capability name in Thread Safety Analysis

[Aaron Ballman via cfe-commits]

Author: Etienne Pierre-Doray
Date: 2020-01-21T15:43:17-05:00
New Revision: 5260bc2497bb593ed4a01de5cfe84ed6f7b529b1

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

LOG: Allow arbitrary capability name in Thread Safety Analysis

Restricting the names of capabilities to only "role" or "mutex" makes
for awkward diagnostic text, such as with:
https://chromium-review.googlesource.com/c/chromium/src/+/1948098/19/base/sequence_checker_unittest.nc#33

Added: 


Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Sema/attr-capabilities.c

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 10db2a868dce..7d01181e7c01 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -2567,10 +2567,6 @@ def Capability : InheritableAttr {
   let Accessors = [Accessor<"isShared",
 [Clang<"shared_capability", 0>]>];
   let Documentation = [Undocumented];
-  let AdditionalMembers = [{
-bool isMutex() const { return getName().equals_lower("mutex"); }
-bool isRole() const { return getName().equals_lower("role"); }
-  }];
 }
 
 def AssertCapability : InheritableAttr {

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index a4d042710858..b87419d393e2 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3252,9 +3252,6 @@ def warn_at_available_unchecked_use : Warning<
   InGroup>;
 
 // Thread Safety Attributes
-def warn_invalid_capability_name : Warning<
-  "invalid capability name '%0'; capability name must be 'mutex' or 'role'">,
-  InGroup, DefaultIgnore;
 def warn_thread_attribute_ignored : Warning<
   "ignoring %0 attribute because its argument is invalid">,
   InGroup, DefaultIgnore;

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 77194de87ba4..040a26956433 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -6195,11 +6195,6 @@ static void handleCapabilityAttr(Sema , Decl *D, const 
ParsedAttr ) {
   !S.checkStringLiteralArgumentAttr(AL, 0, N, ))
 return;
 
-  // Currently, there are only two names allowed for a capability: role and
-  // mutex (case insensitive). Diagnose other capability names.
-  if (!N.equals_lower("mutex") && !N.equals_lower("role"))
-S.Diag(LiteralLoc, diag::warn_invalid_capability_name) << N;
-
   D->addAttr(::new (S.Context) CapabilityAttr(S.Context, AL, N));
 }
 

diff  --git a/clang/test/Sema/attr-capabilities.c 
b/clang/test/Sema/attr-capabilities.c
index 8bfc4a506543..03cebe2f6596 100644
--- a/clang/test/Sema/attr-capabilities.c
+++ b/clang/test/Sema/attr-capabilities.c
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -fsyntax-only -Wthread-safety -verify %s
 
+typedef int __attribute__((capability("role"))) ThreadRole;
 typedef int __attribute__((capability("role"))) ThreadRole;
 struct __attribute__((shared_capability("mutex"))) Mutex {};
 struct NotACapability {};
@@ -8,8 +9,8 @@ struct NotACapability {};
 union __attribute__((capability("mutex"))) MutexUnion { int a; char* b; };
 typedef union { int a; char* b; } __attribute__((capability("mutex"))) 
MutexUnion2;
 
-// Test an invalid capability name
-struct __attribute__((capability("wrong"))) IncorrectName {}; // 
expected-warning {{invalid capability name 'wrong'; capability name must be 
'mutex' or 'role'}}
+// Test a 
diff erent capability name
+struct __attribute__((capability("custom"))) CustomName {};
 
 int Test1 __attribute__((capability("test1")));  // expected-error 
{{'capability' attribute only applies to structs, unions, classes, and 
typedefs}}
 int Test2 __attribute__((shared_capability("test2"))); // expected-error 
{{'shared_capability' attribute only applies to structs, unions, classes, and 
typedefs}}



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

[PATCH] D72841: [RFC] Add support for pragma float_control, to control precision and exception behavior at the source level

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 239409.
mibintc added a comment.

Respond to review from @sepavloff


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/PragmaKinds.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/fp-floatcontrol-class.cpp
  clang/test/CodeGen/fp-floatcontrol-pragma.cpp
  llvm/include/llvm/IR/IRBuilder.h

Index: llvm/include/llvm/IR/IRBuilder.h
===
--- llvm/include/llvm/IR/IRBuilder.h
+++ llvm/include/llvm/IR/IRBuilder.h
@@ -299,10 +299,16 @@
 IRBuilderBase 
 FastMathFlags FMF;
 MDNode *FPMathTag;
+bool IsFPConstrained;
+fp::ExceptionBehavior DefaultConstrainedExcept;
+fp::RoundingMode DefaultConstrainedRounding;
 
   public:
 FastMathFlagGuard(IRBuilderBase )
-: Builder(B), FMF(B.FMF), FPMathTag(B.DefaultFPMathTag) {}
+: Builder(B), FMF(B.FMF), FPMathTag(B.DefaultFPMathTag),
+  IsFPConstrained(B.IsFPConstrained),
+  DefaultConstrainedExcept(B.DefaultConstrainedExcept),
+  DefaultConstrainedRounding(B.DefaultConstrainedRounding) {}
 
 FastMathFlagGuard(const FastMathFlagGuard &) = delete;
 FastMathFlagGuard =(const FastMathFlagGuard &) = delete;
@@ -310,6 +316,9 @@
 ~FastMathFlagGuard() {
   Builder.FMF = FMF;
   Builder.DefaultFPMathTag = FPMathTag;
+  Builder.IsFPConstrained = IsFPConstrained;
+  Builder.DefaultConstrainedExcept = DefaultConstrainedExcept;
+  Builder.DefaultConstrainedRounding = DefaultConstrainedRounding;
 }
   };
 
Index: clang/test/CodeGen/fp-floatcontrol-pragma.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-floatcontrol-pragma.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -fsyntax-only -verify -DCHECK_ERROR %s
+
+float fff(float x, float y) {
+// CHECK-LABEL: define float @_Z3f{{.*}}
+// CHECK: entry
+#pragma float_control(except, on)
+  float z;
+  z = z*z;
+//CHECK: llvm.experimental.constrained.fmul{{.*}}
+  {
+z = x*y;
+//CHECK: llvm.experimental.constrained.fmul{{.*}}
+  }
+  {
+// This pragma has no effect since if there are any fp intrin in the
+// function then all the operations need to be fp intrin
+#pragma float_control(except, off)
+ z = z + x*y;
+//CHECK: llvm.experimental.constrained.fmul{{.*}}
+  }
+  z = z*z;
+//CHECK: llvm.experimental.constrained.fmul{{.*}}
+  return z;
+}
+float check_precise(float x, float y) {
+// CHECK-LABEL: define float @_Z13check_preciseff{{.*}}
+  float z;
+  {
+#pragma float_control(precise, on)
+z = x*y + z;
+//CHECK: llvm.fmuladd{{.*}}
+  }
+  {
+#pragma float_control(precise, off)
+z = x*y + z;
+//CHECK: fmul float
+//CHECK: fadd float
+  }
+  return z;
+}
+float fma_test1(float a, float b, float c) {
+// CHECK-LABEL define float @_Z9fma_test1fff{{.*}}
+#pragma float_control(precise, on)
+  float x = a * b + c;
+//CHECK: fmuladd
+  return x;
+}
+
+// There seems to be a bug in Actions.CurContext->isTranslationUnit()
+// unless this dummy class is used. FIXME Fix the issue then remove this
+// workaround.
+#define TU_WORKAROUND
+#ifdef TU_WORKAROUND
+class ResetTUScope;
+#endif
+#ifdef CHECK_ERROR
+#  pragma float_control(push)
+#  pragma float_control(pop)
+#  pragma float_control(precise,on,push)
+void check_stack() {
+#pragma float_control(push) // expected-error {{can only appear at file scope}}
+#pragma float_control(pop) // expected-error {{can only appear at file scope}}
+#pragma float_control(precise,on,push) // expected-error {{can only appear at file scope}}
+  return;
+}
+#endif
Index: clang/test/CodeGen/fp-floatcontrol-class.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-floatcontrol-class.cpp
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+// XFAIL: *
+
+// This get an assertion failure in Debug mode because the expression
+// occurs within a global_var_init_function. Those expressions are Sema'd
+// before the global_var_init_function is created, and therefore we don't
+// mark those function nodes as "usesPFIntrin". The assertion occurs in
+// ScalarExprEmitter: either Constrained mode is on, or the
+// expression requests non-constrained Rounding and 

[PATCH] D73072: [Driver][CodeGen] Support -fpatchable-function-entry=N,M where M>0

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

merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 62081 tests passed, 2 failed 
and 784 were skipped.

  failed: Clang.Driver/cc-print-options.c
  failed: Clang.Driver/fpatchable-function-entry.c

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

{icon times-circle color=red} clang-format: fail. Please format your changes 
with clang-format by running `git-clang-format HEAD^` or applying this patch 
.

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



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73072



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

[PATCH] D72874: [clangd] Add a textual fallback for go-to-definition

[Nathan Ridge via Phabricator via cfe-commits]

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

Thanks for taking a look!

In D72874#1831977 , @sammccall wrote:

> - it triggers on almost every word, even words that plainly don't refer to 
> any decl like `format [[lazily]], in case vlog is off`. This means that e.g. 
> (in VSCode) the underline on ctrl-hover gives no/misleading signal. It also 
> means that missing your target now jumps you somewhere random instead of 
> doing nothing.


Heh, I didn't realize VSCode had this feature. I do agree that it changes the 
tradeoffs a bit, as it means go-to-definition can be invoked in a context where 
there isn't an explicit signal from the user that they think there's a 
declaration there.

The other points you make are completely fair too. I will revise and take your 
suggestions into account.

I'll aim to start by factoring in enough of your suggestions to reduce the 
noise to an acceptable level for an initial landing, and leave some of the 
others for follow-up enhancements.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72874



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

[PATCH] D71907: [WPD/VFE] Always emit vcall_visibility metadata for -fwhole-program-vtables

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson updated this revision to Diff 239406.
tejohnson added a comment.

Remove stale change that didn't belong here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71907

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGenCXX/vcall-visibility-metadata.cpp
  llvm/include/llvm/IR/GlobalObject.h
  llvm/lib/IR/Metadata.cpp
  llvm/lib/Transforms/IPO/GlobalDCE.cpp
  llvm/lib/Transforms/IPO/GlobalSplit.cpp
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-base-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-derived-pointer-call.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-novfe.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-post-lto.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-pre-lto.ll
  llvm/test/Transforms/GlobalDCE/virtual-functions.ll
  llvm/test/Transforms/GlobalDCE/vtable-rtti.ll

Index: llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
===
--- llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
+++ llvm/test/Transforms/GlobalDCE/vtable-rtti.ll
@@ -39,9 +39,10 @@
 declare dso_local noalias nonnull i8* @_Znwm(i64)
 @_ZTVN10__cxxabiv117__class_type_infoE = external dso_local global i8*
 
-!llvm.module.flags = !{!3}
+!llvm.module.flags = !{!3, !4}
 
 !0 = !{i64 16, !"_ZTS1A"}
 !1 = !{i64 16, !"_ZTSM1AFvvE.virtual"}
 !2 = !{i64 2} ; translation-unit vcall visibility
 !3 = !{i32 1, !"LTOPostLink", i32 1}
+!4 = !{i32 1, !"Virtual Function Elim", i32 1}
Index: llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-pre-lto.ll
===
--- llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-pre-lto.ll
+++ llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-pre-lto.ll
@@ -85,10 +85,11 @@
 
 declare dso_local noalias nonnull i8* @_Znwm(i64)
 
-!llvm.module.flags = !{}
+!llvm.module.flags = !{!5}
 
 !0 = !{i64 16, !"_ZTS1A"}
 !1 = !{i64 16, !"_ZTSM1AFvvE.virtual"}
 !2 = !{i64 0} ; public vcall visibility
 !3 = !{i64 1} ; linkage-unit vcall visibility
 !4 = !{i64 2} ; translation-unit vcall visibility
+!5 = !{i32 1, !"Virtual Function Elim", i32 1}
Index: llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-post-lto.ll
===
--- llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-post-lto.ll
+++ llvm/test/Transforms/GlobalDCE/virtual-functions-visibility-post-lto.ll
@@ -85,7 +85,7 @@
 
 declare dso_local noalias nonnull i8* @_Znwm(i64)
 
-!llvm.module.flags = !{!5}
+!llvm.module.flags = !{!5, !6}
 
 !0 = !{i64 16, !"_ZTS1A"}
 !1 = !{i64 16, !"_ZTSM1AFvvE.virtual"}
@@ -93,3 +93,4 @@
 !3 = !{i64 1} ; linkage-unit vcall visibility
 !4 = !{i64 2} ; translation-unit vcall visibility
 !5 = !{i32 1, !"LTOPostLink", i32 1}
+!6 = !{i32 1, !"Virtual Function Elim", i32 1}
Index: llvm/test/Transforms/GlobalDCE/virtual-functions.ll
===
--- llvm/test/Transforms/GlobalDCE/virtual-functions.ll
+++ llvm/test/Transforms/GlobalDCE/virtual-functions.ll
@@ -48,8 +48,11 @@
   ret i32 %call1
 }
 
+!llvm.module.flags = !{!4}
+
 !0 = !{i64 16, !"_ZTS1A"}
 !1 = !{i64 16, !"_ZTSM1AFivE.virtual"}
 !2 = !{i64 24, !"_ZTSM1AFivE.virtual"}
 !3 = !{i64 2}
+!4 = !{i32 1, !"Virtual Function Elim", i32 1}
 !9 = !{}
Index: llvm/test/Transforms/GlobalDCE/virtual-functions-novfe.ll
===
--- llvm/test/Transforms/GlobalDCE/virtual-functions-novfe.ll
+++ llvm/test/Transforms/GlobalDCE/virtual-functions-novfe.ll
@@ -1,3 +1,5 @@
+; Tests that VFE is not performed when the Virtual Function Elim metadata set
+; to 0. This is the same as virtual-functions.ll otherwise.
 ; RUN: opt < %s -globaldce -S | FileCheck %s
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
@@ -11,14 +13,12 @@
 ; intrinsic. Function test_A makes a call to A::foo, but there is no call to
 ; A::bar anywhere, so A::bar can be deleted, and its vtable slot replaced with
 ; null.
+; However, with the metadata set to 0 we should not perform this VFE.
 
 %struct.A = type { i32 (...)** }
 
-; The pointer to A::bar in the vtable can be removed, because it will never be
-; loaded. We replace it with null to keep the layout the same. Because it is at
-; the end of the vtable we could potentially shrink the vtable, but don't
-; currently do that.
-; CHECK: @_ZTV1A = internal unnamed_addr constant { [4 x i8*] } { [4 x i8*] [i8* null, i8* null, i8* bitcast (i32 (%struct.A*)* @_ZN1A3fooEv to i8*), i8* null] }
+; We should retain @_ZN1A3barEv in the vtable.
+; CHECK: @_ZTV1A = internal unnamed_addr constant { [4 x i8*] } { [4 x i8*] 

[PATCH] D71907: [WPD/VFE] Always emit vcall_visibility metadata for -fwhole-program-vtables

[Teresa Johnson via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:676
+  bool ShouldEmitWPDInfo = CGM.getCodeGenOpts().WholeProgramVTables &&
+   CGM.HasHiddenLTOVisibility(RD);
   llvm::Value *VirtualFn = nullptr;

evgeny777 wrote:
> Why are we checking for hidden visibility here?
This one is leftover from an earlier attempt at doing something more clever 
during GlobalOpt to decide whether we should be doing VFE or not, and I 
eventually abandoned that as it didn't work well, and went with the module flag 
here. You're right that we should be emitting the type test here under 
WholeProgramVtables, and not just with hidden visibility, but that belongs in 
D71913 (where I make the other change to insert type tests without hidden 
visibility). I've removed this change from this patch and am going to add it 
along with a test to that later patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71907



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

[PATCH] D72484: [clang-tidy] Fix check for Abseil internal namespace access

[Eric Fiselier via Phabricator via cfe-commits]

EricWF closed this revision.
EricWF added a comment.

Committed in 020ed6713d889a95f8c98d7725c87b458d99f6b3 
.


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

https://reviews.llvm.org/D72484



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

[PATCH] D73007: [Sema] Avoid Wrange-loop-analysis false positives

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert added a comment.

I also still think that `warn_for_range_copy` //should be// emitted even in 
templates.

These aren't false positives in my opinion, especially since we're now pretty 
conservative about that warning.




Comment at: clang/lib/Sema/SemaStmt.cpp:2703-2704
 // suggest the const reference type that would do so.
 // For instance, given "for (const  : Range)", suggest
 // "for (const Foo : Range)" to denote a copy is made for the loop.  If
 // possible, also suggest "for (const  : Range)" if this type prevents

Mordante wrote:
> aaronpuchert wrote:
> > That's the part the bothers me.
> I think we shouldn't remove the warning, it is useful. We can consider to 
> move this out of -Wall, but I first like to hear the opinion of the other 
> reviewers in this matter. If we want this change I'll be happy to create a 
> new patch.
I don't see a problem with having this as an optional warning that can be 
turned on for those who want it.

Note that this isn't my personal opinion, I'm actually fine with it. But I've 
met considerable resistance to turning the warning on before, and it's somewhat 
hard to argue against that. Binding references to temporaries is perfectly 
normal C++, and we don't discourage it anywhere else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73007



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

[PATCH] D73098: [clang-tidy] readability-identifier-naming disregards parameters restrictions on main like functions

[Mark de Wever via Phabricator via cfe-commits]

Mordante added a comment.

Would it make sense to also allow wmain with wchar_t? 
https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=vs-2019


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73098



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

[clang-tools-extra] 020ed67 - [clang-tidy] Fix check for Abseil internal namespace access

[Eric Fiselier via cfe-commits]

Author: Eric Fiselier
Date: 2020-01-21T15:21:53-05:00
New Revision: 020ed6713d889a95f8c98d7725c87b458d99f6b3

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

LOG: [clang-tidy] Fix check for Abseil internal namespace access

This change makes following modifications:
  * If reference originated from macro expansion, we report location inside of
the macro instead of location where macro is referenced.
  * If for any reason deduced location is not correct we silently ignore it.

Patch by Gennadiy Rozental (roge...@google.com)
Reviewed as https://reviews.llvm.org/D72484

Added: 


Modified: 
clang-tools-extra/clang-tidy/abseil/NoInternalDependenciesCheck.cpp

clang-tools-extra/test/clang-tidy/checkers/Inputs/absl/strings/internal-file.h

clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/abseil/NoInternalDependenciesCheck.cpp 
b/clang-tools-extra/clang-tidy/abseil/NoInternalDependenciesCheck.cpp
index dcb8585d55a9..3ce937a75649 100644
--- a/clang-tools-extra/clang-tidy/abseil/NoInternalDependenciesCheck.cpp
+++ b/clang-tools-extra/clang-tidy/abseil/NoInternalDependenciesCheck.cpp
@@ -37,7 +37,13 @@ void NoInternalDependenciesCheck::check(const 
MatchFinder::MatchResult )
   const auto *InternalDependency =
   Result.Nodes.getNodeAs("InternalDep");
 
-  diag(InternalDependency->getBeginLoc(),
+  SourceLocation LocAtFault =
+  Result.SourceManager->getSpellingLoc(InternalDependency->getBeginLoc());
+
+  if (!LocAtFault.isValid())
+return;
+
+  diag(LocAtFault,
"do not reference any 'internal' namespaces; those implementation "
"details are reserved to Abseil");
 }

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/Inputs/absl/strings/internal-file.h
 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/absl/strings/internal-file.h
index 6014278e2606..31798661a80f 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/Inputs/absl/strings/internal-file.h
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/Inputs/absl/strings/internal-file.h
@@ -15,6 +15,8 @@ template  P InternalTemplateFunction(P a) {}
 
 namespace container_internal {
 struct InternalStruct {};
+
+template  struct InternalTemplate {};
 } // namespace container_internal
 } // namespace absl
 

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
 
b/clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
index 272d0060bdb7..2949d7fdd027 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/abseil-no-internal-dependencies.cpp
@@ -44,5 +44,18 @@ std::string Str = absl::StringsFunction("a");
 void MacroUse() {
   USE_INTERNAL(Function); // no-warning
   USE_EXTERNAL(Function);
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: do not reference any 'internal' 
namespaces; those implementation details are reserved to Abseil
+  // CHECK-MESSAGES: :[[@LINE-5]]:25: warning: do not reference any 'internal' 
namespaces; those implementation details are reserved to Abseil
 }
+
+class A : absl::container_internal::InternalStruct {};
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not reference any 'internal' 
namespaces; those implementation details are reserved to Abseil
+
+template 
+class B : absl::container_internal::InternalTemplate {};
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: do not reference any 'internal' 
namespaces; those implementation details are reserved to Abseil
+
+template  class C : absl::container_internal::InternalTemplate {
+public:
+  template  static C Make(U *p) { return C{}; }
+};
+// CHECK-MESSAGES: :[[@LINE-4]]:33: warning: do not reference any 'internal' 
namespaces; those implementation details are reserved to Abseil



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

[PATCH] D72996: [Sema] Attempt to perform call-size-specific `__attribute__((alloc_align(param_idx)))` validation

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:4489
+// Alignment calculations can wrap around if it's greater than 2**29.
+unsigned MaximumAlignment = 536870912;
+if (I > MaximumAlignment)

erichkeane wrote:
> I thought we had this stored somewhere else?  We probably should have this be 
> a constant somewhere in the frontend.  I THINK I remember doing a review 
> where I pulled this value into clang somewhere...
That was D72998, and I don't think Clang is the right place for this constant. 
It is a property of the llvm alignment attribute and it should live there. 
Thus, llvm/include/Attributes.h or some similar place. Can't we "fix" the 
linker error by making it a constexpr global or are the errors because of other 
file content? If the latter, we could go with a llvm/include/magic_constants.h 
;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72996



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

[PATCH] D73128: [OPENMP][NVPTX]Add NVPTX specific definitions for new/delete operators.

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

merge_guards_bot added a comment.

{icon times-circle color=red} Unit tests: fail. 62080 tests passed, 1 failed 
and 784 were skipped.

  failed: Clang.Driver/cc-print-options.c

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

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

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



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73128



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

[PATCH] D73072: [Driver][CodeGen] Support -fpatchable-function-entry=N,M where M>0

[Fangrui Song via Phabricator via cfe-commits]

MaskRay updated this revision to Diff 239400.
MaskRay added a comment.

Improve tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73072

Files:
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/CC1Options.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/patchable-function-entry.c
  clang/test/Sema/patchable-function-entry-attr.c

Index: clang/test/Sema/patchable-function-entry-attr.c
===
--- clang/test/Sema/patchable-function-entry-attr.c
+++ clang/test/Sema/patchable-function-entry-attr.c
@@ -13,5 +13,5 @@
 // expected-error@+1 {{'patchable_function_entry' attribute requires parameter 0 to be an integer constant}}
 __attribute__((patchable_function_entry(i))) void f();
 
-// expected-error@+1 {{'patchable_function_entry' attribute requires integer constant between 0 and 0 inclusive}}
-__attribute__((patchable_function_entry(1, 1))) void f();
+// expected-error@+1 {{'patchable_function_entry' attribute requires integer constant between 0 and 2 inclusive}}
+__attribute__((patchable_function_entry(2, 3))) void f();
Index: clang/test/CodeGen/patchable-function-entry.c
===
--- clang/test/CodeGen/patchable-function-entry.c
+++ clang/test/CodeGen/patchable-function-entry.c
@@ -17,10 +17,20 @@
 __attribute__((patchable_function_entry(2, 0))) void f20decl();
 void f20decl() {}
 
-// OPT: define void @f() #2
+// CHECK: define void @f44() #2
+__attribute__((patchable_function_entry(4, 4))) void f44() {}
+
+// CHECK: define void @f52() #3
+__attribute__((patchable_function_entry(5, 2))) void f52() {}
+
+// OPT: define void @f() #4
 void f() {}
 
-/// M in patchable_function_entry(N,M) is currently ignored.
-// CHECK: attributes #0 = { {{.*}} "patchable-function-entry"="0"
+/// No need to emit "patchable-function-entry"="0"
+// CHECK: attributes #0 = { {{.*}}
+// CHECK-NOT: "patchable-function-entry"
+
 // CHECK: attributes #1 = { {{.*}} "patchable-function-entry"="2"
-// OPT:   attributes #2 = { {{.*}} "patchable-function-entry"="1"
+// CHECK: attributes #2 = { {{.*}} "patchable-function-entry"="0" "patchable-function-prefix"="4"
+// CHECK: attributes #3 = { {{.*}} "patchable-function-entry"="3" "patchable-function-prefix"="2"
+// OPT:   attributes #4 = { {{.*}} "patchable-function-entry"="1"
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -4924,9 +4924,9 @@
 Expr *Arg = AL.getArgAsExpr(1);
 if (!checkUInt32Argument(S, AL, Arg, Offset, 1, true))
   return;
-if (Offset) {
+if (Count < Offset) {
   S.Diag(getAttrLoc(AL), diag::err_attribute_argument_out_of_range)
-  <<  << 0 << 0 << Arg->getBeginLoc();
+  <<  << 0 << Count << Arg->getBeginLoc();
   return;
 }
   }
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1102,6 +1102,8 @@
 
   Opts.PatchableFunctionEntryCount =
   getLastArgIntValue(Args, OPT_fpatchable_function_entry_EQ, 0, Diags);
+  Opts.PatchableFunctionEntryOffset = getLastArgIntValue(
+  Args, OPT_fpatchable_function_entry_offset_EQ, 0, Diags);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
   Opts.CallFEntry = Args.hasArg(OPT_mfentry);
   Opts.MNopMCount = Args.hasArg(OPT_mnop_mcount);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5111,20 +5111,23 @@
 
   if (Arg *A = Args.getLastArg(options::OPT_fpatchable_function_entry_EQ)) {
 StringRef S0 = A->getValue(), S = S0;
-unsigned Size, Start = 0;
+unsigned Size, Offset = 0;
 if (!Triple.isAArch64() && Triple.getArch() != llvm::Triple::x86 &&
 Triple.getArch() != llvm::Triple::x86_64)
   D.Diag(diag::err_drv_unsupported_opt_for_target)
   << A->getAsString(Args) << TripleStr;
 else if (S.consumeInteger(10, Size) ||
  (!S.empty() && (!S.consume_front(",") ||
- S.consumeInteger(10, Start) || !S.empty(
+ S.consumeInteger(10, Offset) || !S.empty(
   D.Diag(diag::err_drv_invalid_argument_to_option)
   << S0 << A->getOption().getName();
-else if (Start)
+else if (Size < Offset)
   

[clang] 41fcd17 - [Sema] Avoid Wrange-loop-analysis false positives

[Mark de Wever via cfe-commits]

Author: Mark de Wever
Date: 2020-01-21T21:14:10+01:00
New Revision: 41fcd17250fa0526e4b7fd2c7df7721b0f79b683

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

LOG: [Sema] Avoid Wrange-loop-analysis false positives

When Wrange-loop-analysis issues a diagnostic on a dependent type in a
template the diagnostic may not be valid for all instantiations. Therefore
the diagnostic is suppressed during the instantiation. Non dependent types
still issue a diagnostic.

The same can happen when using macros. Therefore the diagnostic is
disabled for macros.

Fixes https://bugs.llvm.org/show_bug.cgi?id=44556

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

Added: 


Modified: 
clang/lib/Sema/SemaStmt.cpp
clang/test/SemaCXX/warn-range-loop-analysis.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index d6c3af9e84c8..ff6481006280 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -2838,6 +2838,9 @@ static void DiagnoseForRangeConstVariableCopies(Sema 
,
 ///Suggest "const foo " to prevent the copy.
 static void DiagnoseForRangeVariableCopies(Sema ,
const CXXForRangeStmt *ForStmt) {
+  if (SemaRef.inTemplateInstantiation())
+return;
+
   if (SemaRef.Diags.isIgnored(diag::warn_for_range_const_reference_copy,
   ForStmt->getBeginLoc()) &&
   SemaRef.Diags.isIgnored(diag::warn_for_range_variable_always_copy,
@@ -2860,6 +2863,9 @@ static void DiagnoseForRangeVariableCopies(Sema ,
   if (!InitExpr)
 return;
 
+  if (InitExpr->getExprLoc().isMacroID())
+return;
+
   if (VariableType->isReferenceType()) {
 DiagnoseForRangeReferenceVariableCopies(SemaRef, VD,
 
ForStmt->getRangeInit()->getType());

diff  --git a/clang/test/SemaCXX/warn-range-loop-analysis.cpp 
b/clang/test/SemaCXX/warn-range-loop-analysis.cpp
index 53b0ca288194..951844c953ef 100644
--- a/clang/test/SemaCXX/warn-range-loop-analysis.cpp
+++ b/clang/test/SemaCXX/warn-range-loop-analysis.cpp
@@ -454,3 +454,75 @@ void test10() {
   // expected-note@-2 {{'Bar'}}
   // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:17-[[@LINE-3]]:18}:" "
 }
+
+template 
+void test_template_function() {
+  // In a template instantiation the diagnostics should not be emitted for
+  // loops with dependent types.
+  Container C;
+  for (const Bar  : C) {}
+  // expected-warning@-1 {{always a copy}}
+  // expected-note@-2 {{'Bar'}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:18-[[@LINE-3]]:19}:""
+
+  Container Dependent;
+  for (const T  : Dependent) {}
+}
+template void test_template_function();
+
+template 
+struct test_template_struct {
+  static void static_member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+
+  void member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+};
+template struct test_template_struct;
+
+struct test_struct_with_templated_member {
+  void member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+  }
+
+  template 
+  void template_member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+};
+template void test_struct_with_templated_member::template_member();
+
+#define TEST_MACRO\
+  void test_macro() { \
+Container C; \
+for (const Bar  : C) {} \
+  }
+
+TEST_MACRO



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

[PATCH] D73007: [Sema] Avoid Wrange-loop-analysis false positives

[Mark de Wever via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Mordante marked an inline comment as done.
Closed by commit rG41fcd17250fa: [Sema] Avoid Wrange-loop-analysis false 
positives (authored by Mordante).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73007

Files:
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaCXX/warn-range-loop-analysis.cpp

Index: clang/test/SemaCXX/warn-range-loop-analysis.cpp
===
--- clang/test/SemaCXX/warn-range-loop-analysis.cpp
+++ clang/test/SemaCXX/warn-range-loop-analysis.cpp
@@ -454,3 +454,75 @@
   // expected-note@-2 {{'Bar'}}
   // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:17-[[@LINE-3]]:18}:" "
 }
+
+template 
+void test_template_function() {
+  // In a template instantiation the diagnostics should not be emitted for
+  // loops with dependent types.
+  Container C;
+  for (const Bar  : C) {}
+  // expected-warning@-1 {{always a copy}}
+  // expected-note@-2 {{'Bar'}}
+  // CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:18-[[@LINE-3]]:19}:""
+
+  Container Dependent;
+  for (const T  : Dependent) {}
+}
+template void test_template_function();
+
+template 
+struct test_template_struct {
+  static void static_member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+
+  void member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+};
+template struct test_template_struct;
+
+struct test_struct_with_templated_member {
+  void member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+  }
+
+  template 
+  void template_member() {
+Container C;
+for (const Bar  : C) {}
+// expected-warning@-1 {{always a copy}}
+// expected-note@-2 {{'Bar'}}
+// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:20-[[@LINE-3]]:21}:""
+
+Container Dependent;
+for (const T  : Dependent) {}
+  }
+};
+template void test_struct_with_templated_member::template_member();
+
+#define TEST_MACRO\
+  void test_macro() { \
+Container C; \
+for (const Bar  : C) {} \
+  }
+
+TEST_MACRO
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -2838,6 +2838,9 @@
 ///Suggest "const foo " to prevent the copy.
 static void DiagnoseForRangeVariableCopies(Sema ,
const CXXForRangeStmt *ForStmt) {
+  if (SemaRef.inTemplateInstantiation())
+return;
+
   if (SemaRef.Diags.isIgnored(diag::warn_for_range_const_reference_copy,
   ForStmt->getBeginLoc()) &&
   SemaRef.Diags.isIgnored(diag::warn_for_range_variable_always_copy,
@@ -2860,6 +2863,9 @@
   if (!InitExpr)
 return;
 
+  if (InitExpr->getExprLoc().isMacroID())
+return;
+
   if (VariableType->isReferenceType()) {
 DiagnoseForRangeReferenceVariableCopies(SemaRef, VD,
 ForStmt->getRangeInit()->getType());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72829: Implement -fsemantic-interposition

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: llvm/lib/IR/Globals.cpp:101
+return true;
+  return isInterposableLinkage(getLinkage());
+}

MaskRay wrote:
> MaskRay wrote:
> > Checking `isInterposableLinkage(getLinkage())` first may be more efficient.
> `if (!isInterposableLinkage(getLinkage())) return false;`
```lang=cpp
if (!isInterposableLinkage(getLinkage()))
  return false;
return getParent() && getParent()->getSemanticInterposition() && !isDSOLocal();
```



Comment at: llvm/lib/IR/Module.cpp:564
+
+  return cast(Val->getValue())->getZExtValue();
+}

A test/llvm/Verifier/ test checking "SemanticInterposition" must be a 
ConstantInt will be nice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72829



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

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

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D72982#1832058 , @xazax.hun wrote:

> In D72982#1832029 , @aganea wrote:
>
> > In D72982#1832000 , @xazax.hun 
> > wrote:
> >
> > > Thanks! Alternatively we could try to push the changes to all three 
> > > versions and revert this patch once all of them are accepted and a new 
> > > pip package is published.
> >
> >
> > @xazax.hun In that case do you think it'd be possible for scan-build to 
> > handle a more structured format like a CDB? (and inherently make clang emit 
> > that)
>
>
> In case you refer to compilation database, scan-build-py already does handle 
> that. The cc1 command line is used to avoid duplicating driver logic in 
> scan-build. So sometimes, when scan-build want to peak the cc1 commands it 
> will get it using `-###` instead of trying to infer them from the (driver) 
> command that is available in the compilation database.


I think the point is to provide a machine-readable alternative to `-###` - that 
would, say, write down one line of compilation database.

The alternative solution would be to teach scan-build to wrap its extra flags 
with `-Xclang`, which is how it should have behaved to begin with. I'm not sure 
we're actually removing any `-cc1` flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72982



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