[PATCH] D60463: [ASTImporter] Add check for correct import of source locations.

2019-05-30 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

In the current state there are failing AST tests. This test can be added after 
the problems are fixed.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60463



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


[PATCH] D60463: [ASTImporter] Add check for correct import of source locations.

2019-05-30 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 202197.
balazske added a comment.

New patch and check the first line of AST dump only.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60463

Files:
  unittests/AST/ASTImporterFixtures.cpp
  unittests/AST/ASTImporterFixtures.h
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -49,9 +49,8 @@
   llvm::raw_svector_ostream ToNothing(ImportChecker);
   ToCtx.getTranslationUnitDecl()->print(ToNothing);
 
-  // This traverses the AST to catch certain bugs like poorly or not
-  // implemented subtrees.
-  (*Imported)->dump(ToNothing);
+  // Additional SourceLocation checks.
+  checkImportedSourceLocations(Node, *Imported);
 }
 
 return Imported;
Index: unittests/AST/ASTImporterFixtures.h
===
--- unittests/AST/ASTImporterFixtures.h
+++ unittests/AST/ASTImporterFixtures.h
@@ -42,6 +42,8 @@
 void createVirtualFileIfNeeded(ASTUnit *ToAST, StringRef FileName,
StringRef Code);
 
+void checkImportedSourceLocations(const Decl *FromD, const Decl *ToD);
+
 // Common base for the different families of ASTImporter tests that are
 // parameterized on the compiler options which may result a different AST. E.g.
 // -fms-compatibility or -fdelayed-template-parsing.
Index: unittests/AST/ASTImporterFixtures.cpp
===
--- unittests/AST/ASTImporterFixtures.cpp
+++ unittests/AST/ASTImporterFixtures.cpp
@@ -18,6 +18,8 @@
 #include "clang/Frontend/ASTUnit.h"
 #include "clang/Tooling/Tooling.h"
 
+#include 
+
 namespace clang {
 namespace ast_matchers {
 
@@ -38,6 +40,82 @@
llvm::MemoryBuffer::getMemBuffer(Code));
 }
 
+void checkImportedSourceLocations(const Decl *FromD, const Decl *ToD) {
+  // Check AST dump for matching source locations in From and To AST.
+  // The first line of the AST dump contains information about the root node and
+  // some of the SourceLocation info, but certainly not everything.
+  // Still it is worth to check these. The test can be extended to check the
+  // whole AST dump but for this to work the ordering of imported Decls must be
+  // the same which is not the case now.
+  // The AST dump additionally traverses the AST and can catch certain bugs like
+  // poorly or not implemented subtrees.
+
+  // Print debug information?
+  const bool Print = false;
+
+  SmallString<1024> ToPrinted;
+  SmallString<1024> FromPrinted;
+  llvm::raw_svector_ostream ToStream(ToPrinted);
+  llvm::raw_svector_ostream FromStream(FromPrinted);
+
+  ToD->dump(ToStream);
+  FromD->dump(FromStream);
+
+  // search for SourceLocation strings:
+  // ::
+  // or
+  // line::
+  // or
+  // col:
+  // or
+  // ''
+  // If a component (filename or line) is same as in the last location
+  // it is not printed.
+  // Filename component is grouped into sub-expression to make it extractable.
+  std::regex MatchSourceLoc(
+  "|((\\w|\\.)+):\\d+:\\d+|line:\\d+:\\d+|col:\\d+");
+
+  std::string ToString(ToStream.str());
+  std::string FromString(FromStream.str());
+  int ToEndl = ToString.find('\n');
+  if (ToEndl == std::string::npos)
+ToEndl = ToString.size();
+  int FromEndl = FromString.find('\n');
+  if (FromEndl == std::string::npos)
+FromEndl = FromString.size();
+  auto ToLoc = std::sregex_iterator(ToString.begin(), ToString.begin() + ToEndl,
+MatchSourceLoc);
+  auto FromLoc = std::sregex_iterator(
+  FromString.begin(), FromString.begin() + FromEndl, MatchSourceLoc);
+  if (Print) {
+llvm::errs() << ToString << "\n\n\n" << FromString << "\n";
+llvm::errs() << "\n";
+  }
+  if (ToLoc->size() > 1 && FromLoc->size() > 1 && (*ToLoc)[1] != (*FromLoc)[1])
+// Different filenames in To and From.
+// This should mean that a to-be-imported decl was mapped to an existing
+// (these normally reside in different files) and the check is
+// not applicable.
+return;
+
+  bool SourceLocationMismatch = false;
+  while (ToLoc != std::sregex_iterator() && FromLoc != std::sregex_iterator()) {
+if (Print)
+  llvm::errs() << ToLoc->str() << "|" << FromLoc->str() << "\n";
+SourceLocationMismatch =
+SourceLocationMismatch || (ToLoc->str() != FromLoc->str());
+++ToLoc;
+++FromLoc;
+  }
+  if (Print)
+llvm::errs() << "\n";
+
+  if (FromLoc != std::sregex_iterator() || ToLoc != std::sregex_iterator())
+SourceLocationMismatch = true;
+
+  EXPECT_FALSE(SourceLocationMismatch);
+}
+
 ASTImporterTestBase::TU::TU(StringRef Code, StringRef FileName, ArgVector Args,
 ImporterConstructor C)
 : 

r362100 - Follow up of r362096

2019-05-30 Thread Sjoerd Meijer via cfe-commits
Author: sjoerdmeijer
Date: Thu May 30 08:04:06 2019
New Revision: 362100

URL: http://llvm.org/viewvc/llvm-project?rev=362100=rev
Log:
Follow up of r362096

The new tests were failing, because I missed dependent patch D60697.
I have removed the failing cases for now, which I will restore once
D60697 is in.

Modified:
cfe/trunk/test/Driver/armv8.1m.main.c
cfe/trunk/test/Driver/armv8.1m.main.s

Modified: cfe/trunk/test/Driver/armv8.1m.main.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/armv8.1m.main.c?rev=362100=362099=362100=diff
==
--- cfe/trunk/test/Driver/armv8.1m.main.c (original)
+++ cfe/trunk/test/Driver/armv8.1m.main.c Thu May 30 08:04:06 2019
@@ -2,20 +2,6 @@
 // RUN: FileCheck --check-prefix=CHECK-DSP < %t %s
 // CHECK-DSP: "-target-feature" "+dsp"
 
-// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp  -### %s 2> 
%t
-// RUN: FileCheck --check-prefix=CHECK-FP < %t %s
-// CHECK-FP: "-target-feature" "+fp-armv8"
-// CHECK-FP-NOT: "-target-feature" "+fp64"
-// CHECK-FP-NOT: "-target-feature" "+d32"
-// CHECK-FP: "-target-feature" "+fullfp16"
-
-// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp.dp  -### %s 
2> %t
-// RUN: FileCheck --check-prefix=CHECK-FPDP < %t %s
-// CHECK-FPDP: "-target-feature" "+fp-armv8"
-// CHECK-FPDP: "-target-feature" "+fullfp16"
-// CHECK-FPDP: "-target-feature" "+fp64"
-// CHECK-FPDP-NOT: "-target-feature" "+d32"
-
 // RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve  -### %s 2> 
%t
 // RUN: FileCheck --check-prefix=CHECK-MVE < %t %s
 // CHECK-MVE: "-target-feature" "+mve"
@@ -25,10 +11,4 @@
 // CHECK-MVEFP: "-target-feature" "+mve.fp"
 // CHECK-MVEFP-NOT: "-target-feature" "+fp64"
 
-// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp  
-### %s 2> %t
-// RUN: FileCheck --check-prefix=CHECK-MVEFP_DP < %t %s
-// CHECK-MVEFP_DP: "-target-feature" "+mve.fp"
-// CHECK-MVEFP_DP: "-target-feature" "+fp64"
-
-// RUN: %clang -target arm-arm-none-eabi -march=armv8.1m.main+fp -S %s
 double foo (double a) { return a; }

Modified: cfe/trunk/test/Driver/armv8.1m.main.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/armv8.1m.main.s?rev=362100=362099=362100=diff
==
--- cfe/trunk/test/Driver/armv8.1m.main.s (original)
+++ cfe/trunk/test/Driver/armv8.1m.main.s Thu May 30 08:04:06 2019
@@ -4,17 +4,10 @@
 # RUN:  FileCheck --check-prefix=ERROR-V81M < %t %s
 # RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+dsp %s 
2>%t
 # RUN:  FileCheck --check-prefix=ERROR-V81M_DSP < %t %s
-# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp %s 
2>%t
-# RUN:  FileCheck --check-prefix=ERROR-V81M_FP < %t %s
-# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp.dp %s 
2>%t
-# RUN:  FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
 # RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve %s 
2>%t
 # RUN:  FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
-# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve+fp 
%s 2>%t
-# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE_FP < %t %s
 # RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp 
%s 2>%t
 # RUN:  FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
-# RUN: %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp 
%s
 
 .syntax unified
 .thumb
@@ -45,21 +38,15 @@ vcmp.f64 d0,d1
 # ERROR-V8M: :[[@LINE-1]]:1: error
 # ERROR-V81M: :[[@LINE-2]]:1: error
 # ERROR-V81M_DSP: :[[@LINE-3]]:1: error
-# ERROR-V81M_FP: :[[@LINE-4]]:1: error
-# ERROR-V81M_MVE: :[[@LINE-5]]:1: error
-# ERROR-V81M_MVE_FP: :[[@LINE-6]]:1: error
-# ERROR-V81M_MVEFP: :[[@LINE-7]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
+# ERROR-V81M_MVEFP: :[[@LINE-5]]:1: error
 
 asrl r0, r1, r2
 # ERROR-V8M: :[[@LINE-1]]:1: error
 # ERROR-V81M: :[[@LINE-2]]:1: error
 # ERROR-V81M_DSP: :[[@LINE-3]]:1: error
-# ERROR-V81M_FP: :[[@LINE-4]]:1: error
-# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
 
 vcadd.i8 q0, q1, q2, #90
 # ERROR-V8M: :[[@LINE-1]]:1: error
 # ERROR-V81M: :[[@LINE-2]]:1: error
 # ERROR-V81M_DSP: :[[@LINE-3]]:1: error
-# ERROR-V81M_FP: :[[@LINE-4]]:1: error
-# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error


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


[PATCH] D62525: [Analyzer] Add new visitor to the iterator checkers

2019-05-30 Thread Balogh, Ádám via Phabricator via cfe-commits
baloghadamsoftware marked an inline comment as done.
baloghadamsoftware added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/IteratorChecker.cpp:281-282
+
+  // `FoundChange` becomes true when we find the statement the results in the
+  // current state of the iterator.
+  // `FoundEmptyness` becomes true when we find the block edge assuming

NoQ wrote:
> I don't think we should stop here. I think it's worth it to highlight *all* 
> increments and decrements of the interesting iterator, so that it was clear 
> how come that it has the given value.
> 
> Additionally, because iterators are copied around, it makes sense to 
> "recursively" apply the visitor to the original object when the iterator is 
> obtained as a copy (similarly to how `trackExpressionValue` works).
This can be done but an iterator can reach the past-the-end or the first 
position by changing the container's size as well, not only by incrementing or 
decrementing the iterator itself.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62525



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


[PATCH] D62525: [Analyzer] Add new visitor to the iterator checkers

2019-05-30 Thread Balogh, Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

In D62525#1519868 , @NoQ wrote:

> In D62525#1519475 , 
> @baloghadamsoftware wrote:
>
> > Before someone asks: `NoteTag`s are not applicable here since invalidation 
> > and reaching one end of the range happens in many different places. This is 
> > also true for container emptiness.
>
>
> Mm, what's wrong with many different places? If you're worried about code 
> duplication, just put tag construction into a function (?)


It is not about code duplication. Of course, that can be handled by a function.

The problem is that the transition is added in the top level function but 
iterator position adjustments happen in the lower level ones. Data flow is 
one-way, top-down. For example, an insertion happens into a vector that 
invalidates all the iterators at and after the position where it is inserted. 
In this case `handleInsert()` calls a function that iterates all the active 
iterator positions and calls other one that invalidates the ones affected by 
the insertion. To propagate back the list of iterators invalidated would be too 
complex. Increments and decrements are even worse. Thus here the correct way 
seems to find the relevant transitions in a visitor instead of trying to figure 
out what note tags to add at each transition.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62525



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


Re: r361997 - [analyzer] print() JSONify: getNodeLabel implementation

2019-05-30 Thread Roman Lebedev via cfe-commits
On Thu, May 30, 2019 at 5:48 PM Csaba Dabis via cfe-commits
 wrote:
>
> Thanks you!
>
> Fixed by 
> https://github.com/llvm/llvm-project/commit/17604c3486cbe7c27cadac1757cd0a9109a92792
The non-determinism is still there though, so this isn't correct fix.

> On Thu, May 30, 2019 at 4:16 PM Russell Gallop  
> wrote:
>>
>> Hi Csaba,
>>
>> Failing example attached. Note that the output is different every time so 
>> there is potentially more than one failure mode.
>>
>> Thanks
>> Russ
>>
>> On Thu, 30 May 2019 at 15:05, Csaba Dabis  wrote:
>>>
>>> Hey!
>>>
>>> When it fails, could you provide the DOT dump? The path is: 
>>> llvm-project/build/tools/clang/test/Analysis/Output/dump_egraph.cpp.tmp.dot
>>>
>>> Thanks,
>>> Csaba.
>>>
>>> On Thu, May 30, 2019 at 4:00 PM Russell Gallop  
>>> wrote:

 Hi Csaba,

 The test dump_egraph.cpp appears to be flaky on Windows. For example here: 
 http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26183.

 C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Analysis\dump_egraph.cpp:23:11:
  error: CHECK: expected string not found in input
 // CHECK: \"store\": [\l\{ 
 \"cluster\": \"t\", \"items\": 
 [\l\{ \"kind\": 
 \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, #1\}\"

 Running locally, it fails after 2-5 runs for me, running:
 python bin/llvm-lit.py -v ../clang/test/Analysis/dump_egraph.cpp

 Please could you take a look?

 Note that I'm not certain it was this commit that started the flakiness, 
 it is the latest which changed the failing line.

 Thanks
 Russ

 On Wed, 29 May 2019 at 19:02, Csaba Dabis via cfe-commits 
  wrote:
>
> Author: charusso
> Date: Wed May 29 11:05:53 2019
> New Revision: 361997
>
> URL: http://llvm.org/viewvc/llvm-project?rev=361997=rev
> Log:
> [analyzer] print() JSONify: getNodeLabel implementation
>
> Summary: This patch also rewrites the ProgramPoint printing.
>
> Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
>
> Reviewed By: NoQ
>
> Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho,
>  donat.nagy, dkrupp
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D62346
>
> Modified:
> cfe/trunk/include/clang/Analysis/ProgramPoint.h
> cfe/trunk/lib/Analysis/ProgramPoint.cpp
> cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
> cfe/trunk/test/Analysis/dump_egraph.c
> cfe/trunk/test/Analysis/dump_egraph.cpp
>
> Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=361997=361996=361997=diff
> ==
> --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
> +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Wed May 29 11:05:53 
> 2019
> @@ -213,7 +213,7 @@ public:
>  ID.AddPointer(getTag());
>}
>
> -  void print(StringRef CR, llvm::raw_ostream ) const;
> +  void printJson(llvm::raw_ostream , const char *NL = "\n") const;
>
>LLVM_DUMP_METHOD void dump() const;
>
>
> Modified: cfe/trunk/lib/Analysis/ProgramPoint.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ProgramPoint.cpp?rev=361997=361996=361997=diff
> ==
> --- cfe/trunk/lib/Analysis/ProgramPoint.cpp (original)
> +++ cfe/trunk/lib/Analysis/ProgramPoint.cpp Wed May 29 11:05:53 2019
> @@ -43,151 +43,152 @@ ProgramPoint ProgramPoint::getProgramPoi
>  }
>
>  LLVM_DUMP_METHOD void ProgramPoint::dump() const {
> -  return print(/*CR=*/"\n", llvm::errs());
> +  return printJson(llvm::errs());
>  }
>
> -static void printLocation(raw_ostream , SourceLocation SLoc,
> -  const SourceManager ,
> -  StringRef CR,
> -  StringRef Postfix) {
> -  if (SLoc.isFileID()) {
> -Out << CR << "line=" << SM.getExpansionLineNumber(SLoc)
> -<< " col=" << SM.getExpansionColumnNumber(SLoc) << Postfix;
> +static void printLocation(raw_ostream , SourceLocation Loc,
> +  const SourceManager ) {
> +  Out << "\"location\": ";
> +  if (!Loc.isFileID()) {
> +Out << "null";
> +return;
>}
> +
> +  Out << "{ \"line\": " << SM.getExpansionLineNumber(Loc)
> +  << ", \"column\": " << SM.getExpansionColumnNumber(Loc) << " }";
>  }
>
> -void ProgramPoint::print(StringRef CR, llvm::raw_ostream ) const {
> +void 

Re: r361997 - [analyzer] print() JSONify: getNodeLabel implementation

2019-05-30 Thread Csaba Dabis via cfe-commits
Thanks you!

Fixed by
https://github.com/llvm/llvm-project/commit/17604c3486cbe7c27cadac1757cd0a9109a92792

On Thu, May 30, 2019 at 4:16 PM Russell Gallop 
wrote:

> Hi Csaba,
>
> Failing example attached. Note that the output is different every time so
> there is potentially more than one failure mode.
>
> Thanks
> Russ
>
> On Thu, 30 May 2019 at 15:05, Csaba Dabis  wrote:
>
>> Hey!
>>
>> When it fails, could you provide the DOT dump? The path
>> is: 
>> llvm-project/build/tools/clang/test/Analysis/Output/dump_egraph.cpp.tmp.dot
>>
>> Thanks,
>> Csaba.
>>
>> On Thu, May 30, 2019 at 4:00 PM Russell Gallop 
>> wrote:
>>
>>> Hi Csaba,
>>>
>>> The test dump_egraph.cpp appears to be flaky on Windows. For example
>>> here:
>>> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26183
>>> .
>>>
>>> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Analysis\dump_egraph.cpp:23:11:
>>> error: CHECK: expected string not found in input
>>> // CHECK: \"store\": [\l\{
>>> \"cluster\": \"t\", \"items\":
>>> [\l\{ \"kind\":
>>> \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, #1\}\"
>>>
>>> Running locally, it fails after 2-5 runs for me, running:
>>> python bin/llvm-lit.py -v ../clang/test/Analysis/dump_egraph.cpp
>>>
>>> Please could you take a look?
>>>
>>> Note that I'm not certain it was this commit that started the flakiness,
>>> it is the latest which changed the failing line.
>>>
>>> Thanks
>>> Russ
>>>
>>> On Wed, 29 May 2019 at 19:02, Csaba Dabis via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: charusso
 Date: Wed May 29 11:05:53 2019
 New Revision: 361997

 URL: http://llvm.org/viewvc/llvm-project?rev=361997=rev
 Log:
 [analyzer] print() JSONify: getNodeLabel implementation

 Summary: This patch also rewrites the ProgramPoint printing.

 Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus

 Reviewed By: NoQ

 Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho,
  donat.nagy, dkrupp

 Tags: #clang

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

 Modified:
 cfe/trunk/include/clang/Analysis/ProgramPoint.h
 cfe/trunk/lib/Analysis/ProgramPoint.cpp
 cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
 cfe/trunk/test/Analysis/dump_egraph.c
 cfe/trunk/test/Analysis/dump_egraph.cpp

 Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=361997=361996=361997=diff

 ==
 --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
 +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Wed May 29 11:05:53
 2019
 @@ -213,7 +213,7 @@ public:
  ID.AddPointer(getTag());
}

 -  void print(StringRef CR, llvm::raw_ostream ) const;
 +  void printJson(llvm::raw_ostream , const char *NL = "\n") const;

LLVM_DUMP_METHOD void dump() const;


 Modified: cfe/trunk/lib/Analysis/ProgramPoint.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ProgramPoint.cpp?rev=361997=361996=361997=diff

 ==
 --- cfe/trunk/lib/Analysis/ProgramPoint.cpp (original)
 +++ cfe/trunk/lib/Analysis/ProgramPoint.cpp Wed May 29 11:05:53 2019
 @@ -43,151 +43,152 @@ ProgramPoint ProgramPoint::getProgramPoi
  }

  LLVM_DUMP_METHOD void ProgramPoint::dump() const {
 -  return print(/*CR=*/"\n", llvm::errs());
 +  return printJson(llvm::errs());
  }

 -static void printLocation(raw_ostream , SourceLocation SLoc,
 -  const SourceManager ,
 -  StringRef CR,
 -  StringRef Postfix) {
 -  if (SLoc.isFileID()) {
 -Out << CR << "line=" << SM.getExpansionLineNumber(SLoc)
 -<< " col=" << SM.getExpansionColumnNumber(SLoc) << Postfix;
 +static void printLocation(raw_ostream , SourceLocation Loc,
 +  const SourceManager ) {
 +  Out << "\"location\": ";
 +  if (!Loc.isFileID()) {
 +Out << "null";
 +return;
}
 +
 +  Out << "{ \"line\": " << SM.getExpansionLineNumber(Loc)
 +  << ", \"column\": " << SM.getExpansionColumnNumber(Loc) << " }";
  }

 -void ProgramPoint::print(StringRef CR, llvm::raw_ostream ) const {
 +void ProgramPoint::printJson(llvm::raw_ostream , const char *NL)
 const {
const ASTContext  =
getLocationContext()->getAnalysisDeclContext()->getASTContext();
const SourceManager  = Context.getSourceManager();
 +
 +  

[PATCH] D62156: [Sema][PR41730] Diagnose addr space mismatch while constructing objects

2019-05-30 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 4 inline comments as done.
Anastasia added inline comments.



Comment at: lib/Sema/SemaDeclCXX.cpp:8229
+  if (FTI.hasMethodTypeCVRUQualifiers()) {
+FTI.MethodQualifiers->forEachCVRUQualifier(
 [&](DeclSpec::TQ TypeQual, StringRef QualName, SourceLocation SL) {

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > rjmccall wrote:
> > > > We want to catch `_Atomic`, too, so please just change this loop to 
> > > > ignore address-space qualifiers, using a flag to decide whether to call 
> > > > `setInvalidType`.
> > > If there aren't any qualifiers we're skipping, the flag isn't necessary.
> > We are skipping addr space currently. I use this flag to avoid setting 
> > declaration as invalid below if it's only qualified by an addr space.
> Okay.  Does `forEachQualifier` not visit address-space qualifiers?
> 
> Please leave a comment explaining that that's the intended behavior: we 
> should visit everything except an address space.
> Okay. Does forEachQualifier not visit address-space qualifiers?

It calls `forEachCVRUQualifier`, nothing else.

> Please leave a comment explaining that that's the intended behavior: we 
> should visit everything except an address space.

Added in FIXME.




Comment at: lib/Sema/SemaOverload.cpp:6095
+// Check that addr space of an object being constructed is convertible to
+// the one ctor qualified with.
+if (!Qualifiers::isAddressSpaceSupersetOf(

rjmccall wrote:
> "Check that the constructor is capable of constructing an object in the 
> destination address space."
> 
> Should there be an exception here for trivial default/copy/move constructors?
Good point. Current implementation is generating one overload of each 
default/copy/move in generic address space only. But we could potentially look 
at changing this. If we could add extra overloads once we encounter each new 
ctor invocation it would be the easiest approach and this code would still be 
applicable. However, I would need to understand the feasibility in more 
details. May be this is something for the future work? Or do you have other 
suggestions? 



Comment at: test/CodeGenCXX/address-space-of-this.cpp:3
 // RUN: %clang_cc1 %s -std=c++17 -triple=spir -emit-llvm -o - | FileCheck %s
+// XFAIL: *
 

rjmccall wrote:
> Is there nothing in this test that's worth continuing to check while we work 
> on fixing this problem?
We can only compile this file if we had address space qualifiers accepted on 
methods, but it's still WIP (https://reviews.llvm.org/D57464) and I don't have 
the time to fix it now. But at the same time the OpenCL test cover the 
functionality originally intended in this test. Not sure if it's better to 
remove this test completely?



Comment at: test/SemaCXX/address-space-ctor.cpp:11
+//expected-note@-6{{candidate constructor (the implicit move constructor) not 
viable: no known conversion from 'int' to 'MyType &&' for 1st argument}}
+//expected-note@-6{{candidate constructor ignored: cannot be used to construct 
an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-8{{candidate constructor ignored: cannot be used to construct 
an object in address space '__attribute__((address_space(10)))'}}

Not sure if we should change to:
  cannot be used to construct an object with 
'__attribute__((address_space(10)))'

Although for OpenCL it would be ok as is.

Or may be it's better to add custom printing of addr spaces?


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

https://reviews.llvm.org/D62156



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


[PATCH] D62156: [Sema][PR41730] Diagnose addr space mismatch while constructing objects

2019-05-30 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 202193.
Anastasia marked 3 inline comments as done.
Anastasia added a comment.

- Improved diagnostic
- Added more comments


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

https://reviews.llvm.org/D62156

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Overload.h
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaInit.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCXX/address-space-of-this.cpp
  test/CodeGenOpenCLCXX/addrspace-ctor.cl
  test/SemaCXX/address-space-ctor.cpp

Index: test/SemaCXX/address-space-ctor.cpp
===
--- /dev/null
+++ test/SemaCXX/address-space-ctor.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 %s -std=c++14 -triple=spir -verify -fsyntax-only
+// RUN: %clang_cc1 %s -std=c++17 -triple=spir -verify -fsyntax-only
+
+struct MyType {
+  MyType(int i) : i(i) {}
+  int i;
+};
+
+//expected-note@-5{{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const MyType &' for 1st argument}}
+//expected-note@-6{{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'MyType &&' for 1st argument}}
+//expected-note@-6{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-8{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-9{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-9{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+
+// FIXME: We can't implicitly convert between address spaces yet.
+MyType __attribute__((address_space(10))) m1 = 123; //expected-error{{no viable conversion from 'int' to '__attribute__((address_space(10))) MyType'}}
+MyType __attribute__((address_space(10))) m2(123);  //expected-error{{no matching constructor for initialization of '__attribute__((address_space(10))) MyType'}}
Index: test/CodeGenOpenCLCXX/addrspace-ctor.cl
===
--- /dev/null
+++ test/CodeGenOpenCLCXX/addrspace-ctor.cl
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=c++ -emit-llvm -O0 -o - | FileCheck %s
+
+struct MyType {
+  MyType(int i) : i(i) {}
+  MyType(int i) __constant : i(i) {}
+  int i;
+};
+
+//CHECK: call void @_ZNU3AS26MyTypeC1Ei(%struct.MyType addrspace(2)* @const1, i32 1)
+__constant MyType const1 = 1;
+//CHECK: call void @_ZNU3AS26MyTypeC1Ei(%struct.MyType addrspace(2)* @const2, i32 2)
+__constant MyType const2(2);
+//CHECK: call void @_ZNU3AS46MyTypeC1Ei(%struct.MyType addrspace(4)* addrspacecast (%struct.MyType addrspace(1)* @glob to %struct.MyType addrspace(4)*), i32 1)
+MyType glob(1);
Index: test/CodeGenCXX/address-space-of-this.cpp
===
--- test/CodeGenCXX/address-space-of-this.cpp
+++ test/CodeGenCXX/address-space-of-this.cpp
@@ -1,8 +1,11 @@
 // RUN: %clang_cc1 %s -std=c++14 -triple=spir -emit-llvm -o - | FileCheck %s
 // RUN: %clang_cc1 %s -std=c++17 -triple=spir -emit-llvm -o - | FileCheck %s
+// XFAIL: *
 
+// FIXME: We can't compile address space method qualifiers yet.
+// Therefore there is no way to check correctness of this code.
 struct MyType {
-  MyType(int i) : i(i) {}
+  MyType(int i) __attribute__((address_space(10))) : i(i) {}
   int i;
 };
 //CHECK: call void @_ZN6MyTypeC1Ei(%struct.MyType* addrspacecast (%struct.MyType addrspace(10)* @m to %struct.MyType*), i32 123)
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -6101,6 +6101,15 @@
 return;
   }
 }
+
+// Check that the constructor is capable of constructing an object in the
+// destination address space.
+if (!Qualifiers::isAddressSpaceSupersetOf(
+Constructor->getMethodQualifiers().getAddressSpace(),
+CandidateSet.getDestAS())) {
+  Candidate.Viable = false;
+  Candidate.FailureKind = ovl_fail_object_addrspace_mismatch;
+}
   }
 
   unsigned NumParams = Proto->getNumParams();
@@ -10392,9 +10401,12 @@
 /// It would be great to be able to express per-candidate problems
 /// more richly for those diagnostic clients that cared, but we'd
 /// still have to be just as careful with the default diagnostics.
+/// \param CtorDestAS Addr space of object being constructed (for ctor
+/// candidates only).
 static void NoteFunctionCandidate(Sema , OverloadCandidate *Cand,
   unsigned NumArgs,
-  bool TakingCandidateAddress) {
+  bool 

[PATCH] D49074: [Analyzer] [WIP] Basic support for multiplication and division in the constraint manager

2019-05-30 Thread Balogh, Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 202192.
baloghadamsoftware removed a reviewer: george.karpenkov.
baloghadamsoftware added a comment.
Herald added a subscriber: Charusso.

Rebased.


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

https://reviews.llvm.org/D49074

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  test/Analysis/multiplicative-folding.c

Index: test/Analysis/multiplicative-folding.c
===
--- test/Analysis/multiplicative-folding.c
+++ test/Analysis/multiplicative-folding.c
@@ -570,6 +570,1478 @@
   }
 }
 
+void signed_multiplication_lt_0(int32_t n) {
+  if (n * 2 < 3) {
+int32_t  U1 = 0x8001,
+L2 = 0xc000, U2 = 1,
+L3 = 0x4000;
+
+assert(INT_MIN * 2 < 3);
+assert(U1 * 2 < 3);
+assert((U1 + 1) * 2 >= 3);
+assert(L2 * 2 < 3);
+assert((L2 - 1) * 2 >= 3);
+assert(U2 * 2 < 3);
+assert((U2 + 1) * 2 >= 3);
+assert(L3 * 2 < 3);
+assert((L3 - 1) * 2 >= 3);
+assert(INT_MAX * 2 < 3);
+
+if (n < INT_MIN / 2) {
+  clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+  clang_analyzer_eval(n <= U1); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U1); //expected-warning{{FALSE}}
+} else if (n < INT_MAX / 2){
+  clang_analyzer_eval(n < L2); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n <= U2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U2); //expected-warning{{FALSE}}
+} else {
+  clang_analyzer_eval(n < L3); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L3); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+}
+  }
+}
+
+void signed_multiplication_lt_1(int32_t n) {
+  if (n * 2 < 4) {
+int32_t  U1 = 0x8001,
+L2 = 0xc000, U2 = 1,
+L3 = 0x4000;
+
+assert(INT_MIN * 2 < 4);
+assert(U1 * 2 < 4);
+assert((U1 + 1) * 2 >= 4);
+assert(L2 * 2 < 4);
+assert((L2 - 1) * 2 >= 4);
+assert(U2 * 2 < 4);
+assert((U2 + 1) * 2 >= 4);
+assert(L3 * 2 < 4);
+assert((L3 - 1) * 2 >= 4);
+assert(INT_MAX * 2 < 4);
+
+if (n < INT_MIN / 2) {
+  clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+  clang_analyzer_eval(n <= U1); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U1); //expected-warning{{FALSE}}
+} else if (n < INT_MAX / 2){
+  clang_analyzer_eval(n < L2); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n <= U2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U2); //expected-warning{{FALSE}}
+} else {
+  clang_analyzer_eval(n < L3); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L3); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+}
+  }
+}
+
+void signed_multiplication_lt_2(int32_t n) {
+  if (n * 2 < 5) {
+int32_t  U1 = 0x8002,
+L2 = 0xc000, U2 = 2,
+L3 = 0x4000;
+
+assert(INT_MIN * 2 < 5);
+assert(U1 * 2 < 5);
+assert((U1 + 1) * 2 >= 5);
+assert(L2 * 2 < 5);
+assert((L2 - 1) * 2 >= 5);
+assert(U2 * 2 < 5);
+assert((U2 + 1) * 2 >= 5);
+assert(L3 * 2 < 5);
+assert((L3 - 1) * 2 >= 5);
+assert(INT_MAX * 2 < 5);
+
+if (n < INT_MIN / 2) {
+  clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+  clang_analyzer_eval(n <= U1); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U1); //expected-warning{{FALSE}}
+} else if (n < INT_MAX / 2){
+  clang_analyzer_eval(n < L2); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n <= U2); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n > U2); //expected-warning{{FALSE}}
+} else {
+  clang_analyzer_eval(n < L3); //expected-warning{{FALSE}}
+  clang_analyzer_eval(n >= L3); //expected-warning{{TRUE}}
+  clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+ //expected-warning@-1{{TRUE}}
+}
+  }
+}
+
+void signed_multiplication_lt_3(int32_t n) {
+  if (n * 3 < 4) {
+int32_t  U1 = 0xaaab,
+L2 = 0xd556, U2 = 

r362098 - [analyzer] print() JSONify chain: Fix build-bot breaks

2019-05-30 Thread Csaba Dabis via cfe-commits
Author: charusso
Date: Thu May 30 07:48:43 2019
New Revision: 362098

URL: http://llvm.org/viewvc/llvm-project?rev=362098=rev
Log:
[analyzer] print() JSONify chain: Fix build-bot breaks

Summary:
Printing out a map structure different in different environments so that
this patch generalize the test-case to check for the 'no stmt'-case
anywhere in the Store.

Modified:
cfe/trunk/test/Analysis/dump_egraph.cpp

Modified: cfe/trunk/test/Analysis/dump_egraph.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/dump_egraph.cpp?rev=362098=362097=362098=diff
==
--- cfe/trunk/test/Analysis/dump_egraph.cpp (original)
+++ cfe/trunk/test/Analysis/dump_egraph.cpp Thu May 30 07:48:43 2019
@@ -20,5 +20,5 @@ void foo() {
 
 // CHECK: \"constructing_objects\": [\l\{ 
\"location_context\": \"#0 Call\", \"calling\": \"T::T\", \"call_line\": 
\"16\", \"items\": [\l\{ 
\"lctx_id\": 2, \"init_id\": {{[0-9]+}}, \"kind\": \"construct into member 
variable\", \"argument_index\": null, \"pretty\": \"s\", \"value\": \"\>s\"
 
-// CHECK: \"store\": [\l\{ \"cluster\": 
\"t\", \"items\": [\l\{ 
\"kind\": \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, 
#1\}\"
+// CHECK: \"cluster\": \"t\", \"items\": 
[\l\{ \"kind\": \"Default\", 
\"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, #1\}\"
 


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


[PATCH] D50256: [Analyzer] [WIP] Basic support for multiplication and division in the constraint manager (for == and != only)

2019-05-30 Thread Balogh, Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 202191.
baloghadamsoftware added a comment.
Herald added a subscriber: Charusso.

Multipliers limited to less or equal to 255.


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

https://reviews.llvm.org/D50256

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
  test/Analysis/multiplicative-folding.c

Index: test/Analysis/multiplicative-folding.c
===
--- /dev/null
+++ test/Analysis/multiplicative-folding.c
@@ -0,0 +1,686 @@
+// RUN: %clang_analyze_cc1 --std=c11 -analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_eval(int);
+void clang_analyzer_warnIfReached(void);
+
+#define UINT_MAX (~0U)
+#define INT_MAX (int)(UINT_MAX & (UINT_MAX >> 1))
+#define INT_MIN (-INT_MAX - 1)
+
+#define ULONG_LONG_MAX (~0UL)
+#define LONG_LONG_MAX (long long)(ULONG_LONG_MAX & (ULONG_LONG_MAX >> 1))
+#define LONG_LONG_MIN (-LONG_LONG_MAX - 1)
+
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned int __line, __const char *__function)
+ __attribute__ ((__noreturn__));
+#define assert(expr) \
+  ((expr)  ? (void)(0)  : __assert_fail (#expr, __FILE__, __LINE__, __func__))
+
+typedef int int32_t;
+typedef unsigned int uint32_t;
+typedef long long int64_t;
+typedef unsigned long long uint64_t;
+
+void signed_multiplication_eq(int32_t n) {
+  if (n * 2 == 3) {
+clang_analyzer_warnIfReached(); // no-warning
+
+  } else if (n * 2 == 4) {
+const int32_t C1 = 0x8002, C2 = 2;
+
+assert(C1 * 2 == 4);
+assert(C2 * 2 == 4);
+
+clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C1 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == 0); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C2 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C2); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C2 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+
+  } else if (n * 3 == 4) {
+const int32_t C1 = 0xaaac;
+
+assert(C1 * 3 == 4);
+
+clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1); //expected-warning{{TRUE}}
+clang_analyzer_eval(n == C1 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == 0); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+
+  } else if (n * 4 == -5) {
+clang_analyzer_warnIfReached(); // no-warning
+
+  } else if (n * 4 == -8) {
+const int32_t C1 = 0xbffe, C2 = 0xfffe,
+  C3 = 0x3ffe, C4 = 0x7ffe;
+
+assert(C1 * 4 == -8);
+assert(C2 * 4 == -8);
+assert(C3 * 4 == -8);
+assert(C4 * 4 == -8);
+
+clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C1 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C2 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C2); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C2 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == 0); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C3 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C3); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C3 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C4 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C4); //expected-warning{{FALSE}}
+  //expected-warning@-1{{TRUE}}
+clang_analyzer_eval(n == C4 + 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == INT_MAX); //expected-warning{{FALSE}}
+
+  } else if (n * 6 == -7) {
+clang_analyzer_warnIfReached(); // no-warning
+
+  } else if (n * 6 == -2) {
+const int32_t C1 = 0xd555, C2 = 0x;
+
+assert(C1 * 6 == -2);
+assert(C2 * 6 == -2);
+
+clang_analyzer_eval(n == INT_MIN); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1 - 1); //expected-warning{{FALSE}}
+clang_analyzer_eval(n == C1); //expected-warning{{FALSE}}
+

[PATCH] D62665: Fix constexpr __builtin_*_overflow issue when unsigned->signed operand.

2019-05-30 Thread Erich Keane via Phabricator via cfe-commits
erichkeane created this revision.
erichkeane added reviewers: eli.friedman, efriedma, craig.topper.

As reported here https://bugs.llvm.org/show_bug.cgi?id=42000, it was
possible to get the constexpr version of __builtin_*_overflow to give
the wrong answer.

This was because when extending the operands to fit the largest type (so
that the math could be done), the decision on whether to sign/zero
extend the operands was based on the result signedness, not on the
operands signedness.

In the reported case, (unsigned char)255 - (int)100 needed
to have each extended to the int in order to do the math.  However, when
extending the first operand to 'int', we incorrectly sign extended it
instead of zero extending.  Thus, the result didnt fit back into the
unsigned char.

The fix for this was simply to choose zero/sign extension based on the
sign of the operand itself.


https://reviews.llvm.org/D62665

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/builtins-overflow.cpp


Index: clang/test/SemaCXX/builtins-overflow.cpp
===
--- clang/test/SemaCXX/builtins-overflow.cpp
+++ clang/test/SemaCXX/builtins-overflow.cpp
@@ -2,6 +2,7 @@
 // expected-no-diagnostics
 
 #include 
+#include 
 
 int a() {
   const int x = 3;
@@ -50,6 +51,7 @@
 static_assert(sub(static_cast(0),static_cast(1)) == 
Result{true, UCHAR_MAX});
 static_assert(sub(static_cast(0),static_cast(1)) == Result{false, -1});
 static_assert(sub(static_cast(0),static_cast(1)) 
== Result{true, USHRT_MAX});
+static_assert(sub(static_cast(255),static_cast(100)) == 
Result{false, 155});
 
 static_assert(sub(17,22) == Result{false, -5});
 static_assert(sub(INT_MAX - 22, -23) == Result{true, INT_MIN});
@@ -91,3 +93,4 @@
 static_assert(smul(17,22) == Result{false, 374});
 static_assert(smul(INT_MAX / 22, 23) == Result{true, -2049870757});
 static_assert(smul(INT_MIN / 22, -23) == Result{true, -2049870757});
+
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -9453,9 +9453,11 @@
   if (IsSigned && !AllSigned)
 ++MaxBits;
 
-  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) : 
LHS.zextOrSelf(MaxBits),
+  LHS = APSInt(LHS.isSigned() ? LHS.sextOrSelf(MaxBits)
+  : LHS.zextOrSelf(MaxBits),
!IsSigned);
-  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) : 
RHS.zextOrSelf(MaxBits),
+  RHS = APSInt(RHS.isSigned() ? RHS.sextOrSelf(MaxBits)
+  : RHS.zextOrSelf(MaxBits),
!IsSigned);
   Result = APSInt(MaxBits, !IsSigned);
 }


Index: clang/test/SemaCXX/builtins-overflow.cpp
===
--- clang/test/SemaCXX/builtins-overflow.cpp
+++ clang/test/SemaCXX/builtins-overflow.cpp
@@ -2,6 +2,7 @@
 // expected-no-diagnostics
 
 #include 
+#include 
 
 int a() {
   const int x = 3;
@@ -50,6 +51,7 @@
 static_assert(sub(static_cast(0),static_cast(1)) == Result{true, UCHAR_MAX});
 static_assert(sub(static_cast(0),static_cast(1)) == Result{false, -1});
 static_assert(sub(static_cast(0),static_cast(1)) == Result{true, USHRT_MAX});
+static_assert(sub(static_cast(255),static_cast(100)) == Result{false, 155});
 
 static_assert(sub(17,22) == Result{false, -5});
 static_assert(sub(INT_MAX - 22, -23) == Result{true, INT_MIN});
@@ -91,3 +93,4 @@
 static_assert(smul(17,22) == Result{false, 374});
 static_assert(smul(INT_MAX / 22, 23) == Result{true, -2049870757});
 static_assert(smul(INT_MIN / 22, -23) == Result{true, -2049870757});
+
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -9453,9 +9453,11 @@
   if (IsSigned && !AllSigned)
 ++MaxBits;
 
-  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) : LHS.zextOrSelf(MaxBits),
+  LHS = APSInt(LHS.isSigned() ? LHS.sextOrSelf(MaxBits)
+  : LHS.zextOrSelf(MaxBits),
!IsSigned);
-  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) : RHS.zextOrSelf(MaxBits),
+  RHS = APSInt(RHS.isSigned() ? RHS.sextOrSelf(MaxBits)
+  : RHS.zextOrSelf(MaxBits),
!IsSigned);
   Result = APSInt(MaxBits, !IsSigned);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D60699: [ARM] add CLI support for 8.1-M and MVE.

2019-05-30 Thread Sjoerd Meijer via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362096: [ARM] Add CLI support for Armv8.1-M and MVE 
(authored by SjoerdMeijer, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60699?vs=195157=202185#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60699

Files:
  cfe/trunk/lib/Basic/Targets/ARM.cpp
  cfe/trunk/test/Driver/armv8.1m.main.c
  cfe/trunk/test/Driver/armv8.1m.main.s

Index: cfe/trunk/lib/Basic/Targets/ARM.cpp
===
--- cfe/trunk/lib/Basic/Targets/ARM.cpp
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp
@@ -197,6 +197,8 @@
 return "8M_MAIN";
   case llvm::ARM::ArchKind::ARMV8R:
 return "8R";
+  case llvm::ARM::ArchKind::ARMV8_1MMainline:
+return "8_1M_MAIN";
   }
 }
 
Index: cfe/trunk/test/Driver/armv8.1m.main.s
===
--- cfe/trunk/test/Driver/armv8.1m.main.s
+++ cfe/trunk/test/Driver/armv8.1m.main.s
@@ -0,0 +1,65 @@
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V8M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+dsp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_DSP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp.dp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve+fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
+# RUN: %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp %s
+
+.syntax unified
+.thumb
+.text
+
+csinc r0, r1, r2, eq
+# ERROR-V8M: :[[@LINE-1]]:1: error
+
+qadd r0, r1, r2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_FP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-4]]:1: error
+
+vadd.f16 s0, s1, s2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
+
+vabs.f32 s0, s1
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-4]]:1: error
+
+vcmp.f64 d0,d1
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_MVE: :[[@LINE-5]]:1: error
+# ERROR-V81M_MVE_FP: :[[@LINE-6]]:1: error
+# ERROR-V81M_MVEFP: :[[@LINE-7]]:1: error
+
+asrl r0, r1, r2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
+
+vcadd.i8 q0, q1, q2, #90
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_DSP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FP: :[[@LINE-4]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-5]]:1: error
Index: cfe/trunk/test/Driver/armv8.1m.main.c
===
--- cfe/trunk/test/Driver/armv8.1m.main.c
+++ cfe/trunk/test/Driver/armv8.1m.main.c
@@ -0,0 +1,34 @@
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+dsp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-DSP < %t %s
+// CHECK-DSP: "-target-feature" "+dsp"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-FP < %t %s
+// CHECK-FP: "-target-feature" "+fp-armv8"
+// CHECK-FP-NOT: "-target-feature" "+fp64"
+// CHECK-FP-NOT: "-target-feature" "+d32"
+// CHECK-FP: "-target-feature" "+fullfp16"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp.dp  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-FPDP < %t %s
+// CHECK-FPDP: "-target-feature" "+fp-armv8"
+// CHECK-FPDP: "-target-feature" "+fullfp16"
+// CHECK-FPDP: "-target-feature" "+fp64"
+// CHECK-FPDP-NOT: "-target-feature" "+d32"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve  -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVE < %t %s
+// CHECK-MVE: "-target-feature" "+mve"
+
+// RUN: %clang -target 

r362096 - [ARM] Add CLI support for Armv8.1-M and MVE

2019-05-30 Thread Sjoerd Meijer via cfe-commits
Author: sjoerdmeijer
Date: Thu May 30 07:22:26 2019
New Revision: 362096

URL: http://llvm.org/viewvc/llvm-project?rev=362096=rev
Log:
[ARM] Add CLI support for Armv8.1-M and MVE

Given the existing infrastructure in LLVM side for +fp and +fp.dp,
this is more or less trivial, needing only one tiny source change and
a couple of tests.

Patch by Simon Tatham.

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

Added:
cfe/trunk/test/Driver/armv8.1m.main.c
cfe/trunk/test/Driver/armv8.1m.main.s
Modified:
cfe/trunk/lib/Basic/Targets/ARM.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARM.cpp?rev=362096=362095=362096=diff
==
--- cfe/trunk/lib/Basic/Targets/ARM.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARM.cpp Thu May 30 07:22:26 2019
@@ -197,6 +197,8 @@ StringRef ARMTargetInfo::getCPUAttr() co
 return "8M_MAIN";
   case llvm::ARM::ArchKind::ARMV8R:
 return "8R";
+  case llvm::ARM::ArchKind::ARMV8_1MMainline:
+return "8_1M_MAIN";
   }
 }
 

Added: cfe/trunk/test/Driver/armv8.1m.main.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/armv8.1m.main.c?rev=362096=auto
==
--- cfe/trunk/test/Driver/armv8.1m.main.c (added)
+++ cfe/trunk/test/Driver/armv8.1m.main.c Thu May 30 07:22:26 2019
@@ -0,0 +1,34 @@
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+dsp  -### %s 2> 
%t
+// RUN: FileCheck --check-prefix=CHECK-DSP < %t %s
+// CHECK-DSP: "-target-feature" "+dsp"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp  -### %s 2> 
%t
+// RUN: FileCheck --check-prefix=CHECK-FP < %t %s
+// CHECK-FP: "-target-feature" "+fp-armv8"
+// CHECK-FP-NOT: "-target-feature" "+fp64"
+// CHECK-FP-NOT: "-target-feature" "+d32"
+// CHECK-FP: "-target-feature" "+fullfp16"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+fp.dp  -### %s 
2> %t
+// RUN: FileCheck --check-prefix=CHECK-FPDP < %t %s
+// CHECK-FPDP: "-target-feature" "+fp-armv8"
+// CHECK-FPDP: "-target-feature" "+fullfp16"
+// CHECK-FPDP: "-target-feature" "+fp64"
+// CHECK-FPDP-NOT: "-target-feature" "+d32"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve  -### %s 2> 
%t
+// RUN: FileCheck --check-prefix=CHECK-MVE < %t %s
+// CHECK-MVE: "-target-feature" "+mve"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp  -### %s 
2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVEFP < %t %s
+// CHECK-MVEFP: "-target-feature" "+mve.fp"
+// CHECK-MVEFP-NOT: "-target-feature" "+fp64"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp  
-### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-MVEFP_DP < %t %s
+// CHECK-MVEFP_DP: "-target-feature" "+mve.fp"
+// CHECK-MVEFP_DP: "-target-feature" "+fp64"
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv8.1m.main+fp -S %s
+double foo (double a) { return a; }

Added: cfe/trunk/test/Driver/armv8.1m.main.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/armv8.1m.main.s?rev=362096=auto
==
--- cfe/trunk/test/Driver/armv8.1m.main.s (added)
+++ cfe/trunk/test/Driver/armv8.1m.main.s Thu May 30 07:22:26 2019
@@ -0,0 +1,65 @@
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V8M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main %s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+dsp %s 
2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_DSP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp %s 
2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+fp.dp %s 
2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_FPDP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve %s 
2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve+fp 
%s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVE_FP < %t %s
+# RUN: not %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp 
%s 2>%t
+# RUN:  FileCheck --check-prefix=ERROR-V81M_MVEFP < %t %s
+# RUN: %clang -c -target arm-none-none-eabi -march=armv8.1-m.main+mve.fp+fp.dp 
%s
+
+.syntax unified
+.thumb
+.text
+
+csinc r0, r1, r2, eq
+# ERROR-V8M: :[[@LINE-1]]:1: error
+
+qadd r0, r1, r2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: :[[@LINE-2]]:1: error
+# ERROR-V81M_FP: :[[@LINE-3]]:1: error
+# ERROR-V81M_FPDP: :[[@LINE-4]]:1: error
+
+vadd.f16 s0, s1, s2
+# ERROR-V8M: :[[@LINE-1]]:1: error
+# ERROR-V81M: 

Re: r361997 - [analyzer] print() JSONify: getNodeLabel implementation

2019-05-30 Thread Russell Gallop via cfe-commits
Hi Csaba,

Failing example attached. Note that the output is different every time so
there is potentially more than one failure mode.

Thanks
Russ

On Thu, 30 May 2019 at 15:05, Csaba Dabis  wrote:

> Hey!
>
> When it fails, could you provide the DOT dump? The path
> is: 
> llvm-project/build/tools/clang/test/Analysis/Output/dump_egraph.cpp.tmp.dot
>
> Thanks,
> Csaba.
>
> On Thu, May 30, 2019 at 4:00 PM Russell Gallop 
> wrote:
>
>> Hi Csaba,
>>
>> The test dump_egraph.cpp appears to be flaky on Windows. For example
>> here:
>> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26183
>> .
>>
>> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Analysis\dump_egraph.cpp:23:11:
>> error: CHECK: expected string not found in input
>> // CHECK: \"store\": [\l\{
>> \"cluster\": \"t\", \"items\":
>> [\l\{ \"kind\":
>> \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, #1\}\"
>>
>> Running locally, it fails after 2-5 runs for me, running:
>> python bin/llvm-lit.py -v ../clang/test/Analysis/dump_egraph.cpp
>>
>> Please could you take a look?
>>
>> Note that I'm not certain it was this commit that started the flakiness,
>> it is the latest which changed the failing line.
>>
>> Thanks
>> Russ
>>
>> On Wed, 29 May 2019 at 19:02, Csaba Dabis via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: charusso
>>> Date: Wed May 29 11:05:53 2019
>>> New Revision: 361997
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=361997=rev
>>> Log:
>>> [analyzer] print() JSONify: getNodeLabel implementation
>>>
>>> Summary: This patch also rewrites the ProgramPoint printing.
>>>
>>> Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
>>>
>>> Reviewed By: NoQ
>>>
>>> Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho,
>>>  donat.nagy, dkrupp
>>>
>>> Tags: #clang
>>>
>>> Differential Revision: https://reviews.llvm.org/D62346
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Analysis/ProgramPoint.h
>>> cfe/trunk/lib/Analysis/ProgramPoint.cpp
>>> cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
>>> cfe/trunk/test/Analysis/dump_egraph.c
>>> cfe/trunk/test/Analysis/dump_egraph.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=361997=361996=361997=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
>>> +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Wed May 29 11:05:53
>>> 2019
>>> @@ -213,7 +213,7 @@ public:
>>>  ID.AddPointer(getTag());
>>>}
>>>
>>> -  void print(StringRef CR, llvm::raw_ostream ) const;
>>> +  void printJson(llvm::raw_ostream , const char *NL = "\n") const;
>>>
>>>LLVM_DUMP_METHOD void dump() const;
>>>
>>>
>>> Modified: cfe/trunk/lib/Analysis/ProgramPoint.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ProgramPoint.cpp?rev=361997=361996=361997=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Analysis/ProgramPoint.cpp (original)
>>> +++ cfe/trunk/lib/Analysis/ProgramPoint.cpp Wed May 29 11:05:53 2019
>>> @@ -43,151 +43,152 @@ ProgramPoint ProgramPoint::getProgramPoi
>>>  }
>>>
>>>  LLVM_DUMP_METHOD void ProgramPoint::dump() const {
>>> -  return print(/*CR=*/"\n", llvm::errs());
>>> +  return printJson(llvm::errs());
>>>  }
>>>
>>> -static void printLocation(raw_ostream , SourceLocation SLoc,
>>> -  const SourceManager ,
>>> -  StringRef CR,
>>> -  StringRef Postfix) {
>>> -  if (SLoc.isFileID()) {
>>> -Out << CR << "line=" << SM.getExpansionLineNumber(SLoc)
>>> -<< " col=" << SM.getExpansionColumnNumber(SLoc) << Postfix;
>>> +static void printLocation(raw_ostream , SourceLocation Loc,
>>> +  const SourceManager ) {
>>> +  Out << "\"location\": ";
>>> +  if (!Loc.isFileID()) {
>>> +Out << "null";
>>> +return;
>>>}
>>> +
>>> +  Out << "{ \"line\": " << SM.getExpansionLineNumber(Loc)
>>> +  << ", \"column\": " << SM.getExpansionColumnNumber(Loc) << " }";
>>>  }
>>>
>>> -void ProgramPoint::print(StringRef CR, llvm::raw_ostream ) const {
>>> +void ProgramPoint::printJson(llvm::raw_ostream , const char *NL)
>>> const {
>>>const ASTContext  =
>>>getLocationContext()->getAnalysisDeclContext()->getASTContext();
>>>const SourceManager  = Context.getSourceManager();
>>> +
>>> +  Out << "\"kind\": \"";
>>>switch (getKind()) {
>>>case ProgramPoint::BlockEntranceKind:
>>> -Out << "Block Entrance: B"
>>> +Out << "BlockEntrance\""
>>> +<< ", \"block_id\": "
>>>  << castAs().getBlock()->getBlockID();
>>>  break;
>>>
>>>case 

[PATCH] D62035: [AST] const-ify ObjC inherited class search

2019-05-30 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

I don't really have much to say about this, and the patch is probably fine, but 
I do note that most of the other accessors on this class also return mutable 
objects.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62035



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


[PATCH] D43576: Solution to fix PR27066 - Redefinition with same mangled name as another definition (dllexport and uuid)

2019-05-30 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a comment.

A review please :-) Thanks.


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

https://reviews.llvm.org/D43576



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


Re: r361997 - [analyzer] print() JSONify: getNodeLabel implementation

2019-05-30 Thread Csaba Dabis via cfe-commits
Hey!

When it fails, could you provide the DOT dump? The path
is: llvm-project/build/tools/clang/test/Analysis/Output/dump_egraph.cpp.tmp.dot

Thanks,
Csaba.

On Thu, May 30, 2019 at 4:00 PM Russell Gallop 
wrote:

> Hi Csaba,
>
> The test dump_egraph.cpp appears to be flaky on Windows. For example here:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26183
> .
>
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Analysis\dump_egraph.cpp:23:11:
> error: CHECK: expected string not found in input
> // CHECK: \"store\": [\l\{
> \"cluster\": \"t\", \"items\":
> [\l\{ \"kind\":
> \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no stmt, #1\}\"
>
> Running locally, it fails after 2-5 runs for me, running:
> python bin/llvm-lit.py -v ../clang/test/Analysis/dump_egraph.cpp
>
> Please could you take a look?
>
> Note that I'm not certain it was this commit that started the flakiness,
> it is the latest which changed the failing line.
>
> Thanks
> Russ
>
> On Wed, 29 May 2019 at 19:02, Csaba Dabis via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: charusso
>> Date: Wed May 29 11:05:53 2019
>> New Revision: 361997
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=361997=rev
>> Log:
>> [analyzer] print() JSONify: getNodeLabel implementation
>>
>> Summary: This patch also rewrites the ProgramPoint printing.
>>
>> Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
>>
>> Reviewed By: NoQ
>>
>> Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho,
>>  donat.nagy, dkrupp
>>
>> Tags: #clang
>>
>> Differential Revision: https://reviews.llvm.org/D62346
>>
>> Modified:
>> cfe/trunk/include/clang/Analysis/ProgramPoint.h
>> cfe/trunk/lib/Analysis/ProgramPoint.cpp
>> cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
>> cfe/trunk/test/Analysis/dump_egraph.c
>> cfe/trunk/test/Analysis/dump_egraph.cpp
>>
>> Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=361997=361996=361997=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
>> +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Wed May 29 11:05:53
>> 2019
>> @@ -213,7 +213,7 @@ public:
>>  ID.AddPointer(getTag());
>>}
>>
>> -  void print(StringRef CR, llvm::raw_ostream ) const;
>> +  void printJson(llvm::raw_ostream , const char *NL = "\n") const;
>>
>>LLVM_DUMP_METHOD void dump() const;
>>
>>
>> Modified: cfe/trunk/lib/Analysis/ProgramPoint.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ProgramPoint.cpp?rev=361997=361996=361997=diff
>>
>> ==
>> --- cfe/trunk/lib/Analysis/ProgramPoint.cpp (original)
>> +++ cfe/trunk/lib/Analysis/ProgramPoint.cpp Wed May 29 11:05:53 2019
>> @@ -43,151 +43,152 @@ ProgramPoint ProgramPoint::getProgramPoi
>>  }
>>
>>  LLVM_DUMP_METHOD void ProgramPoint::dump() const {
>> -  return print(/*CR=*/"\n", llvm::errs());
>> +  return printJson(llvm::errs());
>>  }
>>
>> -static void printLocation(raw_ostream , SourceLocation SLoc,
>> -  const SourceManager ,
>> -  StringRef CR,
>> -  StringRef Postfix) {
>> -  if (SLoc.isFileID()) {
>> -Out << CR << "line=" << SM.getExpansionLineNumber(SLoc)
>> -<< " col=" << SM.getExpansionColumnNumber(SLoc) << Postfix;
>> +static void printLocation(raw_ostream , SourceLocation Loc,
>> +  const SourceManager ) {
>> +  Out << "\"location\": ";
>> +  if (!Loc.isFileID()) {
>> +Out << "null";
>> +return;
>>}
>> +
>> +  Out << "{ \"line\": " << SM.getExpansionLineNumber(Loc)
>> +  << ", \"column\": " << SM.getExpansionColumnNumber(Loc) << " }";
>>  }
>>
>> -void ProgramPoint::print(StringRef CR, llvm::raw_ostream ) const {
>> +void ProgramPoint::printJson(llvm::raw_ostream , const char *NL)
>> const {
>>const ASTContext  =
>>getLocationContext()->getAnalysisDeclContext()->getASTContext();
>>const SourceManager  = Context.getSourceManager();
>> +
>> +  Out << "\"kind\": \"";
>>switch (getKind()) {
>>case ProgramPoint::BlockEntranceKind:
>> -Out << "Block Entrance: B"
>> +Out << "BlockEntrance\""
>> +<< ", \"block_id\": "
>>  << castAs().getBlock()->getBlockID();
>>  break;
>>
>>case ProgramPoint::FunctionExitKind: {
>>  auto FEP = getAs();
>> -Out << "Function Exit: B" << FEP->getBlock()->getBlockID();
>> +Out << "FunctionExit\""
>> +<< ", \"block_id\": " << FEP->getBlock()->getBlockID()
>> +<< ", \"stmt_id\": ";
>> +
>>  if (const ReturnStmt *RS = FEP->getStmt()) {
>> -  Out << CR << " Return: S" << 

Re: r361997 - [analyzer] print() JSONify: getNodeLabel implementation

2019-05-30 Thread Russell Gallop via cfe-commits
Hi Csaba,

The test dump_egraph.cpp appears to be flaky on Windows. For example here:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26183
.

C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Analysis\dump_egraph.cpp:23:11:
error: CHECK: expected string not found in input
// CHECK: \"store\": [\l\{ \"cluster\":
\"t\", \"items\": [\l\{
\"kind\": \"Default\", \"offset\": 0, \"value\": \"conj_$3\{int, LC3, no
stmt, #1\}\"

Running locally, it fails after 2-5 runs for me, running:
python bin/llvm-lit.py -v ../clang/test/Analysis/dump_egraph.cpp

Please could you take a look?

Note that I'm not certain it was this commit that started the flakiness, it
is the latest which changed the failing line.

Thanks
Russ

On Wed, 29 May 2019 at 19:02, Csaba Dabis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: charusso
> Date: Wed May 29 11:05:53 2019
> New Revision: 361997
>
> URL: http://llvm.org/viewvc/llvm-project?rev=361997=rev
> Log:
> [analyzer] print() JSONify: getNodeLabel implementation
>
> Summary: This patch also rewrites the ProgramPoint printing.
>
> Reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, Szelethus
>
> Reviewed By: NoQ
>
> Subscribers: cfe-commits, szepet, rnkovacs, a.sidorin, mikhail.ramalho,
>  donat.nagy, dkrupp
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D62346
>
> Modified:
> cfe/trunk/include/clang/Analysis/ProgramPoint.h
> cfe/trunk/lib/Analysis/ProgramPoint.cpp
> cfe/trunk/lib/StaticAnalyzer/Core/ExprEngine.cpp
> cfe/trunk/test/Analysis/dump_egraph.c
> cfe/trunk/test/Analysis/dump_egraph.cpp
>
> Modified: cfe/trunk/include/clang/Analysis/ProgramPoint.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/ProgramPoint.h?rev=361997=361996=361997=diff
>
> ==
> --- cfe/trunk/include/clang/Analysis/ProgramPoint.h (original)
> +++ cfe/trunk/include/clang/Analysis/ProgramPoint.h Wed May 29 11:05:53
> 2019
> @@ -213,7 +213,7 @@ public:
>  ID.AddPointer(getTag());
>}
>
> -  void print(StringRef CR, llvm::raw_ostream ) const;
> +  void printJson(llvm::raw_ostream , const char *NL = "\n") const;
>
>LLVM_DUMP_METHOD void dump() const;
>
>
> Modified: cfe/trunk/lib/Analysis/ProgramPoint.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/ProgramPoint.cpp?rev=361997=361996=361997=diff
>
> ==
> --- cfe/trunk/lib/Analysis/ProgramPoint.cpp (original)
> +++ cfe/trunk/lib/Analysis/ProgramPoint.cpp Wed May 29 11:05:53 2019
> @@ -43,151 +43,152 @@ ProgramPoint ProgramPoint::getProgramPoi
>  }
>
>  LLVM_DUMP_METHOD void ProgramPoint::dump() const {
> -  return print(/*CR=*/"\n", llvm::errs());
> +  return printJson(llvm::errs());
>  }
>
> -static void printLocation(raw_ostream , SourceLocation SLoc,
> -  const SourceManager ,
> -  StringRef CR,
> -  StringRef Postfix) {
> -  if (SLoc.isFileID()) {
> -Out << CR << "line=" << SM.getExpansionLineNumber(SLoc)
> -<< " col=" << SM.getExpansionColumnNumber(SLoc) << Postfix;
> +static void printLocation(raw_ostream , SourceLocation Loc,
> +  const SourceManager ) {
> +  Out << "\"location\": ";
> +  if (!Loc.isFileID()) {
> +Out << "null";
> +return;
>}
> +
> +  Out << "{ \"line\": " << SM.getExpansionLineNumber(Loc)
> +  << ", \"column\": " << SM.getExpansionColumnNumber(Loc) << " }";
>  }
>
> -void ProgramPoint::print(StringRef CR, llvm::raw_ostream ) const {
> +void ProgramPoint::printJson(llvm::raw_ostream , const char *NL)
> const {
>const ASTContext  =
>getLocationContext()->getAnalysisDeclContext()->getASTContext();
>const SourceManager  = Context.getSourceManager();
> +
> +  Out << "\"kind\": \"";
>switch (getKind()) {
>case ProgramPoint::BlockEntranceKind:
> -Out << "Block Entrance: B"
> +Out << "BlockEntrance\""
> +<< ", \"block_id\": "
>  << castAs().getBlock()->getBlockID();
>  break;
>
>case ProgramPoint::FunctionExitKind: {
>  auto FEP = getAs();
> -Out << "Function Exit: B" << FEP->getBlock()->getBlockID();
> +Out << "FunctionExit\""
> +<< ", \"block_id\": " << FEP->getBlock()->getBlockID()
> +<< ", \"stmt_id\": ";
> +
>  if (const ReturnStmt *RS = FEP->getStmt()) {
> -  Out << CR << " Return: S" << RS->getID(Context) << CR;
> -  RS->printPretty(Out, /*helper=*/nullptr,
> Context.getPrintingPolicy(),
> -  /*Indentation=*/2, /*NewlineSymbol=*/CR);
> +  Out << RS->getID(Context) << ", \"stmt\": \"";
> +  RS->printPretty(Out, /*Helper=*/nullptr,
> Context.getPrintingPolicy());
> +  Out << '\"';
> +} else {
> +  Out << "null, 

[PATCH] D62657: [OpenCL] Fix OpenCL/SPIR version metadata

2019-05-30 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added a comment.
This revision is now accepted and ready to land.

LGTM!


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

https://reviews.llvm.org/D62657



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


[PATCH] D62658: [analyzer] print() JSONify: ExplodedNode revision

2019-05-30 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso created this revision.
Charusso added reviewers: NoQ, xazax.hun, ravikandhadai, baloghadamsoftware, 
Szelethus.
Charusso added a project: clang.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, rnkovacs, szepet.

Revert node-ID removal.


Repository:
  rC Clang

https://reviews.llvm.org/D62658

Files:
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp


Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -3075,8 +3075,8 @@
 const unsigned int Space = 1;
 ProgramStateRef State = N->getState();
 
-Out << "{ \"node_id\": \"" << (const void *)N
-<< "\", \"state_id\": " << State->getID()
+Out << "{ \"node_id\": " << N->getID(G) << ", \"pointer\": \""
+<< (const void *)N << "\", \"state_id\": " << State->getID()
 << ", \"has_report\": " << (nodeHasBugReport(N) ? "true" : "false")
 << ",\\l";
 
@@ -3094,7 +3094,7 @@
   else
 Out << "null }";
 },
-   // Adds a comma and a new-line between each program point.
+// Adds a comma and a new-line between each program point.
 [&](const ExplodedNode *) { Out << ",\\l"; },
 [&](const ExplodedNode *) { return false; });
 


Index: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -3075,8 +3075,8 @@
 const unsigned int Space = 1;
 ProgramStateRef State = N->getState();
 
-Out << "{ \"node_id\": \"" << (const void *)N
-<< "\", \"state_id\": " << State->getID()
+Out << "{ \"node_id\": " << N->getID(G) << ", \"pointer\": \""
+<< (const void *)N << "\", \"state_id\": " << State->getID()
 << ", \"has_report\": " << (nodeHasBugReport(N) ? "true" : "false")
 << ",\\l";
 
@@ -3094,7 +3094,7 @@
   else
 Out << "null }";
 },
-	// Adds a comma and a new-line between each program point.
+// Adds a comma and a new-line between each program point.
 [&](const ExplodedNode *) { Out << ",\\l"; },
 [&](const ExplodedNode *) { return false; });
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62654: [Docs] Modernize references to macOS

2019-05-30 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists added a comment.

I'm fine with the libc++ changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62654



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


[PATCH] D62657: [OpenCL] Fix OpenCL/SPIR version metadata

2019-05-30 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia created this revision.
Anastasia added a reviewer: svenvh.
Herald added subscribers: ebevhan, yaxunl.

C++ is derived from OpenCL v2.0 therefore set the versions to the same.

In the future we might need to add extra version for CXX.


https://reviews.llvm.org/D62657

Files:
  lib/CodeGen/CodeGenModule.cpp
  test/CodeGenOpenCL/spir_version.cl


Index: test/CodeGenOpenCL/spir_version.cl
===
--- test/CodeGenOpenCL/spir_version.cl
+++ test/CodeGenOpenCL/spir_version.cl
@@ -5,6 +5,9 @@
 // RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
 // RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
 
+
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - 
-cl-std=c++ | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-AMDGCN-CL10
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL1.2 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL12
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL2.0 | 
FileCheck %s --check-prefix=CHECK-AMDGCN-CL20
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -559,11 +559,13 @@
 if (getTriple().isSPIR()) {
   // SPIR v2.0 s2.12 - The SPIR version used by the module is stored in the
   // opencl.spir.version named metadata.
+  // C++ is backwards compatible with v2.0.
+  auto Version = LangOpts.OpenCLCPlusPlus ? 200 : LangOpts.OpenCLVersion;
   llvm::Metadata *SPIRVerElts[] = {
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, LangOpts.OpenCLVersion / 100)),
+  Int32Ty, Version / 100)),
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, (LangOpts.OpenCLVersion / 100 > 1) ? 0 : 2))};
+  Int32Ty, (Version / 100 > 1) ? 0 : 2))};
   llvm::NamedMDNode *SPIRVerMD =
   TheModule.getOrInsertNamedMetadata("opencl.spir.version");
   llvm::LLVMContext  = TheModule.getContext();
@@ -618,11 +620,14 @@
 void CodeGenModule::EmitOpenCLMetadata() {
   // SPIR v2.0 s2.13 - The OpenCL version used by the module is stored in the
   // opencl.ocl.version named metadata node.
+  // C++ is backwards compatible with v2.0.
+  // FIXME: We might need to add CXX version at some point too?
+  auto Version = LangOpts.OpenCLCPlusPlus ? 200 : LangOpts.OpenCLVersion;
   llvm::Metadata *OCLVerElts[] = {
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, LangOpts.OpenCLVersion / 100)),
+  Int32Ty, Version / 100)),
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, (LangOpts.OpenCLVersion % 100) / 10))};
+  Int32Ty, (Version % 100) / 10))};
   llvm::NamedMDNode *OCLVerMD =
   TheModule.getOrInsertNamedMetadata("opencl.ocl.version");
   llvm::LLVMContext  = TheModule.getContext();


Index: test/CodeGenOpenCL/spir_version.cl
===
--- test/CodeGenOpenCL/spir_version.cl
+++ test/CodeGenOpenCL/spir_version.cl
@@ -5,6 +5,9 @@
 // RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - -cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
 // RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - -cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20
 
+
+// RUN: %clang_cc1 %s -triple "spir64-unknown-unknown" -emit-llvm -o - -cl-std=c++ | FileCheck %s --check-prefix=CHECK-SPIR-CL20
+
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-AMDGCN-CL10
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-AMDGCN-CL12
 // RUN: %clang_cc1 %s -triple "amdgcn--amdhsa" -emit-llvm -o - -cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-AMDGCN-CL20
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -559,11 +559,13 @@
 if (getTriple().isSPIR()) {
   // SPIR v2.0 s2.12 - The SPIR version used by the module is stored in the
   // opencl.spir.version named metadata.
+  // C++ is backwards compatible with v2.0.
+  auto Version = LangOpts.OpenCLCPlusPlus ? 200 : LangOpts.OpenCLVersion;
   llvm::Metadata *SPIRVerElts[] = {
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, LangOpts.OpenCLVersion / 100)),
+  Int32Ty, Version / 100)),
   llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  Int32Ty, 

[PATCH] D61743: New clang option -MD-filter=prefix to filter files from make dependencies

2019-05-30 Thread Melanie Blower via Phabricator via cfe-commits
mibintc abandoned this revision.
mibintc added a comment.

I'll modify this to be a cc1 only option, there doesn't seem to be community 
interest.


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

https://reviews.llvm.org/D61743



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


[PATCH] D62588: [OpenCL] Support logical vector operators in C++ mode

2019-05-30 Thread Sven van Haastregt via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362087: [OpenCL] Support logical vector operators in C++ 
mode (authored by svenvh, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62588?vs=201897=202162#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62588

Files:
  cfe/trunk/lib/Sema/SemaExpr.cpp
  cfe/trunk/test/CodeGenOpenCL/logical-ops.cl


Index: cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
===
--- cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
+++ cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=CL1.2 -O1 -triple 
x86_64-unknown-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=c++ -O1 -triple 
x86_64-unknown-linux-gnu | FileCheck %s
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 
Index: cfe/trunk/lib/Sema/SemaExpr.cpp
===
--- cfe/trunk/lib/Sema/SemaExpr.cpp
+++ cfe/trunk/lib/Sema/SemaExpr.cpp
@@ -10902,7 +10902,7 @@
   if (vType.isNull())
 return InvalidOperands(Loc, LHS, RHS);
   if (getLangOpts().OpenCL && getLangOpts().OpenCLVersion < 120 &&
-  vType->hasFloatingRepresentation())
+  !getLangOpts().OpenCLCPlusPlus && vType->hasFloatingRepresentation())
 return InvalidOperands(Loc, LHS, RHS);
   // FIXME: The check for C++ here is for GCC compatibility. GCC rejects the
   //usage of the logical operators && and || with vectors in C. This
@@ -13165,7 +13165,8 @@
   }
 } else if (resultType->isExtVectorType()) {
   if (Context.getLangOpts().OpenCL &&
-  Context.getLangOpts().OpenCLVersion < 120) {
+  Context.getLangOpts().OpenCLVersion < 120 &&
+  !Context.getLangOpts().OpenCLCPlusPlus) {
 // OpenCL v1.1 6.3.h: The logical operator not (!) does not
 // operate on vector float types.
 QualType T = resultType->getAs()->getElementType();


Index: cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
===
--- cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
+++ cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=CL1.2 -O1 -triple x86_64-unknown-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=c++ -O1 -triple x86_64-unknown-linux-gnu | FileCheck %s
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 
Index: cfe/trunk/lib/Sema/SemaExpr.cpp
===
--- cfe/trunk/lib/Sema/SemaExpr.cpp
+++ cfe/trunk/lib/Sema/SemaExpr.cpp
@@ -10902,7 +10902,7 @@
   if (vType.isNull())
 return InvalidOperands(Loc, LHS, RHS);
   if (getLangOpts().OpenCL && getLangOpts().OpenCLVersion < 120 &&
-  vType->hasFloatingRepresentation())
+  !getLangOpts().OpenCLCPlusPlus && vType->hasFloatingRepresentation())
 return InvalidOperands(Loc, LHS, RHS);
   // FIXME: The check for C++ here is for GCC compatibility. GCC rejects the
   //usage of the logical operators && and || with vectors in C. This
@@ -13165,7 +13165,8 @@
   }
 } else if (resultType->isExtVectorType()) {
   if (Context.getLangOpts().OpenCL &&
-  Context.getLangOpts().OpenCLVersion < 120) {
+  Context.getLangOpts().OpenCLVersion < 120 &&
+  !Context.getLangOpts().OpenCLCPlusPlus) {
 // OpenCL v1.1 6.3.h: The logical operator not (!) does not
 // operate on vector float types.
 QualType T = resultType->getAs()->getElementType();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r362087 - [OpenCL] Support logical vector operators in C++ mode

2019-05-30 Thread Sven van Haastregt via cfe-commits
Author: svenvh
Date: Thu May 30 05:35:19 2019
New Revision: 362087

URL: http://llvm.org/viewvc/llvm-project?rev=362087=rev
Log:
[OpenCL] Support logical vector operators in C++ mode

Support logical operators on vectors in C++ for OpenCL mode, to
preserve backwards compatibility with OpenCL C.

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

Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/CodeGenOpenCL/logical-ops.cl

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=362087=362086=362087=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu May 30 05:35:19 2019
@@ -10902,7 +10902,7 @@ QualType Sema::CheckVectorLogicalOperand
   if (vType.isNull())
 return InvalidOperands(Loc, LHS, RHS);
   if (getLangOpts().OpenCL && getLangOpts().OpenCLVersion < 120 &&
-  vType->hasFloatingRepresentation())
+  !getLangOpts().OpenCLCPlusPlus && vType->hasFloatingRepresentation())
 return InvalidOperands(Loc, LHS, RHS);
   // FIXME: The check for C++ here is for GCC compatibility. GCC rejects the
   //usage of the logical operators && and || with vectors in C. This
@@ -13165,7 +13165,8 @@ ExprResult Sema::CreateBuiltinUnaryOp(So
   }
 } else if (resultType->isExtVectorType()) {
   if (Context.getLangOpts().OpenCL &&
-  Context.getLangOpts().OpenCLVersion < 120) {
+  Context.getLangOpts().OpenCLVersion < 120 &&
+  !Context.getLangOpts().OpenCLCPlusPlus) {
 // OpenCL v1.1 6.3.h: The logical operator not (!) does not
 // operate on vector float types.
 QualType T = resultType->getAs()->getElementType();

Modified: cfe/trunk/test/CodeGenOpenCL/logical-ops.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/logical-ops.cl?rev=362087=362086=362087=diff
==
--- cfe/trunk/test/CodeGenOpenCL/logical-ops.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/logical-ops.cl Thu May 30 05:35:19 2019
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=CL1.2 -O1 -triple 
x86_64-unknown-linux-gnu | FileCheck %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=c++ -O1 -triple 
x86_64-unknown-linux-gnu | FileCheck %s
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 


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


[PATCH] D62654: [Docs] Modernize references to macOS

2019-05-30 Thread J. Ryan Stinnett via Phabricator via cfe-commits
jryans created this revision.
jryans added a reviewer: JDevlieghere.
Herald added subscribers: llvm-commits, libcxx-commits, lldb-commits, 
cfe-commits, arphaman, christof, mgorny.
Herald added projects: clang, LLDB, libc++, LLVM.

This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.

If a specific version is mentioned, this attempts to use the OS name at the time
of that version:

- Mac OS X for 10.0 - 10.7
- OS X for 10.8 - 10.11
- macOS for 10.12 - present


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62654

Files:
  clang/docs/AddressSanitizer.rst
  clang/docs/AutomaticReferenceCounting.rst
  clang/docs/ClangCommandLineReference.rst
  clang/docs/CommandGuide/clang.rst
  clang/docs/LeakSanitizer.rst
  clang/docs/Modules.rst
  clang/docs/SafeStack.rst
  clang/docs/UndefinedBehaviorSanitizer.rst
  clang/docs/UsersManual.rst
  clang/docs/analyzer/checkers.rst
  clang/docs/analyzer/developer-docs/DebugChecks.rst
  libcxx/docs/BuildingLibcxx.rst
  libcxx/docs/UsingLibcxx.rst
  libcxx/docs/index.rst
  libunwind/docs/index.rst
  lld/docs/sphinx_intro.rst
  lldb/docs/lldb-gdb-remote.txt
  lldb/docs/resources/build.rst
  lldb/docs/use/remote.rst
  llvm/docs/CMake.rst
  llvm/docs/CommandGuide/llvm-ar.rst
  llvm/docs/CompilerWriterInfo.rst
  llvm/docs/DebuggingJITedCode.rst
  llvm/docs/GettingStarted.rst
  llvm/docs/ProgrammersManual.rst
  llvm/docs/TestingGuide.rst
  llvm/docs/WritingAnLLVMPass.rst

Index: llvm/docs/WritingAnLLVMPass.rst
===
--- llvm/docs/WritingAnLLVMPass.rst
+++ llvm/docs/WritingAnLLVMPass.rst
@@ -77,7 +77,7 @@
 is to be compiled and linked into a shared object ``$(LEVEL)/lib/LLVMHello.so`` that
 can be dynamically loaded by the :program:`opt` tool via its :option:`-load`
 option. If your operating system uses a suffix other than ``.so`` (such as
-Windows or Mac OS X), the appropriate extension will be used.
+Windows or macOS), the appropriate extension will be used.
 
 Now that we have the build scripts set up, we just need to write the code for
 the pass itself.
Index: llvm/docs/TestingGuide.rst
===
--- llvm/docs/TestingGuide.rst
+++ llvm/docs/TestingGuide.rst
@@ -511,7 +511,7 @@
The suffix for the host platforms shared library files. This includes the
period as the first character.
 
-   Example: ``.so`` (Linux), ``.dylib`` (OS X), ``.dll`` (Windows)
+   Example: ``.so`` (Linux), ``.dylib`` (macOS), ``.dll`` (Windows)
 
 ``%exeext``
The suffix for the host platforms executable files. This includes the
Index: llvm/docs/ProgrammersManual.rst
===
--- llvm/docs/ProgrammersManual.rst
+++ llvm/docs/ProgrammersManual.rst
@@ -1372,8 +1372,8 @@
 
 Getting this to work requires a small amount of setup.  On Unix systems
 with X11, install the `graphviz `_ toolkit, and make
-sure 'dot' and 'gv' are in your path.  If you are running on Mac OS X, download
-and install the Mac OS X `Graphviz program
+sure 'dot' and 'gv' are in your path.  If you are running on macOS, download
+and install the macOS `Graphviz program
 `_ and add
 ``/Applications/Graphviz.app/Contents/MacOS/`` (or wherever you install it) to
 your path. The programs need not be present when configuring, building or
Index: llvm/docs/GettingStarted.rst
===
--- llvm/docs/GettingStarted.rst
+++ llvm/docs/GettingStarted.rst
@@ -128,8 +128,8 @@
 FreeBSDamd64 GCC, Clang
 NetBSD x86\ :sup:`1` GCC, Clang
 NetBSD amd64 GCC, Clang
-MacOS X\ :sup:`2`  PowerPC   GCC
-MacOS Xx86   GCC, Clang
+macOS\ :sup:`2`PowerPC   GCC
+macOS  x86   GCC, Clang
 Cygwin/Win32   x86\ :sup:`1, 3`  GCC
 Windowsx86\ :sup:`1` Visual Studio
 Windows x64x86-64Visual Studio
@@ -272,7 +272,7 @@
 Getting a Modern Host C++ Toolchain
 ^^^
 
-This section mostly applies to Linux and older BSDs. On Mac OS X, you should
+This section mostly applies to Linux and older BSDs. On macOS, you should
 have a sufficiently modern Xcode, or you will likely need to upgrade until you
 do. Windows does not have a "system compiler", so you must install either Visual
 Studio 2015 or a recent version of mingw64. FreeBSD 10.0 and newer have a modern
@@ -711,7 +711,7 @@
 
 The result of such a build is executables that are not runnable on the build
 host but can be executed on the target. As an example the following CMake
-invocation can generate build files targeting iOS. This will work on Mac OS X
+invocation 

[PATCH] D62580: [OpenCL] Use long instead of long long in x86 builtins

2019-05-30 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

Do you think it's possible to add a test?


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

https://reviews.llvm.org/D62580



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


[PATCH] D60748: Fix i386 struct and union parameter alignment

2019-05-30 Thread Joerg Sonnenberger via Phabricator via cfe-commits
joerg added inline comments.



Comment at: lib/CodeGen/TargetInfo.cpp:1501
+//
+// Exclude other System V OS (e.g Darwin, PS4 and FreeBSD) since we don't
+// want to spend any effort dealing with the ramifications of ABI breaks.

krytarowski wrote:
> Darwin and BSD are not System V.
> 
> CC: @joerg @mgorny for NetBSD. Do we need to do something here?
It's a misnomer. The ABI standard for i386 was the SysV ABI before GNU decided 
to silently break the stack alignment and calling it the new ABI. That said, 
I'm not sure how much copy-by-value of vector types actually happens and that's 
the only situation affected by this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60748



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


Re: r361329 - [c++20] P1330R0: permit simple-assignments that change the active member

2019-05-30 Thread Stephan Bergmann via cfe-commits

On 22/05/2019 01:15, Richard Smith via cfe-commits wrote:

Author: rsmith
Date: Tue May 21 16:15:20 2019
New Revision: 361329

URL: http://llvm.org/viewvc/llvm-project?rev=361329=rev
Log:
[c++20] P1330R0: permit simple-assignments that change the active member
of a union within constant expression evaluation.

[...]

--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Tue May 21 16:15:20 2019

[...]> @@ -4888,6 +4916,159 @@ static bool HandleDynamicCast(EvalInfo &
[...]

+/// Handle a builtin simple-assignment or a call to a trivial assignment
+/// operator whose left-hand side might involve a union member access. If it
+/// does, implicitly start the lifetime of any accessed union elements per
+/// C++20 [class.union]5.
+static bool HandleUnionActiveMemberChange(EvalInfo , const Expr *LHSExpr,
+  const LValue ) {
+  if (LHS.InvalidBase || LHS.Designator.Invalid)
+return false;
+
+  llvm::SmallVector, 4> UnionPathLengths;
+  // C++ [class.union]p5:
+  //   define the set S(E) of subexpressions of E as follows:
+  const Expr *E = LHSExpr;
+  unsigned PathLength = LHS.Designator.Entries.size();
+  while (E) {
+//   -- If E is of the form A.B, S(E) contains the elements of S(A)...
+if (auto *ME = dyn_cast(E)) {
+  auto *FD = dyn_cast(ME->getMemberDecl());
+  if (!FD)
+break;
+
+  //... and also contains A.B if B names a union member
+  if (FD->getParent()->isUnion())
+UnionPathLengths.push_back({PathLength - 1, FD});
+
+  E = ME->getBase();
+  --PathLength;
+  assert(declaresSameEntity(FD,
+LHS.Designator.Entries[PathLength]
+.getAsBaseOrMember().getPointer()));
+
+  //   -- If E is of the form A[B] and is interpreted as a built-in array
+  //  subscripting operator, S(E) is [S(the array operand, if any)].
+} else if (auto *ASE = dyn_cast(E)) {
+  // Step over an ArrayToPointerDecay implicit cast.
+  auto *Base = ASE->getBase()->IgnoreImplicit();
+  if (!Base->getType()->isArrayType())
+break;
+
+  E = Base;
+  --PathLength;
+
+} else if (auto *ICE = dyn_cast(E)) {
+  // Step over a derived-to-base conversion.
+  if (ICE->getCastKind() == CK_NoOp)
+continue;
+  if (ICE->getCastKind() != CK_DerivedToBase &&
+  ICE->getCastKind() != CK_UncheckedDerivedToBase)
+break;
+  for (const CXXBaseSpecifier *Elt : ICE->path()) {
+--PathLength;
+assert(declaresSameEntity(Elt->getType()->getAsCXXRecordDecl(),
+  LHS.Designator.Entries[PathLength]
+  .getAsBaseOrMember().getPointer()));


the above assert fires for the below test.cc with `clang++ -std=c++2a 
-fsyntax-only test.cc`:



struct S1 { int n; };
struct S2: S1 {};
struct S3: S2 {};
void f() {
 S3 s;
 s.n = 0;
}

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


[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

2019-05-30 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added a comment.

Sorry for that much rewrite request but in a script language you have to name 
your stuff properly or you will be completely lost. I have not written a single 
Python class yet, but trust me.

I really like that `DotDumpVisitor` semantic, but it would be a lot better at 
SVG level. At the moment whatever style/table-data you insert it adds an extra 
text tag per styling which is quite inefficient.

We could use "foreignObject" (somehow) and apply pure HTML tables or I could 
use my `` idea instead 
(https://developer.mozilla.org/en-US/docs/Web/SVG/Element/tspan). I recommend 
the latter as it is better than a fixed table.

With the current representation it would be difficult to apply every styling to 
tspans. I think it also would be difficult to use your `Explorer` idea as we 
are talking about modificating the SVG dynamically.

In D62638#1522357 , @NoQ wrote:

> > I wrote some tests but i'm not really sure they're worth it.
>
> Mmm, on second thought, they probably won't work out of the box, because they 
> might require installing python modules in order to work. I'm actually not 
> sure if all machines have python3. I'll try but it'll most likely fail. I 
> guess i could try excluding them from `make check-all`.


It would be cool to introduce something like `check-scripts`.




Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:5
+import collections
+import json as json_module  # 'json' is a great name for a variable.
+import logging

I think it is not that cool variable name. I would use the appropiate name of 
the object instead of the generic `json` name.



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:12
+class SourceLocation(object):
+def __init__(self, json):
+super(SourceLocation, self).__init__()

`json` -> `loc`



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:22
+class ProgramPoint(object):
+def __init__(self, json):
+super(ProgramPoint, self).__init__()

`json` -> `program_point` and so on...



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:33
+self.pretty = json['pretty']
+self.sloc = SourceLocation(json['location']) \
+if json['location'] is not None else None

What about just `loc`?



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:124
+self.parents = []
+self.children = []
+

What about `predecessors` and `successors`? It is the proper name in the Static 
Analyzer world.



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:126
+
+def set_json(self, node_id, json):
+logging.debug('Adding ' + node_id)

- `set_json()` -> `set()` the given `node`
- `json` -> `node`



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:151
+super(ExplodedGraph, self).__init__()
+self.nodes = collections.defaultdict(ExplodedNode)
+self.root_id = None

`nodes` -> `graph`



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:184
+# even though in a valid dot file everything is escaped.
+raw_json = result[2].replace('\\l', '') \
+.replace('', '') \

`raw_json` -> `node_string` which will be a raw JSON after `loads()`.



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:191
+.replace('\\>', '>') \
+.rstrip(',')
+logging.debug(raw_json)

I have removed the trailing `,` from the end yesterday so `rstrip(',')` is not 
needed.

It would be cool to name the `result[]`, like: `pred_id = result[1]` and 
`succ_id = result[2]` or current/previous ID, or something like that.

I also would put the regexes into a function and you could write:
`pred_id, succ_id = parse_edge()` or something more simpler.

What is `result[0]` btw? That confused me a little-bit.



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:233
+else:
+color = 'cyan3'
+

It would be cool to put it into a "switch-statement" 
(https://stackoverflow.com/questions/60208/replacements-for-switch-statement-in-python).



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:237
+if p.sloc is not None:
+self._dump(''
+   '%s:%s:%s:'

I think tables are left aligned by default, so you could remove your left 
alignments.



Comment at: clang/utils/analyzer/exploded-graph-rewriter.py:326
+self._dump('Program point:')
+self._dump(''
+   '')

I would 

r362085 - Fix Wdocumentation warning. NFCI.

2019-05-30 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Thu May 30 03:44:36 2019
New Revision: 362085

URL: http://llvm.org/viewvc/llvm-project?rev=362085=rev
Log:
Fix Wdocumentation warning. NFCI.

Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerManager.h

Modified: cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerManager.h?rev=362085=362084=362085=diff
==
--- cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerManager.h (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/CheckerManager.h Thu May 30 
03:44:36 2019
@@ -410,7 +410,6 @@ public:
   /// \param Out   The output stream
   /// \param State The state being printed
   /// \param NLThe preferred representation of a newline.
-  /// \param Sep   The preferred separator between different messages.
   /// \param Space The preferred space between the left side and the message.
   /// \param IsDot Whether the message will be printed in 'dot' format.
   void runCheckersForPrintStateJson(raw_ostream , ProgramStateRef State,


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


[PATCH] D60499: [ASTImporter] Various source location and range import fixes.

2019-05-30 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

It looks like that the same test can be applied as in D60463 
 but check only the first line of the AST 
dump. The first line contains information about the actual Decl only. This 
checks less than checking the full AST dump but finds some of wrong 
`SourceLocation` import. The problem is that the test can not be added yet 
because there are other failures. At least one new patch is needed with 
corrections related to import of `TypeSourceInfo`. Anyway this change (and the 
others) can not be added together with the test because multiple patches 
(including this) are needed to make the test not fail.

Source locations can be observed here:
http://ce.steveire.com/z/WB9VAu


Repository:
  rC Clang

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

https://reviews.llvm.org/D60499



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


Re: r362067 - asm goto: fix out-of-bounds read of Constraints after rC362045

2019-05-30 Thread Fāng-ruì Sòng via cfe-commits
You beat me to it.. Reverted

On Thu, May 30, 2019 at 5:41 PM Benjamin Kramer  wrote:

> Is this still necessary after r362062?
>
> On Thu, May 30, 2019 at 10:00 AM Fangrui Song via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: maskray
>> Date: Thu May 30 01:03:02 2019
>> New Revision: 362067
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=362067=rev
>> Log:
>> asm goto: fix out-of-bounds read of Constraints after rC362045
>>
>> When parsing goto labels, Names and Exprs are expanded but Constraints
>> is not, this may cause a out-of-bounds read later in:
>>
>> // GCCAsmStmt::GCCAsmStmt
>> // `constraints` has only `NumExprs - NumLabels` elements
>>   Constraints = new (C) StringLiteral*[NumExprs];
>>   std::copy(constraints, constraints + NumExprs, Constraints);
>>
>> Modified:
>> cfe/trunk/lib/Parse/ParseStmtAsm.cpp
>>
>> Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=362067=362066=362067=diff
>>
>> ==
>> --- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
>> +++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Thu May 30 01:03:02 2019
>> @@ -846,6 +846,7 @@ StmtResult Parser::ParseAsmStatement(boo
>>ExprResult Res =
>>Actions.ActOnAddrLabel(Tok.getLocation(), Tok.getLocation(),
>> LD);
>>Exprs.push_back(Res.get());
>> +  Constraints.emplace_back();
>>NumLabels++;
>>ConsumeToken();
>>if (!TryConsumeToken(tok::comma))
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>

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


r362079 - Revert "asm goto: fix out-of-bounds read of Constraints after rC362045"

2019-05-30 Thread Fangrui Song via cfe-commits
Author: maskray
Date: Thu May 30 03:05:52 2019
New Revision: 362079

URL: http://llvm.org/viewvc/llvm-project?rev=362079=rev
Log:
Revert "asm goto: fix out-of-bounds read of Constraints after rC362045"

It was fixed by rC362062.

Modified:
cfe/trunk/lib/Parse/ParseStmtAsm.cpp

Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=362079=362078=362079=diff
==
--- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Thu May 30 03:05:52 2019
@@ -846,7 +846,6 @@ StmtResult Parser::ParseAsmStatement(boo
   ExprResult Res =
   Actions.ActOnAddrLabel(Tok.getLocation(), Tok.getLocation(), LD);
   Exprs.push_back(Res.get());
-  Constraints.emplace_back();
   NumLabels++;
   ConsumeToken();
   if (!TryConsumeToken(tok::comma))


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


Re: r362067 - asm goto: fix out-of-bounds read of Constraints after rC362045

2019-05-30 Thread Benjamin Kramer via cfe-commits
Is this still necessary after r362062?

On Thu, May 30, 2019 at 10:00 AM Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: maskray
> Date: Thu May 30 01:03:02 2019
> New Revision: 362067
>
> URL: http://llvm.org/viewvc/llvm-project?rev=362067=rev
> Log:
> asm goto: fix out-of-bounds read of Constraints after rC362045
>
> When parsing goto labels, Names and Exprs are expanded but Constraints
> is not, this may cause a out-of-bounds read later in:
>
> // GCCAsmStmt::GCCAsmStmt
> // `constraints` has only `NumExprs - NumLabels` elements
>   Constraints = new (C) StringLiteral*[NumExprs];
>   std::copy(constraints, constraints + NumExprs, Constraints);
>
> Modified:
> cfe/trunk/lib/Parse/ParseStmtAsm.cpp
>
> Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=362067=362066=362067=diff
>
> ==
> --- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
> +++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Thu May 30 01:03:02 2019
> @@ -846,6 +846,7 @@ StmtResult Parser::ParseAsmStatement(boo
>ExprResult Res =
>Actions.ActOnAddrLabel(Tok.getLocation(), Tok.getLocation(),
> LD);
>Exprs.push_back(Res.get());
> +  Constraints.emplace_back();
>NumLabels++;
>ConsumeToken();
>if (!TryConsumeToken(tok::comma))
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r362076 - Fix MSVC "not all control paths return a value" warning.

2019-05-30 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Thu May 30 02:39:45 2019
New Revision: 362076

URL: http://llvm.org/viewvc/llvm-project?rev=362076=rev
Log:
Fix MSVC "not all control paths return a value" warning.

Modified:
cfe/trunk/include/clang/Basic/ObjCRuntime.h

Modified: cfe/trunk/include/clang/Basic/ObjCRuntime.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/ObjCRuntime.h?rev=362076=362075=362076=diff
==
--- cfe/trunk/include/clang/Basic/ObjCRuntime.h (original)
+++ cfe/trunk/include/clang/Basic/ObjCRuntime.h Thu May 30 02:39:45 2019
@@ -443,6 +443,7 @@ public:
 case WatchOS:
   return true;
 }
+llvm_unreachable("bad kind");
   }
 
   /// Try to parse an Objective-C runtime specification from the given


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


[PATCH] D60763: Prototype OpenCL BIFs using Tablegen

2019-05-30 Thread Alexey Sotkin via Phabricator via cfe-commits
AlexeySotkin added inline comments.



Comment at: clang/include/clang/Basic/OpenCLBuiltins.td:298-302
+def write_imagef : Builtin<"write_imagef",
+[void_t,
+  image2d_WO_t,
+  VectorType,
+  VectorType]>;

Pierre wrote:
> AlexeySotkin wrote:
> > It seems like there is something wrong with access qualifiers for images. I 
> > have applied this patch and tried to compile the following code:
> > 
> > ```
> > typedef int int2 __attribute__((ext_vector_type(2)));
> > typedef float float4 __attribute__((ext_vector_type(4)));
> > 
> > void kernel k(write_only image2d_t image, int2 coord, float4 data) {
> >   write_imagef(image, coord, data);
> > }
> > 
> > ```
> > I got the following output:
> > ```
> > clang -cc1 -triple spir /work/tmp/tmp.cl -emit-llvm -o -  
> > -fadd-opencl-builtins
> > /work/tmp/tmp.cl:5:16: error: passing '__write_only image2d_t' to parameter 
> > of incompatible type '__read_only image2d_t'
> >   write_imagef(image, coord, data);
> >  ^
> > 1 error generated.
> > ```
> What you are saying is right. This patch is incomplete and some features are 
> missing/ broken. 
> I have a new version of the tablegen builtin feature where the access 
> qualifiers are actually taken into account, but I cannot extract only this 
> from my version. This would imply uploading the whole new version. 
> The new version will hopefully be on top of this patch, making access 
> qualifiers work.
Thanks, Pierre. I'd like to start early testing of image builtins with this 
prototype. Do you have an idea when you will have image builtins done in this 
(or other) patch?
If it is not going to happen in the nearest future, would you mind if I'll 
propose some changes for this patch/prototype meanwhile?


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

https://reviews.llvm.org/D60763



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


[PATCH] D62623: Reduce memory consumption of coverage dumps

2019-05-30 Thread serge via Phabricator via cfe-commits
serge-sans-paille added a comment.

@kwk: looks like you're still compiling with clang-7, this patch is to be 
applied on the master version of LLVM/clang, then you can install it and use it 
to recompile llvm/lld with coverage info.

Does it make sense to you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62623



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


[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-05-30 Thread David Goldman via Phabricator via cfe-commits
dgoldman created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As Typo Resolution can create new TypoExprs while resolving typos,
it is necessary to recurse through the expression to search for more
typos.

This should fix the assertion failure in `clang::Sema::~Sema()`:

  `DelayedTypos.empty() && "Uncorrected typos!"`

Notes:

- For expressions with multiple typos, we only give suggestions if we are able 
to resolve all typos in the expression
- This patch is similar to D37521  except that 
it does not eagerly commit to a correction for the first typo in the 
expression. Instead, it will search for corrections which fix all of the typos 
in the expression.


Repository:
  rC Clang

https://reviews.llvm.org/D62648

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-recursive.cpp

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; } // expected-note {{'getX' declared here}}
+  int getN() const { return m_n; }
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; } // expected-note {{'getY0' declared here}}
+  const Y& getY1() const { return m_y1; }
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+getM().  // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+triggee();   // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'}}
+getM().
+thisDoesntSeemToMakeSense();
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7680,6 +7680,56 @@
 return ExprFilter(Res.get());
   }
 
+  // Try to transform the given expression, looping through the correction
+  // candidates with `CheckAndAdvanceTypoExprCorrectionStreams`.
+  //
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult RecursiveTransformLoop(Expr *E) {
+ExprResult Res;
+while (true) {
+  Res = TryTransform(E);
+
+  // The transform was valid: check if there any new TypoExprs were created.
+  // If so, we need to recurse to check their validity.
+  if (!Res.isInvalid()) {
+Expr *FixedExpr = Res.get();
+auto SavedTypoExprs = TypoExprs;
+llvm::SmallSetVector RecursiveTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+
+// Check to see if any new TypoExprs were created. If they were, we need
+// to recurse in order to handle them. If we're not able to handle them,
+// discard this correction.
+if (!TypoExprs.empty()) {
+  ExprResult RecurResult = RecursiveTransformLoop(FixedExpr);
+  if (RecurResult.isInvalid())
+Res = ExprError();
+  else
+Res = RecurResult;
+  // Add the newly created typos to the TypoExprs list, even if they
+  // failed to apply. This allows them to be reaped although they won't
+  // emit any diagnostic.
+  SavedTypoExprs.set_union(TypoExprs);
+}
+
+TypoExprs = SavedTypoExprs;
+  }
+  // If the transform is still valid after checking for any new typos,
+  // it's good to go.
+  if (!Res.isInvalid())
+break;
+
+  // The transform was invalid, see if we have any TypoExprs with untried
+  // correction candidates.
+  if (!CheckAndAdvanceTypoExprCorrectionStreams())
+break;
+}
+return Res;
+  }
+
 public:
   TransformTypos(Sema , VarDecl *InitDecl, llvm::function_ref Filter)
   : BaseTransform(SemaRef), InitDecl(InitDecl), ExprFilter(Filter) {}
@@ -7707,16 +7757,7 @@
   ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
 
   ExprResult Transform(Expr *E) {
-ExprResult Res;
-while (true) {
-  Res = TryTransform(E);
-
-  // Exit if either the 

r362067 - asm goto: fix out-of-bounds read of Constraints after rC362045

2019-05-30 Thread Fangrui Song via cfe-commits
Author: maskray
Date: Thu May 30 01:03:02 2019
New Revision: 362067

URL: http://llvm.org/viewvc/llvm-project?rev=362067=rev
Log:
asm goto: fix out-of-bounds read of Constraints after rC362045

When parsing goto labels, Names and Exprs are expanded but Constraints
is not, this may cause a out-of-bounds read later in:

// GCCAsmStmt::GCCAsmStmt
// `constraints` has only `NumExprs - NumLabels` elements
  Constraints = new (C) StringLiteral*[NumExprs];
  std::copy(constraints, constraints + NumExprs, Constraints);

Modified:
cfe/trunk/lib/Parse/ParseStmtAsm.cpp

Modified: cfe/trunk/lib/Parse/ParseStmtAsm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseStmtAsm.cpp?rev=362067=362066=362067=diff
==
--- cfe/trunk/lib/Parse/ParseStmtAsm.cpp (original)
+++ cfe/trunk/lib/Parse/ParseStmtAsm.cpp Thu May 30 01:03:02 2019
@@ -846,6 +846,7 @@ StmtResult Parser::ParseAsmStatement(boo
   ExprResult Res =
   Actions.ActOnAddrLabel(Tok.getLocation(), Tok.getLocation(), LD);
   Exprs.push_back(Res.get());
+  Constraints.emplace_back();
   NumLabels++;
   ConsumeToken();
   if (!TryConsumeToken(tok::comma))


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


[libunwind] r362065 - [CMake] Use find_package(LLVM) instead of LLVMConfig

2019-05-30 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Thu May 30 00:34:39 2019
New Revision: 362065

URL: http://llvm.org/viewvc/llvm-project?rev=362065=rev
Log:
[CMake] Use find_package(LLVM) instead of LLVMConfig

This addresses an issues introduced in r362047.

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

Modified:
libunwind/trunk/CMakeLists.txt

Modified: libunwind/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/CMakeLists.txt?rev=362065=362064=362065=diff
==
--- libunwind/trunk/CMakeLists.txt (original)
+++ libunwind/trunk/CMakeLists.txt Thu May 30 00:34:39 2019
@@ -15,7 +15,7 @@ set(CMAKE_MODULE_PATH
   ${CMAKE_MODULE_PATH}
   )
 
-if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR OR 
LIBUNWIND_STANDALONE_BUILD)
   project(libunwind)
 
   # Rely on llvm-config.


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


r362062 - [AST] asm goto labels don't have constraints, don't try to copy them.

2019-05-30 Thread Benjamin Kramer via cfe-commits
Author: d0k
Date: Thu May 30 00:21:08 2019
New Revision: 362062

URL: http://llvm.org/viewvc/llvm-project?rev=362062=rev
Log:
[AST] asm goto labels don't have constraints, don't try to copy them.

Found by asan.

Modified:
cfe/trunk/lib/AST/Stmt.cpp

Modified: cfe/trunk/lib/AST/Stmt.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Stmt.cpp?rev=362062=362061=362062=diff
==
--- cfe/trunk/lib/AST/Stmt.cpp (original)
+++ cfe/trunk/lib/AST/Stmt.cpp Thu May 30 00:21:08 2019
@@ -483,9 +483,10 @@ void GCCAsmStmt::setOutputsAndInputsAndC
   this->Exprs = new (C) Stmt*[NumExprs];
   std::copy(Exprs, Exprs + NumExprs, this->Exprs);
 
+  unsigned NumConstraints = NumOutputs + NumInputs;
   C.Deallocate(this->Constraints);
-  this->Constraints = new (C) StringLiteral*[NumExprs];
-  std::copy(Constraints, Constraints + NumExprs, this->Constraints);
+  this->Constraints = new (C) StringLiteral*[NumConstraints];
+  std::copy(Constraints, Constraints + NumConstraints, this->Constraints);
 
   C.Deallocate(this->Clobbers);
   this->Clobbers = new (C) StringLiteral*[NumClobbers];
@@ -756,8 +757,9 @@ GCCAsmStmt::GCCAsmStmt(const ASTContext
   Exprs = new (C) Stmt*[NumExprs];
   std::copy(exprs, exprs + NumExprs, Exprs);
 
-  Constraints = new (C) StringLiteral*[NumExprs];
-  std::copy(constraints, constraints + NumExprs, Constraints);
+  unsigned NumConstraints = NumOutputs + NumInputs;
+  Constraints = new (C) StringLiteral*[NumConstraints];
+  std::copy(constraints, constraints + NumConstraints, Constraints);
 
   Clobbers = new (C) StringLiteral*[NumClobbers];
   std::copy(clobbers, clobbers + NumClobbers, Clobbers);


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


r362059 - Mark CodeGen/asm-goto.c as x86 specific after r362045

2019-05-30 Thread Fangrui Song via cfe-commits
Author: maskray
Date: Wed May 29 23:48:13 2019
New Revision: 362059

URL: http://llvm.org/viewvc/llvm-project?rev=362059=rev
Log:
Mark CodeGen/asm-goto.c as x86 specific after r362045

Modified:
cfe/trunk/test/CodeGen/asm-goto.c

Modified: cfe/trunk/test/CodeGen/asm-goto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/asm-goto.c?rev=362059=362058=362059=diff
==
--- cfe/trunk/test/CodeGen/asm-goto.c (original)
+++ cfe/trunk/test/CodeGen/asm-goto.c Wed May 29 23:48:13 2019
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -O0 -emit-llvm  %s -o - | FileCheck %s
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -triple x86_64 -O0 -emit-llvm %s -o - | FileCheck %s
 
 int foo(int cond)
 {


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


<    1   2