r312222 - [analyzer] Performance optimizations for the CloneChecker
Author: teemperor
Date: Thu Aug 31 00:10:46 2017
New Revision: 31
URL: http://llvm.org/viewvc/llvm-project?rev=31&view=rev
Log:
[analyzer] Performance optimizations for the CloneChecker
Summary:
This patch aims at optimizing the CloneChecker for larger programs. Before this
patch we took around 102 seconds to analyze sqlite3 with a complexity value of
50. After this patch we now take 2.1 seconds to analyze sqlite3.
The biggest performance optimization is that we now put the constraint for group
size before the constraint for the complexity. The group size constraint is much
faster in comparison to the complexity constraint as it only does a simple
integer comparison. The complexity constraint on the other hand actually
traverses each Stmt and even checks the macro stack, so it is obviously not able
to handle larger amounts of incoming clones. The new order filters out all the
single-clone groups that the type II constraint generates in a faster way before
passing the fewer remaining clones to the complexity constraint. This reduced
runtime by around 95%.
The other change is that we also delay the verification part of the type II
clones back in the chain of constraints. This required to split up the
constraint into two parts - a verification and a hash constraint (which is also
making it more similar to the original design of the clone detection algorithm).
The reasoning for this is the same as before: The verification constraint has to
traverse many statements and shouldn't be at the start of the constraint chain.
However, as the type II hashing has to be the first step in our algorithm, we
have no other choice but split this constrain into two different ones. Now our
group size and complexity constrains filter out a chunk of the clones before
they reach the slow verification step, which reduces the runtime by around 8%.
I also kept the full type II constraint around - that now just calls it's two
sub-constraints - in case someone doesn't care about the performance benefits
of doing this.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: klimek, v.g.vassilev, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34182
Modified:
cfe/trunk/include/clang/Analysis/CloneDetection.h
cfe/trunk/lib/Analysis/CloneDetection.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/CloneChecker.cpp
cfe/trunk/unittests/Analysis/CloneDetectionTest.cpp
Modified: cfe/trunk/include/clang/Analysis/CloneDetection.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/CloneDetection.h?rev=31&r1=312221&r2=31&view=diff
==
--- cfe/trunk/include/clang/Analysis/CloneDetection.h (original)
+++ cfe/trunk/include/clang/Analysis/CloneDetection.h Thu Aug 31 00:10:46 2017
@@ -252,22 +252,25 @@ public:
std::function Compare);
};
-/// Searches all children of the given clones for type II clones (i.e. they are
-/// identical in every aspect beside the used variable names).
-class RecursiveCloneTypeIIConstraint {
-
- /// Generates and saves a hash code for the given Stmt.
- /// \param S The given Stmt.
- /// \param D The Decl containing S.
- /// \param StmtsByHash Output parameter that will contain the hash codes for
- ///each StmtSequence in the given Stmt.
- /// \return The hash code of the given Stmt.
- ///
- /// If the given Stmt is a CompoundStmt, this method will also generate
- /// hashes for all possible StmtSequences in the children of this Stmt.
- size_t saveHash(const Stmt *S, const Decl *D,
- std::vector> &StmtsByHash);
+/// This constraint moves clones into clone groups of type II via hashing.
+///
+/// Clones with different hash values are moved into separate clone groups.
+/// Collisions are possible, and this constraint does nothing to address this
+/// them. Add the slower RecursiveCloneTypeIIVerifyConstraint later in the
+/// constraint chain, not necessarily immediately, to eliminate hash collisions
+/// through a more detailed analysis.
+class RecursiveCloneTypeIIHashConstraint {
+public:
+ void constrain(std::vector &Sequences);
+};
+/// This constraint moves clones into clone groups of type II by comparing
them.
+///
+/// Clones that aren't type II clones are moved into separate clone groups.
+/// In contrast to the RecursiveCloneTypeIIHashConstraint, all clones in a
clone
+/// group are guaranteed to be be type II clones of each other, but it is too
+/// slow to efficiently handle large amounts of clones.
+class RecursiveCloneTypeIIVerifyConstraint {
public:
void constrain(std::vector &Sequences);
};
Modified: cfe/trunk/lib/Analysis/CloneDetection.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/CloneDetection.cpp?rev=31&r1=312221&r2=31&view=diff
==
--- cfe/trunk/lib/Analysis/CloneDetection.cpp (original)
+++ cf
[PATCH] D34182: [analyzer] Performance optimizations for the CloneChecker
This revision was automatically updated to reflect the committed changes.
Closed by commit rL31: [analyzer] Performance optimizations for the
CloneChecker (authored by teemperor).
Changed prior to commit:
https://reviews.llvm.org/D34182?vs=108839&id=113361#toc
Repository:
rL LLVM
https://reviews.llvm.org/D34182
Files:
cfe/trunk/include/clang/Analysis/CloneDetection.h
cfe/trunk/lib/Analysis/CloneDetection.cpp
cfe/trunk/lib/StaticAnalyzer/Checkers/CloneChecker.cpp
cfe/trunk/unittests/Analysis/CloneDetectionTest.cpp
Index: cfe/trunk/lib/StaticAnalyzer/Checkers/CloneChecker.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CloneChecker.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CloneChecker.cpp
@@ -81,11 +81,11 @@
// because reportSuspiciousClones() wants to search them for errors.
std::vector AllCloneGroups;
- Detector.findClones(AllCloneGroups,
- FilenamePatternConstraint(IgnoredFilesPattern),
- RecursiveCloneTypeIIConstraint(),
- MinComplexityConstraint(MinComplexity),
- MinGroupSizeConstraint(2), OnlyLargestCloneConstraint());
+ Detector.findClones(
+ AllCloneGroups, FilenamePatternConstraint(IgnoredFilesPattern),
+ RecursiveCloneTypeIIHashConstraint(), MinGroupSizeConstraint(2),
+ MinComplexityConstraint(MinComplexity),
+ RecursiveCloneTypeIIVerifyConstraint(), OnlyLargestCloneConstraint());
if (ReportSuspiciousClones)
reportSuspiciousClones(BR, Mgr, AllCloneGroups);
Index: cfe/trunk/lib/Analysis/CloneDetection.cpp
===
--- cfe/trunk/lib/Analysis/CloneDetection.cpp
+++ cfe/trunk/lib/Analysis/CloneDetection.cpp
@@ -238,9 +238,18 @@
return HashCode;
}
-size_t RecursiveCloneTypeIIConstraint::saveHash(
-const Stmt *S, const Decl *D,
-std::vector> &StmtsByHash) {
+/// Generates and saves a hash code for the given Stmt.
+/// \param S The given Stmt.
+/// \param D The Decl containing S.
+/// \param StmtsByHash Output parameter that will contain the hash codes for
+///each StmtSequence in the given Stmt.
+/// \return The hash code of the given Stmt.
+///
+/// If the given Stmt is a CompoundStmt, this method will also generate
+/// hashes for all possible StmtSequences in the children of this Stmt.
+static size_t
+saveHash(const Stmt *S, const Decl *D,
+ std::vector> &StmtsByHash) {
llvm::MD5 Hash;
ASTContext &Context = D->getASTContext();
@@ -340,7 +349,7 @@
return DataLHS == DataRHS;
}
-void RecursiveCloneTypeIIConstraint::constrain(
+void RecursiveCloneTypeIIHashConstraint::constrain(
std::vector &Sequences) {
// FIXME: Maybe we can do this in-place and don't need this additional vector.
std::vector Result;
@@ -381,8 +390,7 @@
for (; i < StmtsByHash.size(); ++i) {
// A different hash value means we have reached the end of the sequence.
-if (PrototypeHash != StmtsByHash[i].first ||
-!areSequencesClones(StmtsByHash[i].second, Current.second)) {
+if (PrototypeHash != StmtsByHash[i].first) {
// The current sequence could be the start of a new CloneGroup. So we
// decrement i so that we visit it again in the outer loop.
// Note: i can never be 0 at this point because we are just comparing
@@ -405,6 +413,14 @@
Sequences = Result;
}
+void RecursiveCloneTypeIIVerifyConstraint::constrain(
+std::vector &Sequences) {
+ CloneConstraint::splitCloneGroups(
+ Sequences, [](const StmtSequence &A, const StmtSequence &B) {
+return areSequencesClones(A, B);
+ });
+}
+
size_t MinComplexityConstraint::calculateStmtComplexity(
const StmtSequence &Seq, const std::string &ParentMacroStack) {
if (Seq.empty())
Index: cfe/trunk/unittests/Analysis/CloneDetectionTest.cpp
===
--- cfe/trunk/unittests/Analysis/CloneDetectionTest.cpp
+++ cfe/trunk/unittests/Analysis/CloneDetectionTest.cpp
@@ -69,8 +69,9 @@
// all statements from functions which names start with "bar".
std::vector CloneGroups;
Detector.findClones(CloneGroups, NoBarFunctionConstraint(),
- RecursiveCloneTypeIIConstraint(),
+ RecursiveCloneTypeIIHashConstraint(),
MinComplexityConstraint(2), MinGroupSizeConstraint(2),
+ RecursiveCloneTypeIIVerifyConstraint(),
OnlyLargestCloneConstraint());
ASSERT_EQ(CloneGroups.size(), 1u);
@@ -86,8 +87,9 @@
// Retry above's example without the filter...
CloneGroups.clear();
- Detector.findClones(CloneGroups, RecursiveCloneTypeIIConstraint(),
+ Detector.findClones(CloneGroups, RecursiveCloneTypeIIHashConstraint(),
MinComplexityConstraint(2), MinGroupSizeConstraint(2),
+
r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
Author: mstorsjo
Date: Thu Aug 31 01:29:59 2017
New Revision: 312224
URL: http://llvm.org/viewvc/llvm-project?rev=312224&view=rev
Log:
[ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
This fixes cases where dynamic classes produced RTTI data with
external linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but
this change doesn't break the tests added in that revision.
Differential revision: https://reviews.llvm.org/D37206
Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=312224&r1=312223&r2=312224&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Thu Aug 31 01:29:59 2017
@@ -2998,15 +2998,13 @@ static llvm::GlobalVariable::LinkageType
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key
function.
-// Make sure we emit our own copy instead of attempting to dllimport
it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Modified: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp?rev=312224&r1=312223&r2=312224&view=diff
==
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp Thu Aug 31 01:29:59 2017
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37206: [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
This revision was automatically updated to reflect the committed changes.
Closed by commit rL312224: [ItaniumCXXABI] Always use linkonce_odr linkage for
RTTI data on MinGW (authored by mstorsjo).
Changed prior to commit:
https://reviews.llvm.org/D37206?vs=113309&id=113367#toc
Repository:
rL LLVM
https://reviews.llvm.org/D37206
Files:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
Index: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
===
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key
function.
-// Make sure we emit our own copy instead of attempting to dllimport
it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Index: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
===
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
Index: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
===
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key function.
-// Make sure we emit our own copy instead of attempting to dllimport it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Index: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
===
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8** @_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32 0, i32 0),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D30295: [analyzer] clarify undef shift result when shift count is negative or exceeds the bit width
danielmarjamaki added a comment. ping Repository: rL LLVM https://reviews.llvm.org/D30295 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312229 - Revert r312224: "[ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW"
Author: mstorsjo
Date: Thu Aug 31 02:46:27 2017
New Revision: 312229
URL: http://llvm.org/viewvc/llvm-project?rev=312229&view=rev
Log:
Revert r312224: "[ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data
on MinGW"
Breaks on buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/4548/steps/test-check-all/logs/stdio
The test in CodeGenCXX/virt-dtor-key.cpp tests using %itanium_abi_triple;
on non-windows platforms, this resolves to the current platform triple
(where there was no behaviour change), while on windows, it resolves to
a mingw triple (where the behaviour was intentionally changed).
Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=312229&r1=312228&r2=312229&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Thu Aug 31 02:46:27 2017
@@ -2998,13 +2998,15 @@ static llvm::GlobalVariable::LinkageType
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- // MinGW always uses LinkOnceODRLinkage for type info.
- if (RD->isDynamicClass() &&
- !CGM.getContext()
- .getTargetInfo()
- .getTriple()
- .isWindowsGNUEnvironment())
-return CGM.getVTableLinkage(RD);
+ if (RD->isDynamicClass()) {
+llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
+// MinGW won't export the RTTI information when there is a key
function.
+// Make sure we emit our own copy instead of attempting to dllimport
it.
+if (RD->hasAttr() &&
+llvm::GlobalValue::isAvailableExternallyLinkage(LT))
+ LT = llvm::GlobalValue::LinkOnceODRLinkage;
+return LT;
+ }
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Modified: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp?rev=312229&r1=312228&r2=312229&view=diff
==
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp Thu Aug 31 02:46:27 2017
@@ -2,12 +2,7 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
-class C {
- virtual ~C();
-};
-C::~C() {}
-// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D20689: [clang-tidy] Suspicious Call Argument checker
barancsuk commandeered this revision. barancsuk added a reviewer: varjujan. barancsuk added a comment. Herald added a subscriber: baloghadamsoftware. Since the previous author, @varjujan is not available anymore, I take over the role of the author of this revision. https://reviews.llvm.org/D20689 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37140: [clang-format] Fixed one-line if statement
PriMee updated this revision to Diff 113379.
PriMee added a comment.
Diff file updated. Some tests added. Some new bugs fixed as well :)
https://reviews.llvm.org/D37140
Files:
lib/Format/UnwrappedLineFormatter.cpp
unittests/Format/FormatTest.cpp
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -439,6 +439,7 @@
TEST_F(FormatTest, FormatShortBracedStatements) {
FormatStyle AllowSimpleBracedStatements = getLLVMStyle();
+ AllowSimpleBracedStatements.ColumnLimit = 40;
AllowSimpleBracedStatements.AllowShortBlocksOnASingleLine = true;
AllowSimpleBracedStatements.AllowShortIfStatementsOnASingleLine = true;
@@ -452,6 +453,10 @@
verifyFormat("if constexpr (true) { f(); }", AllowSimpleBracedStatements);
verifyFormat("while (true) { f(); }", AllowSimpleBracedStatements);
verifyFormat("for (;;) { f(); }", AllowSimpleBracedStatements);
+ verifyFormat("if (true) {\n"
+ " ff();\n"
+ "}",
+ AllowSimpleBracedStatements);
verifyFormat("if (true) { //\n"
" f();\n"
"}",
@@ -482,6 +487,7 @@
AllowSimpleBracedStatements);
AllowSimpleBracedStatements.AllowShortIfStatementsOnASingleLine = false;
+ verifyFormat("if (true) {}", AllowSimpleBracedStatements);
verifyFormat("if (true) {\n"
" f();\n"
"}",
@@ -494,14 +500,84 @@
AllowSimpleBracedStatements);
AllowSimpleBracedStatements.AllowShortLoopsOnASingleLine = false;
+ verifyFormat("while (true) {}", AllowSimpleBracedStatements);
verifyFormat("while (true) {\n"
" f();\n"
"}",
AllowSimpleBracedStatements);
+ verifyFormat("for (;;) {}", AllowSimpleBracedStatements);
verifyFormat("for (;;) {\n"
" f();\n"
"}",
AllowSimpleBracedStatements);
+
+ AllowSimpleBracedStatements.AllowShortIfStatementsOnASingleLine = true;
+ AllowSimpleBracedStatements.AllowShortLoopsOnASingleLine = true;
+ AllowSimpleBracedStatements.BreakBeforeBraces = FormatStyle::BS_Custom;
+ AllowSimpleBracedStatements.BraceWrapping.AfterControlStatement = true;
+
+ verifyFormat("if (true) {}", AllowSimpleBracedStatements);
+ verifyFormat("if constexpr (true) {}", AllowSimpleBracedStatements);
+ verifyFormat("while (true) {}", AllowSimpleBracedStatements);
+ verifyFormat("for (;;) {}", AllowSimpleBracedStatements);
+ verifyFormat("if (true) { f(); }", AllowSimpleBracedStatements);
+ verifyFormat("if constexpr (true) { f(); }", AllowSimpleBracedStatements);
+ verifyFormat("while (true) { f(); }", AllowSimpleBracedStatements);
+ verifyFormat("for (;;) { f(); }", AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{\n"
+ " ff();\n"
+ "}",
+ AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{ //\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{\n"
+ " f();\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{\n"
+ " f();\n"
+ "} else\n"
+ "{\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+
+ AllowSimpleBracedStatements.AllowShortIfStatementsOnASingleLine = false;
+ verifyFormat("if (true) {}", AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+ verifyFormat("if (true)\n"
+ "{\n"
+ " f();\n"
+ "} else\n"
+ "{\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+
+ AllowSimpleBracedStatements.AllowShortLoopsOnASingleLine = false;
+ verifyFormat("while (true) {}", AllowSimpleBracedStatements);
+ verifyFormat("while (true)\n"
+ "{\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
+ verifyFormat("for (;;) {}", AllowSimpleBracedStatements);
+ verifyFormat("for (;;)\n"
+ "{\n"
+ " f();\n"
+ "}",
+ AllowSimpleBracedStatements);
}
TEST_F(FormatTest, ParseIfElse) {
Index: lib/Format/UnwrappedLineFormatter.cpp
===
--- lib/Format/UnwrappedLineFormatter.cpp
+++ lib/Format/UnwrappedLineFormatter.cpp
@@ -279,15 +279,41 @@
}
}
+// Try to merge a function block with left brace unwrapped
if
[PATCH] D37327: Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
mstorsjo created this revision.
This fixes cases where dynamic classes produced RTTI data with external
linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but this change
doesn't break the tests added in that revision.
The previous version had missed to update CodeGenCXX/virt-dtor-key.cpp, which
had a behaviour change only when running the testsuite on windows.
https://reviews.llvm.org/D37327
Files:
lib/CodeGen/ItaniumCXXABI.cpp
test/CodeGenCXX/rtti-mingw64.cpp
test/CodeGenCXX/virt-dtor-key.cpp
Index: test/CodeGenCXX/virt-dtor-key.cpp
===
--- test/CodeGenCXX/virt-dtor-key.cpp
+++ test/CodeGenCXX/virt-dtor-key.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck
%s
+// RUN: %clang_cc1 -triple i386-linux -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-windows-gnu -emit-llvm %s -o - | FileCheck %s
-check-prefix CHECK-MINGW
// CHECK: @_ZTI3foo = constant
+// CHECK-MINGW: @_ZTI3foo = linkonce_odr
class foo {
foo();
virtual ~foo();
Index: test/CodeGenCXX/rtti-mingw64.cpp
===
--- test/CodeGenCXX/rtti-mingw64.cpp
+++ test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key
function.
-// Make sure we emit our own copy instead of attempting to dllimport
it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Index: test/CodeGenCXX/virt-dtor-key.cpp
===
--- test/CodeGenCXX/virt-dtor-key.cpp
+++ test/CodeGenCXX/virt-dtor-key.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-linux -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-windows-gnu -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MINGW
// CHECK: @_ZTI3foo = constant
+// CHECK-MINGW: @_ZTI3foo = linkonce_odr
class foo {
foo();
virtual ~foo();
Index: test/CodeGenCXX/rtti-mingw64.cpp
===
--- test/CodeGenCXX/rtti-mingw64.cpp
+++ test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8** @_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32 0, i32 0),
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key function.
-// Make sure we emit our own copy instead of attempting to dllimport it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if
[PATCH] D34030: Fix the postorder visting of the ClassTemplateSpecializationDecl nodes in the RecursiveASTVisitor.
MontyKutyi added a comment. Ping. https://reviews.llvm.org/D34030 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37140: [clang-format] Fixed one-line if statement
PriMee added a comment.
Sorry for wrong formatting before. Some inline comments added.
Comment at: lib/Format/UnwrappedLineFormatter.cpp:286
}
+if (TheLine->Last->is(tok::l_brace) &&
+TheLine->First != TheLine->Last &&
krasimir wrote:
> No tests fail if this `if` statement gets removed. Please either remove it or
> add a test for it.
That's true. Why is that? Without this if statement tests would pass because
our block would have been handled by the construct I have mentioned in problem
description (Line 311). Adding a very similar test case with
BraceWrapping.AfterFunction flag changed would show that we need this if
statement. To my mind, it doesn't make sense to add such test case.
Comment at: lib/Format/UnwrappedLineFormatter.cpp:300
+ return Style.AllowShortBlocksOnASingleLine ? tryMergeSimpleBlock(I-1, E,
Limit) : 0;
+}
if (TheLine->Last->is(tok::l_brace)) {
krasimir wrote:
> krasimir wrote:
> > Please reformat the newly added code with `clang-format`.
> Why in this case we use `Style.AllowShortBlocksOnASingleLine` and in the case
> above we use `AfterControlStatement`?
> Also, why `tryMergeSimpleBlock` instead of `tryMergeControlStatement`?
We use `AfterControlStatement` because we want to ensure that the block with
the opening brace in separate line is correct. The flag implies this fact.
We use `tryMergeControlStatement` only when our control statement is not within
braces, `tryMergeSimpleBlock` in every other case.
Comment at: unittests/Format/FormatTest.cpp:537
+ "}",
+ AllowSimpleBracedStatements);
+
krasimir wrote:
> Why is this example not on a single line? Is it because it has an `else`?
Exactly. Shouldn't this work like that? There is a comment:
`// Don't merge "if (a) { .. } else {".` on line 548 in
UnwrappedLineFormatter.cpp
https://reviews.llvm.org/D37140
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33826: [clang-tidy] avoid pointer cast to more strict alignment check
lebedev.ri added a comment. In https://reviews.llvm.org/D33826#772676, @aaron.ballman wrote: > How does this check compare with the -Wcast-align diagnostic in the Clang > frontend? I believe that warning already covers these cases, so I'm wondering > what extra value is added with this check? In https://reviews.llvm.org/D33826#856887, @rjmccall wrote: > In https://reviews.llvm.org/D33826#856652, @lebedev.ri wrote: > > > In https://reviews.llvm.org/D33826#856619, @Eugene.Zelenko wrote: > > > > > In https://reviews.llvm.org/D33826#856610, @lebedev.ri wrote: > > > > > > > Any status update here? :) > > > > I generally do see a benefit in this check, because `-Wcast-align` (at > > > > least currently?) does not warn on `reinterpret_cast<>()`. > > > > > > > > > I think will be good idea to extend -Wcast-align. > > > > > > Hm, are you *sure* `reinterpret_cast<>()` is not allowed to increase > > alignment? > > There was a commit that intentionally removed that warning: (by @rjmccall, > > i believe) > > > > https://github.com/llvm-mirror/clang/commit/35a38d95da89d48778019c37b5f8c9a20f7e309c > > > One of the fundamental design principles to keep in mind when implementing > warnings like -Wcast-align is that we're trying to warn users about having > written something dangerous, not scold them for writing code a particular > way. Users do need to do these casts sometimes, and there has to be some way > of doing them without a warning. So the question of when to warn has to > consider whether the code is explicitly acknowledging the danger. It would, > for example, be a mistake to warn in C about double-casts through (void*), > because that is not something that people do accidentally; it is very likely > that it is an attempt to suppress the warning. In C++, it seemed to me that > a reinterpret_cast is by its nature explicitly acknowledging the danger, so > it is never really appropriate to warn. So we are back from where we have started, and this check does make sense. Repository: rL LLVM https://reviews.llvm.org/D33826 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis
danielmarjamaki added inline comments. Comment at: tools/scan-build-py/libscanbuild/analyze.py:165 +with open(filename, 'r') as in_file: +for line in in_file: +yield line I believe you can write: for line in open(filename, 'r'): Comment at: tools/scan-build-py/libscanbuild/analyze.py:172 +extern_fns_map_file = os.path.join(ctudir, CTU_FUNCTION_MAP_FILENAME) +with open(extern_fns_map_file, 'w') as out_file: +for mangled_name, ast_file in mangled_ast_pairs: this 'with' seems redundant. I suggest an assignment and then less indentation will be needed below Comment at: tools/scan-build-py/libscanbuild/analyze.py:223 +ctu_config = get_ctu_config(args) +if ctu_config.collect: +shutil.rmtree(ctu_config.dir, ignore_errors=True) not a big deal but I would use early exits in this function Comment at: tools/scan-build-py/libscanbuild/clang.py:177 +arch = "" +i = 0 +while i < len(cmd) and cmd[i] != "-triple": I am guessing that you can use cmd.find() instead of the loop https://reviews.llvm.org/D30691 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312232 - docs: don't say that data flow tracing interface is unstable
Author: dvyukov Date: Thu Aug 31 04:02:44 2017 New Revision: 312232 URL: http://llvm.org/viewvc/llvm-project?rev=312232&view=rev Log: docs: don't say that data flow tracing interface is unstable We are starting to use data flow tracing in kernel. The interface is not subject to change anymore. Reviewed in https://reviews.llvm.org/D37303 Modified: cfe/trunk/docs/SanitizerCoverage.rst Modified: cfe/trunk/docs/SanitizerCoverage.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=312232&r1=312231&r2=312232&view=diff == --- cfe/trunk/docs/SanitizerCoverage.rst (original) +++ cfe/trunk/docs/SanitizerCoverage.rst Thu Aug 31 04:02:44 2017 @@ -281,8 +281,6 @@ the `LLVM GEP instructions
[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis
whisperity added a comment. The Python code here still uses `mangled name` in their wording. Does this mean this patch is yet to be updated with the USR management in the parent patch? Comment at: tools/scan-build-py/libscanbuild/analyze.py:165 +with open(filename, 'r') as in_file: +for line in in_file: +yield line danielmarjamaki wrote: > I believe you can write: > > for line in open(filename, 'r'): Do we want to rely on the interpreter implementation on when the file is closed. If ``` for line in open(filename, 'r'): something() ``` is used, the file handle will be closed based on garbage collection rules. Having this handle disposed after the iteration is true for the stock CPython implementation, but it is still nontheless an implementation specific approach. Whereas using `with` will explicitly close the file handle on the spot, no matter what. Comment at: tools/scan-build-py/libscanbuild/analyze.py:172 +extern_fns_map_file = os.path.join(ctudir, CTU_FUNCTION_MAP_FILENAME) +with open(extern_fns_map_file, 'w') as out_file: +for mangled_name, ast_file in mangled_ast_pairs: danielmarjamaki wrote: > this 'with' seems redundant. I suggest an assignment and then less > indentation will be needed below I don't seem to understand what do you want to assign to what. https://reviews.llvm.org/D30691 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D20689: [clang-tidy] Suspicious Call Argument checker
barancsuk updated this revision to Diff 113376.
barancsuk added a comment.
Major changes that have been made since the last update are as follows:
- It is checked, whether implicit type conversion is possible from the argument
to the other parameter. The following conversion rules are considered:
- Arithmetic type conversions
- Pointer to pointer conversion (for multilevel pointers and also
base/derived class pointers)
- Array to pointer conversion
- Function to function-pointer conversion
- CV-qualifier compatibility is checked as well.
- The calculation of a heuristic`s result and the comparison of this result
with the corresponding threshold value are performed by the same method, the
heuristic`s function.
- The heuristic`s function is called only if the heuristic itself is turned on
by the configuration settings.
**Remark**:
Implicit conversion rules of C are not checked separately, because, as I
experienced when testing the checker on a larger code base, deeming all
pointers convertible results in several false positives.
https://reviews.llvm.org/D20689
Files:
clang-tidy/readability/CMakeLists.txt
clang-tidy/readability/ReadabilityTidyModule.cpp
clang-tidy/readability/SuspiciousCallArgumentCheck.cpp
clang-tidy/readability/SuspiciousCallArgumentCheck.h
docs/ReleaseNotes.rst
docs/clang-tidy/checks/list.rst
docs/clang-tidy/checks/readability-suspicious-call-argument.rst
test/clang-tidy/readability-suspicious-call-argument.cpp
Index: test/clang-tidy/readability-suspicious-call-argument.cpp
===
--- /dev/null
+++ test/clang-tidy/readability-suspicious-call-argument.cpp
@@ -0,0 +1,379 @@
+// RUN: %check_clang_tidy %s readability-suspicious-call-argument %t -- -- -std=c++11
+
+void foo_1(int aa, int bb) {}
+
+void foo_2(int source, int aa) {}
+
+void foo_3(int valToRet, int aa) {}
+
+void foo_4(int pointer, int aa) {}
+
+void foo_5(int aa, int bb, int cc, ...) {}
+
+void foo_6(const int dd, bool &ee) {}
+
+// Test functions for convertible argument--parameter types.
+void fun(const int &m);
+void fun2() {
+ int m = 3;
+ fun(m);
+}
+
+// Test cases for parameters of const reference and value.
+void value_const_reference(int ll, const int &kk);
+
+void const_ref_value_swapped() {
+ const int &kk = 42;
+ const int &ll = 42;
+ value_const_reference(kk, ll);
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: kk (ll) is swapped with ll (kk). [readability-suspicious-call-argument]
+}
+
+// Const, non const references.
+void const_nonconst_parameters(const int &mm, int &nn);
+
+void const_nonconst_swap1() {
+ const int& nn = 42;
+ int mm;
+ // Do not check, because non-const reference parameter cannot bind to const reference argument.
+ const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap3() {
+ const int nn = 42;
+ int m = 42;
+ int &mm = m;
+ // Do not check, const int does not bind to non const reference.
+ const_nonconst_parameters(nn, mm);
+}
+
+void const_nonconst_swap2() {
+ int nn;
+ int mm;
+ // Check for swapped arguments. (Both arguments are non-const.)
+ const_nonconst_parameters(
+ nn,
+ mm);
+ // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: nn (mm) is swapped with mm (nn). [readability-suspicious-call-argument]
+}
+
+void const_nonconst_pointers(const int* mm, int* nn);
+void const_nonconst_pointers2(const int* mm, const int* nn);
+
+void const_nonconst_pointers_swapped(){
+int* mm;
+const int* nn;
+const_nonconst_pointers(nn, mm);
+}
+
+void const_nonconst_pointers_swapped2() {
+ const int *mm;
+ int *nn;
+ const_nonconst_pointers2(nn, mm);
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: nn (mm) is swapped with mm (nn). [readability-suspicious-call-argument]
+}
+
+// Test cases for pointers and arrays.
+void pointer_array_parameters(
+int *pp, int qq[4]);
+
+void pointer_array_swap() {
+ int qq[5];
+ int *pp;
+ // Check for swapped arguments. An array implicitly converts to a pointer.
+ pointer_array_parameters(qq, pp);
+ // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: qq (pp) is swapped with pp (qq). [readability-suspicious-call-argument]
+}
+
+// Test cases for multilevel pointers.
+void multilevel_pointer_parameters(int *const **pp,
+ const int *const *volatile const *qq);
+void multilevel_pointer_parameters2(
+char *nn, char *volatile *const *const *const *const &mm);
+
+typedef float T;
+typedef T * S;
+typedef S *const volatile R;
+typedef R * Q;
+typedef Q * P;
+typedef P * O;
+void multilevel_pointer_parameters3(float **const volatile ***rr, O &ss);
+
+void multilevel_pointer_swap() {
+ int *const ** qq;
+ int *const
[PATCH] D34512: Add preliminary Cross Translation Unit support library
danielmarjamaki added a comment.
small nits
Comment at: include/clang/CrossTU/CrossTranslationUnit.h:58
+
+/// \brief This function can parse an index file that determines which
+///translation unit contains which definition.
I suggest that "can" is removed.
Comment at: include/clang/CrossTU/CrossTranslationUnit.h:62
+/// The index file format is the following:
+/// each line consists of an USR separated by a filepath.
+llvm::Expected>
there is no \return or \returns here.
Comment at: include/clang/CrossTU/CrossTranslationUnit.h:62
+/// The index file format is the following:
+/// each line consists of an USR separated by a filepath.
+llvm::Expected>
danielmarjamaki wrote:
> there is no \return or \returns here.
maybe: each line consists of an USR and a filepath separated by a space
Comment at: include/clang/CrossTU/CrossTranslationUnit.h:68
+
+/// \brief This class can be used for tools that requires cross translation
+///unit capability.
Maybe /can be/is/ unless you envision that tools that require cross translation
unit capability might use some other classes.
Comment at: include/clang/CrossTU/CrossTranslationUnit.h:92
+ /// definition of the function will be merged into the original AST using
+ /// the AST Importer. The declaration with the definition will be returned.
+ /// If no suitable definition is found in the index file, null will be
you should split out some of this information to a \return or \returns
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:60
+
+char IndexError::ID = 0;
+
redundant assignment
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:79
+ std::string Line;
+ unsigned LineNo = 0;
+ while (std::getline(ExternalFnMapFile, Line)) {
I suggest that LineNo is 1 on the first line.
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:81
+ while (std::getline(ExternalFnMapFile, Line)) {
+size_t Pos = Line.find(" ");
+StringRef LineRef{Line};
Pos can be const
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:82
+size_t Pos = Line.find(" ");
+StringRef LineRef{Line};
+if (Pos > 0 && Pos != std::string::npos) {
LineRef can be const
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:84
+if (Pos > 0 && Pos != std::string::npos) {
+ FunctionName = LineRef.substr(0, Pos);
+ if (Result.count(FunctionName))
FunctionName and FileName can be moved here and it is possible to make these
variables const.
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:85
+ FunctionName = LineRef.substr(0, Pos);
+ if (Result.count(FunctionName))
+return llvm::make_error(
I would like to see some FunctionName validation. For instance "123" should not
be a valid function name.
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:89
+ FileName = LineRef.substr(Pos + 1);
+ SmallString<256> FilePath = CrossTUDir;
+ llvm::sys::path::append(FilePath, FileName);
Stupid question .. how will this work if the path is longer than 256 bytes?
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:102
+createCrossTUIndexString(const llvm::StringMap &Index) {
+ std::stringstream Result;
+ for (const auto &E : Index) {
how about std::ostringstream , imho that is cleaner
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:121
+
+/// Recursively visits the funtion decls of a DeclContext, and looks up a
+/// function based on USRs.
/funtion/function/
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:125
+CrossTranslationUnitContext::findFunctionInDeclContext(const DeclContext *DC,
+ StringRef LookupFnName)
{
+ assert(DC && "Declaration Context must not be null");
LookupFnName could be const right?
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:148
+
+ std::string LookupFnName = getLookupName(FD);
+ if (LookupFnName.empty())
I believe LookupFnName can be const
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:189
+ return nullptr; // No definition found even in some other build unit.
+ASTFileName = It->second;
+auto ASTCacheEntry = FileASTUnitMap.find(ASTFileName);
It is possible to make ASTFileName const
Comment at: lib/CrossTU/CrossTranslationUnit.cpp:223
+assert(ToDecl->hasBody());
+assert(FD->hasBody() && "Functions already imported should have body.");
+return ToDecl;
sorry I am probably missing something here.. you first assert !FD->hasBod
[PATCH] D37308: Interface class with uuid base record
zahiraam updated this revision to Diff 113387.
zahiraam added a comment.
Removed the helper function.
If RD (base class) has uuid attribute, we want to ensure that the interface
doesn't have attributes. Otherwise cases like:
class __declspec(uuid("---C000-0046")) IUnknown1 {};
__interface __declspec(dllimport) ISfFileIOPropertyPage1 : public IUnknown1 {};
will compile.
https://reviews.llvm.org/D37308
Files:
lib/Sema/SemaDeclCXX.cpp
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -2398,13 +2398,6 @@
}
}
-
-/// \brief Tests if the __interface base is public.
-static bool IsBasePublicInterface(const CXXRecordDecl *RD,
- AccessSpecifier spec) {
- return RD->isInterface() && spec == AS_public;
-}
-
/// \brief Performs the actual work of attaching the given base class
/// specifiers to a C++ class.
bool Sema::AttachBaseSpecifiers(CXXRecordDecl *Class,
@@ -2457,13 +2450,13 @@
if (const RecordType *Record = NewBaseType->getAs()) {
const CXXRecordDecl *RD = cast(Record->getDecl());
if (Class->isInterface() &&
-!IsBasePublicInterface(RD, KnownBase->getAccessSpecifier()) &&
+!(RD->isInterface() &&
+ KnownBase->getAccessSpecifier() == AS_public) &&
// The Microsoft extension __interface does not permit bases that
// are not themselves public interfaces.
// An interface can inherit from a base, as long as it has
// uuid attributes.
-(!RD->getAttr() ||
-Class->hasAttrs())) {
+(!RD->getAttr() || Class->hasAttrs())) {
Diag(KnownBase->getLocStart(), diag::err_invalid_base_in_interface)
<< getRecordDiagFromTagKind(RD->getTagKind()) << RD->getName()
<< RD->getSourceRange();
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -2398,13 +2398,6 @@
}
}
-
-/// \brief Tests if the __interface base is public.
-static bool IsBasePublicInterface(const CXXRecordDecl *RD,
- AccessSpecifier spec) {
- return RD->isInterface() && spec == AS_public;
-}
-
/// \brief Performs the actual work of attaching the given base class
/// specifiers to a C++ class.
bool Sema::AttachBaseSpecifiers(CXXRecordDecl *Class,
@@ -2457,13 +2450,13 @@
if (const RecordType *Record = NewBaseType->getAs()) {
const CXXRecordDecl *RD = cast(Record->getDecl());
if (Class->isInterface() &&
-!IsBasePublicInterface(RD, KnownBase->getAccessSpecifier()) &&
+!(RD->isInterface() &&
+ KnownBase->getAccessSpecifier() == AS_public) &&
// The Microsoft extension __interface does not permit bases that
// are not themselves public interfaces.
// An interface can inherit from a base, as long as it has
// uuid attributes.
-(!RD->getAttr() ||
- Class->hasAttrs())) {
+(!RD->getAttr() || Class->hasAttrs())) {
Diag(KnownBase->getLocStart(), diag::err_invalid_base_in_interface)
<< getRecordDiagFromTagKind(RD->getTagKind()) << RD->getName()
<< RD->getSourceRange();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
ioeric added inline comments.
Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:39
+ /// Handles the source replacements that are produced by a refactoring
action.
+ virtual void handle(AtomicChanges SourceReplacements) = 0;
+};
arphaman wrote:
> ioeric wrote:
> > I think this interface is specific to some refactoring rules and should be
> > pushed down to derived classes.
> Are you talking about derived classes of `RefactoringResultConsumer`? So
> something like
>
> ```
> class RefactoringResultConsumer {
> virtual void handleInvocationError(llvm::Error Err) = 0;
> };
>
> class RefactoringResultSourceReplacementConsumer: RefactoringResultConsumer {
> virtual void handle(AtomicChanges SourceReplacements) = 0;
> };
> ```
>
> If yes, can you please clarify how the rule can call `handle` if it's in a
> subclass of `RefactoringResultConsumer`?
>
Sorry, I thought the `handle` interface was dispatched by template.
Maybe we can have default implementation of rule-specific handlers, e.g.
generate errors, in the base class? Derived classes can implement handlers that
they care about and ignore others.
Repository:
rL LLVM
https://reviews.llvm.org/D37291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
arphaman added inline comments.
Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:39
+ /// Handles the source replacements that are produced by a refactoring
action.
+ virtual void handle(AtomicChanges SourceReplacements) = 0;
+};
ioeric wrote:
> arphaman wrote:
> > ioeric wrote:
> > > I think this interface is specific to some refactoring rules and should
> > > be pushed down to derived classes.
> > Are you talking about derived classes of `RefactoringResultConsumer`? So
> > something like
> >
> > ```
> > class RefactoringResultConsumer {
> > virtual void handleInvocationError(llvm::Error Err) = 0;
> > };
> >
> > class RefactoringResultSourceReplacementConsumer: RefactoringResultConsumer
> > {
> > virtual void handle(AtomicChanges SourceReplacements) = 0;
> > };
> > ```
> >
> > If yes, can you please clarify how the rule can call `handle` if it's in a
> > subclass of `RefactoringResultConsumer`?
> >
> Sorry, I thought the `handle` interface was dispatched by template.
>
> Maybe we can have default implementation of rule-specific handlers, e.g.
> generate errors, in the base class? Derived classes can implement handlers
> that they care about and ignore others.
Sure, I will add default implementations for `handle(...)`.
I'm not sure about `handle...Error(Error)` though because `llvm::Error` forces
some form of handling, and I don't want to use a generic stub that will silence
the `llvm::Error` as it won't be that useful. The errors will be handled
differently by different clients anyway, like clang-refactor might output the
error to stderr, and clangd might either try to notify the user or silently
swallow the error.
Repository:
rL LLVM
https://reviews.llvm.org/D37291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] r312240 - Build LLVM with -Wstrict-prototypes enabled
Author: arphaman
Date: Thu Aug 31 06:23:24 2017
New Revision: 312240
URL: http://llvm.org/viewvc/llvm-project?rev=312240&view=rev
Log:
Build LLVM with -Wstrict-prototypes enabled
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
Modified:
libunwind/trunk/src/config.h
libunwind/trunk/src/unwind_ext.h
Modified: libunwind/trunk/src/config.h
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/config.h?rev=312240&r1=312239&r2=312240&view=diff
==
--- libunwind/trunk/src/config.h (original)
+++ libunwind/trunk/src/config.h Thu Aug 31 06:23:24 2017
@@ -119,9 +119,9 @@
#ifdef __cplusplus
extern "C" {
#endif
-extern bool logAPIs();
-extern bool logUnwinding();
-extern bool logDWARF();
+extern bool logAPIs(void);
+extern bool logUnwinding(void);
+extern bool logDWARF(void);
#ifdef __cplusplus
}
#endif
Modified: libunwind/trunk/src/unwind_ext.h
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/unwind_ext.h?rev=312240&r1=312239&r2=312240&view=diff
==
--- libunwind/trunk/src/unwind_ext.h (original)
+++ libunwind/trunk/src/unwind_ext.h Thu Aug 31 06:23:24 2017
@@ -23,7 +23,7 @@ extern "C" {
// implemented elsewhere.
extern struct _Unwind_FunctionContext *
-__Unwind_SjLj_GetTopOfFunctionStack();
+__Unwind_SjLj_GetTopOfFunctionStack(void);
extern void
__Unwind_SjLj_SetTopOfFunctionStack(struct _Unwind_FunctionContext *fc);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
arphaman updated this revision to Diff 113397.
arphaman marked an inline comment as done.
arphaman added a comment.
- Add default implementation for `handle()`
- Merge two error handling functions into one
https://reviews.llvm.org/D37291
Files:
include/clang/Tooling/Refactoring/RefactoringActionRule.h
include/clang/Tooling/Refactoring/RefactoringActionRules.h
include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h
include/clang/Tooling/Refactoring/RefactoringResultConsumer.h
unittests/Tooling/RefactoringActionRulesTest.cpp
Index: unittests/Tooling/RefactoringActionRulesTest.cpp
===
--- unittests/Tooling/RefactoringActionRulesTest.cpp
+++ unittests/Tooling/RefactoringActionRulesTest.cpp
@@ -35,8 +35,24 @@
Expected>
createReplacements(const std::unique_ptr &Rule,
RefactoringRuleContext &Context) {
- return cast(*Rule).createSourceReplacements(
- Context);
+ class Consumer final : public RefactoringResultConsumer {
+void handleInitiationFailure() override {
+ Result = Expected>(None);
+}
+
+void handleError(llvm::Error Err) override { Result = std::move(Err); }
+
+void handle(AtomicChanges SourceReplacements) override {
+ Result = std::move(SourceReplacements);
+}
+
+ public:
+Optional>> Result;
+ };
+
+ Consumer C;
+ Rule->invoke(C, Context);
+ return std::move(*C.Result);
}
TEST_F(RefactoringActionRulesTest, MyFirstRefactoringRule) {
Index: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h
===
--- /dev/null
+++ include/clang/Tooling/Refactoring/RefactoringResultConsumer.h
@@ -0,0 +1,74 @@
+//===--- RefactoringResultConsumer.h - Clang refactoring library --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_REFACTOR_REFACTORING_RESULT_CONSUMER_H
+#define LLVM_CLANG_TOOLING_REFACTOR_REFACTORING_RESULT_CONSUMER_H
+
+#include "clang/Basic/LLVM.h"
+#include "clang/Tooling/Refactoring/AtomicChange.h"
+#include "llvm/Support/Error.h"
+
+namespace clang {
+namespace tooling {
+
+/// An abstract interface that consumes the various refactoring results that can
+/// be produced by refactoring actions.
+///
+/// A valid refactoring result must be handled by a \c handle method.
+class RefactoringResultConsumer {
+public:
+ virtual ~RefactoringResultConsumer() {}
+
+ /// Handles an initiation failure. An action typically fails to initiate when
+ /// the source selection has no overlap at all with any relevant AST nodes.
+ virtual void handleInitiationFailure() = 0;
+
+ /// Handles an initation or an invication error. An initiation error typically
+ /// has a \c DiagnosticError payload that describes why initation failed.
+ virtual void handleError(llvm::Error Err) = 0;
+
+ /// Handles the source replacements that are produced by a refactoring action.
+ virtual void handle(AtomicChanges SourceReplacements) {
+defaultResultHandler();
+ }
+
+private:
+ void defaultResultHandler() {
+handleError(llvm::make_error(
+"unsupported refactoring result", llvm::inconvertibleErrorCode()));
+ }
+};
+
+namespace traits {
+namespace internal {
+
+template struct HasHandle {
+private:
+ template
+ static auto check(ClassT *) -> typename std::is_same<
+ decltype(std::declval().handle(std::declval())), void>::type;
+
+ template static std::false_type check(...);
+
+public:
+ using Type = decltype(check(nullptr));
+};
+
+} // end namespace internal
+
+/// A type trait that returns true iff the given type is a valid refactoring
+/// result.
+template
+struct IsValidRefactoringResult : internal::HasHandle::Type {};
+
+} // end namespace traits
+} // end namespace tooling
+} // end namespace clang
+
+#endif // LLVM_CLANG_TOOLING_REFACTOR_REFACTORING_RESULT_CONSUMER_H
Index: include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h
===
--- include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h
+++ include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h
@@ -13,6 +13,7 @@
#include "clang/Basic/LLVM.h"
#include "clang/Tooling/Refactoring/RefactoringActionRule.h"
#include "clang/Tooling/Refactoring/RefactoringActionRuleRequirements.h"
+#include "clang/Tooling/Refactoring/RefactoringResultConsumer.h"
#include "clang/Tooling/Refactoring/RefactoringRuleContext.h"
#include "llvm/Support/Error.h"
#include
@@ -22,39 +23,20 @@
namespace refactoring_action_rules {
namespace internal {
-/// A wrapper around a specific refactoring action rule that calls a generic
-/// 'perform' method from the specific refactoring method.
-te
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
arphaman added inline comments.
Comment at: unittests/Tooling/RefactoringActionRulesTest.cpp:39
+ class Consumer final : public RefactoringResultConsumer {
+void handleInitiationFailure() {
+ Result = Expected>(None);
ioeric wrote:
> Can we probably have default error handling in the base class so that we
> don't need to re-implement these for every derived consumer. I would expect
> the error handling for initiation and invocation to be similar in different
> consumers.
I've merge the two error functions into one, but I'm reluctant to add default
implementation for them because of the reasons that I've mentioned in my
previous inline comment.
https://reviews.llvm.org/D37291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37318: [libcxx] [www] Cleanup links to be https.
mclow.lists accepted this revision. mclow.lists added a comment. This revision is now accepted and ready to land. LGTM; thanks! https://reviews.llvm.org/D37318 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37024: [libcxx] [test] Cleanup nullopt_t tests
mclow.lists accepted this revision. mclow.lists added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D37024 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
ioeric accepted this revision.
ioeric added a comment.
This revision is now accepted and ready to land.
LGTM.
@klimek Manuel, would you like to take a look? This addresses your comment
https://reviews.llvm.org/D36075#854075
Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:30
+ /// the source selection has no overlap at all with any relevant AST nodes.
+ virtual void handleInitiationFailure() = 0;
+
Just wondering if it is possible to provide more information about the
initiation failure to the handler?
Comment at: unittests/Tooling/RefactoringActionRulesTest.cpp:39
+ class Consumer final : public RefactoringResultConsumer {
+void handleInitiationFailure() {
+ Result = Expected>(None);
arphaman wrote:
> ioeric wrote:
> > Can we probably have default error handling in the base class so that we
> > don't need to re-implement these for every derived consumer. I would expect
> > the error handling for initiation and invocation to be similar in different
> > consumers.
> I've merge the two error functions into one, but I'm reluctant to add default
> implementation for them because of the reasons that I've mentioned in my
> previous inline comment.
Ok. Makes sense.
https://reviews.llvm.org/D37291
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36720: [libc++] Prevent stale site configuration headers
mclow.lists added a comment. This looks reasonable to me. https://reviews.llvm.org/D36720 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D35732: Update system_error tests for more platforms.
mclow.lists added inline comments. Comment at: test/std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp:35 +// Exact message format varies by platform. +LIBCPP_ASSERT(msg == "Unknown error -1" || msg == "Unknown error" || + msg == "Unknown error: -1"); How about testing for "starts with 'Unknown error'" instead? Repository: rL LLVM https://reviews.llvm.org/D35732 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D35470: [libcxx] Implement pointer_traits::to_address as in P0653R0
mclow.lists added a comment. This feature has not been added to the draft standard yet, so I'm reluctant to add it to libc++. I appreciate the patch, and we may adopt it in the future, but not now. https://reviews.llvm.org/D35470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
klimek added a comment. Thanks! I think this makes the code easier to understand. Now my remaining question is why the ResultType is templates vs. also being an interface (sorry for being late, was out on vacation the past 2 weeks :) Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:30 + /// the source selection has no overlap at all with any relevant AST nodes. + virtual void handleInitiationFailure() = 0; + ioeric wrote: > Just wondering if it is possible to provide more information about the > initiation failure to the handler? Also, why is initiationFailure not simply handled via handleError? https://reviews.llvm.org/D37291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
iid_iunknown created this revision. Herald added subscribers: kristof.beyls, aemerson. Currently object format is taken from the default target triple. For toolchains with a non-COFF default target this may result in an object format inappropriate for pc-windows and lead to compilation issues. For example, the default triple `aarch64-linux-elf` may produce something like `aarch64-pc-windows-msvc19.0.24215-elf` in CL mode. Clang creates `MicrosoftARM64TargetInfo` for such triple with data layout `e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128`. On the other hand, the AArch64 backend in `computeDataLayout` detects a non-COFF target and selects `e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128` as data layout for little endian. Different layouts used by clang and the backend cause an error: error: backend data layout 'e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128' does not match expected target description 'e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128' This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a default target. This patch enforces COFF in CL mode. Repository: rL LLVM https://reviews.llvm.org/D37336 Files: lib/Driver/Driver.cpp Index: lib/Driver/Driver.cpp === --- lib/Driver/Driver.cpp +++ lib/Driver/Driver.cpp @@ -663,6 +663,7 @@ T.setOS(llvm::Triple::Win32); T.setVendor(llvm::Triple::PC); T.setEnvironment(llvm::Triple::MSVC); +T.setObjectFormat(llvm::Triple::COFF); DefaultTargetTriple = T.str(); } if (const Arg *A = Args.getLastArg(options::OPT_target)) Index: lib/Driver/Driver.cpp === --- lib/Driver/Driver.cpp +++ lib/Driver/Driver.cpp @@ -663,6 +663,7 @@ T.setOS(llvm::Triple::Win32); T.setVendor(llvm::Triple::PC); T.setEnvironment(llvm::Triple::MSVC); +T.setObjectFormat(llvm::Triple::COFF); DefaultTargetTriple = T.str(); } if (const Arg *A = Args.getLastArg(options::OPT_target)) ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36487: Emit section information for extern variables.
erichkeane added a comment. Hey @efriedma : Did you get a chance to take a look at this? She got the langref changes in, so it is just waiting on this. https://reviews.llvm.org/D36487 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312244 - Driver: extract ARCMT flag construction (NFC)
Author: compnerd
Date: Thu Aug 31 08:35:01 2017
New Revision: 312244
URL: http://llvm.org/viewvc/llvm-project?rev=312244&view=rev
Log:
Driver: extract ARCMT flag construction (NFC)
Extract the ARC migration tool flag handling into its own function.
This simplifies the flow of the clang frontend command line construction
function. NFC.
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=312244&r1=312243&r2=312244&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Aug 31 08:35:01 2017
@@ -2119,6 +2119,78 @@ static void RenderOpenCLOptions(const Ar
CmdArgs.push_back(Args.MakeArgString(A->getOption().getPrefixedName()));
}
+static void RenderARCMigrateToolOptions(const Driver &D, const ArgList &Args,
+ArgStringList &CmdArgs) {
+ bool ARCMTEnabled = false;
+ if (!Args.hasArg(options::OPT_fno_objc_arc, options::OPT_fobjc_arc)) {
+if (const Arg *A = Args.getLastArg(options::OPT_ccc_arcmt_check,
+ options::OPT_ccc_arcmt_modify,
+ options::OPT_ccc_arcmt_migrate)) {
+ ARCMTEnabled = true;
+ switch (A->getOption().getID()) {
+ default: llvm_unreachable("missed a case");
+ case options::OPT_ccc_arcmt_check:
+CmdArgs.push_back("-arcmt-check");
+break;
+ case options::OPT_ccc_arcmt_modify:
+CmdArgs.push_back("-arcmt-modify");
+break;
+ case options::OPT_ccc_arcmt_migrate:
+CmdArgs.push_back("-arcmt-migrate");
+CmdArgs.push_back("-mt-migrate-directory");
+CmdArgs.push_back(A->getValue());
+
+Args.AddLastArg(CmdArgs, options::OPT_arcmt_migrate_report_output);
+Args.AddLastArg(CmdArgs, options::OPT_arcmt_migrate_emit_arc_errors);
+break;
+ }
+}
+ } else {
+Args.ClaimAllArgs(options::OPT_ccc_arcmt_check);
+Args.ClaimAllArgs(options::OPT_ccc_arcmt_modify);
+Args.ClaimAllArgs(options::OPT_ccc_arcmt_migrate);
+ }
+
+ if (const Arg *A = Args.getLastArg(options::OPT_ccc_objcmt_migrate)) {
+if (ARCMTEnabled)
+ D.Diag(diag::err_drv_argument_not_allowed_with)
+ << A->getAsString(Args) << "-ccc-arcmt-migrate";
+
+CmdArgs.push_back("-mt-migrate-directory");
+CmdArgs.push_back(A->getValue());
+
+if (!Args.hasArg(options::OPT_objcmt_migrate_literals,
+ options::OPT_objcmt_migrate_subscripting,
+ options::OPT_objcmt_migrate_property)) {
+ // None specified, means enable them all.
+ CmdArgs.push_back("-objcmt-migrate-literals");
+ CmdArgs.push_back("-objcmt-migrate-subscripting");
+ CmdArgs.push_back("-objcmt-migrate-property");
+} else {
+ Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_literals);
+ Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_subscripting);
+ Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_property);
+}
+ } else {
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_literals);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_subscripting);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_property);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_all);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_readonly_property);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_readwrite_property);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_property_dot_syntax);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_annotation);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_instancetype);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_nsmacros);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_protocol_conformance);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_atomic_property);
+Args.AddLastArg(CmdArgs,
options::OPT_objcmt_returns_innerpointer_property);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_ns_nonatomic_iosonly);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_migrate_designated_init);
+Args.AddLastArg(CmdArgs, options::OPT_objcmt_whitelist_dir_path);
+ }
+}
+
void Clang::ConstructJob(Compilation &C, const JobAction &JA,
const InputInfo &Output, const InputInfoList &Inputs,
const ArgList &Args, const char *LinkingOutput) const
{
@@ -3036,75 +3108,7 @@ void Clang::ConstructJob(Compilation &C,
Args.AddLastArg(CmdArgs, options::OPT_working_directory);
- bool ARCMTEnabled = false;
- if (!Args.hasArg(options::OPT_fno_objc_arc, options::OPT_fobjc_arc)) {
-if (const Arg *A = Args.getLastArg(options::OPT_ccc_arcmt_check,
- opti
[libunwind] r312246 - Revert r312240
Author: arphaman
Date: Thu Aug 31 08:51:23 2017
New Revision: 312246
URL: http://llvm.org/viewvc/llvm-project?rev=312246&view=rev
Log:
Revert r312240
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
Modified:
libunwind/trunk/src/config.h
libunwind/trunk/src/unwind_ext.h
Modified: libunwind/trunk/src/config.h
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/config.h?rev=312246&r1=312245&r2=312246&view=diff
==
--- libunwind/trunk/src/config.h (original)
+++ libunwind/trunk/src/config.h Thu Aug 31 08:51:23 2017
@@ -119,9 +119,9 @@
#ifdef __cplusplus
extern "C" {
#endif
-extern bool logAPIs(void);
-extern bool logUnwinding(void);
-extern bool logDWARF(void);
+extern bool logAPIs();
+extern bool logUnwinding();
+extern bool logDWARF();
#ifdef __cplusplus
}
#endif
Modified: libunwind/trunk/src/unwind_ext.h
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/unwind_ext.h?rev=312246&r1=312245&r2=312246&view=diff
==
--- libunwind/trunk/src/unwind_ext.h (original)
+++ libunwind/trunk/src/unwind_ext.h Thu Aug 31 08:51:23 2017
@@ -23,7 +23,7 @@ extern "C" {
// implemented elsewhere.
extern struct _Unwind_FunctionContext *
-__Unwind_SjLj_GetTopOfFunctionStack(void);
+__Unwind_SjLj_GetTopOfFunctionStack();
extern void
__Unwind_SjLj_SetTopOfFunctionStack(struct _Unwind_FunctionContext *fc);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
hans added a comment. Seems reasonable, but should probably have a test. > This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a > default target. But why isn't that failure showing on some buildbot, then? Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
iid_iunknown added a comment. In https://reviews.llvm.org/D37336#857802, @hans wrote: > But why isn't that failure showing on some buildbot, then? The test needs `system-windows` to run: // REQUIRES: system-windows There is no windows buildbot that builds clang defaulted to the AArch64 target. Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
hans added a comment. In https://reviews.llvm.org/D37336#857814, @iid_iunknown wrote: > In https://reviews.llvm.org/D37336#857802, @hans wrote: > > > But why isn't that failure showing on some buildbot, then? > > > The test needs `system-windows` to run: > > // REQUIRES: system-windows > > > There is no windows buildbot that builds clang defaulted to the AArch64 > target. I see. Do you think you can write a test for your patch that will work on the buildbots we have? Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37341: [Sema] Fix an assert-on-invalid by avoiding function template specialisation deduction for invalid functions with fabricated template arguments
arphaman created this revision.
This patch fixes an an assertion that previously occurred for the following
sample:
template
struct SourceSelectionRequirement {
template
OutputT evaluateSelectionRequirement(InputT &&Value) {
}
};
template
OutputT SourceSelectionRequirement::evaluateSelectionRequirement(InputT &&Value) {
return Value;
}
Clang asserted when it was trying to deduce the function template
specialisation for `evaluateSelectionRequirement`, because it was trying to do
deduction with the template specialisation `` and `template ` which have different template depth.
I initially fixed the issue by setting the right depth, during the deduction,
but wasn't happy with the results (we produced two errors, the second one
complained about failed deduction). Thus I changed my approach to the one
that's presented in this patch - we can detect if the template parameters are
fabricated and then avoid the deduction. This approach avoids the second error
while fixing the assertion. It also fixed a redundant error `FIXME` in
`SemaTemplate/explicit-specialization-member.cpp` (Basically removed a
redundant deduction error).
Thanks for taking a look
Repository:
rL LLVM
https://reviews.llvm.org/D37341
Files:
lib/Sema/SemaDecl.cpp
test/SemaTemplate/deduction-crash.cpp
test/SemaTemplate/explicit-specialization-member.cpp
Index: test/SemaTemplate/explicit-specialization-member.cpp
===
--- test/SemaTemplate/explicit-specialization-member.cpp
+++ test/SemaTemplate/explicit-specialization-member.cpp
@@ -38,24 +38,20 @@
template
template
- void Baz::bar() { // expected-note {{couldn't infer template argument
'N'}}
+ void Baz::bar() {
}
- // FIXME: We shouldn't try to match this against a prior declaration if
- // template parameter matching failed.
template
- void Baz::bar<0>() { // expected-error {{cannot specialize a member of an
unspecialized template}} \
- // expected-error {{no function template matches}}
+ void Baz::bar<0>() { // expected-error {{cannot specialize a member of an
unspecialized template}}
}
}
namespace PR19340 {
template struct Helper {
- template static void func(const T *m) {} // expected-note {{failed
template argument deduction}}
+ template static void func(const T *m) {}
};
-template void Helper::func<2>() {} // expected-error {{cannot
specialize a member}} \
- // expected-error {{no
function template matches}}
+template void Helper::func<2>() {} // expected-error {{cannot
specialize a member}}
}
namespace SpecLoc {
Index: test/SemaTemplate/deduction-crash.cpp
===
--- test/SemaTemplate/deduction-crash.cpp
+++ test/SemaTemplate/deduction-crash.cpp
@@ -144,3 +144,20 @@
template int n; // expected-error +{{}}
expected-note {{}}
int k = n;
}
+
+namespace deduceFunctionSpecializationForInvalidOutOfLineFunction {
+
+template
+struct SourceSelectionRequirement {
+ template
+ OutputT evaluateSelectionRequirement(InputT &&Value) {
+ }
+};
+
+template
+OutputT SourceSelectionRequirement::
+evaluateSelectionRequirement(InputT &&Value) { // expected-error
{{cannot specialize a member of an unspecialized template}}
+ return Value;
+}
+
+}
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -8195,6 +8195,7 @@
FunctionTemplateDecl *FunctionTemplate = nullptr;
bool isMemberSpecialization = false;
bool isFunctionTemplateSpecialization = false;
+ bool HasFabricatedTemplateSpecializationTemplateParams = false;
bool isDependentClassScopeExplicitSpecialization = false;
bool HasExplicitTemplateArgs = false;
@@ -8303,6 +8304,8 @@
} else {
// This is a function template specialization.
isFunctionTemplateSpecialization = true;
+if (Invalid && TemplateParams->getLAngleLoc().isInvalid())
+ HasFabricatedTemplateSpecializationTemplateParams = true;
// For source fidelity, store all the template param lists.
if (TemplateParamLists.size() > 0)
NewFD->setTemplateParameterListsInfo(Context, TemplateParamLists);
@@ -8874,7 +8877,8 @@
diag::ext_function_specialization_in_class :
diag::err_function_specialization_in_class)
<< NewFD->getDeclName();
- } else if (CheckFunctionTemplateSpecialization(NewFD,
+ } else if (!HasFabricatedTemplateSpecializationTemplateParams &&
+ CheckFunctionTemplateSpecialization(NewFD,
(HasExplicitTemplateArgs ? &TemplateArgs
: nullptr),
Previous))
Index: test/SemaTemplate/explicit-speciali
[PATCH] D37104: [libc++] PR34298: Change std::function constructor and move assignment operator SFINAE checks to allow std::function with an incomplete return type
mclow.lists added inline comments.
Comment at:
test/libcxx/utilities/function.objects/func.require/incomplete_return_type.pass.cpp:22
+int main() {
+ return 0;
+}
Is copy constructible; can be instantiated.
static_assert( std::is_copy_constructible::value, ""
);
IncompleteReturnType ir;
assert( ir.fn == nullptr );
Repository:
rL LLVM
https://reviews.llvm.org/D37104
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
arphaman added inline comments. Comment at: include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:30 + /// the source selection has no overlap at all with any relevant AST nodes. + virtual void handleInitiationFailure() = 0; + klimek wrote: > ioeric wrote: > > Just wondering if it is possible to provide more information about the > > initiation failure to the handler? > Also, why is initiationFailure not simply handled via handleError? Initiation failure is not really an error as such. It corresponds to a selection in an editor that doesn't overlap with any interesting AST at all. In the editor, the rule will fail to be initiated without a concrete error when we request it, or will be skipped when the editor is querying available actions for some selection. Therefore it doesn't really have any other information. However, your comments made me reconsider this particular design point. We should emit an error for this kind of initiation failure as well, and `clang-refactor` will benefit by default as it will consume it and display it. The editor clients will be able to avoid this kind of error if they want by inspecting the selection constraint prior to invocation. I will remove this method and use just `handleError` when committing. https://reviews.llvm.org/D37291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation
craig.topper added inline comments.
Comment at: lib/CodeGen/CGBuiltin.cpp:7414
+ StringRef FeatureStr = cast(FeatureExpr)->getString();
+ return EmitX86CpuSupports({FeatureStr});
+}
You shouldn't need curly braces here. ArrayRef has a conversion constructor
that should take care of this.
Comment at: lib/CodeGen/CGBuiltin.cpp:7456
+
+ unsigned FeaturesMask = 0;
+
Declare as uint32_t?
Comment at: lib/CodeGen/CGBuiltin.cpp:7494
+assert(Feature != X86Features::MAX && "Invalid feature!");
+FeaturesMask |= (1ULL << Feature);
+ }
No need for 64-bit OR here. FeaturesMask is only 32-bits.
Comment at: lib/CodeGen/CGBuiltin.cpp:7525
const CallExpr *E) {
+ if (BuiltinID == X86::BI__builtin_cpu_is)
+return EmitX86CpuIs(E);
I think you have the builtin handline at the top and in the switch. Bad rebase?
https://reviews.llvm.org/D36707
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37291: [refactor] Use a RefactoringResultConsumer instead of tagged refactoring rule classes
arphaman added a comment. In https://reviews.llvm.org/D37291#857727, @klimek wrote: > Thanks! I think this makes the code easier to understand. Now my remaining > question is why the ResultType is templates vs. also being an interface > (sorry for being late, was out on vacation the past 2 weeks :) ResultType is typically a vector of `AtomicChange` or `SymbolOccurrences` which we can't subclass from an interface. Or are you wondering if `AtomicChange` and `SymbolOccurrence` should subclass from a common interface? It could potentially be useful, but I'm not sure if there could be that many methods that would go into the interface. https://reviews.llvm.org/D37291 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation
erichkeane updated this revision to Diff 113424.
erichkeane marked 4 inline comments as done.
https://reviews.llvm.org/D36707
Files:
lib/CodeGen/CGBuiltin.cpp
lib/CodeGen/CodeGenFunction.h
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -3857,6 +3857,10 @@
void AddObjCARCExceptionMetadata(llvm::Instruction *Inst);
llvm::Value *GetValueForARMHint(unsigned BuiltinID);
+ llvm::Value *EmitX86CpuIs(const CallExpr *E);
+ llvm::Value *EmitX86CpuIs(StringRef CPUStr);
+ llvm::Value *EmitX86CpuSupports(const CallExpr *E);
+ llvm::Value *EmitX86CpuSupports(ArrayRef FeatureStrs);
};
/// Helper class with most of the code for saving a value for a
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -7288,9 +7288,13 @@
return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
}
-static Value *EmitX86CpuIs(CodeGenFunction &CGF, const CallExpr *E) {
+Value *CodeGenFunction::EmitX86CpuIs(const CallExpr *E) {
const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
StringRef CPUStr = cast(CPUExpr)->getString();
+ return EmitX86CpuIs(CPUStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
// This enum contains the vendor, type, and subtype enums from the
// runtime library concatenated together. The _START labels mark
@@ -7332,7 +7336,9 @@
StringSwitch(CPUStr)
.Case("amd", AMD)
.Case("amdfam10h", AMDFAM10H)
+ .Case("amdfam10", AMDFAM10H)
.Case("amdfam15h", AMDFAM15H)
+ .Case("amdfam15", AMDFAM15H)
.Case("atom", INTEL_BONNELL)
.Case("barcelona", AMDFAM10H_BARCELONA)
.Case("bdver1", AMDFAM15H_BDVER1)
@@ -7360,7 +7366,7 @@
.Case("westmere", INTEL_COREI7_WESTMERE)
.Case("znver1", AMDFAM17H_ZNVER1);
- llvm::Type *Int32Ty = CGF.Builder.getInt32Ty();
+ llvm::Type *Int32Ty = Builder.getInt32Ty();
// Matching the struct layout from the compiler-rt/libgcc structure that is
// filled in:
@@ -7372,7 +7378,7 @@
llvm::ArrayType::get(Int32Ty, 1));
// Grab the global __cpu_model.
- llvm::Constant *CpuModel = CGF.CGM.CreateRuntimeVariable(STy, "__cpu_model");
+ llvm::Constant *CpuModel = CGM.CreateRuntimeVariable(STy, "__cpu_model");
// Calculate the index needed to access the correct field based on the
// range. Also adjust the expected value.
@@ -7394,16 +7400,133 @@
ConstantInt::get(Int32Ty, 0),
ConstantInt::get(Int32Ty, Index)
};
- llvm::Value *CpuValue = CGF.Builder.CreateGEP(STy, CpuModel, Idxs);
- CpuValue = CGF.Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
+ llvm::Value *CpuValue = Builder.CreateGEP(STy, CpuModel, Idxs);
+ CpuValue = Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
// Check the value of the field against the requested value.
- return CGF.Builder.CreateICmpEQ(CpuValue,
+ return Builder.CreateICmpEQ(CpuValue,
llvm::ConstantInt::get(Int32Ty, Value));
}
+Value *CodeGenFunction::EmitX86CpuSupports(const CallExpr *E) {
+ const Expr *FeatureExpr = E->getArg(0)->IgnoreParenCasts();
+ StringRef FeatureStr = cast(FeatureExpr)->getString();
+ return EmitX86CpuSupports(FeatureStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuSupports(ArrayRef FeatureStrs) {
+ // TODO: When/if this becomes more than x86 specific then use a TargetInfo
+ // based mapping.
+ // Processor features and mapping to processor feature value.
+ enum X86Features {
+CMOV = 0,
+MMX,
+POPCNT,
+SSE,
+SSE2,
+SSE3,
+SSSE3,
+SSE4_1,
+SSE4_2,
+AVX,
+AVX2,
+SSE4_A,
+FMA4,
+XOP,
+FMA,
+AVX512F,
+BMI,
+BMI2,
+AES,
+PCLMUL,
+AVX512VL,
+AVX512BW,
+AVX512DQ,
+AVX512CD,
+AVX512ER,
+AVX512PF,
+AVX512VBMI,
+AVX512IFMA,
+AVX5124VNNIW,
+AVX5124FMAPS,
+AVX512VPOPCNTDQ,
+MAX
+ };
+
+ uint32_t FeaturesMask = 0;
+
+ for (const StringRef &FeatureStr : FeatureStrs) {
+X86Features Feature =
+StringSwitch(FeatureStr)
+.Case("cmov", X86Features::CMOV)
+.Case("mmx", X86Features::MMX)
+.Case("popcnt", X86Features::POPCNT)
+.Case("sse", X86Features::SSE)
+.Case("sse2", X86Features::SSE2)
+.Case("sse3", X86Features::SSE3)
+.Case("ssse3", X86Features::SSSE3)
+.Case("sse4.1", X86Features::SSE4_1)
+.Case("sse4.2", X86Features::SSE4_2)
+.Case("avx", X86Features::AVX)
+.Case("avx2", X86Features::AVX2)
+.Case("sse4a", X86Features::SSE4_A)
+.Case("fma4", X86Features::FMA4)
+.Case("xop", X86Features::XOP)
+.Case("fma", X86Features::FMA)
+.Cas
[PATCH] D37187: [Analyzer] Fix Bug 25609 - Assertion UNREACHABLE: 'Unexpected ProgramPoint' with widen-loops=true
MTC updated this revision to Diff 113427.
MTC added a comment.
(1) Modify the description of the bug report
(2) Update loop-widening-notes.c
(3) PathDiagnosticLocation::create() - Use the location of TerminatorCondition.
https://reviews.llvm.org/D37187
Files:
lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
lib/StaticAnalyzer/Core/PathDiagnostic.cpp
test/Analysis/loop-widening-notes.c
Index: test/Analysis/loop-widening-notes.c
===
--- /dev/null
+++ test/Analysis/loop-widening-notes.c
@@ -0,0 +1,54 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha -analyzer-max-loop 2
-analyzer-config widen-loops=true -analyzer-output=text -verify %s
+
+int *p_a;
+int bar();
+int flag_a;
+int test_for_bug_25609() {
+ if (p_a == 0) // expected-note {{Assuming 'p_a' is equal to null}}
expected-note {{Taking true branch}}
+bar();
+ for (int i = 0; i < flag_a; ++i) {}// expected-note {{Loop condition is
true. Entering loop body}} expected-note {{Reach the maximum loop limit.
Invalidate the value of 'p_a'}} expected-note {{Loop condition is false.
Execution continues on line 10}}
+ *p_a = 25609; // no-crash expected-note {{Dereference of null pointer
(loaded from variable 'p_a')}} expected-warning {{Dereference of null pointer
(loaded from variable 'p_a')}}
+ return *p_a;
+}
+
+int flag_b;
+int while_analyzer_output() {
+ flag_b = 100;
+ int num = 10;
+ while (flag_b-- > 0) { // expected-note {{Loop condition is true. Entering
loop body}} expected-note {{Reach the maximum loop limit. Invalidate the value
of 'num'}} expected-note {{Loop condition is false. Execution continues on line
21}}
+num = flag_b;
+ }
+ if (num < 0) // expected-note {{Assuming 'num' is >= 0}} expected-note
{{Taking false branch}}
+flag_b = 0;
+ else if (num >= 1) // expected-note {{Assuming 'num' is < 1}} expected-note
{{Taking false branch}}
+flag_b = 50;
+ else
+flag_b = 100;
+ return flag_b / num; // no-crash expected-warning {{Division by zero}}
expected-note {{Division by zero}}
+}
+
+int flag_c;
+int do_while_analyzer_output() {
+ int num = 10;
+ do { // expected-note {{Loop condition is true. Execution continues on line
34}} expected-note {{Loop condition is false. Exiting loop}}
+num--;
+ } while (flag_c-- > 0); //expected-note {{Reach the maximum loop limit.
Invalidate the value of 'num'}}
+ int local = 0;
+ if (num == 0) // expected-note{{Assuming 'num' is equal to 0}}
expected-note{{Taking true branch}}
+local = 10 / num; // no-crash expected-note {{Division by zero}}
expected-warning {{Division by zero}}
+ return local;
+}
+
+int flag_d;
+int test_for_loop() {
+ int num = 10;
+ int tmp = 0;
+ for (int i = 0; ++tmp, // expected-note {{Loop condition is true. Entering
loop body}} expected-note {{Reach the maximum loop limit. Invalidate the value
of 'num'}} expected-note {{Loop condition is false. Execution continues on line
51}}
+ i < flag_d;
+ ++i) {
+++num;
+ }
+ if (num == 0) // expected-note {{Assuming 'num' is equal to 0}}
expected-note {{Taking true branch}}
+flag_d += tmp;
+ return flag_d / num; // no-crash expected-warning {{Division by zero}}
expected-note {{Division by zero}}
+}
Index: lib/StaticAnalyzer/Core/PathDiagnostic.cpp
===
--- lib/StaticAnalyzer/Core/PathDiagnostic.cpp
+++ lib/StaticAnalyzer/Core/PathDiagnostic.cpp
@@ -690,6 +690,8 @@
return getLocationForCaller(CEE->getCalleeContext(),
CEE->getLocationContext(),
SMng);
+ } else if (Optional BE = P.getAs()) {
+S = BE->getBlock()->getTerminatorCondition();
} else {
llvm_unreachable("Unexpected ProgramPoint");
}
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -647,6 +647,12 @@
R->printPretty(os);
}
}
+ } else if (StoreSite->getLocation().getAs()) {
+os << "Reach the maximum loop limit.";
+os << " Invalidate the value of ";
+if (R->canPrintPretty()) {
+ R->printPretty(os);
+}
}
if (os.str().empty()) {
Index: test/Analysis/loop-widening-notes.c
===
--- /dev/null
+++ test/Analysis/loop-widening-notes.c
@@ -0,0 +1,54 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha -analyzer-max-loop 2 -analyzer-config widen-loops=true -analyzer-output=text -verify %s
+
+int *p_a;
+int bar();
+int flag_a;
+int test_for_bug_25609() {
+ if (p_a == 0) // expected-note {{Assuming 'p_a' is equal to null}} expected-note {{Taking true branch}}
+bar();
+ for (int i = 0; i < flag_a; ++i) {}// expected-note {{Loop condition is true. Enterin
[PATCH] D37187: [Analyzer] Fix Bug 25609 - Assertion UNREACHABLE: 'Unexpected ProgramPoint' with widen-loops=true
MTC marked an inline comment as done.
MTC added inline comments.
Comment at: lib/StaticAnalyzer/Core/PathDiagnostic.cpp:694
+ } else if (Optional BE = P.getAs()) {
+CFGElement BlockFront = BE->getBlock()->front();
+if (BlockFront.getKind() == CFGElement::Statement) {
szepet wrote:
> I think it would be more correct to use the location what is used in case of
> the BlockEdge. (So on the entranced block terminator condition.) The reason
> is because the BlockEntrance display message will be displayed before the
> message of the BlockEdge (since it is an "earlier" node in the
> ExplodedGraph). So it would result that if check these notes in a viewer then
> the earlier note would belong to the later location which could be confusing.
Yes, it would be better to use the location of the TerminatorCondition :D.
https://reviews.llvm.org/D37187
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D34367: CodeGen: Fix address space of indirect function argument
yaxunl added inline comments.
Comment at: lib/CodeGen/CGCall.cpp:3861
< Align.getQuantity()) ||
(ArgInfo.getIndirectByVal() && (RVAddrSpace != ArgAddrSpace))) {
// Create an aligned temporary, and copy to it.
yaxunl wrote:
> rjmccall wrote:
> > yaxunl wrote:
> > > rjmccall wrote:
> > > > This should be comparing AST address spaces.
> > > The AST address space of RV cannot be obtained through
> > > `CGFunctionInfo::const_arg_iterator it` and `it->type` since `it->type`
> > > takes type of
> > >
> > >
> > > ```
> > > ImplicitCastExpr 0x60a9ff0 'struct S':'struct S'
> > > `-DeclRefExpr 0x60a9f28 '__global struct S':'__global struct
> > > S' lvalue Var 0x607efb0
> > > ```
> > >
> > > and the original addr space is lost due to LValueToRValue cast.
> > >
> > > To get the AST addr space of RV, it seems I need to save the argument
> > > Expr in CallArgList and get it from Expr.
> > >
> > I think your last two comments are related. I'm not sure why we haven't
> > copied into a temporary here, and if we had, the assumption of
> > LangAS::Default would be fine. Would you mind doing the investigation
> > there?
> It seems the backend will insert a temp copy for byval arguments, therefore
> normally a byval argument does not need caller to create a temp copy in LLVM
> IR. An explicit temp copy is only needed for special cases, e.g. alignment
> mismatch with ABI.
>
> For example, the following C program,
>
>
> ```
> struct S {
> long x[100];
> };
>
> struct S g_s;
>
> void f(struct S s);
>
> void g() {
> f(g_s);
> }
>
> ```
>
> will generate the following IR on x86_64:
>
>
> ```
> target triple = "x86_64-unknown-linux-gnu"
>
> %struct.S = type { [100 x i64] }
>
> @g_s = common global %struct.S zeroinitializer, align 8
>
> ; Function Attrs: noinline nounwind optnone
> define void @g() #0 {
> entry:
> call void @f(%struct.S* byval align 8 @g_s)
> ret void
> }
>
> declare void @f(%struct.S* byval align 8) #1
>
> ```
>
> However, the following C program
>
>
> ```
> struct S {
> int x[100];
> };
>
> struct S g_s;
>
> void f(struct S s);
>
> void g() {
> f(g_s);
> }
>
> ```
>
> will generate the following IR
>
>
> ```
> target triple = "x86_64-unknown-linux-gnu"
>
> %struct.S = type { [100 x i32] }
>
> @g_s = common global %struct.S zeroinitializer, align 4
>
> ; Function Attrs: noinline nounwind optnone
> define void @g() #0 {
> entry:
> %byval-temp = alloca %struct.S, align 8
> %0 = bitcast %struct.S* %byval-temp to i8*
> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast (%struct.S* @g_s
> to i8*), i64 400, i32 4, i1 false)
> call void @f(%struct.S* byval align 8 %byval-temp)
> ret void
> }
>
> declare void @f(%struct.S* byval align 8) #1
>
> ```
>
> The temp var is generated by line 3863. The control flow reaches line 3863
> because the alignment of the argument is 4 but the ABI requires it to be 8,
> so a temp is created to match the ABI align requirement.
>
> That means, in the OpenCL example, it is normal that a temp var is not
> generated at line 3848. The temp is supposed to be generated at line 3863
> too, like the C example.
For C++, it is different story, the AST is
```
`-FunctionDecl 0x64abee0 line:9:6 g 'void (void)'
`-CompoundStmt 0x64ac388
`-CallExpr 0x64ac060 'void'
|-ImplicitCastExpr 0x64ac048 'void (*)(struct S)'
| `-DeclRefExpr 0x64abff8 'void (struct S)' lvalue Function
0x64abe20 'f' 'void (struct S)'
`-CXXConstructExpr 0x64ac278 'struct S' 'void (const struct S &)
throw()'
`-ImplicitCastExpr 0x64ac090 'const struct S' lvalue
`-DeclRefExpr 0x64abfd0 'struct S' lvalue Var 0x64ab938 'g_s'
'struct S'
```
The argument is a copy constructor expr, therefore a temporary copy is always
created, which is in alloca addr space.
For C and OpenCL, since there is no copy constructor, the temporary copy is not
created.
https://reviews.llvm.org/D34367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37187: [Analyzer] Fix Bug 25609 - Assertion UNREACHABLE: 'Unexpected ProgramPoint' with widen-loops=true
szepet added a comment. Thanks for the update! It looks good to me! (Probably somebody else (most likely NoQ) will have some additional comment but I think it's great!) https://reviews.llvm.org/D37187 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r312256 - [test] Cleanup nullopt_t tests
Author: caseycarter
Date: Thu Aug 31 10:56:31 2017
New Revision: 312256
URL: http://llvm.org/viewvc/llvm-project?rev=312256&view=rev
Log:
[test] Cleanup nullopt_t tests
* Update specification text from N4387
* Delete not_brace_initializable.fail.cpp: it's redundant with
nullopt_t.fail.cpp
* is_empty implies is_class
* is_literal is deprecated; directly verify that we can create a nullopt_t in a
constexpr context
Differential Revision: D37024
Removed:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
Modified:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
Removed:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp?rev=312255&view=auto
==
---
libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
(original)
+++
libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
(removed)
@@ -1,25 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// UNSUPPORTED: c++98, c++03, c++11, c++14
-//
-
-// struct nullopt_t{see below};
-
-#include
-
-using std::optional;
-using std::nullopt_t;
-
-int main()
-{
-// I roughly interpret LWG2736 as "it shall not be possible to
copy-list-initialize nullopt_t with an
-// empty braced-init-list."
-nullopt_t foo = {};
-}
Modified:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp?rev=312256&r1=312255&r2=312256&view=diff
==
---
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
(original)
+++
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
Thu Aug 31 10:56:31 2017
@@ -11,15 +11,13 @@
//
// struct nullopt_t{see below};
-// constexpr nullopt_t nullopt(unspecified);
+// inline constexpr nullopt_t nullopt(unspecified);
// [optional.nullopt]/2:
-// Type nullopt_t shall not have a default constructor or an
initializer-list constructor.
-// It shall not be an aggregate and shall be a literal type.
-// Constant nullopt shall be initialized with an argument of literal type.
+// Type nullopt_t shall not have a default constructor or an initializer-list
+// constructor, and shall not be an aggregate.
#include
-#include "test_macros.h"
int main()
{
Modified:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp?rev=312256&r1=312255&r2=312256&view=diff
==
---
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
(original)
+++
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
Thu Aug 31 10:56:31 2017
@@ -11,33 +11,30 @@
//
// struct nullopt_t{see below};
-// constexpr nullopt_t nullopt(unspecified);
+// inline constexpr nullopt_t nullopt(unspecified);
// [optional.nullopt]/2:
-// Type nullopt_t shall not have a default constructor or an
initializer-list constructor.
-// It shall not be an aggregate and shall be a literal type.
-// Constant nullopt shall be initialized with an argument of literal type.
+// Type nullopt_t shall not have a default constructor or an initializer-list
+// constructor, and shall not be an aggregate.
#include
#include
-using std::optional;
using std::nullopt_t;
using std::nullopt;
-constexpr
-int
-test(const nullopt_t&)
+constexpr bool test()
{
-return 3;
+nullopt_t foo{nullopt};
+(void)foo;
+return true;
}
int main()
{
-static_assert(( std::is_class::value), "");
-static_assert(( std::is_empty::value), "");
-static_assert(( std::is_literal_type::value), "");
-static_assert((!std::is_default_constructible::value), "");
+static_assert(std::is_empty_v);
+static_assert(!std::is_default_constructible_v);
-static_assert(test(nullopt) == 3, "");
+static_assert(std::is_same_v);
+static_assert(test());
}
___
cfe-commits mailing list
cfe-commits@lists.llvm
[PATCH] D37024: [libcxx] [test] Cleanup nullopt_t tests
This revision was automatically updated to reflect the committed changes.
Closed by commit rL312256: [test] Cleanup nullopt_t tests (authored by
CaseyCarter).
Changed prior to commit:
https://reviews.llvm.org/D37024?vs=112224&id=113432#toc
Repository:
rL LLVM
https://reviews.llvm.org/D37024
Files:
libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
Index: libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
===
--- libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
+++ libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.fail.cpp
@@ -11,15 +11,13 @@
//
// struct nullopt_t{see below};
-// constexpr nullopt_t nullopt(unspecified);
+// inline constexpr nullopt_t nullopt(unspecified);
// [optional.nullopt]/2:
-// Type nullopt_t shall not have a default constructor or an initializer-list constructor.
-// It shall not be an aggregate and shall be a literal type.
-// Constant nullopt shall be initialized with an argument of literal type.
+// Type nullopt_t shall not have a default constructor or an initializer-list
+// constructor, and shall not be an aggregate.
#include
-#include "test_macros.h"
int main()
{
Index: libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
===
--- libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
+++ libcxx/trunk/test/std/utilities/optional/optional.nullopt/nullopt_t.pass.cpp
@@ -11,33 +11,30 @@
//
// struct nullopt_t{see below};
-// constexpr nullopt_t nullopt(unspecified);
+// inline constexpr nullopt_t nullopt(unspecified);
// [optional.nullopt]/2:
-// Type nullopt_t shall not have a default constructor or an initializer-list constructor.
-// It shall not be an aggregate and shall be a literal type.
-// Constant nullopt shall be initialized with an argument of literal type.
+// Type nullopt_t shall not have a default constructor or an initializer-list
+// constructor, and shall not be an aggregate.
#include
#include
-using std::optional;
using std::nullopt_t;
using std::nullopt;
-constexpr
-int
-test(const nullopt_t&)
+constexpr bool test()
{
-return 3;
+nullopt_t foo{nullopt};
+(void)foo;
+return true;
}
int main()
{
-static_assert(( std::is_class::value), "");
-static_assert(( std::is_empty::value), "");
-static_assert(( std::is_literal_type::value), "");
-static_assert((!std::is_default_constructible::value), "");
+static_assert(std::is_empty_v);
+static_assert(!std::is_default_constructible_v);
-static_assert(test(nullopt) == 3, "");
+static_assert(std::is_same_v);
+static_assert(test());
}
Index: libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
===
--- libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
+++ libcxx/trunk/test/std/utilities/optional/optional.nullopt/not_brace_initializable.fail.cpp
@@ -1,25 +0,0 @@
-//===--===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
-//
-//===--===//
-
-// UNSUPPORTED: c++98, c++03, c++11, c++14
-//
-
-// struct nullopt_t{see below};
-
-#include
-
-using std::optional;
-using std::nullopt_t;
-
-int main()
-{
-// I roughly interpret LWG2736 as "it shall not be possible to copy-list-initialize nullopt_t with an
-// empty braced-init-list."
-nullopt_t foo = {};
-}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r312258 - [libcxx] [www] Change http://cplusplus.github.io/LWG/lwg-defects.html# to https://wg21.link/lwg .
Author: stl_msft Date: Thu Aug 31 10:59:36 2017 New Revision: 312258 URL: http://llvm.org/viewvc/llvm-project?rev=312258&view=rev Log: [libcxx] [www] Change http://cplusplus.github.io/LWG/lwg-defects.html# to https://wg21.link/lwg . Fixes D37318. Modified: libcxx/trunk/www/cxx1y_status.html Modified: libcxx/trunk/www/cxx1y_status.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1y_status.html?rev=312258&r1=312257&r2=312258&view=diff == --- libcxx/trunk/www/cxx1y_status.html (original) +++ libcxx/trunk/www/cxx1y_status.html Thu Aug 31 10:59:36 2017 @@ -109,165 +109,165 @@ Issue #Issue NameMeetingStatus - http://cplusplus.github.io/LWG/lwg-defects.html#1214";>1214Insufficient/inconsistent key immutability requirements for associative containersKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2009";>2009Reporting out-of-bound values on numeric string conversionsKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2010";>2010is_* traits for binding operations can't be meaningfully specializedKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2015";>2015Incorrect pre-conditions for some type traitsKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2021";>2021Further incorrect usages of result_ofKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2028";>2028messages_base::catalog overspecifiedKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2033";>2033Preconditions of reserve, shrink_to_fit, and resize functionsKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2039";>2039Issues with std::reverse and std::copy_ifKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2044";>2044No definition of "Stable" for copy algorithmsKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2045";>2045forward_list::merge and forward_list::splice_after with unequal allocatorsKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2047";>2047Incorrect "mixed" move-assignment semantics of unique_ptrKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2050";>2050Unordered associative containers do not use allocator_traits to define member typesKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2053";>2053Errors in regex bitmask typesKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2061";>2061make_move_iterator and arraysKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2064";>2064More noexcept issues in basic_stringKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2065";>2065Minimal allocator interfaceKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2067";>2067packaged_task should have deleted copy c'tor with const parameterKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2069";>2069Inconsistent exception spec for basic_string move constructorKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2096";>2096Incorrect constraints of future::get in regard to MoveAssignableKonaComplete - http://cplusplus.github.io/LWG/lwg-defects.html#2102";>2102Why is std::launch an implementation-defined type?KonaComplete + https://wg21.link/lwg1214";>1214Insufficient/inconsistent key immutability requirements for associative containersKonaComplete + https://wg21.link/lwg2009";>2009Reporting out-of-bound values on numeric string conversionsKonaComplete + https://wg21.link/lwg2010";>2010is_* traits for binding operations can't be meaningfully specializedKonaComplete + https://wg21.link/lwg2015";>2015Incorrect pre-conditions for some type traitsKonaComplete + https://wg21.link/lwg2021";>2021Further incorrect usages of result_ofKonaComplete + https://wg21.link/lwg2028";>2028messages_base::catalog overspecifiedKonaComplete + https://wg21.link/lwg2033";>2033Preconditions of reserve, shrink_to_fit, and resize functionsKonaComplete + https://wg21.link/lwg2039";>2039Issues with std::reverse and std::copy_ifKonaComplete + https://wg21.link/lwg2044";>2044No definition of "Stable" for copy algorithmsKonaComplete + https://wg21.link/lwg2045";>2045forward_list::merge and forward_list::splice_after with unequal allocatorsKonaComplete + https://wg21.link/lwg2047";>2047Incorrect "mixed" move-assignment semantics of unique_ptrKonaComplete + https://wg21.link/lwg2050";>2050Unordered associative containers do not use allocator_traits to define member typesKonaComplete + https://wg21.link/lwg2053";>2053Errors in regex bitmask typesKonaComplete + https://wg21.link/lwg2061";>2061make_move_iterator and arraysKonaComplete + https://wg21.link/lwg2064";>2064More noexcept issues in basic_stringKonaC
[libcxx] r312260 - [libcxx] [www] Manually change http links to https.
Author: stl_msft Date: Thu Aug 31 10:59:42 2017 New Revision: 312260 URL: http://llvm.org/viewvc/llvm-project?rev=312260&view=rev Log: [libcxx] [www] Manually change http links to https. Fixes D37318. Modified: libcxx/trunk/www/atomic_design.html libcxx/trunk/www/atomic_design_a.html libcxx/trunk/www/atomic_design_b.html libcxx/trunk/www/atomic_design_c.html libcxx/trunk/www/cxx1y_status.html libcxx/trunk/www/cxx1z_status.html libcxx/trunk/www/cxx2a_status.html libcxx/trunk/www/index.html libcxx/trunk/www/ts1z_status.html libcxx/trunk/www/type_traits_design.html libcxx/trunk/www/upcoming_meeting.html Modified: libcxx/trunk/www/atomic_design.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design.html (original) +++ libcxx/trunk/www/atomic_design.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_a.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_a.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design_a.html (original) +++ libcxx/trunk/www/atomic_design_a.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_b.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_b.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design_b.html (original) +++ libcxx/trunk/www/atomic_design_b.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN +https://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC Modified: libcxx/trunk/www/atomic_design_c.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_c.html?rev=312260&r1=312259&r2=312260&view=diff == --- libcxx/trunk/www/atomic_design_c.html (original) +++ libcxx/trunk/www/atomic_design_c.html Thu Aug 31 10:59:42 2017 @@ -12,7 +12,7 @@ -http://llvm.org/";>LLVM Home +https://llvm.org/";>LLVM Home @@ -22,11 +22,11 @@ Quick Links -http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev -http://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits +https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev +https://lists.llvm.org/mailman/listinfo/cfe-commits";>cfe-commits https://bugs.llvm.org/";>Bug Reports -http://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse SVN -http://llvm.org/viewvc/llvm-project/libcxx/trunk/";>Browse ViewVC +https://llvm.org/svn/llvm-project/libcxx/trunk/";>Browse S
[libcxx] r312261 - [libcxx] [www] Fix broken link for LLVM Bugzilla.
Author: stl_msft Date: Thu Aug 31 10:59:46 2017 New Revision: 312261 URL: http://llvm.org/viewvc/llvm-project?rev=312261&view=rev Log: [libcxx] [www] Fix broken link for LLVM Bugzilla. Fixes D37318. Modified: libcxx/trunk/www/index.html Modified: libcxx/trunk/www/index.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/index.html?rev=312261&r1=312260&r2=312261&view=diff == --- libcxx/trunk/www/index.html (original) +++ libcxx/trunk/www/index.html Thu Aug 31 10:59:46 2017 @@ -203,7 +203,7 @@ If you think you've found a bug in libc++, please report it using - the http://llvm.org/bugs";>LLVM Bugzilla. If you're not sure, you + the https://bugs.llvm.org/";>LLVM Bugzilla. If you're not sure, you can post a message to the https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev mailing list or on IRC. Please include "libc++" in your subject. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r312259 - [libcxx] [www] Semi-manually change http://www.open-std.org and http://isocpp.org papers to https://wg21.link .
Author: stl_msft Date: Thu Aug 31 10:59:39 2017 New Revision: 312259 URL: http://llvm.org/viewvc/llvm-project?rev=312259&view=rev Log: [libcxx] [www] Semi-manually change http://www.open-std.org and http://isocpp.org papers to https://wg21.link . Fixes D37318. Modified: libcxx/trunk/www/atomic_design_c.html libcxx/trunk/www/cxx1y_status.html libcxx/trunk/www/cxx1z_status.html libcxx/trunk/www/cxx2a_status.html libcxx/trunk/www/ts1z_status.html libcxx/trunk/www/type_traits_design.html libcxx/trunk/www/upcoming_meeting.html Modified: libcxx/trunk/www/atomic_design_c.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_c.html?rev=312259&r1=312258&r2=312259&view=diff == --- libcxx/trunk/www/atomic_design_c.html (original) +++ libcxx/trunk/www/atomic_design_c.html Thu Aug 31 10:59:39 2017 @@ -328,7 +328,7 @@ void __atomic_signal_fence_seq_cst() One should consult the (currently draft) -http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf";>C++ standard +https://wg21.link/n3126";>C++ standard for the details of the definitions for these operations. For example __atomic_compare_exchange_weak_seq_cst_seq_cst is allowed to fail spuriously while __atomic_compare_exchange_strong_seq_cst_seq_cst is @@ -370,7 +370,7 @@ memory_order_relaxed (See the -http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf";>C++ standard +https://wg21.link/n3126";>C++ standard for the detailed definitions of each of these orderings). Modified: libcxx/trunk/www/cxx1y_status.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1y_status.html?rev=312259&r1=312258&r2=312259&view=diff == --- libcxx/trunk/www/cxx1y_status.html (original) +++ libcxx/trunk/www/cxx1y_status.html Thu Aug 31 10:59:39 2017 @@ -51,17 +51,17 @@ Paper #GroupPaper NameMeetingStatusFirst released version - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3346.pdf";>3346LWGTerminology for Container Element Requirements - Rev 1KonaComplete3.4 + https://wg21.link/n3346";>3346LWGTerminology for Container Element Requirements - Rev 1KonaComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421.htm";>3421LWGMaking Operator Functors greater<>PortlandComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3462.html";>3462LWGstd::result_of and SFINAEPortlandComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3469.html";>3469LWGConstexpr Library Additions: chrono, v3PortlandComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3470.html";>3470LWGConstexpr Library Additions: containers, v2PortlandComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html";>3471LWGConstexpr Library Additions: utilities, v3PortlandComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3302.html";>3302LWGConstexpr Library Additions: complex, v2PortlandComplete3.4 + https://wg21.link/n3421";>3421LWGMaking Operator Functors greater<>PortlandComplete3.4 + https://wg21.link/n3462";>3462LWGstd::result_of and SFINAEPortlandComplete3.4 + https://wg21.link/n3469";>3469LWGConstexpr Library Additions: chrono, v3PortlandComplete3.4 + https://wg21.link/n3470";>3470LWGConstexpr Library Additions: containers, v2PortlandComplete3.4 + https://wg21.link/n3471";>3471LWGConstexpr Library Additions: utilities, v3PortlandComplete3.4 + https://wg21.link/n3302";>3302LWGConstexpr Library Additions: complex, v2PortlandComplete3.4 @@ -76,31 +76,31 @@ - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3545.pdf";>3545LWGAn Incremental Improvement to integral_constantBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3644.pdf";>3644LWGNull Forward IteratorsBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3668.html";>3668LWGstd::exchange()BristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3658.html";>3658LWGCompile-time integer sequencesBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3670.html";>3670LWGAddressing Tuples by TypeBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3671.html";>3671LWGMaking non-modifying sequence operations more robustBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3656.htm";>3656LWGmake_uniqueBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3654.html";>3654LWGQuoted StringsBristolComplete3.4 - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3642.pdf";>3642LWGUser-defined LiteralsBristo
[libcxx] r312262 - [libcxx] [www] Strip trailing whitespace.
Author: stl_msft
Date: Thu Aug 31 10:59:48 2017
New Revision: 312262
URL: http://llvm.org/viewvc/llvm-project?rev=312262&view=rev
Log:
[libcxx] [www] Strip trailing whitespace.
Fixes D37318.
Modified:
libcxx/trunk/www/atomic_design_c.html
libcxx/trunk/www/cxx1y_status.html
libcxx/trunk/www/index.html
libcxx/trunk/www/ts1z_status.html
Modified: libcxx/trunk/www/atomic_design_c.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/atomic_design_c.html?rev=312262&r1=312261&r2=312262&view=diff
==
--- libcxx/trunk/www/atomic_design_c.html (original)
+++ libcxx/trunk/www/atomic_design_c.html Thu Aug 31 10:59:48 2017
@@ -115,7 +115,7 @@ __has_feature(__atomic_flag) == 1
__has_feature(__atomic_exchange_seq_cst_j) == 1
__has_feature(__atomic_store_seq_cst_j) == 1
-typedef unsigned int __atomic_flag__;
+typedef unsigned int __atomic_flag__;
unsigned int __atomic_exchange_seq_cst(unsigned int volatile*, unsigned int)
{
Modified: libcxx/trunk/www/cxx1y_status.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/cxx1y_status.html?rev=312262&r1=312261&r2=312262&view=diff
==
--- libcxx/trunk/www/cxx1y_status.html (original)
+++ libcxx/trunk/www/cxx1y_status.html Thu Aug 31 10:59:48 2017
@@ -46,7 +46,7 @@
SG1 - Study group #1 (Concurrency working group)
-
+
Paper Status
Paper #GroupPaper
NameMeetingStatusFirst released version
@@ -55,7 +55,7 @@
-
+
https://wg21.link/n3421";>3421LWGMaking Operator
Functors greater<>PortlandComplete3.4
https://wg21.link/n3462";>3462LWGstd::result_of and
SFINAEPortlandComplete3.4
https://wg21.link/n3469";>3469LWGConstexpr Library
Additions: chrono, v3PortlandComplete3.4
@@ -75,7 +75,7 @@
-
+
https://wg21.link/n3545";>3545LWGAn Incremental
Improvement to
integral_constantBristolComplete3.4
https://wg21.link/n3644";>3644LWGNull Forward
IteratorsBristolComplete3.4
https://wg21.link/n3668";>3668LWGstd::exchange()BristolComplete3.4
@@ -90,7 +90,7 @@
https://wg21.link/n3672";>3672LWGA proposal to add a
utility class to represent optional objectsBristolRemoved
from Draft Standardn/a
https://wg21.link/n3669";>3669LWGFixing constexpr
member functions without
constBristolComplete3.4
https://wg21.link/n3662";>3662LWGC++ Dynamic Arrays
(dynarray)BristolRemoved from Draft
Standardn/a
-
+
https://wg21.link/n3659";>3659SG1Shared Locking in
C++BristolComplete3.4
Modified: libcxx/trunk/www/index.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/index.html?rev=312262&r1=312261&r2=312262&view=diff
==
--- libcxx/trunk/www/index.html (original)
+++ libcxx/trunk/www/index.html Thu Aug 31 10:59:48 2017
@@ -204,7 +204,7 @@
If you think you've found a bug in libc++, please report it using
the https://bugs.llvm.org/";>LLVM Bugzilla. If you're not sure,
you
- can post a message to the https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev
+ can post a message to the https://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev
mailing list or on IRC. Please include "libc++" in your subject.
Modified: libcxx/trunk/www/ts1z_status.html
URL:
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/ts1z_status.html?rev=312262&r1=312261&r2=312262&view=diff
==
--- libcxx/trunk/www/ts1z_status.html (original)
+++ libcxx/trunk/www/ts1z_status.html Thu Aug 31 10:59:48 2017
@@ -95,7 +95,7 @@
-
+
Features in Filesystem
Feature NameStatusFirst released
version
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libcxx] r312263 - [libcxx] [www] Change an absolute link to cxx1z_status.html to be relative.
Author: stl_msft Date: Thu Aug 31 10:59:51 2017 New Revision: 312263 URL: http://llvm.org/viewvc/llvm-project?rev=312263&view=rev Log: [libcxx] [www] Change an absolute link to cxx1z_status.html to be relative. Fixes D37318. Modified: libcxx/trunk/www/upcoming_meeting.html Modified: libcxx/trunk/www/upcoming_meeting.html URL: http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/upcoming_meeting.html?rev=312263&r1=312262&r2=312263&view=diff == --- libcxx/trunk/www/upcoming_meeting.html (original) +++ libcxx/trunk/www/upcoming_meeting.html Thu Aug 31 10:59:51 2017 @@ -35,7 +35,7 @@ libc++ Issaquah Status - This is a temporary page; please check the c++1z status https://libcxx.llvm.org/cxx1z_status.html";>here + This is a temporary page; please check the c++1z status here This page shows the status of the papers and issues that are expected to be adopted in Toronto. The groups that have contributed papers: ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
erichkeane added a comment. Looks good to me, but I want to give @aaron.ballman a chance to take a look before this gets accepted. https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled
vivekvpandya updated this revision to Diff 113434.
vivekvpandya added a comment.
Updated the patch! I don't think now we require to save OldDiagnosticHandler
and context as we have ClangDiagnosticHandler class with creation of
CreateASTConsumer, but I need some review.
https://reviews.llvm.org/D37196
Files:
lib/CodeGen/CodeGenAction.cpp
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -224,10 +224,10 @@
void *OldContext = Ctx.getInlineAsmDiagnosticContext();
Ctx.setInlineAsmDiagnosticHandler(InlineAsmDiagHandler, this);
- LLVMContext::DiagnosticHandlerTy OldDiagnosticHandler =
- Ctx.getDiagnosticHandler();
- void *OldDiagnosticContext = Ctx.getDiagnosticContext();
- Ctx.setDiagnosticHandler(DiagnosticHandler, this);
+ //LLVMContext::DiagnosticHandlerTy OldDiagnosticHandler =
+ //Ctx.getDiagnosticHandler();
+ // void *OldDiagnosticContext = Ctx.getDiagnosticContext();
+ // Ctx.setDiagnosticHandler(DiagnosticHandler, this);
Ctx.setDiagnosticsHotnessRequested(CodeGenOpts.DiagnosticsWithHotness);
if (CodeGenOpts.DiagnosticsHotnessThreshold != 0)
Ctx.setDiagnosticsHotnessThreshold(
@@ -264,7 +264,7 @@
Ctx.setInlineAsmDiagnosticHandler(OldHandler, OldContext);
- Ctx.setDiagnosticHandler(OldDiagnosticHandler, OldDiagnosticContext);
+ //Ctx.setDiagnosticHandler(OldDiagnosticHandler, OldDiagnosticContext);
if (OptRecordFile)
OptRecordFile->keep();
@@ -756,6 +756,31 @@
}
#undef ComputeDiagID
+class ClangDiagnosticHandler final : public DiagnosticHandler {
+ public:
+ ClangDiagnosticHandler(const CodeGenOptions &CGOpts, void *DiagContext)
+: DiagnosticHandler(DiagContext), CodeGenOpts(CGOpts) {}
+
+ bool handleDiagnostics(const DiagnosticInfo &DI) override {
+((BackendConsumer *)DiagnosticContext)->DiagnosticHandlerImpl(DI);
+return true;
+ }
+ bool isAnalysisRemarkEnable(const std::string &PassName) {
+ return (CodeGenOpts.OptimizationRemarkAnalysisPattern
+&& CodeGenOpts.OptimizationRemarkAnalysisPattern->match(PassName));
+ }
+ bool isMissedOptRemarkEnable(const std::string &PassName) {
+return (CodeGenOpts.OptimizationRemarkMissedPattern
+&& CodeGenOpts.OptimizationRemarkMissedPattern->match(PassName));
+ }
+ bool isPassedOptRemarkEnable(const std::string &PassName) {
+return (CodeGenOpts.OptimizationRemarkPattern
+&& CodeGenOpts.OptimizationRemarkPattern->match(PassName));
+ }
+ private:
+const CodeGenOptions &CodeGenOpts;
+};
+
CodeGenAction::CodeGenAction(unsigned _Act, LLVMContext *_VMContext)
: Act(_Act), VMContext(_VMContext ? _VMContext : new LLVMContext),
OwnsVMContext(!_VMContext) {}
@@ -853,7 +878,8 @@
CI.getLangOpts(), CI.getFrontendOpts().ShowTimers, InFile,
std::move(LinkModules), std::move(OS), *VMContext, CoverageInfo));
BEConsumer = Result.get();
-
+ VMContext->setDiagnosticHandler(
+llvm::make_unique(CI.getCodeGenOpts(),
Result.get()));
// Enable generating macro debug info only when debug info is not disabled
and
// also macro debug info is enabled.
if (CI.getCodeGenOpts().getDebugInfo() != codegenoptions::NoDebugInfo &&
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -224,10 +224,10 @@
void *OldContext = Ctx.getInlineAsmDiagnosticContext();
Ctx.setInlineAsmDiagnosticHandler(InlineAsmDiagHandler, this);
- LLVMContext::DiagnosticHandlerTy OldDiagnosticHandler =
- Ctx.getDiagnosticHandler();
- void *OldDiagnosticContext = Ctx.getDiagnosticContext();
- Ctx.setDiagnosticHandler(DiagnosticHandler, this);
+ //LLVMContext::DiagnosticHandlerTy OldDiagnosticHandler =
+ //Ctx.getDiagnosticHandler();
+ // void *OldDiagnosticContext = Ctx.getDiagnosticContext();
+ // Ctx.setDiagnosticHandler(DiagnosticHandler, this);
Ctx.setDiagnosticsHotnessRequested(CodeGenOpts.DiagnosticsWithHotness);
if (CodeGenOpts.DiagnosticsHotnessThreshold != 0)
Ctx.setDiagnosticsHotnessThreshold(
@@ -264,7 +264,7 @@
Ctx.setInlineAsmDiagnosticHandler(OldHandler, OldContext);
- Ctx.setDiagnosticHandler(OldDiagnosticHandler, OldDiagnosticContext);
+ //Ctx.setDiagnosticHandler(OldDiagnosticHandler, OldDiagnosticContext);
if (OptRecordFile)
OptRecordFile->keep();
@@ -756,6 +756,31 @@
}
#undef ComputeDiagID
+class ClangDiagnosticHandler final : public DiagnosticHandler {
+ public:
+ ClangDiagnosticHandler(const CodeGenOptions &CGOpts, void *DiagContext)
+: DiagnosticHandler(DiagContext), CodeGenOpts(CGOpts) {}
+
+ bool handleDiagnostics(const DiagnosticInfo &DI) override {
+((BackendC
[PATCH] D34367: CodeGen: Fix address space of indirect function argument
yaxunl updated this revision to Diff 113443.
yaxunl added a comment.
Revised by John's comments.
https://reviews.llvm.org/D34367
Files:
lib/CodeGen/CGCall.cpp
lib/CodeGen/CGCall.h
lib/CodeGen/CGDecl.cpp
test/CodeGenCXX/amdgcn-func-arg.cpp
test/CodeGenOpenCL/addr-space-struct-arg.cl
Index: test/CodeGenOpenCL/addr-space-struct-arg.cl
===
--- test/CodeGenOpenCL/addr-space-struct-arg.cl
+++ test/CodeGenOpenCL/addr-space-struct-arg.cl
@@ -1,5 +1,6 @@
// RUN: %clang_cc1 %s -emit-llvm -o - -O0 -finclude-default-header -ffake-address-space-map -triple i686-pc-darwin | FileCheck -enable-var-scope -check-prefixes=COM,X86 %s
// RUN: %clang_cc1 %s -emit-llvm -o - -O0 -finclude-default-header -triple amdgcn-amdhsa-amd-amdgizcl | FileCheck -enable-var-scope -check-prefixes=COM,AMD %s
+// RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=CL2.0 -O0 -finclude-default-header -triple amdgcn-amdhsa-amd-amdgizcl | FileCheck -enable-var-scope -check-prefixes=COM,AMD,AMD20 %s
typedef struct {
int cells[9];
@@ -35,6 +36,9 @@
int2 y[20];
};
+#if __OPENCL_C_VERSION__ >= 200
+struct LargeStructOneMember g_s;
+#endif
// X86-LABEL: define void @foo(%struct.Mat4X4* noalias sret %agg.result, %struct.Mat3X3* byval align 4 %in)
// AMD-LABEL: define %struct.Mat4X4 @foo([9 x i32] %in.coerce)
@@ -80,10 +84,42 @@
}
// AMD-LABEL: define void @FuncOneLargeMember(%struct.LargeStructOneMember addrspace(5)* byval align 8 %u)
+// AMD-NOT: addrspacecast
+// AMD: store <2 x i32> %{{.*}}, <2 x i32> addrspace(5)*
void FuncOneLargeMember(struct LargeStructOneMember u) {
u.x[0] = (int2)(0, 0);
}
+// AMD20-LABEL: define void @test_indirect_arg_globl()
+// AMD20: %[[byval_temp:.*]] = alloca %struct.LargeStructOneMember, align 8, addrspace(5)
+// AMD20: %[[r0:.*]] = bitcast %struct.LargeStructOneMember addrspace(5)* %[[byval_temp]] to i8 addrspace(5)*
+// AMD20: call void @llvm.memcpy.p5i8.p1i8.i64(i8 addrspace(5)* %[[r0]], i8 addrspace(1)* bitcast (%struct.LargeStructOneMember addrspace(1)* @g_s to i8 addrspace(1)*), i64 800, i32 8, i1 false)
+// AMD20: call void @FuncOneLargeMember(%struct.LargeStructOneMember addrspace(5)* byval align 8 %[[byval_temp]])
+#if __OPENCL_C_VERSION__ >= 200
+void test_indirect_arg_globl(void) {
+ FuncOneLargeMember(g_s);
+}
+#endif
+
+// AMD-LABEL: define amdgpu_kernel void @test_indirect_arg_local()
+// AMD: %[[byval_temp:.*]] = alloca %struct.LargeStructOneMember, align 8, addrspace(5)
+// AMD: %[[r0:.*]] = bitcast %struct.LargeStructOneMember addrspace(5)* %[[byval_temp]] to i8 addrspace(5)*
+// AMD: call void @llvm.memcpy.p5i8.p3i8.i64(i8 addrspace(5)* %[[r0]], i8 addrspace(3)* bitcast (%struct.LargeStructOneMember addrspace(3)* @test_indirect_arg_local.l_s to i8 addrspace(3)*), i64 800, i32 8, i1 false)
+// AMD: call void @FuncOneLargeMember(%struct.LargeStructOneMember addrspace(5)* byval align 8 %[[byval_temp]])
+kernel void test_indirect_arg_local(void) {
+ local struct LargeStructOneMember l_s;
+ FuncOneLargeMember(l_s);
+}
+
+// AMD-LABEL: define void @test_indirect_arg_private()
+// AMD: %[[p_s:.*]] = alloca %struct.LargeStructOneMember, align 8, addrspace(5)
+// AMD-NOT: @llvm.memcpy
+// AMD-NEXT: call void @FuncOneLargeMember(%struct.LargeStructOneMember addrspace(5)* byval align 8 %[[p_s]])
+void test_indirect_arg_private(void) {
+ struct LargeStructOneMember p_s;
+ FuncOneLargeMember(p_s);
+}
+
// AMD-LABEL: define amdgpu_kernel void @KernelOneMember
// AMD-SAME: (<2 x i32> %[[u_coerce:.*]])
// AMD: %[[u:.*]] = alloca %struct.StructOneMember, align 8, addrspace(5)
@@ -112,7 +148,6 @@
u.y[0] = (int2)(0, 0);
}
-
// AMD-LABEL: define amdgpu_kernel void @KernelTwoMember
// AMD-SAME: (%struct.StructTwoMember %[[u_coerce:.*]])
// AMD: %[[u:.*]] = alloca %struct.StructTwoMember, align 8, addrspace(5)
Index: test/CodeGenCXX/amdgcn-func-arg.cpp
===
--- /dev/null
+++ test/CodeGenCXX/amdgcn-func-arg.cpp
@@ -0,0 +1,94 @@
+// RUN: %clang_cc1 -O0 -triple amdgcn---amdgiz -emit-llvm %s -o - | FileCheck %s
+
+class A {
+public:
+ int x;
+ A():x(0) {}
+ ~A() {}
+};
+
+class B {
+int x[100];
+};
+
+A g_a;
+B g_b;
+
+void func_with_ref_arg(A &a);
+void func_with_ref_arg(B &b);
+
+// CHECK-LABEL: define void @_Z22func_with_indirect_arg1A(%class.A addrspace(5)* %a)
+// CHECK: %p = alloca %class.A*, align 8, addrspace(5)
+// CHECK: %[[r1:.+]] = addrspacecast %class.A* addrspace(5)* %p to %class.A**
+// CHECK: %[[r0:.+]] = addrspacecast %class.A addrspace(5)* %a to %class.A*
+// CHECK: store %class.A* %[[r0]], %class.A** %[[r1]], align 8
+void func_with_indirect_arg(A a) {
+ A *p = &a;
+}
+
+// CHECK-LABEL: define void @_Z22test_indirect_arg_autov()
+// CHECK: %a = alloca %class.A, align 4, addrspace(5)
+// CHECK: %[[r0:.+]] = addrspacecast %class.A addrspace(5)* %a to %class.A*
+// CHECK: %agg.tmp = alloca %class.A, align 4, addrspace
[PATCH] D37346: Register linkageSpecDecl matcher
kastiglione created this revision. Herald added a subscriber: klimek. This allows `linkageSpecDecl` to be used from `clang-query`. See also https://reviews.llvm.org/D31869 which similary adds `isStaticStorageClass`. https://reviews.llvm.org/D37346 Files: lib/ASTMatchers/Dynamic/Registry.cpp Index: lib/ASTMatchers/Dynamic/Registry.cpp === --- lib/ASTMatchers/Dynamic/Registry.cpp +++ lib/ASTMatchers/Dynamic/Registry.cpp @@ -355,6 +355,7 @@ REGISTER_MATCHER(labelDecl); REGISTER_MATCHER(labelStmt); REGISTER_MATCHER(lambdaExpr); + REGISTER_MATCHER(linkageSpecDecl); REGISTER_MATCHER(lValueReferenceType); REGISTER_MATCHER(matchesName); REGISTER_MATCHER(matchesSelector); Index: lib/ASTMatchers/Dynamic/Registry.cpp === --- lib/ASTMatchers/Dynamic/Registry.cpp +++ lib/ASTMatchers/Dynamic/Registry.cpp @@ -355,6 +355,7 @@ REGISTER_MATCHER(labelDecl); REGISTER_MATCHER(labelStmt); REGISTER_MATCHER(lambdaExpr); + REGISTER_MATCHER(linkageSpecDecl); REGISTER_MATCHER(lValueReferenceType); REGISTER_MATCHER(matchesName); REGISTER_MATCHER(matchesSelector); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37346: Register linkageSpecDecl matcher
aaron.ballman accepted this revision. aaron.ballman added a comment. This revision is now accepted and ready to land. LGTM! https://reviews.llvm.org/D37346 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
aaron.ballman added inline comments. Comment at: include/clang/Basic/AttrDocs.td:2812 +Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions +(like 'movaps') that work with stack require operands to be 16-byte aligned. +This attribute realigns stack in the function prologue to make sure the stack work with stack -> work with the stack Comment at: include/clang/Basic/AttrDocs.td:2813 +(like 'movaps') that work with stack require operands to be 16-byte aligned. +This attribute realigns stack in the function prologue to make sure the stack +can be used with SSE instructions. realigns stack -> realigns the stack Comment at: include/clang/Basic/AttrDocs.td:2817 +Note that the x86_64 ABI forces 16-byte stack alignment at the call site. +Because of this, 'force_align_arg_pointer' is not needed at x86_64 except rare +cases when caller does not align the stack correctly (e.g. flow jumps from i386 at x86_64 except rare cases when caller -> on x86_64, except in rare cases where the caller https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37038: Replace temp MD nodes with unique/distinct before cloning
probinson added a comment. I now think the tactic to pursue is making sure the containing DICompositeType(s) for the method have complete descriptions, and RAUW the temporary nodes, prior to calling CloneFunction. Actually wading around in the MDNodes, Types, and Decls to accomplish that result promises to be "interesting" and "educational" (advice/suggestions welcome). https://reviews.llvm.org/D37038 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
aaron.ballman added a comment.
In https://reviews.llvm.org/D37308#857607, @zahiraam wrote:
> Removed the helper function.
>
> If RD (base class) has uuid attribute, we want to ensure that the interface
> doesn't have attributes. Otherwise cases like:
>
> class __declspec(uuid("---C000-0046")) IUnknown1 {};
> __interface __declspec(dllimport) ISfFileIOPropertyPage1 : public IUnknown1
> {};
>
> will compile.
Is there a reason this code shouldn't work?
class __declspec(uuid("---C000-0046")) IUnknown1 {};
__interface __declspec(deprecated("Don't use this")) blah : public IUnknown1
{};
Is it only dllimport that is a problem?
https://reviews.llvm.org/D37308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
iid_iunknown added a comment. > Do you think you can write a test for your patch that will work on the > buildbots we have? I am afraid, this is not possible with the existing buildbots. `--target` does not affect the default triple. There is `LLVM_TARGET_TRIPLE_ENV` that allows to override the default triple at runtime, but LLVM must be configured to support it and none of the Windows buildbots do this. I see no other way to implement such a test, unfortunately. Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312268 - Disable clang-format's MemoizationTest as it becomes prohibitive with EXPENSIVE_CHECKS
Author: dblaikie
Date: Thu Aug 31 11:49:34 2017
New Revision: 312268
URL: http://llvm.org/viewvc/llvm-project?rev=312268&view=rev
Log:
Disable clang-format's MemoizationTest as it becomes prohibitive with
EXPENSIVE_CHECKS
EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
includes checking the container passed to std::priority_queue for its
well-formedness. This makes the clang-format memoization too expensive,
so disable it.
(it's a necessary feature of libstdc++'s consistency checks that it
ruins the required scalability of C++ standard library features - so
these workarounds are to be expected if a test ever tries to test
scalability in some way, like this test does)
Modified:
cfe/trunk/unittests/Format/FormatTest.cpp
Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=312268&r1=312267&r2=312268&view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Thu Aug 31 11:49:34 2017
@@ -3440,6 +3440,10 @@ TEST_F(FormatTest, BreakConstructorIniti
Style);
}
+#ifndef EXPENSIVE_CHECKS
+// Expensive checks enables libstdc++ checking which includes validating the
+// state of ranges used in std::priority_queue - this blows out the
+// runtime/scalability of the function and makes this test unacceptably slow.
TEST_F(FormatTest, MemoizationTests) {
// This breaks if the memoization lookup does not take \c Indent and
// \c LastSpace into account.
@@ -3518,6 +3522,7 @@ TEST_F(FormatTest, MemoizationTests) {
input += " a) {}";
verifyFormat(input, OnePerLine);
}
+#endif
TEST_F(FormatTest, BreaksAsHighAsPossible) {
verifyFormat(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
zahiraam added a comment. The test case you gave doesn't compile. It returns the diagnostic. CL has the same behavior. I don't think it is because of the dllimport. https://reviews.llvm.org/D37308 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33852: Enable __declspec(selectany) on linux
aaron.ballman added inline comments.
Comment at: include/clang/Basic/AttrDocs.td:3154
+
+def SelectAnyDocs : Documentation {
+ let Content = [{This attribute makes global symbol have a weak definition
I think you need to set the `Category` as well.
To test this you should run something like (replacing and fixing up path
separators as needed):
```
clang-tblgen -gen-attr-docs -I \llvm\tools\clang\include
\llvm\tools\clang\include\clang\Basic\Attr.td -o
\llvm\tools\clang\docs\AttributeReference.rst
```
Comment at: include/clang/Basic/AttrDocs.td:3155
+def SelectAnyDocs : Documentation {
+ let Content = [{This attribute makes global symbol have a weak definition
+ (link-once), meaning that the linker can select any definition.
You should format this the same as other documentation in the file.
Comment at: include/clang/Basic/AttrDocs.td:3155
+def SelectAnyDocs : Documentation {
+ let Content = [{This attribute makes global symbol have a weak definition
+ (link-once), meaning that the linker can select any definition.
aaron.ballman wrote:
> You should format this the same as other documentation in the file.
How about: `This attribute appertains to a global symbol, causing it to have a
weak definition (linkonce), allowing the linker to select any definition.`?
It might also be nice to link the `linkonce` with
https://llvm.org/docs/LangRef.html#linkage-types.
Comment at: include/clang/Basic/AttrDocs.td:3161
+}
\ No newline at end of file
Keep the newline at the end of the file.
https://reviews.llvm.org/D33852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
aaron.ballman added a comment. In https://reviews.llvm.org/D37308#858035, @zahiraam wrote: > The test case you gave doesn't compile. It returns the diagnostic. CL has the > same behavior. I don't think it is because of the dllimport. My test case was based off your example code, not something I had actually tried. Your original example doesn't compile with CL either, even when you remove the dllimport. https://reviews.llvm.org/D37308 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
zahiraam added a comment. That's both of the code snip-its are supposed to fail (take the diagnostic). If I remove the ClasshasAttrs() condition, from line #2459, these snip-its will pass. I was trying to explain the need for that part of the condition. https://reviews.llvm.org/D37308 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
hans accepted this revision. hans added a comment. This revision is now accepted and ready to land. lgtm Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
erichkeane requested changes to this revision.
erichkeane added a comment.
This revision now requires changes to proceed.
When forming 'diffs', please make sure you do so against the current status of
Clang. Your latest diff seems to be only against your first commit, so the
diff is crazy looking, and also not submit-able.
@aaron.ballman : The purpose of this patch is to allow this to succeed (Zahira,
please correct me if I'm wrong):
struct __declspec(uuid("---C000-0046")) IUnknown {};
__interface ISfFileIOPropertyPage : public IUnknown {};
Previously, clang's implementation only permitted __interface to inherit from
public __interfaces. You can see these examples in
test/SemaCXX/ms-interface.cpp.
However, our testers discovered that there is an exception to this case: When
the base struct/class has attribute "uuid" defined. Apparently while
researching, @zahiraam also discovered that EVEN IF the inherited struct/class
has UUID, any attribute on the __interface makes said inheritance an error.
THAT SAID, in researching this to try to explain this better, I just discovered
that this diagnosis is actually not correct. It seems that CL has some
'special cases' for the inheritence from a struct/class. For example:
struct __declspec(uuid("---C000-0046")) IUnknown {};
__interface ISfFileIOPropertyPage : public IUnknown {};
Correctly compiles in CL.
class __declspec(uuid("---C000-0046")) IUnknown {};
__interface ISfFileIOPropertyPage : public IUnknown {};
DOES NOT, with the only difference being struct->class.
Additionally,
struct __declspec(uuid("---C000-0046")) IUnknown2 {};
__interface ISfFileIOPropertyPage : public IUnknown2 {};
struct __declspec(uuid("---C000-0045")) IUnknown {};
__interface ISfFileIOPropertyPage : public IUnknown {};
Fails in CL, with the only difference being changing the UUID by 1 character.
On the other hand,
struct __declspec(uuid("---C000-0046")) IUnknown {};
__interface ISfFileIOPropertyPage : IUnknown {};
DOES compile in CL (note the lack of 'public' inheritence, 'private' there also
permits this to compile.
Additionally if IUnknown is not empty (i tried adding 'int x;' to it), this
ALSO fails in CL.
Fails to compile in CL. Note that the ONLY change I made was to rename the
base-struct. I believe that this commit is being way too liberal in this case.
A solution to this SHOULD happen, since this extensively affects the Windows
SDK, however @zahiraam likely needs to figure out what the ACTUAL exceptions in
CL are. I suspect strongly that the exception here is going to be:
-Base is struct
-base has the UUID (listed above)
-Base is named "IUnknown"
-Base is empty.
https://reviews.llvm.org/D37308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
anatol.pomozov updated this revision to Diff 113458.
https://reviews.llvm.org/D37312
Files:
include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -2803,6 +2803,31 @@
}];
}
+def X86ForceAlignArgPointerDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Use this attribute to force stack alignment.
+
+Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
+(like 'movaps') that work with the stack require operands to be 16-byte
aligned.
+This attribute realigns the stack in the function prologue to make sure the
+stack can be used with SSE instructions.
+
+Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
+Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
+rare cases where the caller does not align the stack properly (e.g. flow
+jumps from i386 arch code).
+
+ .. code-block:: c
+
+__attribute__ ((force_align_arg_pointer))
+void f () {
+ ...
+}
+
+ }];
+}
+
def SwiftCallDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -2043,11 +2043,11 @@
}
def X86ForceAlignArgPointer : InheritableAttr,
TargetSpecificAttr {
- let Spellings = [GNU<"force_align_arg_pointer">];
+ let Spellings = [GCC<"force_align_arg_pointer">];
// Technically, this appertains to a FunctionDecl, but the target-specific
// code silently allows anything function-like (such as typedefs or function
// pointers), but does not apply the attribute to them.
- let Documentation = [Undocumented];
+ let Documentation = [X86ForceAlignArgPointerDocs];
}
def NoSanitize : InheritableAttr {
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -2803,6 +2803,31 @@
}];
}
+def X86ForceAlignArgPointerDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Use this attribute to force stack alignment.
+
+Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
+(like 'movaps') that work with the stack require operands to be 16-byte aligned.
+This attribute realigns the stack in the function prologue to make sure the
+stack can be used with SSE instructions.
+
+Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
+Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
+rare cases where the caller does not align the stack properly (e.g. flow
+jumps from i386 arch code).
+
+ .. code-block:: c
+
+__attribute__ ((force_align_arg_pointer))
+void f () {
+ ...
+}
+
+ }];
+}
+
def SwiftCallDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -2043,11 +2043,11 @@
}
def X86ForceAlignArgPointer : InheritableAttr, TargetSpecificAttr {
- let Spellings = [GNU<"force_align_arg_pointer">];
+ let Spellings = [GCC<"force_align_arg_pointer">];
// Technically, this appertains to a FunctionDecl, but the target-specific
// code silently allows anything function-like (such as typedefs or function
// pointers), but does not apply the attribute to them.
- let Documentation = [Undocumented];
+ let Documentation = [X86ForceAlignArgPointerDocs];
}
def NoSanitize : InheritableAttr {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
aaron.ballman accepted this revision. aaron.ballman added a comment. This revision is now accepted and ready to land. LGTM! Thank you for working on this! https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
erichkeane added a comment. In https://reviews.llvm.org/D37312#858108, @aaron.ballman wrote: > LGTM! Thank you for working on this! Did you want to land this, or should I? https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37336: [clang-cl] Explicitly set object format to COFF in CL mode
iid_iunknown added a comment. Thanks for reviewing this! Repository: rL LLVM https://reviews.llvm.org/D37336 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312275 - [clang-cl] Explicitly set object format to COFF in CL mode
Author: oleg Date: Thu Aug 31 13:31:30 2017 New Revision: 312275 URL: http://llvm.org/viewvc/llvm-project?rev=312275&view=rev Log: [clang-cl] Explicitly set object format to COFF in CL mode Summary: Currently object format is taken from the default target triple. For toolchains with a non-COFF default target this may result in an object format inappropriate for pc-windows and lead to compilation issues. For example, the default triple `aarch64-linux-elf` may produce something like `aarch64-pc-windows-msvc19.0.24215-elf` in CL mode. Clang creates `MicrosoftARM64TargetInfo` for such triple with data layout `e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128`. On the other hand, the AArch64 backend in `computeDataLayout` detects a non-COFF target and selects `e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128` as data layout for little endian. Different layouts used by clang and the backend cause an error: ``` error: backend data layout 'e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128' does not match expected target description 'e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128' ``` This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a default target. This patch enforces COFF in CL mode. Reviewers: hans Reviewed By: hans Subscribers: cfe-commits, aemerson, asl, kristof.beyls Differential Revision: https://reviews.llvm.org/D37336 Modified: cfe/trunk/lib/Driver/Driver.cpp Modified: cfe/trunk/lib/Driver/Driver.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=312275&r1=312274&r2=312275&view=diff == --- cfe/trunk/lib/Driver/Driver.cpp (original) +++ cfe/trunk/lib/Driver/Driver.cpp Thu Aug 31 13:31:30 2017 @@ -663,6 +663,7 @@ Compilation *Driver::BuildCompilation(Ar T.setOS(llvm::Triple::Win32); T.setVendor(llvm::Triple::PC); T.setEnvironment(llvm::Triple::MSVC); +T.setObjectFormat(llvm::Triple::COFF); DefaultTargetTriple = T.str(); } if (const Arg *A = Args.getLastArg(options::OPT_target)) ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312281 - Add documentation for force_align_arg_pointer function attribute
Author: erichkeane
Date: Thu Aug 31 14:08:24 2017
New Revision: 312281
URL: http://llvm.org/viewvc/llvm-project?rev=312281&view=rev
Log:
Add documentation for force_align_arg_pointer function attribute
Patch By: anatol.pomozov (anatol.pomo...@gmail.com)
Differential Revision: https://reviews.llvm.org/D37312
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=312281&r1=312280&r2=312281&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Aug 31 14:08:24 2017
@@ -2043,11 +2043,11 @@ def AnyX86NoCallerSavedRegisters : Inher
}
def X86ForceAlignArgPointer : InheritableAttr,
TargetSpecificAttr {
- let Spellings = [GNU<"force_align_arg_pointer">];
+ let Spellings = [GCC<"force_align_arg_pointer">];
// Technically, this appertains to a FunctionDecl, but the target-specific
// code silently allows anything function-like (such as typedefs or function
// pointers), but does not apply the attribute to them.
- let Documentation = [Undocumented];
+ let Documentation = [X86ForceAlignArgPointerDocs];
}
def NoSanitize : InheritableAttr {
Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=312281&r1=312280&r2=312281&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Thu Aug 31 14:08:24 2017
@@ -2803,6 +2803,31 @@ For example:
}];
}
+def X86ForceAlignArgPointerDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Use this attribute to force stack alignment.
+
+Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
+(like 'movaps') that work with the stack require operands to be 16-byte
aligned.
+This attribute realigns the stack in the function prologue to make sure the
+stack can be used with SSE instructions.
+
+Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
+Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
+rare cases where the caller does not align the stack properly (e.g. flow
+jumps from i386 arch code).
+
+ .. code-block:: c
+
+__attribute__ ((force_align_arg_pointer))
+void f () {
+ ...
+}
+
+ }];
+}
+
def SwiftCallDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
This revision was automatically updated to reflect the committed changes.
Closed by commit rL312281: Add documentation for force_align_arg_pointer
function attribute (authored by erichkeane).
Changed prior to commit:
https://reviews.llvm.org/D37312?vs=113458&id=113469#toc
Repository:
rL LLVM
https://reviews.llvm.org/D37312
Files:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
Index: cfe/trunk/include/clang/Basic/AttrDocs.td
===
--- cfe/trunk/include/clang/Basic/AttrDocs.td
+++ cfe/trunk/include/clang/Basic/AttrDocs.td
@@ -2803,6 +2803,31 @@
}];
}
+def X86ForceAlignArgPointerDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Use this attribute to force stack alignment.
+
+Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
+(like 'movaps') that work with the stack require operands to be 16-byte
aligned.
+This attribute realigns the stack in the function prologue to make sure the
+stack can be used with SSE instructions.
+
+Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
+Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
+rare cases where the caller does not align the stack properly (e.g. flow
+jumps from i386 arch code).
+
+ .. code-block:: c
+
+__attribute__ ((force_align_arg_pointer))
+void f () {
+ ...
+}
+
+ }];
+}
+
def SwiftCallDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
Index: cfe/trunk/include/clang/Basic/Attr.td
===
--- cfe/trunk/include/clang/Basic/Attr.td
+++ cfe/trunk/include/clang/Basic/Attr.td
@@ -2043,11 +2043,11 @@
}
def X86ForceAlignArgPointer : InheritableAttr,
TargetSpecificAttr {
- let Spellings = [GNU<"force_align_arg_pointer">];
+ let Spellings = [GCC<"force_align_arg_pointer">];
// Technically, this appertains to a FunctionDecl, but the target-specific
// code silently allows anything function-like (such as typedefs or function
// pointers), but does not apply the attribute to them.
- let Documentation = [Undocumented];
+ let Documentation = [X86ForceAlignArgPointerDocs];
}
def NoSanitize : InheritableAttr {
Index: cfe/trunk/include/clang/Basic/AttrDocs.td
===
--- cfe/trunk/include/clang/Basic/AttrDocs.td
+++ cfe/trunk/include/clang/Basic/AttrDocs.td
@@ -2803,6 +2803,31 @@
}];
}
+def X86ForceAlignArgPointerDocs : Documentation {
+ let Category = DocCatFunction;
+ let Content = [{
+Use this attribute to force stack alignment.
+
+Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
+(like 'movaps') that work with the stack require operands to be 16-byte aligned.
+This attribute realigns the stack in the function prologue to make sure the
+stack can be used with SSE instructions.
+
+Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
+Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
+rare cases where the caller does not align the stack properly (e.g. flow
+jumps from i386 arch code).
+
+ .. code-block:: c
+
+__attribute__ ((force_align_arg_pointer))
+void f () {
+ ...
+}
+
+ }];
+}
+
def SwiftCallDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
Index: cfe/trunk/include/clang/Basic/Attr.td
===
--- cfe/trunk/include/clang/Basic/Attr.td
+++ cfe/trunk/include/clang/Basic/Attr.td
@@ -2043,11 +2043,11 @@
}
def X86ForceAlignArgPointer : InheritableAttr, TargetSpecificAttr {
- let Spellings = [GNU<"force_align_arg_pointer">];
+ let Spellings = [GCC<"force_align_arg_pointer">];
// Technically, this appertains to a FunctionDecl, but the target-specific
// code silently allows anything function-like (such as typedefs or function
// pointers), but does not apply the attribute to them.
- let Documentation = [Undocumented];
+ let Documentation = [X86ForceAlignArgPointerDocs];
}
def NoSanitize : InheritableAttr {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
anatol.pomozov added a comment. Thank you folks for your work. By the way when these changes are going to be released? clang 6.0? Repository: rL LLVM https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312283 - Register linkageSpecDecl matcher
Author: kastiglione
Date: Thu Aug 31 14:18:27 2017
New Revision: 312283
URL: http://llvm.org/viewvc/llvm-project?rev=312283&view=rev
Log:
Register linkageSpecDecl matcher
Summary:
This allows `linkageSpecDecl` to be used from `clang-query`.
See also D31869 which similary adds `isStaticStorageClass`.
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37346
Modified:
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
Modified: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp?rev=312283&r1=312282&r2=312283&view=diff
==
--- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Thu Aug 31 14:18:27 2017
@@ -355,6 +355,7 @@ RegistryMaps::RegistryMaps() {
REGISTER_MATCHER(labelDecl);
REGISTER_MATCHER(labelStmt);
REGISTER_MATCHER(lambdaExpr);
+ REGISTER_MATCHER(linkageSpecDecl);
REGISTER_MATCHER(lValueReferenceType);
REGISTER_MATCHER(matchesName);
REGISTER_MATCHER(matchesSelector);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37346: Register linkageSpecDecl matcher
This revision was automatically updated to reflect the committed changes. Closed by commit rL312283: Register linkageSpecDecl matcher (authored by kastiglione). Repository: rL LLVM https://reviews.llvm.org/D37346 Files: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp Index: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp === --- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp +++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp @@ -355,6 +355,7 @@ REGISTER_MATCHER(labelDecl); REGISTER_MATCHER(labelStmt); REGISTER_MATCHER(lambdaExpr); + REGISTER_MATCHER(linkageSpecDecl); REGISTER_MATCHER(lValueReferenceType); REGISTER_MATCHER(matchesName); REGISTER_MATCHER(matchesSelector); Index: cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp === --- cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp +++ cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp @@ -355,6 +355,7 @@ REGISTER_MATCHER(labelDecl); REGISTER_MATCHER(labelStmt); REGISTER_MATCHER(lambdaExpr); + REGISTER_MATCHER(linkageSpecDecl); REGISTER_MATCHER(lValueReferenceType); REGISTER_MATCHER(matchesName); REGISTER_MATCHER(matchesSelector); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37312: Add documentation for force_align_arg_pointer function attribute
erichkeane added a comment. In https://reviews.llvm.org/D37312#858217, @anatol.pomozov wrote: > Thank you folks for your work. > > By the way when these changes are going to be released? clang 6.0? Most likely. Its too late to get into 5.0, and 6.0 hasn't been branched yet. Repository: rL LLVM https://reviews.llvm.org/D37312 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37346: Register linkageSpecDecl matcher
kastiglione added a comment. thanks @aaron.ballman Repository: rL LLVM https://reviews.llvm.org/D37346 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37282: clangd: Tolerate additional headers
puremourning updated this revision to Diff 113476.
puremourning added a comment.
Validate that the duplicate message is printed.
https://reviews.llvm.org/D37282
Files:
clangd/JSONRPCDispatcher.cpp
test/clangd/protocol.test
Index: test/clangd/protocol.test
===
--- /dev/null
+++ test/clangd/protocol.test
@@ -0,0 +1,82 @@
+# RUN: clangd -run-synchronously < %s | FileCheck %s
+# RUN: clangd -run-synchronously < %s 2>&1 | FileCheck -check-prefix=STDERR %s
+# vim: fileformat=dos
+# It is absolutely vital that this file has CRLF line endings.
+#
+# Test protocol parsing
+Content-Length: 125
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+# Test message with Content-Type after Content-Length
+#
+# CHECK: "jsonrpc":"2.0","id":0,"result":{"capabilities":{
+# CHECK-DAG: "textDocumentSync": 1,
+# CHECK-DAG: "documentFormattingProvider": true,
+# CHECK-DAG: "documentRangeFormattingProvider": true,
+# CHECK-DAG: "documentOnTypeFormattingProvider": {"firstTriggerCharacter":"}","moreTriggerCharacter":[]},
+# CHECK-DAG: "codeActionProvider": true,
+# CHECK-DAG: "completionProvider": {"resolveProvider": false, "triggerCharacters": [".",">",":"]},
+# CHECK-DAG: "definitionProvider": true
+# CHECK: }}
+
+Content-Length: 246
+
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"file:///main.cpp","languageId":"cpp","version":1,"text":"struct fake { int a, bb, ccc; int f(int i, const float f) const; };\nint main() {\n fake f;\n f.\n}\n"}}}
+
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+Content-Length: 146
+
+{"jsonrpc":"2.0","id":1,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+# Test message with Content-Type before Content-Length
+#
+# CHECK: {"jsonrpc":"2.0","id":1,"result":[
+# CHECK-DAG: {"label":"a","kind":5,"detail":"int","sortText":"00035a","filterText":"a","insertText":"a"}
+# CHECK: ]}
+
+X-Test: Testing
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+Content-Length: 146
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+X-Testing: Test
+
+{"jsonrpc":"2.0","id":2,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+Content-Length: 10
+Content-Length: 146
+
+{"jsonrpc":"2.0","id":3,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+# Test message with duplicate Content-Length headers
+#
+# CHECK: {"jsonrpc":"2.0","id":3,"result":[
+# CHECK-DAG: {"label":"a","kind":5,"detail":"int","sortText":"00035a","filterText":"a","insertText":"a"}
+# CHECK: ]}
+# STDERR: Warning: Duplicate Content-Length header received. The previous value for this message (10) was ignored.
+
+Content-Type: application/vscode-jsonrpc; charset-utf-8
+Content-Length: 10
+
+{"jsonrpc":"2.0","id":4,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+# Test message with malformed Content-Length
+#
+# STDERR: JSON dispatch failed!
+# Ensure we recover by sending another (valid) message
+
+Content-Length: 146
+
+{"jsonrpc":"2.0","id":5,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+# Test message with Content-Type before Content-Length
+#
+# CHECK: {"jsonrpc":"2.0","id":5,"result":[
+# CHECK-DAG: {"label":"a","kind":5,"detail":"int","sortText":"00035a","filterText":"a","insertText":"a"}
+# CHECK: ]}
+
+Content-Length: 1024
+
+{"jsonrpc":"2.0","id":5,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:/main.cpp"},"position":{"line":3,"character":5}}}
+# Test message which reads beyond the end of the stream.
+#
+# Ensure this is the last test in the file!
+# STDERR: Input was aborted. Read only {{[0-9]+}} bytes of expected {{[0-9]+}}.
+
Index: clangd/JSONRPCDispatcher.cpp
===
--- clangd/JSONRPCDispatcher.cpp
+++ clangd/JSONRPCDispatcher.cpp
@@ -136,46 +136,68 @@
JSONRPCDispatcher &Dispatcher,
bool &IsDone) {
while (In.good()) {
-// A Language Server Protocol message starts with a HTTP header, delimited
-// by \r\n.
-std::string Line;
-std::getline(In, Line);
-if (!In.good() && errno == EINTR) {
- In.clear();
- continue;
+// A Language Server Protocol message starts with a set of HTTP headers,
+// delimited by \r\n, and terminated by an empty line (\r\n).
+unsigned long long ContentLength = 0;
+while (In.good()) {
+ std::string Line;
+ std::getline(In, Lin
[PATCH] D36678: [OpenCL] Do not use vararg in emitted functions for enqueue_kernel
yaxunl updated this revision to Diff 113483.
yaxunl marked 3 inline comments as done.
yaxunl added a comment.
update tests.
https://reviews.llvm.org/D36678
Files:
lib/CodeGen/CGBuiltin.cpp
test/CodeGenOpenCL/cl20-device-side-enqueue.cl
Index: test/CodeGenOpenCL/cl20-device-side-enqueue.cl
===
--- test/CodeGenOpenCL/cl20-device-side-enqueue.cl
+++ test/CodeGenOpenCL/cl20-device-side-enqueue.cl
@@ -49,20 +49,30 @@
// COMMON: [[DEF_Q:%[0-9]+]] = load %opencl.queue_t{{.*}}*, %opencl.queue_t{{.*}}** %default_queue
// COMMON: [[FLAGS:%[0-9]+]] = load i32, i32* %flags
- // B32: call i32 (%opencl.queue_t{{.*}}*, i32, %struct.ndrange_t*, i8 addrspace(4)*, i32, ...) @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i32 256)
- // B64: call i32 (%opencl.queue_t{{.*}}*, i32, %struct.ndrange_t*, i8 addrspace(4)*, i32, ...) @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i64 256)
+ // B32: %[[TMP:.*]] = alloca [1 x i32]
+ // B32: %[[TMP1:.*]] = getelementptr [1 x i32], [1 x i32]* %[[TMP]], i32 0, i32 0
+ // B32: store i32 256, i32* %[[TMP1]], align 4
+ // B32: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i32* %[[TMP1]])
+ // B64: %[[TMP:.*]] = alloca [1 x i64]
+ // B64: %[[TMP1:.*]] = getelementptr [1 x i64], [1 x i64]* %[[TMP]], i32 0, i32 0
+ // B64: store i64 256, i64* %[[TMP1]], align 8
+ // B64: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i64* %[[TMP1]])
enqueue_kernel(default_queue, flags, ndrange,
^(local void *p) {
return;
},
256);
char c;
// COMMON: [[DEF_Q:%[0-9]+]] = load %opencl.queue_t{{.*}}*, %opencl.queue_t{{.*}}** %default_queue
// COMMON: [[FLAGS:%[0-9]+]] = load i32, i32* %flags
- // B32: [[SIZE:%[0-9]+]] = zext i8 {{%[0-9]+}} to i32
- // B32: call i32 (%opencl.queue_t{{.*}}*, i32, %struct.ndrange_t*, i8 addrspace(4)*, i32, ...) @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i32 [[SIZE]])
- // B64: [[SIZE:%[0-9]+]] = zext i8 {{%[0-9]+}} to i64
- // B64: call i32 (%opencl.queue_t{{.*}}*, i32, %struct.ndrange_t*, i8 addrspace(4)*, i32, ...) @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i64 [[SIZE]])
+ // B32: %[[TMP:.*]] = alloca [1 x i32]
+ // B32: %[[TMP1:.*]] = getelementptr [1 x i32], [1 x i32]* %[[TMP]], i32 0, i32 0
+ // B32: store i32 %{{.*}}, i32* %[[TMP1]], align 4
+ // B32: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspace(2)* } addrspace(1)* @__block_literal_global{{(.[0-9]+)?}} to i8 addrspace(1)*) to i8 addrspace(4)*), i32 1, i32* %[[TMP1]])
+ // B64: %[[TMP:.*]] = alloca [1 x i64]
+ // B64: %[[TMP1:.*]] = getelementptr [1 x i64], [1 x i64]* %[[TMP]], i32 0, i32 0
+ // B64: store i64 %{{.*}}, i64* %[[TMP1]], align 8
+ // B64: call i32 @__enqueue_kernel_vaargs(%opencl.queue_t{{.*}}* [[DEF_Q]], i32 [[FLAGS]], %struct.ndrange_t* [[NDR]]{{(.[0-9]+)?}}, i8 addrspace(4)* addrspacecast (i8 addrspace(1)* bitcast ({ i8**, i32, i32, i8*, %struct.__block_descriptor addrspac
[PATCH] D28955: [analyzer] Enable support for symbolic extension/truncation
dcoughlin added a comment. @ddcc : When I run this I get a bunch of assertion failures. Does this depend on https://reviews.llvm.org/D28953? (Which was reverted) Is it subsumed by https://reviews.llvm.org/D35450? Is this blocking on a review of another patch on our end? https://reviews.llvm.org/D28955 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
zahiraam added a comment.
Aaron,
Yes I want to this to succeed:
struct __declspec(uuid("---C000-0046")) IUnknown {};
__interface ISfFileIOPropertyPage : public IUnknown {};
But I also want this to succeed:
struct __declspec(uuid("---C000-0046")) IUnknown {};
struct IPropertyPage : public IUnknown {};
__interface ISfFileIOPropertyPage : public IPropertyPage {};
And I can't figure out how these 2 can be differentiated. I think the
conditions that I have currently are differently too. This later case doesn't
succeed with the current code.
And I want this to fail:
class __declspec(uuid("---C000-0046")) IUnknown1 {};
__interface __declspec(dllimport) ISfFileIOPropertyPage1 : public IUnknown1 {};
This currently does with the current code.
I guess I need to work on it a bit more.
https://reviews.llvm.org/D37308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37308: Interface class with uuid base record
erichkeane added a comment.
In https://reviews.llvm.org/D37308#858309, @zahiraam wrote:
> Aaron,
>
> Yes I want to this to succeed:
>
> struct __declspec(uuid("---C000-0046")) IUnknown {};
> __interface ISfFileIOPropertyPage : public IUnknown {};
>
> But I also want this to succeed:
>
> struct __declspec(uuid("---C000-0046")) IUnknown {};
> struct IPropertyPage : public IUnknown {};
> __interface ISfFileIOPropertyPage : public IPropertyPage {};
>
> And I can't figure out how these 2 can be differentiated. I think the
> conditions that I have currently are differently too. This later case doesn't
> succeed with the current code.
> And I want this to fail:
>
> class __declspec(uuid("---C000-0046")) IUnknown1 {};
> __interface __declspec(dllimport) ISfFileIOPropertyPage1 : public IUnknown1
> {};
>
> This currently does with the current code.
>
> I guess I need to work on it a bit more.
It definitely looks like you'll have to walk the inheritance tree to get the
2nd example to work. Based on that, the rule seems to be, an __interface can
inherit from:
1 - Another __interface
2 - The COMPLETE IUnknown type, such that it is a struct, with a uuid of
000...C000...46, named "IUnknown", with an empty definition. (note that this is
independent of namespace)
3- Any other type that:
-a: is a class or struct
-b: has no members
-c: inherits from at least 1 type that:
--I: Is an IUnknown type (in any namespace) --or--
--II: A type that satisfies this point 3.
-d: Inherits from no types other than those in -c.
Note that multiple inheritance is permitted:
namespace S{
struct __declspec(uuid("---C000-0046")) IUnknown {};
}
namespace S2{
struct __declspec(uuid("---C000-0046")) IUnknown {};
}
class __declspec(deprecated("asdf")) IPropertyPage2 : S::IUnknown,
S2::IUnknown { }; // Inherits from 2 different IUnknowns
class __declspec(deprecated("asdf")) IPropertyPage3 : S::IUnknown,
S2::IUnknown { };
class IP3 : IPropertyPage2, IPropertyPage3 {}; // Inherits from 2 different
classes that meet #3 above.
https://reviews.llvm.org/D37308
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312292 - [OPENMP] Fix for PR34398: assert with random access iterator if the
Author: abataev
Date: Thu Aug 31 16:06:52 2017
New Revision: 312292
URL: http://llvm.org/viewvc/llvm-project?rev=312292&view=rev
Log:
[OPENMP] Fix for PR34398: assert with random access iterator if the
step>1.
If the loop is a loot with random access iterators and the iteration
construct is represented it += n, then the compiler crashed because of
reusing of the same MaterializedTemporaryExpr around N. Patch fixes it
by using the expression as written, without any special kind of
wrappings.
Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/distribute_parallel_for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/distribute_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/for_codegen.cpp
cfe/trunk/test/OpenMP/for_loop_messages.cpp
cfe/trunk/test/OpenMP/for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/parallel_for_loop_messages.cpp
cfe/trunk/test/OpenMP/parallel_for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/simd_loop_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_loop_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/target_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_loop_messages.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_loop_messages.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_parallel_for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/target_teams_distribute_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/taskloop_loop_messages.cpp
cfe/trunk/test/OpenMP/taskloop_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/teams_distribute_loop_messages.cpp
cfe/trunk/test/OpenMP/teams_distribute_parallel_for_loop_messages.cpp
cfe/trunk/test/OpenMP/teams_distribute_parallel_for_simd_loop_messages.cpp
cfe/trunk/test/OpenMP/teams_distribute_simd_loop_messages.cpp
Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=312292&r1=312291&r2=312292&view=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Thu Aug 31 16:06:52 2017
@@ -3334,8 +3334,8 @@ bool OpenMPIterationSpaceChecker::SetSte
if (!NewStep->isValueDependent()) {
// Check that the step is integer expression.
SourceLocation StepLoc = NewStep->getLocStart();
-ExprResult Val =
-SemaRef.PerformOpenMPImplicitIntegerConversion(StepLoc, NewStep);
+ExprResult Val = SemaRef.PerformOpenMPImplicitIntegerConversion(
+StepLoc, getExprAsWritten(NewStep));
if (Val.isInvalid())
return true;
NewStep = Val.get();
Modified: cfe/trunk/test/OpenMP/distribute_parallel_for_simd_loop_messages.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/distribute_parallel_for_simd_loop_messages.cpp?rev=312292&r1=312291&r2=312292&view=diff
==
--- cfe/trunk/test/OpenMP/distribute_parallel_for_simd_loop_messages.cpp
(original)
+++ cfe/trunk/test/OpenMP/distribute_parallel_for_simd_loop_messages.cpp Thu
Aug 31 16:06:52 2017
@@ -702,7 +702,7 @@ void test_with_template() {
t1.dotest_lt(begin, end);
t2.dotest_lt(begin, end); // expected-note {{in instantiation of
member function 'TC::dotest_lt' requested here}}
dotest_gt(begin, end);// expected-note {{in instantiation of
function template specialization 'dotest_gt' requested here}}
- dotest_gt(0, 100); // expected-note {{in instantiation of
function template specialization 'dotest_gt' requested here}}
+ dotest_gt(0, 100); // expected-note {{in instantiation of
function template specialization 'dotest_gt' requested here}}
}
void test_loop_break() {
Modified: cfe/trunk/test/OpenMP/distribute_simd_loop_messages.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/distribute_simd_loop_messages.cpp?rev=312292&r1=312291&r2=312292&view=diff
==
--- cfe/trunk/test/OpenMP/distribute_simd_loop_messages.cpp (original)
+++ cfe/trunk/test/OpenMP/distribute_simd_loop_messages.cpp Thu Aug 31 16:06:52
2017
@@ -691,7 +691,7 @@ void test_with_template() {
t1.dotest_lt(begin, end);
t2.dotest_lt(begin, end); // expected-note {{in instantiation of member
function 'TC::dotest_lt' requested here}}
dotest_gt(begin, end); // expected-note {{in instantiation of function
template specialization 'dotest_gt' requested here}}
- dotest_gt(0, 100); // expected-note {{in instantiation of
function template specialization 'dotest_gt' requested here}}
+ dotest_gt(0, 100); // expected-note {{in instantiation of
function template specialization 'dotest_gt' requested here}}
}
void test_loop_break() {
Modified: cfe/trunk/test/OpenMP/for_codegen.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/
r312296 - [OPENMP] Fix the test, NFC.
Author: abataev
Date: Thu Aug 31 16:34:33 2017
New Revision: 312296
URL: http://llvm.org/viewvc/llvm-project?rev=312296&view=rev
Log:
[OPENMP] Fix the test, NFC.
Modified:
cfe/trunk/test/OpenMP/for_codegen.cpp
Modified: cfe/trunk/test/OpenMP/for_codegen.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/for_codegen.cpp?rev=312296&r1=312295&r2=312296&view=diff
==
--- cfe/trunk/test/OpenMP/for_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/for_codegen.cpp Thu Aug 31 16:34:33 2017
@@ -487,7 +487,7 @@ void loop_with_It(It begin, It begin, It end) {
#pragma omp for
- for (It it = begin; it < end; it+=1) {
+ for (It it = begin; it < end; it+=1u) {
*it = 0;
}
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D36487: Emit section information for extern variables.
efriedma added inline comments.
Comment at: lib/CodeGen/CodeGenModule.cpp:2434
+// Emit section information for extern variables.
+if (D->hasExternalStorage() && !D->isThisDeclarationADefinition()) {
+ if (const SectionAttr *SA = D->getAttr())
eandrews wrote:
> efriedma wrote:
> > Why do you specifically check "D->hasExternalStorage() &&
> > !D->isThisDeclarationADefinition()", instead of just setting the section
> > unconditionally?
> I noticed that you enter GetOrCreateLLVMGlobal( ) whenever the extern
> variable is declared as well as when it is defined. The flow of the program
> is different in each case. When the variable is defined, it also enters
> EmitGlobalVarDefinition( ). There is existing code handling section
> information here. I added the check in GetOrCreateLLVMGlobal( ) so the block
> gets skipped for variable definition, since its already handled elsewhere.
I would rather just call setSection unconditionally here, as opposed to trying
to guess whether the global will eventually be defined.
I'm also sort of concerned the behavior here could be weird if a section
attribute is added on a redeclaration (e.g. what happens if you write `extern
int x; int y = &x; extern int x __attribute((section("foo")));`)... maybe we
should emit a warning?
https://reviews.llvm.org/D36487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D36860: [Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure
[STL] > I can't check in copies of `cl.exe` and `link.exe` (the former's version is > inspected, so it can't just be a dummy file). > I'm happy without upstream tests for this logic. In the long run, I hope that > we can eliminate this internal directory structure and make it identical to > the released directory structure. [David Blaikie] > Version as in file metadata, or version as in "cl -v" printed output or the > like? > If it's file metadata (such that Clang can discover it without having to run > the binary on a test machine) might be worth making a dummy file with just > the version metadata in it. > But yeah *shrug* your call Looks like it's just the metadata, so a dummy file would be possible (Don pointed out how the version metadata is created - I thought it was some complicated process, but it's not). However, I'm not planning to write tests at the moment - I see that it is possible but there's a big leap from that to knowing how to actually write them, and I have to go back to working on C++17 features. If the logic for DevDiv-internal paths breaks, I'll deal with it then. Thanks, STL ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D35450: [analyzer] Support generating and reasoning over more symbolic constraint types
ddcc updated this revision to Diff 113505.
ddcc added a comment.
Rebase, make complexity limits configurable
https://reviews.llvm.org/D35450
Files:
include/clang/AST/Expr.h
include/clang/Config/config.h.cmake
include/clang/StaticAnalyzer/Checkers/SValExplainer.h
include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
lib/StaticAnalyzer/Core/RangedConstraintManager.cpp
lib/StaticAnalyzer/Core/SValBuilder.cpp
lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp
test/Analysis/analyzer_test.py
test/Analysis/bitwise-ops.c
test/Analysis/bool-assignment.c
test/Analysis/conditional-path-notes.c
test/Analysis/explain-svals.cpp
test/Analysis/loop-unrolling.cpp
test/Analysis/plist-macros-z3.cpp
test/Analysis/plist-macros.cpp
test/Analysis/range_casts.c
test/Analysis/std-c-library-functions.c
Index: test/Analysis/std-c-library-functions.c
===
--- test/Analysis/std-c-library-functions.c
+++ test/Analysis/std-c-library-functions.c
@@ -57,8 +57,7 @@
size_t y = fread(buf, sizeof(int), 10, fp);
clang_analyzer_eval(y <= 10); // expected-warning{{TRUE}}
size_t z = fwrite(buf, sizeof(int), y, fp);
- // FIXME: should be TRUE once symbol-symbol constraint support is improved.
- clang_analyzer_eval(z <= y); // expected-warning{{UNKNOWN}}
+ clang_analyzer_eval(z <= y); // expected-warning{{TRUE}}
}
ssize_t getline(char **, size_t *, FILE *);
Index: test/Analysis/range_casts.c
===
--- test/Analysis/range_casts.c
+++ test/Analysis/range_casts.c
@@ -67,7 +67,7 @@
{
unsigned index = -1;
if (index < foo) index = foo;
- if (index - 1 == 0) // Was not reached prior fix.
+ if (index - 1 == 0)
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
else
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
@@ -87,7 +87,7 @@
{
unsigned index = -1;
if (index < foo) index = foo;
- if (index - 1L == 0L) // Was not reached prior fix.
+ if (index - 1L == 0L)
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
else
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
@@ -117,7 +117,7 @@
{
unsigned index = -1;
if (index < foo) index = foo;
- if (index - 1UL == 0L) // Was not reached prior fix.
+ if (index - 1UL == 0L)
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
else
clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
Index: test/Analysis/plist-macros.cpp
===
--- test/Analysis/plist-macros.cpp
+++ test/Analysis/plist-macros.cpp
@@ -1,7 +1,7 @@
// RUN: %clang_analyze_cc1 -analyzer-checker=core,unix -analyzer-eagerly-assume -verify %s
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,unix -analyzer-eagerly-assume -analyzer-output=plist-multi-file -analyzer-config path-diagnostics-alternate=ture %s -o %t.plist
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,unix -analyzer-eagerly-assume -analyzer-output=plist-multi-file -analyzer-config path-diagnostics-alternate=true %s -o %t.plist
// RUN: FileCheck --input-file=%t.plist %s
-
+// REQUIRES: !z3
typedef __typeof(sizeof(int)) size_t;
void *malloc(size_t);
@@ -11,13 +11,13 @@
y++;
y--;
mallocmemory
- y++;
+ y++;
y++;
delete x; // expected-warning {{Memory allocated by malloc() should be deallocated by free(), not 'delete'}}
}
void macroIsFirstInFunction(int y) {
- mallocmemory
+ mallocmemory
y++; // expected-warning {{Potential leak of memory pointed to by 'x'}}
}
@@ -39,7 +39,7 @@
return *p; // expected-warning {{Dereference of null pointer}}
}
-#define macroWithArg(mp) mp==0
+#define macroWithArg(mp) mp==0
int macroWithArgInExpression(int *p, int y) {;
y++;
if (macroWithArg(p))
@@ -85,6 +85,7 @@
void test2(int *p) {
CALL_FN(p);
}
+
// CHECK: diagnostics
// CHECK-NEXT:
// CHECK-NEXT:
@@ -636,6 +637,69 @@
// CHECK-NEXT: end
// CHECK-NEXT:
// CHECK-NEXT:
+// CHECK-NEXT:line36
+// CHECK-NEXT:col7
+// CHECK-NEXT:file0
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:line36
+// CHECK-NEXT:col7
+// CHECK-NEXT:file0
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT: kindevent
+// CHECK-NEXT: location
+// CHECK-NEXT:
+// CHECK-NEXT: line36
+// CHECK-NEXT: col7
+// CHECK-NEXT: file0
+// CHECK-NEXT:
+// CHECK-NEXT: ranges
+// CHECK-NEXT:
+// CHECK-NEXT:
+// CHECK-NEXT:
[PATCH] D35450: [analyzer] Support generating and reasoning over more symbolic constraint types
ddcc marked 5 inline comments as done. ddcc added a comment. All testcases pass, except the issue with `range_casts.c`. The cause is still the range intersection discussed in https://reviews.llvm.org/D35450#810469. https://reviews.llvm.org/D35450 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33852: Enable __declspec(selectany) on linux
Prazek added inline comments.
Comment at: include/clang/Basic/AttrDocs.td:3154
+
+def SelectAnyDocs : Documentation {
+ let Content = [{This attribute makes global symbol have a weak definition
aaron.ballman wrote:
> I think you need to set the `Category` as well.
>
> To test this you should run something like (replacing and fixing up
> path separators as needed):
> ```
> clang-tblgen -gen-attr-docs -I \llvm\tools\clang\include
> \llvm\tools\clang\include\clang\Basic\Attr.td -o
> \llvm\tools\clang\docs\AttributeReference.rst
> ```
Thanks for the testing command. Should I do anything in order to check if docs
build?
I enabled docs with -DLLVM_BUILD_DOCS=ON, and I have sphinx. Everything builds,
but I don't see docs anywhere.
the docs looks like this:
+selectany (gnu::selectany)
+--
+.. csv-table:: Supported Syntaxes
+ :header: "GNU", "C++11", "__declspec", "Keyword", "Pragma", "Pragma clang
attribute"
+
+ "X","X","X","", "", ""
+
+This attribute appertains to a global symbol, causing it to have a weak
+definition (
+.. _`linkonce`: https://llvm.org/docs/LangRef.html#linkage-types
+), allowing the linker to select any definition.
+
+For more information see
+.. `gcc documentation`:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html
+
https://reviews.llvm.org/D33852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D33852: Enable __declspec(selectany) on linux
Prazek updated this revision to Diff 113507.
Prazek marked 4 inline comments as done.
Prazek added a comment.
- docs fixes
https://reviews.llvm.org/D33852
Files:
include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
test/Sema/attr-selectany.c
test/SemaCXX/attr-selectany.cpp
Index: test/SemaCXX/attr-selectany.cpp
===
--- test/SemaCXX/attr-selectany.cpp
+++ test/SemaCXX/attr-selectany.cpp
@@ -1,4 +1,7 @@
// RUN: %clang_cc1 -triple x86_64-win32 -fms-compatibility -fms-extensions
-fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fms-compatibility
-fms-extensions -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-win32-macho -fms-compatibility
-fms-extensions -fsyntax-only -verify -std=c++11 %s
+
// MSVC produces similar diagnostics.
__declspec(selectany) void foo() { } // expected-error{{'selectany' can only
be applied to data items with external linkage}}
Index: test/Sema/attr-selectany.c
===
--- test/Sema/attr-selectany.c
+++ test/Sema/attr-selectany.c
@@ -1,5 +1,7 @@
// RUN: %clang_cc1 -triple x86_64-win32 -fdeclspec -verify %s
// RUN: %clang_cc1 -triple x86_64-mingw32 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -verify -fdeclspec %s
+// RUN: %clang_cc1 -triple x86_64-win32-macho -verify -fdeclspec %s
extern __declspec(selectany) const int x1 = 1; // no warning, const means we
need extern in C++
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -3149,3 +3149,17 @@
ensure that this class cannot be subclassed.
}];
}
+
+
+def SelectAnyDocs : Documentation {
+ let Category = DocCatType;
+ let Content = [{
+This attribute appertains to a global symbol, causing it to have a weak
+definition (
+.. _`linkonce`: https://llvm.org/docs/LangRef.html#linkage-types
+), allowing the linker to select any definition.
+
+For more information see
+.. `gcc documentation`:
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html
+ }];
+}
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -2472,9 +2472,9 @@
let Documentation = [DLLImportDocs];
}
-def SelectAny : InheritableAttr, TargetSpecificAttr {
+def SelectAny : InheritableAttr {
let Spellings = [Declspec<"selectany">, GCC<"selectany">];
- let Documentation = [Undocumented];
+ let Documentation = [SelectAnyDocs];
}
def Thread : Attr {
Index: test/SemaCXX/attr-selectany.cpp
===
--- test/SemaCXX/attr-selectany.cpp
+++ test/SemaCXX/attr-selectany.cpp
@@ -1,4 +1,7 @@
// RUN: %clang_cc1 -triple x86_64-win32 -fms-compatibility -fms-extensions -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fms-compatibility -fms-extensions -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -triple x86_64-win32-macho -fms-compatibility -fms-extensions -fsyntax-only -verify -std=c++11 %s
+
// MSVC produces similar diagnostics.
__declspec(selectany) void foo() { } // expected-error{{'selectany' can only be applied to data items with external linkage}}
Index: test/Sema/attr-selectany.c
===
--- test/Sema/attr-selectany.c
+++ test/Sema/attr-selectany.c
@@ -1,5 +1,7 @@
// RUN: %clang_cc1 -triple x86_64-win32 -fdeclspec -verify %s
// RUN: %clang_cc1 -triple x86_64-mingw32 -verify %s
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -verify -fdeclspec %s
+// RUN: %clang_cc1 -triple x86_64-win32-macho -verify -fdeclspec %s
extern __declspec(selectany) const int x1 = 1; // no warning, const means we need extern in C++
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -3149,3 +3149,17 @@
ensure that this class cannot be subclassed.
}];
}
+
+
+def SelectAnyDocs : Documentation {
+ let Category = DocCatType;
+ let Content = [{
+This attribute appertains to a global symbol, causing it to have a weak
+definition (
+.. _`linkonce`: https://llvm.org/docs/LangRef.html#linkage-types
+), allowing the linker to select any definition.
+
+For more information see
+.. `gcc documentation`: https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html
+ }];
+}
Index: include/clang/Basic/Attr.td
===
--- include/clang/Basic/Attr.td
+++ include/clang/Basic/Attr.td
@@ -2472,9 +2472,9 @@
let Documentation = [DLLImportDocs];
}
-def SelectAny : InheritableAttr, TargetSpecificAttr {
+d
[PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation
craig.topper accepted this revision. craig.topper added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D36707 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37182: [libcxx] Special visibility macros for the experimental library
compnerd added a comment. I think that splitting this up in a series of patches would be much better. The first patch should be to do the entirely mechanical change of the visibility attribute. It is a separate library and needs its own visibility attribute. That would significantly slim down this subsequent change. A follow-up change could fix the build, and a third change adds the test harness/support the tests. https://reviews.llvm.org/D37182 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r312306 - Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
Author: mstorsjo
Date: Thu Aug 31 23:41:55 2017
New Revision: 312306
URL: http://llvm.org/viewvc/llvm-project?rev=312306&view=rev
Log:
Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data
on MinGW
This fixes cases where dynamic classes produced RTTI data with
external linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but
this change doesn't break the tests added in that revision.
The previous version had missed to update CodeGenCXX/virt-dtor-key.cpp,
which had a behaviour change only when running the testsuite on windows.
Differential revision: https://reviews.llvm.org/D37327
Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=312306&r1=312305&r2=312306&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Thu Aug 31 23:41:55 2017
@@ -2998,15 +2998,13 @@ static llvm::GlobalVariable::LinkageType
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key
function.
-// Make sure we emit our own copy instead of attempting to dllimport
it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Modified: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp?rev=312306&r1=312305&r2=312306&view=diff
==
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp Thu Aug 31 23:41:55 2017
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
Modified: cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp?rev=312306&r1=312305&r2=312306&view=diff
==
--- cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp Thu Aug 31 23:41:55 2017
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck
%s
+// RUN: %clang_cc1 -triple i386-linux -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-windows-gnu -emit-llvm %s -o - | FileCheck %s
-check-prefix CHECK-MINGW
// CHECK: @_ZTI3foo = constant
+// CHECK-MINGW: @_ZTI3foo = linkonce_odr
class foo {
foo();
virtual ~foo();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D37327: Reland r312224 - [ItaniumCXXABI] Always use linkonce_odr linkage for RTTI data on MinGW
This revision was automatically updated to reflect the committed changes.
Closed by commit rL312306: Reland r312224 - [ItaniumCXXABI] Always use
linkonce_odr linkage for RTTI data… (authored by mstorsjo).
Changed prior to commit:
https://reviews.llvm.org/D37327?vs=113380&id=113511#toc
Repository:
rL LLVM
https://reviews.llvm.org/D37327
Files:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
Index: cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
===
--- cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
+++ cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck
%s
+// RUN: %clang_cc1 -triple i386-linux -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-windows-gnu -emit-llvm %s -o - | FileCheck %s
-check-prefix CHECK-MINGW
// CHECK: @_ZTI3foo = constant
+// CHECK-MINGW: @_ZTI3foo = linkonce_odr
class foo {
foo();
virtual ~foo();
Index: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
===
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8**
@_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32
0, i32 0),
Index: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
===
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key
function.
-// Make sure we emit our own copy instead of attempting to dllimport
it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return LT;
- }
+ // MinGW always uses LinkOnceODRLinkage for type info.
+ if (RD->isDynamicClass() &&
+ !CGM.getContext()
+ .getTargetInfo()
+ .getTriple()
+ .isWindowsGNUEnvironment())
+return CGM.getVTableLinkage(RD);
}
return llvm::GlobalValue::LinkOnceODRLinkage;
Index: cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
===
--- cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
+++ cfe/trunk/test/CodeGenCXX/virt-dtor-key.cpp
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-linux -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-windows-gnu -emit-llvm %s -o - | FileCheck %s -check-prefix CHECK-MINGW
// CHECK: @_ZTI3foo = constant
+// CHECK-MINGW: @_ZTI3foo = linkonce_odr
class foo {
foo();
virtual ~foo();
Index: cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
===
--- cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
+++ cfe/trunk/test/CodeGenCXX/rtti-mingw64.cpp
@@ -2,7 +2,12 @@
struct A { int a; };
struct B : virtual A { int b; };
B b;
+class C {
+ virtual ~C();
+};
+C::~C() {}
+// CHECK: @_ZTI1C = linkonce_odr
// CHECK: @_ZTI1B = linkonce_odr constant { i8*, i8*, i32, i32, i8*, i64 }
// CHECK-SAME: i8* bitcast (i8** getelementptr inbounds (i8*, i8** @_ZTVN10__cxxabiv121__vmi_class_type_infoE, i64 2) to i8*),
// CHECK-SAME: i8* getelementptr inbounds ([3 x i8], [3 x i8]* @_ZTS1B, i32 0, i32 0),
Index: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
===
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
@@ -2998,15 +2998,13 @@
if (RD->hasAttr() &&
ShouldUseExternalRTTIDescriptor(CGM, Ty))
return llvm::GlobalValue::ExternalLinkage;
- if (RD->isDynamicClass()) {
-llvm::GlobalValue::LinkageTypes LT = CGM.getVTableLinkage(RD);
-// MinGW won't export the RTTI information when there is a key function.
-// Make sure we emit our own copy instead of attempting to dllimport it.
-if (RD->hasAttr() &&
-llvm::GlobalValue::isAvailableExternallyLinkage(LT))
- LT = llvm::GlobalValue::LinkOnceODRLinkage;
-return
