[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-17 Thread Balázs Kéri via Phabricator via cfe-commits
balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

aaron.ballman wrote:
> Can you also add tests for:
> ```
> int vla_unevaluated(int x) {
>   // Evaluates the ++x
>   sizeof(int[++x]);
>   // Does not evaluate the ++x
>   _Alignof(int[++x]);
>   _Generic((int(*)[++x])0, default : 0);
>   
>   return x;
> }
> ```
> 
> Also, it's a bit strange to find these VLA tests in a .cpp file. VLAs are a 
> C++ extension and we should have some testing for them for constructs that 
> are C++-specific, but I would have expected many of these tests to be in a C 
> file instead.
Could be there platforms (on buildbot?) where the VLA code (in cpp file) does 
not compile? Is it worth to have a test with VLA type alias then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-17 Thread Balázs Kéri via Phabricator via cfe-commits
balazske marked an inline comment as done.
balazske added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

balazske wrote:
> aaron.ballman wrote:
> > Can you also add tests for:
> > ```
> > int vla_unevaluated(int x) {
> >   // Evaluates the ++x
> >   sizeof(int[++x]);
> >   // Does not evaluate the ++x
> >   _Alignof(int[++x]);
> >   _Generic((int(*)[++x])0, default : 0);
> >   
> >   return x;
> > }
> > ```
> > 
> > Also, it's a bit strange to find these VLA tests in a .cpp file. VLAs are a 
> > C++ extension and we should have some testing for them for constructs that 
> > are C++-specific, but I would have expected many of these tests to be in a 
> > C file instead.
> Could be there platforms (on buildbot?) where the VLA code (in cpp file) does 
> not compile? Is it worth to have a test with VLA type alias then?
I have this output for the test above (without the new code), is it correct?
(The `++` seems to be evaluated for the `alignof` statement too.)
```
int vla_unevaluated(int x)
 [B2 (ENTRY)]
   Succs (1): B1

 [B1]
   1: x
   2: ++[B1.1]
   3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
   4: sizeof(int [++x])
   5: x
   6: ++[B1.5]
   7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
   8: alignof(int [++x])
   9: 0
  10: x
  11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
  12: return [B1.11];
   Preds (1): B2
   Succs (1): B0

 [B0 (EXIT)]
   Preds (1): B1

```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-17 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.
Herald added subscribers: phosek, mgehre.

IMHO we should proceed with this patch.
There's been several patches recently that seem to not care about 
false-positive rate,
and in this case the cost of true-positive can be humongous, as i/we've been 
finding
lots of bugs exactly like this in openmp optimization pass, attributor 
framework :/


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D46317



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


[clang] fd7a341 - [Fixed Point] Move the compassign LHS type correction a bit further down. NFCI.

2020-04-17 Thread Bevin Hansson via cfe-commits

Author: Bevin Hansson
Date: 2020-04-17T10:09:02+02:00
New Revision: fd7a34186137168064ffe2ca536823559b92d939

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

LOG: [Fixed Point] Move the compassign LHS type correction a bit further down. 
NFCI.

Summary:
We can simplify the LHSTy correction for
fixed-point compassign by moving it below
the point where we know we have a compound
assignment.

Also, we shouldn't look at the LHS and RHS
separately; look at the computation result
type instead.

Looking at the LHS and RHS is also wrong
for compassigns with fixed and floating
point (though this does not work upstream
yet).

Reviewers: leonardchan

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 60d99db7ced9..31d694857e9c 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -13639,14 +13639,6 @@ ExprResult Sema::CreateBuiltinBinOp(SourceLocation 
OpLoc,
   if (ResultTy.isNull() || LHS.isInvalid() || RHS.isInvalid())
 return ExprError();
 
-  // The LHS is not converted to the result type for fixed-point compound
-  // assignment as the common type is computed on demand. Reset the CompLHSTy
-  // to the LHS type we would have gotten after unary conversions.
-  if (!CompLHSTy.isNull() &&
-  (LHS.get()->getType()->isFixedPointType() ||
-   RHS.get()->getType()->isFixedPointType()))
-CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
-
   if (ResultTy->isRealFloatingType() &&
   (getLangOpts().getFPRoundingMode() != RoundingMode::NearestTiesToEven ||
getLangOpts().getFPExceptionMode() != LangOptions::FPE_Ignore))
@@ -13705,6 +13697,12 @@ ExprResult Sema::CreateBuiltinBinOp(SourceLocation 
OpLoc,
 OK = LHS.get()->getObjectKind();
   }
 
+  // The LHS is not converted to the result type for fixed-point compound
+  // assignment as the common type is computed on demand. Reset the CompLHSTy
+  // to the LHS type we would have gotten after unary conversions.
+  if (CompResultTy->isFixedPointType())
+CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
+
   if (ConvertHalfVec)
 return convertHalfVecBinOp(*this, LHS, RHS, Opc, ResultTy, VK, OK, true,
OpLoc, CurFPFeatures);



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


[PATCH] D78338: [clangd] Enable diagnostic fixes within macro argument expansions.

2020-04-17 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang-tools-extra/clangd/Diagnostics.cpp:563
+for (auto &FixIt : FixIts) {
+  // Allow fixits within a single macro-arg expansion to be applied.
+  if (FixIt.RemoveRange.getBegin().isMacroID() &&

I feel a bit nervous about this (even it is for macro-arg expansion only), as 
macro is very tricky.

I think we may result in invalid code after applying the fixits in some cases:

1) if the fix is to remove an unused variable (interestingly, clang doesn't 
provide fixit to remove an unused variable, but for unused lambda capture, it 
does)

```
#define LA(arg1, arg2) [arg1, arg2] { return arg2;}
void test1(int x, int y) {
  LA(x, y); // after fixit, it would become LA(, y)? or LA(y)
}
```

2) if the fix is to add some characters to the macro argument, e.g. adding a 
dereference `*`, the semantic of the code after macro expansion maybe changed.

```
void f1(int &a);
void f2(int *a) {
   f1(a); // clang will emits a diagnostic with a fixit adding preceding a `*` 
to a.
}
```

maybe we should be more conservative? just whitelist some diagnostics? fixing 
typos seems pretty safe.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78338



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


[PATCH] D78024: [FileCheck] - Fix the false positive when -implicit-check-not is used with an unknown -check-prefix.

2020-04-17 Thread George Rimar via Phabricator via cfe-commits
grimar marked an inline comment as done.
grimar added inline comments.



Comment at: llvm/lib/Support/FileCheck.cpp:1375-1377
+  // We do not allow using -implicit-check-not when an explicitly specified
+  // check prefix is not present in the input buffer.
+  if ((Req.IsDefaultCheckPrefix || FoundUsedPrefix) && !DagNotMatches.empty()) 
{

jdenny wrote:
> grimar wrote:
> > jdenny wrote:
> > > grimar wrote:
> > > > jdenny wrote:
> > > > > I find this logic confusing.  Its goal appears to be to constrain 
> > > > > when `DagNotMatches` are added to `CheckStrings`.  However, the real 
> > > > > goal is to constrain when FileCheck complains that there are no used 
> > > > > prefixes.  Would the following logic work?
> > > > > 
> > > > > ```
> > > > > if (!FoundUsedPrefix && (ImplicitNegativeChecks.empty() || 
> > > > > !Req.IsDefaultCheckPrefix)) {
> > > > >   errs() << "error: no check strings found with prefix"
> > > > >   . . .
> > > > > }
> > > > > if (!DagNotMatches.empty()) {
> > > > >   CheckStrings->emplace_back(
> > > > >   . . .
> > > > > }
> > > > > ```
> > > > This looks better and works, thanks!
> > > > 
> > > > (The code above has `DagNotMatches = ImplicitNegativeChecks;` line 
> > > > which is also a bit confusing probably)
> > > > This looks better and works, thanks!
> > > 
> > > Thanks for making that change.
> > > 
> > > > (The code above has DagNotMatches = ImplicitNegativeChecks; line which 
> > > > is also a bit confusing probably)
> > > 
> > > I'm fine with that one.  DagNotMatches starts out as 
> > > ImplicitNegativeChecks, and CHECK-NOTs might be added later.
> > > 
> > > I think the second sentence in the following comment still reflects the 
> > > old logic:
> > > 
> > > ```
> > >   // When there are no used prefixes we report an error.
> > >   // We do not allow using -implicit-check-not when an explicitly 
> > > specified
> > >   // check prefix is not present in the input buffer.
> > > ```
> > > 
> > > Something like the following seems better to me:
> > > 
> > > ```
> > >   // When there are no used prefixes we report an error except in the 
> > > case that
> > >   // no prefix is specified explicitly but -implicit-check-not is 
> > > specified.
> > > ```
> > > 
> > > the real goal is to constrain when FileCheck complains that there are no 
> > > used prefixes
> > 
> > btw, do you know why FileCheck seems intentionally allows the case when 
> > `--check-prefixes=KNOWN,UNKNOWN`?
> > I've mentioned in the description of D78110 that there are about 1000 tests 
> > that have this. but is it a feature or a something that we might want to 
> > fix?
> There was a long discussion about diagnostics like that over a year ago.  I 
> believe we described that case as prefixes that are defined but not used.
> 
> In some of my downstream work, I often create FileCheck prefix schemes 
> reflecting various combinations of features I want to test.  For example: 
> FOO, BAR, FOO-AND-BAR, FOO-NOT-BAR, etc.  It's far easier to maintain those 
> tests if I list all appropriate prefixes for each FileCheck command even if 
> some prefixes are not currently used in the test file.  I don't know if this 
> use case exists upstream right now.
> 
> Also, when developing or debugging tests involving many prefixes and many 
> FileCheck commands, I think it could be painful to have to update all 
> FileCheck commands every time you temporarily remove the only uses of some 
> prefix.
> 
> If you pursue this diagnostic, please make it optional, even if on by 
> default.  At one time, we discussed a warning system for such diagnostics.  
> Warnings could be configurable via command-line options, possibly passed via 
> the FILECHECK_OPTS env var so that it's easy to relax them during debugging 
> or based on a test suite's specific needs.
> 
> @probinson and @SjoerdMeijer might want to chime in as they were also part of 
> previous discussions.
I see, thanks for details.

D78110 and this patch (which revealed rG09331fd7) showed that we had test cases 
committed which
had unknown prefixes placed by mistake and hence false positives.
I remember how accidentally pushed on review the patch with the same issue and 
nobody noticed..
I just think that making FileCheck stricter could prevent such issues.

If we'll have a consensus about making `--check-prefixes` stricter I'll be 
happy to work on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78024



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


[PATCH] D78294: [Fixed Point] Move the compassign LHS type correction a bit further down. NFCI.

2020-04-17 Thread Bevin Hansson via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfd7a34186137: [Fixed Point] Move the compassign LHS type 
correction a bit further down. NFCI. (authored by ebevhan).

Changed prior to commit:
  https://reviews.llvm.org/D78294?vs=258033&id=258251#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78294

Files:
  clang/lib/Sema/SemaExpr.cpp


Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -13639,14 +13639,6 @@
   if (ResultTy.isNull() || LHS.isInvalid() || RHS.isInvalid())
 return ExprError();
 
-  // The LHS is not converted to the result type for fixed-point compound
-  // assignment as the common type is computed on demand. Reset the CompLHSTy
-  // to the LHS type we would have gotten after unary conversions.
-  if (!CompLHSTy.isNull() &&
-  (LHS.get()->getType()->isFixedPointType() ||
-   RHS.get()->getType()->isFixedPointType()))
-CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
-
   if (ResultTy->isRealFloatingType() &&
   (getLangOpts().getFPRoundingMode() != RoundingMode::NearestTiesToEven ||
getLangOpts().getFPExceptionMode() != LangOptions::FPE_Ignore))
@@ -13705,6 +13697,12 @@
 OK = LHS.get()->getObjectKind();
   }
 
+  // The LHS is not converted to the result type for fixed-point compound
+  // assignment as the common type is computed on demand. Reset the CompLHSTy
+  // to the LHS type we would have gotten after unary conversions.
+  if (CompResultTy->isFixedPointType())
+CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
+
   if (ConvertHalfVec)
 return convertHalfVecBinOp(*this, LHS, RHS, Opc, ResultTy, VK, OK, true,
OpLoc, CurFPFeatures);


Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -13639,14 +13639,6 @@
   if (ResultTy.isNull() || LHS.isInvalid() || RHS.isInvalid())
 return ExprError();
 
-  // The LHS is not converted to the result type for fixed-point compound
-  // assignment as the common type is computed on demand. Reset the CompLHSTy
-  // to the LHS type we would have gotten after unary conversions.
-  if (!CompLHSTy.isNull() &&
-  (LHS.get()->getType()->isFixedPointType() ||
-   RHS.get()->getType()->isFixedPointType()))
-CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
-
   if (ResultTy->isRealFloatingType() &&
   (getLangOpts().getFPRoundingMode() != RoundingMode::NearestTiesToEven ||
getLangOpts().getFPExceptionMode() != LangOptions::FPE_Ignore))
@@ -13705,6 +13697,12 @@
 OK = LHS.get()->getObjectKind();
   }
 
+  // The LHS is not converted to the result type for fixed-point compound
+  // assignment as the common type is computed on demand. Reset the CompLHSTy
+  // to the LHS type we would have gotten after unary conversions.
+  if (CompResultTy->isFixedPointType())
+CompLHSTy = UsualUnaryConversions(LHS.get()).get()->getType();
+
   if (ConvertHalfVec)
 return convertHalfVecBinOp(*this, LHS, RHS, Opc, ResultTy, VK, OK, true,
OpLoc, CurFPFeatures);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0642e5e - [clang-tidy] modernize-use-using: Fix broken fixit with 'template' keyword

2020-04-17 Thread Matthias Gehre via cfe-commits

Author: Matthias Gehre
Date: 2020-04-17T10:37:24+02:00
New Revision: 0642e5e7a7e54a11120262cfafea0193e3a75faf

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

LOG: [clang-tidy] modernize-use-using: Fix broken fixit with 'template' keyword

Summary:
Before this PR, `modernize-use-using` would transform the typedef in
```

template  class TemplateKeyword {
  typedef typename a::template f<> e;
  typedef typename a::template f<>::d e2;
};
```
into
```
template  class TemplateKeyword {
  using d = typename a::b<>;
  using d2 = typename a::template a::b<>::c;
};
```
The first one is missing the `template` keyword,
the second one has an extra `a::` scope. Both result
in compilation errors.

Reviewers: aaron.ballman, alexfh, hokein, njames93

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
clang/lib/AST/NestedNameSpecifier.cpp
clang/lib/AST/TypePrinter.cpp
clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp

Removed: 




diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
index 2eccc9066fa6..8d25dbb95658 100644
--- a/clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
+++ b/clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
@@ -249,6 +249,17 @@ typedef TwoArgTemplate 
>, S<(0 < 0), Q>, S<(0 < 0), Q>>;
 
+template 
+class TemplateKeyword {
+  typedef typename a::template b<> d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use 'using' instead of 'typedef'
+  // CHECK-FIXES: using d = typename a::template b<>;
+
+  typedef typename a::template b<>::c d2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use 'using' instead of 'typedef'
+  // CHECK-FIXES: using d2 = typename a::template b<>::c;
+};
+
 template 
 class Variadic {};
 

diff  --git a/clang/lib/AST/NestedNameSpecifier.cpp 
b/clang/lib/AST/NestedNameSpecifier.cpp
index af53c7fd9ba4..e28463516a9f 100644
--- a/clang/lib/AST/NestedNameSpecifier.cpp
+++ b/clang/lib/AST/NestedNameSpecifier.cpp
@@ -311,6 +311,14 @@ void NestedNameSpecifier::print(raw_ostream &OS, const 
PrintingPolicy &Policy,
   // Print the template argument list.
   printTemplateArgumentList(OS, SpecType->template_arguments(),
 InnerPolicy);
+} else if (const auto *DepSpecType =
+   dyn_cast(T)) {
+  // Print the template name without its corresponding
+  // nested-name-specifier.
+  OS << DepSpecType->getIdentifier()->getName();
+  // Print the template argument list.
+  printTemplateArgumentList(OS, DepSpecType->template_arguments(),
+InnerPolicy);
 } else {
   // Print the type normally
   QualType(T, 0).print(OS, InnerPolicy);

diff  --git a/clang/lib/AST/TypePrinter.cpp b/clang/lib/AST/TypePrinter.cpp
index 405a760c58ce..4cc0d735ed6a 100644
--- a/clang/lib/AST/TypePrinter.cpp
+++ b/clang/lib/AST/TypePrinter.cpp
@@ -1388,7 +1388,7 @@ void 
TypePrinter::printDependentTemplateSpecializationBefore(
 
   if (T->getQualifier())
 T->getQualifier()->print(OS, Policy);
-  OS << T->getIdentifier()->getName();
+  OS << "template " << T->getIdentifier()->getName();
   printTemplateArgumentList(OS, T->template_arguments(), Policy);
   spaceBeforePlaceHolder(OS);
 }

diff  --git a/clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp 
b/clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
index b8903b884e0a..15cbe6637845 100644
--- a/clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
+++ b/clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
@@ -109,9 +109,9 @@ static_assert(!requires { typename ::F; });
 struct G { template static T temp; };
 
 template requires requires { typename T::template temp; }
-// expected-note@-1{{because 'typename T::temp' would be invalid: type 
'int' cannot be used prior to '::' because it has no members}}
-// expected-note@-2{{because 'typename T::temp' would be invalid: no 
member named 'temp' in 'D'}}
-// expected-note@-3{{because 'typename T::temp' would be invalid: 
template name refers to non-type template 'G::template temp'}}
+// expected-note@-1{{because 'typename T::template temp' would be 
invalid: type 'int' cannot be used prior to '::' because it has no members}}
+// expected-note@-2{{because 'typename T::template temp' would be 
invalid: no member named 'temp' in 'D'}}
+// expected-note@-3{{because 'typename T::template temp' would be 
invalid: template name refers to non-type template 'G::template temp'}}
 struct r7 {};
 
 using r7i1 = r7; // expected-error

[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-17 Thread Matthias Gehre via Phabricator via cfe-commits
mgehre added inline comments.



Comment at: test/clang-tidy/bugprone-map-subscript-operator-lookup.cpp:60
+}
+
+void noWarning() {

We often have code like
```
auto &V = Map[Idx];
if (!V) {
  V = init();
}
use(V);
```
Would that be flagged by this check? Could you add a test for it (possibly with 
`FIXME`)?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D46317



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


[PATCH] D78139: [clang-tidy] modernize-use-using: Fix broken fixit with 'template' keyword

2020-04-17 Thread Matthias Gehre via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0642e5e7a7e5: [clang-tidy] modernize-use-using: Fix broken 
fixit with 'template' keyword (authored by mgehre).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78139

Files:
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-using.cpp
  clang/lib/AST/NestedNameSpecifier.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp


Index: clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
===
--- clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
+++ clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
@@ -109,9 +109,9 @@
 struct G { template static T temp; };
 
 template requires requires { typename T::template temp; }
-// expected-note@-1{{because 'typename T::temp' would be invalid: type 
'int' cannot be used prior to '::' because it has no members}}
-// expected-note@-2{{because 'typename T::temp' would be invalid: no 
member named 'temp' in 'D'}}
-// expected-note@-3{{because 'typename T::temp' would be invalid: 
template name refers to non-type template 'G::template temp'}}
+// expected-note@-1{{because 'typename T::template temp' would be 
invalid: type 'int' cannot be used prior to '::' because it has no members}}
+// expected-note@-2{{because 'typename T::template temp' would be 
invalid: no member named 'temp' in 'D'}}
+// expected-note@-3{{because 'typename T::template temp' would be 
invalid: template name refers to non-type template 'G::template temp'}}
 struct r7 {};
 
 using r7i1 = r7; // expected-error{{constraints not satisfied for class 
template 'r7' [with T = int]}}
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -1388,7 +1388,7 @@
 
   if (T->getQualifier())
 T->getQualifier()->print(OS, Policy);
-  OS << T->getIdentifier()->getName();
+  OS << "template " << T->getIdentifier()->getName();
   printTemplateArgumentList(OS, T->template_arguments(), Policy);
   spaceBeforePlaceHolder(OS);
 }
Index: clang/lib/AST/NestedNameSpecifier.cpp
===
--- clang/lib/AST/NestedNameSpecifier.cpp
+++ clang/lib/AST/NestedNameSpecifier.cpp
@@ -311,6 +311,14 @@
   // Print the template argument list.
   printTemplateArgumentList(OS, SpecType->template_arguments(),
 InnerPolicy);
+} else if (const auto *DepSpecType =
+   dyn_cast(T)) {
+  // Print the template name without its corresponding
+  // nested-name-specifier.
+  OS << DepSpecType->getIdentifier()->getName();
+  // Print the template argument list.
+  printTemplateArgumentList(OS, DepSpecType->template_arguments(),
+InnerPolicy);
 } else {
   // Print the type normally
   QualType(T, 0).print(OS, InnerPolicy);
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
@@ -249,6 +249,17 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: use 'using' instead of 'typedef'
 // CHECK-FIXES: using Nested_t = TwoArgTemplate>, S<(0 < 0), Q>>;
 
+template 
+class TemplateKeyword {
+  typedef typename a::template b<> d;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use 'using' instead of 'typedef'
+  // CHECK-FIXES: using d = typename a::template b<>;
+
+  typedef typename a::template b<>::c d2;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use 'using' instead of 'typedef'
+  // CHECK-FIXES: using d2 = typename a::template b<>::c;
+};
+
 template 
 class Variadic {};
 


Index: clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
===
--- clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
+++ clang/test/CXX/expr/expr.prim/expr.prim.req/type-requirement.cpp
@@ -109,9 +109,9 @@
 struct G { template static T temp; };
 
 template requires requires { typename T::template temp; }
-// expected-note@-1{{because 'typename T::temp' would be invalid: type 'int' cannot be used prior to '::' because it has no members}}
-// expected-note@-2{{because 'typename T::temp' would be invalid: no member named 'temp' in 'D'}}
-// expected-note@-3{{because 'typename T::temp' would be invalid: template name refers to non-type template 'G::template temp'}}
+// expected-note@-1{{because 'typename T::template temp' would be invalid: type 'int' cannot be used prior to '::' because it has no members}}
+// expected-note@-2{{because 'typename T::

[PATCH] D78350: [AST] Build recovery expressions by default for C++.

2020-04-17 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 258268.
hokein added a comment.
Herald added subscribers: usaxena95, kadircet, arphaman, jkorous.

fix clangd test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78350

Files:
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_namespace_1.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp
  clang/test/Parser/objcxx0x-lambda-expressions.mm
  clang/test/Parser/objcxx11-invalid-lambda.cpp
  clang/test/SemaCXX/cast-conversion.cpp
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/cxx1z-copy-omission.cpp
  clang/test/SemaCXX/decltype-crash.cpp
  clang/test/SemaCXX/varargs.cpp
  clang/test/SemaOpenCLCXX/address-space-references.cl
  clang/test/SemaTemplate/instantiate-init.cpp

Index: clang/test/SemaTemplate/instantiate-init.cpp
===
--- clang/test/SemaTemplate/instantiate-init.cpp
+++ clang/test/SemaTemplate/instantiate-init.cpp
@@ -108,7 +108,7 @@
 integral_c<1> ic1 = array_lengthof(Description::data);
 (void)sizeof(array_lengthof(Description::data));
 
-sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
+(void)sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
   Description::data // expected-note{{in instantiation of static data member 'PR7985::Description::data' requested here}}
   ));
 
Index: clang/test/SemaOpenCLCXX/address-space-references.cl
===
--- clang/test/SemaOpenCLCXX/address-space-references.cl
+++ clang/test/SemaOpenCLCXX/address-space-references.cl
@@ -11,7 +11,7 @@
 int bar(const unsigned int &i);
 
 void foo() {
-  bar(1) // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
+  bar(1); // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
 }
 
 // Test addr space conversion with nested pointers
Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -22,7 +22,8 @@
 // default ctor.
 void record_context(int a, ...) {
   struct Foo {
-// expected-error@+1 {{'va_start' cannot be used outside a function}}
+// expected-error@+2 {{'va_start' cannot be used outside a function}}
+// expected-error@+1 {{default argument references parameter 'a'}}
 void meth(int a, int b = (__builtin_va_start(ap, a), 0)) {}
   };
 }
Index: clang/test/SemaCXX/decltype-crash.cpp
===
--- clang/test/SemaCXX/decltype-crash.cpp
+++ clang/test/SemaCXX/decltype-crash.cpp
@@ -3,5 +3,8 @@
 int& a();
 
 void f() {
-  decltype(a()) c; // expected-warning {{'decltype' is a keyword in C++11}} expected-error {{use of undeclared identifier 'decltype'}}
+  decltype(a()) c; // expected-warning {{'decltype' is a keyword in C++11}} \
+   // expected-error {{use of undeclared identifier 'decltype'}} \
+   // expected-error {{expected ';' after expression}} \
+   // expected-error {{use of undeclared identifier 'c'}}
 }
Index: clang/test/SemaCXX/cxx1z-copy-omission.cpp
===
--- clang/test/SemaCXX/cxx1z-copy-omission.cpp
+++ clang/test/SemaCXX/cxx1z-copy-omission.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++1z -verify %s
+// RUN: %clang_cc1 -std=c++1z -verify -Wno-unused %s
 
 struct Noncopyable {
   Noncopyable();
@@ -107,8 +107,10 @@
   sizeof(make_indestructible()); // expected-error {{deleted}}
   sizeof(make_incomplete()); // expected-error {{incomplete}}
   typeid(Indestructible{}); // expected-error {{deleted}}
-  typeid(make_indestructible()); // expected-error {{deleted}}
-  typeid(make_incomplete()); // expected-error {{incomplete}}
+  typeid(make_indestructible()); // expected-error {{deleted}} \
+ // expected-error {{need to include }}
+  typeid(make_incomplete()); // expected-error {{incomplete}} \
+ // expected-error {{need to include }}
 
   // FIXME: The first two cases here are now also valid in C++17 onwards.
   using I = decltype(Indestructible()); // expected-error {{deleted}}
Index: clang/test/SemaCXX/constructor-initializer.cpp
===
--- clang/test/SemaCXX/constructor-initializer.cpp
+++ clang/test/SemaCXX/constructor-initializer.cpp
@@ -250

[PATCH] D78350: [AST] Build recovery expressions by default for C++.

2020-04-17 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
hokein updated this revision to Diff 258268.
hokein added a comment.
Herald added subscribers: usaxena95, kadircet, arphaman, jkorous.
hokein added subscribers: ebevhan, hubert.reinterpretcast.

fix clangd test.


hokein added a comment.

@ebevhan, @hubert.reinterpretcast, the patch is based on 
fd7a34186137168064ffe2ca536823559b92d939 
, it 
should contain all the fixes.
it would be nice if you can test it again in your downstream clang. Thanks!


Reland https://reviews.llvm.org/D76696.
All known crashes have been fixed, another attemption.

Plan:
we have rolled out this to a subset of internal users, I'd wait for one
or two weeks to make sure no new crashes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78350

Files:
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang/include/clang/Basic/LangOptions.def
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_namespace_1.cpp
  clang/test/OpenMP/target_update_from_messages.cpp
  clang/test/OpenMP/target_update_to_messages.cpp
  clang/test/Parser/objcxx0x-lambda-expressions.mm
  clang/test/Parser/objcxx11-invalid-lambda.cpp
  clang/test/SemaCXX/cast-conversion.cpp
  clang/test/SemaCXX/constructor-initializer.cpp
  clang/test/SemaCXX/cxx1z-copy-omission.cpp
  clang/test/SemaCXX/decltype-crash.cpp
  clang/test/SemaCXX/varargs.cpp
  clang/test/SemaOpenCLCXX/address-space-references.cl
  clang/test/SemaTemplate/instantiate-init.cpp

Index: clang/test/SemaTemplate/instantiate-init.cpp
===
--- clang/test/SemaTemplate/instantiate-init.cpp
+++ clang/test/SemaTemplate/instantiate-init.cpp
@@ -108,7 +108,7 @@
 integral_c<1> ic1 = array_lengthof(Description::data);
 (void)sizeof(array_lengthof(Description::data));
 
-sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
+(void)sizeof(array_lengthof( // expected-error{{no matching function for call to 'array_lengthof'}}
   Description::data // expected-note{{in instantiation of static data member 'PR7985::Description::data' requested here}}
   ));
 
Index: clang/test/SemaOpenCLCXX/address-space-references.cl
===
--- clang/test/SemaOpenCLCXX/address-space-references.cl
+++ clang/test/SemaOpenCLCXX/address-space-references.cl
@@ -11,7 +11,7 @@
 int bar(const unsigned int &i);
 
 void foo() {
-  bar(1) // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
+  bar(1); // expected-error{{binding reference of type 'const __global unsigned int' to value of type 'int' changes address space}}
 }
 
 // Test addr space conversion with nested pointers
Index: clang/test/SemaCXX/varargs.cpp
===
--- clang/test/SemaCXX/varargs.cpp
+++ clang/test/SemaCXX/varargs.cpp
@@ -22,7 +22,8 @@
 // default ctor.
 void record_context(int a, ...) {
   struct Foo {
-// expected-error@+1 {{'va_start' cannot be used outside a function}}
+// expected-error@+2 {{'va_start' cannot be used outside a function}}
+// expected-error@+1 {{default argument references parameter 'a'}}
 void meth(int a, int b = (__builtin_va_start(ap, a), 0)) {}
   };
 }
Index: clang/test/SemaCXX/decltype-crash.cpp
===
--- clang/test/SemaCXX/decltype-crash.cpp
+++ clang/test/SemaCXX/decltype-crash.cpp
@@ -3,5 +3,8 @@
 int& a();
 
 void f() {
-  decltype(a()) c; // expected-warning {{'decltype' is a keyword in C++11}} expected-error {{use of undeclared identifier 'decltype'}}
+  decltype(a()) c; // expected-warning {{'decltype' is a keyword in C++11}} \
+   // expected-error {{use of undeclared identifier 'decltype'}} \
+   // expected-error {{expected ';' after expression}} \
+   // expected-error {{use of undeclared identifier 'c'}}
 }
Index: clang/test/SemaCXX/cxx1z-copy-omission.cpp
===
--- clang/test/SemaCXX/cxx1z-copy-omission.cpp
+++ clang/test/SemaCXX/cxx1z-copy-omission.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++1z -verify %s
+// RUN: %clang_cc1 -std=c++1z -verify -Wno-unused %s
 
 struct Noncopyable {
   Noncopyable();
@@ -107,8 +107,10 @@
   sizeof(make_indestructible()); // expected-error {{deleted}}
   sizeof(make_incomplete()); // expected-error {{incomplete}}
   typeid(Indestructible{}); // expected-error {{deleted}}
-  typeid(make_indestructible()); // expected-error {{deleted}}
-  typeid(make_incomplete()); // expected-error {{incomplete}}
+  typeid(make_indestructible())

[PATCH] D77802: [analyzer] Improved RangeSet::Negate support of unsigned ranges

2020-04-17 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov marked 9 inline comments as done.
ASDenysPetrov added a comment.

@baloghadamsoftware

> However, please still extend the current tests

I've looked for some appropriate tests to extend, but haven't found. What would 
you advise to use instead of mine?
@steakhal
Thanks for the comments.




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:217
+
+  const llvm::APSInt sampleValue = getMinValue();
+  const bool isUnsigned = sampleValue.isUnsigned();

steakhal wrote:
> Should we take it as `const ref` to prevent copying?
getMinValue returns APSInt by value, so it wouldn't make sense.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:572-573
   if (const RangeSet *negV = State->get(negSym)) {
-// Unsigned range set cannot be negated, unless it is [0, 0].
-if ((negV->getConcreteValue() &&
- (*negV->getConcreteValue() == 0)) ||
+if (T->isUnsignedIntegerOrEnumerationType() ||
 T->isSignedIntegerOrEnumerationType())
   return negV;

steakhal wrote:
> Couldn't we simplify the disjunction to single `T->isEnumerationType()` or to 
> something similar?
I've looked for similar single function, but there is no appropriate one. I 
decided not to add a new one to make patch more focused.



Comment at: clang/test/Analysis/constraint_manager_negate_difference.c:114-118
+void negated_unsigned_range(unsigned x, unsigned y) {
+  clang_analyzer_eval(x - y != 0); // expected-warning{{FALSE}} 
expected-warning{{TRUE}}
+  clang_analyzer_eval(y - x != 0); // expected-warning{{FALSE}} 
expected-warning{{TRUE}}
+  clang_analyzer_eval(x - y != 0); // expected-warning{{FALSE}} 
expected-warning{{TRUE}}
+}

steakhal wrote:
> What does this test case demonstrate? Could you elaborate on that?
> Why do you evaluate the `x - y != 0` here twice?
>Why do you evaluate the x - y != 0 here twice?
This is the root line which assertion occured on.
I'll add some comments.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:23
+template  struct TestCase {
+  RangeSet original;
+  RangeSet expected;

steakhal wrote:
> According to the [LLVM coding 
> style](https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly)
>  we should use UpperCamelCase for variable names for new code.
> 
> Note that the Analyzer Core was written in a different style, we should 
> follow that there instead (at least IMO).
Here is a discussion [[ https://llvm.org/docs/Proposals/VariableNames.html | 
VariableNames]] I was guide. Seems like we can use camelBack for new code. Am I 
right? Also RangeSetTest.cpp already uses mixed naming as you can see.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:27-28
+  TestCase(BasicValueFactory &BVF, RangeSet::Factory &F,
+   const std::initializer_list &originalList,
+   const std::initializer_list &expectedList)
+  : original(createRangeSetFromList(BVF, F, originalList)),

steakhal wrote:
> AFAIK since `std::initializer_list` is just two pointers we should take it by 
> value.
I'm not sure about //should//, since initializer_list is a container and it'd 
be consistent if we handle it like any other compound object despite its 
implementation (IMO). But I can change it if you wish.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:51
+  // init block
+  DiagnosticsEngine Diag{new DiagnosticIDs, new DiagnosticOptions};
+  FileSystemOptions FileSystemOpts;

steakhal wrote:
> Generally, `new expressions` are a code smell. We should use something like 
> an `std::make_unique` to prevent memory leaks on exceptions.
> Though, I'm not sure if there is a similar function for 
> `llvm::IntrusiveRefCntPtr`s.
I'll make it more safe.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:66
+  template  void checkNegate() {
+using type = T;
+

steakhal wrote:
> To be honest, I'm not sure if `type` is more descriptive than `T`.
It is useful for debug purposes, for instance you can change it to `using type 
= int;` to verify something. It also untie from template argument list and make 
the code more flexible.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:68
+
+// use next values of the range {MIN, A, B, MID, C, D, MAX}
+

steakhal wrote:
> AFAIK full sentences are required for comments.
> https://llvm.org/docs/CodingStandards.html#commenting
I'll correct it.



Comment at: clang/unittests/StaticAnalyzer/RangeSetTest.cpp:113-120
+  // c.original.print(llvm::dbgs());
+  // llvm::dbgs() << " => ";
+  // c.expected.print(llvm::dbgs());
+  // llvm::dbgs() << " => ";
+  // negatedFromOriginal.print(llvm::dbgs());
+  // ll

[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

2020-04-17 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 258269.
fhahn marked 9 inline comments as done.
fhahn added a comment.

Update wordings as suggested, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/MatrixTypes.rst

Index: clang/docs/MatrixTypes.rst
===
--- /dev/null
+++ clang/docs/MatrixTypes.rst
@@ -0,0 +1,285 @@
+==
+Matrix Types
+==
+
+.. contents::
+   :local:
+
+.. _matrixtypes:
+
+Clang provides a C/C++ language extension that allows users to directly express
+fixed-size 2-dimensional matrices as language values and perform arithmetic on
+them.
+
+This feature is currently experimental, and both its design and its
+implementation are in flux.
+
+Draft Specification
+===
+
+Matrix Type
+---
+
+A matrix type is a scalar type with an underlying *element type*, a constant
+number of *rows*, and a constant number of *columns*. Matrix types with the same
+element type, rows, and columns are the same type. A value of a matrix type
+includes storage for ``rows * columns`` values of the *element type*. The
+internal layout, overall size and alignment are implementation-defined.
+
+The maximum of the product of the number of rows and columns is
+implementation-defined. If that implementation-defined limit is exceeded, the
+program is ill-formed.
+
+Currently, the element type of a matrix is only permitted to be one of the
+following types:
+
+* an integer type (as in C2x 6.2.5p19), but excluding enumerated types and ``_Bool``
+* the standard floating types ``float`` or ``double``
+* a half-precision floating point type, if one is supported on the target
+
+Other types may be supported in the future.
+
+Matrix Type Attribute
+-
+
+Matrix types can be declared by adding the ``matrix_type`` attribute to the
+declaration of a *typedef* (or a C++ alias declaration). The underlying type
+of the *typedef* must be a valid matrix element type. The
+attribute takes two arguments, both of which must be integer constant
+expressions that evaluate to a value greater than zero. The first specifies the
+number of rows, and the second specifies the number of columns. The underlying
+type of the *typedef* becomes a matrix type with the given dimensions and an
+element type of the former underlying type.
+
+If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
+declaration of that *typedef-name* shall have a matrix_type attribute with the
+same element type, number of rows, and number of columns.
+
+Standard Conversions
+
+
+The standard conversions are extended as follows. Note that these conversions
+are intentionally not listed as satisfying the constraints for assignment,
+which is to say, they are only permitted as explicit casts, not as implicit
+conversions.
+
+A value of matrix type can be converted to another matrix type if the number of
+rows and columns are the same and the value's elements can be converted to the
+element type of the result type. The result is a matrix where each element is
+the converted corresponding element.
+
+A value of any real type (as in C2x 6.2.5p17) can be converted to a matrix type
+if it can be converted to the element type of the matrix. The result is a
+matrix where all elements are the converted original value.
+
+If the number of rows or columns differ between the original and resulting
+type, the program is ill-formed.
+
+
+Arithmetic Conversions
+--
+
+The usual arithmetic conversions are extended as follows.
+
+Insert at the start:
+
+* If both operands are of matrix type, no arithmetic conversion is performed.
+* If one operand is of matrix type and the other operand is of a real type,
+  convert the real type operand to the matrix type
+  according to the standard conversion rules.
+
+Matrix Type Element Access Operator
+---
+
+An expression of the form ``E1 [E2] [E3]``, where ``E1`` has matrix type ``cv
+M``, is a matrix element access expression.  Let ``T`` be the element type
+of ``M``, and let ``R`` and ``C`` be the number of rows and columns in ``M``
+respectively.  The index expressions shall have integral or unscoped
+enumeration type and shall not be uses of the comma operator unless
+parenthesized.  The first index expression shall evaluate to a
+non-negative value less than ``R``, and the second index expression shall
+evaluate to a non-negative value less than ``C``, or else the expression has
+undefined behavior.  If ``E1`` is a prvalue, the result is a prvalue with type
+``T`` and is the value of the element at the given row and column in the matrix.
+Otherwise, the result is a glvalue with type ``cv T`` and with the same value
+category as ``E1`` which refers to the element at the given row 

[PATCH] D78350: [AST] Build recovery expressions by default for C++.

2020-04-17 Thread Haojian Wu via Phabricator via cfe-commits
hokein added subscribers: ebevhan, hubert.reinterpretcast.
hokein added a comment.

@ebevhan, @hubert.reinterpretcast, the patch is based on 
fd7a34186137168064ffe2ca536823559b92d939 
, it 
should contain all the fixes.
it would be nice if you can test it again in your downstream clang. Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78350



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


[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

2020-04-17 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:511
+*r = *a +  (*b * *c);
+  }
+

rjmccall wrote:
> This is kindof an unnecessarily unreadable example.  I know you haven't 
> decided on calling convention treatment yet, but maybe the leading example 
> could be just a little ahead of the implementation and just take the matrices 
> as arguments and then return the result.
I wasn't sure if that would be fine, but it indeed makes things much more 
readable. Updated.



Comment at: clang/docs/MatrixTypes.rst:29
+A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding
+enumeration types or an implementation-defined half-precision floating point
+type, otherwise the program is ill-formed.

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > fhahn wrote:
> > > > SjoerdMeijer wrote:
> > > > > Now I am wondering if this requires some explanations on binary 
> > > > > operations for these implemenation-defined types? For example, for 
> > > > > `__fp16` and matrices with this `__fp16` element type, I assume 
> > > > > arithmetic is performed in at least the (single) floating-point 
> > > > > precision. So I guess in section "Arithmetic Conversions" a rule 
> > > > > needs to be added that the conversion of these implementation defined 
> > > > > types need to performed?
> > > > > 
> > > > I don't think we need to specifically discuss the implementation 
> > > > defined types here, as the conversions and binary operator definitions 
> > > > are framed in terms of the existing rules for the element types used. I 
> > > > am potentially missing something, but with the current wording the 
> > > > conversions for `__fp16` would use the conversion rules for that type 
> > > > and the binary operators would use the arithmetic rules for it.
> > > Yeah, for the scalar conversions / scalar operands, you should just say 
> > > that the source has to be a real type and not otherwise restrict it.  All 
> > > of those types should already be convertible to any matrix element type.
> > Thanks, I've updated the wording to ensure the scalar values are of a real 
> > type in the scalar -> matrix conversion and scalar, matrix binary operator 
> > contexts. I hope that is enough to clarify things.
> This would be clearer as something like:
> 
> > Currently, the element type of a matrix is only permitted to be one of the 
> > following types:
> >
> > - an integer type (as in C2x 6.2.5p19), but excluding enumerated types and 
> > `_Bool`
> > - a standard floating type (as in C2x 6.2.5p10)
> > - a half-precision floating point type, if one is supported on the target
> >
> > Other types may be supported in the future.
> 
> Although I don't know if you actually want to unconditionally support `long 
> double`; you might just want to say "the standard floating types `float` and 
> `double`".
That's much better, thanks! I've also applied your suggestion to exclude `long 
double` for now.



Comment at: clang/docs/MatrixTypes.rst:167
+operations on matrix types match the behavior of the elementwise operations
+in the corresponding expansions provided above.
+

rjmccall wrote:
> The expansions have a lot of statement boundaries that contraction wouldn't 
> be allowed across.  I'd suggest saying something like:
> 
> > Operations on floating-point matrices have the same rounding and 
> > floating-point environment behavior as ordinary floating-point operations 
> > in the expression's context.  For the purposes of floating-point 
> > contraction, all calculations done as part of a matrix operation are 
> > considered intermediate operations, and their results need not be rounded 
> > to the format of the element type until the final result in the containing 
> > expression.  This is subject to the normal restrictions on contraction, 
> > such as `#pragma STDC FP_CONTRACT`.
Updated, thanks!



Comment at: clang/docs/MatrixTypes.rst:216
+to ``row`` and ``col`` respectively. The parameter ``columnStride`` is optional
+and if ommitted ``row`` is used as ``columnStride``.
+

rjmccall wrote:
> "omitted".
> 
> I would expect these operands to have type either `size_t` or `ptrdiff_t`.  
> Of course it only really matters for `columnStride`.
> "omitted".

Done, thanks!

> I would expect these operands to have type either size_t or ptrdiff_t. Of 
> course it only really matters for columnStride.
Yes, I update them to size_t. This should give the implementations the most 
freedom with respect to choosing the implementation defined limits of 
rows/columns. `size_t` also makes the most sense for the stride I think, as it 
is required to be >= the number of rows in the matrix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76612



___
cfe-commits

[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-17 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

balazske wrote:
> balazske wrote:
> > aaron.ballman wrote:
> > > Can you also add tests for:
> > > ```
> > > int vla_unevaluated(int x) {
> > >   // Evaluates the ++x
> > >   sizeof(int[++x]);
> > >   // Does not evaluate the ++x
> > >   _Alignof(int[++x]);
> > >   _Generic((int(*)[++x])0, default : 0);
> > >   
> > >   return x;
> > > }
> > > ```
> > > 
> > > Also, it's a bit strange to find these VLA tests in a .cpp file. VLAs are 
> > > a C++ extension and we should have some testing for them for constructs 
> > > that are C++-specific, but I would have expected many of these tests to 
> > > be in a C file instead.
> > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > does not compile? Is it worth to have a test with VLA type alias then?
> I have this output for the test above (without the new code), is it correct?
> (The `++` seems to be evaluated for the `alignof` statement too.)
> ```
> int vla_unevaluated(int x)
>  [B2 (ENTRY)]
>Succs (1): B1
> 
>  [B1]
>1: x
>2: ++[B1.1]
>3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
>4: sizeof(int [++x])
>5: x
>6: ++[B1.5]
>7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
>8: alignof(int [++x])
>9: 0
>   10: x
>   11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
>   12: return [B1.11];
>Preds (1): B2
>Succs (1): B0
> 
>  [B0 (EXIT)]
>Preds (1): B1
> 
> ```
> Could be there platforms (on buildbot?) where the VLA code (in cpp file) does 
> not compile? Is it worth to have a test with VLA type alias then?

That's unlikely; the problems with VLAs in C++ are IIRC about the bureaucracy 
of the Standard (i.e., they couldn't solve enough cornercases, like whether 
`T` and `T` the same template when `x == y` at run-time?), not 
about platform support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D78280: [Analyzer][StreamChecker] Track streams that were not found to be opened.

2020-04-17 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

I am not sure if this is the best approach: In a similar case (no opening 
function encountered) it is possible that the stream is already "escaped", 
there could be references to it from outside the analyzed function (to which it 
was passed, or got from another non-analyzed function). Maybe it is better to 
ignore such cases as it is already without this change, then we do not need to 
handle "escape" of the stream pointer specially (only remove it from the data).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78280



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


[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

2020-04-17 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

The new option will simply list the (found) functions that have a summary based 
check enabled. (The term "Loaded" may be misleading in the current 
implementation, somebody can think if it is loaded from file?) A more detailed 
output would be better (display the signature too, or maybe the whole 
summary?). For simple purpose the current way may be enough but it may be 
useful (probably for a non-checker-developer too) to see the summary details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118



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


[PATCH] D78190: Add Bfloat IR type

2020-04-17 Thread Ties Stuij via Phabricator via cfe-commits
stuij marked 2 inline comments as done.
stuij added a comment.

Marked all comments as having been addressed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78190



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


Re: [clang-tools-extra] dffa9df - [clangd] Shard preamble symbols in dynamic index

2020-04-17 Thread Mikael Holmén via cfe-commits
Hi Kadir,

I noticed in our buildbots that run with sanitizers that we got a new
complaint with this commit. It's still there on current top-of-tree now
so the fixes you pushed after this patch doesn't seem to address this
one:

==89727==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 136 byte(s) in 1 object(s) allocated from:
#0 0x5b9838 in operator new(unsigned long)
/repo/uabkaka/tmp/llvm/projects/compiler-
rt/lib/asan/asan_new_delete.cc:106
#1 0xc50879 in make_unique
/proj/flexasic/app/llvm/8.0/bin/../include/c++/v1/memory:3132:28
#2 0xc50879 in refSlab /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../../clang-tools-extra/clangd/unittests/FileIndexTests.cpp:87
#3 0xc50879 in clang::clangd::(anonymous
namespace)::FileShardedIndexTest_Sharding_Test::TestBody()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-asan/../../clang-tools-
extra/clangd/unittests/FileIndexTests.cpp:535
#4 0x1620190 in HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#5 0x1620190 in testing::Test::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2474
#6 0x1623875 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2656:11
#7 0x1624cf0 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:2774:28
#8 0x1643714 in testing::internal::UnitTestImpl::RunAllTests()
/repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4649:43
#9 0x16428c0 in
HandleExceptionsInMethodIfSupported /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc
#10 0x16428c0 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/src/gtest.cc:4257
#11 0x16048f0 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
#12 0x16048f0 in main /repo/bbiswjenk/fem023-
eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
#13 0x7f558b333544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 136 byte(s) leaked in 1 allocation(s).

/Mikael

On Wed, 2020-04-15 at 00:15 -0700, Kadir Cetinkaya via cfe-commits
wrote:
> Author: Kadir Cetinkaya
> Date: 2020-04-15T09:10:10+02:00
> New Revision: dffa9dfbda56820c02e357ad34c24ce8759b4d26
> 
> URL: 
> https://protect2.fireeye.com/v1/url?k=1ed901c9-4253d508-1ed94152-863d9bcb726f-37cce004cef08ce5&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26
> DIFF: 
> https://protect2.fireeye.com/v1/url?k=27955bfa-7b1f8f3b-27951b61-863d9bcb726f-307938d8468e38e8&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26.diff
> 
> LOG: [clangd] Shard preamble symbols in dynamic index
> 
> Summary:
> This reduces memory usage by dynamic index from more than 400MB to
> 32MB
> when all files in clang-tools-extra/clangd/*.cpp are active in
> clangd.
> 
> Reviewers: sammccall
> 
> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95,
> cfe-commits
> 
> Tags: #clang
> 
> Differential Revision: https://reviews.llvm.org/D77732
> 
> Added: 
> 
> 
> Modified: 
> clang-tools-extra/clangd/index/Background.cpp
> clang-tools-extra/clangd/index/FileIndex.cpp
> clang-tools-extra/clangd/index/FileIndex.h
> clang-tools-extra/clangd/index/SymbolCollector.cpp
> clang-tools-extra/clangd/unittests/FileIndexTests.cpp
> clang-tools-extra/clangd/unittests/TestTU.cpp
> 
> Removed: 
> 
> 
> 
> #
> ###
> diff  --git a/clang-tools-extra/clangd/index/Background.cpp b/clang-
> tools-extra/clangd/index/Background.cpp
> index 1c26dd48093e..4c5719d0526c 100644
> --- a/clang-tools-extra/clangd/index/Background.cpp
> +++ b/clang-tools-extra/clangd/index/Background.cpp
> @@ -61,51 +61,6 @@ namespace clang {
>  namespace clangd {
>  namespace {
>  
> -// Resolves URI to file paths with cache.
> -class URIToFileCache {
> -public:
> -  URIToFileCache(llvm::StringRef HintPath) : HintPath(HintPath) {}
> -
> -  llvm::StringRef resolve(llvm::StringRe

[PATCH] D78338: [clangd] Enable diagnostic fixes within macro argument expansions.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked an inline comment as done.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/Diagnostics.cpp:563
+for (auto &FixIt : FixIts) {
+  // Allow fixits within a single macro-arg expansion to be applied.
+  if (FixIt.RemoveRange.getBegin().isMacroID() &&

hokein wrote:
> I feel a bit nervous about this (even it is for macro-arg expansion only), as 
> macro is very tricky.
> 
> I think we may result in invalid code after applying the fixits in some cases:
> 
> 1) if the fix is to remove an unused variable (interestingly, clang doesn't 
> provide fixit to remove an unused variable, but for unused lambda capture, it 
> does)
> 
> ```
> #define LA(arg1, arg2) [arg1, arg2] { return arg2;}
> void test1(int x, int y) {
>   LA(x, y); // after fixit, it would become LA(, y)? or LA(y)
> }
> ```
> 
> 2) if the fix is to add some characters to the macro argument, e.g. adding a 
> dereference `*`, the semantic of the code after macro expansion maybe changed.
> 
> ```
> void f1(int &a);
> void f2(int *a) {
>f1(a); // clang will emits a diagnostic with a fixit adding preceding a 
> `*` to a.
> }
> ```
> 
> maybe we should be more conservative? just whitelist some diagnostics? fixing 
> typos seems pretty safe.
your `test1` example doesn't trigger this case because the fix has to delete a 
comma that's provided by the macro body - this patch doesn't change behavior.

To construct an example that follows this schema:
```
struct S { S(int *x); };
int *x;
S s1(*x); // fixit -> S s1(x);
#define CONCAT(a,b) a b
S s2(CONCAT(*, x)); // fixit -> S s2(CONCAT(, x));
```

The fixed code compiles fine and addresses the error in the expected way. It 
may not be *idiomatic*, but this is also a pathological case. I think it's at 
least as good to offer the fix in this case, and certainly it's not a good 
reason to drop support for others..

---

> void f1(int &a);

I can't follow this example, there are no macros?
Why would the insertion change semantics?

---

> maybe we should be more conservative? just whitelist some diagnostics? fixing 
> typos seems pretty safe.

I think this leaves a lot of value on the table - we've been conservative so 
far.
The problem with whitelists is they're incomplete and outdated (e.g. we have a 
whitelist for include fixer that's very incomplete, and I haven't managed to 
get around to fixing it, and neither has anyone else).
So I think we should use this (or a blacklist) only if we can show this 
plausibly causes real problems.

(To put this another way: by being too aggressive we'll get more feedback, by 
being more conservative we'll continue to get none)



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78338



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


[PATCH] D78359: [clangd] Do not store BaseOf relations for missing subjects

2020-04-17 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78359

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp


Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -469,7 +469,10 @@
 if (!ObjectID)
   continue;
 
-// Record the relation.
+// In a BaseOf relation we must've seen the definition/declaration of base
+// type.
+if (!Symbols.find(ID))
+  continue;
 // TODO: There may be cases where the object decl is not indexed for some
 // reason. Those cases should probably be removed in due course, but for
 // now there are two possible ways to handle it:


Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -469,7 +469,10 @@
 if (!ObjectID)
   continue;
 
-// Record the relation.
+// In a BaseOf relation we must've seen the definition/declaration of base
+// type.
+if (!Symbols.find(ID))
+  continue;
 // TODO: There may be cases where the object decl is not indexed for some
 // reason. Those cases should probably be removed in due course, but for
 // now there are two possible ways to handle it:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-17 Thread Kalle Huttunen via Phabricator via cfe-commits
khuttun marked an inline comment as done.
khuttun added a comment.

In D46317#1988261 , @lebedev.ri wrote:

> IMHO we should proceed with this patch.
>  There's been several patches recently that seem to not care about 
> false-positive rate,
>  and in this case the cost of true-positive can be humongous, as i/we've been 
> finding
>  lots of bugs exactly like this in openmp optimization pass, attributor 
> framework :/


When developing this checker I tested it on LLVM code base, and there was 
hundreds of warnings. Looking at my notes from then, the ones that I analyzed 
fell in to couple of different categories:

- The program logic is such that it's known that the key is found in the map 
(in some of these cases `count()` is asserted before the lookup)
- The code does `find()` vs.` end()` comparison before the lookup

From these the at least the first category could be considered false positives.

I also think that this checker could bring value, though. For example when 
enabled on a new project from the start. I should have time to finish it if 
reviewers feel that we should reconsider it. Also, go ahead and share if you 
have any ideas on how to make the checker more accurate.




Comment at: test/clang-tidy/bugprone-map-subscript-operator-lookup.cpp:60
+}
+
+void noWarning() {

mgehre wrote:
> We often have code like
> ```
> auto &V = Map[Idx];
> if (!V) {
>   V = init();
> }
> use(V);
> ```
> Would that be flagged by this check? Could you add a test for it (possibly 
> with `FIXME`)?
This would not be flagged, as the reference is non-const


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D46317



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


[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-17 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D46317#1988261 , @lebedev.ri wrote:

> IMHO we should proceed with this patch.
>  There's been several patches recently that seem to not care about 
> false-positive rate,


I don't think that's accurate. We still care about false-positive rates and ask 
people to report on them when we think there's going to be an issue. That's not 
to say that we shouldn't proceed with this patch.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D46317



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


[PATCH] D77938: [clangd] Extend YAML Serialization

2020-04-17 Thread Mark Nauwelaerts via Phabricator via cfe-commits
mnauw updated this revision to Diff 258292.
mnauw added a comment.

As suggested, existing (YAML) Serialization test has been extended.


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

https://reviews.llvm.org/D77938

Files:
  clang-tools-extra/clangd/index/YAMLSerialization.cpp
  clang-tools-extra/clangd/unittests/SerializationTests.cpp

Index: clang-tools-extra/clangd/unittests/SerializationTests.cpp
===
--- clang-tools-extra/clangd/unittests/SerializationTests.cpp
+++ clang-tools-extra/clangd/unittests/SerializationTests.cpp
@@ -16,6 +16,7 @@
 
 using ::testing::_;
 using ::testing::AllOf;
+using ::testing::ElementsAre;
 using ::testing::Pair;
 using ::testing::UnorderedElementsAre;
 using ::testing::UnorderedElementsAreArray;
@@ -91,6 +92,20 @@
 Object:
   ID:  6512AEC512EA3A2D
 ...
+--- !Cmd
+Directory:   'testdir'
+CommandLine:
+  - 'cmd1'
+  - 'cmd2'
+...
+--- !Source
+URI: 'file:///path/source1.cpp'
+Flags:   1
+Digest:  EED8F5EAF25C453C
+DirectIncludes:
+  - 'file:///path/inc1.h'
+  - 'file:///path/inc2.h'
+...
 )";
 
 MATCHER_P(ID, I, "") { return arg.ID == cantFail(SymbolID::fromStr(I)); }
@@ -155,6 +170,21 @@
   EXPECT_THAT(
   *ParsedYAML->Relations,
   UnorderedElementsAre(Relation{Base, RelationKind::BaseOf, Derived}));
+
+  ASSERT_TRUE(bool(ParsedYAML->Cmd));
+  auto &Cmd = *ParsedYAML->Cmd;
+  ASSERT_EQ(Cmd.Directory, "testdir");
+  EXPECT_THAT(Cmd.CommandLine, ElementsAre("cmd1", "cmd2"));
+
+  ASSERT_TRUE(bool(ParsedYAML->Sources));
+  const auto *URI = "file:///path/source1.cpp";
+  ASSERT_TRUE(ParsedYAML->Sources->count(URI));
+  auto IGNDeserialized = ParsedYAML->Sources->lookup(URI);
+  EXPECT_EQ(llvm::toHex(IGNDeserialized.Digest), "EED8F5EAF25C453C");
+  EXPECT_THAT(IGNDeserialized.DirectIncludes,
+  ElementsAre("file:///path/inc1.h", "file:///path/inc2.h"));
+  EXPECT_EQ(IGNDeserialized.URI, URI);
+  EXPECT_EQ(IGNDeserialized.Flags, IncludeGraphNode::SourceFlag(1));
 }
 
 std::vector YAMLFromSymbols(const SymbolSlab &Slab) {
Index: clang-tools-extra/clangd/index/YAMLSerialization.cpp
===
--- clang-tools-extra/clangd/index/YAMLSerialization.cpp
+++ clang-tools-extra/clangd/index/YAMLSerialization.cpp
@@ -41,6 +41,8 @@
   llvm::Optional Symbol;
   llvm::Optional Refs;
   llvm::Optional Relation;
+  llvm::Optional Source;
+  llvm::Optional Cmd;
 };
 // A class helps YAML to serialize the 32-bit encoded position (Line&Column),
 // as YAMLIO can't directly map bitfields.
@@ -49,10 +51,16 @@
   uint32_t Column;
 };
 
+// avoid ODR violation of specialization for non-owned CompileCommand
+struct CompileCommandYAML : clang::tooling::CompileCommand {};
+
 } // namespace
 namespace llvm {
 namespace yaml {
 
+using clang::clangd::FileDigest;
+using clang::clangd::IncludeGraph;
+using clang::clangd::IncludeGraphNode;
 using clang::clangd::Ref;
 using clang::clangd::RefKind;
 using clang::clangd::Relation;
@@ -65,6 +73,7 @@
 using clang::index::SymbolKind;
 using clang::index::SymbolLanguage;
 using clang::index::SymbolRole;
+using clang::tooling::CompileCommand;
 
 // Helper to (de)serialize the SymbolID. We serialize it as a hex string.
 struct NormalizedSymbolID {
@@ -308,6 +317,59 @@
   }
 };
 
+struct NormalizedSourceFlag {
+  NormalizedSourceFlag(IO &) {}
+  NormalizedSourceFlag(IO &, IncludeGraphNode::SourceFlag O) {
+Flag = static_cast(O);
+  }
+
+  IncludeGraphNode::SourceFlag denormalize(IO &) {
+return static_cast(Flag);
+  }
+
+  uint8_t Flag = 0;
+};
+
+struct NormalizedFileDigest {
+  NormalizedFileDigest(IO &) {}
+  NormalizedFileDigest(IO &, const FileDigest &Digest) {
+HexString = llvm::toHex(Digest);
+  }
+
+  FileDigest denormalize(IO &I) {
+FileDigest Digest;
+if (HexString.size() == Digest.size() * 2 &&
+llvm::all_of(HexString, llvm::isHexDigit)) {
+  memcpy(Digest.data(), llvm::fromHex(HexString).data(), Digest.size());
+} else {
+  I.setError(std::string("Bad hex file digest: ") + HexString);
+}
+return Digest;
+  }
+
+  std::string HexString;
+};
+
+template <> struct MappingTraits {
+  static void mapping(IO &IO, IncludeGraphNode &Node) {
+IO.mapRequired("URI", Node.URI);
+MappingNormalization
+NSourceFlag(IO, Node.Flags);
+IO.mapRequired("Flags", NSourceFlag->Flag);
+MappingNormalization NDigest(IO,
+   Node.Digest);
+IO.mapRequired("Digest", NDigest->HexString);
+IO.mapRequired("DirectIncludes", Node.DirectIncludes);
+  }
+};
+
+template <> struct MappingTraits {
+  static void mapping(IO &IO, CompileCommandYAML &Cmd) {
+IO.mapRequired("Directory", Cmd.Directory);
+IO.mapRequired("CommandLine", Cmd.CommandLine);
+  }
+};
+
 template <> struct MappingTraits {
   static void mapping(IO &IO, VariantEntry &Variant

[clang-tools-extra] 4503cf5 - [clangd] Drop dangling relations while sharding

2020-04-17 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2020-04-17T13:57:32+02:00
New Revision: 4503cf5f231368d6e11af724b78f1371463d86a6

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

LOG: [clangd] Drop dangling relations while sharding

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/index/FileIndex.cpp
clang-tools-extra/clangd/unittests/FileIndexTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/FileIndex.cpp 
b/clang-tools-extra/clangd/index/FileIndex.cpp
index 91914be00148..590bf46ec01c 100644
--- a/clang-tools-extra/clangd/index/FileIndex.cpp
+++ b/clang-tools-extra/clangd/index/FileIndex.cpp
@@ -174,9 +174,9 @@ FileShardedIndex::FileShardedIndex(IndexFileIn Input, 
PathRef HintPath)
   // not have been indexed, see SymbolCollector::processRelations for details.
   if (Index.Relations) {
 for (const auto &R : *Index.Relations) {
-  auto *File = SymbolIDToFile.lookup(R.Subject);
-  assert(File && "unknown subject in relation");
-  File->Relations.insert(&R);
+  // FIXME: RelationSlab shouldn't contain dangling relations.
+  if (auto *File = SymbolIDToFile.lookup(R.Subject))
+File->Relations.insert(&R);
 }
   }
   // Store only the direct includes of a file in a shard.

diff  --git a/clang-tools-extra/clangd/unittests/FileIndexTests.cpp 
b/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
index dc39ad2acf25..328892f750de 100644
--- a/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ b/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -540,6 +540,8 @@ TEST(FileShardedIndexTest, Sharding) {
 B.insert(Relation{Sym1.ID, RelationKind::BaseOf, Sym2.ID});
 // Should be stored in b.h
 B.insert(Relation{Sym2.ID, RelationKind::BaseOf, Sym1.ID});
+// Dangling relation should be dropped.
+B.insert(Relation{symbol("3").ID, RelationKind::BaseOf, Sym1.ID});
 IF.Relations = std::move(B).build();
   }
 



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


[clang-tools-extra] 66b54d5 - [clangd] Fix memory leak in FileIndexTest

2020-04-17 Thread Kadir Cetinkaya via cfe-commits

Author: Kadir Cetinkaya
Date: 2020-04-17T14:00:34+02:00
New Revision: 66b54d586fa73499714e2bfef3cedffeabb08f34

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

LOG: [clangd] Fix memory leak in FileIndexTest

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clangd/unittests/FileIndexTests.cpp 
b/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
index 328892f750de..9631c920fb27 100644
--- a/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ b/clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -532,7 +532,7 @@ TEST(FileShardedIndexTest, Sharding) {
   }
   {
 // Should be stored in b.cc
-IF.Refs = std::move(*refSlab(Sym1.ID, BSourceUri.c_str()).release());
+IF.Refs = std::move(*refSlab(Sym1.ID, BSourceUri.c_str()));
   }
   {
 RelationSlab::Builder B;



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


Re: [clang-tools-extra] dffa9df - [clangd] Shard preamble symbols in dynamic index

2020-04-17 Thread Kadir Çetinkaya via cfe-commits
Thanks Mikael,

66b54d586fa73499714e2bfef3cedffeabb08f34 should fix this.

On Fri, Apr 17, 2020 at 2:42 PM Mikael Holmén 
wrote:

> Hi Kadir,
>
> I noticed in our buildbots that run with sanitizers that we got a new
> complaint with this commit. It's still there on current top-of-tree now
> so the fixes you pushed after this patch doesn't seem to address this
> one:
>
> ==89727==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 136 byte(s) in 1 object(s) allocated from:
> #0 0x5b9838 in operator new(unsigned long)
> /repo/uabkaka/tmp/llvm/projects/compiler-
> rt/lib/asan/asan_new_delete.cc:106
> #1 0xc50879 in make_unique clang::clangd::RefSlab>
> /proj/flexasic/app/llvm/8.0/bin/../include/c++/v1/memory:3132:28
> #2 0xc50879 in refSlab /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../../clang-tools-extra/clangd/unittests/FileIndexTests.cpp:87
> #3 0xc50879 in clang::clangd::(anonymous
> namespace)::FileShardedIndexTest_Sharding_Test::TestBody()
> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
> asan/llvm/build-all-asan/../../clang-tools-
> extra/clangd/unittests/FileIndexTests.cpp:535
> #4 0x1620190 in HandleExceptionsInMethodIfSupported void> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc
> #5 0x1620190 in testing::Test::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2474
> #6 0x1623875 in testing::TestInfo::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2656:11
> #7 0x1624cf0 in testing::TestCase::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:2774:28
> #8 0x1643714 in testing::internal::UnitTestImpl::RunAllTests()
> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-sanitize-
> asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:4649:43
> #9 0x16428c0 in
> HandleExceptionsInMethodIfSupported bool> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc
> #10 0x16428c0 in testing::UnitTest::Run() /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/src/gtest.cc:4257
> #11 0x16048f0 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
> #12 0x16048f0 in main /repo/bbiswjenk/fem023-
> eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
> #13 0x7f558b333544 in __libc_start_main (/lib64/libc.so.6+0x22544)
>
> SUMMARY: AddressSanitizer: 136 byte(s) leaked in 1 allocation(s).
>
> /Mikael
>
> On Wed, 2020-04-15 at 00:15 -0700, Kadir Cetinkaya via cfe-commits
> wrote:
> > Author: Kadir Cetinkaya
> > Date: 2020-04-15T09:10:10+02:00
> > New Revision: dffa9dfbda56820c02e357ad34c24ce8759b4d26
> >
> > URL:
> >
> https://protect2.fireeye.com/v1/url?k=1ed901c9-4253d508-1ed94152-863d9bcb726f-37cce004cef08ce5&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26
> > DIFF:
> >
> https://protect2.fireeye.com/v1/url?k=27955bfa-7b1f8f3b-27951b61-863d9bcb726f-307938d8468e38e8&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26.diff
> >
> > LOG: [clangd] Shard preamble symbols in dynamic index
> >
> > Summary:
> > This reduces memory usage by dynamic index from more than 400MB to
> > 32MB
> > when all files in clang-tools-extra/clangd/*.cpp are active in
> > clangd.
> >
> > Reviewers: sammccall
> >
> > Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95,
> > cfe-commits
> >
> > Tags: #clang
> >
> > Differential Revision: https://reviews.llvm.org/D77732
> >
> > Added:
> >
> >
> > Modified:
> > clang-tools-extra/clangd/index/Background.cpp
> > clang-tools-extra/clangd/index/FileIndex.cpp
> > clang-tools-extra/clangd/index/FileIndex.h
> > clang-tools-extra/clangd/index/SymbolCollector.cpp
> > clang-tools-extra/clangd/unittests/FileIndexTests.cpp
> > clang-tools-extra/clangd/unittests/TestTU.cpp
> >
> > Removed:
> >
> >
> >
> > #
> > ###
> > diff  --git a/clang-tools-extra/clangd/index/Background.cpp b/clang-
> > tools-extra/clangd/index/Background.cpp
> > index 1c26dd48093e..4c5719d0526c 100644
> > --- a/clang-tools-extra/clangd/ind

Re: [clang-tools-extra] dffa9df - [clangd] Shard preamble symbols in dynamic index

2020-04-17 Thread Mikael Holmén via cfe-commits
On Fri, 2020-04-17 at 15:02 +0300, Kadir Çetinkaya wrote:
> Thanks Mikael,
> 
> 66b54d586fa73499714e2bfef3cedffeabb08f34 should fix this.
> 

Yep, now it runs without complaints.

Thanks!
/Mikael

> On Fri, Apr 17, 2020 at 2:42 PM Mikael Holmén <
> mikael.hol...@ericsson.com> wrote:
> > Hi Kadir,
> > 
> > I noticed in our buildbots that run with sanitizers that we got a
> > new
> > complaint with this commit. It's still there on current top-of-tree 
> > now
> > so the fixes you pushed after this patch doesn't seem to address
> > this
> > one:
> > 
> > ==89727==ERROR: LeakSanitizer: detected memory leaks
> > 
> > Direct leak of 136 byte(s) in 1 object(s) allocated from:
> > #0 0x5b9838 in operator new(unsigned long)
> > /repo/uabkaka/tmp/llvm/projects/compiler-
> > rt/lib/asan/asan_new_delete.cc:106
> > #1 0xc50879 in make_unique > clang::clangd::RefSlab>
> > /proj/flexasic/app/llvm/8.0/bin/../include/c++/v1/memory:3132:28
> > #2 0xc50879 in refSlab /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../../clang-tools-extra/clangd/unittests/FileIndexTests.cpp:87
> > #3 0xc50879 in clang::clangd::(anonymous
> > namespace)::FileShardedIndexTest_Sharding_Test::TestBody()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-asan/../../clang-tools-
> > extra/clangd/unittests/FileIndexTests.cpp:535
> > #4 0x1620190 in
> > HandleExceptionsInMethodIfSupported > void> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #5 0x1620190 in testing::Test::Run() /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2474
> > #6 0x1623875 in testing::TestInfo::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2656:11
> > #7 0x1624cf0 in testing::TestCase::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:2774:28
> > #8 0x1643714 in testing::internal::UnitTestImpl::RunAllTests()
> > /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-
> > asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4649:43
> > #9 0x16428c0 in
> > HandleExceptionsInMethodIfSupported > ,
> > bool> /repo/bbiswjenk/fem023-eiffel003/workspace/llvm/llvm-master-
> > sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc
> > #10 0x16428c0 in testing::UnitTest::Run()
> > /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/src/gtest.cc:4257
> > #11 0x16048f0 in RUN_ALL_TESTS /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/googletest/include/gtest/gtest.h:2233:46
> > #12 0x16048f0 in main /repo/bbiswjenk/fem023-
> > eiffel003/workspace/llvm/llvm-master-sanitize-asan/llvm/build-all-
> > asan/../utils/unittest/UnitTestMain/TestMain.cpp:50
> > #13 0x7f558b333544 in __libc_start_main
> > (/lib64/libc.so.6+0x22544)
> > 
> > SUMMARY: AddressSanitizer: 136 byte(s) leaked in 1 allocation(s).
> > 
> > /Mikael
> > 
> > On Wed, 2020-04-15 at 00:15 -0700, Kadir Cetinkaya via cfe-commits
> > wrote:
> > > Author: Kadir Cetinkaya
> > > Date: 2020-04-15T09:10:10+02:00
> > > New Revision: dffa9dfbda56820c02e357ad34c24ce8759b4d26
> > > 
> > > URL: 
> > > 
> > https://protect2.fireeye.com/v1/url?k=1ed901c9-4253d508-1ed94152-863d9bcb726f-37cce004cef08ce5&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26
> > > DIFF: 
> > > 
> > https://protect2.fireeye.com/v1/url?k=27955bfa-7b1f8f3b-27951b61-863d9bcb726f-307938d8468e38e8&q=1&e=d51603fa-ef7d-4c66-99fd-b868e84ed659&u=https%3A%2F%2Fgithub.com%2Fllvm%2Fllvm-project%2Fcommit%2Fdffa9dfbda56820c02e357ad34c24ce8759b4d26.diff
> > > 
> > > LOG: [clangd] Shard preamble symbols in dynamic index
> > > 
> > > Summary:
> > > This reduces memory usage by dynamic index from more than 400MB
> > to
> > > 32MB
> > > when all files in clang-tools-extra/clangd/*.cpp are active in
> > > clangd.
> > > 
> > > Reviewers: sammccall
> > > 
> > > Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman,
> > usaxena95,
> > > cfe-commits
> > > 
> > > Tags: #clang
> > > 
> > > Differential Revision: https://reviews.llvm.org/D77732
> > > 
> > > Added: 
> > > 
> > > 
> > > Modified: 
> > > clang-tools-extra/clangd/index/Background.cpp
> > > clang-tools-extra/clangd/index/FileIndex.cpp
> > > clang-tools-extra/clangd/index/FileIndex.h
> > > clang-tools-extra/clangd/index/SymbolCollector.cpp

[PATCH] D78359: [clangd] Do not store BaseOf relations for missing subjects

2020-04-17 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4503cf5f2313: [clangd] Drop dangling relations while 
sharding (authored by kadircet).

Changed prior to commit:
  https://reviews.llvm.org/D78359?vs=258287&id=258294#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78359

Files:
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp


Index: clang-tools-extra/clangd/unittests/FileIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -540,6 +540,8 @@
 B.insert(Relation{Sym1.ID, RelationKind::BaseOf, Sym2.ID});
 // Should be stored in b.h
 B.insert(Relation{Sym2.ID, RelationKind::BaseOf, Sym1.ID});
+// Dangling relation should be dropped.
+B.insert(Relation{symbol("3").ID, RelationKind::BaseOf, Sym1.ID});
 IF.Relations = std::move(B).build();
   }
 
Index: clang-tools-extra/clangd/index/FileIndex.cpp
===
--- clang-tools-extra/clangd/index/FileIndex.cpp
+++ clang-tools-extra/clangd/index/FileIndex.cpp
@@ -174,9 +174,9 @@
   // not have been indexed, see SymbolCollector::processRelations for details.
   if (Index.Relations) {
 for (const auto &R : *Index.Relations) {
-  auto *File = SymbolIDToFile.lookup(R.Subject);
-  assert(File && "unknown subject in relation");
-  File->Relations.insert(&R);
+  // FIXME: RelationSlab shouldn't contain dangling relations.
+  if (auto *File = SymbolIDToFile.lookup(R.Subject))
+File->Relations.insert(&R);
 }
   }
   // Store only the direct includes of a file in a shard.


Index: clang-tools-extra/clangd/unittests/FileIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -540,6 +540,8 @@
 B.insert(Relation{Sym1.ID, RelationKind::BaseOf, Sym2.ID});
 // Should be stored in b.h
 B.insert(Relation{Sym2.ID, RelationKind::BaseOf, Sym1.ID});
+// Dangling relation should be dropped.
+B.insert(Relation{symbol("3").ID, RelationKind::BaseOf, Sym1.ID});
 IF.Relations = std::move(B).build();
   }
 
Index: clang-tools-extra/clangd/index/FileIndex.cpp
===
--- clang-tools-extra/clangd/index/FileIndex.cpp
+++ clang-tools-extra/clangd/index/FileIndex.cpp
@@ -174,9 +174,9 @@
   // not have been indexed, see SymbolCollector::processRelations for details.
   if (Index.Relations) {
 for (const auto &R : *Index.Relations) {
-  auto *File = SymbolIDToFile.lookup(R.Subject);
-  assert(File && "unknown subject in relation");
-  File->Relations.insert(&R);
+  // FIXME: RelationSlab shouldn't contain dangling relations.
+  if (auto *File = SymbolIDToFile.lookup(R.Subject))
+File->Relations.insert(&R);
 }
   }
   // Store only the direct includes of a file in a shard.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D77809: [Analyzer] Include typedef statements in CFG build.

2020-04-17 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Analysis/cfg.cpp:570
 }
 
+// CHECK-LABEL: void vla_simple(int x)

NoQ wrote:
> balazske wrote:
> > balazske wrote:
> > > aaron.ballman wrote:
> > > > Can you also add tests for:
> > > > ```
> > > > int vla_unevaluated(int x) {
> > > >   // Evaluates the ++x
> > > >   sizeof(int[++x]);
> > > >   // Does not evaluate the ++x
> > > >   _Alignof(int[++x]);
> > > >   _Generic((int(*)[++x])0, default : 0);
> > > >   
> > > >   return x;
> > > > }
> > > > ```
> > > > 
> > > > Also, it's a bit strange to find these VLA tests in a .cpp file. VLAs 
> > > > are a C++ extension and we should have some testing for them for 
> > > > constructs that are C++-specific, but I would have expected many of 
> > > > these tests to be in a C file instead.
> > > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > > does not compile? Is it worth to have a test with VLA type alias then?
> > I have this output for the test above (without the new code), is it correct?
> > (The `++` seems to be evaluated for the `alignof` statement too.)
> > ```
> > int vla_unevaluated(int x)
> >  [B2 (ENTRY)]
> >Succs (1): B1
> > 
> >  [B1]
> >1: x
> >2: ++[B1.1]
> >3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
> >4: sizeof(int [++x])
> >5: x
> >6: ++[B1.5]
> >7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
> >8: alignof(int [++x])
> >9: 0
> >   10: x
> >   11: [B1.10] (ImplicitCastExpr, LValueToRValue, int)
> >   12: return [B1.11];
> >Preds (1): B2
> >Succs (1): B0
> > 
> >  [B0 (EXIT)]
> >Preds (1): B1
> > 
> > ```
> > Could be there platforms (on buildbot?) where the VLA code (in cpp file) 
> > does not compile? Is it worth to have a test with VLA type alias then?
> 
> That's unlikely; the problems with VLAs in C++ are IIRC about the bureaucracy 
> of the Standard (i.e., they couldn't solve enough cornercases, like whether 
> `T` and `T` the same template when `x == y` at run-time?), 
> not about platform support.
> Could be there platforms (on buildbot?) where the VLA code (in cpp file) does 
> not compile? Is it worth to have a test with VLA type alias then?

I think the type alias test is a good idea (as are any other C++-specific 
tests) because we support VLAs in C++ mode as an extension, my concern was more 
that this is a C feature and so if I was hunting for tests for VLAs, I'd look  
in a .c file first. It's not a huge concern, more like a style nit.

> (The ++ seems to be evaluated for the alignof statement too.)

That seems wrong per C17 6.5.3.4p3. It also doesn't seem to match the behavior 
I'm seeing: https://godbolt.org/z/rVaGnb



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77809



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


[PATCH] D76038: PR45000: Use Sema::SetParamDefaultArgument in TransformLambdaExpr

2020-04-17 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.

Let's have a look at an example. Do we allow this?

  template
  int x = [](T = T()){ return 0; }(args...);
  
  template int x; // Uses default argument int() = 0.
  
  struct S { S(int); };
  template int x; // Default argument not well-formed, but not needed.

Currently we don't, and neither does GCC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76038



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


[PATCH] D77802: [analyzer] Improved RangeSet::Negate support of unsigned ranges

2020-04-17 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 258300.
ASDenysPetrov added a comment.

Refined Negate function. Divided by steps for clarity.
Made some changes in comments due to guideline.


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

https://reviews.llvm.org/D77802

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constraint_manager_negate_difference.c
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp

Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -0,0 +1,141 @@
+//===- unittests/StaticAnalyzer/RangeSetTest.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/Builtins.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace ento {
+namespace {
+
+// TestCase contains to lists of ranges.
+// Original one has to be negated.
+// Expected one has to be compared to negated original range.
+template  struct TestCase {
+  RangeSet original;
+  RangeSet expected;
+
+  TestCase(BasicValueFactory &BVF, RangeSet::Factory &F,
+   const std::initializer_list &originalList,
+   const std::initializer_list &expectedList)
+  : original(createRangeSetFromList(BVF, F, originalList)),
+expected(createRangeSetFromList(BVF, F, expectedList)) {}
+
+private:
+  RangeSet createRangeSetFromList(BasicValueFactory &BVF, RangeSet::Factory &F,
+  const std::initializer_list &rangeList) {
+llvm::APSInt from(sizeof(T) * 8, std::is_unsigned::value);
+llvm::APSInt to = from;
+RangeSet rangeSet = F.getEmptySet();
+for (auto it = rangeList.begin(); it != rangeList.end(); it += 2) {
+  from = *it;
+  to = *(it + 1);
+  rangeSet = rangeSet.addRange(
+  F, RangeSet(F, BVF.getValue(from), BVF.getValue(to)));
+}
+return rangeSet;
+  }
+};
+
+class RangeSetTest : public testing::Test {
+protected:
+  // Init block
+  IntrusiveRefCntPtr Diags{new DiagnosticIDs};
+  IntrusiveRefCntPtr DiagOpts{new DiagnosticOptions};
+  DiagnosticsEngine Diag{Diags, DiagOpts};
+  FileSystemOptions FileSystemOpts;
+  FileManager FileMgr{FileSystemOpts};
+  SourceManager SM{Diag, FileMgr};
+  LangOptions LOpts;
+  IdentifierTable idents;
+  SelectorTable sels;
+  Builtin::Context builtins;
+  ASTContext context{LOpts, SM, idents, sels, builtins};
+  llvm::BumpPtrAllocator alloc;
+  BasicValueFactory BVF{context, alloc};
+  RangeSet::Factory F;
+  // End init block
+
+  template  void checkNegate() {
+using type = T;
+
+// Use next values of the range {MIN, A, B, MID, C, D, MAX}.
+
+// MID is a value in the middle of the range
+// which unary minus does not affect on,
+// e.g. int8/int32(0), uint8(128), uint32(2147483648).
+
+constexpr type MIN = std::numeric_limits::min();
+constexpr type MAX = std::numeric_limits::max();
+constexpr type MID = std::is_signed::value
+ ? 0
+ : ~(static_cast(-1) / static_cast(2));
+constexpr type A = MID - static_cast(42 + 42);
+constexpr type B = MID - static_cast(42);
+constexpr type C = -B;
+constexpr type D = -A;
+
+static_assert(MIN < A && A < B && B < MID && MID < C && C < D && D < MAX,
+  "Values shall be in an ascending order");
+
+// Left {[x, y], [x, y]} is what shall be negated.
+// Right {[x, y], [x, y]} is what shall be compared to a negation result.
+TestCase cases[] = {
+{BVF, F, {MIN, A}, {MIN, MIN, D, MAX}},
+{BVF, F, {MIN, C}, {MIN, MIN, B, MAX}},
+{BVF, F, {MIN, MID}, {MIN, MIN, MID, MAX}},
+{BVF, F, {MIN, MAX}, {MIN, MAX}},
+{BVF, F, {A, D}, {A, D}},
+{BVF, F, {A, B}, {C, D}},
+{BVF, F, {MIN, A, D, MAX}, {MIN, A, D, MAX}},
+{BVF, F, {MIN, B, MID, D}, {MIN, MIN, A, MID, C, MAX}},
+{BVF, F, {MIN, MID, C, D}, {MIN, MIN, A, B, MID, MAX}},
+{BVF, F, {MIN, MID, C, MAX}, {MIN, B, MID, MAX}},
+{BVF, F, {A, MID, D, MAX}, {MIN + 1, A, MID, D}},
+{BVF, F, {A, A}, {D, D}},
+{BVF, F, {MID, MID}, {MID, MID}},
+{BVF, F, {MAX, MAX}, {MIN + 1, MIN + 1}},
+};
+
+for (const auto &c : cases) {
+  // Negate original and check with expected.
+  RangeSet negatedFromOriginal = c.original.Negate(BVF, F);
+  EXPECT_EQ(negatedFromOriginal, c.expected);
+  // Negate negated bac

[clang] a7afb21 - [clang][AST] Support AST files larger than 512M

2020-04-17 Thread Dmitry Polukhin via cfe-commits

Author: Dmitry Polukhin
Date: 2020-04-17T06:17:33-07:00
New Revision: a7afb211dc460bd4cfb2542ad1f9b05876b57ba1

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

LOG: [clang][AST] Support AST files larger than 512M

Summary:
Clang uses 32-bit integers for storing bit offsets from the beginning of
the file that results in 512M limit on AST file. This diff replaces
absolute offsets with relative offsets from the beginning of
corresponding data structure when it is possible. And uses 64-bit
offsets for DeclOffests and TypeOffssts because these coder AST
section may easily exceeds 512M alone.

This diff breaks AST file format compatibility so VERSION_MAJOR bumped.

Test Plan:
Existing clang AST serialization tests
Tested on clangd with ~700M and ~900M preamble files
check-clang with ubsan

Reviewers: rsmith, dexonsmith

Subscribers: ilya-biryukov, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Serialization/ASTBitCodes.h
clang/include/clang/Serialization/ASTReader.h
clang/include/clang/Serialization/ASTWriter.h
clang/include/clang/Serialization/ModuleFile.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterDecl.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTBitCodes.h 
b/clang/include/clang/Serialization/ASTBitCodes.h
index 323edfbf8126..d5a27f487fa9 100644
--- a/clang/include/clang/Serialization/ASTBitCodes.h
+++ b/clang/include/clang/Serialization/ASTBitCodes.h
@@ -41,7 +41,7 @@ namespace serialization {
 /// Version 4 of AST files also requires that the version control branch 
and
 /// revision match exactly, since there is no backward compatibility of
 /// AST files at this time.
-const unsigned VERSION_MAJOR = 9;
+const unsigned VERSION_MAJOR = 10;
 
 /// AST file minor version number supported by this version of
 /// Clang.
@@ -181,7 +181,7 @@ namespace serialization {
   /// Raw source location of end of range.
   unsigned End;
 
-  /// Offset in the AST file.
+  /// Offset in the AST file relative to ModuleFile::MacroOffsetsBase.
   uint32_t BitOffset;
 
   PPEntityOffset(SourceRange R, uint32_t BitOffset)
@@ -216,17 +216,41 @@ namespace serialization {
   }
 };
 
-/// Source range/offset of a preprocessed entity.
+/// Offset in the AST file. Use splitted 64-bit integer into low/high
+/// parts to keep structure alignment 32-bit (it is important because
+/// blobs in bitstream are 32-bit aligned). This structure is serialized
+/// "as is" to the AST file.
+struct UnderalignedInt64 {
+  uint32_t BitOffsetLow = 0;
+  uint32_t BitOffsetHigh = 0;
+
+  UnderalignedInt64() = default;
+  UnderalignedInt64(uint64_t BitOffset) { setBitOffset(BitOffset); }
+
+  void setBitOffset(uint64_t Offset) {
+BitOffsetLow = Offset;
+BitOffsetHigh = Offset >> 32;
+  }
+
+  uint64_t getBitOffset() const {
+return BitOffsetLow | (uint64_t(BitOffsetHigh) << 32);
+  }
+};
+
+/// Source location and bit offset of a declaration.
 struct DeclOffset {
   /// Raw source location.
   unsigned Loc = 0;
 
-  /// Offset in the AST file.
-  uint32_t BitOffset = 0;
+  /// Offset in the AST file. Keep structure alignment 32-bit and avoid
+  /// padding gap because undefined value in the padding affects AST hash.
+  UnderalignedInt64 BitOffset;
 
   DeclOffset() = default;
-  DeclOffset(SourceLocation Loc, uint32_t BitOffset)
-: Loc(Loc.getRawEncoding()), BitOffset(BitOffset) {}
+  DeclOffset(SourceLocation Loc, uint64_t BitOffset) {
+setLocation(Loc);
+setBitOffset(BitOffset);
+  }
 
   void setLocation(SourceLocation L) {
 Loc = L.getRawEncoding();
@@ -235,6 +259,14 @@ namespace serialization {
   SourceLocation getLocation() const {
 return SourceLocation::getFromRawEncoding(Loc);
   }
+
+  void setBitOffset(uint64_t Offset) {
+BitOffset.setBitOffset(Offset);
+  }
+
+  uint64_t getBitOffset() const {
+return BitOffset.getBitOffset();
+  }
 };
 
 /// The number of predefined preprocessed entity IDs.

diff  --git a/clang/include/clang/Serialization/ASTReader.h 
b/clang/include/clang/Serialization/ASTReader.h
index 94645fff9f93..11a537fad5d5 100644
--- a/clang/include/clang/Serialization/ASTReader.h
+++ b/clang/include/clang/Serialization/ASTReader.h
@@ -723,9 +723,10 @@ class ASTReader
 
   struct PendingMacroInfo {
 ModuleFile *M;
-uint64_t MacroDirectivesOffset;
+/// Off

[PATCH] D76594: [clang][AST] Support AST files larger than 512M

2020-04-17 Thread Dmitry Polukhin via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa7afb211dc46: [clang][AST] Support AST files larger than 
512M (authored by DmitryPolukhin).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76594

Files:
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp

Index: clang/lib/Serialization/ASTWriterDecl.cpp
===
--- clang/lib/Serialization/ASTWriterDecl.cpp
+++ clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2434,12 +2434,12 @@
   SourceLocation Loc = D->getLocation();
   unsigned Index = ID - FirstDeclID;
   if (DeclOffsets.size() == Index)
-DeclOffsets.push_back(DeclOffset(Loc, Offset));
+DeclOffsets.emplace_back(Loc, Offset);
   else if (DeclOffsets.size() < Index) {
 // FIXME: Can/should this happen?
 DeclOffsets.resize(Index+1);
 DeclOffsets[Index].setLocation(Loc);
-DeclOffsets[Index].BitOffset = Offset;
+DeclOffsets[Index].setBitOffset(Offset);
   } else {
 llvm_unreachable("declarations should be emitted in ID order");
   }
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1893,6 +1893,7 @@
   // Write out the source location entry table. We skip the first
   // entry, which is always the same dummy entry.
   std::vector SLocEntryOffsets;
+  uint64_t SLocEntryOffsetsBase = Stream.GetCurrentBitNo();
   RecordData PreloadSLocs;
   SLocEntryOffsets.reserve(SourceMgr.local_sloc_entry_size() - 1);
   for (unsigned I = 1, N = SourceMgr.local_sloc_entry_size();
@@ -1903,7 +1904,9 @@
 assert(&SourceMgr.getSLocEntry(FID) == SLoc);
 
 // Record the offset of this source-location entry.
-SLocEntryOffsets.push_back(Stream.GetCurrentBitNo());
+uint64_t Offset = Stream.GetCurrentBitNo() - SLocEntryOffsetsBase;
+assert((Offset >> 32) == 0 && "SLocEntry offset too large");
+SLocEntryOffsets.push_back(Offset);
 
 // Figure out which record code to use.
 unsigned Code;
@@ -2011,12 +2014,14 @@
   Abbrev->Add(BitCodeAbbrevOp(SOURCE_LOCATION_OFFSETS));
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 16)); // # of slocs
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 16)); // total size
+  Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::VBR, 32)); // base offset
   Abbrev->Add(BitCodeAbbrevOp(BitCodeAbbrevOp::Blob)); // offsets
   unsigned SLocOffsetsAbbrev = Stream.EmitAbbrev(std::move(Abbrev));
   {
 RecordData::value_type Record[] = {
 SOURCE_LOCATION_OFFSETS, SLocEntryOffsets.size(),
-SourceMgr.getNextLocalOffset() - 1 /* skip dummy */};
+SourceMgr.getNextLocalOffset() - 1 /* skip dummy */,
+SLocEntryOffsetsBase};
 Stream.EmitRecordWithBlob(SLocOffsetsAbbrev, Record,
   bytes(SLocEntryOffsets));
   }
@@ -2093,9 +2098,11 @@
 /// Writes the block containing the serialized form of the
 /// preprocessor.
 void ASTWriter::WritePreprocessor(const Preprocessor &PP, bool IsModule) {
+  uint64_t MacroOffsetsBase = Stream.GetCurrentBitNo();
+
   PreprocessingRecord *PPRec = PP.getPreprocessingRecord();
   if (PPRec)
-WritePreprocessorDetail(*PPRec);
+WritePreprocessorDetail(*PPRec, MacroOffsetsBase);
 
   RecordData Record;
   RecordData ModuleMacroRecord;
@@ -2156,7 +2163,8 @@
   // identifier they belong to.
   for (const IdentifierInfo *Name : MacroIdentifiers) {
 MacroDirective *MD = PP.getLocalMacroDirectiveHistory(Name);
-auto StartOffset = Stream.GetCurrentBitNo();
+uint64_t StartOffset = Stream.GetCurrentBitNo() - MacroOffsetsBase;
+assert((StartOffset >> 32) == 0 && "Macro identifiers offset too large");
 
 // Emit the macro directives in reverse source order.
 for (; MD; MD = MD->getPrevious()) {
@@ -2229,14 +2237,12 @@
 
 // Record the local offset of this macro.
 unsigned Index = ID - FirstMacroID;
-if (Index == MacroOffsets.size())
-  MacroOffsets.push_back(Stream.GetCurrentBitNo());
-else {
-  if (Index > MacroOffsets.size())
-MacroOffsets.resize(Index + 1);
+if (Index >= MacroOffsets.size())
+  MacroOffsets.resize(Index + 1);
 
-  MacroOffsets[Index] = Stream.GetCurrentBitNo();
-}
+uint64_t Offset = Stream.GetCurrentBitNo() - MacroOffsetsBase;
+assert((Offset >> 32) == 0 && "Macro offset too large");
+MacroOffsets[Index] = Offset;
 
 AddIdentifierRef(Name, Record);
 AddSourceLocation(MI->getDefinitionLoc(), Record);
@@ -2287,17 +2293,20 @@
 

[PATCH] D78024: [FileCheck] - Fix the false positive when -implicit-check-not is used with an unknown -check-prefix.

2020-04-17 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny marked an inline comment as done.
jdenny added inline comments.



Comment at: llvm/lib/Support/FileCheck.cpp:1375-1377
+  // We do not allow using -implicit-check-not when an explicitly specified
+  // check prefix is not present in the input buffer.
+  if ((Req.IsDefaultCheckPrefix || FoundUsedPrefix) && !DagNotMatches.empty()) 
{

grimar wrote:
> jdenny wrote:
> > grimar wrote:
> > > jdenny wrote:
> > > > grimar wrote:
> > > > > jdenny wrote:
> > > > > > I find this logic confusing.  Its goal appears to be to constrain 
> > > > > > when `DagNotMatches` are added to `CheckStrings`.  However, the 
> > > > > > real goal is to constrain when FileCheck complains that there are 
> > > > > > no used prefixes.  Would the following logic work?
> > > > > > 
> > > > > > ```
> > > > > > if (!FoundUsedPrefix && (ImplicitNegativeChecks.empty() || 
> > > > > > !Req.IsDefaultCheckPrefix)) {
> > > > > >   errs() << "error: no check strings found with prefix"
> > > > > >   . . .
> > > > > > }
> > > > > > if (!DagNotMatches.empty()) {
> > > > > >   CheckStrings->emplace_back(
> > > > > >   . . .
> > > > > > }
> > > > > > ```
> > > > > This looks better and works, thanks!
> > > > > 
> > > > > (The code above has `DagNotMatches = ImplicitNegativeChecks;` line 
> > > > > which is also a bit confusing probably)
> > > > > This looks better and works, thanks!
> > > > 
> > > > Thanks for making that change.
> > > > 
> > > > > (The code above has DagNotMatches = ImplicitNegativeChecks; line 
> > > > > which is also a bit confusing probably)
> > > > 
> > > > I'm fine with that one.  DagNotMatches starts out as 
> > > > ImplicitNegativeChecks, and CHECK-NOTs might be added later.
> > > > 
> > > > I think the second sentence in the following comment still reflects the 
> > > > old logic:
> > > > 
> > > > ```
> > > >   // When there are no used prefixes we report an error.
> > > >   // We do not allow using -implicit-check-not when an explicitly 
> > > > specified
> > > >   // check prefix is not present in the input buffer.
> > > > ```
> > > > 
> > > > Something like the following seems better to me:
> > > > 
> > > > ```
> > > >   // When there are no used prefixes we report an error except in the 
> > > > case that
> > > >   // no prefix is specified explicitly but -implicit-check-not is 
> > > > specified.
> > > > ```
> > > > 
> > > > the real goal is to constrain when FileCheck complains that there are 
> > > > no used prefixes
> > > 
> > > btw, do you know why FileCheck seems intentionally allows the case when 
> > > `--check-prefixes=KNOWN,UNKNOWN`?
> > > I've mentioned in the description of D78110 that there are about 1000 
> > > tests that have this. but is it a feature or a something that we might 
> > > want to fix?
> > There was a long discussion about diagnostics like that over a year ago.  I 
> > believe we described that case as prefixes that are defined but not used.
> > 
> > In some of my downstream work, I often create FileCheck prefix schemes 
> > reflecting various combinations of features I want to test.  For example: 
> > FOO, BAR, FOO-AND-BAR, FOO-NOT-BAR, etc.  It's far easier to maintain those 
> > tests if I list all appropriate prefixes for each FileCheck command even if 
> > some prefixes are not currently used in the test file.  I don't know if 
> > this use case exists upstream right now.
> > 
> > Also, when developing or debugging tests involving many prefixes and many 
> > FileCheck commands, I think it could be painful to have to update all 
> > FileCheck commands every time you temporarily remove the only uses of some 
> > prefix.
> > 
> > If you pursue this diagnostic, please make it optional, even if on by 
> > default.  At one time, we discussed a warning system for such diagnostics.  
> > Warnings could be configurable via command-line options, possibly passed 
> > via the FILECHECK_OPTS env var so that it's easy to relax them during 
> > debugging or based on a test suite's specific needs.
> > 
> > @probinson and @SjoerdMeijer might want to chime in as they were also part 
> > of previous discussions.
> I see, thanks for details.
> 
> D78110 and this patch (which revealed rG09331fd7) showed that we had test 
> cases committed which
> had unknown prefixes placed by mistake and hence false positives.
> I remember how accidentally pushed on review the patch with the same issue 
> and nobody noticed..
> I just think that making FileCheck stricter could prevent such issues.
> 
> If we'll have a consensus about making `--check-prefixes` stricter I'll be 
> happy to work on this.
As long as it's optional, I think I'd be fine with that diagnostic, and I agree 
it would probably be more helpful than harmful in most cases.  Of course, 
check-all would need to be run before pushing to be sure.

Instead of the system of warning options I mentioned, we might just have 
something simple like `-allow-unused-prefix` (similar to `-allow-empty`) to 
disable it when it gets in

[PATCH] D67052: Add reference type transformation builtins

2020-04-17 Thread Michael Schellenberger Costa via Phabricator via cfe-commits
miscco added inline comments.



Comment at: clang/include/clang/Sema/DeclSpec.h:416
   static bool isTypeRep(TST T) {
-return (T == TST_typename || T == TST_typeofType ||
-T == TST_underlyingType || T == TST_atomic);
+return (TST_typename <= T <= TST_atomic);
   }

There is a bug here, this should probably be

```
return (TST_typename <= T && T <= TST_atomic);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67052



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


[PATCH] D78365: [AST] Preserve the invalid initializer for auto VarDecl.

2020-04-17 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: usaxena95, kadircet, ilya-biryukov.
Herald added a project: clang.

fixes https://github.com/clangd/clangd/issues/330


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78365

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/AST/ast-dump-expr-errors.cpp
  clang/test/AST/ast-dump-recovery.cpp


Index: clang/test/AST/ast-dump-recovery.cpp
===
--- clang/test/AST/ast-dump-recovery.cpp
+++ clang/test/AST/ast-dump-recovery.cpp
@@ -156,3 +156,22 @@
   // CHECK-NEXT: `-UnresolvedLookupExpr {{.*}} 'invalid'
   Bar b6 = Bar{invalid()};
 }
+void InitializerForAuto() {
+  // CHECK: `-VarDecl {{.*}} invalid a 'auto'
+  // CHECK-NEXT: `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   `-UnresolvedLookupExpr {{.*}} 'invalid'
+  auto a = invalid();
+
+  // CHECK: `-VarDecl {{.*}} invalid b 'auto'
+  // CHECK-NEXT: `-CallExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   |-UnresolvedLookupExpr {{.*}} 'some_func'
+  // CHECK-NEXT:   `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT: `-UnresolvedLookupExpr {{.*}} 'invalid'
+  auto b = some_func(invalid());
+
+  decltype(ned);
+  // very bad initailizer: there is an unresolved typo expr internally, we just
+  // drop it.
+  // CHECK: `-VarDecl {{.*}} invalid unresolved_typo 'auto'
+  auto unresolved_typo = gned.*[] {};
+}
\ No newline at end of file
Index: clang/test/AST/ast-dump-expr-errors.cpp
===
--- clang/test/AST/ast-dump-expr-errors.cpp
+++ clang/test/AST/ast-dump-expr-errors.cpp
@@ -40,10 +40,6 @@
 // CHECK-NEXT:| `-IntegerLiteral {{.*}} 1
 int d = static_cast(bar() + 1);
 
-// FIXME: store initializer even when 'auto' could not be deduced.
-// Expressions with errors currently do not keep initializers around.
-// CHECK: -VarDecl {{.*}} invalid e 'auto'
-auto e = bar();
 
 // Error type should result in an invalid decl.
 // CHECK: -VarDecl {{.*}} invalid f 'decltype((bar))'
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11847,10 +11847,18 @@
 // be deduced based on the chosen correction if the original init contains 
a
 // TypoExpr.
 ExprResult Res = CorrectDelayedTyposInExpr(Init, VDecl);
-if (!Res.isUsable() || Res.get()->containsErrors()) {
+if (!Res.isUsable()) {
+  // There are unresolved typos in Init. Usually it indicates the
+  // initializer is very ill-formed, just drop it.
   RealDecl->setInvalidDecl();
   return;
 }
+if (Res.get()->containsErrors()) {
+  // Invalidate the decl as we don't know the type for recovery-expr yet.
+  RealDecl->setInvalidDecl();
+  VDecl->setInit(Res.get());
+  return;
+}
 Init = Res.get();
 
 if (DeduceVariableDeclarationType(VDecl, DirectInit, Init))


Index: clang/test/AST/ast-dump-recovery.cpp
===
--- clang/test/AST/ast-dump-recovery.cpp
+++ clang/test/AST/ast-dump-recovery.cpp
@@ -156,3 +156,22 @@
   // CHECK-NEXT: `-UnresolvedLookupExpr {{.*}} 'invalid'
   Bar b6 = Bar{invalid()};
 }
+void InitializerForAuto() {
+  // CHECK: `-VarDecl {{.*}} invalid a 'auto'
+  // CHECK-NEXT: `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   `-UnresolvedLookupExpr {{.*}} 'invalid'
+  auto a = invalid();
+
+  // CHECK: `-VarDecl {{.*}} invalid b 'auto'
+  // CHECK-NEXT: `-CallExpr {{.*}} '' contains-errors
+  // CHECK-NEXT:   |-UnresolvedLookupExpr {{.*}} 'some_func'
+  // CHECK-NEXT:   `-RecoveryExpr {{.*}} '' contains-errors
+  // CHECK-NEXT: `-UnresolvedLookupExpr {{.*}} 'invalid'
+  auto b = some_func(invalid());
+
+  decltype(ned);
+  // very bad initailizer: there is an unresolved typo expr internally, we just
+  // drop it.
+  // CHECK: `-VarDecl {{.*}} invalid unresolved_typo 'auto'
+  auto unresolved_typo = gned.*[] {};
+}
\ No newline at end of file
Index: clang/test/AST/ast-dump-expr-errors.cpp
===
--- clang/test/AST/ast-dump-expr-errors.cpp
+++ clang/test/AST/ast-dump-expr-errors.cpp
@@ -40,10 +40,6 @@
 // CHECK-NEXT:| `-IntegerLiteral {{.*}} 1
 int d = static_cast(bar() + 1);
 
-// FIXME: store initializer even when 'auto' could not be deduced.
-// Expressions with errors currently do not keep initializers around.
-// CHECK: -VarDecl {{.*}} invalid e 'auto'
-auto e = bar();
 
 // Error type should result in an invalid decl.
 // CHECK: -VarDecl {{.*}} invalid f 'decltype((bar))'
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11847,10 +11847,18 @@
 // be deduced based on the chosen correc

[PATCH] D78366: [Preamble] Allow recursive inclusion of header-guarded mainfile.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, 
ilya-biryukov.
Herald added a project: clang.

This is guaranteed to be a no-op without the preamble, so should be a
no-op with it too.

Partially fixes https://github.com/clangd/clangd/issues/337
This doesn't yet work for #ifndef guards, which are not recognized in preambles.
see D78038 

I can't for the life of me work out how to test this outside clangd.
The original reentrant preamble diagnostic was untested, I added a test
to clangd for that too.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78366

Files:
  clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
  clang/lib/Lex/PPDirectives.cpp

Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -1940,19 +1940,6 @@
 return {ImportAction::None};
   }
 
-  // Check for circular inclusion of the main file.
-  // We can't generate a consistent preamble with regard to the conditional
-  // stack if the main file is included again as due to the preamble bounds
-  // some directives (e.g. #endif of a header guard) will never be seen.
-  // Since this will lead to confusing errors, avoid the inclusion.
-  if (File && PreambleConditionalStack.isRecording() &&
-  SourceMgr.translateFile(&File->getFileEntry()) ==
-  SourceMgr.getMainFileID()) {
-Diag(FilenameTok.getLocation(),
- diag::err_pp_including_mainfile_in_preamble);
-return {ImportAction::None};
-  }
-
   // Should we enter the source file? Set to Skip if either the source file is
   // known to have no effect beyond its effect on module visibility -- that is,
   // if it's got an include guard that is already defined, set to Import if it
@@ -2070,6 +2057,19 @@
 Action = (SuggestedModule && !getLangOpts().CompilingPCH) ? Import : Skip;
   }
 
+  // Check for circular inclusion of the main file.
+  // We can't generate a consistent preamble with regard to the conditional
+  // stack if the main file is included again as due to the preamble bounds
+  // some directives (e.g. #endif of a header guard) will never be seen.
+  // Since this will lead to confusing errors, avoid the inclusion.
+  if (Action == Enter && File && PreambleConditionalStack.isRecording() &&
+  SourceMgr.translateFile(&File->getFileEntry()) ==
+  SourceMgr.getMainFileID()) {
+Diag(FilenameTok.getLocation(),
+ diag::err_pp_including_mainfile_in_preamble);
+return {ImportAction::None};
+  }
+
   if (Callbacks && !IsImportDecl) {
 // Notify the callback object that we've seen an inclusion directive.
 // FIXME: Use a different callback for a pp-import?
Index: clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
===
--- clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
+++ clang-tools-extra/clangd/unittests/DiagnosticsTests.cpp
@@ -33,6 +33,7 @@
 using ::testing::Field;
 using ::testing::IsEmpty;
 using ::testing::Pair;
+using testing::SizeIs;
 using ::testing::UnorderedElementsAre;
 
 ::testing::Matcher WithFix(::testing::Matcher FixMatcher) {
@@ -378,6 +379,47 @@
   ElementsAre(Diag(Test.range(), "use of undeclared identifier 'b'")));
 }
 
+// Recursive main-file include is diagnosed, and doesn't crash.
+TEST(DiagnosticsTest, RecursivePreamble) {
+  auto TU = TestTU::withCode(R"cpp(
+#include "foo.h" // error-ok
+int symbol;
+  )cpp");
+  TU.Filename = "foo.h";
+  EXPECT_THAT(TU.build().getDiagnostics(),
+  ElementsAre(DiagName("pp_including_mainfile_in_preamble")));
+  EXPECT_THAT(TU.build().getLocalTopLevelDecls(), SizeIs(1));
+}
+
+// Recursive main-file include with #pragma once guard is OK.
+TEST(DiagnosticsTest, RecursivePreamblePragmaOnce) {
+  auto TU = TestTU::withCode(R"cpp(
+#pragma once
+#include "foo.h"
+int symbol;
+  )cpp");
+  TU.Filename = "foo.h";
+  EXPECT_THAT(TU.build().getDiagnostics(), IsEmpty());
+  EXPECT_THAT(TU.build().getLocalTopLevelDecls(), SizeIs(1));
+}
+
+// Recursive main-file include with #ifndef guard should be OK.
+// However, it's not yet recognized (incomplete at end of preamble).
+TEST(DiagnosticsTest, RecursivePreambleIfndefGuard) {
+  auto TU = TestTU::withCode(R"cpp(
+#ifndef FOO
+#define FOO
+#include "foo.h" // error-ok
+int symbol;
+#endif
+  )cpp");
+  TU.Filename = "foo.h";
+  // FIXME: should be no errors here.
+  EXPECT_THAT(TU.build().getDiagnostics(),
+  ElementsAre(DiagName("pp_including_mainfile_in_preamble")));
+  EXPECT_THAT(TU.build().getLocalTopLevelDecls(), SizeIs(1));
+}
+
 TEST(DiagnosticsTest, InsideMacros) {
   Annotations Test(R"cpp(
 #define TEN 10
___
cfe-commits mailing list
cfe-commits@lists.llvm.or

[PATCH] D77910: AMDGPU: Define cl_khr_gl_sharing as a supported extension

2020-04-17 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D77910#1981828 , @b-sumner wrote:

> In D77910#1981429 , @arsenm wrote:
>
> > In D77910#1976171 , @b-sumner 
> > wrote:
> >
> > > I don't think we can guarantee this is or will be supported on all 
> > > devices.  The language runtime makes this decision.
> >
> >
> > We don't need to worry about theoretical devices. We should know the 
> > properties of the driver from -amdhsa, -amdpal, -mesa3d
>
>
> It takes more than support in the ISA for some features.  The OpenCL driver 
> may not want to support a given optional feature, e.g. images.  I'm not 
> opposed to defaults, but if the driver chooses to not support images, it 
> needs to be able to prevent `__IMAGE_SUPPORT__` from being defined.  
> Conformance will fail if the runtime and compiler are not consistent.


The driver details should be captured by the the triple. If some weird driver 
decided to do something different, we would need to add a new triple for it. We 
don't have such a driver, so I don't see why worry about it. It's possible to 
work around with undef and redef in an implicitly included header. We need to 
fix properties of the driver based on the target to have perfectly matching 
offline compilation


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

https://reviews.llvm.org/D77910



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


[PATCH] D78365: [AST] Preserve the invalid initializer for auto VarDecl.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Oops, intended to accept this (with the comment above)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78365



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


[PATCH] D78365: [AST] Preserve the invalid initializer for auto VarDecl.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Nice!

Yet another case of "do we need to stop here" though. Do you have a doc or bug 
or somewhere to collect the different directions we could/should extend in?




Comment at: clang/lib/Sema/SemaDecl.cpp:11852
+  // There are unresolved typos in Init. Usually it indicates the
+  // initializer is very ill-formed, just drop it.
   RealDecl->setInvalidDecl();

Do you have an example to back this up? (Not to include in the comment, just 
curious).

ISTM when there are errors in the input, you can get "lucky" and they turn into 
recoveryexpr and survive here, or you get "unlucky" and they turn into typoexpr 
and are dropped here after correction fails. And lucky/unlucky might mostly 
depend on details about the type of error, not how ill-formed the code is?

This suggests two possible recovery strategies:
 - if CorrectDelayedTyposInExpr fails typo-correction, it could rebuild with 
the typos "degraded" to RecoveryExpr of some sort
 - or we could just wrap `Init` in `RecoveryExpr`, TypoExprs and all. With the 
assumption that stuff that doesn't handle TypoExpr should either treate 
RecoveryExpr as opaque or should bail out at the top-level based on 
ContainsErrors.

The former seems more precise and more general, probably more work too.

None of this needs to be addressed in this patch except maybe a FIXME and/or a 
tweak to the existing comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78365



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


[clang] b639091 - Change users of CreateShuffleVector to pass the masks as int instead of Constants

2020-04-17 Thread Benjamin Kramer via cfe-commits

Author: Benjamin Kramer
Date: 2020-04-17T16:34:29+02:00
New Revision: b639091c02df31954899c8107709597947e33364

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

LOG: Change users of CreateShuffleVector to pass the masks as int instead of 
Constants

No functionality change intended.

Added: 


Modified: 
clang/lib/CodeGen/CGExprScalar.cpp
llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index 343c62273ec4..62a0f6c0efe6 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -1780,22 +1780,18 @@ Value 
*ScalarExprEmitter::VisitArraySubscriptExpr(ArraySubscriptExpr *E) {
   return Builder.CreateExtractElement(Base, Idx, "vecext");
 }
 
-static llvm::Constant *getMaskElt(llvm::ShuffleVectorInst *SVI, unsigned Idx,
-  unsigned Off, llvm::Type *I32Ty) {
+static int getMaskElt(llvm::ShuffleVectorInst *SVI, unsigned Idx,
+  unsigned Off) {
   int MV = SVI->getMaskValue(Idx);
   if (MV == -1)
-return llvm::UndefValue::get(I32Ty);
-  return llvm::ConstantInt::get(I32Ty, Off+MV);
+return -1;
+  return Off + MV;
 }
 
-static llvm::Constant *getAsInt32(llvm::ConstantInt *C, llvm::Type *I32Ty) {
-  if (C->getBitWidth() != 32) {
-  assert(llvm::ConstantInt::isValueValidForType(I32Ty,
-C->getZExtValue()) &&
- "Index operand too large for shufflevector mask!");
-  return llvm::ConstantInt::get(I32Ty, C->getZExtValue());
-  }
-  return C;
+static int getAsInt32(llvm::ConstantInt *C, llvm::Type *I32Ty) {
+  assert(llvm::ConstantInt::isValueValidForType(I32Ty, C->getZExtValue()) &&
+ "Index operand too large for shufflevector mask!");
+  return C->getZExtValue();
 }
 
 Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) {
@@ -1832,7 +1828,7 @@ Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr 
*E) {
   for (unsigned i = 0; i != NumInitElements; ++i) {
 Expr *IE = E->getInit(i);
 Value *Init = Visit(IE);
-SmallVector Args;
+SmallVector Args;
 
 llvm::VectorType *VVT = dyn_cast(Init->getType());
 
@@ -1850,7 +1846,7 @@ Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr 
*E) {
 // insert into undef -> shuffle (src, undef)
 // shufflemask must use an i32
 Args.push_back(getAsInt32(C, CGF.Int32Ty));
-Args.resize(ResElts, llvm::UndefValue::get(CGF.Int32Ty));
+Args.resize(ResElts, -1);
 
 LHS = EI->getVectorOperand();
 RHS = V;
@@ -1859,17 +1855,16 @@ Value 
*ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) {
 // insert into undefshuffle && size match -> shuffle (v, src)
 llvm::ShuffleVectorInst *SVV = cast(V);
 for (unsigned j = 0; j != CurIdx; ++j)
-  Args.push_back(getMaskElt(SVV, j, 0, CGF.Int32Ty));
-Args.push_back(Builder.getInt32(ResElts + C->getZExtValue()));
-Args.resize(ResElts, llvm::UndefValue::get(CGF.Int32Ty));
+  Args.push_back(getMaskElt(SVV, j, 0));
+Args.push_back(ResElts + C->getZExtValue());
+Args.resize(ResElts, -1);
 
 LHS = cast(V)->getOperand(0);
 RHS = EI->getVectorOperand();
 VIsUndefShuffle = false;
   }
   if (!Args.empty()) {
-llvm::Constant *Mask = llvm::ConstantVector::get(Args);
-V = Builder.CreateShuffleVector(LHS, RHS, Mask);
+V = Builder.CreateShuffleVector(LHS, RHS, Args);
 ++CurIdx;
 continue;
   }
@@ -1898,15 +1893,14 @@ Value 
*ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) {
   // If the current vector initializer is a shuffle with undef, merge
   // this shuffle directly into it.
   if (VIsUndefShuffle) {
-Args.push_back(getMaskElt(cast(V), j, 0,
-  CGF.Int32Ty));
+Args.push_back(getMaskElt(cast(V), j, 0));
   } else {
-Args.push_back(Builder.getInt32(j));
+Args.push_back(j);
   }
 }
 for (unsigned j = 0, je = InitElts; j != je; ++j)
-  Args.push_back(getMaskElt(SVI, j, Offset, CGF.Int32Ty));
-Args.resize(ResElts, llvm::UndefValue::get(CGF.Int32Ty));
+  Args.push_back(getMaskElt(SVI, j, Offset));
+Args.resize(ResElts, -1);
 
 if (VIsUndefShuffle)
   V = cast(V)->getOperand(0);
@@ -1919,26 +1913,24 @@ Value 
*ScalarExprEmitter::Vi

[clang] f89abd6 - [SYCL] Update __builtin_unique_stable_name for other backends.

2020-04-17 Thread Erich Keane via cfe-commits

Author: Erich Keane
Date: 2020-04-17T07:54:18-07:00
New Revision: f89abd6923bcc0839288af4b96113a0cb4fa4edd

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

LOG: [SYCL] Update __builtin_unique_stable_name for other backends.

The CUDA backend (and other downstreams) have trouble with the tilde and
arrow delimiter, so replace these with 'm' (for macro) and '_'.  Since
these are in the normal lambda ID location, the format of these should
not conflict with anything else.

Added: 


Modified: 
clang/lib/AST/ItaniumMangle.cpp
clang/test/CodeGenSYCL/unique-stable-name.cpp

Removed: 




diff  --git a/clang/lib/AST/ItaniumMangle.cpp b/clang/lib/AST/ItaniumMangle.cpp
index 4a45847c9425..d60cacf07534 100644
--- a/clang/lib/AST/ItaniumMangle.cpp
+++ b/clang/lib/AST/ItaniumMangle.cpp
@@ -1795,7 +1795,7 @@ static void mangleUniqueNameLambda(CXXNameMangler 
&Mangler, SourceManager &SM,
 
   PresumedLoc PLoc = SM.getPresumedLoc(Loc);
   Mangler.mangleNumber(PLoc.getLine());
-  Out << "->";
+  Out << "_";
   Mangler.mangleNumber(PLoc.getColumn());
 
   while(Loc.isMacroID()) {
@@ -1804,9 +1804,9 @@ static void mangleUniqueNameLambda(CXXNameMangler 
&Mangler, SourceManager &SM,
   SLToPrint = SM.getImmediateExpansionRange(Loc).getBegin();
 
 PLoc = SM.getPresumedLoc(SM.getSpellingLoc(SLToPrint));
-Out << "~";
+Out << "m";
 Mangler.mangleNumber(PLoc.getLine());
-Out << "->";
+Out << "_";
 Mangler.mangleNumber(PLoc.getColumn());
 
 Loc = SM.getImmediateMacroCallerLoc(Loc);

diff  --git a/clang/test/CodeGenSYCL/unique-stable-name.cpp 
b/clang/test/CodeGenSYCL/unique-stable-name.cpp
index b54c17baec35..ca66327b0021 100644
--- a/clang/test/CodeGenSYCL/unique-stable-name.cpp
+++ b/clang/test/CodeGenSYCL/unique-stable-name.cpp
@@ -1,12 +1,12 @@
 // RUN: %clang_cc1 -triple spir64-unknown-unknown-sycldevice -fsycl 
-fsycl-is-device -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s
 // CHECK: @[[INT:[^\w]+]] = private unnamed_addr constant [[INT_SIZE:\[[0-9]+ 
x i8\]]] c"_ZTSi\00"
-// CHECK: @[[LAMBDA_X:[^\w]+]] = private unnamed_addr constant 
[[LAMBDA_X_SIZE:\[[0-9]+ x i8\]]] c"_ZTSZZ4mainENKUlvE42->5clEvEUlvE46->16\00"
-// CHECK: @[[MACRO_X:[^\w]+]] = private unnamed_addr constant 
[[MACRO_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZZ4mainENKUlvE42->5clEvEUlvE52->7~28->18\00"
-// CHECK: @[[MACRO_Y:[^\w]+]] =  private unnamed_addr constant [[MACRO_SIZE]] 
c"_ZTSZZ4mainENKUlvE42->5clEvEUlvE52->7~28->41\00"
-// CHECK: @[[MACRO_MACRO_X:[^\w]+]] = private unnamed_addr constant 
[[MACRO_MACRO_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZZ4mainENKUlvE42->5clEvEUlvE55->7~28->18~33->4\00"
-// CHECK: @[[MACRO_MACRO_Y:[^\w]+]] = private unnamed_addr constant 
[[MACRO_MACRO_SIZE]] c"_ZTSZZ4mainENKUlvE42->5clEvEUlvE55->7~28->41~33->4\00"
-// CHECK: @[[LAMBDA_IN_DEP_INT:[^\w]+]] = private unnamed_addr constant 
[[DEP_INT_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZ28lambda_in_dependent_functionIiEvvEUlvE23->12\00",
-// CHECK: @[[LAMBDA_IN_DEP_X:[^\w]+]] = private unnamed_addr constant 
[[DEP_LAMBDA_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZ28lambda_in_dependent_functionIZZ4mainENKUlvE42->5clEvEUlvE46->16EvvEUlvE23->12\00",
+// CHECK: @[[LAMBDA_X:[^\w]+]] = private unnamed_addr constant 
[[LAMBDA_X_SIZE:\[[0-9]+ x i8\]]] c"_ZTSZZ4mainENKUlvE42_5clEvEUlvE46_16\00"
+// CHECK: @[[MACRO_X:[^\w]+]] = private unnamed_addr constant 
[[MACRO_SIZE:\[[0-9]+ x i8\]]] c"_ZTSZZ4mainENKUlvE42_5clEvEUlvE52_7m28_18\00"
+// CHECK: @[[MACRO_Y:[^\w]+]] =  private unnamed_addr constant [[MACRO_SIZE]] 
c"_ZTSZZ4mainENKUlvE42_5clEvEUlvE52_7m28_41\00"
+// CHECK: @[[MACRO_MACRO_X:[^\w]+]] = private unnamed_addr constant 
[[MACRO_MACRO_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZZ4mainENKUlvE42_5clEvEUlvE55_7m28_18m33_4\00"
+// CHECK: @[[MACRO_MACRO_Y:[^\w]+]] = private unnamed_addr constant 
[[MACRO_MACRO_SIZE]] c"_ZTSZZ4mainENKUlvE42_5clEvEUlvE55_7m28_41m33_4\00"
+// CHECK: @[[LAMBDA_IN_DEP_INT:[^\w]+]] = private unnamed_addr constant 
[[DEP_INT_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZ28lambda_in_dependent_functionIiEvvEUlvE23_12\00",
+// CHECK: @[[LAMBDA_IN_DEP_X:[^\w]+]] = private unnamed_addr constant 
[[DEP_LAMBDA_SIZE:\[[0-9]+ x i8\]]] 
c"_ZTSZ28lambda_in_dependent_functionIZZ4mainENKUlvE42_5clEvEUlvE46_16EvvEUlvE23_12\00",
 
 extern "C" void printf(const char *) {}
 



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


[PATCH] D46317: [clang-tidy] New check bugprone-map-subscript-operator-lookup

2020-04-17 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: test/clang-tidy/bugprone-map-subscript-operator-lookup.cpp:48
+  int getter() const;
+  void setter(int);
+};

Besides mgehre's request for `auto&` test cases, I'd like to see some test 
cases involving these member functions. I assume that's why these lines of code 
are here (but no tests use them yet).


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D46317



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


[PATCH] D77938: [clangd] Extend YAML Serialization

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Thank you!

Do you have commit access, or would you like me to land this and D78038 
 for you?


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

https://reviews.llvm.org/D77938



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


[PATCH] D78374: [Analyzer][StreamChecker] Added evaluation of fread and fwrite.

2020-04-17 Thread Balázs Kéri via Phabricator via cfe-commits
balazske created this revision.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
gamesh411, dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
Herald added a reviewer: Szelethus.
Herald added a project: clang.

Functions fread and fwrite are now modeled with the possible
return values and stream error flags on error.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78374

Files:
  clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
  clang/test/Analysis/stream-error.c

Index: clang/test/Analysis/stream-error.c
===
--- clang/test/Analysis/stream-error.c
+++ clang/test/Analysis/stream-error.c
@@ -3,6 +3,7 @@
 #include "Inputs/system-header-simulator.h"
 
 void clang_analyzer_eval(int);
+void clang_analyzer_warnIfReached();
 void StreamTesterChecker_make_feof_stream(FILE *);
 void StreamTesterChecker_make_ferror_stream(FILE *);
 
@@ -53,6 +54,39 @@
   fclose(F);
 }
 
+void error_fread() {
+  FILE *F = tmpfile();
+  if (!F)
+return;
+  int Ret = fread(0, 1, 10, F);
+  if (Ret == 10) {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{FALSE}}
+  } else {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{TRUE}}
+if (feof(F))
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+if (ferror(F))
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  }
+  fclose(F);
+  Ret = fread(0, 1, 10, F); // expected-warning {{Stream might be already closed}}
+}
+
+void error_fwrite() {
+  FILE *F = tmpfile();
+  if (!F)
+return;
+  int Ret = fwrite(0, 1, 10, F);
+  if (Ret == 10) {
+clang_analyzer_eval(feof(F) || ferror(F)); // expected-warning {{FALSE}}
+  } else {
+clang_analyzer_eval(feof(F));   // expected-warning {{FALSE}}
+clang_analyzer_eval(ferror(F)); // expected-warning {{TRUE}}
+  }
+  fclose(F);
+  Ret = fwrite(0, 1, 10, F); // expected-warning {{Stream might be already closed}}
+}
+
 void error_fseek() {
   FILE *F = fopen("file", "r");
   if (!F)
Index: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -122,11 +122,16 @@
   FnCheck PreFn;
   FnCheck EvalFn;
   ArgNoTy StreamArgNo;
-  // What errors are possible after this operation.
-  // Used only if this operation resulted in Unknown state
-  // (otherwise there is a known single error).
-  // Must contain 2 or 3 elements, or zero.
+  // What errors are possible after the operation has failed.
   llvm::SmallVector PossibleErrors = {};
+
+  StreamState::ErrorKindTy getErrorKindAfterFailedOperation() const {
+assert(!PossibleErrors.empty() &&
+   "Function must be called on operation that can fail.");
+if (PossibleErrors.size() == 1)
+  return PossibleErrors.front();
+return StreamState::Unknown;
+  }
 };
 
 Optional
@@ -199,17 +204,31 @@
   {{"tmpfile"}, {nullptr, &StreamChecker::evalFopen, ArgNone, {}}},
   {{"fclose", 1},
{&StreamChecker::preDefault, &StreamChecker::evalFclose, 0, {}}},
-  {{"fread", 4}, {&StreamChecker::preDefault, nullptr, 3, {}}},
-  {{"fwrite", 4}, {&StreamChecker::preDefault, nullptr, 3, {}}},
+  {{"fread", 4},
+   {&StreamChecker::preDefault,
+&StreamChecker::evalFreadFwrite,
+3,
+{StreamState::FError, StreamState::FEof}}},
+  {{"fwrite", 4},
+   {&StreamChecker::preDefault,
+&StreamChecker::evalFreadFwrite,
+3,
+{StreamState::FError}}},
   {{"fseek", 3},
{&StreamChecker::preFseek,
 &StreamChecker::evalFseek,
 0,
 {StreamState::FEof, StreamState::FError, StreamState::NoError}}},
-  {{"ftell", 1}, {&StreamChecker::preDefault, nullptr, 0, {}}},
+  // Note: ftell sets errno only.
+  {{"ftell", 1},
+   {&StreamChecker::preDefault, nullptr, 0, {StreamState::NoError}}},
   {{"rewind", 1}, {&StreamChecker::preDefault, nullptr, 0, {}}},
-  {{"fgetpos", 2}, {&StreamChecker::preDefault, nullptr, 0, {}}},
-  {{"fsetpos", 2}, {&StreamChecker::preDefault, nullptr, 0, {}}},
+  // Note: fgetpos sets errno only.
+  {{"fgetpos", 2},
+   {&StreamChecker::preDefault, nullptr, 0, {StreamState::NoError}}},
+  // Note: fsetpos sets errno only.
+  {{"fsetpos", 2},
+   {&StreamChecker::preDefault, nullptr, 0, {StreamState::NoError}}},
   {{"clearerr", 1},
{&StreamChecker::preDefault, &StreamChecker::evalClearerr, 0, {}}},
   // Note: feof can result in Unknown if at the call there is a
@@ -249,17 +268,20 @@
   void evalFclose(const FnDescription *Desc, const CallEvent &Call,
   CheckerContext &C) const;
 
+  void evalFreadFwrite(const FnDescription *Desc, const CallEvent &Call,
+ 

[PATCH] D78252: [AArch64] FMLA/FMLS patterns improvement.

2020-04-17 Thread Pavel Iliin via Phabricator via cfe-commits
ilinpv updated this revision to Diff 258337.
ilinpv marked an inline comment as done.
ilinpv edited the summary of this revision.
ilinpv added a comment.

More patterns added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78252

Files:
  clang/test/CodeGen/aarch64-v8.2a-neon-intrinsics-constrained.c
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/test/CodeGen/AArch64/fp16_intrinsic_lane.ll

Index: llvm/test/CodeGen/AArch64/fp16_intrinsic_lane.ll
===
--- llvm/test/CodeGen/AArch64/fp16_intrinsic_lane.ll
+++ llvm/test/CodeGen/AArch64/fp16_intrinsic_lane.ll
@@ -14,8 +14,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $d2 killed $d2 def $q2
-; CHECK-NEXT:dup v2.4h, v2.h[0]
-; CHECK-NEXT:fmla v0.4h, v2.4h, v1.4h
+; CHECK-NEXT:fmla v0.4h, v1.4h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %lane1 = shufflevector <4 x half> %c, <4 x half> undef, <4 x i32> zeroinitializer
@@ -29,8 +28,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $d2 killed $d2 def $q2
-; CHECK-NEXT:dup v2.8h, v2.h[0]
-; CHECK-NEXT:fmla v0.8h, v2.8h, v1.8h
+; CHECK-NEXT:fmla v0.8h, v1.8h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %lane1 = shufflevector <4 x half> %c, <4 x half> undef, <8 x i32> zeroinitializer
@@ -43,8 +41,7 @@
 ; CHECK:   .Lt_vfma_laneq_f16$local:
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
-; CHECK-NEXT:dup v2.4h, v2.h[0]
-; CHECK-NEXT:fmla v0.4h, v1.4h, v2.4h
+; CHECK-NEXT:fmla v0.4h, v1.4h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %lane1 = shufflevector <8 x half> %c, <8 x half> undef, <4 x i32> zeroinitializer
@@ -57,8 +54,7 @@
 ; CHECK:   .Lt_vfmaq_laneq_f16$local:
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
-; CHECK-NEXT:dup v2.8h, v2.h[0]
-; CHECK-NEXT:fmla v0.8h, v1.8h, v2.8h
+; CHECK-NEXT:fmla v0.8h, v1.8h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %lane1 = shufflevector <8 x half> %c, <8 x half> undef, <8 x i32> zeroinitializer
@@ -72,8 +68,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $h2 killed $h2 def $q2
-; CHECK-NEXT:dup v2.4h, v2.h[0]
-; CHECK-NEXT:fmla v0.4h, v2.4h, v1.4h
+; CHECK-NEXT:fmla v0.4h, v1.4h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %vecinit = insertelement <4 x half> undef, half %c, i32 0
@@ -88,8 +83,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $h2 killed $h2 def $q2
-; CHECK-NEXT:dup v2.8h, v2.h[0]
-; CHECK-NEXT:fmla v0.8h, v2.8h, v1.8h
+; CHECK-NEXT:fmla v0.8h, v1.8h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %vecinit = insertelement <8 x half> undef, half %c, i32 0
@@ -104,7 +98,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $d2 killed $d2 def $q2
-; CHECK-NEXT:fmadd h0, h1, h2, h0
+; CHECK-NEXT:fmla h0, h1, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %extract = extractelement <4 x half> %c, i32 0
@@ -117,7 +111,7 @@
 ; CHECK:   .Lt_vfmah_laneq_f16$local:
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
-; CHECK-NEXT:fmadd h0, h1, h2, h0
+; CHECK-NEXT:fmla h0, h1, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %extract = extractelement <8 x half> %c, i32 0
@@ -131,9 +125,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $d2 killed $d2 def $q2
-; CHECK-NEXT:fneg v1.4h, v1.4h
-; CHECK-NEXT:dup v2.4h, v2.h[0]
-; CHECK-NEXT:fmla v0.4h, v2.4h, v1.4h
+; CHECK-NEXT:fmls v0.4h, v1.4h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %sub = fsub <4 x half> , %b
@@ -148,9 +140,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// kill: def $d2 killed $d2 def $q2
-; CHECK-NEXT:fneg v1.8h, v1.8h
-; CHECK-NEXT:dup v2.8h, v2.h[0]
-; CHECK-NEXT:fmla v0.8h, v2.8h, v1.8h
+; CHECK-NEXT:fmls v0.8h, v1.8h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %sub = fsub <8 x half> , %b
@@ -164,8 +154,7 @@
 ; CHECK:   .Lt_vfms_laneq_f16$local:
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
-; CHECK-NEXT:dup v2.4h, v2.h[0]
-; CHECK-NEXT:fmls v0.4h, v2.4h, v1.4h
+; CHECK-NEXT:fmls v0.4h, v1.4h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %sub = fsub <4 x half> , %b
@@ -179,8 +168,7 @@
 ; CHECK:   .Lt_vfmsq_laneq_f16$local:
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
-; CHECK-NEXT:dup v2.8h, v2.h[0]
-; CHECK-NEXT:fmls v0.8h, v2.8h, v1.8h
+; CHECK-NEXT:fmls v0.8h, v1.8h, v2.h[0]
 ; CHECK-NEXT:ret
 entry:
   %sub = fsub <8 x half> , %b
@@ -195,9 +183,7 @@
 ; CHECK-NEXT:.cfi_startproc
 ; CHECK-NEXT:  // %bb.0: // %entry
 ; CHECK-NEXT:// 

[PATCH] D78252: [AArch64] FMLA/FMLS patterns improvement.

2020-04-17 Thread Pavel Iliin via Phabricator via cfe-commits
ilinpv added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:8055
 multiclass SIMDFPIndexedTiedPatterns {
+  let Predicates = [HasNEON, HasFullFP16] in {
+  // 1 variant for the .8h version: DUPLANE from 128-bit

dmgreen wrote:
> Should we have equal patterns to those below for f32 as well? So using DUP, D 
> vector (4xf16) and possibly from a vector_extract too.
I'm worried about performance impact of change fmadd/sub -> fmla/ls in last 
pattern case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78252



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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Sterling Augustine via Phabricator via cfe-commits
saugustine added a comment.

This change breaks the lldb build with

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: 
enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
[-Werror,-Wswitch]

  switch (qual_type->getTypeClass()) {
  ^

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: 
enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
[-Werror,-Wswitch]

  switch (qual_type->getTypeClass()) {
  ^

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: 
enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
[-Werror,-Wswitch]

  switch (qual_type->getTypeClass()) {

I would fix it, but I don't know the lldb code well enough.

I am reverting this change shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967



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


[PATCH] D77910: AMDGPU: Define cl_khr_gl_sharing as a supported extension

2020-04-17 Thread Brian Sumner via Phabricator via cfe-commits
b-sumner added a comment.

In D77910#1988807 , @arsenm wrote:

> In D77910#1981828 , @b-sumner wrote:
>
> > In D77910#1981429 , @arsenm wrote:
> >
> > > In D77910#1976171 , @b-sumner 
> > > wrote:
> > >
> > > > I don't think we can guarantee this is or will be supported on all 
> > > > devices.  The language runtime makes this decision.
> > >
> > >
> > > We don't need to worry about theoretical devices. We should know the 
> > > properties of the driver from -amdhsa, -amdpal, -mesa3d
> >
> >
> > It takes more than support in the ISA for some features.  The OpenCL driver 
> > may not want to support a given optional feature, e.g. images.  I'm not 
> > opposed to defaults, but if the driver chooses to not support images, it 
> > needs to be able to prevent `__IMAGE_SUPPORT__` from being defined.  
> > Conformance will fail if the runtime and compiler are not consistent.
>
>
> The driver details should be captured by the the triple. If some weird driver 
> decided to do something different, we would need to add a new triple for it. 
> We don't have such a driver, so I don't see why worry about it. It's possible 
> to work around with undef and redef in an implicitly included header. We need 
> to fix properties of the driver based on the target to have perfectly 
> matching offline compilation


I don't see anywhere in the triple talking about driver specific details, 
unless you would use the environment?  That seems like overkill to me.  But 
again, I'm not opposed to defaults, and as long as the driver can override 
them, this should be OK.


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

https://reviews.llvm.org/D77910



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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D73967#1989145 , @saugustine wrote:

> This change breaks the lldb build with
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   ^
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   ^
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   
>
> I would fix it, but I don't know the lldb code well enough.
>
> I am reverting this change shortly.


I think I know how to fix the LLDB code, can you hold off on reverting and let 
me take a look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967



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


[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

2020-04-17 Thread Lei Huang via Phabricator via cfe-commits
lei marked an inline comment as done.
lei added inline comments.



Comment at: clang/lib/Basic/Targets/PPC.cpp:243
+  bool Passed = CheckVSXSubfeature("+power8-vector", "-mpower8-vector");
+  Passed |= CheckVSXSubfeature("+direct-move", "-mdirect-move");
+  Passed |= CheckVSXSubfeature("+float128", "-mfloat128");

jsji wrote:
> Looks like this is will cause behavior change.. And NOT NFC at all..
> 
> Before refactor, we will return false when *ANY* of the subfeature is ON.
> After refactor, we will only return false, when *ALL* of the subfeature are 
> ON, Passed will be set to true when any of subfeature are off .
> 
> Can you please double check?
You are right...  will post an update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78308



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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Sterling Augustine via Phabricator via cfe-commits
saugustine added a comment.

Reverted in a4b88c044980337bb14390be654fe76864aa60ec 
. Happy to 
approve an updated change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967



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


[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D73967#1989145 , @saugustine wrote:

> This change breaks the lldb build with
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   ^
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   ^
>
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: 
> enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch 
> [-Werror,-Wswitch]
>
>   switch (qual_type->getTypeClass()) {
>   
>
> I would fix it, but I don't know the lldb code well enough.
>
> I am reverting this change shortly.


Also, can you share the buildbot that failed here?  I'd like to keep an eye on 
it after my fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967



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


[PATCH] D78024: [FileCheck] - Fix the false positive when -implicit-check-not is used with an unknown -check-prefix.

2020-04-17 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

I'm just reading this review for the first time, and my thought was, why is 
this interacting with implicit-check-not?

I think specifying a `--check-prefix=FOO` with no uses of FOO should be 
diagnosed.  I can't say I recall the previous discussion in detail, but that's 
what I think now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78024



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


[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-17 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 258368.
saiislam marked an inline comment as done.
saiislam added a comment.

1. Moved test case to clang/test/CodeGenCXX.
2. Added a failing test case with invalid sync scope, which gets detected by 
implementation of fence instruction.
3. Updated the change description of the builtin.
4. Updated the clang documentation describing mapping of C++ memory-ordering to 
LLVM memory-ordering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75917

Files:
  clang/docs/LanguageExtensions.rst
  clang/test/CodeGenCXX/builtin-memory-fence-failure.cpp
  clang/test/CodeGenCXX/builtin-memory-fence.cpp
  clang/test/CodeGenHIP/builtin_memory_fence.cpp

Index: clang/test/CodeGenHIP/builtin_memory_fence.cpp
===
--- /dev/null
+++ clang/test/CodeGenHIP/builtin_memory_fence.cpp
@@ -1,25 +0,0 @@
-// REQUIRES: amdgpu-registered-target
-// RUN: %clang_cc1 %s -x hip -emit-llvm -O0 -o - \
-// RUN:   -triple=amdgcn-amd-amdhsa  | opt -instnamer -S | FileCheck %s
-
-void test_memory_fence_success() {
-// CHECK-LABEL: test_memory_fence_success
-
-  // CHECK: fence syncscope("workgroup") seq_cst
-  __builtin_memory_fence(__ATOMIC_SEQ_CST,  "workgroup");
-  
-   // CHECK: fence syncscope("agent") acquire
-  __builtin_memory_fence(__ATOMIC_ACQUIRE, "agent");
-
-  // CHECK: fence seq_cst
-  __builtin_memory_fence(__ATOMIC_SEQ_CST, "");
-
-  // CHECK: fence syncscope("agent") acq_rel
-  __builtin_memory_fence(4, "agent");
-
-// CHECK: fence syncscope("workgroup") release
-  __builtin_memory_fence(3, "workgroup");
-
-  // CHECK: fence syncscope("foobar") release
-  __builtin_memory_fence(3, "foobar");
-}
\ No newline at end of file
Index: clang/test/CodeGenCXX/builtin-memory-fence-failure.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/builtin-memory-fence-failure.cpp
@@ -0,0 +1,9 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: not %clang_cc1 %s -S \
+// RUN:   -triple=amdgcn-amd-amdhsa 2>&1 | FileCheck %s
+
+void test_memory_fence_failure() {
+
+  // CHECK: error: Unsupported atomic synchronization scope 
+  __builtin_memory_fence(__ATOMIC_SEQ_CST, "foobar");
+}
\ No newline at end of file
Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -2455,6 +2455,59 @@
 and ``__OPENCL_MEMORY_SCOPE_SUB_GROUP`` are provided, with values
 corresponding to the enumerators of OpenCL's ``memory_scope`` enumeration.)
 
+``__builtin_memory_fence``
+-
+
+``__builtin_memory_fence`` allows using `Fence instruction `_ 
+from clang. It takes C++11 compatible memory-ordering and target-specific
+sync-scope as arguments, and generates a fence instruction in the IR.
+
+**Syntax**:
+
+.. code-block:: c++
+
+__builtin_memory_fence(unsigned int memory_ordering, String sync_scope)
+
+**Example of use**:
+
+.. code-block:: c++
+
+  void my_fence(int i) {
+i++;
+__builtin_memory_fence(__ATOMIC_ACQUIRE,  "workgroup");
+i--;
+__builtin_memory_fence(__ATOMIC_SEQ_CST,  "agent");
+  }
+
+**Description**:
+
+The first argument of ``__builtin_memory_fence()`` builtin is one of the
+memory-ordering specifiers ``__ATOMIC_ACQUIRE``, ``__ATOMIC_RELEASE``,
+``__ATOMIC_ACQ_REL``, or ``__ATOMIC_SEQ_CST`` following C++11 memory model
+semantics. Equivalent enum values of these memory-ordering can also be 
+specified. The builtin maps these C++ memory-ordering to corresponding
+LLVM Atomic Memory Ordering for the fence instruction using LLVM Atomic C
+ABI, as given in the table below. The second argument is a target-specific
+synchronization scope defined as a String. This builtin transparently
+passes the second argument to fence instruction and relies on target
+implementation for validity check.
+
++--++
+| Input in clang   | Output in IR   |
+| (C++11 Memory-ordering)  | (LLVM Atomic Memory-ordering)  |
++==+===++===+
+| Enum | Value | Enum   | Value |
++--+---++---+
+| ``__ATOMIC_ACQUIRE`` | 2 | Acquire| 4 |
++--+---++---+
+| ``__ATOMIC_RELEASE`` | 3 | Release| 5 |
++--+---++---+
+| ``__ATOMIC_ACQ_REL`` | 4 | AcquireRelease | 6 |
++--+---++---+
+| ``__ATOMIC_SEQ_CST`` | 5 | SequentiallyConsistent | 7 |
++--+---+

[PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Already relanded here: 5f0903e9bec9 


@saugustine  I checked the buildbots, every one with LLDB in its name stayed 
green, and I cannot see the warning in any of their STDIO.  Can you point out 
how I can proactively keep an eye on this? The lldb build is broken 
out-of-the-box anyway for me due to the LLDB Python Wrapper having a syntax 
error in the SWIG bindings.

bash-4.2$ swig -copyright

SWIG Version 2.0.10
/workspaces/llvm-project/lldb/bindings/./python/python-typemaps.swig:496: 
Error: Syntax error in input(3).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967



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


[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

2020-04-17 Thread Lei Huang via Phabricator via cfe-commits
lei updated this revision to Diff 258375.
lei added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78308

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-dependent-options.cpp


Index: clang/test/Driver/ppc-dependent-options.cpp
===
--- clang/test/Driver/ppc-dependent-options.cpp
+++ clang/test/Driver/ppc-dependent-options.cpp
@@ -54,6 +54,10 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-FLT128
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
+
 #ifdef __VSX__
 static_assert(false, "VSX enabled");
 #endif
@@ -78,5 +82,7 @@
 // CHECK-NVSX-P9V: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-FLT128: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-DMV: error: option '-mdirect-move' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX: Neither enabled
 // CHECK-VSX: VSX enabled
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -228,33 +228,25 @@
 static bool ppcUserFeaturesCheck(DiagnosticsEngine &Diags,
  const std::vector &FeaturesVec) {
 
-  if (llvm::find(FeaturesVec, "-vsx") != FeaturesVec.end()) {
-if (llvm::find(FeaturesVec, "+power8-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower8-vector"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+direct-move") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mdirect-move"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+float128") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mfloat128"
- << "-mno-vsx";
-  return false;
+  // vsx was not explicitly turned off.
+  if (llvm::find(FeaturesVec, "-vsx") == FeaturesVec.end())
+return true;
+
+  auto FindVSXSubfeature = [&](StringRef Feature, StringRef Option) {
+if (llvm::find(FeaturesVec, Feature) != FeaturesVec.end()) {
+  Diags.Report(diag::err_opt_not_valid_with_opt) << Option << "-mno-vsx";
+  return true;
 }
+return false;
+  };
 
-if (llvm::find(FeaturesVec, "+power9-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower9-vector"
- << "-mno-vsx";
-  return false;
-}
-  }
+  bool Found = FindVSXSubfeature("+power8-vector", "-mpower8-vector");
+  Found |= FindVSXSubfeature("+direct-move", "-mdirect-move");
+  Found |= FindVSXSubfeature("+float128", "-mfloat128");
+  Found |= FindVSXSubfeature("+power9-vector", "-mpower9-vector");
 
-  return true;
+  // Return false if any vsx subfeatures was found.
+  return !Found;
 }
 
 bool PPCTargetInfo::initFeatureMap(


Index: clang/test/Driver/ppc-dependent-options.cpp
===
--- clang/test/Driver/ppc-dependent-options.cpp
+++ clang/test/Driver/ppc-dependent-options.cpp
@@ -54,6 +54,10 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-FLT128
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
+
 #ifdef __VSX__
 static_assert(false, "VSX enabled");
 #endif
@@ -78,5 +82,7 @@
 // CHECK-NVSX-P9V: error: option '-mpower9-vector' cannot be specified with '-mno-vsx'
 // CHECK-NVSX-FLT128: error: option '-mfloat128' cannot be specified with '-mno-vsx'
 // CHECK-NVSX-DMV: error: option '-mdirect-move' cannot be specified with '-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mfloat128' cannot be specified with '-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mpower9-vector' cannot be specified with '-mno-vsx'
 // CHECK-NVSX: Neither enabled
 // CHECK-VSX: VSX enabled
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -228,33 +228,25 @@
 static bool ppcUserFeaturesCheck(Diagnostics

[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

2020-04-17 Thread Jinsong Ji via Phabricator via cfe-commits
jsji accepted this revision.
jsji added a comment.

LGTM. Since there is an improvement for multi errors, we should remove `[NFC]` 
in title and commit messages. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78308



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


[PATCH] D78390: [dfsan] Add dataflow option to LLVM_USE_SANITIZER

2020-04-17 Thread Zola Bridges via Phabricator via cfe-commits
zbrid created this revision.
zbrid added a reviewer: morehouse.
Herald added subscribers: libcxx-commits, cfe-commits, mgorny.
Herald added projects: clang, libc++.
Herald added a reviewer: libc++.
zbrid added a reviewer: EricWF.
zbrid edited the summary of this revision.

This patch add the dataflow option to LLVM_USE_SANITIZER and documents
it.

I tested this manually by trying it out on my set up. Let me know if that's not 
sufficient.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78390

Files:
  clang/docs/DataFlowSanitizer.rst
  libcxx/CMakeLists.txt
  llvm/cmake/modules/HandleLLVMOptions.cmake
  llvm/docs/CMake.rst


Index: llvm/docs/CMake.rst
===
--- llvm/docs/CMake.rst
+++ llvm/docs/CMake.rst
@@ -422,7 +422,7 @@
 **LLVM_USE_SANITIZER**:STRING
   Define the sanitizer used to build LLVM binaries and tests. Possible values
   are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, 
``Thread``,
-  and ``Address;Undefined``. Defaults to empty string.
+  ``DataFlow``, and ``Address;Undefined``. Defaults to empty string.
 
 **LLVM_ENABLE_LTO**:STRING
   Add ``-flto`` or ``-flto=`` flags to the compile and link command
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -728,6 +728,8 @@
 elseif (LLVM_USE_SANITIZER STREQUAL "Thread")
   append_common_sanitizer_flags()
   append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow")
+  append("-fsanitize=dataflow" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
 elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR
 LLVM_USE_SANITIZER STREQUAL "Undefined;Address")
   append_common_sanitizer_flags()
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -682,6 +682,8 @@
   append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined 
-fno-sanitize=vptr,function -fno-sanitize-recover=all")
 elseif (USE_SANITIZER STREQUAL "Thread")
   append_flags(SANITIZER_FLAGS -fsanitize=thread)
+elseif (USE_SANITIZER STREQUAL "DataFlow")
+  append_flags(SANITIZER_FLAGS -fsanitize=dataflow)
 else()
   message(WARNING "Unsupported value of LLVM_USE_SANITIZER: 
${USE_SANITIZER}")
 endif()
Index: clang/docs/DataFlowSanitizer.rst
===
--- clang/docs/DataFlowSanitizer.rst
+++ clang/docs/DataFlowSanitizer.rst
@@ -20,6 +20,26 @@
 dynamic data flow analysis framework to be used by clients to help
 detect application-specific issues within their own code.
 
+How to build
+
+
+Build LLVM/Clang with `CMake `_.
+
+To build libc++ and the libc++ ABI with data flow sanitizer instrumentation:
+
+.. code-block:: console
+  cd libcxx-build
+
+  # An example using ninja
+  cmake -GNinja path/to/llvm-project/llvm \
+-DCMAKE_C_COMPILER=clang \
+-DCMAKE_CXX_COMPILER=clang++ \
+-DLLVM_USE_SANITIZER="DataFlow" \
+-DLLVM_ENABLE_LIBCXX=ON \
+-DLLVM_ENABLE_PROJECTS="libcxx;libcxxabi"
+
+  ninja cxx cxxabi
+
 Usage
 =
 


Index: llvm/docs/CMake.rst
===
--- llvm/docs/CMake.rst
+++ llvm/docs/CMake.rst
@@ -422,7 +422,7 @@
 **LLVM_USE_SANITIZER**:STRING
   Define the sanitizer used to build LLVM binaries and tests. Possible values
   are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, ``Thread``,
-  and ``Address;Undefined``. Defaults to empty string.
+  ``DataFlow``, and ``Address;Undefined``. Defaults to empty string.
 
 **LLVM_ENABLE_LTO**:STRING
   Add ``-flto`` or ``-flto=`` flags to the compile and link command
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -728,6 +728,8 @@
 elseif (LLVM_USE_SANITIZER STREQUAL "Thread")
   append_common_sanitizer_flags()
   append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow")
+  append("-fsanitize=dataflow" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
 elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR
 LLVM_USE_SANITIZER STREQUAL "Undefined;Address")
   append_common_sanitizer_flags()
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -682,6 +682,8 @@
   append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined -fno-sanitize=vptr,function -fno-sanitize-recover=all")
 elseif (USE_SANITIZER STREQUAL "Thread")
   append_flags(SANITIZER_FLAGS -fsan

Re: [PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Sterling Augustine via cfe-commits
Sorry for the trouble. I think many buildbots don't build lldb--not enough
of them anyway. I found this myself.

As I understand it, the switch-cover warning is supposed to be enabled
everywhere when built in release mode, so it looks like the lldb builders
(what few there are) aren't building in release mode. I can look into
fixing that.

On Fri, Apr 17, 2020 at 11:20 AM Erich Keane via Phabricator <
revi...@reviews.llvm.org> wrote:

> erichkeane added a comment.
>
> Already relanded here: 5f0903e9bec9 <
> https://reviews.llvm.org/rG5f0903e9bec97e67bf34d887bcbe9d05790de934>
>
> @saugustine  I checked the buildbots, every one with LLDB in its name
> stayed green, and I cannot see the warning in any of their STDIO.  Can you
> point out how I can proactively keep an eye on this? The lldb build is
> broken out-of-the-box anyway for me due to the LLDB Python Wrapper having a
> syntax error in the SWIG bindings.
>
> bash-4.2$ swig -copyright
>
> SWIG Version 2.0.10
> /workspaces/llvm-project/lldb/bindings/./python/python-typemaps.swig:496:
> Error: Syntax error in input(3).
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D73967/new/
>
> https://reviews.llvm.org/D73967
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


RE: [PATCH] D73967: Implement _ExtInt as an extended int type specifier.

2020-04-17 Thread Keane, Erich via cfe-commits
No problem, thanks for the response!

Phab emails are apparently about 30 minutes delayed for me apparently, which is 
unfortunate or I would have had the fix ready before your revert 😊

Let me know if you run into any more issues, but I’m 99% sure I got it right 
this time.

Thanks
-Erich

From: Sterling Augustine 
Sent: Friday, April 17, 2020 11:38 AM
To: reviews+d73967+public+2549cbb9adffa...@reviews.llvm.org
Cc: Keane, Erich ; aaron.ball...@gmail.com; 
m.ge...@gmx.de; Blower, Melanie I ; Mikhail Ramalho 
; arichardson@gmail.com; david.gr...@arm.com; 
bevin.hans...@ericsson.com; riccib...@gmail.com; Andrews, Elizabeth 
; samm...@gmail.com; Mikael Holmén 
; a.bat...@hotmail.com; Sidorov, Dmitry 
; sabre+phabrica...@nondot.org; 
karl-johan.karls...@ericsson.com; git...@john.mcfarlane.name; 
jfbast...@apple.com; ronan-l...@keryell.fr; Richard Smith 
; ikosa...@accesssoftek.com; rekanikol...@gmail.com; 
Alex L ; cfe-commits ; 
mlek...@skidmore.edu; blitzrak...@gmail.com; Han Shen ; 
1.in...@gmail.com
Subject: Re: [PATCH] D73967: Implement _ExtInt as an extended int type 
specifier.

Sorry for the trouble. I think many buildbots don't build lldb--not enough of 
them anyway. I found this myself.

As I understand it, the switch-cover warning is supposed to be enabled 
everywhere when built in release mode, so it looks like the lldb builders (what 
few there are) aren't building in release mode. I can look into fixing that.

On Fri, Apr 17, 2020 at 11:20 AM Erich Keane via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
erichkeane added a comment.

Already relanded here: 5f0903e9bec9 


@saugustine  I checked the buildbots, every one with LLDB in its name stayed 
green, and I cannot see the warning in any of their STDIO.  Can you point out 
how I can proactively keep an eye on this? The lldb build is broken 
out-of-the-box anyway for me due to the LLDB Python Wrapper having a syntax 
error in the SWIG bindings.

bash-4.2$ swig -copyright

SWIG Version 2.0.10
/workspaces/llvm-project/lldb/bindings/./python/python-typemaps.swig:496: 
Error: Syntax error in input(3).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73967


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


[PATCH] D78390: [dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER

2020-04-17 Thread Zola Bridges via Phabricator via cfe-commits
zbrid added a comment.

Oh I found some lit tests that fail by running `check-cxx`. I'll address that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78390



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


[PATCH] D77233: [NFC] Refactoring PropertyAttributeKind for ObjCPropertyDecl and ObjCDeclSpec.

2020-04-17 Thread Puyan Lotfi via Phabricator via cfe-commits
plotfi added a comment.

In D77233#1977671 , @erik.pilkington 
wrote:

> LGTM (after fixing those tests). Thanks for cleaning this up!


Can this be a LGTM again  @erik.pilkington @arphaman? I have managed to undo 
any unintended C API changes. Tests appear to all pass too. I had to add a 
short prefix to the enum values to avoid hitting any C++ keywords (ie class). 
Is there anything else needed for this refactor to go in?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77233



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


[PATCH] D76801: [AST] Print a> without extra spaces in C++11 or later.

2020-04-17 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added subscribers: tstellar, hans, rnk.
rnk added a comment.

We ran into three distinct issues with this change.

We updated the compiler and break some VS std::map visualizers:
https://crbug.com/1068394
I haven't 100% confirmed that this caused the issue, but looking at the code 
suggests that the names in our codeview output changed, which I would consider 
to be a regression. This should've been caught by clang's test suite. We 
already have codeview tests that try to ensure clang prints debug info names 
following MSVC's exact spacing, but apparently none broke, so this area was 
under-tested. I wonder if gdb or other DWARF consumers might be affected by 
this formatting change.

Two issues in the Chrome codebase where tests relied on the output of clang's 
diagnostics:
https://crbug.com/1064986
The compiler's diagnostic output isn't stable, so this is expected.

While I appreciate the effort towards modernization, I want to register that it 
has created work for folks, and this might come up again in six months during 
the next release. @tstellar @hans


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801



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


[PATCH] D78390: [dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER

2020-04-17 Thread Zola Bridges via Phabricator via cfe-commits
zbrid updated this revision to Diff 258383.
zbrid added a comment.
Herald added a subscriber: broadwaylamb.

Update config.py to support data flow sanitizer


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78390

Files:
  clang/docs/DataFlowSanitizer.rst
  libcxx/CMakeLists.txt
  libcxx/utils/libcxx/test/config.py
  llvm/cmake/modules/HandleLLVMOptions.cmake
  llvm/docs/CMake.rst


Index: llvm/docs/CMake.rst
===
--- llvm/docs/CMake.rst
+++ llvm/docs/CMake.rst
@@ -422,7 +422,7 @@
 **LLVM_USE_SANITIZER**:STRING
   Define the sanitizer used to build LLVM binaries and tests. Possible values
   are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, 
``Thread``,
-  and ``Address;Undefined``. Defaults to empty string.
+  ``DataFlow``, and ``Address;Undefined``. Defaults to empty string.
 
 **LLVM_ENABLE_LTO**:STRING
   Add ``-flto`` or ``-flto=`` flags to the compile and link command
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -728,6 +728,8 @@
 elseif (LLVM_USE_SANITIZER STREQUAL "Thread")
   append_common_sanitizer_flags()
   append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow")
+  append("-fsanitize=dataflow" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
 elseif (LLVM_USE_SANITIZER STREQUAL "Address;Undefined" OR
 LLVM_USE_SANITIZER STREQUAL "Undefined;Address")
   append_common_sanitizer_flags()
Index: libcxx/utils/libcxx/test/config.py
===
--- libcxx/utils/libcxx/test/config.py
+++ libcxx/utils/libcxx/test/config.py
@@ -909,6 +909,10 @@
 self.cxx.flags += ['-fsanitize=thread']
 self.config.available_features.add('tsan')
 self.config.available_features.add('sanitizer-new-delete')
+elif san == 'DataFlow':
+self.cxx.flags += ['-fsanitize=dataflow']
+self.config.available_features.add('dfsan')
+self.config.available_features.add('sanitizer-new-delete')
 else:
 self.lit_config.fatal('unsupported value for '
   'use_sanitizer: {0}'.format(san))
Index: libcxx/CMakeLists.txt
===
--- libcxx/CMakeLists.txt
+++ libcxx/CMakeLists.txt
@@ -682,6 +682,8 @@
   append_flags(SANITIZER_FLAGS "-fsanitize=address,undefined 
-fno-sanitize=vptr,function -fno-sanitize-recover=all")
 elseif (USE_SANITIZER STREQUAL "Thread")
   append_flags(SANITIZER_FLAGS -fsanitize=thread)
+elseif (USE_SANITIZER STREQUAL "DataFlow")
+  append_flags(SANITIZER_FLAGS -fsanitize=dataflow)
 else()
   message(WARNING "Unsupported value of LLVM_USE_SANITIZER: 
${USE_SANITIZER}")
 endif()
Index: clang/docs/DataFlowSanitizer.rst
===
--- clang/docs/DataFlowSanitizer.rst
+++ clang/docs/DataFlowSanitizer.rst
@@ -20,6 +20,26 @@
 dynamic data flow analysis framework to be used by clients to help
 detect application-specific issues within their own code.
 
+How to build
+
+
+Build LLVM/Clang with `CMake `_.
+
+To build libc++ and the libc++ ABI with data flow sanitizer instrumentation:
+
+.. code-block:: console
+  cd libcxx-build
+
+  # An example using ninja
+  cmake -GNinja path/to/llvm-project/llvm \
+-DCMAKE_C_COMPILER=clang \
+-DCMAKE_CXX_COMPILER=clang++ \
+-DLLVM_USE_SANITIZER="DataFlow" \
+-DLLVM_ENABLE_LIBCXX=ON \
+-DLLVM_ENABLE_PROJECTS="libcxx;libcxxabi"
+
+  ninja cxx cxxabi
+
 Usage
 =
 


Index: llvm/docs/CMake.rst
===
--- llvm/docs/CMake.rst
+++ llvm/docs/CMake.rst
@@ -422,7 +422,7 @@
 **LLVM_USE_SANITIZER**:STRING
   Define the sanitizer used to build LLVM binaries and tests. Possible values
   are ``Address``, ``Memory``, ``MemoryWithOrigins``, ``Undefined``, ``Thread``,
-  and ``Address;Undefined``. Defaults to empty string.
+  ``DataFlow``, and ``Address;Undefined``. Defaults to empty string.
 
 **LLVM_ENABLE_LTO**:STRING
   Add ``-flto`` or ``-flto=`` flags to the compile and link command
Index: llvm/cmake/modules/HandleLLVMOptions.cmake
===
--- llvm/cmake/modules/HandleLLVMOptions.cmake
+++ llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -728,6 +728,8 @@
 elseif (LLVM_USE_SANITIZER STREQUAL "Thread")
   append_common_sanitizer_flags()
   append("-fsanitize=thread" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
+elseif (LLVM_USE_SANITIZER STREQUAL "DataFlow")
+ 

[PATCH] D77278: Remove asserting getters from base Type

2020-04-17 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau updated this revision to Diff 258393.
ctetreau added a comment.

fix permissions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77278

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -4263,7 +4263,7 @@
 
 Base = SDB->getValue(C);
 
-unsigned NumElts = Ptr->getType()->getVectorNumElements();
+unsigned NumElts = cast(Ptr->getType())->getNumElements();
 EVT VT = EVT::getVectorVT(*DAG.getContext(), TLI.getPointerTy(DL), NumElts);
 Index = DAG.getConstant(0, SDB->getCurSDLoc(), VT);
 IndexType = ISD::SIGNED_SCALED;
Index: llvm/lib/CodeGen/CodeGenPrepare.cpp
===
--- llvm/lib/CodeGen/CodeGenPrepare.cpp
+++ llvm/lib/CodeGen/CodeGenPrepare.cpp
@@ -5262,7 +5262,7 @@
   if (!RewriteGEP && Ops.size() == 2)
 return false;
 
-  unsigned NumElts = Ptr->getType()->getVectorNumElements();
+  unsigned NumElts = cast(Ptr->getType())->getNumElements();
 
   IRBuilder<> Builder(MemoryInst);
 
Index: llvm/include/llvm/IR/Type.h
===
--- llvm/include/llvm/IR/Type.h
+++ llvm/include/llvm/IR/Type.h
@@ -300,11 +300,7 @@
 
   /// If this is a vector type, return the element type, otherwise return
   /// 'this'.
-  Type *getScalarType() const {
-if (isVectorTy())
-  return getVectorElementType();
-return const_cast(this);
-  }
+  inline Type *getScalarType() const;
 
   //======//
   // Type Iteration support.
@@ -339,8 +335,8 @@
 
   //======//
   // Helper methods corresponding to subclass methods.  This forces a cast to
-  // the specified subclass and calls its accessor.  "getVectorNumElements" (for
-  // example) is shorthand for cast(Ty)->getNumElements().  This is
+  // the specified subclass and calls its accessor.  "getArrayNumElements" (for
+  // example) is shorthand for cast(Ty)->getNumElements().  This is
   // only intended to cover the core methods that are frequently used, helper
   // methods should not be added here.
 
@@ -361,14 +357,6 @@
 return ContainedTys[0];
   }
 
-  inline bool getVectorIsScalable() const;
-  inline unsigned getVectorNumElements() const;
-  inline ElementCount getVectorElementCount() const;
-  Type *getVectorElementType() const {
-assert(getTypeID() == VectorTyID);
-return ContainedTys[0];
-  }
-
   Type *getPointerElementType() const {
 assert(getTypeID() == PointerTyID);
 return ContainedTys[0];
Index: llvm/include/llvm/IR/DerivedTypes.h
===
--- llvm/include/llvm/IR/DerivedTypes.h
+++ llvm/include/llvm/IR/DerivedTypes.h
@@ -531,18 +531,6 @@
   }
 };
 
-unsigned Type::getVectorNumElements() const {
-  return cast(this)->getNumElements();
-}
-
-bool Type::getVectorIsScalable() const {
-  return cast(this)->isScalable();
-}
-
-ElementCount Type::getVectorElementCount() const {
-  return cast(this)->getElementCount();
-}
-
 bool Type::isVectorTy() const { return isa(this); }
 
 /// Class to represent pointers.
@@ -597,8 +585,8 @@
   isIntOrIntVectorTy() &&
   "Original type expected to be a vector of integers or a scalar integer.");
   Type *NewType = getIntNTy(getContext(), NewBitWidth);
-  if (isVectorTy())
-NewType = VectorType::get(NewType, getVectorElementCount());
+  if (auto *VTy = dyn_cast(this))
+NewType = VectorType::get(NewType, VTy->getElementCount());
   return NewType;
 }
 
@@ -606,6 +594,12 @@
   return cast(getScalarType())->getAddressSpace();
 }
 
+Type *Type::getScalarType() const {
+  if (isVectorTy())
+return cast(this)->getElementType();
+  return const_cast(this);
+}
+
 } // end namespace llvm
 
 #endif // LLVM_IR_DERIVEDTYPES_H
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -7573,8 +7573,7 @@
   // The vector type that is stored may be different from the
   // eventual type stored to memory.
   auto VectorTy = cast(Ops.back()->getType());
-  auto MemoryTy =
-  llvm::VectorType::get(MemEltTy, VectorTy->getVectorElementCount());
+  auto MemoryTy = llvm::VectorType::get(MemEltTy, VectorTy->getElementCount());
 
   Value *Predicate = EmitSVEPredicateCast(Ops[0], MemoryTy);
   Value *BasePtr = Builder.CreateBitCast(Ops[1], MemoryTy->getPointerTo());
_

[PATCH] D78392: [CUDA] Define __CUDACC__ before standard library headers

2020-04-17 Thread Raul Tambre via Phabricator via cfe-commits
tambre created this revision.
tambre added a reviewer: tra.
Herald added subscribers: cfe-commits, yaxunl.
Herald added a project: clang.
tambre edited the summary of this revision.
tambre edited the summary of this revision.
tra added inline comments.



Comment at: clang/lib/Headers/__clang_cuda_runtime_wrapper.h:44
 #include 
 
 // Preserve common macros that will be changed below by us or by CUDA

We should undef __CUDACC__ here to make sure it does not affect anything else 
in the headers we include further down.


libstdc++ since version 7 when GNU extensions are enabled (e.g. -std=gnu++11) 
use it to avoid defining overloads using `__float128`.
This fixes compiling with GNU extensions failing due to `__float128` being used.

Discovered at 
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4442#note_737136.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78392

Files:
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,6 +31,11 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,6 +31,11 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D78392: [CUDA] Define __CUDACC__ before standard library headers

2020-04-17 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Headers/__clang_cuda_runtime_wrapper.h:44
 #include 
 
 // Preserve common macros that will be changed below by us or by CUDA

We should undef __CUDACC__ here to make sure it does not affect anything else 
in the headers we include further down.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78392



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


[PATCH] D77278: Remove asserting getters from base Type

2020-04-17 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau updated this revision to Diff 258392.
ctetreau added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

catch stragglers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77278

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -4263,7 +4263,7 @@
 
 Base = SDB->getValue(C);
 
-unsigned NumElts = Ptr->getType()->getVectorNumElements();
+unsigned NumElts = cast(Ptr->getType())->getNumElements();
 EVT VT = EVT::getVectorVT(*DAG.getContext(), TLI.getPointerTy(DL), NumElts);
 Index = DAG.getConstant(0, SDB->getCurSDLoc(), VT);
 IndexType = ISD::SIGNED_SCALED;
Index: llvm/lib/CodeGen/CodeGenPrepare.cpp
===
--- llvm/lib/CodeGen/CodeGenPrepare.cpp
+++ llvm/lib/CodeGen/CodeGenPrepare.cpp
@@ -5262,7 +5262,7 @@
   if (!RewriteGEP && Ops.size() == 2)
 return false;
 
-  unsigned NumElts = Ptr->getType()->getVectorNumElements();
+  unsigned NumElts = cast(Ptr->getType())->getNumElements();
 
   IRBuilder<> Builder(MemoryInst);
 
Index: llvm/include/llvm/IR/Type.h
===
--- llvm/include/llvm/IR/Type.h
+++ llvm/include/llvm/IR/Type.h
@@ -300,11 +300,7 @@
 
   /// If this is a vector type, return the element type, otherwise return
   /// 'this'.
-  Type *getScalarType() const {
-if (isVectorTy())
-  return getVectorElementType();
-return const_cast(this);
-  }
+  inline Type *getScalarType() const;
 
   //======//
   // Type Iteration support.
@@ -339,8 +335,8 @@
 
   //======//
   // Helper methods corresponding to subclass methods.  This forces a cast to
-  // the specified subclass and calls its accessor.  "getVectorNumElements" (for
-  // example) is shorthand for cast(Ty)->getNumElements().  This is
+  // the specified subclass and calls its accessor.  "getArrayNumElements" (for
+  // example) is shorthand for cast(Ty)->getNumElements().  This is
   // only intended to cover the core methods that are frequently used, helper
   // methods should not be added here.
 
@@ -361,14 +357,6 @@
 return ContainedTys[0];
   }
 
-  inline bool getVectorIsScalable() const;
-  inline unsigned getVectorNumElements() const;
-  inline ElementCount getVectorElementCount() const;
-  Type *getVectorElementType() const {
-assert(getTypeID() == VectorTyID);
-return ContainedTys[0];
-  }
-
   Type *getPointerElementType() const {
 assert(getTypeID() == PointerTyID);
 return ContainedTys[0];
Index: llvm/include/llvm/IR/DerivedTypes.h
===
--- llvm/include/llvm/IR/DerivedTypes.h
+++ llvm/include/llvm/IR/DerivedTypes.h
@@ -531,18 +531,6 @@
   }
 };
 
-unsigned Type::getVectorNumElements() const {
-  return cast(this)->getNumElements();
-}
-
-bool Type::getVectorIsScalable() const {
-  return cast(this)->isScalable();
-}
-
-ElementCount Type::getVectorElementCount() const {
-  return cast(this)->getElementCount();
-}
-
 bool Type::isVectorTy() const { return isa(this); }
 
 /// Class to represent pointers.
@@ -597,8 +585,8 @@
   isIntOrIntVectorTy() &&
   "Original type expected to be a vector of integers or a scalar integer.");
   Type *NewType = getIntNTy(getContext(), NewBitWidth);
-  if (isVectorTy())
-NewType = VectorType::get(NewType, getVectorElementCount());
+  if (auto *VTy = dyn_cast(this))
+NewType = VectorType::get(NewType, VTy->getElementCount());
   return NewType;
 }
 
@@ -606,6 +594,12 @@
   return cast(getScalarType())->getAddressSpace();
 }
 
+Type *Type::getScalarType() const {
+  if (isVectorTy())
+return cast(this)->getElementType();
+  return const_cast(this);
+}
+
 } // end namespace llvm
 
 #endif // LLVM_IR_DERIVEDTYPES_H
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -7573,8 +7573,7 @@
   // The vector type that is stored may be different from the
   // eventual type stored to memory.
   auto VectorTy = cast(Ops.back()->getType());
-  auto MemoryTy =
-  llvm::VectorType::get(MemEltTy, VectorTy->getVectorElementCount());
+  auto MemoryTy = llvm::VectorType::get(MemEltTy, VectorTy->getElementCount());
 
   Value *Predicate = EmitSVEPredicateCast(Ops[0], MemoryTy);
   Val

[PATCH] D78390: [dfsan] Add "DataFlow" option to LLVM_USE_SANITIZER

2020-04-17 Thread Matt Morehouse via Phabricator via cfe-commits
morehouse added inline comments.



Comment at: clang/docs/DataFlowSanitizer.rst:24
+How to build
+
+

Let's add some explanation here about why we want to build libc++ with dfsan.



Comment at: clang/docs/DataFlowSanitizer.rst:26
+
+Build LLVM/Clang with `CMake `_.
+

This sentence doesn't seem too helpful.  I think most people reading this doc 
will know how to build LLVM/Clang.

I suggest either removing this sentence or expanding it to explain that we want 
to build LLVM/Clang separately from libc++ since we only want dfsan 
instrumentation on libc++.



Comment at: libcxx/utils/libcxx/test/config.py:915
+self.config.available_features.add('dfsan')
+self.config.available_features.add('sanitizer-new-delete')
 else:

I'm not 100% sure what the `sanitizer-new-delete` feature is used for, but I 
don't think we want it for dfsan since it doesn't use a custom allocator.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78390



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


[PATCH] D78392: [CUDA] Define __CUDACC__ before standard library headers

2020-04-17 Thread Artem Belevich via Phabricator via cfe-commits
tra updated this revision to Diff 258396.
tra added a comment.

Undef __CUDACC__ after the standard headers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78392

Files:
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,11 +31,17 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
 #include 
 #include 
+#undef __CUDACC__
 
 // Preserve common macros that will be changed below by us or by CUDA
 // headers.


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,11 +31,17 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
 #include 
 #include 
+#undef __CUDACC__
 
 // Preserve common macros that will be changed below by us or by CUDA
 // headers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8e20516 - [CUDA] Define __CUDACC__ before standard library headers

2020-04-17 Thread Artem Belevich via cfe-commits

Author: Raul Tambre
Date: 2020-04-17T12:56:13-07:00
New Revision: 8e20516540444618ad32dd11e835c05804053697

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

LOG: [CUDA] Define __CUDACC__ before standard library headers

libstdc++ since version 7 when GNU extensions are enabled (e.g. -std=gnu++11)
use it to avoid defining overloads using `__float128`.  This fixes compiling
with GNU extensions failing due to `__float128` being used.

Discovered at 
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4442#note_737136.

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

Added: 


Modified: 
clang/lib/Headers/__clang_cuda_runtime_wrapper.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_cuda_runtime_wrapper.h 
b/clang/lib/Headers/__clang_cuda_runtime_wrapper.h
index 63404c9bdeb5..f43ed55de489 100644
--- a/clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ b/clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,11 +31,17 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
 #include 
 #include 
+#undef __CUDACC__
 
 // Preserve common macros that will be changed below by us or by CUDA
 // headers.



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


[PATCH] D75917: Expose llvm fence instruction as clang intrinsic

2020-04-17 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

The tests look good, but I can't see the implementation in this diff. Maybe a 
file missing from the patch? Can be hard to tell with phabricator, the error 
may be at my end.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75917



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


[PATCH] D78392: [CUDA] Define __CUDACC__ before standard library headers

2020-04-17 Thread Artem Belevich via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8e2051654044: [CUDA] Define __CUDACC__ before standard 
library headers (authored by tambre, committed by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78392

Files:
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,11 +31,17 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
 #include 
 #include 
+#undef __CUDACC__
 
 // Preserve common macros that will be changed below by us or by CUDA
 // headers.


Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -31,11 +31,17 @@
 // Include some forward declares that must come before cmath.
 #include <__clang_cuda_math_forward_declares.h>
 
+// Define __CUDACC__ early as libstdc++ standard headers with GNU extensions
+// enabled depend on it to avoid using __float128, which is unsupported in
+// CUDA.
+#define __CUDACC__
+
 // Include some standard headers to avoid CUDA headers including them
 // while some required macros (like __THROW) are in a weird state.
 #include 
 #include 
 #include 
+#undef __CUDACC__
 
 // Preserve common macros that will be changed below by us or by CUDA
 // headers.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 10b60dd - [PowerPC] Refactor ppcUserFeaturesCheck()

2020-04-17 Thread Lei Huang via cfe-commits

Author: Lei Huang
Date: 2020-04-17T15:19:46-05:00
New Revision: 10b60dde767011c250649dc6a305379034c5b5c5

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

LOG: [PowerPC] Refactor ppcUserFeaturesCheck()

Summary: This function keeps growing, refactor to use lambda.

Reviewers: nemanjai, stefanp

Subscribers: kbarton, shchenz, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Basic/Targets/PPC.cpp
clang/test/Driver/ppc-dependent-options.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 1877d4a5ef70..81c13a8104e8 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -228,33 +228,25 @@ void PPCTargetInfo::getTargetDefines(const LangOptions 
&Opts,
 static bool ppcUserFeaturesCheck(DiagnosticsEngine &Diags,
  const std::vector &FeaturesVec) {
 
-  if (llvm::find(FeaturesVec, "-vsx") != FeaturesVec.end()) {
-if (llvm::find(FeaturesVec, "+power8-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower8-vector"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+direct-move") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mdirect-move"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+float128") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mfloat128"
- << "-mno-vsx";
-  return false;
+  // vsx was not explicitly turned off.
+  if (llvm::find(FeaturesVec, "-vsx") == FeaturesVec.end())
+return true;
+
+  auto FindVSXSubfeature = [&](StringRef Feature, StringRef Option) {
+if (llvm::find(FeaturesVec, Feature) != FeaturesVec.end()) {
+  Diags.Report(diag::err_opt_not_valid_with_opt) << Option << "-mno-vsx";
+  return true;
 }
+return false;
+  };
 
-if (llvm::find(FeaturesVec, "+power9-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower9-vector"
- << "-mno-vsx";
-  return false;
-}
-  }
+  bool Found = FindVSXSubfeature("+power8-vector", "-mpower8-vector");
+  Found |= FindVSXSubfeature("+direct-move", "-mdirect-move");
+  Found |= FindVSXSubfeature("+float128", "-mfloat128");
+  Found |= FindVSXSubfeature("+power9-vector", "-mpower9-vector");
 
-  return true;
+  // Return false if any vsx subfeatures was found.
+  return !Found;
 }
 
 bool PPCTargetInfo::initFeatureMap(

diff  --git a/clang/test/Driver/ppc-dependent-options.cpp 
b/clang/test/Driver/ppc-dependent-options.cpp
index 9fb812dc218f..c089422c68b9 100644
--- a/clang/test/Driver/ppc-dependent-options.cpp
+++ b/clang/test/Driver/ppc-dependent-options.cpp
@@ -54,6 +54,10 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-FLT128
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
+
 #ifdef __VSX__
 static_assert(false, "VSX enabled");
 #endif
@@ -78,5 +82,7 @@ static_assert(false, "Neither enabled");
 // CHECK-NVSX-P9V: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-FLT128: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-DMV: error: option '-mdirect-move' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX: Neither enabled
 // CHECK-VSX: VSX enabled



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


[PATCH] D76801: [AST] Print a> without extra spaces in C++11 or later.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a subscriber: dblaikie.
sammccall added a comment.

Sorry about the problems here, and thanks for letting me know...

In D76801#1989421 , @rnk wrote:

> We updated the compiler and break some VS std::map visualizers:
>  https://crbug.com/1068394
>  I haven't 100% confirmed that this caused the issue, but looking at the code 
> suggests that the names in our codeview output changed, which I would 
> consider to be a regression. This should've been caught by clang's test 
> suite. We already have codeview tests that try to ensure clang prints debug 
> info names following MSVC's exact spacing, but apparently none broke, so this 
> area was under-tested. I wonder if gdb or other DWARF consumers might be 
> affected by this formatting change.


I've got a sinking feeling that I misunderstood the implications of updating 
CodeGenCXX/debug-info-template-explicit-specialization.cpp and the 
Modules/*DebugInfo.cpp tests.
I assumed that these were human-readable names, not things that tools rely on. 
As you say maybe the dwarf changes broke things.
I don't really know much about debug info, @dblaikie do you think the DWARF 
changes in those tests are safe? If not, should I be documenting/mitigating 
this or trying to undo it?

Regarding CodeView it sounds like we do need to undo this change. 
PrintingPolicy has:

  /// Use whitespace and punctuation like MSVC does. In particular, this prints
  /// anonymous namespaces as `anonymous namespace' and does not insert spaces
  /// after template arguments.
  unsigned MSVCFormatting : 1;

and this is set in `CGDebugInfo::getPrintingPolicy()` in CodeView mode.

That seems like the right knob to change this behavior.
I'm not sure I know enough to write the codeview test, but I'll give it a shot 
and send that to you.

> Two issues in the Chrome codebase where tests relied on the output of clang's 
> diagnostics:
>  https://crbug.com/1064986
>  The compiler's diagnostic output isn't stable, so this is expected.

Yeah, obviously this changed a bunch of clang's own diagnostics tests too.
I'm not sure there's much to be done about this - even with perfect knowledge 
of such downstream tests, I don't think shying away from marginal improvements 
in diagnostics would be a great tradeoff.
Sorry about the churn though :-(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801



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


[PATCH] D77278: Remove asserting getters from base Type

2020-04-17 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77278



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


[PATCH] D77278: Remove asserting getters from base Type

2020-04-17 Thread Christopher Tetreault via Phabricator via cfe-commits
ctetreau updated this revision to Diff 258411.
ctetreau added a comment.

catch straggler


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77278

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/unittests/IR/VPIntrinsicTest.cpp

Index: llvm/unittests/IR/VPIntrinsicTest.cpp
===
--- llvm/unittests/IR/VPIntrinsicTest.cpp
+++ llvm/unittests/IR/VPIntrinsicTest.cpp
@@ -107,7 +107,7 @@
 if (MaskParamPos.hasValue()) {
   Type *MaskParamType = F.getArg(MaskParamPos.getValue())->getType();
   ASSERT_TRUE(MaskParamType->isVectorTy());
-  ASSERT_TRUE(MaskParamType->getVectorElementType()->isIntegerTy(1));
+  ASSERT_TRUE(cast(MaskParamType)->getElementType()->isIntegerTy(1));
 }
 
 Optional VecLenParamPos =
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -4263,7 +4263,7 @@
 
 Base = SDB->getValue(C);
 
-unsigned NumElts = Ptr->getType()->getVectorNumElements();
+unsigned NumElts = cast(Ptr->getType())->getNumElements();
 EVT VT = EVT::getVectorVT(*DAG.getContext(), TLI.getPointerTy(DL), NumElts);
 Index = DAG.getConstant(0, SDB->getCurSDLoc(), VT);
 IndexType = ISD::SIGNED_SCALED;
Index: llvm/lib/CodeGen/CodeGenPrepare.cpp
===
--- llvm/lib/CodeGen/CodeGenPrepare.cpp
+++ llvm/lib/CodeGen/CodeGenPrepare.cpp
@@ -5262,7 +5262,7 @@
   if (!RewriteGEP && Ops.size() == 2)
 return false;
 
-  unsigned NumElts = Ptr->getType()->getVectorNumElements();
+  unsigned NumElts = cast(Ptr->getType())->getNumElements();
 
   IRBuilder<> Builder(MemoryInst);
 
Index: llvm/include/llvm/IR/Type.h
===
--- llvm/include/llvm/IR/Type.h
+++ llvm/include/llvm/IR/Type.h
@@ -300,11 +300,7 @@
 
   /// If this is a vector type, return the element type, otherwise return
   /// 'this'.
-  Type *getScalarType() const {
-if (isVectorTy())
-  return getVectorElementType();
-return const_cast(this);
-  }
+  inline Type *getScalarType() const;
 
   //======//
   // Type Iteration support.
@@ -339,8 +335,8 @@
 
   //======//
   // Helper methods corresponding to subclass methods.  This forces a cast to
-  // the specified subclass and calls its accessor.  "getVectorNumElements" (for
-  // example) is shorthand for cast(Ty)->getNumElements().  This is
+  // the specified subclass and calls its accessor.  "getArrayNumElements" (for
+  // example) is shorthand for cast(Ty)->getNumElements().  This is
   // only intended to cover the core methods that are frequently used, helper
   // methods should not be added here.
 
@@ -361,14 +357,6 @@
 return ContainedTys[0];
   }
 
-  inline bool getVectorIsScalable() const;
-  inline unsigned getVectorNumElements() const;
-  inline ElementCount getVectorElementCount() const;
-  Type *getVectorElementType() const {
-assert(getTypeID() == VectorTyID);
-return ContainedTys[0];
-  }
-
   Type *getPointerElementType() const {
 assert(getTypeID() == PointerTyID);
 return ContainedTys[0];
Index: llvm/include/llvm/IR/DerivedTypes.h
===
--- llvm/include/llvm/IR/DerivedTypes.h
+++ llvm/include/llvm/IR/DerivedTypes.h
@@ -531,18 +531,6 @@
   }
 };
 
-unsigned Type::getVectorNumElements() const {
-  return cast(this)->getNumElements();
-}
-
-bool Type::getVectorIsScalable() const {
-  return cast(this)->isScalable();
-}
-
-ElementCount Type::getVectorElementCount() const {
-  return cast(this)->getElementCount();
-}
-
 bool Type::isVectorTy() const { return isa(this); }
 
 /// Class to represent pointers.
@@ -597,8 +585,8 @@
   isIntOrIntVectorTy() &&
   "Original type expected to be a vector of integers or a scalar integer.");
   Type *NewType = getIntNTy(getContext(), NewBitWidth);
-  if (isVectorTy())
-NewType = VectorType::get(NewType, getVectorElementCount());
+  if (auto *VTy = dyn_cast(this))
+NewType = VectorType::get(NewType, VTy->getElementCount());
   return NewType;
 }
 
@@ -606,6 +594,12 @@
   return cast(getScalarType())->getAddressSpace();
 }
 
+Type *Type::getScalarType() const {
+  if (isVectorTy())
+return cast(this)->getElementType();
+  return const_cast(this);
+}
+
 } // end namespace llvm
 
 #endif // LLVM_IR_DERIVEDTYPES_H
Index: clang/lib/CodeGen/CGBuiltin.cpp
=

[PATCH] D76932: [AIX] emit .extern and .weak directive linkage

2020-04-17 Thread Digger via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 258409.
DiggerLin marked 2 inline comments as done.
DiggerLin added a comment.

rebase the patch on the D78045  and address 
comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76932

Files:
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/test/Driver/aix-as.c
  llvm/include/llvm/MC/MCAsmInfo.h
  llvm/include/llvm/MC/MCDirectives.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/lib/MC/MCAsmInfoXCOFF.cpp
  llvm/lib/MC/MCAsmStreamer.cpp
  llvm/lib/MC/MCXCOFFStreamer.cpp
  llvm/lib/MC/XCOFFObjectWriter.cpp
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/CodeGen/PowerPC/aix-LinkOnceAnyLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-LinkOnceODRLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-WeakODRLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-extern-weak.ll
  llvm/test/CodeGen/PowerPC/aix-extern.ll
  llvm/test/CodeGen/PowerPC/aix-reference-func-addr-const.ll
  llvm/test/CodeGen/PowerPC/aix-weak.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll

Index: llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
===
--- llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
+++ llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
@@ -36,7 +36,7 @@
 ; OBJ-NEXT:   NumberOfSections: 2
 ; OBJ-NEXT:   TimeStamp: None (0x0)
 ; OBJ-NEXT:   SymbolTableOffset: 0x13C
-; OBJ-NEXT:   SymbolTableEntries: 24
+; OBJ-NEXT:   SymbolTableEntries: 26
 ; OBJ-NEXT:   OptionalHeaderSize: 0x0
 ; OBJ-NEXT:   Flags: 0x0
 ; OBJ-NEXT: }
@@ -86,7 +86,7 @@
 ; RELOC-NEXT:   }
 ; RELOC-NEXT:   Relocation {
 ; RELOC-NEXT: Virtual Address: 0x1A
-; RELOC-NEXT: Symbol: globalA (20)
+; RELOC-NEXT: Symbol: globalA (22)
 ; RELOC-NEXT: IsSigned: No
 ; RELOC-NEXT: FixupBitValue: 0
 ; RELOC-NEXT: Length: 16
@@ -94,7 +94,7 @@
 ; RELOC-NEXT:   }
 ; RELOC-NEXT:   Relocation {
 ; RELOC-NEXT: Virtual Address: 0x1E
-; RELOC-NEXT: Symbol: globalB (22)
+; RELOC-NEXT: Symbol: globalB (24)
 ; RELOC-NEXT: IsSigned: No
 ; RELOC-NEXT: FixupBitValue: 0
 ; RELOC-NEXT: Length: 16
@@ -104,7 +104,7 @@
 ; RELOC-NEXT: Section (index: 2) .data {
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x70
-; RELOC-NEXT:   Symbol: arr (12)
+; RELOC-NEXT:   Symbol: arr (14)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -112,7 +112,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x74
-; RELOC-NEXT:   Symbol: .foo (4)
+; RELOC-NEXT:   Symbol: .foo (6)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -120,7 +120,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x78
-; RELOC-NEXT:   Symbol: TOC (18)
+; RELOC-NEXT:   Symbol: TOC (20)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -128,7 +128,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x80
-; RELOC-NEXT:   Symbol: globalA (8)
+; RELOC-NEXT:   Symbol: globalA (10)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -136,7 +136,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x84
-; RELOC-NEXT:   Symbol: globalB (10)
+; RELOC-NEXT:   Symbol: globalB (12)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -168,6 +168,26 @@
 ; SYM-NEXT:   }
 ; SYM-NEXT:   Symbol {
 ; SYM-NEXT: Index: 2
+; SYM-NEXT: Name: bar
+; SYM-NEXT: Value (RelocatableAddress): 0x0
+; SYM-NEXT: Section: N_UNDEF
+; SYM-NEXT: Type: 0x0
+; SYM-NEXT: StorageClass: C_EXT (0x2)
+; SYM-NEXT: NumberOfAuxEntries: 1
+; SYM-NEXT: CSECT Auxiliary Entry {
+; SYM-NEXT:   Index: 3
+; SYM-NEXT:   SectionLen: 0
+; SYM-NEXT:   ParameterHashIndex: 0x0
+; SYM-NEXT:   TypeChkSectNum: 0x0
+; SYM-NEXT:   SymbolAlignmentLog2: 0
+; SYM-NEXT:   SymbolType: XTY_ER (0x0)
+; SYM-NEXT:   StorageMappingClass: XMC_DS (0xA)
+; SYM-NEXT:   StabInfoIndex: 0x0
+; SYM-NEXT:   StabSectNum: 0x0
+; SYM-NEXT: }
+; SYM-NEXT:   }
+; SYM-NEXT:   Symbol {
+; SYM-NEXT: Index: 4
 ; SYM-NEXT: Name: .text
 ; SYM-NEXT: Value (RelocatableAddress): 0x0
 ; SYM-NEXT: Section: .text
@@ -175,7 +195,7 @@
 ; SYM-NEXT: StorageClass: C_HIDEXT (0x6B)
 ; SYM-NEXT: NumberOfAuxEntries: 1
 ; SYM-NEXT: CSECT Auxiliary Entry {
-; SYM-NEXT:   Index: 3
+; SYM-NEXT:   Index: 5
 ; SYM-NEXT:   SectionLen: 64
 ; SYM-NEXT:   ParameterHashIndex: 0x0
 ; SYM-NEXT:   TypeChkSectNum: 0x0
@@ -187,7 +207,7 @@
 ; SYM-NEXT: }
 ; SYM-NEXT:   }
 ; SYM-NEXT:   Symbol {
-; SYM-NEXT: Index: 4
+; SYM-NEXT: Index: 6
 ; SYM-NEXT: Name: .foo
 ; SYM-NEXT: V

[PATCH] D76932: [AIX] emit .extern and .weak directive linkage

2020-04-17 Thread Digger via Phabricator via cfe-commits
DiggerLin marked 7 inline comments as done.
DiggerLin added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1496
+
+MCSymbol *Name = getSymbol(&F);
+if (TM.getTargetTriple().isOSBinFormatXCOFF() && !F.isIntrinsic()) {

hubert.reinterpretcast wrote:
> DiggerLin wrote:
> > jasonliu wrote:
> > > This block of code and D78045 will have conflict. One of us will need to 
> > > rebase.
> > the one who land later will rebase.
> My understanding is that this would need a semantic reconciliation. I'd like 
> to see the rebase of this patch before approving. Also, this would be another 
> place to look into for the follow-up mentioned in 
> https://reviews.llvm.org/D78045?id=257331#inline-714634 @jasonliu.
rebase the patch on the D78045



Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1641
 
-  // External global variables are already handled.
-  if (GV->isDeclaration())
+  if (GV->isDeclaration()) {
+emitLinkage(GV, Csect->getQualNameSymbol());

hubert.reinterpretcast wrote:
> This should probably be `isDeclarationForLinker`. It seems we need a larger 
> followup for `AvailableExternallyLinkage` that would involve checking our 
> calls to `isDeclaration`:
> 
> ```
> define void @_Z1gv() {
> entry:
>   call void @_Z1fIiEvv()
>   ret void
> }
> 
> ; Function Attrs: inlinehint nounwind
> define available_externally void @_Z1fIiEvv() #0 {
> entry:
>   ret void
> }
> 
> attributes #0 = { inlinehint nounwind }
> ```

   bool isDeclarationForLinker() const {
 if (hasAvailableExternallyLinkage())
   return true;
 
 return isDeclaration();
   }
 
since we do not deal with AvailableExternallyLinkage in 
AsmPrinter::emitLinkage()

if change to isDeclarationForLinker here , it will hit a report_fatal_error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76932



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


[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

2020-04-17 Thread Lei Huang via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
lei marked an inline comment as done.
Closed by commit rG10b60dde7670: [PowerPC] Refactor ppcUserFeaturesCheck() 
(authored by lei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78308

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-dependent-options.cpp


Index: clang/test/Driver/ppc-dependent-options.cpp
===
--- clang/test/Driver/ppc-dependent-options.cpp
+++ clang/test/Driver/ppc-dependent-options.cpp
@@ -54,6 +54,10 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-FLT128
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
+
 #ifdef __VSX__
 static_assert(false, "VSX enabled");
 #endif
@@ -78,5 +82,7 @@
 // CHECK-NVSX-P9V: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-FLT128: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX-DMV: error: option '-mdirect-move' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mfloat128' cannot be specified with 
'-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mpower9-vector' cannot be specified with 
'-mno-vsx'
 // CHECK-NVSX: Neither enabled
 // CHECK-VSX: VSX enabled
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -228,33 +228,25 @@
 static bool ppcUserFeaturesCheck(DiagnosticsEngine &Diags,
  const std::vector &FeaturesVec) {
 
-  if (llvm::find(FeaturesVec, "-vsx") != FeaturesVec.end()) {
-if (llvm::find(FeaturesVec, "+power8-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower8-vector"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+direct-move") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mdirect-move"
- << "-mno-vsx";
-  return false;
-}
-
-if (llvm::find(FeaturesVec, "+float128") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mfloat128"
- << "-mno-vsx";
-  return false;
+  // vsx was not explicitly turned off.
+  if (llvm::find(FeaturesVec, "-vsx") == FeaturesVec.end())
+return true;
+
+  auto FindVSXSubfeature = [&](StringRef Feature, StringRef Option) {
+if (llvm::find(FeaturesVec, Feature) != FeaturesVec.end()) {
+  Diags.Report(diag::err_opt_not_valid_with_opt) << Option << "-mno-vsx";
+  return true;
 }
+return false;
+  };
 
-if (llvm::find(FeaturesVec, "+power9-vector") != FeaturesVec.end()) {
-  Diags.Report(diag::err_opt_not_valid_with_opt) << "-mpower9-vector"
- << "-mno-vsx";
-  return false;
-}
-  }
+  bool Found = FindVSXSubfeature("+power8-vector", "-mpower8-vector");
+  Found |= FindVSXSubfeature("+direct-move", "-mdirect-move");
+  Found |= FindVSXSubfeature("+float128", "-mfloat128");
+  Found |= FindVSXSubfeature("+power9-vector", "-mpower9-vector");
 
-  return true;
+  // Return false if any vsx subfeatures was found.
+  return !Found;
 }
 
 bool PPCTargetInfo::initFeatureMap(


Index: clang/test/Driver/ppc-dependent-options.cpp
===
--- clang/test/Driver/ppc-dependent-options.cpp
+++ clang/test/Driver/ppc-dependent-options.cpp
@@ -54,6 +54,10 @@
 // RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 %s 2>&1 | \
 // RUN: FileCheck %s -check-prefix=CHECK-NVSX-FLT128
 
+// RUN: not %clang -target powerpc64le-unknown-unknown -fsyntax-only \
+// RUN: -mcpu=power9 -std=c++11 -mno-vsx -mfloat128 -mpower9-vector %s 2>&1 | \
+// RUN: FileCheck %s -check-prefix=CHECK-NVSX-MULTI
+
 #ifdef __VSX__
 static_assert(false, "VSX enabled");
 #endif
@@ -78,5 +82,7 @@
 // CHECK-NVSX-P9V: error: option '-mpower9-vector' cannot be specified with '-mno-vsx'
 // CHECK-NVSX-FLT128: error: option '-mfloat128' cannot be specified with '-mno-vsx'
 // CHECK-NVSX-DMV: error: option '-mdirect-move' cannot be specified with '-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mfloat128' cannot be specified with '-mno-vsx'
+// CHECK-NVSX-MULTI: error: option '-mpower9-vector' cannot be specified with '-mno-vsx'
 // CHECK-NVSX: Neither enabled
 // CHECK-VSX: VSX enabled
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/T

[clang] c858deb - Remove asserting getters from base Type

2020-04-17 Thread Christopher Tetreault via cfe-commits

Author: Christopher Tetreault
Date: 2020-04-17T14:03:31-07:00
New Revision: c858debebc1308e748de882c745e179b1a398fa0

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

LOG: Remove asserting getters from base Type

Summary:
Remove asserting vector getters from Type in preparation for the
VectorType refactor. The existence of these functions complicates the
refactor while adding little value.

Reviewers: dexonsmith, sdesmalen, efriedma

Reviewed By: efriedma

Subscribers: cfe-commits, hiraditya, llvm-commits

Tags: #llvm, #clang

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp
llvm/include/llvm/IR/DerivedTypes.h
llvm/include/llvm/IR/Type.h
llvm/lib/CodeGen/CodeGenPrepare.cpp
llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
llvm/unittests/IR/VPIntrinsicTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index f4832ef4afb2..8ee69740f15c 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -7573,8 +7573,7 @@ Value *CodeGenFunction::EmitSVEMaskedStore(const CallExpr 
*E,
   // The vector type that is stored may be 
diff erent from the
   // eventual type stored to memory.
   auto VectorTy = cast(Ops.back()->getType());
-  auto MemoryTy =
-  llvm::VectorType::get(MemEltTy, VectorTy->getVectorElementCount());
+  auto MemoryTy = llvm::VectorType::get(MemEltTy, VectorTy->getElementCount());
 
   Value *Predicate = EmitSVEPredicateCast(Ops[0], MemoryTy);
   Value *BasePtr = Builder.CreateBitCast(Ops[1], MemoryTy->getPointerTo());

diff  --git a/llvm/include/llvm/IR/DerivedTypes.h 
b/llvm/include/llvm/IR/DerivedTypes.h
index 92017448fe0d..186430754303 100644
--- a/llvm/include/llvm/IR/DerivedTypes.h
+++ b/llvm/include/llvm/IR/DerivedTypes.h
@@ -531,18 +531,6 @@ class VectorType : public Type {
   }
 };
 
-unsigned Type::getVectorNumElements() const {
-  return cast(this)->getNumElements();
-}
-
-bool Type::getVectorIsScalable() const {
-  return cast(this)->isScalable();
-}
-
-ElementCount Type::getVectorElementCount() const {
-  return cast(this)->getElementCount();
-}
-
 bool Type::isVectorTy() const { return isa(this); }
 
 /// Class to represent pointers.
@@ -597,8 +585,8 @@ Type *Type::getWithNewBitWidth(unsigned NewBitWidth) const {
   isIntOrIntVectorTy() &&
   "Original type expected to be a vector of integers or a scalar 
integer.");
   Type *NewType = getIntNTy(getContext(), NewBitWidth);
-  if (isVectorTy())
-NewType = VectorType::get(NewType, getVectorElementCount());
+  if (auto *VTy = dyn_cast(this))
+NewType = VectorType::get(NewType, VTy->getElementCount());
   return NewType;
 }
 
@@ -606,6 +594,12 @@ unsigned Type::getPointerAddressSpace() const {
   return cast(getScalarType())->getAddressSpace();
 }
 
+Type *Type::getScalarType() const {
+  if (isVectorTy())
+return cast(this)->getElementType();
+  return const_cast(this);
+}
+
 } // end namespace llvm
 
 #endif // LLVM_IR_DERIVEDTYPES_H

diff  --git a/llvm/include/llvm/IR/Type.h b/llvm/include/llvm/IR/Type.h
index 79d6964e3b3e..67be3ef480b7 100644
--- a/llvm/include/llvm/IR/Type.h
+++ b/llvm/include/llvm/IR/Type.h
@@ -300,11 +300,7 @@ class Type {
 
   /// If this is a vector type, return the element type, otherwise return
   /// 'this'.
-  Type *getScalarType() const {
-if (isVectorTy())
-  return getVectorElementType();
-return const_cast(this);
-  }
+  inline Type *getScalarType() const;
 
   
//======//
   // Type Iteration support.
@@ -339,8 +335,8 @@ class Type {
 
   
//======//
   // Helper methods corresponding to subclass methods.  This forces a cast to
-  // the specified subclass and calls its accessor.  "getVectorNumElements" 
(for
-  // example) is shorthand for cast(Ty)->getNumElements().  This is
+  // the specified subclass and calls its accessor.  "getArrayNumElements" (for
+  // example) is shorthand for cast(Ty)->getNumElements().  This is
   // only intended to cover the core methods that are frequently used, helper
   // methods should not be added here.
 
@@ -361,14 +357,6 @@ class Type {
 return ContainedTys[0];
   }
 
-  inline bool getVectorIsScalable() const;
-  inline unsigned getVectorNumElements() const;
-  inline ElementCount getVectorElementCount() const;
-  Type *getVectorElementType() const {
-assert(getTypeID() == VectorTyID);
-return ContainedTys[0];
-  }
-
   Type *getPointerElementType() const {
 assert(getTypeID() == PointerTyID);
 return ContainedTys[0];

diff  --git a/llvm/lib/CodeGen/CodeGenPrepare.cpp 
b/llvm/lib/CodeGen/

[PATCH] D78401: [SveEmitter] IsInsertOp1SVALL and builtins for svqdec[bhwd] and svqinc[bhwd]

2020-04-17 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen created this revision.
sdesmalen added reviewers: efriedma, SjoerdMeijer.
Herald added a subscriber: tschuett.
Herald added a project: clang.
sdesmalen added a parent revision: D77597: [SveEmitter] Add IsAppendSVALL and 
builtins for svptrue and svcnt[bhwd].

Some ACLE builtins leave out the argument to specify the predicate
pattern, which is expected to be expanded to an SV_ALL pattern.

This patch adds the flag IsInsertOp1SVALL to insert SV_ALL as the
second operand.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78401

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdech.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qinch.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdech.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qdecw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qinch.c
  clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -502,6 +502,7 @@
 Bitwidth = 16;
 ElementBitwidth = 1;
 break;
+  case 's':
   case 'a':
 Bitwidth = ElementBitwidth;
 NumVectors = 0;
Index: clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/negative/acle_sve_qincw.c
@@ -0,0 +1,155 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify %s
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+#include 
+
+int32_t test_svqincw_n_s32(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s32,,)(op, 0);
+}
+
+int32_t test_svqincw_n_s32_1(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s32,,)(op, 17);
+}
+
+int64_t test_svqincw_n_s64(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s64,,)(op, 0);
+}
+
+int64_t test_svqincw_n_s64_1(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_s64,,)(op, 17);
+}
+
+uint32_t test_svqincw_n_u32(uint32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u32,,)(op, 0);
+}
+
+uint32_t test_svqincw_n_u32_1(uint32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u32,,)(op, 17);
+}
+
+uint64_t test_svqincw_n_u64(uint64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u64,,)(op, 0);
+}
+
+uint64_t test_svqincw_n_u64_1(uint64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw,_n_u64,,)(op, 17);
+}
+
+int32_t test_svqincw_pat_n_s32(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw_pat,_n_s32,,)(op, SV_POW2, 0);
+}
+
+int32_t test_svqincw_pat_n_s32_1(int32_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid range [1, 16]}}
+  return SVE_ACLE_FUNC(svqincw_pat,_n_s32,,)(op, SV_VL1, 17);
+}
+
+int64_t test_svqincw_pat_n_s64(int64_t op)
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is

[PATCH] D77597: [SveEmitter] Add IsAppendSVALL and builtins for svptrue and svcnt[bhwd]

2020-04-17 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 258416.
sdesmalen retitled this revision from "[SveEmitter] Add ExpandOp1SVALL and 
builtin for svptrue" to "[SveEmitter] Add IsAppendSVALL and builtins for 
svptrue and svcnt[bhwd]".
sdesmalen edited the summary of this revision.
sdesmalen added a comment.

- Renamed flag to `IsAppendSVALL` to distinguish it from the case of 
`IsInsertOp1SVALL` that will follow in a separate patch.


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

https://reviews.llvm.org/D77597

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cnth.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cntw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c

Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_ptrue.c
@@ -0,0 +1,201 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+svbool_t test_svptrue_b8()
+{
+  // CHECK-LABEL: test_svptrue_b8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 31)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_b8();
+}
+
+svbool_t test_svptrue_b16()
+{
+  // CHECK-LABEL: test_svptrue_b16
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv8i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv8i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b16();
+}
+
+svbool_t test_svptrue_b32()
+{
+  // CHECK-LABEL: test_svptrue_b32
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv4i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv4i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b32();
+}
+
+svbool_t test_svptrue_b64()
+{
+  // CHECK-LABEL: test_svptrue_b64
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv2i1(i32 31)
+  // CHECK: %[[CAST:.*]] = call  @llvm.aarch64.sve.convert.to.svbool.nxv2i1( %[[INTRINSIC]])
+  // CHECK: ret  %[[CAST]]
+  return svptrue_b64();
+}
+
+svbool_t test_svptrue_pat_b8()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 0)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_POW2);
+}
+
+svbool_t test_svptrue_pat_b8_1()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_1
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 1)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL1);
+}
+
+svbool_t test_svptrue_pat_b8_2()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_2
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 2)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL2);
+}
+
+svbool_t test_svptrue_pat_b8_3()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_3
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 3)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL3);
+}
+
+svbool_t test_svptrue_pat_b8_4()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_4
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 4)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL4);
+}
+
+svbool_t test_svptrue_pat_b8_5()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_5
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 5)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL5);
+}
+
+svbool_t test_svptrue_pat_b8_6()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_6
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 6)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL6);
+}
+
+svbool_t test_svptrue_pat_b8_7()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_7
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 7)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL7);
+}
+
+svbool_t test_svptrue_pat_b8_8()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_8
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 8)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL8);
+}
+
+svbool_t test_svptrue_pat_b8_9()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_9
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 9)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL16);
+}
+
+svbool_t test_svptrue_pat_b8_10()
+{
+  // CHECK-LABEL: test_svptrue_pat_b8_10
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.ptrue.nxv16i1(i32 10)
+  // CHECK: ret  %[[INTRINSIC]]
+  return svptrue_pat_b8(SV_VL32);
+}
+
+svbool_

[PATCH] D76801: [AST] Print a> without extra spaces in C++11 or later.

2020-04-17 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a subscriber: amccarth.
rnk added a comment.

In D76801#1989641 , @sammccall wrote:

> I've got a sinking feeling that I misunderstood the implications of updating 
> CodeGenCXX/debug-info-template-explicit-specialization.cpp and the 
> Modules/*DebugInfo.cpp tests.
>  I assumed that these were human-readable names, not things that tools rely 
> on. As you say maybe the dwarf changes broke things.
>  I don't really know much about debug info, @dblaikie do you think the DWARF 
> changes in those tests are safe? If not, should I be documenting/mitigating 
> this or trying to undo it?
>
> Regarding CodeView it sounds like we do need to undo this change. 
> PrintingPolicy has:
>
>   /// Use whitespace and punctuation like MSVC does. In particular, this 
> prints
>   /// anonymous namespaces as `anonymous namespace' and does not insert spaces
>   /// after template arguments.
>   unsigned MSVCFormatting : 1;
>   
>
> and this is set in `CGDebugInfo::getPrintingPolicy()` in CodeView mode.
>
> That seems like the right knob to change this behavior.
>  I'm not sure I know enough to write the codeview test, but I'll give it a 
> shot and send that to you.


Yep, that sounds like the right fix. I was imagining some policy method 
`useMSVCFormatting` that flips both options together.

Hang on, I may have been too quick. We *do* have a test for this, at the end of 
clang/test/CodeGenCXX/debug-info-codeview-display-names.cpp:
https://github.com/llvm/llvm-project/blob/f8452ddfcc3336e42544a35481507f0b3bae423e/clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp#L98

The test passes for me locally, although I'm not sure why.

I would leave things a bit longer to give @amccarth more time to investigate 
and confirm. Thanks for the offer to help, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801



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


[PATCH] D73307: Unique Names for Functions with Internal Linkage

2020-04-17 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a subscriber: erichkeane.
rnk added a comment.

In D73307#1978140 , @tmsriram wrote:

> In D73307#1972388 , @rnk wrote:
>
> > Regarding the alias attribute, it occurs to me that reimplementing this as 
> > an early LLVM pass would not have that problem. Do you think that would be 
> > worth doing?
>
>
> I can try doing this.  If my understanding is right,  you are suggesting that 
> doing this later would mean the alias would have already been applied?.  
> However, for multi-versioning symbols, I must parse the target name to insert 
> the module name in between right?


Yes, Clang will apply the alias, do all name mangling, etc, and then renaming 
will happen later.

It's not clear to me if the order of the `.` suffix on multi-versioned 
symbols matters. @erichkeane, should it? Supposing some mid-level optimization 
came along and did function versioning, it would rename the internal function 
and append `.1`. So, I think appending as you implemented is fine.

---

All of my concerns have been addressed, and I think everyone else's are as 
well. We have documentation indicating what we mean by uniqueness which 
@hubert.reinterpretcast wanted clarified, we had the prefix map issue which I 
believe is addressed, so to my knowledge this is ready.

Let's wait a bit to hear from Erich, but otherwise I think this is ready in a 
few days.


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

https://reviews.llvm.org/D73307



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


[PATCH] D78289: [analyzer] Stability improvements for IteratorModeling functions

2020-04-17 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

@baloghadamsoftware
I know you have much expertise here. Do you have some thoughts of how I can 
test exactly these cases?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78289



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


[PATCH] D77278: Remove asserting getters from base Type

2020-04-17 Thread Christopher Tetreault via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc858debebc13: Remove asserting getters from base Type 
(authored by ctetreau).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77278

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/include/llvm/IR/DerivedTypes.h
  llvm/include/llvm/IR/Type.h
  llvm/lib/CodeGen/CodeGenPrepare.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/unittests/IR/VPIntrinsicTest.cpp

Index: llvm/unittests/IR/VPIntrinsicTest.cpp
===
--- llvm/unittests/IR/VPIntrinsicTest.cpp
+++ llvm/unittests/IR/VPIntrinsicTest.cpp
@@ -107,7 +107,7 @@
 if (MaskParamPos.hasValue()) {
   Type *MaskParamType = F.getArg(MaskParamPos.getValue())->getType();
   ASSERT_TRUE(MaskParamType->isVectorTy());
-  ASSERT_TRUE(MaskParamType->getVectorElementType()->isIntegerTy(1));
+  ASSERT_TRUE(cast(MaskParamType)->getElementType()->isIntegerTy(1));
 }
 
 Optional VecLenParamPos =
Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
===
--- llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+++ llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
@@ -4263,7 +4263,7 @@
 
 Base = SDB->getValue(C);
 
-unsigned NumElts = Ptr->getType()->getVectorNumElements();
+unsigned NumElts = cast(Ptr->getType())->getNumElements();
 EVT VT = EVT::getVectorVT(*DAG.getContext(), TLI.getPointerTy(DL), NumElts);
 Index = DAG.getConstant(0, SDB->getCurSDLoc(), VT);
 IndexType = ISD::SIGNED_SCALED;
Index: llvm/lib/CodeGen/CodeGenPrepare.cpp
===
--- llvm/lib/CodeGen/CodeGenPrepare.cpp
+++ llvm/lib/CodeGen/CodeGenPrepare.cpp
@@ -5262,7 +5262,7 @@
   if (!RewriteGEP && Ops.size() == 2)
 return false;
 
-  unsigned NumElts = Ptr->getType()->getVectorNumElements();
+  unsigned NumElts = cast(Ptr->getType())->getNumElements();
 
   IRBuilder<> Builder(MemoryInst);
 
Index: llvm/include/llvm/IR/Type.h
===
--- llvm/include/llvm/IR/Type.h
+++ llvm/include/llvm/IR/Type.h
@@ -300,11 +300,7 @@
 
   /// If this is a vector type, return the element type, otherwise return
   /// 'this'.
-  Type *getScalarType() const {
-if (isVectorTy())
-  return getVectorElementType();
-return const_cast(this);
-  }
+  inline Type *getScalarType() const;
 
   //======//
   // Type Iteration support.
@@ -339,8 +335,8 @@
 
   //======//
   // Helper methods corresponding to subclass methods.  This forces a cast to
-  // the specified subclass and calls its accessor.  "getVectorNumElements" (for
-  // example) is shorthand for cast(Ty)->getNumElements().  This is
+  // the specified subclass and calls its accessor.  "getArrayNumElements" (for
+  // example) is shorthand for cast(Ty)->getNumElements().  This is
   // only intended to cover the core methods that are frequently used, helper
   // methods should not be added here.
 
@@ -361,14 +357,6 @@
 return ContainedTys[0];
   }
 
-  inline bool getVectorIsScalable() const;
-  inline unsigned getVectorNumElements() const;
-  inline ElementCount getVectorElementCount() const;
-  Type *getVectorElementType() const {
-assert(getTypeID() == VectorTyID);
-return ContainedTys[0];
-  }
-
   Type *getPointerElementType() const {
 assert(getTypeID() == PointerTyID);
 return ContainedTys[0];
Index: llvm/include/llvm/IR/DerivedTypes.h
===
--- llvm/include/llvm/IR/DerivedTypes.h
+++ llvm/include/llvm/IR/DerivedTypes.h
@@ -531,18 +531,6 @@
   }
 };
 
-unsigned Type::getVectorNumElements() const {
-  return cast(this)->getNumElements();
-}
-
-bool Type::getVectorIsScalable() const {
-  return cast(this)->isScalable();
-}
-
-ElementCount Type::getVectorElementCount() const {
-  return cast(this)->getElementCount();
-}
-
 bool Type::isVectorTy() const { return isa(this); }
 
 /// Class to represent pointers.
@@ -597,8 +585,8 @@
   isIntOrIntVectorTy() &&
   "Original type expected to be a vector of integers or a scalar integer.");
   Type *NewType = getIntNTy(getContext(), NewBitWidth);
-  if (isVectorTy())
-NewType = VectorType::get(NewType, getVectorElementCount());
+  if (auto *VTy = dyn_cast(this))
+NewType = VectorType::get(NewType, VTy->getElementCount());
   return NewType;
 }
 
@@ -606,6 +594,12 @@
   return cast(getScalarType())->getAddressSpace();
 }
 
+Type *Type::getScalarType() const {
+  if (isVectorTy())
+return cast(this)->getElementType();
+  return const_cast(this);
+}
+
 } // end namespace llvm
 
 #endif // LL

[clang] 7ce4e65 - [cmake] Temporarily disable building std::filesystem in CrossWinToARMLinux.cmake

2020-04-17 Thread Sergej Jaskiewicz via cfe-commits

Author: Sergej Jaskiewicz
Date: 2020-04-18T00:29:44+03:00
New Revision: 7ce4e652312f776c2cdd1650370c8909f7cf992f

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

LOG: [cmake] Temporarily disable building std::filesystem in 
CrossWinToARMLinux.cmake

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index 3d1e961ada8d..c01c31ae5a72 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -89,6 +89,9 @@ set(LIBCXXABI_LINK_TESTS_WITH_SHARED_LIBCXXOFF CACHE BOOL 
"")
 set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXXABIOFF CACHE BOOL "")
 set(LIBCXX_LINK_TESTS_WITH_SHARED_LIBCXX   OFF CACHE BOOL "")
 
+# FIXME: Remove this when https://reviews.llvm.org/D78200 is merged.
+set(LIBCXX_ENABLE_FILESYSTEM OFF CACHE BOOL "") 
+
 set(LIBCXX_USE_COMPILER_RT  ON CACHE BOOL "")
 set(LIBCXX_TARGET_TRIPLE"${CMAKE_C_COMPILER_TARGET}" CACHE 
STRING "")
 set(LIBCXX_SYSROOT  "${DEFAULT_SYSROOT}" CACHE STRING 
"")



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


[PATCH] D78402: [AArch64] Define ACLE FP conversion intrinsics with more specific predicate.

2020-04-17 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78402



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


[PATCH] D59647: [CUDA][HIP] Warn shared var initialization

2020-04-17 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl requested review of this revision.
yaxunl added a comment.

We need to revive this review since we found it is very inconvenient without 
this.

Also, nvcc only emits a warning for it

https://cuda.godbolt.org/z/AzrDTt

So I think maybe we even want to emit it as warning by default.


Repository:
  rC Clang

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

https://reviews.llvm.org/D59647



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


[PATCH] D78239: [SveEmitter] Add builtins for FP conversions

2020-04-17 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 258426.
sdesmalen added a comment.

- Added comment to CGBuiltin explaining that the special case for IsFPConvert 
will be removed in a follow-up patch.


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

https://reviews.llvm.org/D78239

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/arm_sve.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cvt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtlt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtnt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -556,6 +556,21 @@
 ElementBitwidth = Bitwidth = 64;
 NumVectors = 0;
 break;
+  case 'O':
+Predicate = false;
+Float = true;
+ElementBitwidth = 16;
+break;
+  case 'M':
+Predicate = false;
+Float = true;
+ElementBitwidth = 32;
+break;
+  case 'N':
+Predicate = false;
+Float = true;
+ElementBitwidth = 64;
+break;
   case 'S':
 Constant = true;
 Pointer = true;
@@ -1010,6 +1025,17 @@
   if (!InGuard.empty())
 OS << "#endif  //" << InGuard << "\n";
 
+  OS << "#if defined(__ARM_FEATURE_SVE2)\n";
+  OS << "#define svcvtnt_f16_x  svcvtnt_f16_m\n";
+  OS << "#define svcvtnt_f16_f32_x  svcvtnt_f16_f32_m\n";
+  OS << "#define svcvtnt_f32_x  svcvtnt_f32_m\n";
+  OS << "#define svcvtnt_f32_f64_x  svcvtnt_f32_f64_m\n\n";
+
+  OS << "#define svcvtxnt_f32_x svcvtxnt_f32_m\n";
+  OS << "#define svcvtxnt_f32_f64_x svcvtxnt_f32_f64_m\n\n";
+
+  OS << "#endif /*__ARM_FEATURE_SVE2 */\n\n";
+
   OS << "#ifdef __cplusplus\n";
   OS << "} // extern \"C\"\n";
   OS << "#endif\n\n";
Index: clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtxnt.c
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify -verify-ignore-unexpected=error %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only -verify=overload -verify-ignore-unexpected=error %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1,A2_UNUSED,A3,A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1,A2,A3,A4) A1##A2##A3##A4
+#endif
+
+svfloat32_t test_svcvtxnt_f32_f64_m(svfloat32_t inactive, svbool_t pg, svfloat64_t op)
+{
+  // CHECK-LABEL: test_svcvtxnt_f32_f64_m
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.fcvtxnt.f32f64( %inactive,  %pg,  %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  // overload-warning@+2 {{implicit declaration of function 'svcvtxnt_f32_m'}}
+  // expected-warning@+1 {{implicit declaration of function 'svcvtxnt_f32_f64_m'}}
+  return SVE_ACLE_FUNC(svcvtxnt_f32,_f64,_m,)(inactive, pg, op);
+}
+
+svfloat32_t test_svcvtxnt_f32_f64_x(svfloat32_t even, svbool_t pg, svfloat64_t op)
+{
+  // CHECK-LABEL: test_svcvtxnt_f32_f64_x
+  // CHECK: %[[INTRINSIC:.*]] = call  @llvm.aarch64.sve.fcvtxnt.f32f64( %even,  %pg,  %op)
+  // CHECK: ret  %[[INTRINSIC]]
+  // overload-warning@+2 {{implicit declaration of function 'svcvtxnt_f32_x'}}
+  // expected-warning@+1 {{implicit declaration of function 'svcvtxnt_f32_f64_x'}}
+  return SVE_ACLE_FUNC(svcvtxnt_f32,_f64,_x,)(even, pg, op);
+}
Index: clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_cvtx.c
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE2 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve2 -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D_

[PATCH] D76801: [AST] Print a> without extra spaces in C++11 or later.

2020-04-17 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D76801#1989718 , @rnk wrote:

> Hang on, I may have been too quick. We *do* have a test for this, at the end 
> of clang/test/CodeGenCXX/debug-info-codeview-display-names.cpp:
>  
> https://github.com/llvm/llvm-project/blob/f8452ddfcc3336e42544a35481507f0b3bae423e/clang/test/CodeGenCXX/debug-info-codeview-display-name.cpp#L98
>
> The test passes for me locally, although I'm not sure why.


After this patch the default depends on the language version, and that test 
specifies c++98 :-(

> I would leave things a bit longer to give @amccarth more time to investigate 
> and confirm. Thanks for the offer to help, though.

Sure thing, let me know if it's useful for me to pick this up. I'm sure the 
debugging was the worst of it though, sorry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76801



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


[PATCH] D76932: [AIX] emit .extern and .weak directive linkage

2020-04-17 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast added inline comments.



Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:2144
 report_fatal_error(
-"Unhandled linkage when mapping linkage to StorageClass.");
+"AvailableExternallyLinkage is for its first instance of linkage");
   }

It seems my editing instruction got confused for the text. This is what I meant:
```
"Unhandled AvailableExternallyLinkage when mapping linkage to StorageClass"
```



Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1641
 
-  // External global variables are already handled.
-  if (GV->isDeclaration())
+  if (GV->isDeclaration()) {
+emitLinkage(GV, Csect->getQualNameSymbol());

DiggerLin wrote:
> hubert.reinterpretcast wrote:
> > This should probably be `isDeclarationForLinker`. It seems we need a larger 
> > followup for `AvailableExternallyLinkage` that would involve checking our 
> > calls to `isDeclaration`:
> > 
> > ```
> > define void @_Z1gv() {
> > entry:
> >   call void @_Z1fIiEvv()
> >   ret void
> > }
> > 
> > ; Function Attrs: inlinehint nounwind
> > define available_externally void @_Z1fIiEvv() #0 {
> > entry:
> >   ret void
> > }
> > 
> > attributes #0 = { inlinehint nounwind }
> > ```
> 
>bool isDeclarationForLinker() const {
>  if (hasAvailableExternallyLinkage())
>return true;
>  
>  return isDeclaration();
>}
>  
> since we do not deal with AvailableExternallyLinkage in 
> AsmPrinter::emitLinkage()
> 
> if change to isDeclarationForLinker here , it will hit a report_fatal_error.
What happens for the case above? We need to generate `MCSA_Extern` for the 
reference. The definition should not appear in the output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76932



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


[PATCH] D78239: [SveEmitter] Add builtins for FP conversions

2020-04-17 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen marked an inline comment as done.
sdesmalen added a comment.

In D78239#1987859 , @efriedma wrote:

> I think the predicate type is something we should fix.   Even if it's not 
> causing problems now, it seems like the sort of thing that will bite us later.


Yes I agree, I've implemented this in D78402 




Comment at: clang/utils/TableGen/SveEmitter.cpp:1035
+  OS << "#define svcvtxnt_f32_x svcvtxnt_f32_m\n";
+  OS << "#define svcvtxnt_f32_f64_x svcvtxnt_f32_f64_m\n\n";
+

efriedma wrote:
> Not worth implementing these separately?  I guess I can see why it wouldn't 
> be profitable.
We currently don't really optimise the _x (MergeAny) case yet for other 
intrinsics, so addressing this seems more trouble than it's worth, specifically 
because the merging with `undef` for only the top/odd lanes would not be 
trivial to represent. 


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

https://reviews.llvm.org/D78239



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


[PATCH] D78404: [clang] Implement P0692R1 from C++20 (access checking on specializations)

2020-04-17 Thread Sergej Jaskiewicz via Phabricator via cfe-commits
broadwaylamb created this revision.
broadwaylamb added reviewers: asl, rsmith, doug.gregor, rjmccall, triton.
broadwaylamb added a project: clang.
Herald added subscribers: cfe-commits, dexonsmith.

This patch implements paper P0692R1 
 from the 
C++20 standard.

This also fixes a bug (https://llvm.org/PR37424) where explicit instantiations 
of templates parameterized by overloaded private member functions were 
incorrectly rejected.

This is my first contribution to CFE, so please let me know if I did something 
horribly wrong.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D78404

Files:
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/CXX/temp/temp.decls/temp.class.spec/p10.cpp
  clang/test/CXX/temp/temp.spec/p6.cpp
  clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -966,7 +966,7 @@
 
   Access checking on specializations
   https://wg21.link/p0692r1";>P0692R1
-  Partial
+  Clang 11
 
 
   Default constructible and assignable stateless lambdas
Index: clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
===
--- clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
+++ /dev/null
@@ -1,19 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// expected-no-diagnostics
-
-class X {
-  template  class Y {};
-};
-
-class A {
-  class B {};
-  class C {};
-};
-
-// C++0x [temp.explicit] 14.7.2/11:
-//   The usual access checking rules do not apply to names used to specify
-//   explicit instantiations.
-template class X::Y;
-
-// As an extension, this rule is applied to explicit specializations as well.
-template <> class X::Y {};
Index: clang/test/CXX/temp/temp.spec/p6.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/p6.cpp
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+class X {
+  template  class Y {};
+};
+
+class A {
+  class B {};
+  class C {};
+
+  void func();
+  static void staticFunc();
+
+  // See https://llvm.org/PR37424
+  void funcOverloaded();
+  void funcOverloaded(int);
+  static void staticFuncOverloaded();
+  static void staticFuncOverloaded(int);
+
+  int field;
+};
+
+// C++20 [temp.spec] 17.8/6:
+//   The usual access checking rules do not apply to names in a declaration of
+//   an explicit instantiation or explicit specialization, with the exception
+//   of names appearing in a function body, default argument, base-clause,
+//   member-specification, enumerator-list, or static data member or variable
+//   template initializer.
+template class X::Y;
+
+template  class D {};
+template class D<&A::func>;
+template class D<&A::funcOverloaded>;
+
+template  class E { };
+template class E<&A::staticFunc>;
+template class E<&A::staticFuncOverloaded>;
+
+template  class G {};
+template class G<&A::field>;
+
+// As an extension, this rule is applied to explicit specializations as well.
+template <> class X::Y {};
Index: clang/test/CXX/temp/temp.decls/temp.class.spec/p10.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.decls/temp.class.spec/p10.cpp
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+// C++20 [temp.class.spec] 17.6.5/10:
+//   The usual access checking rules do not apply to non-dependent names used
+//   to specify template arguments of the simple-template-id of the partial
+//   specialization.
+
+class TestClass {
+private:
+  void func();
+  void funcOverloaded();
+  void funcOverloaded(int);
+
+  static void staticFunc();
+  static void staticFuncOverloaded();
+  static void staticFuncOverloaded(int);
+
+  class Nested {};
+
+  int field;
+};
+
+template  class TemplateClass {};
+template <> class TemplateClass<&TestClass::func> {};
+template <> class TemplateClass<&TestClass::funcOverloaded> {};
+
+template  class TemplateClass2 { };
+template <> class TemplateClass2<&TestClass::staticFunc> {};
+template <> class TemplateClass2<&TestClass::staticFuncOverloaded> {};
+
+template class TemplateClass3 {};
+template class TemplateClass3 {};
+template class TemplateClass3 {};
+
+template class TemplateClass4 {};
+template class TemplateClass4 {};
+template class TemplateClass4 {};
+
+template class TemplateClass5 {};
+template<> class TemplateClass5 {};
+
+template class TemplateClass6 {};
+template class TemplateClass6 {};
+
+template  class TemplateClass7 {};
+template <> class TemplateClass7<&TestClass::field> {};
+
+template  class TemplateClass8 {};
+template  class TemplateClass8 {};
+
+template
+struct trait;
+
+class class_ {
+  template
+  struct impl;
+};
+
+template
+struct trai

[PATCH] D78239: [SveEmitter] Add builtins for FP conversions

2020-04-17 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang/utils/TableGen/SveEmitter.cpp:1035
+  OS << "#define svcvtxnt_f32_x svcvtxnt_f32_m\n";
+  OS << "#define svcvtxnt_f32_f64_x svcvtxnt_f32_f64_m\n\n";
+

sdesmalen wrote:
> efriedma wrote:
> > Not worth implementing these separately?  I guess I can see why it wouldn't 
> > be profitable.
> We currently don't really optimise the _x (MergeAny) case yet for other 
> intrinsics, so addressing this seems more trouble than it's worth, 
> specifically because the merging with `undef` for only the top/odd lanes 
> would not be trivial to represent. 
Okay.


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

https://reviews.llvm.org/D78239



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


  1   2   >