Re: [PATCH] D15222: [Patch][Profile] add “--dependent-lib= libclang_rt.profile-x86_64.a” to the CC1 command line when enabling code coverage on PS4
MaggieYi added a comment. Ping http://reviews.llvm.org/D15222 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
On 10 December 2015 at 17:42, Gao, Yunzhong <
yunzhong_...@playstation.sony.com> wrote:
> Out of curiosity, is the following test case possible too?
>
>
>
> void f();
>
> void g() __asm__(“real_g”); // rename g into real_g.
>
>
>
> void f() {
>
> g(); // this would actually be calling real_g()
>
> }
>
> void real_g() __asm__("gold"); // re-declaring real_g() into gold <--
> should this be an error too?
>
I can't see any reason why not. Both clang and gcc will emit "real_g" here
instead of "gold", but changing the asm label in a program is highly
dubious. I added an error for this too.
Thanks!
> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
> Behalf Of *Nick Lewycky via cfe-commits
> *Sent:* Thursday, December 10, 2015 3:15 PM
> *To:* Clang Commits
> *Subject:* PATCH: error on code that redeclares with an __asm__ label
> after the first ODR use
>
>
>
> PR22830 shows a case where some code was adding an __asm__ label after the
> first use of a function. GCC and Clang diverged on this code, GCC emitting
> the name in the last __asm__ label for all uses while clang would switch in
> the middle of the TU as the redeclaration was parsed. The attached patch
> detects this case and issues an error on such a redeclaration. If this
> breaks real code, we can turn it down to a warning.
>
>
>
> Please review!
>
>
>
> Nick
>
>
>
pr22830-2.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D13289: [libc++] Provide additional templates for valarray transcendentals that satisfy the standard synopsis
petpav01 updated this revision to Diff 42506.
petpav01 added a comment.
Updated patch adds more tests and fixes a problem introduced in the previous
revision where templates taking `__val_expr` were not correctly protected by
SFINAE from immediate context (it introduced same problem with explicit
template parameters that I am trying to solve).
@Eric: Could you please send me an example that shows the problem with the
ranking in overload resolution so I can add a test for it too? I would like to
understand this case because if it is not needed then a number of `atan2()` and
`pow()` templates can be reduced (to the same amount as in the original patch).
http://reviews.llvm.org/D13289
Files:
include/valarray
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/abs_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/acos_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/asin_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/atan2_valarray_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/atan2_valarray_value.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/atan2_value_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/atan_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/cos_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/cosh_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/exp_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/log10_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/log_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/pow_valarray_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/pow_valarray_value.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/pow_value_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/sin_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/sinh_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/sqrt_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tan_valarray.pass.cpp
test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tanh_valarray.pass.cpp
Index: test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tanh_valarray.pass.cpp
===
--- test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tanh_valarray.pass.cpp
+++ test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tanh_valarray.pass.cpp
@@ -33,19 +33,36 @@
int main()
{
+typedef double T;
+T a1[] = {-.9, -.5, 0., .5, .75};
+T a3[] = {-7.1629787019902447e-01,
+ -4.6211715726000974e-01,
+ 0.e+00,
+ 4.6211715726000974e-01,
+ 6.3514895238728730e-01};
+const unsigned N = sizeof(a1)/sizeof(a1[0]);
{
-typedef double T;
-T a1[] = {-.9, -.5, 0., .5, .75};
-T a3[] = {-7.1629787019902447e-01,
- -4.6211715726000974e-01,
- 0.e+00,
- 4.6211715726000974e-01,
- 6.3514895238728730e-01};
-const unsigned N = sizeof(a1)/sizeof(a1[0]);
+// tanh(valarray&)
std::valarray v1(a1, N);
std::valarray v3 = tanh(v1);
assert(v3.size() == v1.size());
for (int i = 0; i < v3.size(); ++i)
assert(is_about(v3[i], a3[i], 10));
}
+{
+// tanh(__val_expr&)
+std::valarray v1(a1, N);
+std::valarray v3 = tanh(v1 + 0.0);
+assert(v3.size() == v1.size());
+for (int i = 0; i < v3.size(); ++i)
+assert(is_about(v3[i], a3[i], 10));
+}
+{
+// tanh()
+std::valarray v1(a1, N);
+std::valarray v3 = std::tanh(v1);
+assert(v3.size() == v1.size());
+for (int i = 0; i < v3.size(); ++i)
+assert(is_about(v3[i], a3[i], 10));
+}
}
Index: test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tan_valarray.pass.cpp
===
--- test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tan_valarray.pass.cpp
+++ test/std/numerics/numarray/valarray.nonmembers/valarray.transcend/tan_valarray.pass.cpp
@@ -33,19 +33,36 @@
int main()
{
+typedef double T;
+T a1[] = {-.9, -.5, 0., .5, .75};
+T a3[] = {-1.2601582175503390e+00,
+ -5.4630248984379048e-01,
+ 0.e+00,
+ 5.4630248984
Re: [PATCH] D14274: Add alloc_size attribute to clang
majnemer added a subscriber: majnemer. Comment at: include/clang/Basic/AttrDocs.td:214 @@ +213,3 @@ + that we can lower to in the near future. This should cover a large number of + nonconst cases. + }]; nonconst -> non-const? http://reviews.llvm.org/D14274 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.
Ping. http://reviews.llvm.org/D15223
-Original Message-
From: Eric Christopher [mailto:echri...@gmail.com]
Sent: 07 December 2015 19:18
To: Alexandros Lamprineas; James Molloy; renato.go...@linaro.org;
cfe-commits@lists.llvm.org
Cc: Amara Emerson
Subject: Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for
{VS}QRDML{AS}H v8.1a intrinsics.
echristo added a comment.
One inline comment, thanks!
-eric
Comment at: test/CodeGen/aarch64-v8.1a-neon-intrinsics.c:4
@@ -3,4 +3,3 @@
// RUN: %clang_cc1 -triple aarch64-linux-gnu -target-feature +neon \ -// RUN:
-target-feature +v8.1a -O3 -S -o - %s \ -// RUN: | FileCheck %s
--check-prefix=CHECK --check-prefix=CHECK-AARCH64
+// RUN: -target-feature +v8.1a -O1 -S -emit-llvm -o - %s | FileCheck
+%s
Why do you need to enable the optimizers?
http://reviews.llvm.org/D15223
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15445: clang-format: Fix WebKit BeforeElse brace wrapping style
cjk added a comment. @djasper: Tagged you because it seems like you've reviewed a bunch recent clang-format patches. This is my first patch to any of the projects in the LLVM family, so please let me know if I've done something stupid, not added the proper reviewers/lists, etc. Cheers! http://reviews.llvm.org/D15445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15445: clang-format: Fix WebKit BeforeElse brace wrapping style
djasper accepted this revision. djasper added a comment. This revision is now accepted and ready to land. Looks good. Funny that we don't seem to have a test for this. http://reviews.llvm.org/D15445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15120: Add support for __float128 type to be used by targets that support it
nemanjai added inline comments.
Comment at: include/clang/Basic/TargetInfo.h:384
@@ +383,3 @@
+ unsigned getFloat128Width() const { return 128; }
+ unsigned getFloat128Align() const { return 128; }
+ const llvm::fltSemantics &getFloat128Format() const {
hubert.reinterpretcast wrote:
> This should probably not be hard-coded. On s390x-ibm-linux-gnu, the IEEE
> 128-bit binary format type has 8 byte alignment (not 16).
OK, I probably shouldn't have assumed anything about the alignment. I'll add
fields to the target info that can be set as needed.
Comment at: lib/CodeGen/CGDebugInfo.cpp:539
@@ -538,2 +538,3 @@
case BuiltinType::LongDouble:
+ case BuiltinType::Float128:
case BuiltinType::Double:
hubert.reinterpretcast wrote:
> Is a PPCDoubleDouble "long double" and "__float128" distinguishable on PPC
> given this DWARF treatment?
Unless there's something put into the debugger to figure out which type
something actually is, I don't think so. However, there isn't a consensus on
what encoding will be used, so I'll just leave it as-is and put a FIXME in the
code to note this.
Comment at: lib/Lex/LiteralSupport.cpp:604
@@ -596,3 +603,3 @@
if (isLong || isLongLong) break; // Cannot be repeated.
- if (isFloat) break; // LF invalid.
+ if (isFloat || isFloat128) break; // LF, QL invalid.
hubert.reinterpretcast wrote:
> minor: should the comment have FL instead of LF?
I agree that it probably should, but it was already there so I didn't change
it. I'll change it on the next review.
Repository:
rL LLVM
http://reviews.llvm.org/D15120
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15448: [analyzer] SVal Visitor.
NoQ created this revision.
NoQ added reviewers: zaks.anna, dcoughlin, xazax.hun.
NoQ added a subscriber: cfe-commits.
It seems that in several places in the code Clang Static Analyzer tries to
recursively traverse the `SVal` hierarchy, so i made a visitor for `SVal`,
`SymExpr`, and `MemRegion` hierarchies. Actually, three separate visitors, but
they're rarely useful on their own, so there's `FullSValVisitor` to merge the
three for visiting the whole thing. The approach was literally copied from
`StmtVisitor` etc in an obvious manner.
One thing that could make the visitor a lot more useful, which i'd probably
love to implement, is a simple re-usable `VisitChildren()` method (in case the
visitor's return type is `void`). Because we cannot write such method in every
visitor as easily as we do it for, say, `StmtVisitor` (we don't have a
full-featured iterator for child values/symbols/regions). This would allow a
trivial implementation of methods like "find all `ElementRegion`'s inside this
`SVal`, and mark their indices"). To-think: how should such method handle lazy
compound values?
This review is a bit green, in a sense that there's not much actually delivered
yet, apart from the visitor header itself. Some further todo's would be:
- Refactor some pieces of the code to use the visitor. In fact, we already
have the `SymbolVisitor` class somewhere. Probably `SymbolReaper` could be
simplified.
- Some checkers, that rely on exploring the hierarchy, may be making use of
the visitor. Even if existing checkers don't use it, developers of new checkers
may like it.
- The object responsible for this alpha-renaming thing would most likely look
like a `FullSValVisitor` that returns an `SVal`.
- Not sure, maybe split the three visitors into three different header files?
In order to make sure that the visitor header compiles, i started a simple
example visitor - the `SValExplainer`. It explains symbolic values in a
human-readable manner, returning an `std::string`. `SValExplainer` can be used:
- for pretty-printing values to the analyzer's end-user, eg. in checker
warning messages, or even in "[assuming ...]" diagnostic pieces instead of
pretty-printed expressions.
- for deep-testing analyzer internals, when the test needs to ensure that a
particular kind of `SVal` is produced durign analysis. In fact, one of the
tests a FIXME test that exposes a certain problem in the core.
- as a documentation for `SVal` kinds (because novice checker developers are
often confused about the meaning of different `SVal` kinds). Users may also
rely on it to understand how the analyzer works during debugging, eg. quickly
explain what does this particular `SVal` they obtained in a certain callback
actually means.
Todos for `SValExplainer` include:
- Explaining more values. In particular, i could use a bit of advice for
Objective-C-specific values, because i know very little about this language. I
might have also forgotten something. Memory spaces are worth it, most likely.
- Improving natural language. Probably some bugs would be exposed later. Not
sure if the long "of"-chains the explainer produces sound naturally.
- Probably add various constructor-time flags if there are multiple users of
the explainer having different expectations.
In order to test `SValExplainer`, a new callback was added to the
`debug.ExprInspectionChecker`, namely `clang_analyzer_explain()`, that causes
an explanation of its argument value to be printed as a warning message. I also
added another callback - `clang_analyzer_getExtent()` in order to obtain
`SymbolExtent` for testing. Testing how extents are modeled would probably be
useful later as well. Regexps are used in the tests in order to match the start
and the end of the warning message.
So, essentially, i'm humbly requesting a quick glance on this code, if this
facility is useful, if some stuff is clearly useless, and whether any of the
todos are actually wanted.
I'd probably make more updates in the process.
http://reviews.llvm.org/D15448
Files:
docs/analyzer/DebugChecks.rst
include/clang/StaticAnalyzer/Checkers/SValExplainer.h
include/clang/StaticAnalyzer/Core/PathSensitive/SValVisitor.h
lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
test/Analysis/explain-svals.cpp
Index: test/Analysis/explain-svals.cpp
===
--- /dev/null
+++ test/Analysis/explain-svals.cpp
@@ -0,0 +1,98 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core.builtin,debug.ExprInspection,unix.cstring -verify %s
+
+typedef unsigned long size_t;
+
+struct S {
+ struct S3 {
+int y[10];
+ };
+ struct S2 : S3 {
+int *x;
+ } s2[10];
+ int z;
+};
+
+
+void clang_analyzer_explain(int);
+void clang_analyzer_explain(void *);
+void clang_analyzer_explain(S);
+
+size_t clang_analyzer_getExtent(void *);
+
+size_t strlen(const char *);
+
+int conjure();
+S conjure_S();
+
+int glob;
+static in
r255337 - [OpenCL 2.0] In OpenCL v2.0 s6.5 all pointers are implicitly in generic
Author: stulova
Date: Fri Dec 11 07:49:15 2015
New Revision: 255337
URL: http://llvm.org/viewvc/llvm-project?rev=255337&view=rev
Log:
[OpenCL 2.0] In OpenCL v2.0 s6.5 all pointers are implicitly in generic
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
Added:
cfe/trunk/test/SemaOpenCL/null_literal.cl
Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
Modified: cfe/trunk/lib/AST/Expr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=255337&r1=255336&r2=255337&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Fri Dec 11 07:49:15 2015
@@ -3293,9 +3293,20 @@ Expr::isNullPointerConstant(ASTContext &
// Check that it is a cast to void*.
if (const PointerType *PT = CE->getType()->getAs()) {
QualType Pointee = PT->getPointeeType();
-if (!Pointee.hasQualifiers() &&
-Pointee->isVoidType() && // to void*
-CE->getSubExpr()->getType()->isIntegerType()) // from int.
+Qualifiers Q = Pointee.getQualifiers();
+// In OpenCL v2.0 generic address space acts as a placeholder
+// and should be ignored.
+bool IsASValid = true;
+if (Ctx.getLangOpts().OpenCLVersion >= 200) {
+ if (Pointee.getAddressSpace() == LangAS::opencl_generic)
+Q.removeAddressSpace();
+ else
+IsASValid = false;
+}
+
+if (IsASValid && !Q.hasQualifiers() &&
+Pointee->isVoidType() && // to void*
+CE->getSubExpr()->getType()->isIntegerType()) // from int.
return CE->getSubExpr()->isNullPointerConstant(Ctx, NPC);
}
}
Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255337&r1=255336&r2=255337&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Dec 11 07:49:15 2015
@@ -8806,7 +8806,8 @@ QualType Sema::CheckCompareOperands(Expr
diagnoseDistinctPointerComparison(*this, Loc, LHS, RHS,
/*isError*/false);
}
if (LCanPointeeTy != RCanPointeeTy) {
- if (getLangOpts().OpenCL) {
+ // Treat NULL constant as a special case in OpenCL.
+ if (getLangOpts().OpenCL && !LHSIsNull && !RHSIsNull) {
const PointerType *LHSPtr = LHSType->getAs();
if
(!LHSPtr->isAddressSpaceOverlapping(*RHSType->getAs())) {
Diag(Loc,
Added: cfe/trunk/test/SemaOpenCL/null_literal.cl
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/null_literal.cl?rev=255337&view=auto
==
--- cfe/trunk/test/SemaOpenCL/null_literal.cl (added)
+++ cfe/trunk/test/SemaOpenCL/null_literal.cl Fri Dec 11 07:49:15 2015
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
+
+#define NULL ((void*)0)
+
+void foo(){
+
+global int* ptr1 = NULL;
+
+global int* ptr2 = (global void*)0;
+
+constant int* ptr3 = NULL;
+
+constant int* ptr4 = (global void*)0; // expected-error{{initializing
'__constant int *' with an expression of type '__global void *' changes address
space of pointer}}
+
+#ifdef CL20
+// Accept explicitly pointer to generic address space in OpenCL v2.0.
+global int* ptr5 = (generic void*)0;
+#endif
+
+global int* ptr6 = (local void*)0; // expected-error{{initializing '__global
int *' with an expression of type '__local void *' changes address space of
pointer}}
+
+bool cmp = ptr1 == NULL;
+
+cmp = ptr1 == (local void*)0; // expected-error{{comparison between
('__global int *' and '__local void *') which are pointers to non-overlapping
address spaces}}
+
+cmp = ptr3 == NULL;
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15450: Avoid double deletion in Clang driver.
sepavloff created this revision.
sepavloff added a subscriber: cfe-commits.
Llvm module object is shared between CodeGenerator and BackendConsumer,
in both classes it is stored as std::unique_ptr, which is not a good
design solution and can cause double deletion error. Usually it does
not occur because in BackendConsumer::HandleTranslationUnit the
ownership of CodeGenerator over the module is taken away. If however
this method is not called, the module is deleted twice and compiler crashes.
As the module owned by BackendConsumer is always the same as CodeGenerator
has, local copy of llvm module can be removed from BackendGenerator.
http://reviews.llvm.org/D15450
Files:
lib/CodeGen/CodeGenAction.cpp
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -73,7 +73,6 @@
std::unique_ptr Gen;
-std::unique_ptr TheModule;
SmallVector>, 4>
LinkModules;
@@ -97,7 +96,10 @@
this->LinkModules.push_back(
std::make_pair(I.first, std::unique_ptr(I.second)));
}
-std::unique_ptr takeModule() { return std::move(TheModule); }
+llvm::Module *getModule() const { return Gen->GetModule(); }
+std::unique_ptr takeModule() {
+ return std::unique_ptr(Gen->ReleaseModule());
+}
void releaseLinkModules() {
for (auto &I : LinkModules)
I.second.release();
@@ -117,8 +119,6 @@
Gen->Initialize(Ctx);
- TheModule.reset(Gen->GetModule());
-
if (llvm::TimePassesIsEnabled)
LLVMIRGeneration.stopTimer();
}
@@ -165,27 +165,14 @@
}
// Silently ignore if we weren't initialized for some reason.
- if (!TheModule)
-return;
-
- // Make sure IR generation is happy with the module. This is released by
- // the module provider.
- llvm::Module *M = Gen->ReleaseModule();
- if (!M) {
-// The module has been released by IR gen on failures, do not double
-// free.
-TheModule.release();
+ if (!getModule())
return;
- }
-
- assert(TheModule.get() == M &&
- "Unexpected module change during IR generation");
// Link LinkModule into this module if present, preserving its validity.
for (auto &I : LinkModules) {
unsigned LinkFlags = I.first;
llvm::Module *LinkModule = I.second.get();
-if (Linker::linkModules(*M, *LinkModule,
+if (Linker::linkModules(*getModule(), *LinkModule,
[=](const DiagnosticInfo &DI) {
linkerDiagnosticHandler(DI, LinkModule,
Diags);
},
@@ -195,7 +182,7 @@
// Install an inline asm handler so that diagnostics get printed through
// our diagnostics hooks.
- LLVMContext &Ctx = TheModule->getContext();
+ LLVMContext &Ctx = getModule()->getContext();
LLVMContext::InlineAsmDiagHandlerTy OldHandler =
Ctx.getInlineAsmDiagnosticHandler();
void *OldContext = Ctx.getInlineAsmDiagnosticContext();
@@ -208,7 +195,7 @@
EmitBackendOutput(Diags, CodeGenOpts, TargetOpts, LangOpts,
C.getTargetInfo().getDataLayoutString(),
-TheModule.get(), Action, AsmOutStream);
+getModule(), Action, AsmOutStream);
Ctx.setInlineAsmDiagnosticHandler(OldHandler, OldContext);
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -73,7 +73,6 @@
std::unique_ptr Gen;
-std::unique_ptr TheModule;
SmallVector>, 4>
LinkModules;
@@ -97,7 +96,10 @@
this->LinkModules.push_back(
std::make_pair(I.first, std::unique_ptr(I.second)));
}
-std::unique_ptr takeModule() { return std::move(TheModule); }
+llvm::Module *getModule() const { return Gen->GetModule(); }
+std::unique_ptr takeModule() {
+ return std::unique_ptr(Gen->ReleaseModule());
+}
void releaseLinkModules() {
for (auto &I : LinkModules)
I.second.release();
@@ -117,8 +119,6 @@
Gen->Initialize(Ctx);
- TheModule.reset(Gen->GetModule());
-
if (llvm::TimePassesIsEnabled)
LLVMIRGeneration.stopTimer();
}
@@ -165,27 +165,14 @@
}
// Silently ignore if we weren't initialized for some reason.
- if (!TheModule)
-return;
-
- // Make sure IR generation is happy with the module. This is released by
- // the module provider.
- llvm::Module *M = Gen->ReleaseModule();
- if (!M) {
-// The module has been released by IR gen on failures, do not double
-// free.
-TheModule.release();
+ if (!getModule())
return;
- }
-
- assert(TheModule.get() == M &&
-
[PATCH]: git-clang-format
Hello everyone,
Please, consider applying the attached patch or (at your option) a
refined version of it upstream. I'd be very excited to see it make into
the upcoming 3.8 release. The patch looks self-explanatory but in case
any questions should arise, feel free to ask. I can provide both
rationale and use case examples to support it if needed. In fact, we
already use it extensively for Git 'pre-commit' hook to enforce code
style conventions.
Looking forward to your response. Thanks.
Kind regards,
Alexander
diff --git a/git-clang-format b/git-clang-format
index 0c45762..2ebd405 100755
--- a/git-clang-format
+++ b/git-clang-format
@@ -101,6 +101,8 @@ def main():
help='allow changes to unstaged files')
p.add_argument('-p', '--patch', action='store_true',
help='select hunks interactively')
+ p.add_argument('-s', '--staged', action='store_true',
+ help='consider only staged lines')
p.add_argument('-q', '--quiet', action='count', default=0,
help='print less information')
p.add_argument('--style',
@@ -141,7 +143,10 @@ def main():
# The computed diff outputs absolute paths, so we must cd before accessing
# those files.
cd_to_toplevel()
- old_tree = create_tree_from_workdir(changed_lines)
+ if opts.staged:
+old_tree = run_git_ls_files_and_save_to_tree(changed_lines)
+ else:
+old_tree = create_tree_from_workdir(changed_lines)
new_tree = run_clang_format_and_save_to_tree(changed_lines,
binary=opts.binary,
style=opts.style)
@@ -260,7 +265,7 @@ def compute_diff(commit, files):
The return value's `stdin` file object will produce a patch with the
differences between the working directory and `commit`, filtered on `files`
(if non-empty). Zero context lines are used in the patch."""
- cmd = ['git', 'diff-index', '-p', '-U0', commit, '--']
+ cmd = ['git', 'diff-index', '--cached', '-p', '-U0', commit, '--']
cmd.extend(files)
p = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
p.stdin.close()
@@ -317,6 +322,27 @@ def create_tree_from_workdir(filenames):
return create_tree(filenames, '--stdin')
+def run_git_ls_files_and_save_to_tree(changed_lines):
+ """Run git ls-files and save the result to a git tree.
+
+ Returns the object ID (SHA-1) of the created tree."""
+ index_path = os.environ.get('GIT_INDEX_FILE')
+ def index_info_generator():
+for filename, line_ranges in changed_lines.iteritems():
+ old_index_path = os.environ.get('GIT_INDEX_FILE')
+ os.environ['GIT_INDEX_FILE'] = index_path
+ try:
+mode, id, stage, filename = run('git', 'ls-files', '--stage', '--',
+filename).split()
+yield '%s %s\t%s' % (mode, id, filename)
+ finally:
+if old_index_path is None:
+ del os.environ['GIT_INDEX_FILE']
+else:
+ os.environ['GIT_INDEX_FILE'] = old_index_path
+ return create_tree(index_info_generator(), '--index-info')
+
+
def run_clang_format_and_save_to_tree(changed_lines, binary='clang-format',
style=None):
"""Run clang-format on each file and save the result to a git tree.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D14779: Adding checker to detect excess padding in records
bcraig marked 7 inline comments as done.
bcraig added a comment.
Somehow, I thought I was waiting on Anna, but I missed the Dec 1 update during
the Thanksgiving break, and nothing was blocking me. An updated patch should
be posted soon.
In http://reviews.llvm.org/D14779#299895, @zaks.anna wrote:
> > An analysis of llvm+clang+compiler-rt now only generates 16 excessive
> > padding reports in index.html.
>
>
> Should those be fixed or are they all false positives?
All of them are real problems.
- 6 of them would be straightforward to fix
- 9 of them are the exact same (difficult to fix) issue that gets duplicated
because the filenames appear different
- projects/compiler-rt/lib/**tsan**/../sanitizer_common/sanitizer_flags.h vs.
projects/compiler-rt/lib/**asan**/../sanitizer_common/sanitizer_flags.h
- It's a difficult fix because it is a structure where the elements are
defined via a preprocessor x-macro.
- 1 is in gtest-internal-inl.h, and would be straightforward to fix, but I
don't know if we would because it might be considered external code.
Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:48
@@ +47,3 @@
+// The calls to checkAST* from AnalysisConsumer don't end
+// visit template instantiations or lambda classes. We
+// want to visit those, so make our own RecursiveASTVisitor.
zaks.anna wrote:
> Wording is off here.
> Would it be possible to provide a checkAST method that does visit temple
> instantiations and lambdas? What if another checker wants the same
> functionality?
Fixed the wording.
I don't know of a good way to make the Analysis consumer just pass template
instantiations and implicit code to only the checkers that want them.
The root of a template instantiation or implicit code tree could be pretty
straightforward, but once the children of those nodes start to be examined, it
becomes a lot more difficult to determine if a particular call to malloc (for
example) should be dispatched to a particular checker.
I'm not opposed to the idea, but I would expect that kind of change to go in a
different patch.
Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:196
@@ +195,3 @@
+auto LeftFoldFunc =
+[&ASTContext, &RL](const CharUnitInfo &Old, const CharUnitInfo &New) {
+ CharUnitInfo Retval;
zaks.anna wrote:
> Is this doing more than just accumulating the padding for every field in the
> record? For example, it seems we could do it with a simple loop the does:
> PadSum += Current.Offset - (Prev.Offset + Prev.Size)
Switched to raw loop.
There has been some advice floating around the C++ community for a little while
suggesting that developers should avoid raw loops and use STL and STL like
algorithms instead. (
https://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning ).
To be honest though, the raw loop is a lot easier to read (IMO) than the two
lambas + functional programming algorithm. The raw loop is certainly shorter.
Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:249
@@ +248,3 @@
+CharUnits NewOffset = ASTContext.toCharUnitsFromBits(RL.getFieldOffset(0));
+CharUnits NewPad;
+
zaks.anna wrote:
> Is NewPad initialized?
CharUnits has a default constructor that initializes the value to 0.
http://reviews.llvm.org/D14779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH]: git-clang-format
+djasper On Fri, Dec 11, 2015 at 3:40 PM Alexander Shukaev via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Hello everyone, > > Please, consider applying the attached patch or (at your option) a > refined version of it upstream. I'd be very excited to see it make into > the upcoming 3.8 release. The patch looks self-explanatory but in case > any questions should arise, feel free to ask. I can provide both > rationale and use case examples to support it if needed. In fact, we > already use it extensively for Git 'pre-commit' hook to enforce code > style conventions. > > Looking forward to your response. Thanks. > > Kind regards, > Alexander > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255339 - Reverting r255337 as it seems to kill bots. Needs investigation.
Author: stulova
Date: Fri Dec 11 09:23:00 2015
New Revision: 255339
URL: http://llvm.org/viewvc/llvm-project?rev=255339&view=rev
Log:
Reverting r255337 as it seems to kill bots. Needs investigation.
Removed:
cfe/trunk/test/SemaOpenCL/null_literal.cl
Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
Modified: cfe/trunk/lib/AST/Expr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=255339&r1=255338&r2=255339&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Fri Dec 11 09:23:00 2015
@@ -3293,20 +3293,9 @@ Expr::isNullPointerConstant(ASTContext &
// Check that it is a cast to void*.
if (const PointerType *PT = CE->getType()->getAs()) {
QualType Pointee = PT->getPointeeType();
-Qualifiers Q = Pointee.getQualifiers();
-// In OpenCL v2.0 generic address space acts as a placeholder
-// and should be ignored.
-bool IsASValid = true;
-if (Ctx.getLangOpts().OpenCLVersion >= 200) {
- if (Pointee.getAddressSpace() == LangAS::opencl_generic)
-Q.removeAddressSpace();
- else
-IsASValid = false;
-}
-
-if (IsASValid && !Q.hasQualifiers() &&
-Pointee->isVoidType() && // to void*
-CE->getSubExpr()->getType()->isIntegerType()) // from int.
+if (!Pointee.hasQualifiers() &&
+Pointee->isVoidType() && // to void*
+CE->getSubExpr()->getType()->isIntegerType()) // from int.
return CE->getSubExpr()->isNullPointerConstant(Ctx, NPC);
}
}
Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255339&r1=255338&r2=255339&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Dec 11 09:23:00 2015
@@ -8806,8 +8806,7 @@ QualType Sema::CheckCompareOperands(Expr
diagnoseDistinctPointerComparison(*this, Loc, LHS, RHS,
/*isError*/false);
}
if (LCanPointeeTy != RCanPointeeTy) {
- // Treat NULL constant as a special case in OpenCL.
- if (getLangOpts().OpenCL && !LHSIsNull && !RHSIsNull) {
+ if (getLangOpts().OpenCL) {
const PointerType *LHSPtr = LHSType->getAs();
if
(!LHSPtr->isAddressSpaceOverlapping(*RHSType->getAs())) {
Diag(Loc,
Removed: cfe/trunk/test/SemaOpenCL/null_literal.cl
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/null_literal.cl?rev=255338&view=auto
==
--- cfe/trunk/test/SemaOpenCL/null_literal.cl (original)
+++ cfe/trunk/test/SemaOpenCL/null_literal.cl (removed)
@@ -1,29 +0,0 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
-
-#define NULL ((void*)0)
-
-void foo(){
-
-global int* ptr1 = NULL;
-
-global int* ptr2 = (global void*)0;
-
-constant int* ptr3 = NULL;
-
-constant int* ptr4 = (global void*)0; // expected-error{{initializing
'__constant int *' with an expression of type '__global void *' changes address
space of pointer}}
-
-#ifdef CL20
-// Accept explicitly pointer to generic address space in OpenCL v2.0.
-global int* ptr5 = (generic void*)0;
-#endif
-
-global int* ptr6 = (local void*)0; // expected-error{{initializing '__global
int *' with an expression of type '__local void *' changes address space of
pointer}}
-
-bool cmp = ptr1 == NULL;
-
-cmp = ptr1 == (local void*)0; // expected-error{{comparison between
('__global int *' and '__local void *') which are pointers to non-overlapping
address spaces}}
-
-cmp = ptr3 == NULL;
-
-}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH]: git-clang-format
Please submit patches to clang-format to reviews.llvm.org. Also, any change no matter how easy it is to deduce from the code itself deserves a proper change description :-). Bullet points are fine. On Fri, Dec 11, 2015 at 4:26 PM, Manuel Klimek wrote: > +djasper > > On Fri, Dec 11, 2015 at 3:40 PM Alexander Shukaev via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Hello everyone, >> >> Please, consider applying the attached patch or (at your option) a >> refined version of it upstream. I'd be very excited to see it make into >> the upcoming 3.8 release. The patch looks self-explanatory but in case >> any questions should arise, feel free to ask. I can provide both >> rationale and use case examples to support it if needed. In fact, we >> already use it extensively for Git 'pre-commit' hook to enforce code >> style conventions. >> >> Looking forward to your response. Thanks. >> >> Kind regards, >> Alexander >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D14779: Adding checker to detect excess padding in records
bcraig updated this revision to Diff 42524.
bcraig marked 3 inline comments as done.
bcraig added a comment.
Anna Zaks last round of review requests.
http://reviews.llvm.org/D14779
Files:
lib/StaticAnalyzer/Checkers/CMakeLists.txt
lib/StaticAnalyzer/Checkers/Checkers.td
lib/StaticAnalyzer/Checkers/PaddingChecker.cpp
test/Analysis/padding_c.c
test/Analysis/padding_cpp.cpp
test/Analysis/padding_message.cpp
Index: test/Analysis/padding_message.cpp
===
--- /dev/null
+++ test/Analysis/padding_message.cpp
@@ -0,0 +1,185 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -std=c++14 -analyze -analyzer-checker=performance -analyzer-config performance.Padding:AllowedPad=2 -verify %s
+
+// expected-warning@+1{{Excessive padding in 'struct IntSandwich' (6 padding bytes, where 2 is optimal)}}
+struct IntSandwich {
+ char c1;
+ int i;
+ char c2;
+};
+
+// expected-warning@+1{{Excessive padding in 'struct TurDuckHen' (6 padding bytes, where 2 is optimal)}}
+struct TurDuckHen {
+ char c1;
+ struct IntSandwich i;
+ char c2;
+};
+
+#pragma pack(push)
+#pragma pack(2)
+// expected-warning@+1{{Excessive padding in 'struct SmallIntSandwich' (4 padding bytes, where 0 is optimal)}}
+struct SmallIntSandwich {
+ char c1;
+ int i1;
+ char c2;
+ int i2;
+ char c3;
+ int i3;
+ char c4;
+};
+#pragma pack(pop)
+
+union SomeUnion { // no-warning
+ char c;
+ short s;
+ int i;
+};
+
+// expected-warning@+1{{Excessive padding in 'struct HoldsAUnion' (6 padding bytes, where 2 is optimal)}}
+struct HoldsAUnion {
+ char c1;
+ union SomeUnion u;
+ char c2;
+};
+
+struct SmallCharArray { // no-warning
+ char c[5];
+};
+
+struct MediumIntArray { // no-warning
+ int i[5];
+};
+
+// expected-warning@+1{{Excessive padding in 'struct StructSandwich' (6 padding bytes, where 2 is optimal)}}
+struct StructSandwich {
+ struct SmallCharArray s;
+ struct MediumIntArray m;
+ struct SmallCharArray s2;
+};
+
+// expected-warning@+1{{Excessive padding in 'TypedefSandwich' (6 padding bytes, where 2 is optimal)}}
+typedef struct {
+ char c1;
+ int i;
+ char c2;
+} TypedefSandwich;
+
+// expected-warning@+1{{Excessive padding in 'struct StructAttrAlign' (10 padding bytes, where 2 is optimal)}}
+struct StructAttrAlign {
+ char c1;
+ int i;
+ char c2;
+} __attribute__((aligned(8)));
+
+// expected-warning@+1{{Excessive padding in 'struct OverlyAlignedChar' (8185 padding bytes, where 4089 is optimal)}}
+struct OverlyAlignedChar {
+ char c1;
+ int x;
+ char c2;
+ char c __attribute__((aligned(4096)));
+};
+
+// expected-warning@+1{{Excessive padding in 'struct HoldsOverlyAlignedChar' (8190 padding bytes, where 4094 is optimal)}}
+struct HoldsOverlyAlignedChar {
+ char c1;
+ struct OverlyAlignedChar o;
+ char c2;
+};
+
+void internalStructFunc() {
+ // expected-warning@+1{{Excessive padding in 'struct X' (6 padding bytes, where 2 is optimal)}}
+ struct X {
+char c1;
+int t;
+char c2;
+ };
+ struct X obj;
+}
+
+void typedefStructFunc() {
+ // expected-warning@+1{{Excessive padding in 'S' (6 padding bytes, where 2 is optimal)}}
+ typedef struct {
+char c1;
+int t;
+char c2;
+ } S;
+ S obj;
+}
+
+// expected-warning@+1{{Excessive padding in 'struct DefaultAttrAlign' (22 padding bytes, where 6 is optimal)}}
+struct DefaultAttrAlign {
+ char c1;
+ long long i;
+ char c2;
+} __attribute__((aligned));
+
+// expected-warning@+1{{Excessive padding in 'struct SmallArrayShortSandwich' (2 padding bytes, where 0 is optimal)}}
+struct SmallArrayShortSandwich {
+ char c1;
+ short s;
+ char c2;
+} ShortArray[20];
+
+// expected-warning@+1{{Excessive padding in 'struct SmallArrayInFunc' (2 padding bytes, where 0 is optimal)}}
+struct SmallArrayInFunc {
+ char c1;
+ short s;
+ char c2;
+};
+
+void arrayHolder() {
+ struct SmallArrayInFunc Arr[15];
+}
+
+// expected-warning@+1{{Excessive padding in 'class VirtualIntSandwich' (10 padding bytes, where 2 is optimal)}}
+class VirtualIntSandwich {
+ virtual void foo() {}
+ char c1;
+ int i;
+ char c2;
+};
+
+// constructed so as not to have tail padding
+// expected-warning@+1{{Excessive padding in 'class InnerPaddedB' (6 padding bytes, where 2 is optimal)}}
+class InnerPaddedB {
+ char c1;
+ int i1;
+ char c2;
+ int i2;
+};
+
+class Empty {}; // no-warning
+
+// expected-warning@+1{{Excessive padding in 'class LotsOfSpace' (6 padding bytes, where 2 is optimal)}}
+class LotsOfSpace {
+ Empty e1;
+ int i;
+ Empty e2;
+};
+
+// expected-warning@+1{{Excessive padding in 'TypedefSandwich2' (6 padding bytes, where 2 is optimal)}}
+typedef struct {
+ char c1;
+ // expected-warning@+1{{Excessive padding in 'TypedefSandwich2::NestedTypedef' (6 padding bytes, where 2 is optimal)}}
+ typedef struct {
+char c1;
+int i;
+char c2;
+ } NestedTypedef;
+ NestedTypedef t;
+ char c2;
+} TypedefSandwich2;
+
+template
+struct Foo {
+ // expected-warning@+1{{Excessive padd
Re: [PATCH] D15440: [libc++abi] Use libgcc and libgcc_s to provide _Unwind symbols instead of libgcc_eh.a
compnerd added inline comments.
Comment at: cmake/config-ix.cmake:45
@@ -44,3 +44,3 @@
check_library_exists(pthread pthread_once "" LIBCXXABI_HAS_PTHREAD_LIB)
-check_library_exists(gcc_eh _Unwind_GetRegionStart "" LIBCXXABI_HAS_GCC_EH_LIB)
+check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXXABI_HAS_GCC_S_LIB)
check_library_exists(c __cxa_thread_atexit_impl ""
EricWF wrote:
> compnerd wrote:
> > Might be nice to extend this further to allow building against
> > clang_rt.builtins. We could of course do that as a follow up if you prefer.
> I don't think the clang_rt.builtin libraries are *ever* along the library
> search path. Maybe we could detect if clang accepts `--rtlib `? (I
> don't know the flag off hand).
Pretty close with the flag: it is `--rtlib=` if you like the 2 dash version.
Hmm, though the problem with the symbol we are using for gcc_s here is the crus
of the issue I think. The problem is that if clang_rt.builtins is used,
`__gcc_personality_v0` will be defined since the symbol is the C personality
routine. Perhaps a compromise may be to change the symbol we use to detect
gcc_s. However, given that this was the original behavior, Im not as
concerned, since it has worked for most people so far (and its easy to modify).
Comment at: src/CMakeLists.txt:37
@@ +36,3 @@
+
+remove_flags(-Wl,-z,defs)
+
EricWF wrote:
> compnerd wrote:
> > Do we need to worry about an alternative spelling of `-z defs`?
> Not sure. I only considered the spellings used within the LLVM source tree
> `llvm/cmake/modules/HandleLLVMOptions.cmake`.
This is a change in the original behavior. I think it may be safer to add the
`-z defs` and `-zdefs` spellings as well if you want the no undefined symbols
behavior. At least on solaris, I believe that `-no-undefined` is also going to
cause this to be emitted.
Comment at: src/CMakeLists.txt:62
@@ -44,1 +61,3 @@
+# first and last library on the link line. This behavior mimics clang's
+# behavior.
set(libraries ${LIBCXXABI_CXX_ABI_LIBRARIES})
Why does gcc_s need to be first? Is there some symbol that needs to be
resolved from it and not another provider?
http://reviews.llvm.org/D15440
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15222: [Patch][Profile] add “--dependent-lib= libclang_rt.profile-x86_64.a” to the CC1 command line when enabling code coverage on PS4
vsk added a subscriber: vsk. vsk added a comment. Thanks, comments inline -- Comment at: lib/Driver/Tools.cpp:4064 @@ -4046,1 +4063,3 @@ + // Add runtime flag for PS4 when PGO or Coverage are enabled. + if (getToolChain().getTriple().isPS4CPU()) Profiling instrumentation seems orthogonal to PIC. Could you keep the calls to `addPS4ProfileRTArgs` in their original locations? Comment at: test/Driver/ps4-runtime-flags.c:8 @@ +7,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fprofile-arcs %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-arcs -fprofile-arcs %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-arcs %s -### 2>&1 | FileCheck -check-prefix=CHECK-PS4-NO-PROFILE %s This tests whether ArgList::hasFlag() works. It doesn't really stress your patch. Please omit it. Comment at: test/Driver/ps4-runtime-flags.c:10 @@ +9,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-arcs %s -### 2>&1 | FileCheck -check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-arcs -fno-profile-arcs %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-arcs %s -### 2>&1 | FileCheck -check-prefix=CHECK-PS4-NO-PROFILE %s ^ Ditto. Comment at: test/Driver/ps4-runtime-flags.c:11 @@ +10,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fprofile-arcs -fno-profile-arcs %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-arcs %s -### 2>&1 | FileCheck -check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s Looks identical to line 9. Unless I'm missing something, this should be removed. Comment at: test/Driver/ps4-runtime-flags.c:14 @@ +13,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fprofile-generate=dir %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-generate -fprofile-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s Omit? Comment at: test/Driver/ps4-runtime-flags.c:16 @@ +15,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-generate -fno-profile-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-generate -fno-profile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s This one too. Comment at: test/Driver/ps4-runtime-flags.c:22 @@ +21,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fprofile-instr-generate=somefile.profraw %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-instr-generate -fprofile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-instr-generate -fcoverage-mappinge %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s And this. Comment at: test/Driver/ps4-runtime-flags.c:23 @@ +22,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-instr-generate -fprofile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-instr-generate -fcoverage-mappinge %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s Typo: `-fcoverage-mappinge` Comment at: test/Driver/ps4-runtime-flags.c:24 @@ +23,3 @@ +// RUN: %clang -target x86_64-scei-ps4 -fprofile-instr-generate -fcoverage-mappinge %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fno-profile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s +// RUN: %clang -target x86_64-scei-ps4 -fprofile-instr-generate -fno-profile-instr-generate %s -### 2>&1 | FileCheck --check-prefix=CHECK-PS4-NO-PROFILE %s The rest of these feel a bit redundant, but I haven't looked too closely. http://reviews.llvm.org/D15222 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D13330: Implement __attribute__((unique_instantiation))
loladiro added a comment. @majnemer Do you like the new approach? Is there anything else to be done here? http://reviews.llvm.org/D13330 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
friss created this revision.
friss added reviewers: jyknight, rnk, joerg.
friss added a subscriber: cfe-commits.
In r245667 -static was changed not to disable -fPIC as they control
2 different concepts. On toolchains that enable -fPIC by default,
this means that now you have to pass "-static -fno-PIC" to get the
previous behavior.
As static usually means that we do not need PIC, this patches allows
-static to override the toolchain default. You can still build all the
combinations, but -static doesn't require -fno-PIC anymore on default-PIC
toolchains.
http://reviews.llvm.org/D15455
Files:
lib/Driver/Tools.cpp
test/Driver/pic.c
Index: test/Driver/pic.c
===
--- test/Driver/pic.c
+++ test/Driver/pic.c
@@ -217,7 +217,7 @@
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext
-miphoneos-version-min=5.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext
-miphoneos-version-min=6.0.0 -static -### 2>&1 \
-// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
+// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
//
// On OpenBSD, PIE is enabled by default, but can be disabled.
// RUN: %clang -c %s -target amd64-pc-openbsd -### 2>&1 \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3121,8 +3121,9 @@
const ArgList &Args) {
// FIXME: why does this code...and so much everywhere else, use both
// ToolChain.getTriple() and Triple?
- bool PIE = ToolChain.isPIEDefault();
- bool PIC = PIE || ToolChain.isPICDefault();
+ bool isStatic = Args.hasArg(options::OPT_static);
+ bool PIE = ToolChain.isPIEDefault() && !isStatic;
+ bool PIC = PIE || (ToolChain.isPICDefault() && !isStatic);
bool IsPICLevelTwo = PIC;
bool KernelOrKext =
Index: test/Driver/pic.c
===
--- test/Driver/pic.c
+++ test/Driver/pic.c
@@ -217,7 +217,7 @@
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext -miphoneos-version-min=5.0.0 -### 2>&1 \
// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
// RUN: %clang -c %s -target armv7-apple-ios -fapple-kext -miphoneos-version-min=6.0.0 -static -### 2>&1 \
-// RUN: | FileCheck %s --check-prefix=CHECK-PIC2
+// RUN: | FileCheck %s --check-prefix=CHECK-NO-PIC
//
// On OpenBSD, PIE is enabled by default, but can be disabled.
// RUN: %clang -c %s -target amd64-pc-openbsd -### 2>&1 \
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3121,8 +3121,9 @@
const ArgList &Args) {
// FIXME: why does this code...and so much everywhere else, use both
// ToolChain.getTriple() and Triple?
- bool PIE = ToolChain.isPIEDefault();
- bool PIC = PIE || ToolChain.isPICDefault();
+ bool isStatic = Args.hasArg(options::OPT_static);
+ bool PIE = ToolChain.isPIEDefault() && !isStatic;
+ bool PIC = PIE || (ToolChain.isPICDefault() && !isStatic);
bool IsPICLevelTwo = PIC;
bool KernelOrKext =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255346 - [OpenCL 2.0] In OpenCL v2.0 s6.5 all pointers are implicitly in generic
Author: stulova
Date: Fri Dec 11 11:41:19 2015
New Revision: 255346
URL: http://llvm.org/viewvc/llvm-project?rev=255346&view=rev
Log:
[OpenCL 2.0] In OpenCL v2.0 s6.5 all pointers are implicitly in generic
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
Added:
cfe/trunk/test/SemaOpenCL/null_literal.cl
Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
Modified: cfe/trunk/lib/AST/Expr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=255346&r1=255345&r2=255346&view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Fri Dec 11 11:41:19 2015
@@ -3293,9 +3293,20 @@ Expr::isNullPointerConstant(ASTContext &
// Check that it is a cast to void*.
if (const PointerType *PT = CE->getType()->getAs()) {
QualType Pointee = PT->getPointeeType();
-if (!Pointee.hasQualifiers() &&
-Pointee->isVoidType() && // to void*
-CE->getSubExpr()->getType()->isIntegerType()) // from int.
+Qualifiers Q = Pointee.getQualifiers();
+// In OpenCL v2.0 generic address space acts as a placeholder
+// and should be ignored.
+bool IsASValid = true;
+if (Ctx.getLangOpts().OpenCLVersion >= 200) {
+ if (Pointee.getAddressSpace() == LangAS::opencl_generic)
+Q.removeAddressSpace();
+ else
+IsASValid = false;
+}
+
+if (IsASValid && !Q.hasQualifiers() &&
+Pointee->isVoidType() && // to void*
+CE->getSubExpr()->getType()->isIntegerType()) // from int.
return CE->getSubExpr()->isNullPointerConstant(Ctx, NPC);
}
}
Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255346&r1=255345&r2=255346&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri Dec 11 11:41:19 2015
@@ -8806,7 +8806,8 @@ QualType Sema::CheckCompareOperands(Expr
diagnoseDistinctPointerComparison(*this, Loc, LHS, RHS,
/*isError*/false);
}
if (LCanPointeeTy != RCanPointeeTy) {
- if (getLangOpts().OpenCL) {
+ // Treat NULL constant as a special case in OpenCL.
+ if (getLangOpts().OpenCL && !LHSIsNull && !RHSIsNull) {
const PointerType *LHSPtr = LHSType->getAs();
if
(!LHSPtr->isAddressSpaceOverlapping(*RHSType->getAs())) {
Diag(Loc,
Added: cfe/trunk/test/SemaOpenCL/null_literal.cl
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/null_literal.cl?rev=255346&view=auto
==
--- cfe/trunk/test/SemaOpenCL/null_literal.cl (added)
+++ cfe/trunk/test/SemaOpenCL/null_literal.cl Fri Dec 11 11:41:19 2015
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
+
+#define NULL ((void*)0)
+
+void foo(){
+
+global int* ptr1 = NULL;
+
+global int* ptr2 = (global void*)0;
+
+constant int* ptr3 = NULL;
+
+constant int* ptr4 = (global void*)0; // expected-error{{initializing
'__constant int *' with an expression of type '__global void *' changes address
space of pointer}}
+
+#ifdef CL20
+// Accept explicitly pointer to generic address space in OpenCL v2.0.
+global int* ptr5 = (generic void*)0;
+#endif
+
+global int* ptr6 = (local void*)0; // expected-error{{initializing '__global
int *' with an expression of type '__local void *' changes address space of
pointer}}
+
+bool cmp = ptr1 == NULL;
+
+cmp = ptr1 == (local void*)0; // expected-error{{comparison between
('__global int *' and '__local void *') which are pointers to non-overlapping
address spaces}}
+
+cmp = ptr3 == NULL;
+
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15228: [PATCH] New diagnostic for non-idiomatic copy or move operations
aaron.ballman abandoned this revision. aaron.ballman added a comment. Abandoning this revision, will post a new patch approach shortly. http://reviews.llvm.org/D15228 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15411: [clang-tidy] Check for suspicious string assignments.
LegalizeAdulthood added a subscriber: LegalizeAdulthood.
Comment at: test/clang-tidy/misc-string-integer-assignment.cpp:25
@@ +24,3 @@
+int main() {
+ std::string s("foobar");
+
Use {} initialization perhaps?
http://reviews.llvm.org/D15411
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15456: [PATCH] New diagnostic for non-idiomatic copy or move operations (v2)
aaron.ballman created this revision. aaron.ballman added reviewers: rsmith, dblaikie. aaron.ballman added a subscriber: cfe-commits. All copy operations were created equal (as far as the core language is concerned), but some copy operations are more equal than others (as far as the library is concerned). The same is true of move operations. This patch diagnoses copy and move operations (constructors and assignment operators) that are non-idiomatic so that users are not surprised when their copyable type cannot be placed in a standard library container or used with a standard library algorithm. Idiomatic copy and move operations are (where T is the class type for the object): Copy Constructor: takes a const T& Move constructor: takes a T&& Copy Assignment: takes a const T&, returns a T&, and has no ref-qualifiers Move Assignment: takes a T&&, returns a T&, and has no ref-qualifiers This patch does not diagnose *all* non-idiomatic uses because of false positives in practice. Specifically, it does not diagnose when a non-idiomatic operation is overloaded with an idiomatic one (T(const T&); T(T&);) or when there are multiple non-idiomatic operation overloads (T(volatile T&); T(T&);). In both cases, it is reasonable to assume that the user knows they have non-idiomatic signatures. This means that the diagnostic can always be suppressed by either converting the operation into an idiomatic one, or by adding an overload that is deleted (or is private, as in pre-C++11 code bases), depending on the behavior they desire. One thing this patch does could have are fix-it hints to correct the types involved. However, I cannot find a way to get the full source range for the type, including qualifiers. For a parameter of type 'const volatile T&', the TypeLoc appears to only track the location of T&, but not the qualifiers. Assistance in understanding how to do this would be appreciated. http://reviews.llvm.org/D15456 Files: include/clang/Basic/DiagnosticGroups.td include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaDeclCXX.cpp test/Analysis/NewDelete-checker-test.cpp test/Analysis/inlining/path-notes.cpp test/Analysis/operator-calls.cpp test/CXX/basic/basic.types/p10.cpp test/CXX/class.access/p4.cpp test/CXX/class/class.union/p1.cpp test/CXX/class/p6-0x.cpp test/CXX/dcl.decl/dcl.fct.def/dcl.fct.def.default/p1.cpp test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-cxx03-extra-copy.cpp test/CXX/dcl.decl/dcl.init/dcl.init.ref/p5-cxx0x-no-extra-copy.cpp test/CXX/dcl.decl/dcl.meaning/dcl.fct/dcl.fct.def.default/p2.cpp test/CXX/drs/dr0xx.cpp test/CXX/drs/dr1xx.cpp test/CXX/drs/dr3xx.cpp test/CXX/drs/dr5xx.cpp test/CXX/expr/expr.prim/expr.prim.lambda/p14.cpp test/CXX/expr/expr.prim/expr.prim.lambda/p21.cpp test/CXX/special/class.copy/implicit-move.cpp test/CXX/special/class.copy/p11.0x.copy.cpp test/CXX/special/class.copy/p12-0x.cpp test/CXX/special/class.copy/p18-cxx11.cpp test/CXX/special/class.copy/p20.cpp test/CXX/special/class.copy/p23-cxx11.cpp test/CXX/special/class.copy/p25-0x.cpp test/CXX/special/class.copy/p8-cxx11.cpp test/CXX/special/class.copy/p9.cpp test/CXX/stmt.stmt/stmt.dcl/p3-0x.cpp test/CXX/stmt.stmt/stmt.dcl/p3.cpp test/CXX/temp/temp.fct.spec/temp.deduct/cwg1170.cpp test/CodeGenCXX/copy-assign-synthesis-3.cpp test/OpenMP/for_firstprivate_messages.cpp test/OpenMP/for_lastprivate_messages.cpp test/OpenMP/for_reduction_messages.cpp test/OpenMP/for_simd_lastprivate_messages.cpp test/OpenMP/for_simd_reduction_messages.cpp test/OpenMP/parallel_copyin_messages.cpp test/OpenMP/parallel_for_copyin_messages.cpp test/OpenMP/parallel_for_lastprivate_messages.cpp test/OpenMP/parallel_for_reduction_messages.cpp test/OpenMP/parallel_for_simd_copyin_messages.cpp test/OpenMP/parallel_for_simd_lastprivate_messages.cpp test/OpenMP/parallel_for_simd_reduction_messages.cpp test/OpenMP/parallel_reduction_messages.cpp test/OpenMP/parallel_sections_copyin_messages.cpp test/OpenMP/parallel_sections_lastprivate_messages.cpp test/OpenMP/parallel_sections_reduction_messages.cpp test/OpenMP/parallel_sections_shared_messages.cpp test/OpenMP/parallel_shared_messages.cpp test/OpenMP/sections_lastprivate_messages.cpp test/OpenMP/sections_reduction_messages.cpp test/OpenMP/simd_lastprivate_messages.cpp test/OpenMP/simd_reduction_messages.cpp test/OpenMP/single_copyprivate_messages.cpp test/OpenMP/target_map_messages.cpp test/OpenMP/task_shared_messages.cpp test/OpenMP/taskloop_firstprivate_messages.cpp test/OpenMP/taskloop_lastprivate_messages.cpp test/OpenMP/taskloop_simd_firstprivate_messages.cpp test/OpenMP/taskloop_simd_lastprivate_messages.cpp test/OpenMP/teams_reduction_messages.cpp test/OpenMP/teams_shared_messages.cpp test/Parser/cxx0x-ambig.cpp test/SemaCUDA/implicit-copy.cu test/SemaCUDA/implicit-member-target.cu test/SemaCXX/MicrosoftCompatibility.cpp test/SemaCXX/conditional-
Re: [PATCH] D15456: [PATCH] New diagnostic for non-idiomatic copy or move operations (v2)
aaron.ballman added a comment. I should note that the majority of the changes in this patch are to deal with the diagnostic triggering on test cases. I tried to correct the test cases to be idiomatic where it appears the signature of the operation was not the purpose of the test. The other cases either got an expected-warning, or had the flag disabled. I ran the diagnostic over several code bases, and the outcome was: LLVM: 0 warnings Qt: 7206 warnings (most of these are duplicate diagnostics because the signatures are in a header file) rethinkdb: 34 warnings (same here) cocos2d: 0 warnings opencv: 0 warnings http://reviews.llvm.org/D15456 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D9600: Add scan-build python implementation
dcoughlin added inline comments.
Comment at: tools/scan-build-py/README.md:85
@@ +84,3 @@
+
+The 2. mode is available only on FreeBSD, Linux and OSX. Where library preload
+is available from the dynamic loader. On OSX System Integrity Protection
security
My comment about SIP on 10.11 not preventing library interposition on build
tools is not correct. My apologies for the bad information. SIP does not
prevent DYLD_INSERT_LIBRARIES on the build tools themselves but it *does*
prevent interposition on the build tool shims in /usr/bin. These are thin shims
that call the appropriate tools elsewhere and it is these shims that typical
build scripts call. SIP also prevents library interposition on perl/python/etc.
-- which are commonly used to drive build scripts. (For example, openssl's
build script uses make to call perl to call cc). I think on Darwin we should
use your wrapper-based approach (intercept-c/intercept-c++) instead. In my
tests on openssl it produces the same (modulo ordering of entries) compilation
database as running with library-interposition on a machine with SIP turned off.
Comment at: tools/scan-build-py/libear/ear.c:141
@@ +140,3 @@
+environ = *_NSGetEnviron();
+#endif
+if (!initialized)
rizsotto.mailinglist wrote:
> this call just sets up the `environ` variables for the `bear_capture_env_t`
> method, two lines down. that call saves the relevant variables... so, if
> before execv'ing somebody modify the variables we still have it saved. (by
> the way `Scons` is the tool which does this.) and when `call_execve` called
> it recovers from the saved environment.
>
> there is a test against it. (tests/functional/cases/test_create_cdb.py:53)
>
> > The issue I am seeing with library-interposition on OS X [...]
>
> can you give me details what did you see? what was the test you were running?
You also later use 'environ' in `execv()`. But at that point the environment
stashed in environ is different than the environment given to children. So in
execv() rather than using 'environ' you on Darwin you would need to use
'*_NSGetEnviron()'. (The behavior of 'environ' on Darwin in dylibs is different
than in main executables, which is why _NSGetEnviron() exists). In any event,
if only support using wrapper-based interposition (intercept-build-cc, etc.) on
Darwin then perhaps we don't need to deal with this.
>> there is a test against it. (tests/functional/cases/test_create_cdb.py:53)
Interesting. Have you run the tests on OS X? Can you tell me how to run them?
Comment at: tools/scan-build-py/libscanbuild/intercept.py:143
@@ +142,3 @@
+})
+elif sys.platform == 'darwin':
+logging.debug('intercept gonna preload libear on OSX')
I think it would be better to use the fall-back compiler-wrapper interposition
on darwin. As I noted above (apologies again for the bad information) System
Integrity Protection will make library-based interposition unreliable for build
scripts that employ restricted executables.
http://reviews.llvm.org/D9600
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15384: Don't ask for the size of dependent integral types in template diffing
rnk added a comment. Digging back through more history, I see that Richard added the call to getTypeSize in http://reviews.llvm.org/rL230603. http://reviews.llvm.org/D15384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15140: Update clang to use the updated LLVM EH instructions
rnk added inline comments.
Comment at: lib/CodeGen/CGCall.cpp:3482
@@ +3481,3 @@
+ &EHPersonality::get(*this) ==
+ &EHPersonality::MSVC_CxxFrameHandler3) {
+// The MSVC++ personality will implicitly terminate the program if an
I guess we have a cleaner way of writing this:
EHPersonality::get(*this).isMSVCXXPersonality()
Comment at: lib/CodeGen/CGException.cpp:899
@@ -892,10 +898,3 @@
-// If this is the last handler, we're at the end, and the next
-// block is the block for the enclosing EH scope.
-if (I + 1 == E) {
- NextBlock = CGF.createBasicBlock("catchendblock");
- CGBuilderTy(CGF, NextBlock).CreateCatchEndPad(
- CGF.getEHDispatchBlock(CatchScope.getEnclosingEHScope()));
-} else {
- NextBlock = CGF.createBasicBlock("catch.dispatch");
-}
+llvm::BasicBlock *CatchPadBB = CGF.createBasicBlock("catch");
+CGF.EmitBlock(CatchPadBB);
This creates one extra basic block per catch handler. Why not insert the
catchpadinst directly into Handler.Block, emit Handler.Block, and add
Handler.Block to the switch?
If this disturbs the test cases too much, then we can punt on it for now.
Comment at: lib/CodeGen/CGException.cpp:910
@@ -911,3 +909,3 @@
-// Otherwise we need to emit and continue at that block.
-CGF.EmitBlock(NextBlock);
+CGF.Builder.CreateBr(Handler.Block);
+
If we go with the suggestion above, we don't need this Br.
Comment at: lib/CodeGen/MicrosoftCXXABI.cpp:896-897
@@ -895,4 +895,4 @@
VarDecl *CatchParam = S->getExceptionDecl();
llvm::BasicBlock *CatchPadBB =
CGF.Builder.GetInsertBlock()->getSinglePredecessor();
llvm::CatchPadInst *CPI =
If we emit the catchpadinst into Handler.Block, we can drop the
'getSinglePredecessor' call.
http://reviews.llvm.org/D15140
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D14274: Add alloc_size attribute to clang
george.burgess.iv added inline comments.
Comment at: include/clang/Basic/Attr.td:714
@@ +713,3 @@
+ let Spellings = [GCC<"alloc_size">];
+ let Subjects = SubjectList<[Function]>;
+ let Args = [IntArgument<"ElemSizeParam">, IntArgument<"NumElemsParam", 1>];
aaron.ballman wrote:
> Should this be using HasFunctionProto instead of Function?
Nice catch!
Comment at: include/clang/Basic/AttrDocs.td:214
@@ +213,3 @@
+ that we can lower to in the near future. This should cover a large number of
+ nonconst cases.
+ }];
majnemer wrote:
> nonconst -> non-const?
Danke
Comment at: lib/AST/ExprConstant.cpp:1109
@@ -1022,1 +1108,3 @@
void set(APValue::LValueBase B, unsigned I = 0, bool BInvalid = false) {
+#ifndef NDEBUG
+ // We only allow a few types of invalid bases. Enforce that here.
aaron.ballman wrote:
> Is there a reason this assert only fires in !NDEBUG mode? Is it too expensive
> to enable for any assert build?
I was under the impression that asserts are only enabled if !NDEBUG. The code
only exists to make a few assertions, so I think guarding it with "if
assertions are enabled" makes that purpose more clear. If my assumption is
wrong, I'm happy to remove the ifndef.
Comment at: lib/Sema/SemaDeclAttr.cpp:728
@@ +727,3 @@
+
+ if (!FPT->getParamType(FuncParamNo - 1)->isIntegerType()) {
+auto SrcLoc = Attr.getArgAsExpr(AttrArgNo)->getLocStart();
aaron.ballman wrote:
> Are character types and Boolean types also okay?
Boolean makes no sense, but char is fine here. Thanks
Comment at: lib/Sema/SemaDeclAttr.cpp:766
@@ +765,3 @@
+S.Diag(Attr.getLoc(), diag::warn_attribute_wrong_decl_type)
+<< Attr.getName() << 4;
+return;
aaron.ballman wrote:
> Please, no magic numbers. I don't think 4 is even the correct value, that's
> ExpectedParameter.
Doesn't matter; dead code.
http://reviews.llvm.org/D14274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D14274: Add alloc_size attribute to clang
george.burgess.iv updated this revision to Diff 42547.
george.burgess.iv marked an inline comment as done.
george.burgess.iv added a comment.
- Fixed wording in AttrDocs
- Realized I forgot to press 'submit' on comment responses after the last
update. Will correct this in ~5 seconds :)
http://reviews.llvm.org/D14274
Files:
include/clang/Basic/Attr.td
include/clang/Basic/AttrDocs.td
include/clang/Basic/DiagnosticSemaKinds.td
lib/AST/ExprConstant.cpp
lib/Sema/SemaDeclAttr.cpp
test/CodeGen/alloc-size.c
test/CodeGenCXX/global-init.cpp
test/Sema/alloc-size.c
test/SemaCXX/constant-expression-cxx11.cpp
Index: test/SemaCXX/constant-expression-cxx11.cpp
===
--- test/SemaCXX/constant-expression-cxx11.cpp
+++ test/SemaCXX/constant-expression-cxx11.cpp
@@ -1156,7 +1156,7 @@
constexpr int m2b = const_cast(n2); // expected-error {{constant expression}} expected-note {{read of volatile object 'n2'}}
struct T { int n; };
-const T t = { 42 }; // expected-note {{declared here}}
+const T t = { 42 };
constexpr int f(volatile int &&r) {
return r; // expected-note {{read of volatile-qualified type 'volatile int'}}
@@ -1168,7 +1168,7 @@
int j : f(0); // expected-error {{constant expression}} expected-note {{in call to 'f(0)'}}
int k : g(0); // expected-error {{constant expression}} expected-note {{temporary created here}} expected-note {{in call to 'g(0)'}}
int l : n3; // expected-error {{constant expression}} expected-note {{read of non-const variable}}
- int m : t.n; // expected-error {{constant expression}} expected-note {{read of non-constexpr variable}}
+ int m : t.n; // expected-warning{{width of bit-field 'm' (42 bits)}}
};
}
Index: test/Sema/alloc-size.c
===
--- /dev/null
+++ test/Sema/alloc-size.c
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 %s -verify
+
+void *fail1(int a) __attribute__((alloc_size)); //expected-error{{'alloc_size' attribute takes at least 1 argument}}
+void *fail2(int a) __attribute__((alloc_size())); //expected-error{{'alloc_size' attribute takes at least 1 argument}}
+
+void *fail3(int a) __attribute__((alloc_size(0))); //expected-error{{'alloc_size' attribute parameter 1 is out of bounds: can only be 1, since there is one parameter}}
+void *fail4(int a) __attribute__((alloc_size(2))); //expected-error{{'alloc_size' attribute parameter 1 is out of bounds: can only be 1, since there is one parameter}}
+
+void *fail5(int a, int b) __attribute__((alloc_size(0, 1))); //expected-error{{'alloc_size' attribute parameter 1 is out of bounds: must be between 1 and 2}}
+void *fail6(int a, int b) __attribute__((alloc_size(3, 1))); //expected-error{{'alloc_size' attribute parameter 1 is out of bounds: must be between 1 and 2}}
+
+void *fail7(int a, int b) __attribute__((alloc_size(1, 0))); //expected-error{{'alloc_size' attribute parameter 2 is out of bounds: must be between 1 and 2}}
+void *fail8(int a, int b) __attribute__((alloc_size(1, 3))); //expected-error{{'alloc_size' attribute parameter 2 is out of bounds: must be between 1 and 2}}
+
+int fail9(int a) __attribute__((alloc_size(1))); //expected-warning{{'alloc_size' attribute only applies to return values that are pointers}}
+
+int fail10 __attribute__((alloc_size(1))); //expected-warning{{'alloc_size' attribute only applies to non-K&R-style functions}}
+
+void *fail11(void *a) __attribute__((alloc_size(1))); //expected-error{{'alloc_size' attribute argument may only refer to a function parameter of integer type}}
+
+void *fail12(int a) __attribute__((alloc_size("abc"))); //expected-error{{'alloc_size' attribute requires parameter 1 to be an integer constant}}
+void *fail12(int a) __attribute__((alloc_size(1, "abc"))); //expected-error{{'alloc_size' attribute requires parameter 2 to be an integer constant}}
+void *fail13(int a) __attribute__((alloc_size(1U<<31))); //expected-error{{integer constant expression evaluates to value 2147483648 that cannot be represented in a 32-bit signed integer type}}
Index: test/CodeGenCXX/global-init.cpp
===
--- test/CodeGenCXX/global-init.cpp
+++ test/CodeGenCXX/global-init.cpp
@@ -18,9 +18,6 @@
// CHECK: @__dso_handle = external global i8
// CHECK: @c = global %struct.C zeroinitializer, align 8
-// It's okay if we ever implement the IR-generation optimization to remove this.
-// CHECK: @_ZN5test3L3varE = internal constant i8* getelementptr inbounds ([7 x i8], [7 x i8]*
-
// PR6205: The casts should not require global initializers
// CHECK: @_ZN6PR59741cE = external global %"struct.PR5974::C"
// CHECK: @_ZN6PR59741aE = global %"struct.PR5974::A"* getelementptr inbounds (%"struct.PR5974::C", %"struct.PR5974::C"* @_ZN6PR59741cE, i32 0, i32 0)
Index: test/CodeGen/alloc-size.c
===
--- /dev/null
+++ test/CodeGen/alloc-size.c
@
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
joerg added a comment. As before, I don't see why a linker flag should change code generation. That seems to be a gross violation of layering and quite surprising. http://reviews.llvm.org/D15455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
eraman updated this revision to Diff 42549.
eraman added a comment.
Added a test case.
Repository:
rL LLVM
http://reviews.llvm.org/D15163
Files:
lib/CodeGen/CodeGenModule.cpp
test/CodeGen/pgo-max-function-count.c
Index: test/CodeGen/pgo-max-function-count.c
===
--- /dev/null
+++ test/CodeGen/pgo-max-function-count.c
@@ -0,0 +1,9 @@
+// RUN: %clang -fprofile-generate -o %t -O2 %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
+// Check
+int main() {
+ return 0;
+}
+// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -376,6 +376,9 @@
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
+ // In PGO mode, attach maximum function count to the module.
+ if (PGOReader)
+getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
Index: test/CodeGen/pgo-max-function-count.c
===
--- /dev/null
+++ test/CodeGen/pgo-max-function-count.c
@@ -0,0 +1,9 @@
+// RUN: %clang -fprofile-generate -o %t -O2 %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
+// Check
+int main() {
+ return 0;
+}
+// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -376,6 +376,9 @@
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
+ // In PGO mode, attach maximum function count to the module.
+ if (PGOReader)
+getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15444: [clang-modernize] AddOverride: tests for handling throw() and noexcept() specifiers
Eugene.Zelenko added a subscriber: Eugene.Zelenko. Eugene.Zelenko added a comment. Should be moved to Clang-tidy, since clang-modernize is deprecated. http://reviews.llvm.org/D15444 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
friss added a comment. Just because it makes the behavior more intuitive? If you toolchain does PIC by default, it's because you are mostly building shared objects. When you are building a static object, it's highly likely that you don't need PIC. There should be a way to enable it, but I find it really awkward to have to spell "clang -static -fno-PIC" to get the intuitive behavior. http://reviews.llvm.org/D15455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255366 - [PGO] Stop using invalid char in instr variable names.
Author: davidxl
Date: Fri Dec 11 13:53:35 2015
New Revision: 255366
URL: http://llvm.org/viewvc/llvm-project?rev=255366&view=rev
Log:
[PGO] Stop using invalid char in instr variable names.
(This is part-2 of the patch -- fixing test cases)
Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specified when the file contains
any static functions (the -S output is also invalid).
This patch fixed the issue. With the change, the index format
version will be bumped up by 1. Backward compatibility is
preserved with this change.
Differential Revision: http://reviews.llvm.org/D15243
Modified:
cfe/trunk/test/CoverageMapping/unused_names.c
cfe/trunk/test/Profile/Inputs/c-captured.proftext
cfe/trunk/test/Profile/Inputs/c-general.proftext
cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
cfe/trunk/test/Profile/Inputs/objc-general.proftext
cfe/trunk/test/Profile/c-captured.c
cfe/trunk/test/Profile/c-general.c
cfe/trunk/test/Profile/c-linkage.c
cfe/trunk/test/Profile/cxx-lambda.cpp
cfe/trunk/test/Profile/objc-general.m
Modified: cfe/trunk/test/CoverageMapping/unused_names.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/unused_names.c?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/CoverageMapping/unused_names.c (original)
+++ cfe/trunk/test/CoverageMapping/unused_names.c Fri Dec 11 13:53:35 2015
@@ -6,7 +6,7 @@
// CHECK-DAG: @__llvm_profile_name_bar = {{.*}} [3 x i8] c"bar", section
"{{.*}}__llvm_prf_names"
// CHECK-DAG: @__llvm_profile_name_baz = {{.*}} [3 x i8] c"baz", section
"{{.*}}__llvm_prf_names"
-// CHECK-DAG: @"__llvm_profile_name_unused_names.c:qux" = {{.*}} [18 x i8]
c"unused_names.c:qux", section "{{.*}}__llvm_prf_names"
+// CHECK-DAG: @__llvm_profile_name_unused_names.c__qux = {{.*}} [19 x i8]
c"unused_names.c__qux", section "{{.*}}__llvm_prf_names"
// SYSHEADER-NOT: @__llvm_profile_name_foo =
Modified: cfe/trunk/test/Profile/Inputs/c-captured.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-captured.proftext?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/Profile/Inputs/c-captured.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/c-captured.proftext Fri Dec 11 13:53:35 2015
@@ -1,10 +1,10 @@
-c-captured.c:__captured_stmt
+c-captured.ccaptured_stmt
10
2
1
1
-c-captured.c:__captured_stmt.1
+c-captured.ccaptured_stmt.1
266
3
1
Modified: cfe/trunk/test/Profile/Inputs/c-general.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-general.proftext?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/Profile/Inputs/c-general.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/c-general.proftext Fri Dec 11 13:53:35 2015
@@ -149,7 +149,7 @@ main
1
1
-c-general.c:static_func
+c-general.c__static_func
4
2
1
Modified: cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext Fri Dec 11 13:53:35 2015
@@ -1,4 +1,4 @@
-cxx-lambda.cpp:_ZZ7lambdasvENK3$_0clEi
+cxx-lambda.cpp___ZZ7lambdasvENK3$_0clEi
654
3
10
Modified: cfe/trunk/test/Profile/Inputs/objc-general.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/objc-general.proftext?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/Profile/Inputs/objc-general.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/objc-general.proftext Fri Dec 11 13:53:35 2015
@@ -1,10 +1,10 @@
-objc-general.m:__13+[A foreach:]_block_invoke
+objc-general.m13+[A foreach:]_block_invoke
10
2
2
1
-objc-general.m:+[A foreach:]
+objc-general.m__+[A foreach:]
6
2
1
Modified: cfe/trunk/test/Profile/c-captured.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/c-captured.c?rev=255366&r1=255365&r2=255366&view=diff
==
--- cfe/trunk/test/Profile/c-captured.c (original)
+++ cfe/trunk/test/Profile/c-captured.c Fri Dec 11 13:53:35 2015
@@ -4,8 +4,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name
c-captured.c %s -o - -emit-llvm -fprofile-instr-use=%t.profdata | FileCheck
-check-prefix=PGOUSE -check-prefix=PGOALL %s
// PGOGEN: @[[DCC:__llvm_profile_counters_debug_captured]] = private global [3
x i64] zeroinitializer
-// PGOGEN: @[[CSC:"__llvm_profile_counters_c-c
Re: [PATCH] D14274: Add alloc_size attribute to clang
aaron.ballman added inline comments.
Comment at: lib/AST/ExprConstant.cpp:1110
@@ -1022,1 +1109,3 @@
void set(APValue::LValueBase B, unsigned I = 0, bool BInvalid = false) {
+#ifndef NDEBUG
+ // We only allow a few types of invalid bases. Enforce that here.
> I was under the impression that asserts are only enabled if !NDEBUG. The code
> only exists to make a few assertions, so I think guarding it with "if
> assertions are enabled" makes that purpose more clear. If my assumption is
> wrong, I'm happy to remove the ifndef.
That's a good point; I forgot that we use NDEBUG as our release+asserts flag
(derp). That being said, this is basically the same as:
```
assert((!BInvalid || isa(B.get()) ||
tryUnwrapAllocSizeCall(B.get())) && "Unexpected type of invalid base");
```
Uncertain if that is an improvement or not, but it is shorter-ish. :-)
Comment at: lib/Sema/SemaDeclAttr.cpp:728
@@ +727,3 @@
+
+ const ParmVarDecl *Param = FD->getParamDecl(FuncParamNo - 1);
+ if (!Param->getType()->isIntegerType() && !Param->getType()->isCharType()) {
> Boolean makes no sense, but char is fine here. Thanks
isIntegerType() already covers isCharType(). I think what you want is:
```
if (!Param->getType()->isIntegerType() || Param->getType()->isBooleanType())
```
http://reviews.llvm.org/D14274
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15444: [clang-modernize] AddOverride: tests for handling throw() and noexcept() specifiers
adek05 added a comment. I don't see any tests for AddOverride in tests/clang-tidy yet. Is clang-tidy linking everything that clang-modernizer has? If so, I can create another patch which just moves these tests over. http://reviews.llvm.org/D15444 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15444: [clang-modernize] AddOverride: tests for handling throw() and noexcept() specifiers
Eugene.Zelenko added a comment. In http://reviews.llvm.org/D15444#308573, @adek05 wrote: > I don't see any tests for AddOverride in tests/clang-tidy yet. Is clang-tidy > linking everything that clang-modernizer has? If so, I can create another > patch which just moves these tests over. Clanag-modernize functionality was moved to Clang-tidy and extended there (modernize- check). See http://clang.llvm.org/extra/clang-tidy/checks/list.html. http://reviews.llvm.org/D15444 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
friss added reviewers: silvas, probinson. friss added a comment. Adding some SCE people, as their platform would be impacted by that change. http://reviews.llvm.org/D15455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
jyknight added a comment. In http://reviews.llvm.org/D15455#308532, @joerg wrote: > As before, I don't see why a linker flag should change code generation. That > seems to be a gross violation of layering and quite surprising. I agree. http://reviews.llvm.org/D15455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255368 - [PGO] Revert r255366: solution incomplete, not handling lambda yet
Author: davidxl
Date: Fri Dec 11 14:23:12 2015
New Revision: 255368
URL: http://llvm.org/viewvc/llvm-project?rev=255368&view=rev
Log:
[PGO] Revert r255366: solution incomplete, not handling lambda yet
Modified:
cfe/trunk/test/CoverageMapping/unused_names.c
cfe/trunk/test/Profile/Inputs/c-captured.proftext
cfe/trunk/test/Profile/Inputs/c-general.proftext
cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
cfe/trunk/test/Profile/Inputs/objc-general.proftext
cfe/trunk/test/Profile/c-captured.c
cfe/trunk/test/Profile/c-general.c
cfe/trunk/test/Profile/c-linkage.c
cfe/trunk/test/Profile/cxx-lambda.cpp
cfe/trunk/test/Profile/objc-general.m
Modified: cfe/trunk/test/CoverageMapping/unused_names.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/unused_names.c?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/CoverageMapping/unused_names.c (original)
+++ cfe/trunk/test/CoverageMapping/unused_names.c Fri Dec 11 14:23:12 2015
@@ -6,7 +6,7 @@
// CHECK-DAG: @__llvm_profile_name_bar = {{.*}} [3 x i8] c"bar", section
"{{.*}}__llvm_prf_names"
// CHECK-DAG: @__llvm_profile_name_baz = {{.*}} [3 x i8] c"baz", section
"{{.*}}__llvm_prf_names"
-// CHECK-DAG: @__llvm_profile_name_unused_names.c__qux = {{.*}} [19 x i8]
c"unused_names.c__qux", section "{{.*}}__llvm_prf_names"
+// CHECK-DAG: @"__llvm_profile_name_unused_names.c:qux" = {{.*}} [18 x i8]
c"unused_names.c:qux", section "{{.*}}__llvm_prf_names"
// SYSHEADER-NOT: @__llvm_profile_name_foo =
Modified: cfe/trunk/test/Profile/Inputs/c-captured.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-captured.proftext?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/Profile/Inputs/c-captured.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/c-captured.proftext Fri Dec 11 14:23:12 2015
@@ -1,10 +1,10 @@
-c-captured.ccaptured_stmt
+c-captured.c:__captured_stmt
10
2
1
1
-c-captured.ccaptured_stmt.1
+c-captured.c:__captured_stmt.1
266
3
1
Modified: cfe/trunk/test/Profile/Inputs/c-general.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-general.proftext?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/Profile/Inputs/c-general.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/c-general.proftext Fri Dec 11 14:23:12 2015
@@ -149,7 +149,7 @@ main
1
1
-c-general.c__static_func
+c-general.c:static_func
4
2
1
Modified: cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext Fri Dec 11 14:23:12 2015
@@ -1,4 +1,4 @@
-cxx-lambda.cpp___ZZ7lambdasvENK3$_0clEi
+cxx-lambda.cpp:_ZZ7lambdasvENK3$_0clEi
654
3
10
Modified: cfe/trunk/test/Profile/Inputs/objc-general.proftext
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/objc-general.proftext?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/Profile/Inputs/objc-general.proftext (original)
+++ cfe/trunk/test/Profile/Inputs/objc-general.proftext Fri Dec 11 14:23:12 2015
@@ -1,10 +1,10 @@
-objc-general.m13+[A foreach:]_block_invoke
+objc-general.m:__13+[A foreach:]_block_invoke
10
2
2
1
-objc-general.m__+[A foreach:]
+objc-general.m:+[A foreach:]
6
2
1
Modified: cfe/trunk/test/Profile/c-captured.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/c-captured.c?rev=255368&r1=255367&r2=255368&view=diff
==
--- cfe/trunk/test/Profile/c-captured.c (original)
+++ cfe/trunk/test/Profile/c-captured.c Fri Dec 11 14:23:12 2015
@@ -4,8 +4,8 @@
// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name
c-captured.c %s -o - -emit-llvm -fprofile-instr-use=%t.profdata | FileCheck
-check-prefix=PGOUSE -check-prefix=PGOALL %s
// PGOGEN: @[[DCC:__llvm_profile_counters_debug_captured]] = private global [3
x i64] zeroinitializer
-// PGOGEN: @[[CSC:__llvm_profile_counters_c-captured.ccaptured_stmt]] =
private global [2 x i64] zeroinitializer
-// PGOGEN: @[[C1C:__llvm_profile_counters_c-captured.ccaptured_stmt.1]] =
private global [3 x i64] zeroinitializer
+// PGOGEN: @[[CSC:"__llvm_profile_counters_c-captured.c:__captured_stmt"]] =
private global [2 x i64] zeroinitializer
+// PGOGEN: @[[C1C:"__llvm_profile_counters_c-captured.c:__captured_stmt.1"]] =
private global [3 x i64]
Re: [PATCH] D12299: [libcxx] ABI-Breaking Fix for ALL undefined behavior in .
EricWF added inline comments. Comment at: include/list:198 @@ +197,3 @@ +__node_pointer; +__node_base_pointer __prev_; +__node_base_pointer __next_; Possible ABI break here. http://reviews.llvm.org/D12299 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15445: clang-format: Fix WebKit BeforeElse brace wrapping style
cjk added a comment. Excellent. Mind committing this on my behalf? I don't have commit access. http://reviews.llvm.org/D15445 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
gcc 4.8.2 accepts the following case silently without error or warning:
void f();
void g() __asm__(“real_g”);
void f() { g(); } // gcc emits a call to real_g() here
void real_g() __asm__(“gold”);
void real_g() { } // gcc generates a body for gold() here
gcc 4.8.2 generates a warning for the following test case:
void g() __asm__(“func1”);
void g() __asm__(“func2”); // gcc generates a warning and ignores this asm label
void g() { }
Comparing to gcc behavior, I think it is better to emit error in both cases.
Looks good to me. Thanks!
- Gao
From: Nick Lewycky [mailto:nlewy...@google.com]
Sent: Friday, December 11, 2015 12:44 AM
To: Gao, Yunzhong
Cc: Clang Commits
Subject: Re: PATCH: error on code that redeclares with an __asm__ label after
the first ODR use
On 10 December 2015 at 17:42, Gao, Yunzhong
mailto:yunzhong_...@playstation.sony.com>>
wrote:
Out of curiosity, is the following test case possible too?
void f();
void g() __asm__(“real_g”); // rename g into real_g.
void f() {
g(); // this would actually be calling real_g()
}
void real_g() __asm__("gold"); // re-declaring real_g() into gold <-- should
this be an error too?
I can't see any reason why not. Both clang and gcc will emit "real_g" here
instead of "gold", but changing the asm label in a program is highly dubious. I
added an error for this too.
Thanks!
From: cfe-commits
[mailto:cfe-commits-boun...@lists.llvm.org]
On Behalf Of Nick Lewycky via cfe-commits
Sent: Thursday, December 10, 2015 3:15 PM
To: Clang Commits
Subject: PATCH: error on code that redeclares with an __asm__ label after the
first ODR use
PR22830 shows a case where some code was adding an __asm__ label after the
first use of a function. GCC and Clang diverged on this code, GCC emitting the
name in the last __asm__ label for all uses while clang would switch in the
middle of the TU as the redeclaration was parsed. The attached patch detects
this case and issues an error on such a redeclaration. If this breaks real
code, we can turn it down to a warning.
Please review!
Nick
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15384: Don't ask for the size of dependent integral types in template diffing
rtrieu added a comment. So there's three or four semi-related failures around this part template diffing. I'm investigating the best way to handle these bugs. http://reviews.llvm.org/D15384 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
On Fri, Dec 11, 2015 at 12:43 PM, Gao, Yunzhong via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> gcc 4.8.2 accepts the following case silently without error or warning:
>
> void f();
>
> void g() __asm__(“real_g”);
>
> void f() { g(); } // gcc emits a call to real_g() here
>
> void real_g() __asm__(“gold”);
>
> void real_g() { } // gcc generates a body for gold() here
>
>
>
> gcc 4.8.2 generates a warning for the following test case:
>
> void g() __asm__(“func1”);
>
> void g() __asm__(“func2”); // gcc generates a warning and ignores this asm
> label
>
> void g() { }
>
>
>
> Comparing to gcc behavior, I think it is better to emit error in both
> cases.
>
Why? I don't see anything wrong with the first example. We have a function
whose source-level name is "g()" and whose asm name is "real_g", and we
have a function whose source-level name is "real_g()" and whose asm name is
"gold". What's wrong with that?
> Looks good to me. Thanks!
>
> - Gao
>
>
>
>
>
> *From:* Nick Lewycky [mailto:nlewy...@google.com]
> *Sent:* Friday, December 11, 2015 12:44 AM
> *To:* Gao, Yunzhong
> *Cc:* Clang Commits
> *Subject:* Re: PATCH: error on code that redeclares with an __asm__ label
> after the first ODR use
>
>
>
> On 10 December 2015 at 17:42, Gao, Yunzhong <
> yunzhong_...@playstation.sony.com> wrote:
>
> Out of curiosity, is the following test case possible too?
>
>
>
> void f();
>
> void g() __asm__(“real_g”); // rename g into real_g.
>
>
>
> void f() {
>
> g(); // this would actually be calling real_g()
>
> }
>
> void real_g() __asm__("gold"); // re-declaring real_g() into gold <--
> should this be an error too?
>
>
>
> I can't see any reason why not. Both clang and gcc will emit "real_g" here
> instead of "gold", but changing the asm label in a program is highly
> dubious. I added an error for this too.
>
>
>
> Thanks!
>
>
>
> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
> Behalf Of *Nick Lewycky via cfe-commits
> *Sent:* Thursday, December 10, 2015 3:15 PM
> *To:* Clang Commits
> *Subject:* PATCH: error on code that redeclares with an __asm__ label
> after the first ODR use
>
>
>
> PR22830 shows a case where some code was adding an __asm__ label after the
> first use of a function. GCC and Clang diverged on this code, GCC emitting
> the name in the last __asm__ label for all uses while clang would switch in
> the middle of the TU as the redeclaration was parsed. The attached patch
> detects this case and issues an error on such a redeclaration. If this
> breaks real code, we can turn it down to a warning.
>
>
>
> Please review!
>
>
>
> Nick
>
>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
On Fri, Dec 11, 2015 at 07:49:25PM +, Frederic Riss wrote: > friss added a comment. > > Just because it makes the behavior more intuitive? If you toolchain > does PIC by default, it's because you are mostly building shared > objects. When you are building a static object, it's highly likely > that you don't need PIC. There should be a way to enable it, but I > find it really awkward to have to spell "clang -static -fno-PIC" to > get the intuitive behavior. There is nothing wrong with linking PIC as static binary. In some cases that can even result in more compact binaries. The only platforms I know that default to PIC are some RISC architectures like PPC or MIPS, where the overhead of materializing immediates is comparable to indirect calls. Most people don't use single-step compilation anyway, so your change would be just more puzzling. Why does clang -c && clang -static give different results than clang -static? Joerg ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] Reinstate and fix overload sets to be const-correct wherever possible
On Thu, Dec 10, 2015 at 5:24 PM, Duncan P. N. Exon Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > > On 2015-Dec-10, at 15:32, Richard Smith wrote: > > > > On Thu, Dec 10, 2015 at 11:45 AM, Marshall Clow > wrote: > > On Tue, Dec 8, 2015 at 3:52 PM, Richard Smith > wrote: > > Ping. > > > > Sorry about that. > > Completely missed this in my email flood. > > > > This approach looks ok to me, but I wonder if it would be better to get > Apple to fix their iOS C library instead. > > > > Well, it's not broken in the sense that it does what the C standard > library is supposed to do. But it's not providing the "C pieces" of a C++ > standard library. I don't know what its design goal is here, but with this > patch we don't need to care. > > > > Duncan offered to file a bug on this, but I don't know if that's > happened. > > Nope, I lost track of this. > > I just re-read the thread and I'm not clear on what bug I would even file > with the Libc folks. > > Darwin's implementation of the string.h C header seems to match what > n1570's 7.24.5.2 The strchr function asks for. That's not the right thing > for n3337's 21.7 Null-terminated sequence utilities, but that does seem > like a problem for libc++ to solve. > Here's the rub: that problem is impossible for a C++ standard library to solve, assuming that its includes the underlying C , and it doesn't use any non-portable extension (beyond something like #include_next) nor assume that it knows the exact implementation details of the C library. This is the problem that Howard was bemoaning upthread. I suppose if we apply the patch in this thread, then recent Clang + recent libc++ + Darwin's libc will provide the right signatures, and if that's the only configuration you guys care about going forward then there's no bug for you to fix. But that's a decision for Apple to make, not us. In any case, this patch fixes the corresponding problem in other libc implementations that don't provide the C++ signatures (such as musl libc). > I'm probably missing the point somehow though. If you can clarify exactly > what should be different in Libc (whether or not it's a bug in C), I can > ask around and find out how likely it is to get fixed. (What does GCC do > here that it's not a problem over there? Provide different signatures > depending on whether the caller is C or C++?) > What other C standard libraries do (at least glibc, MSVC's libc, probably others) is to provide the C++ signatures when __cplusplus is defined. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15462: [CMake] Add support for generating profdata for clang from training files
beanz created this revision.
beanz added reviewers: dexonsmith, silvas, friss, vsk, bogner, cmatthews.
beanz added a subscriber: cfe-commits.
This patch adds support for using LIT to drive generating PGO profile data for
clang.
This first pass implementation should work on Linux and Unix based platforms.
If you build clang using CMake with LLVM_BUILD_INSTRUMENTED=On the CMake build
generates a generate-profdata target that will use the just-built clang to
build any test files (see hello_world.cpp as an example). Each test compile
will generate profraw files for each clang process. After all tests have run
CMake will merge the profraw files using llvm-profdata.
Future opportunities for extension:
* Support for Build->Profile->Build bootstrapping
* Support for linker order file generation using a similar mechanism and the
same training data
* Support for Windows
http://reviews.llvm.org/D15462
Files:
CMakeLists.txt
utils/perf-training/CMakeLists.txt
utils/perf-training/README.txt
utils/perf-training/cxx/hello_world.cpp
utils/perf-training/lit.cfg
utils/perf-training/lit.site.cfg.in
Index: utils/perf-training/lit.site.cfg.in
===
--- /dev/null
+++ utils/perf-training/lit.site.cfg.in
@@ -0,0 +1,20 @@
+import sys
+
+## Autogenerated by LLVM/Clang configuration.
+# Do not edit!
+config.clang_tools_dir = "@CLANG_TOOLS_DIR@"
+config.test_exec_root = "@CMAKE_CURRENT_BINARY_DIR@"
+config.test_source_root = "@CMAKE_CURRENT_SOURCE_DIR@"
+config.target_triple = "@TARGET_TRIPLE@"
+
+# Support substitution of the tools and libs dirs with user parameters. This is
+# used when we can't determine the tool dir at configuration time.
+try:
+config.clang_tools_dir = config.clang_tools_dir % lit_config.params
+except KeyError:
+e = sys.exc_info()[1]
+key, = e.args
+lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % (key,key))
+
+# Let the main config do the real work.
+lit_config.load_config(config, "@CLANG_SOURCE_DIR@/utils/perf-training/lit.cfg")
Index: utils/perf-training/lit.cfg
===
--- /dev/null
+++ utils/perf-training/lit.cfg
@@ -0,0 +1,53 @@
+# -*- Python -*-
+
+from lit import Test
+import lit.formats
+import lit.util
+
+def inferClang(PATH):
+# Determine which clang to use.
+clang = os.getenv('CLANG')
+
+# If the user set clang in the environment, definitely use that and don't
+# try to validate.
+if clang:
+return clang
+
+# Otherwise look in the path.
+clang = lit.util.which('clang', PATH)
+
+if not clang:
+lit_config.fatal("couldn't find 'clang' program, try setting "
+ "CLANG in your environment")
+
+return clang
+
+def getSysrootFlagsOnDarwin(config, lit_config):
+# On Darwin, support relocatable SDKs by providing Clang with a
+# default system root path.
+if 'darwin' in config.target_triple:
+try:
+out = lit.util.capture(['xcrun', '--show-sdk-path']).strip()
+res = 0
+except OSError:
+res = -1
+if res == 0 and out:
+sdk_path = out
+lit_config.note('using SDKROOT: %r' % sdk_path)
+return '-isysroot %s' % sdk_path
+return ''
+
+sysroot_flags = getSysrootFlagsOnDarwin(config, lit_config)
+
+config.clang = inferClang(config.clang_tools_dir).replace('\\', '/')
+
+config.name = 'Clang Perf Training'
+config.suffixes = ['.c', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.S', '.modulemap']
+
+use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
+config.test_format = lit.formats.ShTest(use_lit_shell == "0")
+config.substitutions.append( ('%clang_cpp', ' %s --driver-mode=cpp %s ' % (config.clang, sysroot_flags)))
+config.substitutions.append( ('%clang', ' %s %s ' % (config.clang, sysroot_flags) ) )
+
+config.environment['LLVM_PROFILE_FILE'] = 'perf-training-%p.profraw'
+
Index: utils/perf-training/cxx/hello_world.cpp
===
--- /dev/null
+++ utils/perf-training/cxx/hello_world.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cpp -c %s
+#include
+
+int main(int, char**) {
+ std::cout << "Hello, World!";
+ return 0;
+}
Index: utils/perf-training/README.txt
===
--- /dev/null
+++ utils/perf-training/README.txt
@@ -0,0 +1,6 @@
+==
+ Performance Training Data
+==
+
+This directory contains simple source files for use as training data for
+generating PGO data and linker order files for clang.
Index: utils/perf-training/CMakeLists.txt
===
--- /dev/null
+++ utils/perf-training/CMakeLists.txt
@@ -0,0 +1,36 @@
+if(LLVM_BUILD_INSTRUMENTED AND NOT WIN32)
+ if (CMAKE_CFG_INTDIR STREQUAL ".")
+set(LLVM_BUILD_MODE ".")
+ else ()
+
[PATCH] D15463: [Objective-c] Fix a crash
ahatanak created this revision.
ahatanak added a subscriber: cfe-commits.
This patch fixes a crash that occurs when __kindof is incorrectly used in the
type parameter list of an interface. The crash occurs because
ObjCTypeParamList::back() is called in checkTypeParamListConsistency on an
empty list:
00762 diagLoc = S.getLocForEndOfToken(newTypeParams->back()->getLocEnd());
http://reviews.llvm.org/D15463
Files:
lib/Parse/ParseObjc.cpp
test/SemaObjC/kindof.m
Index: test/SemaObjC/kindof.m
===
--- test/SemaObjC/kindof.m
+++ test/SemaObjC/kindof.m
@@ -302,3 +302,13 @@
void processCopyable(__typeof(getSomeCopyable()) string);
processCopyable(0); // expected-warning{{null passed to a callee that
requires a non-null argument}}
}
+
+// __kinddof cannot be used in parameter list.
+@interface Array1 : NSObject
+@end
+
+@interface I1 : NSObject
+@end
+
+@interface Array1<__kindof I1*>(extensions) // // expected-error{{expected
type parameter name}}
+@end
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -603,7 +603,7 @@
// whether there are any protocol references.
lAngleLoc = SourceLocation();
rAngleLoc = SourceLocation();
- return list;
+ return invalid ? nullptr : list;
}
/// Parse an objc-type-parameter-list.
Index: test/SemaObjC/kindof.m
===
--- test/SemaObjC/kindof.m
+++ test/SemaObjC/kindof.m
@@ -302,3 +302,13 @@
void processCopyable(__typeof(getSomeCopyable()) string);
processCopyable(0); // expected-warning{{null passed to a callee that requires a non-null argument}}
}
+
+// __kinddof cannot be used in parameter list.
+@interface Array1 : NSObject
+@end
+
+@interface I1 : NSObject
+@end
+
+@interface Array1<__kindof I1*>(extensions) // // expected-error{{expected type parameter name}}
+@end
Index: lib/Parse/ParseObjc.cpp
===
--- lib/Parse/ParseObjc.cpp
+++ lib/Parse/ParseObjc.cpp
@@ -603,7 +603,7 @@
// whether there are any protocol references.
lAngleLoc = SourceLocation();
rAngleLoc = SourceLocation();
- return list;
+ return invalid ? nullptr : list;
}
/// Parse an objc-type-parameter-list.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
On 11 December 2015 at 12:57, Richard Smith wrote:
> On Fri, Dec 11, 2015 at 12:43 PM, Gao, Yunzhong via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> gcc 4.8.2 accepts the following case silently without error or warning:
>>
>> void f();
>>
>> void g() __asm__(“real_g”);
>>
>> void f() { g(); } // gcc emits a call to real_g() here
>>
>> void real_g() __asm__(“gold”);
>>
>> void real_g() { } // gcc generates a body for gold() here
>>
>>
>>
>> gcc 4.8.2 generates a warning for the following test case:
>>
>> void g() __asm__(“func1”);
>>
>> void g() __asm__(“func2”); // gcc generates a warning and ignores this
>> asm label
>>
>> void g() { }
>>
>>
>>
>> Comparing to gcc behavior, I think it is better to emit error in both
>> cases.
>>
>
> Why? I don't see anything wrong with the first example. We have a function
> whose source-level name is "g()" and whose asm name is "real_g", and we
> have a function whose source-level name is "real_g()" and whose asm name is
> "gold". What's wrong with that?
>
Hah, I completely misread the example and fixed something else. What I
added an error for is:
void f() __asm__("something");
void f() __asm__("somethingelse");
With my patch, we don't issue an error on the case Yunzhong actually
supplied. Joerg has pointed out over IRC that this is a really useful
construct and that NetBSD's stack smashing protection uses it. We shouldn't
break that. I've added a testcase to make sure it continues working. Please
review!
Nick
Looks good to me. Thanks!
>>
>> - Gao
>>
>>
>>
>>
>>
>> *From:* Nick Lewycky [mailto:nlewy...@google.com]
>> *Sent:* Friday, December 11, 2015 12:44 AM
>> *To:* Gao, Yunzhong
>> *Cc:* Clang Commits
>> *Subject:* Re: PATCH: error on code that redeclares with an __asm__
>> label after the first ODR use
>>
>>
>>
>> On 10 December 2015 at 17:42, Gao, Yunzhong <
>> yunzhong_...@playstation.sony.com> wrote:
>>
>> Out of curiosity, is the following test case possible too?
>>
>>
>>
>> void f();
>>
>> void g() __asm__(“real_g”); // rename g into real_g.
>>
>>
>>
>> void f() {
>>
>> g(); // this would actually be calling real_g()
>>
>> }
>>
>> void real_g() __asm__("gold"); // re-declaring real_g() into gold <--
>> should this be an error too?
>>
>>
>>
>> I can't see any reason why not. Both clang and gcc will emit "real_g"
>> here instead of "gold", but changing the asm label in a program is highly
>> dubious. I added an error for this too.
>>
>>
>>
>> Thanks!
>>
>>
>>
>> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
>> Behalf Of *Nick Lewycky via cfe-commits
>> *Sent:* Thursday, December 10, 2015 3:15 PM
>> *To:* Clang Commits
>> *Subject:* PATCH: error on code that redeclares with an __asm__ label
>> after the first ODR use
>>
>>
>>
>> PR22830 shows a case where some code was adding an __asm__ label after
>> the first use of a function. GCC and Clang diverged on this code, GCC
>> emitting the name in the last __asm__ label for all uses while clang would
>> switch in the middle of the TU as the redeclaration was parsed. The
>> attached patch detects this case and issues an error on such a
>> redeclaration. If this breaks real code, we can turn it down to a warning.
>>
>>
>>
>> Please review!
>>
>>
>>
>> Nick
>>
>>
>>
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>>
>
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td (revision 255303)
+++ include/clang/Basic/DiagnosticSemaKinds.td (working copy)
@@ -4256,6 +4256,9 @@
def err_conflicting_types : Error<"conflicting types for %0">;
def err_different_pass_object_size_params : Error<
"conflicting pass_object_size attributes on parameters">;
+def err_late_asm_label_name : Error<
+ "cannot apply asm label to %select{variable|function}0 after its first use">;
+def err_different_asm_label : Error<"conflicting asm label">;
def err_nested_redefinition : Error<"nested redefinition of %0">;
def err_use_with_wrong_tag : Error<
"use of %0 with tag type that does not match previous declaration">;
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp (revision 255303)
+++ lib/Sema/SemaDecl.cpp (working copy)
@@ -2379,9 +2379,24 @@
if (!Old->hasAttrs() && !New->hasAttrs())
return;
- // attributes declared post-definition are currently ignored
+ // Attributes declared post-definition are currently ignored.
checkNewAttributesAfterDef(*this, New, Old);
+ if (AsmLabelAttr *NewA = New->getAttr()) {
+if (AsmLabelAttr *OldA = Old->getAttr()) {
+ if (OldA->getLabel() != NewA->getLabel()) {
+ // This redeclaration changes __asm__ label.
+Diag(New->getLocation(), diag::err_different_asm_label);
+Diag(OldA->getLocation(), diag::n
Re: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
LGTM
+ if (OldA->getLabel() != NewA->getLabel()) {
+ // This redeclaration changes __asm__ label.
+Diag(New->getLocation(), diag::err_different_asm_label);
Comment is underindented by one space.
On Fri, Dec 11, 2015 at 1:17 PM, Nick Lewycky wrote:
> On 11 December 2015 at 12:57, Richard Smith wrote:
>
>> On Fri, Dec 11, 2015 at 12:43 PM, Gao, Yunzhong via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> gcc 4.8.2 accepts the following case silently without error or warning:
>>>
>>> void f();
>>>
>>> void g() __asm__(“real_g”);
>>>
>>> void f() { g(); } // gcc emits a call to real_g() here
>>>
>>> void real_g() __asm__(“gold”);
>>>
>>> void real_g() { } // gcc generates a body for gold() here
>>>
>>>
>>>
>>> gcc 4.8.2 generates a warning for the following test case:
>>>
>>> void g() __asm__(“func1”);
>>>
>>> void g() __asm__(“func2”); // gcc generates a warning and ignores this
>>> asm label
>>>
>>> void g() { }
>>>
>>>
>>>
>>> Comparing to gcc behavior, I think it is better to emit error in both
>>> cases.
>>>
>>
>> Why? I don't see anything wrong with the first example. We have a
>> function whose source-level name is "g()" and whose asm name is "real_g",
>> and we have a function whose source-level name is "real_g()" and whose asm
>> name is "gold". What's wrong with that?
>>
>
> Hah, I completely misread the example and fixed something else. What I
> added an error for is:
>
> void f() __asm__("something");
> void f() __asm__("somethingelse");
>
> With my patch, we don't issue an error on the case Yunzhong actually
> supplied. Joerg has pointed out over IRC that this is a really useful
> construct and that NetBSD's stack smashing protection uses it. We shouldn't
> break that. I've added a testcase to make sure it continues working. Please
> review!
>
> Nick
>
> Looks good to me. Thanks!
>>>
>>> - Gao
>>>
>>>
>>>
>>>
>>>
>>> *From:* Nick Lewycky [mailto:nlewy...@google.com]
>>> *Sent:* Friday, December 11, 2015 12:44 AM
>>> *To:* Gao, Yunzhong
>>> *Cc:* Clang Commits
>>> *Subject:* Re: PATCH: error on code that redeclares with an __asm__
>>> label after the first ODR use
>>>
>>>
>>>
>>> On 10 December 2015 at 17:42, Gao, Yunzhong <
>>> yunzhong_...@playstation.sony.com> wrote:
>>>
>>> Out of curiosity, is the following test case possible too?
>>>
>>>
>>>
>>> void f();
>>>
>>> void g() __asm__(“real_g”); // rename g into real_g.
>>>
>>>
>>>
>>> void f() {
>>>
>>> g(); // this would actually be calling real_g()
>>>
>>> }
>>>
>>> void real_g() __asm__("gold"); // re-declaring real_g() into gold <--
>>> should this be an error too?
>>>
>>>
>>>
>>> I can't see any reason why not. Both clang and gcc will emit "real_g"
>>> here instead of "gold", but changing the asm label in a program is highly
>>> dubious. I added an error for this too.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> *From:* cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] *On
>>> Behalf Of *Nick Lewycky via cfe-commits
>>> *Sent:* Thursday, December 10, 2015 3:15 PM
>>> *To:* Clang Commits
>>> *Subject:* PATCH: error on code that redeclares with an __asm__ label
>>> after the first ODR use
>>>
>>>
>>>
>>> PR22830 shows a case where some code was adding an __asm__ label after
>>> the first use of a function. GCC and Clang diverged on this code, GCC
>>> emitting the name in the last __asm__ label for all uses while clang would
>>> switch in the middle of the TU as the redeclaration was parsed. The
>>> attached patch detects this case and issues an error on such a
>>> redeclaration. If this breaks real code, we can turn it down to a warning.
>>>
>>>
>>>
>>> Please review!
>>>
>>>
>>>
>>> Nick
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: PATCH: error on code that redeclares with an __asm__ label after the first ODR use
Probably my misunderstanding of how the __asm__ extension should work then.
I’ve been thinking that
void g() __asm__(“real_g”) should behave the same as
void real_g();
but thinking in terms of source-level names and assembly-level names makes
sense to me. Thanks!
From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Friday, December 11, 2015 12:57 PM
To: Gao, Yunzhong
Cc: Nick Lewycky; Clang Commits
Subject: Re: PATCH: error on code that redeclares with an __asm__ label after
the first ODR use
On Fri, Dec 11, 2015 at 12:43 PM, Gao, Yunzhong via cfe-commits
mailto:cfe-commits@lists.llvm.org>> wrote:
gcc 4.8.2 accepts the following case silently without error or warning:
void f();
void g() __asm__(“real_g”);
void f() { g(); } // gcc emits a call to real_g() here
void real_g() __asm__(“gold”);
void real_g() { } // gcc generates a body for gold() here
gcc 4.8.2 generates a warning for the following test case:
void g() __asm__(“func1”);
void g() __asm__(“func2”); // gcc generates a warning and ignores this asm label
void g() { }
Comparing to gcc behavior, I think it is better to emit error in both cases.
Why? I don't see anything wrong with the first example. We have a function
whose source-level name is "g()" and whose asm name is "real_g", and we have a
function whose source-level name is "real_g()" and whose asm name is "gold".
What's wrong with that?
Looks good to me. Thanks!
- Gao
From: Nick Lewycky [mailto:nlewy...@google.com]
Sent: Friday, December 11, 2015 12:44 AM
To: Gao, Yunzhong
Cc: Clang Commits
Subject: Re: PATCH: error on code that redeclares with an __asm__ label after
the first ODR use
On 10 December 2015 at 17:42, Gao, Yunzhong
mailto:yunzhong_...@playstation.sony.com>>
wrote:
Out of curiosity, is the following test case possible too?
void f();
void g() __asm__(“real_g”); // rename g into real_g.
void f() {
g(); // this would actually be calling real_g()
}
void real_g() __asm__("gold"); // re-declaring real_g() into gold <-- should
this be an error too?
I can't see any reason why not. Both clang and gcc will emit "real_g" here
instead of "gold", but changing the asm label in a program is highly dubious. I
added an error for this too.
Thanks!
From: cfe-commits
[mailto:cfe-commits-boun...@lists.llvm.org]
On Behalf Of Nick Lewycky via cfe-commits
Sent: Thursday, December 10, 2015 3:15 PM
To: Clang Commits
Subject: PATCH: error on code that redeclares with an __asm__ label after the
first ODR use
PR22830 shows a case where some code was adding an __asm__ label after the
first use of a function. GCC and Clang diverged on this code, GCC emitting the
name in the last __asm__ label for all uses while clang would switch in the
middle of the TU as the redeclaration was parsed. The attached patch detects
this case and issues an error on such a redeclaration. If this breaks real
code, we can turn it down to a warning.
Please review!
Nick
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255371 - Error on redeclaring with a conflicting asm label and on redeclaring with an asm label after the first ODR-use. Detects problems like the one in PR22830 where gcc and clang both compiled the
Author: nicholas
Date: Fri Dec 11 15:28:55 2015
New Revision: 255371
URL: http://llvm.org/viewvc/llvm-project?rev=255371&view=rev
Log:
Error on redeclaring with a conflicting asm label and on redeclaring with an
asm label after the first ODR-use. Detects problems like the one in PR22830
where gcc and clang both compiled the file but with different behaviour.
Added:
cfe/trunk/test/Sema/asm-label.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=255371&r1=255370&r2=255371&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Dec 11 15:28:55
2015
@@ -4259,6 +4259,9 @@ def err_tag_definition_of_typedef : Erro
def err_conflicting_types : Error<"conflicting types for %0">;
def err_different_pass_object_size_params : Error<
"conflicting pass_object_size attributes on parameters">;
+def err_late_asm_label_name : Error<
+ "cannot apply asm label to %select{variable|function}0 after its first use">;
+def err_different_asm_label : Error<"conflicting asm label">;
def err_nested_redefinition : Error<"nested redefinition of %0">;
def err_use_with_wrong_tag : Error<
"use of %0 with tag type that does not match previous declaration">;
Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=255371&r1=255370&r2=255371&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Dec 11 15:28:55 2015
@@ -2379,9 +2379,24 @@ void Sema::mergeDeclAttributes(NamedDecl
if (!Old->hasAttrs() && !New->hasAttrs())
return;
- // attributes declared post-definition are currently ignored
+ // Attributes declared post-definition are currently ignored.
checkNewAttributesAfterDef(*this, New, Old);
+ if (AsmLabelAttr *NewA = New->getAttr()) {
+if (AsmLabelAttr *OldA = Old->getAttr()) {
+ if (OldA->getLabel() != NewA->getLabel()) {
+// This redeclaration changes __asm__ label.
+Diag(New->getLocation(), diag::err_different_asm_label);
+Diag(OldA->getLocation(), diag::note_previous_declaration);
+ }
+} else if (Old->isUsed()) {
+ // This redeclaration adds an __asm__ label to a declaration that has
+ // already been ODR-used.
+ Diag(New->getLocation(), diag::err_late_asm_label_name)
+<< isa(Old) << New->getAttr()->getRange();
+}
+ }
+
if (!Old->hasAttrs())
return;
Added: cfe/trunk/test/Sema/asm-label.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/asm-label.c?rev=255371&view=auto
==
--- cfe/trunk/test/Sema/asm-label.c (added)
+++ cfe/trunk/test/Sema/asm-label.c Fri Dec 11 15:28:55 2015
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -verify %s
+
+void f();
+void f() __asm__("fish");
+void g();
+
+void f() {
+ g();
+}
+void g() __asm__("gold"); // expected-error{{cannot apply asm label to
function after its first use}}
+
+void h() __asm__("hose"); // expected-note{{previous declaration is here}}
+void h() __asm__("hair"); // expected-error{{conflicting asm label}}
+
+int x;
+int x __asm__("xenon");
+int y;
+
+int test() { return y; }
+
+int y __asm__("yacht"); // expected-error{{cannot apply asm label to variable
after its first use}}
+
+int z __asm__("zebra"); // expected-note{{previous declaration is here}}
+int z __asm__("zooms"); // expected-error{{conflicting asm label}}
+
+
+// No diagnostics on the following.
+void __real_readlink() __asm("readlink");
+void readlink() __asm("__protected_readlink");
+void readlink() { __real_readlink(); }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255372 - Unify diagnostics for type defintitions in bad contexts
Author: rnk
Date: Fri Dec 11 15:39:12 2015
New Revision: 255372
URL: http://llvm.org/viewvc/llvm-project?rev=255372&view=rev
Log:
Unify diagnostics for type defintitions in bad contexts
The message for a type definition in an "if" condition was different
from the other three for no particular reason.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/SemaCXX/condition.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=255372&r1=255371&r2=255372&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Dec 11 15:39:12
2015
@@ -1172,6 +1172,8 @@ def err_type_defined_in_param_type : Err
"%0 cannot be defined in a parameter type">;
def err_type_defined_in_alias_template : Error<
"%0 cannot be defined in a type alias template">;
+def err_type_defined_in_condition : Error<
+ "%0 cannot be defined in a condition">;
def note_pure_virtual_function : Note<
"unimplemented pure virtual method %0 in %1">;
@@ -5961,8 +5963,6 @@ def err_pseudo_dtor_destructor_non_type
def err_invalid_use_of_function_type : Error<
"a function type is not allowed here">;
def err_invalid_use_of_array_type : Error<"an array type is not allowed here">;
-def err_type_defined_in_condition : Error<
- "types may not be defined in conditions">;
def err_typecheck_bool_condition : Error<
"value of type %0 is not contextually convertible to 'bool'">;
def err_typecheck_ambiguous_condition : Error<
Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=255372&r1=255371&r2=255372&view=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Fri Dec 11 15:39:12 2015
@@ -2749,6 +2749,7 @@ static QualType GetDeclSpecTypeForDeclar
OwnedTagDecl && OwnedTagDecl->isCompleteDefinition()) {
// Check the contexts where C++ forbids the declaration of a new class
// or enumeration in a type-specifier-seq.
+unsigned DiagID = 0;
switch (D.getContext()) {
case Declarator::TrailingReturnContext:
// Class and enumeration definitions are syntactically not allowed in
@@ -2768,10 +2769,7 @@ static QualType GetDeclSpecTypeForDeclar
case Declarator::AliasDeclContext:
break;
case Declarator::AliasTemplateContext:
- SemaRef.Diag(OwnedTagDecl->getLocation(),
- diag::err_type_defined_in_alias_template)
-<< SemaRef.Context.getTypeDeclType(OwnedTagDecl);
- D.setInvalidType(true);
+ DiagID = diag::err_type_defined_in_alias_template;
break;
case Declarator::TypeNameContext:
case Declarator::ConversionIdContext:
@@ -2780,10 +2778,7 @@ static QualType GetDeclSpecTypeForDeclar
case Declarator::CXXCatchContext:
case Declarator::ObjCCatchContext:
case Declarator::TemplateTypeArgContext:
- SemaRef.Diag(OwnedTagDecl->getLocation(),
- diag::err_type_defined_in_type_specifier)
-<< SemaRef.Context.getTypeDeclType(OwnedTagDecl);
- D.setInvalidType(true);
+ DiagID = diag::err_type_defined_in_type_specifier;
break;
case Declarator::PrototypeContext:
case Declarator::LambdaExprParameterContext:
@@ -2792,20 +2787,21 @@ static QualType GetDeclSpecTypeForDeclar
case Declarator::KNRTypeListContext:
// C++ [dcl.fct]p6:
// Types shall not be defined in return or parameter types.
- SemaRef.Diag(OwnedTagDecl->getLocation(),
- diag::err_type_defined_in_param_type)
-<< SemaRef.Context.getTypeDeclType(OwnedTagDecl);
- D.setInvalidType(true);
+ DiagID = diag::err_type_defined_in_param_type;
break;
case Declarator::ConditionContext:
// C++ 6.4p2:
// The type-specifier-seq shall not contain typedef and shall not declare
// a new class or enumeration.
- SemaRef.Diag(OwnedTagDecl->getLocation(),
- diag::err_type_defined_in_condition);
- D.setInvalidType(true);
+ DiagID = diag::err_type_defined_in_condition;
break;
}
+
+if (DiagID != 0) {
+ SemaRef.Diag(OwnedTagDecl->getLocation(), DiagID)
+ << SemaRef.Context.getTypeDeclType(OwnedTagDecl);
+ D.setInvalidType(true);
+}
}
assert(!T.isNull() && "This function should not return a null type");
Modified: cfe/trunk/test/SemaCXX/condition.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/condition.cpp?rev=255372&r1=255371&r2=255372&view=diff
==
--- cfe/trunk/test/SemaCXX/condition.cpp (origin
Re: [PATCH] D15444: [clang-modernize] AddOverride: tests for handling throw() and noexcept() specifiers
adek05 updated this revision to Diff 42568.
adek05 added a comment.
Moved tests to clang-tidy test suite following Eugene.Zelenko suggestion.
http://reviews.llvm.org/D15444
Files:
test/clang-tidy/modernize-use-override.cpp
Index: test/clang-tidy/modernize-use-override.cpp
===
--- test/clang-tidy/modernize-use-override.cpp
+++ test/clang-tidy/modernize-use-override.cpp
@@ -37,6 +37,9 @@
virtual void cv() const volatile;
virtual void cv2() const volatile;
+
+ virtual void ne() noexcept(false);
+ virtual void t() throw();
};
struct SimpleCases : public Base {
@@ -104,6 +107,14 @@
virtual void o() __attribute__((unused));
// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
// CHECK-FIXES: {{^}} void o() override __attribute__((unused));
+
+ virtual void ne() noexcept(false);
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
+ // CHECK-FIXES: {{^}} void ne() noexcept(false) override;
+
+ virtual void t() throw();
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
+ // CHECK-FIXES: {{^}} void t() throw() override;
};
// CHECK-MESSAGES-NOT: warning:
Index: test/clang-tidy/modernize-use-override.cpp
===
--- test/clang-tidy/modernize-use-override.cpp
+++ test/clang-tidy/modernize-use-override.cpp
@@ -37,6 +37,9 @@
virtual void cv() const volatile;
virtual void cv2() const volatile;
+
+ virtual void ne() noexcept(false);
+ virtual void t() throw();
};
struct SimpleCases : public Base {
@@ -104,6 +107,14 @@
virtual void o() __attribute__((unused));
// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
// CHECK-FIXES: {{^}} void o() override __attribute__((unused));
+
+ virtual void ne() noexcept(false);
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
+ // CHECK-FIXES: {{^}} void ne() noexcept(false) override;
+
+ virtual void t() throw();
+ // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: prefer using
+ // CHECK-FIXES: {{^}} void t() throw() override;
};
// CHECK-MESSAGES-NOT: warning:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15444: [clang-modernize] AddOverride: tests for handling throw() and noexcept() specifiers
adek05 added a comment. I need a brave soul to review http://reviews.llvm.org/D15443 too, so if you know who else could take a look at it feel free to add people there. http://reviews.llvm.org/D15444 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255377 - Reapply "[Modules] Fix regression when an elaborated-type-specifier mentions a hidden tag"
Author: benlangmuir
Date: Fri Dec 11 16:05:13 2015
New Revision: 255377
URL: http://llvm.org/viewvc/llvm-project?rev=255377&view=rev
Log:
Reapply "[Modules] Fix regression when an elaborated-type-specifier mentions a
hidden tag"
Now not trying to use a C++ lookup mechanism in C (d'oh). Unqualified
lookup is actually fine for this case in C.
Added:
cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h
cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Modules/Inputs/module.map
Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=255377&r1=255376&r2=255377&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Dec 11 16:05:13 2015
@@ -12136,9 +12136,16 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
// In C++, we need to do a redeclaration lookup to properly
// diagnose some problems.
+// FIXME: redeclaration lookup is also used (with and without C++) to find
a
+// hidden declaration so that we don't get ambiguity errors when using a
+// type declared by an elaborated-type-specifier. In C that is not correct
+// and we should instead merge compatible types found by lookup.
if (getLangOpts().CPlusPlus) {
Previous.setRedeclarationKind(ForRedeclaration);
LookupQualifiedName(Previous, SearchDC);
+} else {
+ Previous.setRedeclarationKind(ForRedeclaration);
+ LookupName(Previous, S);
}
}
Added: cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h?rev=255377&view=auto
==
--- cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h (added)
+++ cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h Fri Dec 11 16:05:13
2015
@@ -0,0 +1,3 @@
+struct S1;
+struct S2 { int x; };
+struct S3 { int x; };
Modified: cfe/trunk/test/Modules/Inputs/module.map
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=255377&r1=255376&r2=255377&view=diff
==
--- cfe/trunk/test/Modules/Inputs/module.map (original)
+++ cfe/trunk/test/Modules/Inputs/module.map Fri Dec 11 16:05:13 2015
@@ -386,3 +386,10 @@ module TypedefTag {
header "typedef-tag-hidden.h"
}
}
+
+module ElaboratedTypeStructs {
+ module Empty {}
+ module Structs {
+header "elaborated-type-structs.h"
+ }
+}
Added: cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m?rev=255377&view=auto
==
--- cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
(added)
+++ cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m Fri
Dec 11 16:05:13 2015
@@ -0,0 +1,18 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -I
%S/Inputs %s -verify
+
+@import ElaboratedTypeStructs.Empty; // The structs are now hidden.
+struct S1 *x;
+struct S2 *y;
+// FIXME: compatible definition should not be an error.
+struct S2 { int x; }; // expected-error {{redefinition}}
+struct S3 *z;
+// Incompatible definition.
+struct S3 { float y; }; // expected-error {{redefinition}}
+// expected-note@elaborated-type-structs.h:* 2 {{previous definition is here}}
+
+@import ElaboratedTypeStructs.Structs;
+
+void useS1(struct S1 *x);
+void useS2(struct S2 *x);
+void useS2(struct S2 *x);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255382 - [clang-cl] Let /W4 map to -Wall -Wextra instead of just -Wall.
Author: nico Date: Fri Dec 11 16:31:16 2015 New Revision: 255382 URL: http://llvm.org/viewvc/llvm-project?rev=255382&view=rev Log: [clang-cl] Let /W4 map to -Wall -Wextra instead of just -Wall. There's no way to make a flag alias to two flags, so add a /WCL4 flag that maps to the All, Extra diag groups. Fixes PR25563. http://reviews.llvm.org/D15350 Modified: cfe/trunk/docs/UsersManual.rst cfe/trunk/include/clang/Basic/DiagnosticGroups.td cfe/trunk/include/clang/Driver/CLCompatOptions.td cfe/trunk/include/clang/Driver/Options.td cfe/trunk/test/Driver/cl-options.c Modified: cfe/trunk/docs/UsersManual.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=255382&r1=255381&r2=255382&view=diff == --- cfe/trunk/docs/UsersManual.rst (original) +++ cfe/trunk/docs/UsersManual.rst Fri Dec 11 16:31:16 2015 @@ -2080,7 +2080,7 @@ Execute ``clang-cl /?`` to see a list of /W1Enable -Wall /W2Enable -Wall /W3Enable -Wall - /W4Enable -Wall + /W4Enable -Wall and -Wextra /Wall Enable -Wall /WX- Do not treat warnings as errors /WXTreat warnings as errors Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=255382&r1=255381&r2=255382&view=diff == --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original) +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Fri Dec 11 16:31:16 2015 @@ -663,7 +663,10 @@ def Consumed : DiagGroup<"consumed // Note that putting warnings in -Wall will not disable them by default. If a // warning should be active _only_ when -Wall is passed in, mark it as // DefaultIgnore in addition to putting it here. -def : DiagGroup<"all", [Most, Parentheses, Switch, SwitchBool]>; +def All : DiagGroup<"all", [Most, Parentheses, Switch, SwitchBool]>; + +// Warnings that should be in clang-cl /w4. +def : DiagGroup<"CL4", [All, Extra]>; // Warnings enabled by -pedantic. This is magically filled in by TableGen. def Pedantic : DiagGroup<"pedantic">; Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=255382&r1=255381&r2=255382&view=diff == --- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original) +++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Fri Dec 11 16:31:16 2015 @@ -119,7 +119,7 @@ def _SLASH_W0 : CLFlag<"W0">, HelpText<" def _SLASH_W1 : CLFlag<"W1">, HelpText<"Enable -Wall">, Alias; def _SLASH_W2 : CLFlag<"W2">, HelpText<"Enable -Wall">, Alias; def _SLASH_W3 : CLFlag<"W3">, HelpText<"Enable -Wall">, Alias; -def _SLASH_W4 : CLFlag<"W4">, HelpText<"Enable -Wall">, Alias; +def _SLASH_W4 : CLFlag<"W4">, HelpText<"Enable -Wall and -Wextra">, Alias; def _SLASH_Wall : CLFlag<"Wall">, HelpText<"Enable -Wall">, Alias; def _SLASH_WX : CLFlag<"WX">, HelpText<"Treat warnings as errors">, Alias, AliasArgs<["error"]>; Modified: cfe/trunk/include/clang/Driver/Options.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=255382&r1=255381&r2=255382&view=diff == --- cfe/trunk/include/clang/Driver/Options.td (original) +++ cfe/trunk/include/clang/Driver/Options.td Fri Dec 11 16:31:16 2015 @@ -295,6 +295,7 @@ def Wa_COMMA : CommaJoined<["-"], "Wa,"> HelpText<"Pass the comma separated arguments in to the assembler">, MetaVarName<"">; def Wall : Flag<["-"], "Wall">, Group, Flags<[CC1Option]>; +def WCL4 : Flag<["-"], "WCL4">, Group, Flags<[CC1Option]>; def Wdeprecated : Flag<["-"], "Wdeprecated">, Group, Flags<[CC1Option]>; def Wno_deprecated : Flag<["-"], "Wno-deprecated">, Group, Flags<[CC1Option]>; def Wextra : Flag<["-"], "Wextra">, Group, Flags<[CC1Option]>; Modified: cfe/trunk/test/Driver/cl-options.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=255382&r1=255381&r2=255382&view=diff == --- cfe/trunk/test/Driver/cl-options.c (original) +++ cfe/trunk/test/Driver/cl-options.c Fri Dec 11 16:31:16 2015 @@ -173,9 +173,10 @@ // RUN: %clang_cl /W1 -### -- %s 2>&1 | FileCheck -check-prefix=W1 %s // RUN: %clang_cl /W2 -### -- %s 2>&1 | FileCheck -check-prefix=W1 %s // RUN: %clang_cl /W3 -### -- %s 2>&1 | FileCheck -check-prefix=W1 %s -// RUN: %clang_cl /W4 -### -- %s 2>&1 | FileCheck -check-prefix=W1 %s +// RUN: %clang_cl /W4 -### -- %s 2>&1 | FileCheck -check-prefix=W4 %s //
Re: [PATCH] D15350: [clang-cl] Let /W4 map to -Wall -Wextra instead of just -Wall.
thakis closed this revision. thakis added a comment. r255382, thanks! http://reviews.llvm.org/D15350 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255383 - Allow non-defining declarations of class template partial specializations to
Author: rsmith
Date: Fri Dec 11 16:39:52 2015
New Revision: 255383
URL: http://llvm.org/viewvc/llvm-project?rev=255383&view=rev
Log:
Allow non-defining declarations of class template partial specializations to
have a nested name specifier. Strictly speaking, forward declarations of class
template partial specializations are not permitted at all, but that seems like
an obvious wording defect, and if we allow them without a nested name specifier
we should also allow them with a nested name specifier.
Added:
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.elab/p1.cpp
Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Modules/Inputs/submodules-merge-defs/defs.h
Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=255383&r1=255382&r2=255383&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Dec 11 16:39:52 2015
@@ -3780,10 +3780,15 @@ Decl *Sema::ParsedFreeStandingDeclSpec(S
bool IsExplicitSpecialization =
!TemplateParams.empty() && TemplateParams.back()->size() == 0;
if (Tag && SS.isNotEmpty() && !Tag->isCompleteDefinition() &&
- !IsExplicitInstantiation && !IsExplicitSpecialization) {
+ !IsExplicitInstantiation && !IsExplicitSpecialization &&
+ !isa(Tag)) {
// Per C++ [dcl.type.elab]p1, a class declaration cannot have a
// nested-name-specifier unless it is an explicit instantiation
// or an explicit specialization.
+//
+// FIXME: We allow class template partial specializations here too, per the
+// obvious intent of DR1819.
+//
// Per C++ [dcl.enum]p1, an opaque-enum-declaration can't either.
Diag(SS.getBeginLoc(), diag::err_standalone_class_nested_name_specifier)
<< GetDiagnosticTypeSpecifierID(DS.getTypeSpecType()) << SS.getRange();
Added: cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.elab/p1.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.elab/p1.cpp?rev=255383&view=auto
==
--- cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.elab/p1.cpp (added)
+++ cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.elab/p1.cpp Fri Dec
11 16:39:52 2015
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -verify %s -std=c++11
+
+namespace N {
+ struct A;
+ template struct B {};
+}
+template struct C {};
+struct D {
+ template struct A {};
+};
+struct N::A; // expected-error {{cannot have a nested name specifier}}
+
+template struct N::B; // expected-error {{cannot have a nested
name specifier}}
+template struct N::B; // FIXME: This is technically
ill-formed, but that's not the intent.
+template<> struct N::B;
+template struct N::B;
+
+template struct C;
+template struct C; // FIXME: This is technically ill-formed,
but that's not the intent.
+template<> struct C;
+template struct C;
+
+template struct D::A; // expected-error {{cannot have a nested
name specifier}}
+template struct D::A; // FIXME: This is technically
ill-formed, but that's not the intent.
+template<> struct D::A;
+template struct D::A;
Modified: cfe/trunk/test/Modules/Inputs/submodules-merge-defs/defs.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/submodules-merge-defs/defs.h?rev=255383&r1=255382&r2=255383&view=diff
==
--- cfe/trunk/test/Modules/Inputs/submodules-merge-defs/defs.h (original)
+++ cfe/trunk/test/Modules/Inputs/submodules-merge-defs/defs.h Fri Dec 11
16:39:52 2015
@@ -131,3 +131,10 @@ namespace ClassTemplatePartialSpec {
};
template template F::F() {}
}
+
+struct MemberClassTemplate {
+ template struct A;
+};
+template struct MemberClassTemplate::A {};
+template struct MemberClassTemplate::A {};
+template<> struct MemberClassTemplate::A {};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255384 - [modules] If the semantic and lexical DC of a decl are the same, write out the
Author: rsmith
Date: Fri Dec 11 16:41:00 2015
New Revision: 255384
URL: http://llvm.org/viewvc/llvm-project?rev=255384&view=rev
Log:
[modules] If the semantic and lexical DC of a decl are the same, write out the
second one as 0 instead of writing the same bits to the module file twice.
This typically reduces PCM file size by about 1%.
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=255384&r1=255383&r2=255384&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Fri Dec 11 16:41:00 2015
@@ -476,6 +476,8 @@ void ASTDeclReader::VisitDecl(Decl *D) {
// placeholder.
GlobalDeclID SemaDCIDForTemplateParmDecl = ReadDeclID(Record, Idx);
GlobalDeclID LexicalDCIDForTemplateParmDecl = ReadDeclID(Record, Idx);
+if (!LexicalDCIDForTemplateParmDecl)
+ LexicalDCIDForTemplateParmDecl = SemaDCIDForTemplateParmDecl;
Reader.addPendingDeclContextInfo(D,
SemaDCIDForTemplateParmDecl,
LexicalDCIDForTemplateParmDecl);
@@ -483,6 +485,8 @@ void ASTDeclReader::VisitDecl(Decl *D) {
} else {
DeclContext *SemaDC = ReadDeclAs(Record, Idx);
DeclContext *LexicalDC = ReadDeclAs(Record, Idx);
+if (!LexicalDC)
+ LexicalDC = SemaDC;
DeclContext *MergedSemaDC = Reader.MergedDeclContexts.lookup(SemaDC);
// Avoid calling setLexicalDeclContext() directly because it uses
// Decl::getASTContext() internally which is unsafe during derialization.
Modified: cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriterDecl.cpp?rev=255384&r1=255383&r2=255384&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriterDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriterDecl.cpp Fri Dec 11 16:41:00 2015
@@ -276,7 +276,10 @@ void ASTDeclWriter::Visit(Decl *D) {
void ASTDeclWriter::VisitDecl(Decl *D) {
Writer.AddDeclRef(cast_or_null(D->getDeclContext()), Record);
- Writer.AddDeclRef(cast_or_null(D->getLexicalDeclContext()), Record);
+ if (D->getDeclContext() != D->getLexicalDeclContext())
+Writer.AddDeclRef(cast_or_null(D->getLexicalDeclContext()), Record);
+ else
+Record.push_back(0);
Record.push_back(D->isInvalidDecl());
Record.push_back(D->hasAttrs());
if (D->hasAttrs())
@@ -340,7 +343,8 @@ void ASTDeclWriter::VisitTypedefNameDecl
void ASTDeclWriter::VisitTypedefDecl(TypedefDecl *D) {
VisitTypedefNameDecl(D);
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
D->getFirstDecl() == D->getMostRecentDecl() &&
!D->isInvalidDecl() &&
@@ -402,7 +406,8 @@ void ASTDeclWriter::VisitEnumDecl(EnumDe
Writer.AddDeclRef(nullptr, Record);
}
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
!D->isUsed(false) &&
!D->hasExtInfo() &&
@@ -430,7 +435,8 @@ void ASTDeclWriter::VisitRecordDecl(Reco
Record.push_back(D->hasObjectMember());
Record.push_back(D->hasVolatileMember());
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
!D->isUsed(false) &&
!D->hasExtInfo() &&
@@ -688,7 +694,8 @@ void ASTDeclWriter::VisitObjCIvarDecl(Ob
Record.push_back(D->getAccessControl());
Record.push_back(D->getSynthesize());
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
!D->isUsed(false) &&
!D->isInvalidDecl() &&
@@ -820,7 +827,8 @@ void ASTDeclWriter::VisitFieldDecl(Field
if (!D->getDeclName())
Writer.AddDeclRef(Context.getInstantiatedFromUnnamedFieldDecl(D), Record);
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
!D->isUsed(false) &&
!D->isInvalidDecl() &&
@@ -894,7 +902,8 @@ void ASTDeclWriter::VisitVarDecl(VarDecl
Record.push_back(VarNotTemplate);
}
- if (!D->hasAttrs() &&
+ if (D->getDeclContext() == D->getLexicalDeclContext() &&
+ !D->hasAttrs() &&
!D->isImplicit() &&
!D->isUsed(false) &&
!D->isInvalidDecl() &&
@@ -942,7 +951,8 @@ void ASTDeclWriter::VisitParmVarDecl(Par
// If the assumptions about the DECL_PARM_VAR abbrev are true, use it. Here
// we dynamically check for the properties that we optimize for, but don't
// know are true of all PAR
Re: [PATCH] D9600: Add scan-build python implementation
rizsotto.mailinglist marked 6 inline comments as done. Comment at: tools/scan-build-py/README.md:86 @@ +85,3 @@ +The 2. mode is available only on FreeBSD, Linux and OSX. Where library preload +is available from the dynamic loader. On OSX System Integrity Protection security +feature enabled prevents library preload, so this method will not work in such zaks.anna wrote: > This is very unfortunate! > > We should call out that library interposition is "not supported on OS X > (unless System Integrity Protection feature is turned off)" and return an > error if people are trying to use it (and System Integrity Protection feature > is turned on). comment changed. please hint me with some code how can the script detect SIP status. (or postpone the check implementation after the patch is accepted) Comment at: tools/scan-build-py/bin/analyze-c++:3 @@ +2,3 @@ +# -*- coding: utf-8 -*- +# The LLVM Compiler Infrastructure +# zaks.anna wrote: > I searched the code and did not see it being called. By looking back at the > previous revision I see that that libscanbuild.analyze.main used to call > 'analyze-cxx' not 'analyze-c++'. Looks like you've also fixed the same bug > with 'intercept-c++'. > > Is this something that could/would be caught by the tests? test harness contains only C files, that was the reason this could have gone unnoticed. added specific check for it. http://reviews.llvm.org/D9600 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D10370: clang-format: Implement AlwaysBreakAfterDeclarationReturnType.
zturner added a subscriber: zturner. zturner added a comment. What needs to happen for this to go in? If I understand correctly, it is either: 1. Add a new option `TreatDeclarationsLikeDefinitions` 2. Merge this option into `AlwaysBreakAfterDefinitionReturnType` and make it an enum with 5 values. In theory I think option 2 is the best, but are you concerned about backwards compatibility? It breaks anyone already using `AlwaysBreakAfterDefinitionReturnType` and forces them to update their style files. Is this an important consideration? I don't really like option 1 because then we are tied to treating declarations like definitions for all current and future options including ones we haven't imagined yet. That might not be the best choice. Let me know what to do, and I will finish out this patch if strager won't. http://reviews.llvm.org/D10370 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
eraman marked an inline comment as done. eraman added a comment. I've added a test case to check for the presence of MaxFunctionCount module flag. I'll check in this patch soon. Repository: rL LLVM http://reviews.llvm.org/D15163 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D15470: Preserve source location in namespaced base ctor initializers
shahms created this revision.
shahms added a subscriber: cfe-commits.
Resolved a FIXME to preserve source location in qualified base initializers.
This patch preserves location information for constructs such as:
namespace ns1 {
struct Base {};
struct Derived : Base {
Derived() : ns1::Base() {}
};
}
previously, the reference to ns1 would overlap the reference to Base. With
this patch it properly spans only ns1.
http://reviews.llvm.org/D15470
Files:
lib/Sema/SemaDeclCXX.cpp
test/Index/namespaced-base-ctor-init.cpp
Index: test/Index/namespaced-base-ctor-init.cpp
===
--- /dev/null
+++ test/Index/namespaced-base-ctor-init.cpp
@@ -0,0 +1,9 @@
+namespace ns1 {
+struct Base {};
+struct Derived : Base {
+ Derived() : ns1::Base() {}
+};
+}
+
+// RUN: c-index-test -test-load-source all %s | FileCheck %s
+// CHECK: namespaced-base-ctor-init.cpp:4:15: NamespaceRef=ns1:1:11
Extent=[4:15 - 4:18]
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -2980,10 +2980,14 @@
if (BaseType.isNull()) {
BaseType = Context.getTypeDeclType(TyD);
MarkAnyDeclReferenced(TyD->getLocation(), TyD, /*OdrUse=*/false);
- if (SS.isSet())
-// FIXME: preserve source range information
+ if (SS.isSet()) {
BaseType = Context.getElaboratedType(ETK_None, SS.getScopeRep(),
BaseType);
+TInfo = Context.CreateTypeSourceInfo(BaseType);
+ElaboratedTypeLoc TL = TInfo->getTypeLoc().castAs();
+TL.setElaboratedKeywordLoc(IdLoc);
+TL.setQualifierLoc(SS.getWithLocInContext(Context));
+ }
}
}
Index: test/Index/namespaced-base-ctor-init.cpp
===
--- /dev/null
+++ test/Index/namespaced-base-ctor-init.cpp
@@ -0,0 +1,9 @@
+namespace ns1 {
+struct Base {};
+struct Derived : Base {
+ Derived() : ns1::Base() {}
+};
+}
+
+// RUN: c-index-test -test-load-source all %s | FileCheck %s
+// CHECK: namespaced-base-ctor-init.cpp:4:15: NamespaceRef=ns1:1:11 Extent=[4:15 - 4:18]
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -2980,10 +2980,14 @@
if (BaseType.isNull()) {
BaseType = Context.getTypeDeclType(TyD);
MarkAnyDeclReferenced(TyD->getLocation(), TyD, /*OdrUse=*/false);
- if (SS.isSet())
-// FIXME: preserve source range information
+ if (SS.isSet()) {
BaseType = Context.getElaboratedType(ETK_None, SS.getScopeRep(),
BaseType);
+TInfo = Context.CreateTypeSourceInfo(BaseType);
+ElaboratedTypeLoc TL = TInfo->getTypeLoc().castAs();
+TL.setElaboratedKeywordLoc(IdLoc);
+TL.setQualifierLoc(SS.getWithLocInContext(Context));
+ }
}
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15470: Preserve source location in namespaced base ctor initializers
rsmith added a subscriber: rsmith. Comment at: lib/Sema/SemaDeclCXX.cpp:2987 @@ +2986,3 @@ +TInfo = Context.CreateTypeSourceInfo(BaseType); +ElaboratedTypeLoc TL = TInfo->getTypeLoc().castAs(); +TL.setElaboratedKeywordLoc(IdLoc); You also need to initialize the `TypeLoc` for the contained `TypeDeclType` (`TL.getNamedTypeLoc()`). Comment at: lib/Sema/SemaDeclCXX.cpp:2988 @@ +2987,3 @@ +ElaboratedTypeLoc TL = TInfo->getTypeLoc().castAs(); +TL.setElaboratedKeywordLoc(IdLoc); +TL.setQualifierLoc(SS.getWithLocInContext(Context)); This should be initialized to `SourceLocation()`, since there is no elaborated type keyword (`struct`/`union`/`class`/`enum`) in this case. http://reviews.llvm.org/D15470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D9600: Add scan-build python implementation
rizsotto.mailinglist added inline comments. Comment at: tools/scan-build-py/libear/ear.c:142 @@ +141,3 @@ +#endif +if (!initialized) +initialized = bear_capture_env_t(&initial_env); to run the full test set > PATH=$(pwd)/bin:$PATH python -m unittest discover to run that specific test > PATH=$(pwd)/bin:$PATH python -m unittest -v > tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env to more about run tests https://docs.python.org/2/library/unittest.html Comment at: tools/scan-build-py/libear/ear.c:142 @@ +141,3 @@ +#endif +if (!initialized) +initialized = bear_capture_env_t(&initial_env); rizsotto.mailinglist wrote: > to run the full test set > > > PATH=$(pwd)/bin:$PATH python -m unittest discover > > to run that specific test > > > PATH=$(pwd)/bin:$PATH python -m unittest -v > > tests.functional.cases.test_create_cdb.CompilationDatabaseTest.test_successful_build_on_empty_env > > to more about run tests > > https://docs.python.org/2/library/unittest.html my understanding on the `_NSGetEnviron` is, that it shall be used when the library is during the load process. later when the build process calls `execv` the load process is over, and `environ` variable is available. an earlier version of this code had a `get_environ` method, which were either return the `environ` variable or called the `_NSGetEnviron`. then i made this change and the tests were still passing, so i don't see where your issue is coming from. please tell me what kind of test you run against it to find it as problem. would like to add it to the test suite. http://reviews.llvm.org/D9600 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255393 - docs: Document -fno-sanitize-trap= and -fsanitize-recover= flags for CFI.
Author: pcc Date: Fri Dec 11 17:54:18 2015 New Revision: 255393 URL: http://llvm.org/viewvc/llvm-project?rev=255393&view=rev Log: docs: Document -fno-sanitize-trap= and -fsanitize-recover= flags for CFI. Modified: cfe/trunk/docs/ControlFlowIntegrity.rst Modified: cfe/trunk/docs/ControlFlowIntegrity.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrity.rst?rev=255393&r1=255392&r2=255393&view=diff == --- cfe/trunk/docs/ControlFlowIntegrity.rst (original) +++ cfe/trunk/docs/ControlFlowIntegrity.rst Fri Dec 11 17:54:18 2015 @@ -61,6 +61,24 @@ checking. Remember that you have to provide ``-flto`` if at least one CFI scheme is enabled. +Trapping and Diagnostics + + +By default, CFI will abort the program immediately upon detecting a control +flow integrity violation. You can use the :ref:`-fno-sanitize-trap= +` flag to cause CFI to print a diagnostic +similar to the one below before the program aborts. + +.. code-block:: console + +bad-cast.cpp:109:7: runtime error: control flow integrity check for type 'B' failed during base-to-derived cast (vtable address 0x00425a50) +0x00425a50: note: vtable is of type 'A' + 00 00 00 00 f0 f1 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 5a 42 00 + ^ + +If diagnostics are enabled, you can also configure CFI to continue program +execution instead of aborting by using the :ref:`-fsanitize-recover= +` flag. Forward-Edge CFI for Virtual Calls == ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255397 - Attach maximum function count to Module when using PGO mode
Author: eraman
Date: Fri Dec 11 18:31:02 2015
New Revision: 255397
URL: http://llvm.org/viewvc/llvm-project?rev=255397&view=rev
Log:
Attach maximum function count to Module when using PGO mode
This sets the maximum entry count among all functions in the program to the
module using module flags. This allows the optimizer to use this information.
Differential Revision: http://reviews.llvm.org/D15163
Added:
cfe/trunk/test/CodeGen/pgo-max-function-count.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=255397&r1=255396&r2=255397&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri Dec 11 18:31:02 2015
@@ -376,6 +376,9 @@ void CodeGenModule::Release() {
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
+ // In PGO mode, attach maximum function count to the module.
+ if (PGOReader)
+getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
Added: cfe/trunk/test/CodeGen/pgo-max-function-count.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/pgo-max-function-count.c?rev=255397&view=auto
==
--- cfe/trunk/test/CodeGen/pgo-max-function-count.c (added)
+++ cfe/trunk/test/CodeGen/pgo-max-function-count.c Fri Dec 11 18:31:02 2015
@@ -0,0 +1,9 @@
+// RUN: %clang -fprofile-generate -o %t -O2 %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
+// Check
+int main() {
+ return 0;
+}
+// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL255397: Attach maximum function count to Module when using
PGO mode (authored by eraman).
Changed prior to commit:
http://reviews.llvm.org/D15163?vs=42549&id=42604#toc
Repository:
rL LLVM
http://reviews.llvm.org/D15163
Files:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGen/pgo-max-function-count.c
Index: cfe/trunk/test/CodeGen/pgo-max-function-count.c
===
--- cfe/trunk/test/CodeGen/pgo-max-function-count.c
+++ cfe/trunk/test/CodeGen/pgo-max-function-count.c
@@ -0,0 +1,9 @@
+// RUN: %clang -fprofile-generate -o %t -O2 %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
+// Check
+int main() {
+ return 0;
+}
+// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -376,6 +376,9 @@
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
+ // In PGO mode, attach maximum function count to the module.
+ if (PGOReader)
+getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
Index: cfe/trunk/test/CodeGen/pgo-max-function-count.c
===
--- cfe/trunk/test/CodeGen/pgo-max-function-count.c
+++ cfe/trunk/test/CodeGen/pgo-max-function-count.c
@@ -0,0 +1,9 @@
+// RUN: %clang -fprofile-generate -o %t -O2 %s
+// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
+// RUN: llvm-profdata merge -o %t.profdata %t.profraw
+// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
+// Check
+int main() {
+ return 0;
+}
+// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -376,6 +376,9 @@
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
+ // In PGO mode, attach maximum function count to the module.
+ if (PGOReader)
+getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15367: Cross-DSO control flow integrity (Clang part)
eugenis updated this revision to Diff 42607.
eugenis marked an inline comment as done.
Repository:
rL LLVM
http://reviews.llvm.org/D15367
Files:
include/clang/Driver/Options.td
include/clang/Driver/SanitizerArgs.h
include/clang/Frontend/CodeGenOptions.def
lib/CodeGen/CGClass.cpp
lib/CodeGen/CGExpr.cpp
lib/CodeGen/CGVTables.cpp
lib/CodeGen/CodeGenFunction.h
lib/CodeGen/CodeGenModule.cpp
lib/CodeGen/CodeGenModule.h
lib/CodeGen/MicrosoftCXXABI.cpp
lib/Driver/SanitizerArgs.cpp
lib/Driver/Tools.cpp
lib/Frontend/CompilerInvocation.cpp
test/CodeGen/cfi-icall-cross-dso.c
test/CodeGenCXX/cfi-cross-dso.cpp
test/Driver/fsanitize.c
test/Driver/sanitizer-ld.c
Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -291,6 +291,46 @@
// CHECK-LSAN-ASAN-LINUX: libclang_rt.asan-x86_64
// CHECK-LSAN-ASAN-LINUX-NOT: libclang_rt.lsan
+// CFI by itself does not link runtime libraries.
+// RUN: %clang -fsanitize=cfi %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: | FileCheck --check-prefix=CHECK-CFI-LINUX %s
+// CHECK-CFI-LINUX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-LINUX-NOT: libclang_rt.
+
+// CFI with diagnostics links the UBSan runtime.
+// RUN: %clang -fsanitize=cfi -fno-sanitize-trap=cfi -fsanitize-recover=cfi \
+// RUN: %s -### -o %t.o 2>&1\
+// RUN: -target x86_64-unknown-linux \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: | FileCheck --check-prefix=CHECK-CFI-DIAG-LINUX %s
+// CHECK-CFI-DIAG-LINUX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-LINUX-NOT: libclang_rt.
+// CHECK-CFI-DIAG-LINUX: libclang_rt.ubsan
+// CHECK-CFI-CROSS-DSO-LINUX-NOT: libclang_rt.
+
+// Cross-DSO CFI links the CFI runtime.
+// RUN: %clang -fsanitize=cfi -fsanitize-cfi-cross-dso %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-LINUX %s
+// CHECK-CFI-CROSS-DSO-LINUX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-LINUX-NOT: libclang_rt.
+// CHECK-CFI-CROSS-DSO-LINUX: libclang_rt.cfi
+// CHECK-CFI-CROSS-DSO-LINUX-NOT: libclang_rt.
+
+// Cross-DSO CFI with diagnostics links just the CFI runtime.
+// RUN: %clang -fsanitize=cfi -fsanitize-cfi-cross-dso %s -### -o %t.o 2>&1 \
+// RUN: -fno-sanitize-trap=cfi -fsanitize-recover=cfi \
+// RUN: -target x86_64-unknown-linux \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: | FileCheck --check-prefix=CHECK-CFI-CROSS-DSO-DIAG-LINUX %s
+// CHECK-CFI-CROSS-DSO-DIAG-LINUX: "{{.*}}ld{{(.exe)?}}"
+// CHECK-CFI-CROSS-DSO-DIAG-LINUX-NOT: libclang_rt.
+// CHECK-CFI-CROSS-DSO-DIAG-LINUX: libclang_rt.cfi
+// CHECK-CFI-CROSS-DSO-DIAG-LINUX-NOT: libclang_rt.
+
// RUN: %clangxx -fsanitize=address %s -### -o %t.o 2>&1 \
// RUN: -mmacosx-version-min=10.6 \
// RUN: -target x86_64-apple-darwin13.4.0 \
Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -263,6 +263,15 @@
// CHECK-CFI-NOTRAP-WIN: -emit-llvm-bc
// CHECK-CFI-NOTRAP-WIN-NOT: -fsanitize-trap=cfi
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fsanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-CROSS-DSO
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NO-CROSS-DSO
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fsanitize-cfi-cross-dso -fno-sanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-NO-CROSS-DSO
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=cfi -fno-sanitize-cfi-cross-dso -fsanitize-cfi-cross-dso -flto -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CFI-CROSS-DSO
+// CHECK-CFI-CROSS-DSO: -emit-llvm-bc
+// CHECK-CFI-CROSS-DSO: -fsanitize-cfi-cross-dso
+// CHECK-CFI-NO-CROSS-DSO: -emit-llvm-bc
+// CHECK-CFI-NO-CROSS-DSO-NOT: -fsanitize-cfi-cross-dso
+
// RUN: %clang_cl -fsanitize=address -c -MDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -MTd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
// RUN: %clang_cl -fsanitize=address -c -LDd -### -- %s 2>&1 | FileCheck %s -check-prefix=CHECK-ASAN-DEBUGRTL
Index: test/CodeGenCXX/cfi-cross-dso.cpp
===
--- /dev/null
+++ test/CodeGenCXX/cfi-cross-dso.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fsanitize=cfi-vcall -fsanitize-cfi-cross-dso -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=ITANIUM %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fsanitize=cfi-vcall -fsanitize-cfi-cross-dso -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --ch
Re: [PATCH] D15367: Cross-DSO control flow integrity (Clang part)
eugenis added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:2558 @@ +2557,3 @@ + false)); + llvm::MDString *MDS = dyn_cast(MD); + llvm::Constant *TypeId = pcc wrote: > What happens if `MD` is not an `MDString`? assert + check on the caller side Repository: rL LLVM http://reviews.llvm.org/D15367 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255416 - Revert r254647.
Author: eraman
Date: Fri Dec 11 19:11:09 2015
New Revision: 255416
URL: http://llvm.org/viewvc/llvm-project?rev=255416&view=rev
Log:
Revert r254647.
Reason: The testcase fails in many architectures.
Differential Revision: http://reviews.llvm.org/D15163
Removed:
cfe/trunk/test/CodeGen/pgo-max-function-count.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=255416&r1=255415&r2=255416&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Fri Dec 11 19:11:09 2015
@@ -376,9 +376,6 @@ void CodeGenModule::Release() {
}
if (PGOReader && PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
- // In PGO mode, attach maximum function count to the module.
- if (PGOReader)
-getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
EmitCtorList(GlobalCtors, "llvm.global_ctors");
EmitCtorList(GlobalDtors, "llvm.global_dtors");
EmitGlobalAnnotations();
Removed: cfe/trunk/test/CodeGen/pgo-max-function-count.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/pgo-max-function-count.c?rev=255415&view=auto
==
--- cfe/trunk/test/CodeGen/pgo-max-function-count.c (original)
+++ cfe/trunk/test/CodeGen/pgo-max-function-count.c (removed)
@@ -1,9 +0,0 @@
-// RUN: %clang -fprofile-generate -o %t -O2 %s
-// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
-// RUN: llvm-profdata merge -o %t.profdata %t.profraw
-// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
-// Check
-int main() {
- return 0;
-}
-// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r255366 - [PGO] Stop using invalid char in instr variable names.
On Fri, Dec 11, 2015 at 11:53 AM, Xinliang David Li via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: davidxl
> Date: Fri Dec 11 13:53:35 2015
> New Revision: 255366
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255366&view=rev
> Log:
> [PGO] Stop using invalid char in instr variable names.
>
> (This is part-2 of the patch -- fixing test cases)
>
> Before the patch, -fprofile-instr-generate compile will fail
> if no integrated-as is specified when the file contains
> any static functions (the -S output is also invalid).
>
> This patch fixed the issue. With the change, the index format
> version will be bumped up by 1. Backward compatibility is
> preserved with this change.
>
> Differential Revision: http://reviews.llvm.org/D15243
FYI, this was a bit premature. There had been no review of the testing that
v3 format continued to be accepted (which you snuck in with clang-side
patches that had not been discussed; also, testing an llvm feature inside
clang is generally not allowed (i.e. a piece of code in LLVM that is only
exercised by clang)).
In general, for compatibility-related issues extra careful review is
required. I recommend you reopen the review and continue the discussion,
including the clang-side patches and the strange testing arrangement for
testing that v3 continues to be accepted and correctly interpreted.
-- Sean Silva
>
>
>
>
> Modified:
> cfe/trunk/test/CoverageMapping/unused_names.c
> cfe/trunk/test/Profile/Inputs/c-captured.proftext
> cfe/trunk/test/Profile/Inputs/c-general.proftext
> cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
> cfe/trunk/test/Profile/Inputs/objc-general.proftext
> cfe/trunk/test/Profile/c-captured.c
> cfe/trunk/test/Profile/c-general.c
> cfe/trunk/test/Profile/c-linkage.c
> cfe/trunk/test/Profile/cxx-lambda.cpp
> cfe/trunk/test/Profile/objc-general.m
>
> Modified: cfe/trunk/test/CoverageMapping/unused_names.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CoverageMapping/unused_names.c?rev=255366&r1=255365&r2=255366&view=diff
>
> ==
> --- cfe/trunk/test/CoverageMapping/unused_names.c (original)
> +++ cfe/trunk/test/CoverageMapping/unused_names.c Fri Dec 11 13:53:35 2015
> @@ -6,7 +6,7 @@
>
> // CHECK-DAG: @__llvm_profile_name_bar = {{.*}} [3 x i8] c"bar", section
> "{{.*}}__llvm_prf_names"
> // CHECK-DAG: @__llvm_profile_name_baz = {{.*}} [3 x i8] c"baz", section
> "{{.*}}__llvm_prf_names"
> -// CHECK-DAG: @"__llvm_profile_name_unused_names.c:qux" = {{.*}} [18 x
> i8] c"unused_names.c:qux", section "{{.*}}__llvm_prf_names"
> +// CHECK-DAG: @__llvm_profile_name_unused_names.c__qux = {{.*}} [19 x i8]
> c"unused_names.c__qux", section "{{.*}}__llvm_prf_names"
>
> // SYSHEADER-NOT: @__llvm_profile_name_foo =
>
>
> Modified: cfe/trunk/test/Profile/Inputs/c-captured.proftext
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-captured.proftext?rev=255366&r1=255365&r2=255366&view=diff
>
> ==
> --- cfe/trunk/test/Profile/Inputs/c-captured.proftext (original)
> +++ cfe/trunk/test/Profile/Inputs/c-captured.proftext Fri Dec 11 13:53:35
> 2015
> @@ -1,10 +1,10 @@
> -c-captured.c:__captured_stmt
> +c-captured.ccaptured_stmt
> 10
> 2
> 1
> 1
>
> -c-captured.c:__captured_stmt.1
> +c-captured.ccaptured_stmt.1
> 266
> 3
> 1
>
> Modified: cfe/trunk/test/Profile/Inputs/c-general.proftext
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/c-general.proftext?rev=255366&r1=255365&r2=255366&view=diff
>
> ==
> --- cfe/trunk/test/Profile/Inputs/c-general.proftext (original)
> +++ cfe/trunk/test/Profile/Inputs/c-general.proftext Fri Dec 11 13:53:35
> 2015
> @@ -149,7 +149,7 @@ main
> 1
> 1
>
> -c-general.c:static_func
> +c-general.c__static_func
> 4
> 2
> 1
>
> Modified: cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext?rev=255366&r1=255365&r2=255366&view=diff
>
> ==
> --- cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext (original)
> +++ cfe/trunk/test/Profile/Inputs/cxx-lambda.proftext Fri Dec 11 13:53:35
> 2015
> @@ -1,4 +1,4 @@
> -cxx-lambda.cpp:_ZZ7lambdasvENK3$_0clEi
> +cxx-lambda.cpp___ZZ7lambdasvENK3$_0clEi
> 654
> 3
> 10
>
> Modified: cfe/trunk/test/Profile/Inputs/objc-general.proftext
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/Inputs/objc-general.proftext?rev=255366&r1=255365&r2=255366&view=diff
>
> ==
> --- cfe/trunk/test/Profile/Inputs/objc-general.proftext (original)
> +++ cfe/trunk/test/Profile/Inputs/objc-general.proftext Fri Dec 11
> 13
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
eraman added a comment. I have reverted the commit in r255416 because the test failed in many architectures. In many cases the linker is not able to find libclang_rt.profile-$ARCH.a file. There are also other errors. Here is one: 0. Program arguments: /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang -cc1 -triple hexagon-unknown--elf -emit-obj -disable-free -main-file-name pgo-max-function-count.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu hexagonv4 -mqdsp6-compat -Wreturn-type -fshort-enums -mllvm -machine-sink-split=0 -target-linker-version 2.25 -dwarf-column-info -fprofile-instr-generate -resource-dir /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.8.0 -internal-externc-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/lib/gcc/hexagon/0.0.0/include -internal-externc-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/lib/gcc/hexagon/0.0.0/include-fixed -internal-externc-isystem /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/hexagon/include -O2 -fdebug-compilation-dir /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/CodeGen -ferror-limit 19 -fmessage-length 0 -fshort-enums -fno-signed-char -fno-use-cxa-atexit -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /tmp/pgo-max-function-count-816195.o -x c /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.src/tools/clang/test/CodeGen/pgo-max-function-count.c Target: hexagon-unknown--elf Seems like the command line is messed up (I assume there should be a space between hexagon-unknown and --elf). Any suggestions on how to fix this test case? AFAICT, there are no PGO related tests in clang and I based this on PGO tests in compiler-rt/ Repository: rL LLVM http://reviews.llvm.org/D15163 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r255377 - Reapply "[Modules] Fix regression when an elaborated-type-specifier mentions a hidden tag"
On Fri, Dec 11, 2015 at 2:05 PM, Ben Langmuir via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: benlangmuir
> Date: Fri Dec 11 16:05:13 2015
> New Revision: 255377
>
> URL: http://llvm.org/viewvc/llvm-project?rev=255377&view=rev
> Log:
> Reapply "[Modules] Fix regression when an elaborated-type-specifier
> mentions a hidden tag"
>
> Now not trying to use a C++ lookup mechanism in C (d'oh). Unqualified
> lookup is actually fine for this case in C.
>
> Added:
> cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h
> cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
> Modified:
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/test/Modules/Inputs/module.map
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=255377&r1=255376&r2=255377&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Dec 11 16:05:13 2015
> @@ -12136,9 +12136,16 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>
> // In C++, we need to do a redeclaration lookup to properly
> // diagnose some problems.
> +// FIXME: redeclaration lookup is also used (with and without C++) to
> find a
> +// hidden declaration so that we don't get ambiguity errors when
> using a
> +// type declared by an elaborated-type-specifier. In C that is not
> correct
> +// and we should instead merge compatible types found by lookup.
> if (getLangOpts().CPlusPlus) {
>Previous.setRedeclarationKind(ForRedeclaration);
>LookupQualifiedName(Previous, SearchDC);
> +} else {
> + Previous.setRedeclarationKind(ForRedeclaration);
> + LookupName(Previous, S);
>
Can we move the comment inside the "else" to make it clear that the `else`
code is what the FIXME is relevant to?
-- Sean Silva
> }
>}
>
>
> Added: cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h?rev=255377&view=auto
>
> ==
> --- cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h (added)
> +++ cfe/trunk/test/Modules/Inputs/elaborated-type-structs.h Fri Dec 11
> 16:05:13 2015
> @@ -0,0 +1,3 @@
> +struct S1;
> +struct S2 { int x; };
> +struct S3 { int x; };
>
> Modified: cfe/trunk/test/Modules/Inputs/module.map
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=255377&r1=255376&r2=255377&view=diff
>
> ==
> --- cfe/trunk/test/Modules/Inputs/module.map (original)
> +++ cfe/trunk/test/Modules/Inputs/module.map Fri Dec 11 16:05:13 2015
> @@ -386,3 +386,10 @@ module TypedefTag {
> header "typedef-tag-hidden.h"
>}
> }
> +
> +module ElaboratedTypeStructs {
> + module Empty {}
> + module Structs {
> +header "elaborated-type-structs.h"
> + }
> +}
>
> Added:
> cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m?rev=255377&view=auto
>
> ==
> --- cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
> (added)
> +++ cfe/trunk/test/Modules/elaborated-type-specifier-from-hidden-module.m
> Fri Dec 11 16:05:13 2015
> @@ -0,0 +1,18 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps
> -fmodules-cache-path=%t -I %S/Inputs %s -verify
> +
> +@import ElaboratedTypeStructs.Empty; // The structs are now hidden.
> +struct S1 *x;
> +struct S2 *y;
> +// FIXME: compatible definition should not be an error.
> +struct S2 { int x; }; // expected-error {{redefinition}}
> +struct S3 *z;
> +// Incompatible definition.
> +struct S3 { float y; }; // expected-error {{redefinition}}
> +// expected-note@elaborated-type-structs.h:* 2 {{previous definition is
> here}}
> +
> +@import ElaboratedTypeStructs.Structs;
> +
> +void useS1(struct S1 *x);
> +void useS2(struct S2 *x);
> +void useS2(struct S2 *x);
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D12299: [libcxx] Fix for ALL undefined behavior in .
EricWF retitled this revision from "[libcxx] ABI-Breaking Fix for ALL undefined
behavior in ." to "[libcxx] Fix for ALL undefined behavior in .".
EricWF updated the summary for this revision.
EricWF updated this revision to Diff 42557.
EricWF added a comment.
Ping.
Originally I considered this change to be ABI breaking because we changed the
type of the link pointers from `__list_node_pointer` to
`__list_node_base_pointer`. However I now believe this change is ABI
compatible in 99% of cases. I assert that this change is safe whenever
`__list_node_pointer` and `__list_node_base_pointer` are builtin pointer types.
Unfortunately std::list supports fancy "class-like" pointers and we cannot
guarantee that these fancy pointers will be ABI compatible in the same why
builtin pointers are. Fancy pointers are free to have entirely different
representations depending on the pointee type. For this reason I don't think we
can fix std::list with fancy pointers until the next ABI version.
This patch fixes std::list for builtin pointer types in the current ABI version
and fixes std::list for all fancy pointer types in the next ABI version. The
patch was designed to minimize the amount of code needed to support both ABI
configurations. Currently only ~5 lines of code differ.
The patch works by introducing a `__link_pointer` typedef that defines the type
of pointers used to make the link list. `__link_pointer` is either
`__list_node_pointer` or `__list_node_base_pointer' depending on the ABI
version. Instead of working with `__node_pointer` or `__node_base_pointer`
types in std::list we now only work with `__link_pointer` types except when we
absolutely need to access the underlying node. When we need to convert between
`__node_pointer`, `__node_base_pointer` or `__link_pointer` we use the
conversion methods supplied defined in `__list_node_base`.
One problem with `__link_pointer` is that its easy to accidentally depend on
it being defined as `__node_pointer` or `__node_base_pointer`. For example it
would be incorrect to access `__list_node::__value_` through a pointer declared
as `__link_pointer` even though it will work when `__link_pointer` is an alias
for `__node_pointer`. This code will compile
http://reviews.llvm.org/D12299
Files:
include/list
Index: include/list
===
--- include/list
+++ include/list
@@ -191,21 +191,32 @@
template
struct __list_node_base
{
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-pointer;
typedef typename __rebind_pointer<_VoidPtr, __list_node_base>::type
-__base_pointer;
+__node_base_pointer;
+typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
+__node_pointer;
+__node_base_pointer __prev_;
+__node_base_pointer __next_;
-pointer __prev_;
-pointer __next_;
+#if _LIBCPP_ABI_VERSION == 1 && !defined(_LIBCPP_ABI_UNSTABLE)
+static_assert(
+sizeof(__node_base_pointer) == sizeof(__node_pointer) &&
+__alignof__(__node_base_pointer) == __alignof__(__node_pointer),
+"The ABI of std::list was broken by http://reviews.llvm.org/D12299. "
+"Please report this issue at llvm.org/bugs"
+);
+#endif
_LIBCPP_INLINE_VISIBILITY
-__list_node_base() : __prev_(__self()), __next_(__self()) {}
+__list_node_base() : __prev_(__as_base()), __next_(__as_base()) {}
_LIBCPP_INLINE_VISIBILITY
-pointer __self()
-{
-return static_cast(pointer_traits<__base_pointer>::pointer_to(*this));
+__node_base_pointer __as_base() {
+return pointer_traits<__node_base_pointer>::pointer_to(*this);
+}
+_LIBCPP_INLINE_VISIBILITY
+__node_pointer __as_node() {
+return static_cast<__node_pointer>(__as_base());
}
};
@@ -223,21 +234,21 @@
template
class _LIBCPP_TYPE_VIS_ONLY __list_iterator
{
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-__node_pointer;
+typedef typename __rebind_pointer<_VoidPtr, __list_node_base<_Tp, _VoidPtr> >::type
+__node_base_pointer;
-__node_pointer __ptr_;
+__node_base_pointer __ptr_;
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_iterator(__node_base_pointer __p, const void* __c) _NOEXCEPT
: __ptr_(__p)
{
__get_db()->__insert_ic(this, __c);
}
#else
_LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_iterator(__node_base_pointer __p) _NOEXCEPT : __ptr_(__p) {}
#endif
@@ -295,7 +306,7 @@
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
#endif
-return __ptr_->__value_;
+
Re: [PATCH] D12299: [libcxx] Fix for ALL undefined behavior in .
EricWF updated this revision to Diff 42612.
EricWF added a comment.
Update with correct patch this time.
http://reviews.llvm.org/D12299
Files:
include/__config
include/list
Index: include/list
===
--- include/list
+++ include/list
@@ -187,25 +187,55 @@
_LIBCPP_BEGIN_NAMESPACE_STD
template struct __list_node;
+template struct __list_node_base;
+
+template
+struct __node_pointer_traits {
+ typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
+__node_pointer;
+ typedef typename __rebind_pointer<_VoidPtr, __list_node_base<_Tp, _VoidPtr> >::type
+__base_pointer;
+
+#if defined(_LIBCPP_ABI_LIST_NODE_FIX)
+ typedef __base_pointer __link_pointer;
+#else
+ typedef typename conditional<
+ is_pointer<_VoidPtr>::value,
+ __base_pointer,
+ __node_pointer
+ >::type __link_pointer;
+#endif
+
+};
template
struct __list_node_base
{
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-pointer;
-typedef typename __rebind_pointer<_VoidPtr, __list_node_base>::type
-__base_pointer;
+typedef __node_pointer_traits<_Tp, _VoidPtr> _NodeTraits;
+typedef typename _NodeTraits::__node_pointer __node_pointer;
+typedef typename _NodeTraits::__base_pointer __base_pointer;
+typedef typename _NodeTraits::__link_pointer __link_pointer;
-pointer __prev_;
-pointer __next_;
+__link_pointer __prev_;
+__link_pointer __next_;
_LIBCPP_INLINE_VISIBILITY
-__list_node_base() : __prev_(__self()), __next_(__self()) {}
+__list_node_base() : __prev_(__as_link()), __next_(__as_link()) {}
_LIBCPP_INLINE_VISIBILITY
-pointer __self()
-{
-return static_cast(pointer_traits<__base_pointer>::pointer_to(*this));
+__base_pointer __as_base() {
+return pointer_traits<__base_pointer>::pointer_to(*this);
+}
+
+_LIBCPP_INLINE_VISIBILITY
+__link_pointer __as_link() {
+return static_cast<__link_pointer>(static_cast<_VoidPtr>(
+__as_base()));
+}
+
+_LIBCPP_INLINE_VISIBILITY
+__node_pointer __as_node() {
+return static_cast<__node_pointer>(__as_base());
}
};
@@ -223,21 +253,21 @@
template
class _LIBCPP_TYPE_VIS_ONLY __list_iterator
{
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-__node_pointer;
+typedef __node_pointer_traits<_Tp, _VoidPtr> _NodeTraits;
+typedef typename _NodeTraits::__link_pointer __link_pointer;
-__node_pointer __ptr_;
+__link_pointer __ptr_;
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_iterator(__link_pointer __p, const void* __c) _NOEXCEPT
: __ptr_(__p)
{
__get_db()->__insert_ic(this, __c);
}
#else
_LIBCPP_INLINE_VISIBILITY
-explicit __list_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_iterator(__link_pointer __p) _NOEXCEPT : __ptr_(__p) {}
#endif
@@ -295,7 +325,7 @@
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
#endif
-return __ptr_->__value_;
+return __ptr_->__as_node()->__value_;
}
_LIBCPP_INLINE_VISIBILITY
pointer operator->() const
@@ -304,7 +334,7 @@
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::iterator");
#endif
-return pointer_traits::pointer_to(__ptr_->__value_);
+return pointer_traits::pointer_to(__ptr_->__as_node()->__value_);
}
_LIBCPP_INLINE_VISIBILITY
@@ -346,21 +376,21 @@
template
class _LIBCPP_TYPE_VIS_ONLY __list_const_iterator
{
-typedef typename __rebind_pointer<_VoidPtr, __list_node<_Tp, _VoidPtr> >::type
-__node_pointer;
+typedef __node_pointer_traits<_Tp, _VoidPtr> _NodeTraits;
+typedef typename _NodeTraits::__link_pointer __link_pointer;
-__node_pointer __ptr_;
+__link_pointer __ptr_;
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p, const void* __c) _NOEXCEPT
+explicit __list_const_iterator(__link_pointer __p, const void* __c) _NOEXCEPT
: __ptr_(__p)
{
__get_db()->__insert_ic(this, __c);
}
#else
_LIBCPP_INLINE_VISIBILITY
-explicit __list_const_iterator(__node_pointer __p) _NOEXCEPT : __ptr_(__p) {}
+explicit __list_const_iterator(__link_pointer __p) _NOEXCEPT : __ptr_(__p) {}
#endif
template friend class list;
@@ -422,7 +452,7 @@
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable list::const_iterator");
#endif
-
Re: [PATCH] D15223: [ARM] [AARCH64] Add CodeGen IR tests for {VS}QRDML{AS}H v8.1a intrinsics.
echristo added a comment. Should be pretty easy to either use CHECK-DAG or pick out the particular instructions you want to check here. Otherwise you're just checking how the optimizer runs. That, in particular, also sounds like a good backend check. http://reviews.llvm.org/D15223 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15367: Cross-DSO control flow integrity (Clang part)
pcc added inline comments.
Comment at: lib/CodeGen/CGClass.cpp:2564
@@ -2563,16 +2563,3 @@
- SanitizerMask M;
- switch (TCK) {
- case CFITCK_VCall:
-M = SanitizerKind::CFIVCall;
-break;
- case CFITCK_NVCall:
-M = SanitizerKind::CFINVCall;
-break;
- case CFITCK_DerivedCast:
-M = SanitizerKind::CFIDerivedCast;
-break;
- case CFITCK_UnrelatedCast:
-M = SanitizerKind::CFIUnrelatedCast;
-break;
- }
+ if (CGM.getCodeGenOpts().SanitizeCfiCrossDso &&
+ isExternallyVisible(RD->getTypeForDecl()->getLinkage())) {
This could be an early return.
Comment at: lib/CodeGen/CGExpr.cpp:2560
@@ +2559,3 @@
+ llvm::MDString *MDS = dyn_cast(MD);
+ assert(MDS);
+ llvm::Constant *TypeId =
Use cast instead of dyn_cast/assert (but see my other comment).
Comment at: lib/CodeGen/CGExpr.cpp:3871
@@ +3870,3 @@
+isa(MD) && dyn_cast(MD)->isDistinct();
+if (CGM.getCodeGenOpts().SanitizeCfiCrossDso && !hasLocalScope) {
+ EmitCfiSlowPathCheck(BitSetTest, MD, CastedCallee);
Early return.
Comment at: lib/CodeGen/CodeGenModule.cpp:996
@@ +995,3 @@
+ !(isa(FD) && !cast(FD)->isStatic()) &&
+ !(CodeGenOpts.SanitizeCfiCrossDso && !FD->hasBody() &&
+!(getContext().GetGVALinkageForFunction(FD) ==
This is a little hard to read and probably needs to go back into a function
with early returns. Sorry, my bad. I also think the logic for
`available_externally` is wrong (please add a test case).
Comment at: lib/CodeGen/CodeGenModule.cpp:1011
@@ +1010,3 @@
+ uint64_t TypeId =
+ BuildCFICallSiteTypeId(dyn_cast(MD)->getString());
+ llvm::Metadata *BitsetOps2[] = {
This isn't handling function types with internal linkage.
We can probably do this more consistently (e.g. by introducing a function that
takes a `Metadata` from `CreateMetadataIdentifierForType` and returns a
`ConstantInt` or `nullptr` if none suitable, and using it here, in callers of
`EmitCfiSlowPathCheck` and in `CreateVTableBitSetEntry`).
Repository:
rL LLVM
http://reviews.llvm.org/D15367
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
Easwaran Raman writes: > eraman added a comment. > > I have reverted the commit in r255416 because the test failed in many > architectures. You also committed without waiting for further review, despite that David said "LGTM but please wait for other reviewers". Please don't do that in the future. > In many cases the linker is not able to find > libclang_rt.profile-$ARCH.a file. There are also other errors. Here is > one: > > 0. Program arguments: > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/clang > -cc1 -triple hexagon-unknown--elf -emit-obj -disable-free > -main-file-name pgo-max-function-count.c -mrelocation-model static > -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose > -mconstructor-aliases -target-cpu hexagonv4 -mqdsp6-compat > -Wreturn-type -fshort-enums -mllvm -machine-sink-split=0 > -target-linker-version 2.25 -dwarf-column-info > -fprofile-instr-generate -resource-dir > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../lib/clang/3.8.0 > -internal-externc-isystem > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/lib/gcc/hexagon/0.0.0/include > -internal-externc-isystem > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/lib/gcc/hexagon/0.0.0/include-fixed > -internal-externc-isystem > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/Release+Asserts/bin/../../gnu/hexagon/include > -O2 -fdebug-compilation-dir > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.obj/tools/clang/test/CodeGen > -ferror-limit 19 -fmessage-length 0 -fshort-enums -fno-signed-char > -fno-use-cxa-atexit -fobjc-runtime=gcc -fdiagnostics-show-option > -vectorize-loops -vectorize-slp -o > /tmp/pgo-max-function-count-816195.o -x c > /var/lib/buildbot/slaves/hexagon-build-03/clang-hexagon-elf/llvm.src/tools/clang/test/CodeGen/pgo-max-function-count.c > > > > Target: hexagon-unknown--elf > > Seems like the command line is messed up (I assume there should be a > space between hexagon-unknown and --elf). > > Any suggestions on how to fix this test case? AFAICT, there are no PGO > related tests in clang and I based this on PGO tests in compiler-rt/ I'll comment on the patch, but you can't write tests in clang that attempt to compile and run the compiled binary. > > Repository: > rL LLVM > > http://reviews.llvm.org/D15163 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15462: [CMake] Add support for generating profdata for clang from training files
silvas added a comment.
Can you elaborate on why this patch is restricted to unix?
Also, this probably requires some documentation in
http://llvm.org/docs/CMake.html
(we don't really have an analogous page just for clang currently, so the llvm
one is probably the best place right now)
Comment at: utils/perf-training/CMakeLists.txt:21
@@ +20,3 @@
+ add_custom_target(clear-profraw
+COMMAND find ${CMAKE_CURRENT_BINARY_DIR} -name "*.profraw" -print | xargs
rm
+COMMENT "Clearing old profraw data")
Can you write a tiny pure-Python helper script for clear-profraw and another
for generate-profdata? That will be more portable.
If this is the only thing blocking windows support, I think that shooting for
windows support on the initial patch is worth a shot.
http://reviews.llvm.org/D15462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15455: [Driver] Let -static override the toolchain default PIC setting.
probinson added a comment. PS4 rejects -static unconditionally, so in that sense changing what it means doesn't matter to us. (But I really appreciate being asked!) Still, abstractly it seems like -static doesn't really imply noPIC. http://reviews.llvm.org/D15455 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15163: Attach maximum function count to Module when using PGO mode.
Easwaran Raman writes:
> eraman updated this revision to Diff 42549.
> eraman added a comment.
>
> Added a test case.
>
>
> Repository:
> rL LLVM
>
> http://reviews.llvm.org/D15163
>
> Files:
> lib/CodeGen/CodeGenModule.cpp
> test/CodeGen/pgo-max-function-count.c
>
> Index: test/CodeGen/pgo-max-function-count.c
> ===
> --- /dev/null
> +++ test/CodeGen/pgo-max-function-count.c
> @@ -0,0 +1,9 @@
> +// RUN: %clang -fprofile-generate -o %t -O2 %s
> +// RUN: env LLVM_PROFILE_FILE=%t.profraw %t
The clang tests are run in environments where the generated binaries
can't run on the host system, so you can't do this. Instead of this kind
of full integration test you should provide handwritten profile data to
feed into the test. See the tests in test/Profile for examples, and also
consider putting this test in that directory with the others.
> +// RUN: llvm-profdata merge -o %t.profdata %t.profraw
> +// RUN: %clang -fprofile-use=%t.profdata -o - -S -emit-llvm %s | FileCheck %s
> +// Check
> +int main() {
> + return 0;
> +}
> +// CHECK: !{{[0-9]+}} = !{i32 1, !"MaxFunctionCount", i32 1}
> Index: lib/CodeGen/CodeGenModule.cpp
> ===
> --- lib/CodeGen/CodeGenModule.cpp
> +++ lib/CodeGen/CodeGenModule.cpp
> @@ -376,6 +376,9 @@
>}
>if (PGOReader && PGOStats.hasDiagnostics())
> PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
> + // In PGO mode, attach maximum function count to the module.
This comment isn't helpful - it's just stating exactly what the code
that follows does.
> + if (PGOReader)
> +
> getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
It would read better to fold the two `if (PGOReader)` checks
together. ie:
if (PGOReader) {
getModule().setMaximumFunctionCount(PGOReader->getMaximumFunctionCount());
if (PGOStats.hasDiagnostics())
PGOStats.reportDiagnostics(getDiags(), getCodeGenOpts().MainFileName);
}
That said, wouldn't it make more sense to set this within PGOReader
itself? It feels pretty awkward for this to be happening in
CodeGenModule::Release().
>EmitCtorList(GlobalCtors, "llvm.global_ctors");
>EmitCtorList(GlobalDtors, "llvm.global_dtors");
>EmitGlobalAnnotations();
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15470: Preserve source location in namespaced base ctor initializers
rsmith accepted this revision. rsmith added a comment. This revision is now accepted and ready to land. LGTM http://reviews.llvm.org/D15470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255420 - Preserve source location information for qualified names used in a constructor
Author: rsmith
Date: Fri Dec 11 20:17:54 2015
New Revision: 255420
URL: http://llvm.org/viewvc/llvm-project?rev=255420&view=rev
Log:
Preserve source location information for qualified names used in a constructor
initializer list to name a base class. Patch by Shahms King!
Added:
cfe/trunk/test/Index/namespaced-base-ctor-init.cpp
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=255420&r1=255419&r2=255420&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Fri Dec 11 20:17:54 2015
@@ -2980,10 +2980,15 @@ Sema::BuildMemInitializer(Decl *Construc
if (BaseType.isNull()) {
BaseType = Context.getTypeDeclType(TyD);
MarkAnyDeclReferenced(TyD->getLocation(), TyD, /*OdrUse=*/false);
- if (SS.isSet())
-// FIXME: preserve source range information
+ if (SS.isSet()) {
BaseType = Context.getElaboratedType(ETK_None, SS.getScopeRep(),
BaseType);
+TInfo = Context.CreateTypeSourceInfo(BaseType);
+ElaboratedTypeLoc TL = TInfo->getTypeLoc().castAs();
+TL.getNamedTypeLoc().castAs().setNameLoc(IdLoc);
+TL.setElaboratedKeywordLoc(SourceLocation());
+TL.setQualifierLoc(SS.getWithLocInContext(Context));
+ }
}
}
Added: cfe/trunk/test/Index/namespaced-base-ctor-init.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/namespaced-base-ctor-init.cpp?rev=255420&view=auto
==
--- cfe/trunk/test/Index/namespaced-base-ctor-init.cpp (added)
+++ cfe/trunk/test/Index/namespaced-base-ctor-init.cpp Fri Dec 11 20:17:54 2015
@@ -0,0 +1,10 @@
+namespace ns1 {
+struct Base {};
+struct Derived : Base {
+ Derived() : ns1::Base() {}
+};
+}
+
+// RUN: c-index-test -test-load-source all %s | FileCheck %s
+// CHECK: namespaced-base-ctor-init.cpp:4:15: NamespaceRef=ns1:1:11
Extent=[4:15 - 4:18]
+// CHECK: namespaced-base-ctor-init.cpp:4:20: TypeRef=struct ns1::Base:2:8
Extent=[4:20 - 4:24]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15470: Preserve source location in namespaced base ctor initializers
rsmith closed this revision. rsmith added a comment. Committed as r255420. Thanks for the patch! http://reviews.llvm.org/D15470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15462: [CMake] Add support for generating profdata for clang from training files
vsk added a comment.
Thanks! Interesting approach. I think @cmatthews would appreciate a
`generate-profdata-from-lnt` target if you're up for it :).
Comments inline --
Comment at: utils/perf-training/CMakeLists.txt:2
@@ +1,3 @@
+if(LLVM_BUILD_INSTRUMENTED AND NOT WIN32)
+ if (CMAKE_CFG_INTDIR STREQUAL ".")
+set(LLVM_BUILD_MODE ".")
Afaict, lines 2-8 look like they're provided by configure_lit_site_cfg
(AddLLVM.cmake).
Comment at: utils/perf-training/CMakeLists.txt:8
@@ +7,3 @@
+
+ string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} CLANG_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
+
Is it possible for this line to interact poorly with the one in
clang/test/CMakeLists.txt? E.g something weird like if CMAKE_CFG_INTDIR is a
substring of LLVM_BUILD_MODE?
Comment at: utils/perf-training/CMakeLists.txt:17
@@ +16,3 @@
+${CMAKE_CURRENT_BINARY_DIR}
+DEPENDS clang clear-profraw
+)
Can we build llvm-profdata too?
Comment at: utils/perf-training/CMakeLists.txt:25
@@ +24,3 @@
+ if(NOT LLVM_PROFDATA)
+find_program(LLVM_PROFDATA llvm-profdata)
+ endif()
We should use a llvm-profdata built out of the current source. Does the
`llvm_find_program` function help with this?
Comment at: utils/perf-training/CMakeLists.txt:33
@@ +32,3 @@
+ add_custom_target(generate-profdata
+COMMAND find ${CMAKE_CURRENT_BINARY_DIR} -name "*.profraw" -print | xargs
${LLVM_PROFDATA} merge -o ${CMAKE_CURRENT_BINARY_DIR}/clang.profdata
+COMMENT "Merging profdata"
Sean's comment about relying on `find` applies here too.
Comment at: utils/perf-training/lit.cfg:7
@@ +6,3 @@
+
+def inferClang(PATH):
+# Determine which clang to use.
This duplicates code in tools/clang/test/lit.cfg. Can we lift it into a shared
module?
Comment at: utils/perf-training/lit.site.cfg.in:3
@@ +2,3 @@
+
+## Autogenerated by LLVM/Clang configuration.
+# Do not edit!
I don't know too much about what's going on here. It seems weird to check in
auto generated files.. why do we need to do that?
http://reviews.llvm.org/D15462
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15140: Update clang to use the updated LLVM EH instructions
majnemer updated this revision to Diff 42618.
majnemer added a comment.
- Updated for the latest EH changes
- Updated for LLVM changes
- Address review comments
http://reviews.llvm.org/D15140
Files:
lib/CodeGen/CGCall.cpp
lib/CodeGen/CGCleanup.cpp
lib/CodeGen/CGCleanup.h
lib/CodeGen/CGException.cpp
lib/CodeGen/CodeGenFunction.h
lib/CodeGen/EHScopeStack.h
lib/CodeGen/MicrosoftCXXABI.cpp
test/CodeGen/exceptions-seh-finally.c
test/CodeGen/exceptions-seh-leave.c
test/CodeGen/exceptions-seh.c
test/CodeGenCXX/exceptions-cxx-new.cpp
test/CodeGenCXX/exceptions-seh.cpp
test/CodeGenCXX/microsoft-abi-arg-order.cpp
test/CodeGenCXX/microsoft-abi-eh-catch.cpp
test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
test/CodeGenCXX/microsoft-abi-try-throw.cpp
Index: test/CodeGenCXX/microsoft-abi-try-throw.cpp
===
--- test/CodeGenCXX/microsoft-abi-try-throw.cpp
+++ test/CodeGenCXX/microsoft-abi-try-throw.cpp
@@ -19,7 +19,7 @@
external(); // TRY: invoke void @"\01?external@@YAXXZ"
} catch (int) {
rv = 1;
-// TRY: catchpad [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i8* null]
+// TRY: catchpad within %0 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0, i8* null]
// TRY: catchret
}
#endif
@@ -39,7 +39,7 @@
external();
} catch (const int *) {
}
- // TRY: catchpad [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32 1, i8* null]
+ // TRY: catchpad within %0 [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32 1, i8* null]
// TRY: catchret
}
#endif
Index: test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
===
--- test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
+++ test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
@@ -39,7 +39,7 @@
// CHECK-NEXT: ret %struct.S* @"\01?s@?1??f@@YAAAUS@@XZ@4U2@A"
// CHECK: [[lpad:.*]]:
-// CHECK-NEXT: cleanuppad []
+// CHECK-NEXT: cleanuppad within none []
// CHECK: %[[guard:.*]] = load i32, i32* @"\01??__J?1??f@@YAAAUS@@XZ@51"
// CHECK-NEXT: %[[mask:.*]] = and i32 %[[guard]], -2
// CHECK-NEXT: store i32 %[[mask]], i32* @"\01??__J?1??f@@YAAAUS@@XZ@51"
@@ -75,7 +75,7 @@
// CHECK-NEXT: ret %struct.S* @"\01?s@?1??g@@YAAAUS@@XZ@4U2@A"
//
// CHECK: [[lpad]]:
-// CHECK-NEXT: cleanuppad []
+// CHECK-NEXT: cleanuppad within none []
// CHECK: call void @_Init_thread_abort(i32* @"\01?$TSS0@?1??g@@YAAAUS@@XZ")
// CHECK-NEXT: cleanupret {{.*}} unwind to caller
return s;
Index: test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
===
--- test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
+++ test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
@@ -9,6 +9,6 @@
// CHECK-LABEL: define void @"\01?never_throws@@YAXXZ"()
// CHECK-SAME: personality i8* bitcast (i32 (...)* @__CxxFrameHandler3 to i8*)
// CHECK: invoke void @"\01?may_throw@@YAXXZ"()
-// MSVC2013: terminatepad [void ()* @"\01?terminate@@YAXXZ"]
-// MSVC2015: terminatepad [void ()* @__std_terminate]
+// MSVC2013: terminatepad within none [void ()* @"\01?terminate@@YAXXZ"]
+// MSVC2015: terminatepad within none [void ()* @__std_terminate]
// CHECK-NEXT: unreachable
Index: test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
===
--- test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
+++ test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
@@ -27,7 +27,7 @@
//
//There should be one dtor call for unwinding from the second getA.
// WIN32: cleanuppad
-// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline:[0-9]+]]
+// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-NOT: @"\01??1A@@QAE@XZ"
// WIN32: }
@@ -62,7 +62,7 @@
//Conditionally destroy arg1.
// WIN32: %[[cond:.*]] = load i1, i1* %[[isactive]]
// WIN32: br i1 %[[cond]]
-// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %[[arg1]]) #[[noinline]]
+// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"(%struct.A* %[[arg1]])
// WIN32: }
// Test putting the cleanups inside a conditional.
@@ -85,7 +85,7 @@
// WIN32: call i32 @"\01?CouldThrow@@YAHXZ"()
//
//Only one dtor in the invoke for arg1
-// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline]]
+// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WIN32-NOT: invoke x86_thiscallcc void @"\01??1A@@QAE@XZ"
// WIN32: }
@@ -126,7 +126,7 @@
//Somewhere in the landing pad soup, we conditionally destroy arg1.
// WIN32: %[[isactive:.*]] = load i1, i1* %[[arg1_cond]]
// WIN32: br i1 %[[isactive]]
-// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}}) #[[noinline]]
+// WIN32: call x86_thiscallcc void @"\01??1A@@QAE@XZ"({{.*}})
// WI
Re: [PATCH] D15410: AnalysisConsumer: use canonical decl for both lookup and store of visited decls
zaks.anna added inline comments. Comment at: test/Analysis/inlining/analysis-order.c:13 @@ +12,3 @@ + +// CHECK: analysis-order.c test2 +// CHECK: analysis-order.c test1 Can you use CHECK-NEXT instead? Repository: rL LLVM http://reviews.llvm.org/D15410 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D15370: [scan-view] replace deprecated optparse with argparse
zaks.anna added a comment.
Overall, looks good!
Comment at: tools/scan-view/bin/scan-view:94
@@ +93,3 @@
+import argparse
+parser = argparse.ArgumentParser()
+parser.add_argument("root", metavar="", type=str)
Please, add the tool description, like "The clang static analyzer results
viewer."
http://reviews.llvm.org/D15370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255423 - Update clang to use the updated LLVM EH instructions
Author: majnemer
Date: Fri Dec 11 23:39:21 2015
New Revision: 255423
URL: http://llvm.org/viewvc/llvm-project?rev=255423&view=rev
Log:
Update clang to use the updated LLVM EH instructions
Depends on D15139.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D15140
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGCleanup.h
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/EHScopeStack.h
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGen/exceptions-seh-finally.c
cfe/trunk/test/CodeGen/exceptions-seh-leave.c
cfe/trunk/test/CodeGen/exceptions-seh.c
cfe/trunk/test/CodeGenCXX/exceptions-cxx-new.cpp
cfe/trunk/test/CodeGenCXX/exceptions-seh.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-catch.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=255423&r1=255422&r2=255423&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Dec 11 23:39:21 2015
@@ -15,6 +15,7 @@
#include "CGCall.h"
#include "ABIInfo.h"
#include "CGCXXABI.h"
+#include "CGCleanup.h"
#include "CodeGenFunction.h"
#include "CodeGenModule.h"
#include "TargetInfo.h"
@@ -3472,11 +3473,21 @@ RValue CodeGenFunction::EmitCall(const C
llvm::AttributeSet Attrs = llvm::AttributeSet::get(getLLVMContext(),
AttributeList);
- llvm::BasicBlock *InvokeDest = nullptr;
- if (!Attrs.hasAttribute(llvm::AttributeSet::FunctionIndex,
- llvm::Attribute::NoUnwind) ||
- currentFunctionUsesSEHTry())
-InvokeDest = getInvokeDest();
+ bool CannotThrow;
+ if (currentFunctionUsesSEHTry()) {
+// SEH cares about asynchronous exceptions, everything can "throw."
+CannotThrow = false;
+ } else if (isCleanupPadScope() &&
+ EHPersonality::get(*this).isMSVCXXPersonality()) {
+// The MSVC++ personality will implicitly terminate the program if an
+// exception is thrown. An unwind edge cannot be reached.
+CannotThrow = true;
+ } else {
+// Otherwise, nowunind callsites will never throw.
+CannotThrow = Attrs.hasAttribute(llvm::AttributeSet::FunctionIndex,
+ llvm::Attribute::NoUnwind);
+ }
+ llvm::BasicBlock *InvokeDest = CannotThrow ? nullptr : getInvokeDest();
llvm::CallSite CS;
if (!InvokeDest) {
@@ -3495,14 +3506,8 @@ RValue CodeGenFunction::EmitCall(const C
Attrs.addAttribute(getLLVMContext(), llvm::AttributeSet::FunctionIndex,
llvm::Attribute::AlwaysInline);
- // Disable inlining inside SEH __try blocks and cleanup funclets. None of the
- // funclet EH personalities that clang supports have tables that are
- // expressive enough to describe catching an exception inside a cleanup.
- // __CxxFrameHandler3, for example, will terminate the program without
- // catching it.
- // FIXME: Move this decision to the LLVM inliner. Before we can do that, the
- // inliner needs to know if a given call site is part of a cleanuppad.
- if (isSEHTryScope() || isCleanupPadScope())
+ // Disable inlining inside SEH __try blocks.
+ if (isSEHTryScope())
Attrs =
Attrs.addAttribute(getLLVMContext(), llvm::AttributeSet::FunctionIndex,
llvm::Attribute::NoInline);
Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=255423&r1=255422&r2=255423&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Fri Dec 11 23:39:21 2015
@@ -246,13 +246,6 @@ void EHScopeStack::pushTerminate() {
InnermostEHScope = stable_begin();
}
-void EHScopeStack::pushPadEnd(llvm::BasicBlock *PadEndBB) {
- char *Buffer = allocate(EHPadEndScope::getSize());
- auto *CES = new (Buffer) EHPadEndScope(InnermostEHScope);
- CES->setCachedEHDispatchBlock(PadEndBB);
- InnermostEHScope = stable_begin();
-}
-
/// Remove any 'null' fixups on the stack. However, we can't pop more
/// fixups than the fixup depth on the innermost normal cleanup, or
/// else fixups that we try to add to that cleanup will end up in the
@@ -909,24 +902,17 @@ void CodeGenFunction::PopCleanupBlock(bo
// throwing cleanups. For funclet EH personalities, the cleanupendpad
models
// program termination when cle
Re: [PATCH] D15140: Update clang to use the updated LLVM EH instructions
This revision was automatically updated to reflect the committed changes.
Closed by commit rL255423: Update clang to use the updated LLVM EH instructions
(authored by majnemer).
Changed prior to commit:
http://reviews.llvm.org/D15140?vs=42618&id=42632#toc
Repository:
rL LLVM
http://reviews.llvm.org/D15140
Files:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGCleanup.h
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/EHScopeStack.h
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGen/exceptions-seh-finally.c
cfe/trunk/test/CodeGen/exceptions-seh-leave.c
cfe/trunk/test/CodeGen/exceptions-seh.c
cfe/trunk/test/CodeGenCXX/exceptions-cxx-new.cpp
cfe/trunk/test/CodeGenCXX/exceptions-seh.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-arg-order.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-catch.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-terminate.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-thread-safe-statics.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp
Index: cfe/trunk/test/CodeGen/exceptions-seh.c
===
--- cfe/trunk/test/CodeGen/exceptions-seh.c
+++ cfe/trunk/test/CodeGen/exceptions-seh.c
@@ -34,12 +34,9 @@
// CHECK: to label %{{.*}} unwind label %[[catchpad:[^ ]*]]
//
// CHECK: [[catchpad]]
-// X64: %[[padtoken:[^ ]*]] = catchpad [i8* null]
-// X86: %[[padtoken:[^ ]*]] = catchpad [i8* bitcast (i32 ()* @"\01?filt$0@0@safe_div@@" to i8*)]
-// CHECK-NEXT:to label %[[exceptret:[^ ]*]] unwind label
-//
-// CHECK: [[exceptret]]
-// CHECK: catchret %[[padtoken]] to label %[[except:[^ ]*]]
+// X64: %[[padtoken:[^ ]*]] = catchpad within %{{[^ ]*}} [i8* null]
+// X86: %[[padtoken:[^ ]*]] = catchpad within %{{[^ ]*}} [i8* bitcast (i32 ()* @"\01?filt$0@0@safe_div@@" to i8*)]
+// CHECK-NEXT: catchret from %[[padtoken]] to label %[[except:[^ ]*]]
//
// CHECK: [[except]]
// CHECK: store i32 -42, i32* %[[success:[^ ]*]]
@@ -85,7 +82,7 @@
// CHECK: store i32 42, i32* %[[r]]
// CHECK: invoke void @j() #[[NOINLINE]]
//
-// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@filter_expr_capture@@" to i8*)]
+// CHECK: catchpad within %{{[^ ]*}} [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@filter_expr_capture@@" to i8*)]
// CHECK: store i32 13, i32* %[[r]]
//
// CHECK: %[[rv:[^ ]*]] = load i32, i32* %[[r]]
@@ -121,37 +118,37 @@
// X86-SAME: personality i8* bitcast (i32 (...)* @_except_handler3 to i8*)
// CHECK: store i32 42, i32* %[[r:[^ ,]*]]
// CHECK: invoke void @j() #[[NOINLINE]]
-// CHECK: to label %[[cont:[^ ]*]] unwind label %[[cpad_inner:[^ ]*]]
-//
-// CHECK: [[cpad_inner]]
-// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$1@0@nested_try@@" to i8*)]
-// CHECK-NEXT: to label %[[exceptret_inner:[^ ]*]] unwind label %[[cpad_outer:[^ ]*]]
+// CHECK: to label %[[cont:[^ ]*]] unwind label %[[cswitch_inner:[^ ]*]]
//
-// CHECK: [[exceptret_inner]]
-// CHECK: catchret {{.*}} to label %[[except_inner:[^ ]*]]
+// CHECK: [[cswitch_inner]]
+// CHECK: %[[cs_inner:[^ ]*]] = catchswitch within none [label %[[cpad_inner:[^ ]*]]] unwind label %[[cswitch_outer:[^ ]*]]
//
-// CHECK: [[except_inner]]
-// CHECK: store i32 123, i32* %[[r]]
-// CHECK: br label %[[inner_try_cont:[^ ]*]]
-//
-// CHECK: [[inner_try_cont]]
-// CHECK: br label %[[outer_try_cont:[^ ]*]]
+// CHECK: [[cswitch_outer]]
+// CHECK: %[[cs_outer:[^ ]*]] = catchswitch within none [label %[[cpad_outer:[^ ]*]]] unwind to caller
//
// CHECK: [[cpad_outer]]
-// CHECK: catchpad [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@nested_try@@" to i8*)]
-// CHECK-NEXT: to label %[[exceptret_outer:[^ ]*]] unwind label
-//
-// CHECK: [[exceptret_outer]]
-// CHECK: catchret {{.*}} to label %[[except_outer:[^ ]*]]
+// CHECK: catchpad within %{{[^ ]*}} [i8* bitcast (i32 ({{.*}})* @"\01?filt$0@0@nested_try@@" to i8*)]
+// CHECK-NEXT: catchret {{.*}} to label %[[except_outer:[^ ]*]]
//
// CHECK: [[except_outer]]
// CHECK: store i32 456, i32* %[[r]]
-// CHECK: br label %[[outer_try_cont]]
+// CHECK: br label %[[outer_try_cont:[^ ]*]]
//
// CHECK: [[outer_try_cont]]
// CHECK: %[[r_load:[^ ]*]] = load i32, i32* %[[r]]
// CHECK: ret i32 %[[r_load]]
//
+// CHECK: [[cpad_inner]]
+// CHECK: catchpad within %[[cs_inner]] [i8* bitcast (i32 ({{.*}})* @"\01?filt$1@0@nested_try@@" to i8*)]
+// CHECK-NEXT: catchret {{.*}} to label %[[except_inner:[^ ]*]]
+//
+// CHECK: [[except_inner]]
+// CHECK: store i32 123, i32* %[[r]]
+// CHECK: br label %[[inner_try_cont:[^ ]*]]
+//
+// CHECK: [[inner_try_cont]]
+// CHECK: br label %[[outer_try_cont]]
+//
// CHECK: [[cont]]
// CHECK: store i32 0, i32* %[[r]]
// CHECK: br label %[[inner_try_cont]]
@@ -193,14 +190,10 @@
// CHECK: ret i32
//
// CHECK: [[cleanuppad]]
-// CHECK: %[[padtoken:[^ ]*]] = cleanuppad []
+// CHECK: %[
Re: [PATCH] D14779: Adding checker to detect excess padding in records
zaks.anna added a comment. With respect to the issues this checker found, I suggest submitting patches for the clang issues that can be fixed. Can the x-macro case be suppressed with the recommended suppression? I'd also submit a patch to gtest. Submitting patches with the fixes provides a good evaluation of new checkers:) Comment at: lib/StaticAnalyzer/Checkers/Checkers.td:49 @@ -48,1 +48,3 @@ +def Performance : Package<"performance">; + I think Performance should be in the OptIn package. Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:194 @@ +193,3 @@ + /// 3. If no fields can fit, pad by rounding the current offset up to our + /// lowest aligned field. Measure and track the amount of padding added. + /// Go back to 2. It's not 100% clear what the "lowest aligned field" is. Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:196 @@ +195,3 @@ + /// Go back to 2. + /// 4. Increment the current offset by the size of the chosen field + /// 5. Remove the chosen field from the set of future possibilities Punctuation is missing in 4, 5, 6. Comment at: lib/StaticAnalyzer/Checkers/PaddingChecker.cpp:200 @@ +199,3 @@ + /// 7. Add tail padding by rounding the current offset up to the structure + /// alignment. Track the amount of padding added. + Extra space before "Track"? http://reviews.llvm.org/D14779 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255424 - Try to appease a buildbot.
Author: majnemer
Date: Fri Dec 11 23:50:32 2015
New Revision: 255424
URL: http://llvm.org/viewvc/llvm-project?rev=255424&view=rev
Log:
Try to appease a buildbot.
Modified:
cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp
Modified: cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp?rev=255424&r1=255423&r2=255424&view=diff
==
--- cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/microsoft-abi-try-throw.cpp Fri Dec 11 23:50:32
2015
@@ -19,7 +19,7 @@ int main() {
external(); // TRY: invoke void @"\01?external@@YAXXZ"
} catch (int) {
rv = 1;
-// TRY: catchpad within %0 [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32 0,
i8* null]
+// TRY: catchpad within {{.*}} [%rtti.TypeDescriptor2* @"\01??_R0H@8", i32
0, i8* null]
// TRY: catchret
}
#endif
@@ -39,7 +39,7 @@ void qual_catch() {
external();
} catch (const int *) {
}
- // TRY: catchpad within %0 [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32 1,
i8* null]
+ // TRY: catchpad within {{.*}} [%rtti.TypeDescriptor4* @"\01??_R0PAH@8", i32
1, i8* null]
// TRY: catchret
}
#endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255427 - [Sema] Simplify a couple if statements. Explicitly check up front that only one of the expressions is a comparision op. Then if we find that either is a bitwise op, we know it must be the ot
Author: ctopper Date: Sat Dec 12 00:30:48 2015 New Revision: 255427 URL: http://llvm.org/viewvc/llvm-project?rev=255427&view=rev Log: [Sema] Simplify a couple if statements. Explicitly check up front that only one of the expressions is a comparision op. Then if we find that either is a bitwise op, we know it must be the other one. NFC Modified: cfe/trunk/lib/Sema/SemaExpr.cpp Modified: cfe/trunk/lib/Sema/SemaExpr.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255427&r1=255426&r2=255427&view=diff == --- cfe/trunk/lib/Sema/SemaExpr.cpp (original) +++ cfe/trunk/lib/Sema/SemaExpr.cpp Sat Dec 12 00:30:48 2015 @@ -10474,17 +10474,17 @@ static void DiagnoseBitwisePrecedence(Se BinaryOperator *LHSBO = dyn_cast(LHSExpr); BinaryOperator *RHSBO = dyn_cast(RHSExpr); - // Check that one of the sides is a comparison operator. + // Check that one of the sides is a comparison operator and the other isn't. bool isLeftComp = LHSBO && LHSBO->isComparisonOp(); bool isRightComp = RHSBO && RHSBO->isComparisonOp(); - if (!isLeftComp && !isRightComp) + if (isLeftComp == isRightComp) return; // Bitwise operations are sometimes used as eager logical ops. // Don't diagnose this. bool isLeftBitwise = LHSBO && LHSBO->isBitwiseOp(); bool isRightBitwise = RHSBO && RHSBO->isBitwiseOp(); - if ((isLeftComp || isLeftBitwise) && (isRightComp || isRightBitwise)) + if (isLeftBitwise || isRightBitwise) return; SourceRange DiagRange = isLeftComp ? SourceRange(LHSExpr->getLocStart(), ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r255428 - Minor formatting cleanup. NFC
Author: ctopper
Date: Sat Dec 12 00:30:51 2015
New Revision: 255428
URL: http://llvm.org/viewvc/llvm-project?rev=255428&view=rev
Log:
Minor formatting cleanup. NFC
Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=255428&r1=255427&r2=255428&view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Sat Dec 12 00:30:51 2015
@@ -10591,7 +10591,7 @@ static void DiagnoseLogicalAndInLogicalO
/// \brief Look for '&' in the left or right hand of a '|' expr.
static void DiagnoseBitwiseAndInBitwiseOr(Sema &S, SourceLocation OpLoc,
- Expr *OrArg) {
+ Expr *OrArg) {
if (BinaryOperator *Bop = dyn_cast(OrArg)) {
if (Bop->getOpcode() == BO_And)
return EmitDiagnosticForBitwiseAndInBitwiseOr(S, OpLoc, Bop);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
