Re: r243987 - [Sema] Allocate SmallVector to the right size.
On Aug 4, 2015 7:51 AM, Benjamin Kramer benny@googlemail.com wrote:
Author: d0k
Date: Tue Aug 4 09:46:06 2015
New Revision: 243987
URL: http://llvm.org/viewvc/llvm-project?rev=243987view=rev
Log:
[Sema] Allocate SmallVector to the right size.
SmallVector::set_size does not reallocate the vector. Sadly I have no
idea how to test this. The vector never has more than one member in all
of the regression tests.
Could try adding an assert and self hosting to find a non-singular case?
But yeah, I get that's probably not worth it.
Should we rename set_size something more intimidating/scary? That, or I'd
love to remove it...
Found by inspection.
Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=243987r1=243986r2=243987view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Tue Aug 4
09:46:06 2015
@@ -1657,7 +1657,7 @@ TemplateDeclInstantiator::VisitCXXMethod
SmallVectorTemplateParameterList *, 4 TempParamLists;
unsigned NumTempParamLists = 0;
if (isFriend (NumTempParamLists =
D-getNumTemplateParameterLists())) {
-TempParamLists.set_size(NumTempParamLists);
+TempParamLists.resize(NumTempParamLists);
for (unsigned I = 0; I != NumTempParamLists; ++I) {
TemplateParameterList *TempParams = D-getTemplateParameterList(I);
TemplateParameterList *InstParams =
SubstTemplateParams(TempParams);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r243987 - [Sema] Allocate SmallVector to the right size.
On Aug 4, 2015 8:12 AM, Benjamin Kramer benny@gmail.com wrote:
On 04.08.2015, at 17:08, David Blaikie dblai...@gmail.com wrote:
On Aug 4, 2015 7:51 AM, Benjamin Kramer benny@googlemail.com
wrote:
Author: d0k
Date: Tue Aug 4 09:46:06 2015
New Revision: 243987
URL: http://llvm.org/viewvc/llvm-project?rev=243987view=rev
Log:
[Sema] Allocate SmallVector to the right size.
SmallVector::set_size does not reallocate the vector. Sadly I have no
idea how to test this. The vector never has more than one member in
all
of the regression tests.
Could try adding an assert and self hosting to find a non-singular
case? But yeah, I get that's probably not worth it.
We may have crazy templated code in LLVM, but I'm 100% sure that we don't
have any friend functions with multiple template parameter lists ;)
Fair - I figured it might turn up in some stl implementation pieces etc.
But boost or the like is perhaps more likely.
Should we rename set_size something more intimidating/scary? That, or
I'd love to remove it...
Naming suggestions welcome. Removing it is probably not feasible as
raw_svector_ostream relies on it.
Yeah... Not sure what the right answer there.
A while back I made a half hearted attempt to replace smallvector with
std::vector just to see how much perf the optimizations were getting us
(because there were some ops in smallvector and other containers that
werent so well defined (inserting subranges into the container the
subranges was in))
- Ben
Found by inspection.
Modified:
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=243987r1=243986r2=243987view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Tue Aug 4
09:46:06 2015
@@ -1657,7 +1657,7 @@ TemplateDeclInstantiator::VisitCXXMethod
SmallVectorTemplateParameterList *, 4 TempParamLists;
unsigned NumTempParamLists = 0;
if (isFriend (NumTempParamLists =
D-getNumTemplateParameterLists())) {
-TempParamLists.set_size(NumTempParamLists);
+TempParamLists.resize(NumTempParamLists);
for (unsigned I = 0; I != NumTempParamLists; ++I) {
TemplateParameterList *TempParams =
D-getTemplateParameterList(I);
TemplateParameterList *InstParams =
SubstTemplateParams(TempParams);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r243694 - Split DWARF: Allow -gmlt/-gsplit-dwarf to override rather than complement each other
Author: dblaikie
Date: Thu Jul 30 16:42:22 2015
New Revision: 243694
URL: http://llvm.org/viewvc/llvm-project?rev=243694view=rev
Log:
Split DWARF: Allow -gmlt/-gsplit-dwarf to override rather than complement each
other
It doesn't make any sense to enable -gmlt with -gsplit-dwarf, since
-gmlt is designed for on-line symbolication (and -gsplit-dwarf normally
emits all the -gmlt data into the .o anyway - so there's nothing to
split out except redundant/duplicate info).
With this change they override each other, -gmlt -gsplit-dwarf is the
same as -gsplit-dwarf and -gsplit-dwarf -gmlt is the same as -gmlt.
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/split-debug.c
Modified: cfe/trunk/lib/Driver/Tools.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=243694r1=243693r2=243694view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Thu Jul 30 16:42:22 2015
@@ -3644,9 +3644,11 @@ void Clang::ConstructJob(Compilation C,
// Use the last option from -g group. -gline-tables-only and -gdwarf-x
// are preserved, all other debug options are substituted with -g.
Args.ClaimAllArgs(options::OPT_g_Group);
+ Arg *SplitDwarfArg = Args.getLastArg(options::OPT_gsplit_dwarf);
if (Arg *A = Args.getLastArg(options::OPT_g_Group)) {
-if (A-getOption().matches(options::OPT_gline_tables_only) ||
-A-getOption().matches(options::OPT_g1)) {
+if ((A-getOption().matches(options::OPT_gline_tables_only) ||
+ A-getOption().matches(options::OPT_g1))
+(!SplitDwarfArg || A-getIndex() SplitDwarfArg-getIndex())) {
// FIXME: we should support specifying dwarf version with
// -gline-tables-only.
CmdArgs.push_back(-gline-tables-only);
@@ -3656,6 +3658,7 @@ void Clang::ConstructJob(Compilation C,
Triple.getOS() == llvm::Triple::FreeBSD ||
Triple.getOS() == llvm::Triple::Solaris)
CmdArgs.push_back(-gdwarf-2);
+ SplitDwarfArg = nullptr;
} else if (A-getOption().matches(options::OPT_gdwarf_2))
CmdArgs.push_back(-gdwarf-2);
else if (A-getOption().matches(options::OPT_gdwarf_3))
@@ -3685,8 +3688,7 @@ void Clang::ConstructJob(Compilation C,
// -gsplit-dwarf should turn on -g and enable the backend dwarf
// splitting and extraction.
// FIXME: Currently only works on Linux.
- if (getToolChain().getTriple().isOSLinux()
- Args.hasArg(options::OPT_gsplit_dwarf)) {
+ if (getToolChain().getTriple().isOSLinux() SplitDwarfArg) {
CmdArgs.push_back(-g);
CmdArgs.push_back(-backend-option);
CmdArgs.push_back(-split-dwarf=Enable);
@@ -4970,8 +4972,7 @@ void Clang::ConstructJob(Compilation C,
// Add the split debug info name to the command lines here so we
// can propagate it to the backend.
- bool SplitDwarf = Args.hasArg(options::OPT_gsplit_dwarf)
-getToolChain().getTriple().isOSLinux()
+ bool SplitDwarf = SplitDwarfArg getToolChain().getTriple().isOSLinux()
(isaAssembleJobAction(JA) || isaCompileJobAction(JA) ||
isaBackendJobAction(JA));
const char *SplitDwarfOut;
Modified: cfe/trunk/test/Driver/split-debug.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/split-debug.c?rev=243694r1=243693r2=243694view=diff
==
--- cfe/trunk/test/Driver/split-debug.c (original)
+++ cfe/trunk/test/Driver/split-debug.c Thu Jul 30 16:42:22 2015
@@ -32,3 +32,20 @@
// RUN: FileCheck -check-prefix=CHECK-IAS %t %s
//
// CHECK-IAS: objcopy
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -gmlt -S -### %s
2 %t
+// RUN: FileCheck -check-prefix=CHECK-GMLT-OVER-SPLIT %t %s
+//
+// CHECK-GMLT-OVER-SPLIT: -gline-tables-only
+// CHECK-GMLT-OVER-SPLIT-NOT: -g
+// CHECK-GMLT-OVER-SPLIT-NOT: -split-dwarf=Enable
+// CHECK-GMLT-OVER-SPLIT-NOT: -split-dwarf-file
+
+// RUN: %clang -target x86_64-unknown-linux-gnu -gmlt -gsplit-dwarf -S -### %s
2 %t
+// RUN: FileCheck -check-prefix=CHECK-SPLIT-OVER-GMLT %t %s
+//
+// CHECK-SPLIT-OVER-GMLT-NOT: -gline-tables-only
+// CHECK-SPLIT-OVER-GMLT: -g
+// CHECK-SPLIT-OVER-GMLT: -split-dwarf=Enable
+// CHECK-SPLIT-OVER-GMLT: -split-dwarf-file
+// CHECK-SPLIT-OVER-GMLT-NOT: -gline-tables-only
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11670: [libcxx] Disable -Wnon-virtual-dtor warning in locale
On Thu, Jul 30, 2015 at 6:43 PM, Eric Fiselier e...@efcs.ca wrote:
EricWF created this revision.
EricWF added a reviewer: mclow.lists.
EricWF added a subscriber: cfe-commits.
Normally people won't see warnings in libc++ headers, but if they compile
with -Wsystem-headers -Wnon-virtual-dtor they will likely see issues in
locale.
The struct `time_get` is specified as having a non-virtual protected
destructor but in the libc++ implementation `time_get` also has a
non-virtual base class with virtual methods.
If the base class has a protected non-virtual dtor and the derived class is
marked final, this warning will not fire (because that interface will
ensure no polymorphic destruction occurs). Would that be sufficient for
your needs?
I don't believe this is a bug but instead a false positive.
http://reviews.llvm.org/D11670
Files:
include/__config
include/locale
Index: include/locale
===
--- include/locale
+++ include/locale
@@ -1875,6 +1875,11 @@
enum dateorder {no_order, dmy, mdy, ymd, ydm};
};
+#if __has_warning(-Wnon-virtual-dtor)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored -Wnon-virtual-dtor
+#endif
+
template class _CharT
class _LIBCPP_TYPE_VIS_ONLY __time_get_c_storage
{
@@ -1890,6 +1895,10 @@
virtual const string_type __X() const;
};
+#if __has_warning(-Wnon-virtual-dtor)
+#pragma clang diagnostic pop
+#endif
+
template class _CharT, class _InputIterator =
istreambuf_iterator_CharT
class _LIBCPP_TYPE_VIS_ONLY time_get
: public locale::facet,
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -45,6 +45,9 @@
#ifndef __is_identifier
#define __is_identifier(__x) 1
#endif
+#ifndef __has_warning
+#define __has_warning(__x) 0
+#endif
#ifdef __LITTLE_ENDIAN__
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11670: [libcxx] Disable -Wnon-virtual-dtor warning in locale
On Thu, Jul 30, 2015 at 9:58 PM, Eric Fiselier e...@efcs.ca wrote:
If the base class has a protected non-virtual dtor and the derived class
is marked final, this warning will not fire (because that interface will
ensure no
polymorphic destruction occurs). Would that be sufficient for your needs?
Oh, almost. I can't mark the derived class as final, but simply making
the base classes dtor protected prevents the warning. Thanks for the
information.
Awesome :)
On Thu, Jul 30, 2015 at 11:16 PM, David Blaikie dblai...@gmail.com
wrote:
On Thu, Jul 30, 2015 at 6:43 PM, Eric Fiselier e...@efcs.ca wrote:
EricWF created this revision.
EricWF added a reviewer: mclow.lists.
EricWF added a subscriber: cfe-commits.
Normally people won't see warnings in libc++ headers, but if they
compile
with -Wsystem-headers -Wnon-virtual-dtor they will likely see issues
in
locale.
The struct `time_get` is specified as having a non-virtual protected
destructor but in the libc++ implementation `time_get` also has a
non-virtual base class with virtual methods.
If the base class has a protected non-virtual dtor and the derived class
is
marked final, this warning will not fire (because that interface will
ensure
no polymorphic destruction occurs). Would that be sufficient for your
needs?
I don't believe this is a bug but instead a false positive.
http://reviews.llvm.org/D11670
Files:
include/__config
include/locale
Index: include/locale
===
--- include/locale
+++ include/locale
@@ -1875,6 +1875,11 @@
enum dateorder {no_order, dmy, mdy, ymd, ydm};
};
+#if __has_warning(-Wnon-virtual-dtor)
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored -Wnon-virtual-dtor
+#endif
+
template class _CharT
class _LIBCPP_TYPE_VIS_ONLY __time_get_c_storage
{
@@ -1890,6 +1895,10 @@
virtual const string_type __X() const;
};
+#if __has_warning(-Wnon-virtual-dtor)
+#pragma clang diagnostic pop
+#endif
+
template class _CharT, class _InputIterator =
istreambuf_iterator_CharT
class _LIBCPP_TYPE_VIS_ONLY time_get
: public locale::facet,
Index: include/__config
===
--- include/__config
+++ include/__config
@@ -45,6 +45,9 @@
#ifndef __is_identifier
#define __is_identifier(__x) 1
#endif
+#ifndef __has_warning
+#define __has_warning(__x) 0
+#endif
#ifdef __LITTLE_ENDIAN__
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r243425 - [CodeGen] Clean up CGBuiltin a bit.
On Tue, Jul 28, 2015 at 8:40 AM, Benjamin Kramer benny@googlemail.com
wrote:
Author: d0k
Date: Tue Jul 28 10:40:11 2015
New Revision: 243425
URL: http://llvm.org/viewvc/llvm-project?rev=243425view=rev
Log:
[CodeGen] Clean up CGBuiltin a bit.
- Use cached LLVM types
- Turn SmallVectors into Arrays/ArrayRef if the size is static
- Use ConstantInt::get's implicit splatting for vector types
No functionality change intended.
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=243425r1=243424r2=243425view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jul 28 10:40:11 2015
@@ -1940,10 +1940,7 @@ Value *CodeGenFunction::EmitNeonCall(Fun
Value *CodeGenFunction::EmitNeonShiftVector(Value *V, llvm::Type *Ty,
bool neg) {
int SV = castConstantInt(V)-getSExtValue();
-
- llvm::VectorType *VTy = castllvm::VectorType(Ty);
- llvm::Constant *C = ConstantInt::get(VTy-getElementType(), neg ? -SV :
SV);
- return llvm::ConstantVector::getSplat(VTy-getNumElements(), C);
+ return ConstantInt::get(Ty, neg ? -SV : SV);
}
// \brief Right-shift a vector by a constant.
@@ -1962,8 +1959,7 @@ Value *CodeGenFunction::EmitNeonRShiftIm
if (ShiftAmt == EltSize) {
if (usgn) {
// Right-shifting an unsigned value by its size yields 0.
- llvm::Constant *Zero = ConstantInt::get(VTy-getElementType(), 0);
- return llvm::ConstantVector::getSplat(VTy-getNumElements(), Zero);
+ return llvm::ConstantAggregateZero::get(VTy);
} else {
// Right-shifting a signed value by its size is equivalent
// to a shift of size-1.
@@ -2782,9 +2778,8 @@ Value *CodeGenFunction::EmitCommonNeonBu
Ops[0] = Builder.CreateAdd(Ops[0], Ops[1], vaddhn);
// %high = lshr 4 x i32 %sum, i32 16, i32 16, i32 16, i32 16
-Constant *ShiftAmt = ConstantInt::get(SrcTy-getElementType(),
- SrcTy-getScalarSizeInBits() / 2);
-ShiftAmt = ConstantVector::getSplat(VTy-getNumElements(), ShiftAmt);
+Constant *ShiftAmt =
+ConstantInt::get(SrcTy, SrcTy-getScalarSizeInBits() / 2);
Ops[0] = Builder.CreateLShr(Ops[0], ShiftAmt, vaddhn);
// %res = trunc 4 x i32 %high to 4 x i16
@@ -3019,14 +3014,10 @@ Value *CodeGenFunction::EmitCommonNeonBu
case NEON::BI__builtin_neon_vqdmlal_v:
case NEON::BI__builtin_neon_vqdmlsl_v: {
SmallVectorValue *, 2 MulOps(Ops.begin() + 1, Ops.end());
-Value *Mul = EmitNeonCall(CGM.getIntrinsic(LLVMIntrinsic, Ty),
- MulOps, vqdmlal);
-
-SmallVectorValue *, 2 AccumOps;
-AccumOps.push_back(Ops[0]);
-AccumOps.push_back(Mul);
-return EmitNeonCall(CGM.getIntrinsic(AltLLVMIntrinsic, Ty),
-AccumOps, NameHint);
+Ops[1] =
+EmitNeonCall(CGM.getIntrinsic(LLVMIntrinsic, Ty), MulOps,
vqdmlal);
+Ops.resize(2);
+return EmitNeonCall(CGM.getIntrinsic(AltLLVMIntrinsic, Ty), Ops,
NameHint);
}
case NEON::BI__builtin_neon_vqshl_n_v:
case NEON::BI__builtin_neon_vqshlq_n_v:
@@ -3101,9 +3092,8 @@ Value *CodeGenFunction::EmitCommonNeonBu
Ops[0] = Builder.CreateSub(Ops[0], Ops[1], vsubhn);
// %high = lshr 4 x i32 %sum, i32 16, i32 16, i32 16, i32 16
-Constant *ShiftAmt = ConstantInt::get(SrcTy-getElementType(),
- SrcTy-getScalarSizeInBits() / 2);
-ShiftAmt = ConstantVector::getSplat(VTy-getNumElements(), ShiftAmt);
+Constant *ShiftAmt =
+ConstantInt::get(SrcTy, SrcTy-getScalarSizeInBits() / 2);
Ops[0] = Builder.CreateLShr(Ops[0], ShiftAmt, vsubhn);
// %res = trunc 4 x i32 %high to 4 x i16
@@ -3252,33 +3242,37 @@ static Value *packTBLDVectorList(CodeGen
}
Value *CodeGenFunction::GetValueForARMHint(unsigned BuiltinID) {
+ unsigned Value;
switch (BuiltinID) {
default:
return nullptr;
case ARM::BI__builtin_arm_nop:
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_hint),
- llvm::ConstantInt::get(Int32Ty, 0));
+Value = 0;
+break;
case ARM::BI__builtin_arm_yield:
case ARM::BI__yield:
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_hint),
- llvm::ConstantInt::get(Int32Ty, 1));
+Value = 1;
+break;
case ARM::BI__builtin_arm_wfe:
case ARM::BI__wfe:
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_hint),
- llvm::ConstantInt::get(Int32Ty, 2));
+Value = 2;
+break;
case ARM::BI__builtin_arm_wfi:
case ARM::BI__wfi:
-return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_hint),
-
Re: [PATCH] Have clang list the imported modules in the debug info
*reads back through the thread* So what I originally had in mind about a year ago when we discussed this, was that the module data could have an extra table from type hash to whatever useful internal representation to find the type in the PCM. Everything else would just be DWARF with type units and fission (with the slight wrinkle of type units that aren't resolvable within a single object file - they could reference cross-object/dwo file) - emitting a fission CU for each referenced module. Needing modules to disambiguate/avoid collisions/support non-odr languages wasn't something I understood/had considered back then. That explains the need to add module references to the CU, so the debugger can know which modules to search for the types in ( doesn't just go loading all of them, etc). I would still picture this as normal type units + a table in the module to resolve types, but if you guys particularly like using the mangled string name (or other identifier) in the DWARF that may avoid the need for an intermediate table (but it doesn't sound like you are avoiding an intermediate table - you said something about having an accelerator-table-like thing to aid in the DWARF-AST mapping? So could that be key'd of the type hash/signature we're using, thus keeping the DWARF more plain/vanilla DWARF5 (type units + fission)?) - Dave On Wed, May 6, 2015 at 3:43 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 3:24 PM, David Blaikie dblai...@gmail.com wrote: On Wed, May 6, 2015 at 3:15 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 2:52 PM, David Blaikie dblai...@gmail.com wrote: On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 2:35 PM, Eric Christopher echri...@gmail.com wrote: That said, add enough to the name for hashing purposes to make it hash uniquely? Or you can go down the path of hashing the type similar to the fission CU hashing (which is what type units were arguably designed to do in the first place if you take a look at the standard, we just only use them for ODR compliant languages etc right now). I suppose one could hash the entire module configuration + the mangled name and get something that is relatively stable. For implementation reasons it would be terrible to do the full fission hashing because that would mean that we would actually have to look up (and deserialize the type) in order to get to its ID when emitting an external type reference, which would void at least some of the performance gains we want from module debugging. I thought you were proposing using the mangled name of the type for the identifier anyway? Perhaps I misunderstood - what are you proposing to use? In any case, I'd prefer to see whatever it is hashed and used as the type unit signature for compatibility with DWARF5, rather than adding an extra/separate/new/non-standard way to do cross-unit/cross-fission type references. In the IR I’d /like/ to have a DIExternalTypeRef(DW_TAG_class_type, !”_ZTC6TypeName”, !1) with !1 being a reference to either the DIModule or the skeleton CU. Then the backend would emit the hash of the name if type units are enabled (C++/gdb) or the mangled name (+ the accelerator table entry) otherwise (ObjC and/or Darwin). If there is significant pushback to the latter, I’d be willing to have the backend emit a hash in both cases but we’d have to careful about what to exactly to hash for all the aforementioned reasons. I don't follow - if the mangled name is sufficient, then a hash of the mangled name should be what am I missing? Nothing, these are two separate issues: If you don't have an ODR to rely on, then a mangled name seems insufficient just as the hash would be. The decision for mangled name vs hash is motivated by the mangled name also doubling as a key to look up the type in the AST. The other problem is (partially) solved by the accelerator table entry that associates the mangled name with a module. I’m starting to think now that it might be better to include a fission-style forward declaration + decl context into the TAG_module instead. The DWARF-style decl context could in theory be smaller than the mangled name because two types could share common ancestors and then we could emit the same hash of the mangled names as we do for type units. But let’s discuss this when it comes up (together with the patch that makes use of DIExternalTypeRef). -- adrian ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r242824 - Pass an iterator range to EmitCallArgs
Author: dblaikie
Date: Tue Jul 21 13:37:18 2015
New Revision: 242824
URL: http://llvm.org/viewvc/llvm-project?rev=242824view=rev
Log:
Pass an iterator range to EmitCallArgs
Modified:
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/include/clang/AST/ExprObjC.h
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=242824r1=242823r2=242824view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Tue Jul 21 13:37:18 2015
@@ -1821,6 +1821,14 @@ public:
typedef ExprIterator arg_iterator;
typedef ConstExprIterator const_arg_iterator;
+ llvm::iterator_rangearg_iterator placement_arguments() {
+return llvm::make_range(placement_arg_begin(), placement_arg_end());
+ }
+
+ llvm::iterator_rangeconst_arg_iterator placement_arguments() const {
+return llvm::make_range(placement_arg_begin(), placement_arg_end());
+ }
+
arg_iterator placement_arg_begin() {
return SubExprs + Array + hasInitializer();
}
Modified: cfe/trunk/include/clang/AST/ExprObjC.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprObjC.h?rev=242824r1=242823r2=242824view=diff
==
--- cfe/trunk/include/clang/AST/ExprObjC.h (original)
+++ cfe/trunk/include/clang/AST/ExprObjC.h Tue Jul 21 13:37:18 2015
@@ -1360,6 +1360,14 @@ public:
typedef ExprIterator arg_iterator;
typedef ConstExprIterator const_arg_iterator;
+ llvm::iterator_rangearg_iterator arguments() {
+return llvm::make_range(arg_begin(), arg_end());
+ }
+
+ llvm::iterator_rangeconst_arg_iterator arguments() const {
+return llvm::make_range(arg_begin(), arg_end());
+ }
+
arg_iterator arg_begin() { return reinterpret_castStmt **(getArgs()); }
arg_iterator arg_end() {
return reinterpret_castStmt **(getArgs() + NumArgs);
Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBlocks.cpp?rev=242824r1=242823r2=242824view=diff
==
--- cfe/trunk/lib/CodeGen/CGBlocks.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBlocks.cpp Tue Jul 21 13:37:18 2015
@@ -978,8 +978,7 @@ RValue CodeGenFunction::EmitBlockCallExp
QualType FnType = BPT-getPointeeType();
// And the rest of the arguments.
- EmitCallArgs(Args, FnType-getAsFunctionProtoType(),
- E-arg_begin(), E-arg_end());
+ EmitCallArgs(Args, FnType-getAsFunctionProtoType(), E-arguments());
// Load the function.
llvm::Value *Func = Builder.CreateLoad(FuncPtr);
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=242824r1=242823r2=242824view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Jul 21 13:37:18 2015
@@ -2808,12 +2808,11 @@ void CodeGenFunction::EmitNonNullArgChec
nonnull_arg, StaticData, None);
}
-void CodeGenFunction::EmitCallArgs(CallArgList Args,
- ArrayRefQualType ArgTypes,
- CallExpr::const_arg_iterator ArgBeg,
- CallExpr::const_arg_iterator ArgEnd,
- const FunctionDecl *CalleeDecl,
- unsigned ParamsToSkip) {
+void CodeGenFunction::EmitCallArgs(
+CallArgList Args, ArrayRefQualType ArgTypes,
+llvm::iterator_rangeCallExpr::const_arg_iterator ArgRange,
+const FunctionDecl *CalleeDecl, unsigned ParamsToSkip) {
+ assert((int)ArgTypes.size() == (ArgRange.end() - ArgRange.begin()));
// We *have* to evaluate arguments from right to left in the MS C++ ABI,
// because arguments are destroyed left to right in the callee.
if (CGM.getTarget().getCXXABI().areArgsDestroyedLeftToRightInCallee()) {
@@ -2830,7 +2829,7 @@ void CodeGenFunction::EmitCallArgs(CallA
// Evaluate each argument.
size_t CallArgsStart = Args.size();
for (int I = ArgTypes.size() - 1; I = 0; --I) {
- CallExpr::const_arg_iterator Arg = ArgBeg + I;
+ CallExpr::const_arg_iterator Arg = ArgRange.begin() + I;
EmitCallArg(Args, *Arg, ArgTypes[I]);
EmitNonNullArgCheck(Args.back().RV, ArgTypes[I], (*Arg)-getExprLoc(),
CalleeDecl, ParamsToSkip + I);
@@ -2843,8 +2842,8 @@ void
r242826 - Fix GCC build due to shadowing
Author: dblaikie Date: Tue Jul 21 13:59:10 2015 New Revision: 242826 URL: http://llvm.org/viewvc/llvm-project?rev=242826view=rev Log: Fix GCC build due to shadowing Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=242826r1=242825r2=242826view=diff == --- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original) +++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Tue Jul 21 13:59:10 2015 @@ -3006,8 +3006,8 @@ public: Extra arguments in non-variadic function!); // If we still have any arguments, emit them using the type of the argument. -for (auto *Arg : llvm::make_range(Arg, ArgRange.end())) - ArgTypes.push_back(getVarArgType(Arg)); +for (auto *A : llvm::make_range(Arg, ArgRange.end())) + ArgTypes.push_back(getVarArgType(A)); EmitCallArgs(Args, ArgTypes, ArgRange, CalleeDecl, ParamsToSkip); } ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r242826 - Fix GCC build due to shadowing
On Tue, Jul 21, 2015 at 12:31 PM, Pete Cooper peter_coo...@apple.com wrote: Do you think this happens enough that it should be issued by clang with -Wcompat? I haven't really looked at what else we put under that flag, if anything - so I'm not sure if this would fit/meet the bar. I'm personally not too fussed by it. I just consider non-clang builds of clang to be things we need to maintain, but not things we need to worry about too much. So I'm usually OK with breaking GCC and MSVC buildbots and fixing forwards for these little incompatibilities. - Dave Cheers, Pete On Jul 21, 2015, at 11:59 AM, David Blaikie dblai...@gmail.com wrote: Author: dblaikie Date: Tue Jul 21 13:59:10 2015 New Revision: 242826 URL: http://llvm.org/viewvc/llvm-project?rev=242826view=rev Log: Fix GCC build due to shadowing Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=242826r1=242825r2=242826view=diff == --- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original) +++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Tue Jul 21 13:59:10 2015 @@ -3006,8 +3006,8 @@ public: Extra arguments in non-variadic function!); // If we still have any arguments, emit them using the type of the argument. -for (auto *Arg : llvm::make_range(Arg, ArgRange.end())) - ArgTypes.push_back(getVarArgType(Arg)); +for (auto *A : llvm::make_range(Arg, ArgRange.end())) + ArgTypes.push_back(getVarArgType(A)); EmitCallArgs(Args, ArgTypes, ArgRange, CalleeDecl, ParamsToSkip); } ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11085: compiler-rt: add support for mingw-w64 in builtins
As phab suggests, you probably want to restart the review if you didn't add a community list at the time of creation. Phab only sends the initial summary email with details and attached patch on that first mailing so the list still has no context here. On Jul 17, 2015 2:35 AM, Martell Malone martellmal...@gmail.com wrote: martell added a comment. Added cfe-commits so that people can actually see the patch on the lists :) Hopefully someone will consider merging this http://reviews.llvm.org/D11085 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11085: compiler-rt: add support for mingw-w64 in builtins
dblaikie added a subscriber: dblaikie. dblaikie added a comment. As phab suggests, you probably want to restart the review if you didn't add a community list at the time of creation. Phab only sends the initial summary email with details and attached patch on that first mailing so the list still has no context here. http://reviews.llvm.org/D11085 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] D11280: [CUDA] Improve CUDA compilation pipeline creation.
dblaikie added a subscriber: dblaikie. dblaikie added a comment. Manuel - just got this private email from Phab. Seems that should've gone to all the subscribers ended up on the mailing list, but didn't? http://reviews.llvm.org/D11280 ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241620 - Wrap clang modules and pch files in an object file container.
On Mon, Jul 13, 2015 at 7:25 PM, Richard Smith rich...@metafoo.co.uk wrote: On Mon, Jul 13, 2015 at 6:02 PM, Adrian Prantl apra...@apple.com wrote: On Jul 13, 2015, at 5:47 PM, Richard Smith rich...@metafoo.co.uk wrote: On Mon, Jul 13, 2015 at 3:06 PM, Adrian Prantl apra...@apple.com wrote: On Jul 13, 2015, at 2:00 PM, Eric Christopher echri...@gmail.com wrote: Hi Adrian, Finally getting around to looking at some of this and I think it's going in slightly the wrong direction. In general I think begin -able- to put modules in object files to simplify wrapping, use, etc is a good thing. I think being required to do so is somewhat problematic. Let me start with that the current infrastructure already allows selecting whether you want wrapped modules or not by passing the appropriate PCHContainerOperations object to CompilerInstance. Clang currently unconditionally uses an object file wrapper, all of clang-tools-extra doesn’t. We could easily control the behavior of clang based on a (new) command line option. But.. on a platform with a shared module cache you always have to assume that a module once built will eventually be used by a client that wants to read the debug info. Think llvm-dsymutil — it does not know and does not want to know how to build clang modules, but does want to read all the debug info from a clang module. Imagine, for example, you have a giant distributed build system... You'd want to create a pile of modules (that may reference/include/etc other modules) that aren't don't or may not have debug information as part of them (because you might want to build without it or have the debug info alongside it as a separate compilation). Waiting on the full build of the module including debug is going to adversely affect your overall build time and so shouldn't be necessary - especially if you want to be able to have information separate ultimately. Make sense? Not sure if you would be saving much by having the debug info separately, from what I’ve measured so far the debug info for a module makes up less than 10% of the total size. Admittedly, build-time-wise going through the backend to emit the object file is a lot more expensive than just dumping the raw PCH. [1] Yeah, I think wanting to be able to control the behavior is reasonable, we just need to be careful what the implications for consumers are. If we add a, e.g., an “-fraw-modules” [2] or switch to clang to turn off the object file wrapping, I’d strongly suggest that we add the value of this switch to the module hash (or add a an optional “-g” to the module file name after the hash or something like that) to avoid ugly race conditions between debug info and non-debug-info builds of the same module. This way we’d have essentially two separate module caches, with and without debug info. That's fine, I think (we don't use a module cache at all in our build system; it doesn't really make much sense for a distributed build) and most command-line flag changes already have this effect. Great! would that work for you? -- adrian [1] If you want to be serious about building the module debug info in parallel to the rest of the build, you could even have a clang-based tool import the just-built raw clang module and emit the debug info without having to parse the headers again :-) That is what we intend to do :) (Assuming this turns out to actually be faster than re-parsing; faulting in the entire contents of a module has much worse locality than parsing.) [2] -fraw-modules, -fmodule-format-raw, -fmodule-debug-info, ...? I would imagine that the driver enables module debug info when -gmodules” is present and by default on Darwin. That seems reasonable to me. For the frontend flag, I think a flag to turn this on or to select the module format makes more sense than a flag to switch to the raw format. Okay then let’s narrow this down. Other possibilities in that direction include (sorted from subjectively best to worst) -fmodule-format=obj -fmodule-debug-info -ffat-modules -fmodule-container -fmodule-container-object It's a -cc1 flag, so it doesn't really matter much. If this will eventually govern whether we put code for inline functions into the module, then I think we should avoid names like -fmodule-debug-info. Other than that, I don't really have a preference. What you're picturing there is essentially a flag that would indicate if we should build all module-related-object-things into the module, or not? That seems like a useful broad flag (with an eventual corresponding compiler mode where we pass another flag and explicitly pass just the module and say build a separate object with all the module-related-object-things - for use in a non-implicit-cache build) (Hmm, we're going to have a weird middle ground in here - where the IR for the inline functions needs to go in the module itself (as an available_externally definition
Re: r241620 - Wrap clang modules and pch files in an object file container.
On Tue, Jul 14, 2015 at 9:55 AM, Adrian Prantl apra...@apple.com wrote: On Jul 14, 2015, at 8:25 AM, David Blaikie dblai...@gmail.com wrote: On Mon, Jul 13, 2015 at 7:25 PM, Richard Smith rich...@metafoo.co.uk wrote: On Mon, Jul 13, 2015 at 6:02 PM, Adrian Prantl apra...@apple.com wrote: On Jul 13, 2015, at 5:47 PM, Richard Smith rich...@metafoo.co.uk wrote: On Mon, Jul 13, 2015 at 3:06 PM, Adrian Prantl apra...@apple.com wrote: On Jul 13, 2015, at 2:00 PM, Eric Christopher echri...@gmail.com wrote: Hi Adrian, Finally getting around to looking at some of this and I think it's going in slightly the wrong direction. In general I think begin -able- to put modules in object files to simplify wrapping, use, etc is a good thing. I think being required to do so is somewhat problematic. Let me start with that the current infrastructure already allows selecting whether you want wrapped modules or not by passing the appropriate PCHContainerOperations object to CompilerInstance. Clang currently unconditionally uses an object file wrapper, all of clang-tools-extra doesn’t. We could easily control the behavior of clang based on a (new) command line option. But.. on a platform with a shared module cache you always have to assume that a module once built will eventually be used by a client that wants to read the debug info. Think llvm-dsymutil — it does not know and does not want to know how to build clang modules, but does want to read all the debug info from a clang module. Imagine, for example, you have a giant distributed build system... You'd want to create a pile of modules (that may reference/include/etc other modules) that aren't don't or may not have debug information as part of them (because you might want to build without it or have the debug info alongside it as a separate compilation). Waiting on the full build of the module including debug is going to adversely affect your overall build time and so shouldn't be necessary - especially if you want to be able to have information separate ultimately. Make sense? Not sure if you would be saving much by having the debug info separately, from what I’ve measured so far the debug info for a module makes up less than 10% of the total size. Admittedly, build-time-wise going through the backend to emit the object file is a lot more expensive than just dumping the raw PCH. [1] Yeah, I think wanting to be able to control the behavior is reasonable, we just need to be careful what the implications for consumers are. If we add a, e.g., an “-fraw-modules” [2] or switch to clang to turn off the object file wrapping, I’d strongly suggest that we add the value of this switch to the module hash (or add a an optional “-g” to the module file name after the hash or something like that) to avoid ugly race conditions between debug info and non-debug-info builds of the same module. This way we’d have essentially two separate module caches, with and without debug info. That's fine, I think (we don't use a module cache at all in our build system; it doesn't really make much sense for a distributed build) and most command-line flag changes already have this effect. Great! would that work for you? -- adrian [1] If you want to be serious about building the module debug info in parallel to the rest of the build, you could even have a clang-based tool import the just-built raw clang module and emit the debug info without having to parse the headers again :-) That is what we intend to do :) (Assuming this turns out to actually be faster than re-parsing; faulting in the entire contents of a module has much worse locality than parsing.) [2] -fraw-modules, -fmodule-format-raw, -fmodule-debug-info, ...? I would imagine that the driver enables module debug info when -gmodules” is present and by default on Darwin. That seems reasonable to me. For the frontend flag, I think a flag to turn this on or to select the module format makes more sense than a flag to switch to the raw format. Okay then let’s narrow this down. Other possibilities in that direction include (sorted from subjectively best to worst) -fmodule-format=obj -fmodule-debug-info -ffat-modules -fmodule-container -fmodule-container-object It's a -cc1 flag, so it doesn't really matter much. If this will eventually govern whether we put code for inline functions into the module, then I think we should avoid names like -fmodule-debug-info. Other than that, I don't really have a preference. Unless the “=“ part turns out to be an implementation nightmare, I think I’ll be going with -fmodule-format=[raw,obj] then and implicitly emit debug info in the obj case. If necessary, we can make this more fine grained later. What you're picturing there is essentially a flag that would indicate if we should build all module-related-object-things into the module, or not? That seems like a useful broad flag
r242168 - Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg functions
Author: dblaikie
Date: Tue Jul 14 12:27:39 2015
New Revision: 242168
URL: http://llvm.org/viewvc/llvm-project?rev=242168view=rev
Log:
Rely on default zero-arg value for IRBuilder::CreateCall calls to zero-arg
functions
Patch by servuswiegehtz at yahoo.de
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/CodeGen/CGObjCRuntime.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=242168r1=242167r2=242168view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Jul 14 12:27:39 2015
@@ -535,7 +535,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(
}
case Builtin::BI__builtin_readcyclecounter: {
Value *F = CGM.getIntrinsic(Intrinsic::readcyclecounter);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__builtin___clear_cache: {
Value *Begin = EmitScalarExpr(E-getArg(0));
@@ -923,7 +923,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(
}
case Builtin::BI__builtin_unwind_init: {
Value *F = CGM.getIntrinsic(Intrinsic::eh_unwind_init);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__builtin_extend_pointer: {
// Extends a pointer to the size of an _Unwind_Word, which is
@@ -962,7 +962,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(
// Store the stack pointer to the setjmp buffer.
Value *StackAddr =
-Builder.CreateCall(CGM.getIntrinsic(Intrinsic::stacksave), {});
+Builder.CreateCall(CGM.getIntrinsic(Intrinsic::stacksave));
Value *StackSaveSlot =
Builder.CreateGEP(Buf, ConstantInt::get(Int32Ty, 2));
Builder.CreateStore(StackAddr, StackSaveSlot);
@@ -3399,7 +3399,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
: InlineAsm::get(FTy, .inst 0x + utohexstr(ZExtValue), ,
/*SideEffects=*/true);
-return Builder.CreateCall(Emit, {});
+return Builder.CreateCall(Emit);
}
if (BuiltinID == ARM::BI__builtin_arm_dbg) {
@@ -3543,7 +3543,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
if (BuiltinID == ARM::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::arm_clrex);
-return Builder.CreateCall(F, {});
+return Builder.CreateCall(F);
}
// CRC32
@@ -4339,7 +4339,7 @@ Value *CodeGenFunction::EmitAArch64Built
if (BuiltinID == AArch64::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::aarch64_clrex);
-return Builder.CreateCall(F, {});
+return Builder.CreateCall(F);
}
// CRC32
@@ -6375,7 +6375,7 @@ Value *CodeGenFunction::EmitX86BuiltinEx
break;
}
-Value *Call = Builder.CreateCall(CGM.getIntrinsic(ID), {});
+Value *Call = Builder.CreateCall(CGM.getIntrinsic(ID));
Builder.CreateStore(Builder.CreateExtractValue(Call, 0), Ops[0]);
return Builder.CreateExtractValue(Call, 1);
}
Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=242168r1=242167r2=242168view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Tue Jul 14 12:27:39 2015
@@ -988,7 +988,7 @@ CodeGenFunction::EmitAutoVarAlloca(const
llvm::Value *Stack = CreateTempAlloca(Int8PtrTy, saved_stack);
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::stacksave);
- llvm::Value *V = Builder.CreateCall(F, {});
+ llvm::Value *V = Builder.CreateCall(F);
Builder.CreateStore(V, Stack);
Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=242168r1=242167r2=242168view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Tue Jul 14 12:27:39 2015
@@ -1311,7 +1311,7 @@ struct PerformSEHFinally : EHScopeStack:
// Compute the two argument values.
QualType ArgTys[2] = {Context.UnsignedCharTy, Context.VoidPtrTy};
llvm::Value *LocalAddrFn = CGM.getIntrinsic(llvm::Intrinsic::localaddress);
-llvm::Value *FP = CGF.Builder.CreateCall(LocalAddrFn, {});
+llvm::Value *FP = CGF.Builder.CreateCall(LocalAddrFn);
llvm::Value *IsForEH =
llvm::ConstantInt::get(CGF.ConvertType(ArgTys[0]), F.isForEHCleanup());
Args.add(RValue::get(IsForEH), ArgTys[0]);
Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL:
Re: r241534 - Debug info: Emit distinct __block_literal_generic types for blocks with
On Mon, Jul 6, 2015 at 5:49 PM, Adrian Prantl apra...@apple.com wrote:
Author: adrian
Date: Mon Jul 6 19:49:35 2015
New Revision: 241534
URL: http://llvm.org/viewvc/llvm-project?rev=241534view=rev
Log:
Debug info: Emit distinct __block_literal_generic types for blocks with
different function signatures. (Previously clang would emit all block
pointer types with the type of the first block pointer in the compile
unit.)
rdar://problem/21602473
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/test/CodeGen/debug-info-block.c
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=241534r1=241533r2=241534view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Jul 6 19:49:35 2015
@@ -705,9 +705,6 @@ llvm::DIType *CGDebugInfo::getOrCreateSt
llvm::DIType *CGDebugInfo::CreateType(const BlockPointerType *Ty,
llvm::DIFile *Unit) {
- if (BlockLiteralGeneric)
-return BlockLiteralGeneric;
-
SmallVectorllvm::Metadata *, 8 EltTys;
QualType FType;
uint64_t FieldSize, FieldOffset;
@@ -753,12 +750,15 @@ llvm::DIType *CGDebugInfo::CreateType(co
FieldOffset += FieldSize;
Elements = DBuilder.getOrCreateArray(EltTys);
+ // The __block_literal_generic structs are marked with a special
+ // DW_AT_APPLE_BLOCK attribute and are an implementation detail only
+ // the debugger needs to know about. To allow type uniquing, emit
+ // them without a name or a location.
EltTy =
- DBuilder.createStructType(Unit, __block_literal_generic, nullptr,
LineNo,
+ DBuilder.createStructType(Unit, , nullptr, LineNo,
FieldOffset, 0, Flags, nullptr, Elements);
- BlockLiteralGeneric = DBuilder.createPointerType(EltTy, Size);
- return BlockLiteralGeneric;
+ return DBuilder.createPointerType(EltTy, Size);
What about two of the same? I assume that hits the type cache long before
this doesn't produce duplicate type metadata?
}
llvm::DIType *CGDebugInfo::CreateType(const TemplateSpecializationType
*Ty,
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=241534r1=241533r2=241534view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Mon Jul 6 19:49:35 2015
@@ -65,7 +65,6 @@ class CGDebugInfo {
llvm::DIType *OCLImage2dArrayDITy = nullptr;
llvm::DIType *OCLImage3dDITy = nullptr;
llvm::DIType *OCLEventDITy = nullptr;
- llvm::DIType *BlockLiteralGeneric = nullptr;
/// \brief Cache of previously constructed Types.
llvm::DenseMapconst void *, llvm::TrackingMDRef TypeCache;
Modified: cfe/trunk/test/CodeGen/debug-info-block.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-info-block.c?rev=241534r1=241533r2=241534view=diff
==
--- cfe/trunk/test/CodeGen/debug-info-block.c (original)
+++ cfe/trunk/test/CodeGen/debug-info-block.c Mon Jul 6 19:49:35 2015
@@ -2,11 +2,28 @@
// Verify that the desired debugging type is generated for a structure
// member that is a pointer to a block.
-// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name:
__block_literal_generic
-// CHECK-NOT: line
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, scope
+// CHECK-NOT: line
+// CHECK-SAME: elements: ![[ELEMS1:.*]])
+// CHECK: ![[ELEMS1]] = {{.*, .*, .*,}} ![[FPEL1:.*]], {{.*}}
+// CHECK: ![[INT:.*]] = !DIBasicType(name: int
+// CHECK: ![[FPEL1]] = {{.*}}__FuncPtr, {{.*}}, baseType:
![[FPTY1:[0-9]+]]
+// CHECK: ![[FPTY1]] = {{.*}}baseType: ![[FNTY1:[0-9]+]]
+// CHECK: ![[FNTY1]] = !DISubroutineType(types: ![[VOIDVOID:[0-9]+]])
+// CHECK: ![[VOIDVOID]] = !{null, null}
// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name:
__block_descriptor
-// CHECK-NOT: line
+// CHECK-NOT: line
+// CHECK-SAME:)
+
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, scope
+// CHECK-NOT: line
+// CHECK-SAME: elements: ![[ELEMS2:.*]])
+// CHECK: ![[ELEMS2]] = {{.*,.*,.*}}, ![[FPEL2:.*]], {{.*}}
+// CHECK: ![[FPEL2]] = {{.*}}__FuncPtr, {{.*}}, baseType:
![[FPTY2:[0-9]+]]
+// CHECK: ![[FPTY2]] = {{.*}}baseType: ![[FNTY2:[0-9]+]]
+// CHECK: ![[FNTY2]] = !DISubroutineType(types: ![[INTINT:[0-9]+]])
+// CHECK: ![[INTINT]] = !{![[INT]], ![[INT]]}
struct inStruct {
- void (^genericBlockPtr)();
+ void (^voidBlockPtr)();
+ int (^intBlockPtr)(int);
} is;
-
___
Re: r241467 - Resubmit Pass down the -flto option to the -cc1 job (r239481)
I think I probably asked this before - but just to check, the reason these definitions are left in is because the actual external definition may not be in the lto build? (Otherwise you could drop the available externally definition in each object/bitcode file and know that you could clone it from the actual external definition during lto time?) When does this come up (where do we get these available externally definitions at compile time? From c99 extern inline? Does it come up that the true extern definition is not in the lto scope?) On Jul 6, 2015 9:28 AM, Teresa Johnson tejohn...@google.com wrote: Author: tejohnson Date: Mon Jul 6 11:23:00 2015 New Revision: 241467 URL: http://llvm.org/viewvc/llvm-project?rev=241467view=rev Log: Resubmit Pass down the -flto option to the -cc1 job (r239481) The patch is the same except for the addition of a new test for the issue that required reverting the dependent llvm commit. --Original Commit Message-- Pass down the -flto option to the -cc1 job, and from there into the CodeGenOptions and onto the PassManagerBuilder. This enables gating the new EliminateAvailableExternally module pass on whether we are preparing for LTO. If we are preparing for LTO (e.g. a -flto -c compile), the new pass is not included as we want to preserve available externally functions for possible link time inlining. Added: cfe/trunk/test/CodeGen/available-externally-hidden.cpp Modified: cfe/trunk/include/clang/Driver/Options.td cfe/trunk/include/clang/Frontend/CodeGenOptions.def cfe/trunk/lib/CodeGen/BackendUtil.cpp cfe/trunk/lib/Driver/Tools.cpp cfe/trunk/lib/Frontend/CompilerInvocation.cpp cfe/trunk/test/CodeGen/available-externally-suppress.c Modified: cfe/trunk/include/clang/Driver/Options.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=241467r1=241466r2=241467view=diff == --- cfe/trunk/include/clang/Driver/Options.td (original) +++ cfe/trunk/include/clang/Driver/Options.td Mon Jul 6 11:23:00 2015 @@ -641,7 +641,7 @@ def flat__namespace : Flag[-], flat_ def flax_vector_conversions : Flag[-], flax-vector-conversions, Groupf_Group; def flimited_precision_EQ : Joined[-], flimited-precision=, Groupf_Group; def flto_EQ : Joined[-], flto=, Groupclang_ignored_gcc_optimization_f_Group; -def flto : Flag[-], flto, Groupf_Group; +def flto : Flag[-], flto, Flags[CC1Option], Groupf_Group; def fno_lto : Flag[-], fno-lto, Groupf_Group; def fmacro_backtrace_limit_EQ : Joined[-], fmacro-backtrace-limit=, Groupf_Group, Flags[DriverOption, CoreOption]; Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=241467r1=241466r2=241467view=diff == --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original) +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Jul 6 11:23:00 2015 @@ -67,6 +67,8 @@ CODEGENOPT(InstrumentFunctions , 1, 0) / CODEGENOPT(InstrumentForProfiling , 1, 0) /// Set when -pg is enabled. CODEGENOPT(LessPreciseFPMAD , 1, 0) /// Enable less precise MAD instructions to /// be generated. +CODEGENOPT(PrepareForLTO , 1, 0) /// Set when -flto is enabled on the + /// compile step. CODEGENOPT(MergeAllConstants , 1, 1) /// Merge identical constants. CODEGENOPT(MergeFunctions, 1, 0) /// Set when -fmerge-functions is enabled. CODEGENOPT(MSVolatile, 1, 0) /// Set when /volatile:ms is enabled. Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=241467r1=241466r2=241467view=diff == --- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original) +++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jul 6 11:23:00 2015 @@ -292,6 +292,7 @@ void EmitAssemblyHelper::CreatePasses() PMBuilder.DisableUnitAtATime = !CodeGenOpts.UnitAtATime; PMBuilder.DisableUnrollLoops = !CodeGenOpts.UnrollLoops; PMBuilder.MergeFunctions = CodeGenOpts.MergeFunctions; + PMBuilder.PrepareForLTO = CodeGenOpts.PrepareForLTO; PMBuilder.RerollLoops = CodeGenOpts.RerollLoops; PMBuilder.addExtension(PassManagerBuilder::EP_EarlyAsPossible, Modified: cfe/trunk/lib/Driver/Tools.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=241467r1=241466r2=241467view=diff == --- cfe/trunk/lib/Driver/Tools.cpp (original) +++ cfe/trunk/lib/Driver/Tools.cpp Mon Jul 6 11:23:00 2015 @@ -2805,6 +2805,10 @@ void Clang::ConstructJob(Compilation
Re: [clang-tools-extra] r241335 - Revert r241330. It compiled with Visual C++ 2013 and gcc 4.9.1 (mingw) but now fails the bots.
On Fri, Jul 3, 2015 at 2:30 AM, Yaron Keren yaron.ke...@gmail.com wrote:
Author: yrnkrn
Date: Fri Jul 3 04:30:33 2015
New Revision: 241335
URL: http://llvm.org/viewvc/llvm-project?rev=241335view=rev
Log:
Revert r241330. It compiled with Visual C++ 2013 and gcc 4.9.1 (mingw) but
now fails the bots.
Got a link to the buildbot failure or copy/paste the error message(s) from
them?
Modified:
clang-tools-extra/trunk/clang-modernize/LoopConvert/StmtAncestor.h
clang-tools-extra/trunk/clang-rename/RenamingAction.cpp
clang-tools-extra/trunk/clang-rename/RenamingAction.h
clang-tools-extra/trunk/modularize/Modularize.cpp
clang-tools-extra/trunk/pp-trace/PPCallbacksTracker.cpp
clang-tools-extra/trunk/pp-trace/PPCallbacksTracker.h
Modified:
clang-tools-extra/trunk/clang-modernize/LoopConvert/StmtAncestor.h
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-modernize/LoopConvert/StmtAncestor.h?rev=241335r1=241334r2=241335view=diff
==
--- clang-tools-extra/trunk/clang-modernize/LoopConvert/StmtAncestor.h
(original)
+++ clang-tools-extra/trunk/clang-modernize/LoopConvert/StmtAncestor.h Fri
Jul 3 04:30:33 2015
@@ -170,9 +170,9 @@ private:
class DeclFinderASTVisitor :
public clang::RecursiveASTVisitorDeclFinderASTVisitor {
public:
- DeclFinderASTVisitor(std::string Name,
- const StmtGeneratedVarNameMap *GeneratedDecls)
- : Name(std::move(Name)), GeneratedDecls(GeneratedDecls),
Found(false) {}
+ DeclFinderASTVisitor(const std::string Name,
+ const StmtGeneratedVarNameMap *GeneratedDecls) :
+Name(Name), GeneratedDecls(GeneratedDecls), Found(false) { }
/// Attempts to find any usages of variables name Name in Body,
returning
/// true when it is used in Body. This includes the generated loop
variables
Modified: clang-tools-extra/trunk/clang-rename/RenamingAction.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/RenamingAction.cpp?rev=241335r1=241334r2=241335view=diff
==
--- clang-tools-extra/trunk/clang-rename/RenamingAction.cpp (original)
+++ clang-tools-extra/trunk/clang-rename/RenamingAction.cpp Fri Jul 3
04:30:33 2015
@@ -37,11 +37,14 @@ namespace rename {
class RenamingASTConsumer : public ASTConsumer {
public:
- RenamingASTConsumer(StringRef NewName, StringRef PrevName,
+ RenamingASTConsumer(const std::string NewName,
+ const std::string PrevName,
const std::vectorstd::string USRs,
- tooling::Replacements Replaces, bool
PrintLocations)
+ tooling::Replacements Replaces,
+ bool PrintLocations)
: NewName(NewName), PrevName(PrevName), USRs(USRs),
Replaces(Replaces),
-PrintLocations(PrintLocations) {}
+PrintLocations(PrintLocations) {
+ }
void HandleTranslationUnit(ASTContext Context) override {
const auto SourceMgr = Context.getSourceManager();
@@ -55,7 +58,7 @@ public:
NewCandidates.clear();
}
-auto PrevNameLen = PrevName.size();
+auto PrevNameLen = PrevName.length();
if (PrintLocations)
for (const auto Loc : RenamingCandidates) {
FullSourceLoc FullLoc(Loc, SourceMgr);
@@ -72,7 +75,7 @@ public:
}
private:
- StringRef NewName, PrevName;
+ const std::string NewName, PrevName;
const std::vectorstd::string USRs;
tooling::Replacements Replaces;
bool PrintLocations;
Modified: clang-tools-extra/trunk/clang-rename/RenamingAction.h
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-rename/RenamingAction.h?rev=241335r1=241334r2=241335view=diff
==
--- clang-tools-extra/trunk/clang-rename/RenamingAction.h (original)
+++ clang-tools-extra/trunk/clang-rename/RenamingAction.h Fri Jul 3
04:30:33 2015
@@ -25,7 +25,7 @@ namespace rename {
class RenamingAction {
public:
- RenamingAction(llvm::StringRef NewName, llvm::StringRef PrevName,
+ RenamingAction(const std::string NewName, const std::string PrevName,
const std::vectorstd::string USRs,
tooling::Replacements Replaces, bool PrintLocations =
false)
: NewName(NewName), PrevName(PrevName), USRs(USRs),
Replaces(Replaces),
@@ -35,7 +35,7 @@ public:
std::unique_ptrASTConsumer newASTConsumer();
private:
- llvm::StringRef NewName, PrevName;
+ const std::string NewName, PrevName;
const std::vectorstd::string USRs;
tooling::Replacements Replaces;
bool PrintLocations;
Modified: clang-tools-extra/trunk/modularize/Modularize.cpp
URL:
r241177 - Revert [DebugInfo] Fix debug info generation for function static variables, typedefs, and records
Author: dblaikie
Date: Wed Jul 1 13:07:22 2015
New Revision: 241177
URL: http://llvm.org/viewvc/llvm-project?rev=241177view=rev
Log:
Revert [DebugInfo] Fix debug info generation for function static variables,
typedefs, and records
Caused PR24008.
This reverts commit r241154.
Removed:
cfe/trunk/test/CodeGenCXX/debug-info-lb-class.cpp
cfe/trunk/test/CodeGenCXX/debug-info-lb-static.cpp
cfe/trunk/test/CodeGenCXX/debug-info-lb-static2.cpp
cfe/trunk/test/CodeGenCXX/debug-info-lb-typedef.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/CGDecl.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=241177r1=241176r2=241177view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Jul 1 13:07:22 2015
@@ -786,18 +786,15 @@ llvm::DIType *CGDebugInfo::CreateType(co
llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
llvm::DIFile *Unit) {
- TypedefNameDecl *TD = Ty-getDecl();
// We don't set size information, but do specify where the typedef was
// declared.
- SourceLocation Loc = TD-getLocation();
-
- llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD, QualType(Ty, 0));
+ SourceLocation Loc = Ty-getDecl()-getLocation();
// Typedefs are derived from some other type.
return DBuilder.createTypedef(
getOrCreateType(Ty-getDecl()-getUnderlyingType(), Unit),
Ty-getDecl()-getName(), getOrCreateFile(Loc), getLineNumber(Loc),
- TDContext);
+ getContextDescriptor(castDecl(Ty-getDecl()-getDeclContext(;
}
llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
@@ -1445,23 +1442,6 @@ llvm::DIType *CGDebugInfo::getOrCreateIn
return T;
}
-void CGDebugInfo::recordDeclarationLexicalScope(const Decl D) {
- assert(LexicalBlockMap.find(D) == LexicalBlockMap.end()
- D is already mapped to lexical block scope);
- if (!LexicalBlockStack.empty())
-LexicalBlockMap[D] = LexicalBlockStack.back();
-}
-
-llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl D,
- QualType Ty) {
- auto I = LexicalBlockMap.find(D);
- if (I != LexicalBlockMap.end()) {
-RetainedTypes.push_back(Ty.getAsOpaquePtr());
-return I-second;
- } else
-return getContextDescriptor(castDecl(D.getDeclContext()));
-}
-
void CGDebugInfo::completeType(const EnumDecl *ED) {
if (DebugKind = CodeGenOptions::DebugLineTablesOnly)
return;
@@ -2289,7 +2269,8 @@ llvm::DICompositeType *CGDebugInfo::Crea
unsigned Line = getLineNumber(RD-getLocation());
StringRef RDName = getClassName(RD);
- llvm::DIScope *RDContext = getDeclarationLexicalScope(*RD, QualType(Ty, 0));
+ llvm::DIScope *RDContext =
+ getContextDescriptor(castDecl(RD-getDeclContext()));
// If we ended up creating the type during the context chain construction,
// just return that.
@@ -2435,14 +2416,7 @@ void CGDebugInfo::collectVarDeclProps(co
// outside the class by putting it in the global scope.
if (DC-isRecord())
DC = CGM.getContext().getTranslationUnitDecl();
-
- if (VD-isStaticLocal()) {
-// Get context for static locals (that are technically globals) the same
way
-// we do for local locals -- by using current lexical block.
-assert(!LexicalBlockStack.empty() Region stack mismatch, stack
empty!);
-VDContext = LexicalBlockStack.back();
- } else
-VDContext = getContextDescriptor(dyn_castDecl(DC));
+ VDContext = getContextDescriptor(dyn_castDecl(DC));
}
llvm::DISubprogram *
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=241177r1=241176r2=241177view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Wed Jul 1 13:07:22 2015
@@ -100,11 +100,6 @@ class CGDebugInfo {
// LexicalBlockStack - Keep track of our current nested lexical block.
std::vectorllvm::TypedTrackingMDRefllvm::DIScope LexicalBlockStack;
-
- /// \brief Map of AST declaration to its lexical block scope.
- llvm::DenseMapconst Decl *, llvm::TypedTrackingMDRefllvm::DIScope
- LexicalBlockMap;
-
llvm::DenseMapconst Decl *, llvm::TrackingMDRef RegionMap;
// FnBeginRegionCount - Keep track of LexicalBlockStack counter at the
// beginning of a function. This is used to pop unbalanced regions at
@@ -310,12 +305,6 @@ public:
/// debug info.
llvm::DIType *getOrCreateInterfaceType(QualType Ty, SourceLocation Loc);
- /// \brief Map AST declaration to its lexical block scope if available.
- void recordDeclarationLexicalScope(const Decl D);
-
- /// \brief Get
Re: r241154 - [DebugInfo] Fix debug info generation for function static variables, typedefs, and records
Looks like this broke some things:
https://llvm.org/bugs/show_bug.cgi?id=24008 (hopefully Nico can provide a
reproduction shortly)
I've reverted this (and the LLVM patch) for now. Let me know if there's
anything I can do to help debug the issue.
On Wed, Jul 1, 2015 at 5:34 AM, Michael Kuperstein
michael.m.kuperst...@intel.com wrote:
Author: mkuper
Date: Wed Jul 1 07:34:39 2015
New Revision: 241154
URL: http://llvm.org/viewvc/llvm-project?rev=241154view=rev
Log:
[DebugInfo] Fix debug info generation for function static variables,
typedefs, and records
Function static variables, typedefs and records (class, struct or union)
declared inside
a lexical scope were associated with the function as their parent scope,
rather than the
lexical scope they are defined or declared in.
This fixes PR19238
Patch by: amjad.ab...@intel.com
Differential Revision: http://reviews.llvm.org/D9760
Added:
cfe/trunk/test/CodeGenCXX/debug-info-lb-class.cpp (with props)
cfe/trunk/test/CodeGenCXX/debug-info-lb-static.cpp (with props)
cfe/trunk/test/CodeGenCXX/debug-info-lb-static2.cpp (with props)
cfe/trunk/test/CodeGenCXX/debug-info-lb-typedef.cpp (with props)
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/CGDecl.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=241154r1=241153r2=241154view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Jul 1 07:34:39 2015
@@ -786,15 +786,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
llvm::DIFile *Unit) {
+ TypedefNameDecl *TD = Ty-getDecl();
// We don't set size information, but do specify where the typedef was
// declared.
- SourceLocation Loc = Ty-getDecl()-getLocation();
+ SourceLocation Loc = TD-getLocation();
+
+ llvm::DIScope *TDContext = getDeclarationLexicalScope(*TD, QualType(Ty,
0));
// Typedefs are derived from some other type.
return DBuilder.createTypedef(
getOrCreateType(Ty-getDecl()-getUnderlyingType(), Unit),
Ty-getDecl()-getName(), getOrCreateFile(Loc), getLineNumber(Loc),
- getContextDescriptor(castDecl(Ty-getDecl()-getDeclContext(;
+ TDContext);
}
llvm::DIType *CGDebugInfo::CreateType(const FunctionType *Ty,
@@ -1442,6 +1445,23 @@ llvm::DIType *CGDebugInfo::getOrCreateIn
return T;
}
+void CGDebugInfo::recordDeclarationLexicalScope(const Decl D) {
+ assert(LexicalBlockMap.find(D) == LexicalBlockMap.end()
+ D is already mapped to lexical block scope);
+ if (!LexicalBlockStack.empty())
+LexicalBlockMap[D] = LexicalBlockStack.back();
+}
+
+llvm::DIScope *CGDebugInfo::getDeclarationLexicalScope(const Decl D,
+ QualType Ty) {
+ auto I = LexicalBlockMap.find(D);
+ if (I != LexicalBlockMap.end()) {
+RetainedTypes.push_back(Ty.getAsOpaquePtr());
+return I-second;
+ } else
+return getContextDescriptor(castDecl(D.getDeclContext()));
+}
+
void CGDebugInfo::completeType(const EnumDecl *ED) {
if (DebugKind = CodeGenOptions::DebugLineTablesOnly)
return;
@@ -2269,8 +2289,7 @@ llvm::DICompositeType *CGDebugInfo::Crea
unsigned Line = getLineNumber(RD-getLocation());
StringRef RDName = getClassName(RD);
- llvm::DIScope *RDContext =
- getContextDescriptor(castDecl(RD-getDeclContext()));
+ llvm::DIScope *RDContext = getDeclarationLexicalScope(*RD, QualType(Ty,
0));
// If we ended up creating the type during the context chain
construction,
// just return that.
@@ -2416,7 +2435,14 @@ void CGDebugInfo::collectVarDeclProps(co
// outside the class by putting it in the global scope.
if (DC-isRecord())
DC = CGM.getContext().getTranslationUnitDecl();
- VDContext = getContextDescriptor(dyn_castDecl(DC));
+
+ if (VD-isStaticLocal()) {
+// Get context for static locals (that are technically globals) the
same way
+// we do for local locals -- by using current lexical block.
+assert(!LexicalBlockStack.empty() Region stack mismatch, stack
empty!);
+VDContext = LexicalBlockStack.back();
+ } else
+VDContext = getContextDescriptor(dyn_castDecl(DC));
}
llvm::DISubprogram *
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=241154r1=241153r2=241154view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Wed Jul 1 07:34:39 2015
@@ -100,6 +100,11 @@ class CGDebugInfo {
//
Re: r241140 - -frewrite-includes: Rework how includes and modules are differentiated
On Wed, Jul 1, 2015 at 12:21 AM, Justin Bogner m...@justinbogner.com wrote: David Blaikie dblai...@gmail.com writes: On Tue, Jun 30, 2015 at 9:40 PM, Justin Bogner m...@justinbogner.com wrote: Author: bogner Date: Tue Jun 30 23:40:10 2015 New Revision: 241140 URL: http://llvm.org/viewvc/llvm-project?rev=241140view=rev Log: -frewrite-includes: Rework how includes and modules are differentiated The map of FileChange structs here was storing two disjoint types of information: 1. A pointer to the Module that an #include directive implicitly imported 2. A FileID and FileType for an included file. These would be left uninitialized in the Module case. This change splits these two kinds of information into their own maps, which both simplifies how we access either and avoids the undefined behaviour we were hitting due to the uninitialized fields in the included file case. Mostly NFC, but fixes some errors found by self-host with ubsan. Ideally it'd be nice to have those test cases reduced and committed, so they can be found/verified/etc without a full selfhost build later on. I worded this poorly - the errors were in the test suite (in Frontend/rewrite-includes-missing.c) when running check-clang with a self-hosted clang with ubsan enabled. Ah, so an UBSan bot/anyone developing with UBSan enabled would've caught this - sounds good. Thanks! ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r241140 - -frewrite-includes: Rework how includes and modules are differentiated
On Tue, Jun 30, 2015 at 9:40 PM, Justin Bogner m...@justinbogner.com
wrote:
Author: bogner
Date: Tue Jun 30 23:40:10 2015
New Revision: 241140
URL: http://llvm.org/viewvc/llvm-project?rev=241140view=rev
Log:
-frewrite-includes: Rework how includes and modules are differentiated
The map of FileChange structs here was storing two disjoint types of
information:
1. A pointer to the Module that an #include directive implicitly
imported
2. A FileID and FileType for an included file. These would be left
uninitialized in the Module case.
This change splits these two kinds of information into their own maps,
which both simplifies how we access either and avoids the undefined
behaviour we were hitting due to the uninitialized fields in the
included file case.
Mostly NFC, but fixes some errors found by self-host with ubsan.
Ideally it'd be nice to have those test cases reduced and committed, so
they can be found/verified/etc without a full selfhost build later on.
Modified:
cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
Modified: cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp?rev=241140r1=241139r2=241140view=diff
==
--- cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Frontend/Rewrite/InclusionRewriter.cpp Tue Jun 30
23:40:10 2015
@@ -29,13 +29,11 @@ namespace {
class InclusionRewriter : public PPCallbacks {
/// Information about which #includes were actually performed,
/// created by preprocessor callbacks.
- struct FileChange {
-const Module *Mod;
-SourceLocation From;
+ struct IncludedFile {
FileID Id;
SrcMgr::CharacteristicKind FileType;
-FileChange(SourceLocation From, const Module *Mod) : Mod(Mod),
From(From) {
-}
+IncludedFile(FileID Id, SrcMgr::CharacteristicKind FileType)
+: Id(Id), FileType(FileType) {}
};
Preprocessor PP; /// Used to find inclusion directives.
SourceManager SM; /// Used to read and manage source files.
@@ -44,11 +42,13 @@ class InclusionRewriter : public PPCallb
const llvm::MemoryBuffer *PredefinesBuffer; /// The preprocessor
predefines.
bool ShowLineMarkers; /// Show #line markers.
bool UseLineDirectives; /// Use of line directives or line markers.
- typedef std::mapunsigned, FileChange FileChangeMap;
- FileChangeMap FileChanges; /// Tracks which files were included where.
- /// Used transitively for building up the FileChanges mapping over the
+ /// Tracks where inclusions that change the file are found.
+ std::mapunsigned, IncludedFile FileIncludes;
+ /// Tracks where inclusions that import modules are found.
+ std::mapunsigned, const Module * ModuleIncludes;
+ /// Used transitively for building up the FileIncludes mapping over the
/// various \c PPCallbacks callbacks.
- FileChangeMap::iterator LastInsertedFileChange;
+ SourceLocation LastInclusionLocation;
public:
InclusionRewriter(Preprocessor PP, raw_ostream OS, bool
ShowLineMarkers,
bool UseLineDirectives);
@@ -82,7 +82,8 @@ private:
bool HandleHasInclude(FileID FileId, Lexer RawLex,
const DirectoryLookup *Lookup, Token Tok,
bool FileExists);
- const FileChange *FindFileChangeLocation(SourceLocation Loc) const;
+ const IncludedFile *FindIncludeAtLocation(SourceLocation Loc) const;
+ const Module *FindModuleAtLocation(SourceLocation Loc) const;
StringRef NextIdentifierName(Lexer RawLex, Token RawToken);
};
@@ -95,7 +96,7 @@ InclusionRewriter::InclusionRewriter(Pre
: PP(PP), SM(PP.getSourceManager()), OS(OS), MainEOL(\n),
PredefinesBuffer(nullptr), ShowLineMarkers(ShowLineMarkers),
UseLineDirectives(UseLineDirectives),
- LastInsertedFileChange(FileChanges.end()) {}
+ LastInclusionLocation(SourceLocation()) {}
/// Write appropriate line information as either #line directives or GNU
line
/// markers depending on what mode we're in, including the \p Filename and
@@ -143,12 +144,14 @@ void InclusionRewriter::FileChanged(Sour
FileID) {
if (Reason != EnterFile)
return;
- if (LastInsertedFileChange == FileChanges.end())
+ if (LastInclusionLocation.isInvalid())
// we didn't reach this file (eg: the main file) via an inclusion
directive
return;
- LastInsertedFileChange-second.Id = FullSourceLoc(Loc, SM).getFileID();
- LastInsertedFileChange-second.FileType = NewFileType;
- LastInsertedFileChange = FileChanges.end();
+ FileID Id = FullSourceLoc(Loc, SM).getFileID();
+ auto P = FileIncludes.emplace(LastInclusionLocation.getRawEncoding(),
+IncludedFile(Id, NewFileType));
+ assert(P.second Unexpected revisitation of the same
Re: r241084 - Debug Info: Emit debug info for @import declarations.
On Tue, Jun 30, 2015 at 10:39 AM, Adrian Prantl apra...@apple.com wrote:
Author: adrian
Date: Tue Jun 30 12:39:51 2015
New Revision: 241084
URL: http://llvm.org/viewvc/llvm-project?rev=241084view=rev
Log:
Debug Info: Emit debug info for @import declarations.
This allows a module-aware debugger such as LLDB to import the currently
visible modules before dropping into the expression evaluator.
rdar://problem/20965932
Added:
cfe/trunk/test/Modules/Inputs/DebugModule.h
cfe/trunk/test/Modules/debug-info-moduleimport.m
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/Modules/Inputs/module.map
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=241084r1=241083r2=241084view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Jun 30 12:39:51 2015
@@ -27,6 +27,8 @@
#include clang/Basic/SourceManager.h
#include clang/Basic/Version.h
#include clang/Frontend/CodeGenOptions.h
+#include clang/Lex/HeaderSearchOptions.h
+#include clang/Lex/PreprocessorOptions.h
#include llvm/ADT/SmallVector.h
#include llvm/ADT/StringExtras.h
#include llvm/IR/Constants.h
@@ -1661,6 +1663,49 @@ llvm::DIType *CGDebugInfo::CreateType(co
return CreateTypeDefinition(Ty, Unit);
}
+llvm::DIModule *
+CGDebugInfo::getOrCreateModuleRef(ExternalASTSource::ASTSourceDescriptor
Mod) {
+ llvm::DIModule *ModuleRef = nullptr;
+ auto it = ModuleRefCache.find(Mod.Signature);
+ if (it != ModuleRefCache.end())
+ModuleRef = it-second;
Early return to reduce indentation?
+ else {
+// Macro definitions that were defined with -D on the command line.
+SmallString128 ConfigMacros;
+{
+ llvm::raw_svector_ostream OS(ConfigMacros);
+ const auto PPOpts = CGM.getPreprocessorOpts();
+ unsigned I = 0;
+ // Translate the macro definitions back into a commmand line.
+ for (auto M : PPOpts.Macros) {
+if (++I 1)
+ OS ;
+const std::string Macro = M.first;
+bool Undef = M.second;
+OS \- (Undef ? 'U' : 'D');
+for (char c : Macro)
+ switch (c) {
+ case '\\' : OS ; break;
+ case '' : OS \\\; break;
+ default: OS c;
+ }
+OS '\';
+ }
+}
+llvm::DIBuilder DIB(CGM.getModule());
+auto *CU = DIB.createCompileUnit(
+TheCU-getSourceLanguage(), internString(Mod.ModuleName),
+internString(Mod.Path), TheCU-getProducer(), true, StringRef(),
0,
+internString(Mod.ASTFile), llvm::DIBuilder::FullDebug,
Mod.Signature);
+ModuleRef = DIB.createModule(
+CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
+internString(CGM.getHeaderSearchOpts().Sysroot));
+DIB.finalize();
+ModuleRefCache.insert(std::make_pair(Mod.Signature, ModuleRef));
+ }
+ return ModuleRef;
+}
+
llvm::DIType *CGDebugInfo::CreateTypeDefinition(const ObjCInterfaceType
*Ty,
llvm::DIFile *Unit) {
ObjCInterfaceDecl *ID = Ty-getDecl();
@@ -3304,6 +3349,15 @@ void CGDebugInfo::EmitUsingDecl(const Us
getLineNumber(USD.getLocation()));
}
+void CGDebugInfo::EmitImportDecl(const ImportDecl ID) {
+ auto *Reader = CGM.getContext().getExternalSource();
+ auto Info = Reader-getSourceDescriptor(*ID.getImportedModule());
+ DBuilder.createImportedDeclaration(
+getCurrentContextDescriptor(castDecl(ID.getDeclContext())),
+getOrCreateModuleRef(Info),
+getLineNumber(ID.getLocation()));
+}
+
llvm::DIImportedEntity *
CGDebugInfo::EmitNamespaceAlias(const NamespaceAliasDecl NA) {
if (CGM.getCodeGenOpts().getDebugInfo()
CodeGenOptions::LimitedDebugInfo)
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=241084r1=241083r2=241084view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Tue Jun 30 12:39:51 2015
@@ -83,6 +83,9 @@ class CGDebugInfo {
/// which may change.
llvm::SmallVectorObjCInterfaceCacheEntry, 32 ObjCInterfaceCache;
+ /// \brief Cache of references to AST files such as PCHs or modules.
+ llvm::DenseMapuint64_t, llvm::DIModule * ModuleRefCache;
+
/// \brief list of interfaces we want to keep even if orphaned.
std::vectorvoid * RetainedTypes;
@@ -289,6 +292,9 @@ public:
/// \brief Emit C++ using declaration.
void EmitUsingDecl(const UsingDecl UD);
+ /// \brief Emit an @import declaration.
+ void
Re: r241088 - Use an early exit to improve readability. (NFC)
On Tue, Jun 30, 2015 at 11:01 AM, Adrian Prantl apra...@apple.com wrote:
Author: adrian
Date: Tue Jun 30 13:01:05 2015
New Revision: 241088
URL: http://llvm.org/viewvc/llvm-project?rev=241088view=rev
Log:
Use an early exit to improve readability. (NFC)
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=241088r1=241087r2=241088view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Jun 30 13:01:05 2015
@@ -1665,44 +1665,42 @@ llvm::DIType *CGDebugInfo::CreateType(co
llvm::DIModule *
CGDebugInfo::getOrCreateModuleRef(ExternalASTSource::ASTSourceDescriptor
Mod) {
- llvm::DIModule *ModuleRef = nullptr;
auto it = ModuleRefCache.find(Mod.Signature);
Oh, and, assuming this function isn't recursive (ie: the process of
building the DIModule doesn't cause other DIModules to be created/inserted
into ModuleRefCache) you can avoid doing two map lookups:
auto *ModuleRef = ModuleRefCache[Mod.Signature];
if (ModuleRef)
return ModuleRef
...
ModuleRef = ...;
return ModuleRef;
if (it != ModuleRefCache.end())
-ModuleRef = it-second;
- else {
-// Macro definitions that were defined with -D on the command line.
-SmallString128 ConfigMacros;
-{
- llvm::raw_svector_ostream OS(ConfigMacros);
- const auto PPOpts = CGM.getPreprocessorOpts();
- unsigned I = 0;
- // Translate the macro definitions back into a commmand line.
- for (auto M : PPOpts.Macros) {
-if (++I 1)
- OS ;
-const std::string Macro = M.first;
-bool Undef = M.second;
-OS \- (Undef ? 'U' : 'D');
-for (char c : Macro)
- switch (c) {
- case '\\' : OS ; break;
- case '' : OS \\\; break;
- default: OS c;
- }
-OS '\';
- }
+return it-second;
+
+ // Macro definitions that were defined with -D on the command line.
+ SmallString128 ConfigMacros;
+ {
+llvm::raw_svector_ostream OS(ConfigMacros);
+const auto PPOpts = CGM.getPreprocessorOpts();
+unsigned I = 0;
+// Translate the macro definitions back into a commmand line.
+for (auto M : PPOpts.Macros) {
+ if (++I 1)
+OS ;
+ const std::string Macro = M.first;
+ bool Undef = M.second;
+ OS \- (Undef ? 'U' : 'D');
+ for (char c : Macro)
+switch (c) {
+case '\\' : OS ; break;
+case '' : OS \\\; break;
+default: OS c;
+}
+ OS '\';
}
-llvm::DIBuilder DIB(CGM.getModule());
-auto *CU = DIB.createCompileUnit(
-TheCU-getSourceLanguage(), internString(Mod.ModuleName),
-internString(Mod.Path), TheCU-getProducer(), true, StringRef(),
0,
-internString(Mod.ASTFile), llvm::DIBuilder::FullDebug,
Mod.Signature);
-ModuleRef = DIB.createModule(
-CU, Mod.ModuleName, ConfigMacros, internString(Mod.Path),
-internString(CGM.getHeaderSearchOpts().Sysroot));
-DIB.finalize();
-ModuleRefCache.insert(std::make_pair(Mod.Signature, ModuleRef));
}
+ llvm::DIBuilder DIB(CGM.getModule());
+ auto *CU = DIB.createCompileUnit(
+ TheCU-getSourceLanguage(), internString(Mod.ModuleName),
+ internString(Mod.Path), TheCU-getProducer(), true, StringRef(), 0,
+ internString(Mod.ASTFile), llvm::DIBuilder::FullDebug,
Mod.Signature);
+ llvm::DIModule *ModuleRef =
+ DIB.createModule(CU, Mod.ModuleName, ConfigMacros,
internString(Mod.Path),
+ internString(CGM.getHeaderSearchOpts().Sysroot));
+ DIB.finalize();
+ ModuleRefCache.insert(std::make_pair(Mod.Signature, ModuleRef));
return ModuleRef;
}
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Fixed debug info generation for function static variables, typedef, and records
Do you need to resolve the Context in the retained types iteration? If it's a lexical block it shouldn't ever be a scope ref, I think? Not sure. (mostly I'm just concerned aobut the inconsistency between that case and the global variable case above) In DwarfCompileUnit - perhaps: auto LocalDeclNodeRangeForScope = DD-findLocalDeclNodesForScope(DS); could be changed to: iterator_rangeLocalDeclMap::const_iterator LocalDeclNodeRangeForScope; if (!includeMinimalInlineScopes()) LocalDeclNodeRangeForScope = DD-findLocalDeclNodesForScope(DS); Then you can drop the includeMinimalInlineScopes() condition from the following if and the if around the for loop furtehr down, I think? (with the caveat that I'm not sure if iterator_range is guaranteed (or can be guaranteed) to produce an empty range - not sure if two default constructed iterators are guaranteed/meant to be equal to each other - could check the spec, etc) - David On Mon, Jun 29, 2015 at 12:18 AM, Amjad Aboud amjad.ab...@intel.com wrote: Updated the LLVM version to 240902 (close to top of trunk preparing for commit). http://reviews.llvm.org/D9760 Files: lib/CodeGen/CGDebugInfo.cpp lib/CodeGen/CGDebugInfo.h lib/CodeGen/CGDecl.cpp test/CodeGenCXX/debug-info-lb-class.cpp test/CodeGenCXX/debug-info-lb-static.cpp test/CodeGenCXX/debug-info-lb-static2.cpp test/CodeGenCXX/debug-info-lb-typedef.cpp EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] missing the consideration of calling conversion in around 81 clang regression tests.
Sure thing - committed in r240971
On Mon, Jun 29, 2015 at 3:50 AM, Ying Yi maggieyi...@gmail.com wrote:
Hello David,
Many thanks for your comments. When I modified the regression tests to add
the calling conventions, I considered using “{{\w*}}” as well. However, I
found some tests with calling conventions that used {{.*}}. Therefore, I
have used {{.*}} to make the tests consistent. I hope this is ok.
I don’t have commit access at the moment since this patch is my first
patch to cfe-commits. As mentioned in
http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch,
the commit access is granted to contributors with a track record of
submitting high quality patches.
Could you please help me by committing this patch or advise what do I need
to do in order to commit this change?
Many thanks,
Ying Yi
On Fri, Jun 26, 2015 at 5:24 PM, David Blaikie dblai...@gmail.com wrote:
Looks good to me, please commit.
(optionally, if you could put a space in the regex, that might not hurt:
define {{.* }}void
maybe even:
define {{\w* }}void
So it only accepts one token and doesn't accidentally eat more things.
Probably not terribly important and maybe what you have is the better
readability/accuracy tradeoff anyway.)
On Fri, Jun 26, 2015 at 2:16 AM, Maggie Yi maggieyi...@gmail.com wrote:
Dear All,
I would like to propose a patch for clang regression tests that will
fail on targets that set specific calling conventions.
For example, in Clang :: CodeGen/builtinshufflevector2.c:
Expected IR:
define void @clang_shufflevector_v_v
IR generated with a default triple of armv7a_pc_linux:
define arm_aapcs void @clang_shufflevector_v_v
The test could be changed to expect define{{.*}} void
@clang_shufflevector_v_v.
For ARM target with default triple armv7a_pc_linux, around 81 clang
regression tests failed due to the same reason.
It includes CodeGen, CodeGenCXX, CodeGenObjC, CodeGenObjCXX,
CodeGenOpenCL, Modules, OpenMP,
PCH, Profile and Sema tests. Please see attached the patch file for the
details.
Please let me know if this is an acceptable change.
Kind Regards,
Ying
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
Ying Yi
SN Systems Ltd - Sony Computer Entertainment Group.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r240971 - Account for calling convention specifiers in function definitions in IR test cases
Author: dblaikie
Date: Mon Jun 29 12:29:50 2015
New Revision: 240971
URL: http://llvm.org/viewvc/llvm-project?rev=240971view=rev
Log:
Account for calling convention specifiers in function definitions in IR test
cases
Several tests wouldn't pass when executed on an armv7a_pc_linux triple
due to the non-default arm_aapcs calling convention produced on the
function definitions in the IR output. Account for this with the
application of a little regex.
Patch by Ying Yi.
Modified:
cfe/trunk/test/CodeGen/2004-11-27-StaticFunctionRedeclare.c
cfe/trunk/test/CodeGen/2007-04-14-FNoBuiltin.c
cfe/trunk/test/CodeGen/PR8880.c
cfe/trunk/test/CodeGen/builtinshufflevector2.c
cfe/trunk/test/CodeGen/c-strings.c
cfe/trunk/test/CodeGen/call.c
cfe/trunk/test/CodeGen/captured-statements-nested.c
cfe/trunk/test/CodeGen/captured-statements.c
cfe/trunk/test/CodeGen/complex-convert.c
cfe/trunk/test/CodeGen/dostmt.c
cfe/trunk/test/CodeGen/fast-math.c
cfe/trunk/test/CodeGen/finite-math.c
cfe/trunk/test/CodeGen/linkage-redecl.c
cfe/trunk/test/CodeGen/nomathbuiltin.c
cfe/trunk/test/CodeGen/stack-protector.c
cfe/trunk/test/CodeGen/static-order.c
cfe/trunk/test/CodeGen/ubsan-blacklist.c
cfe/trunk/test/CodeGen/volatile-1.c
cfe/trunk/test/CodeGenCXX/PR5093-static-member-function.cpp
cfe/trunk/test/CodeGenCXX/address-of-fntemplate.cpp
cfe/trunk/test/CodeGenCXX/attr-cleanup.cpp
cfe/trunk/test/CodeGenCXX/block-byref-cxx-objc.cpp
cfe/trunk/test/CodeGenCXX/c-linkage.cpp
cfe/trunk/test/CodeGenCXX/captured-statements.cpp
cfe/trunk/test/CodeGenCXX/constructor-attr.cpp
cfe/trunk/test/CodeGenCXX/ctor-globalopt.cpp
cfe/trunk/test/CodeGenCXX/debug-info-line.cpp
cfe/trunk/test/CodeGenCXX/deferred-global-init.cpp
cfe/trunk/test/CodeGenCXX/derived-to-virtual-base-class-calls-final.cpp
cfe/trunk/test/CodeGenCXX/dynamic_cast-no-rtti.cpp
cfe/trunk/test/CodeGenCXX/extern-c.cpp
cfe/trunk/test/CodeGenCXX/function-template-explicit-specialization.cpp
cfe/trunk/test/CodeGenCXX/globalinit-loc.cpp
cfe/trunk/test/CodeGenCXX/mangle-address-space.cpp
cfe/trunk/test/CodeGenCXX/mangle-nullptr-arg.cpp
cfe/trunk/test/CodeGenCXX/mangle-template.cpp
cfe/trunk/test/CodeGenCXX/pr11797.cpp
cfe/trunk/test/CodeGenCXX/pr18661.cpp
cfe/trunk/test/CodeGenCXX/pr9965.cpp
cfe/trunk/test/CodeGenCXX/pragma-weak.cpp
cfe/trunk/test/CodeGenCXX/predefined-expr.cpp
cfe/trunk/test/CodeGenCXX/template-dependent-bind-temporary.cpp
cfe/trunk/test/CodeGenCXX/typeid-should-throw.cpp
cfe/trunk/test/CodeGenCXX/vararg-non-pod.cpp
cfe/trunk/test/CodeGenCXX/virtual-destructor-synthesis.cpp
cfe/trunk/test/CodeGenCXX/vla-lambda-capturing.cpp
cfe/trunk/test/CodeGenCXX/volatile-1.cpp
cfe/trunk/test/CodeGenObjC/arc-block-copy-escape.m
cfe/trunk/test/CodeGenObjC/objc2-legacy-dispatch.m
cfe/trunk/test/CodeGenObjC/related-result-type.m
cfe/trunk/test/CodeGenObjCXX/arc-mangle.mm
cfe/trunk/test/CodeGenObjCXX/debug-info-line.mm
cfe/trunk/test/CodeGenOpenCL/event_t.cl
cfe/trunk/test/CodeGenOpenCL/local.cl
cfe/trunk/test/CodeGenOpenCL/opencl_types.cl
cfe/trunk/test/Modules/cxx-irgen.cpp
cfe/trunk/test/Modules/direct-module-import.m
cfe/trunk/test/Modules/pch-used.m
cfe/trunk/test/OpenMP/critical_codegen.cpp
cfe/trunk/test/OpenMP/flush_codegen.cpp
cfe/trunk/test/OpenMP/for_private_codegen.cpp
cfe/trunk/test/OpenMP/master_codegen.cpp
cfe/trunk/test/OpenMP/parallel_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/parallel_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/parallel_if_codegen.cpp
cfe/trunk/test/OpenMP/parallel_num_threads_codegen.cpp
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
cfe/trunk/test/OpenMP/parallel_proc_bind_codegen.cpp
cfe/trunk/test/OpenMP/sections_private_codegen.cpp
cfe/trunk/test/OpenMP/single_private_codegen.cpp
cfe/trunk/test/OpenMP/taskgroup_codegen.cpp
cfe/trunk/test/PCH/cxx-mangling.cpp
cfe/trunk/test/PCH/objc_container.m
cfe/trunk/test/PCH/objc_literals.m
cfe/trunk/test/PCH/objc_literals.mm
cfe/trunk/test/Profile/cxx-lambda.cpp
cfe/trunk/test/Profile/cxx-rangefor.cpp
cfe/trunk/test/Profile/cxx-templates.cpp
cfe/trunk/test/Sema/attr-malloc.c
cfe/trunk/test/Sema/enable_if.c
Modified: cfe/trunk/test/CodeGen/2004-11-27-StaticFunctionRedeclare.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2004-11-27-StaticFunctionRedeclare.c?rev=240971r1=240970r2=240971view=diff
==
--- cfe/trunk/test/CodeGen/2004-11-27-StaticFunctionRedeclare.c (original)
+++ cfe/trunk/test/CodeGen/2004-11-27-StaticFunctionRedeclare.c Mon Jun 29
12:29:50 2015
@@ -6,7 +6,7 @@
// This is PR244
-// CHECK-LABEL: define void @bar(
+// CHECK-LABEL: define {{.*}}void
Re: [PATCH] clang-format: Add missing members to FormatStyle::operator==
can/should there be any test coverage for this? (I suppose there's probably
not any test coverage that would catch added fields without using UB to
scramble the object's bits... )
On Fri, Jun 26, 2015 at 4:40 PM, Birunthan Mohanathas
birunt...@mohanathas.com wrote:
Hi djasper,
Depends on D10784.
http://reviews.llvm.org/D10785
Files:
include/clang/Format/Format.h
Index: include/clang/Format/Format.h
===
--- include/clang/Format/Format.h
+++ include/clang/Format/Format.h
@@ -427,12 +427,15 @@
bool operator==(const FormatStyle R) const {
return AccessModifierOffset == R.AccessModifierOffset
AlignAfterOpenBracket == R.AlignAfterOpenBracket
+ AlignConsecutiveAssignments == R.AlignConsecutiveAssignments
AlignEscapedNewlinesLeft == R.AlignEscapedNewlinesLeft
AlignOperands == R.AlignOperands
AlignTrailingComments == R.AlignTrailingComments
AllowAllParametersOfDeclarationOnNextLine ==
R.AllowAllParametersOfDeclarationOnNextLine
AllowShortBlocksOnASingleLine ==
R.AllowShortBlocksOnASingleLine
+ AllowShortCaseLabelsOnASingleLine ==
+ R.AllowShortCaseLabelsOnASingleLine
AllowShortFunctionsOnASingleLine ==
R.AllowShortFunctionsOnASingleLine
AllowShortIfStatementsOnASingleLine ==
@@ -460,6 +463,7 @@
ContinuationIndentWidth == R.ContinuationIndentWidth
Cpp11BracedListStyle == R.Cpp11BracedListStyle
DerivePointerAlignment == R.DerivePointerAlignment
+ DisableFormat == R.DisableFormat
ExperimentalAutoDetectBinPacking ==
R.ExperimentalAutoDetectBinPacking
ForEachMacros == R.ForEachMacros
@@ -473,6 +477,8 @@
ObjCBlockIndentWidth == R.ObjCBlockIndentWidth
ObjCSpaceAfterProperty == R.ObjCSpaceAfterProperty
ObjCSpaceBeforeProtocolList == R.ObjCSpaceBeforeProtocolList
+ PenaltyBreakBeforeFirstCallParameter ==
+ R.PenaltyBreakBeforeFirstCallParameter
PenaltyBreakComment == R.PenaltyBreakComment
PenaltyBreakFirstLessLess == R.PenaltyBreakFirstLessLess
PenaltyBreakString == R.PenaltyBreakString
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] missing the consideration of calling conversion in around 81 clang regression tests.
Looks good to me, please commit.
(optionally, if you could put a space in the regex, that might not hurt:
define {{.* }}void
maybe even:
define {{\w* }}void
So it only accepts one token and doesn't accidentally eat more things.
Probably not terribly important and maybe what you have is the better
readability/accuracy tradeoff anyway.)
On Fri, Jun 26, 2015 at 2:16 AM, Maggie Yi maggieyi...@gmail.com wrote:
Dear All,
I would like to propose a patch for clang regression tests that will fail
on targets that set specific calling conventions.
For example, in Clang :: CodeGen/builtinshufflevector2.c:
Expected IR:
define void @clang_shufflevector_v_v
IR generated with a default triple of armv7a_pc_linux:
define arm_aapcs void @clang_shufflevector_v_v
The test could be changed to expect define{{.*}} void
@clang_shufflevector_v_v.
For ARM target with default triple armv7a_pc_linux, around 81 clang
regression tests failed due to the same reason.
It includes CodeGen, CodeGenCXX, CodeGenObjC, CodeGenObjCXX,
CodeGenOpenCL, Modules, OpenMP,
PCH, Profile and Sema tests. Please see attached the patch file for the
details.
Please let me know if this is an acceptable change.
Kind Regards,
Ying
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Warn, if parameter is used in ctor body after being used for move-construct
+rtrieu
On Fri, Jun 12, 2015 at 3:53 PM, Ismail Pazarbasi
ismail.pazarb...@gmail.com wrote:
Hi rsmith, dblaikie,
If a member of type unique_ptr or shared_ptr is move-constructed from
a parameter in ctor-init, the parameter will be left with nullptr at
the completion of member's initialization. If the parameter's and
member's names are the same, use of member's name in the constructor
body will not refer to the member, but to the parameter.
#include memory
struct X {
int v;
X() : v() { }
int f() { return v + 42; }
};
struct Y {
std::unique_ptrX p;
int x;
explicit Y(std::unique_ptrX p)
: p{std::move(p)} {
x = p-f(); // 'p' is nullptr
decltype(p-f()) v = x; // ignore unevaluated context
}
int f() const { return x; }
};
int main() {
std::unique_ptrX p(new X);
Y y(std::move(p));
return y.f();
}
http://reviews.llvm.org/D10425
Files:
include/clang/Basic/DiagnosticGroups.td
include/clang/Basic/DiagnosticSemaKinds.td
lib/Sema/SemaDecl.cpp
test/SemaCXX/rval-references.cpp
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Use more range-based for loops
Looks good - feel free to commit this sort of cleanup in areas you're working directly/with post-commit review. http://reviews.llvm.org/D10738 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Warn, if parameter is used in ctor body after being used for move-construct
A few thoughts - but probably having some review by rtreiu would be good. He's
more involved in the diagnostic development than I am.
Have you run this over any substantial existing codebase to see what the stats
are like (true/false positives, etc)?
The other issue is that, of course, we'd like a much more general version of
this warning but it's unclear how much work that'll be and what the right
tradeoff is for compile time. Some common analysis might be shared between a
bunch of such warnings - we already have sometimes-uninitialized which is a
CFG diagnostic that could be useful (treat moved-from as the uninitialized
state and do the same analysis).
Comment at: lib/Sema/SemaDecl.cpp:10694
@@ +10693,3 @@
+FieldInitMovedFromParamVisitor V(FD-getASTContext(), FD-getName());
+V.Visit(E);
+if (ParmVarDecl *P = V.getParam())
I'm not sure how much of an efficiency concern there is doing a generic RAV
here, rather than something more targeted. I mean I suppose in general the
std::move could happen in any subexpression of an init - but I assume the case
you're trying to catch here is just the one where the name of the parameter and
variable are the same (or very similar - like foo_ and foo, etc) and the user
accidentally uses the parameter instead of the variable they moved-in-to?
Comment at: lib/Sema/SemaDecl.cpp:10783
@@ -10674,1 +10782,3 @@
DiagnoseUnusedParameters(FD-param_begin(), FD-param_end());
+if (getLangOpts().CPlusPlus11)
+ DiagnoseUseOfMovedParams(*this, FD);
I forget, is CPlusPlus11 true in modes greater than 11? (so we still get the
warning in 14, etc?)
Comment at: test/SemaCXX/rval-references.cpp:95
@@ -94,1 +94,3 @@
}
+
+namespace std {
This test case seems a bit long/verbose - you probably don't need to reproduce
a substantial amount of this template machinery to reproduce the warning (a
trivial movable type rather than a copy of a substantial amount of unique_ptr
would suffice, for example - and there's no need for the extra type traits
(remove_ref, etc) work in the faux-move implementation, etc)
http://reviews.llvm.org/D10425
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Omit 'nodebug' method from the class
Looks good - thanks! Comment at: test/CodeGenCXX/debug-info-method-nodebug.cpp:6 @@ +5,3 @@ + void absent() __attribute__((nodebug)); + int i; +}; do you need the int member? http://reviews.llvm.org/D10678 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Fwd: r225956 - Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).
Oops, replied intsead of reply-all'd. -- Forwarded message -- From: David Blaikie dblai...@gmail.com Date: Thu, Jun 25, 2015 at 10:18 AM Subject: Re: r225956 - Reapply r225000 (reverted in r22): DebugInfo: Generalize debug info location handling (and follow-up commits). To: Frédéric Riss fr...@apple.com On Wed, Jun 17, 2015 at 5:03 PM, Frédéric Riss fr...@apple.com wrote: Sorry for the thread necrology. I was investigating compile time regressions, and I noticed that this commit alone would cause a 25% slowdown on the “-O0 -g” irgen phase. Hmm, curious. Good to know, though. Any idea on how to improve on that? Nothing that springs immediately to mind (though equally I'm not immediately sure why it should create /that/ much slowdown) I’ll profile a bit to see if I can pinpoint how particular path, but I thought I’d reach out early in case you have ideas. Yeah, sorry - but I'll be curious to see any profiles/data throw around some ideas. Thanks for noticing/looking into it. (not sure why this wouldn't've shown up for our own performance measurements - perhaps the irgen portion is dwarfed by other parts of compilation (parsing, LLVM opt/codegen/etc)) - David Fred On Jan 13, 2015, at 11:38 PM, David Blaikie dblai...@gmail.com wrote: Author: dblaikie Date: Wed Jan 14 01:38:27 2015 New Revision: 225956 URL: http://llvm.org/viewvc/llvm-project?rev=225956view=rev Log: Reapply r225000 (reverted in r22): DebugInfo: Generalize debug info location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply DebugInfo: Generalize debug info location handling Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. Modified: cfe/trunk/lib/CodeGen/CGBlocks.cpp cfe/trunk
Re: [PATCH] FileCheck-ize test and make sure more things don't happen.
SGTM (heh, I don't even remember llvm.dbg.func.start - maybe that's from before my time... yep, 2009) Maybe it'd be nice to make sure that this test doesn't bitrot the same way again - have a canary of some kind? (eg: a non-nodebug function and positively CHECK for the same features - so if those checks ever fail, we know we've accidentally made the negative tests for dbg/DISubprogram invalid) Seems weird - not sure if it's a good idea. Just a thought. On Thu, Jun 25, 2015 at 1:58 PM, Paul Robinson paul_robin...@playstation.sony.com wrote: Hi dblaikie, echristo, Attirbute 'nodebug' means no llvm.dbg.* intrinsics, no !dbg annotations, and no DISubprogram for the function. http://reviews.llvm.org/D10747 Files: test/CodeGen/attr-nodebug.c Index: test/CodeGen/attr-nodebug.c === --- test/CodeGen/attr-nodebug.c +++ test/CodeGen/attr-nodebug.c @@ -1,5 +1,4 @@ -// RUN: %clang_cc1 -g -emit-llvm -o %t %s -// RUN: not grep 'call void @llvm.dbg.func.start' %t +// RUN: %clang_cc1 -g -emit-llvm -o - %s | FileCheck %s void t1() __attribute__((nodebug)); @@ -10,3 +9,10 @@ a++; } +// IR should have no llvm.dbg.* calls, or !dbg annotations. +// CHECK-LABEL: @t1 +// CHECK-NOT: dbg +// CHECK: } + +// And no function description for debug info. +// CHECK-NOT: DISubprogram EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] FileCheck-ize test and make sure more things don't happen.
Looks good - alternatively you could phrase this as a single function with
a macro for the nodebug attribute - two clang+FileCheck lines, one passes
-D to enable the nodebug, one passes an empty -D. Might be a more direct
comparison? ( does require two clang invocations, which is a tradeoff)
On Thu, Jun 25, 2015 at 4:11 PM, Paul Robinson
paul_robin...@playstation.sony.com wrote:
I had a similar thought, but had foolishly suppressed it. Since you had
the same thought, it's probably worth paying attention to it.
http://reviews.llvm.org/D10747
Files:
test/CodeGen/attr-nodebug.c
Index: test/CodeGen/attr-nodebug.c
===
--- test/CodeGen/attr-nodebug.c
+++ test/CodeGen/attr-nodebug.c
@@ -1,12 +1,32 @@
-// RUN: %clang_cc1 -g -emit-llvm -o %t %s
-// RUN: not grep 'call void @llvm.dbg.func.start' %t
+// RUN: %clang_cc1 -g -emit-llvm -o - %s | FileCheck %s
void t1() __attribute__((nodebug));
void t1()
{
int a = 10;
-
a++;
}
+void t2()
+{
+ int b = 10;
+ b++;
+}
+
+// With nodebug, IR should have no llvm.dbg.* calls, or !dbg annotations.
+// CHECK-LABEL: @t1
+// CHECK-NOT: dbg
+// CHECK: }
+
+// For sanity, check those things do occur normally.
+// CHECK-LABEL: @t2
+// CHECK: call{{.*}}llvm.dbg
+// CHECK: !dbg
+// CHECK: }
+
+// We should see a function description for t2 but not t1.
+// CHECK-NOT: DISubprogram(name: t1
+// CHECK: DISubprogram(name: t2
+// CHECK-NOT: DISubprogram(name: t1
+
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] clarify ownership of BugReport objects
I'm assuming emitReport always takes ownership? (it doesn't look like it has any API surface area to express to the caller (in the current raw pointer API) that it didn't take ownership) In that case, best to pass by value rather than (lvalue or rvalue) reference so caller's explicitly pass off ownership (std::move(R)) to emitReport. You'll have to use llvm::make_unique, rather than std::make_unique - since we're still compiling as C++11, not C++14. I probably wouldn't bother renaming R to UniqueR in emitReport - don't think it adds/changes much. Ah, I see - there already was a UniqueR and R. Probably just use R, though? (now that it's the only thing, so there's no need to distinguish it as the unique one) Looks like a reformat of an unchanged/unrelated line: - BugReportEquivClass* EQ = EQClasses.FindNodeOrInsertPos(ID, InsertPos); + BugReportEquivClass *EQ = EQClasses.FindNodeOrInsertPos(ID, InsertPos); And where does emitReport actually take ownership? On Mon, Jun 22, 2015 at 8:07 AM, Aaron Ballman aa...@aaronballman.com wrote: Currently, when the analyzer wants to emit a report, it takes a naked pointer, and the emitReport function eventually takes over ownership of that pointer. I think this is a dangerous API because it's not particularly clear that this ownership transfer will happen, or that the pointer must be unique. This patch makes the ownership semantics more clear by encoding it as part of the API. There should be no functional changes, and I do not think it caught any bugs, but I do think this is an improvement. Thoughts or opinions? ~Aaron ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r240349 - Update for LLVM API change to return by InputArgList directly (rather than by pointer) from ParseArgs
Author: dblaikie
Date: Mon Jun 22 17:07:27 2015
New Revision: 240349
URL: http://llvm.org/viewvc/llvm-project?rev=240349view=rev
Log:
Update for LLVM API change to return by InputArgList directly (rather than by
pointer) from ParseArgs
Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/tools/driver/cc1as_main.cpp
cfe/trunk/tools/driver/driver.cpp
Modified: cfe/trunk/include/clang/Driver/Driver.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=240349r1=240348r2=240349view=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Mon Jun 22 17:07:27 2015
@@ -262,7 +262,7 @@ public:
/// ParseArgStrings - Parse the given list of strings into an
/// ArgList.
- llvm::opt::InputArgList *ParseArgStrings(ArrayRefconst char * Args);
+ llvm::opt::InputArgList ParseArgStrings(ArrayRefconst char * Args);
/// BuildInputs - Construct the list of inputs and their types from
/// the given arguments.
Modified: cfe/trunk/lib/Driver/Driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=240349r1=240348r2=240349view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Mon Jun 22 17:07:27 2015
@@ -106,7 +106,7 @@ void Driver::ParseDriverMode(ArrayRefco
}
}
-InputArgList *Driver::ParseArgStrings(ArrayRefconst char * ArgStrings) {
+InputArgList Driver::ParseArgStrings(ArrayRefconst char * ArgStrings) {
llvm::PrettyStackTraceString CrashInfo(Command line argument parsing);
unsigned IncludedFlagsBitmask;
@@ -115,32 +115,31 @@ InputArgList *Driver::ParseArgStrings(Ar
getIncludeExcludeOptionFlagMasks();
unsigned MissingArgIndex, MissingArgCount;
- InputArgList *Args =
+ InputArgList Args =
getOpts().ParseArgs(ArgStrings, MissingArgIndex, MissingArgCount,
IncludedFlagsBitmask, ExcludedFlagsBitmask);
// Check for missing argument error.
if (MissingArgCount)
Diag(clang::diag::err_drv_missing_argument)
- Args-getArgString(MissingArgIndex) MissingArgCount;
+ Args.getArgString(MissingArgIndex) MissingArgCount;
// Check for unsupported options.
- for (const Arg *A : *Args) {
+ for (const Arg *A : Args) {
if (A-getOption().hasFlag(options::Unsupported)) {
- Diag(clang::diag::err_drv_unsupported_opt) A-getAsString(*Args);
+ Diag(clang::diag::err_drv_unsupported_opt) A-getAsString(Args);
continue;
}
// Warn about -mcpu= without an argument.
if (A-getOption().matches(options::OPT_mcpu_EQ)
A-containsValue()) {
- Diag(clang::diag::warn_drv_empty_joined_argument)
-A-getAsString(*Args);
+ Diag(clang::diag::warn_drv_empty_joined_argument)
A-getAsString(Args);
}
}
- for (const Arg *A : Args-filtered(options::OPT_UNKNOWN))
-Diags.Report(diag::err_drv_unknown_argument) A-getAsString(*Args);
+ for (const Arg *A : Args.filtered(options::OPT_UNKNOWN))
+Diags.Report(diag::err_drv_unknown_argument) A-getAsString(Args);
return Args;
}
@@ -312,13 +311,13 @@ Compilation *Driver::BuildCompilation(Ar
// FIXME: This stuff needs to go into the Compilation, not the driver.
bool CCCPrintActions;
- InputArgList *Args = ParseArgStrings(ArgList.slice(1));
+ InputArgList Args = ParseArgStrings(ArgList.slice(1));
// -no-canonical-prefixes is used very early in main.
- Args-ClaimAllArgs(options::OPT_no_canonical_prefixes);
+ Args.ClaimAllArgs(options::OPT_no_canonical_prefixes);
// Ignore -pipe.
- Args-ClaimAllArgs(options::OPT_pipe);
+ Args.ClaimAllArgs(options::OPT_pipe);
// Extract -ccc args.
//
@@ -326,12 +325,12 @@ Compilation *Driver::BuildCompilation(Ar
// should be outside in the client; the parts that aren't should have proper
// options, either by introducing new ones or by overloading gcc ones like -V
// or -b.
- CCCPrintActions = Args-hasArg(options::OPT_ccc_print_phases);
- CCCPrintBindings = Args-hasArg(options::OPT_ccc_print_bindings);
- if (const Arg *A = Args-getLastArg(options::OPT_ccc_gcc_name))
+ CCCPrintActions = Args.hasArg(options::OPT_ccc_print_phases);
+ CCCPrintBindings = Args.hasArg(options::OPT_ccc_print_bindings);
+ if (const Arg *A = Args.getLastArg(options::OPT_ccc_gcc_name))
CCCGenericGCCName = A-getValue();
- CCCUsePCH = Args-hasFlag(options::OPT_ccc_pch_is_pch,
-options::OPT_ccc_pch_is_pth);
+ CCCUsePCH =
+ Args.hasFlag(options::OPT_ccc_pch_is_pch, options::OPT_ccc_pch_is_pth);
// FIXME: DefaultTargetTriple is used by the target-prefixed calls to as/ld
// and getToolChain is const.
if (IsCLMode()) {
@@ -341,39 +340,42
[clang-tools-extra] r240348 - Update for LLVM API change to return by InputArgList directly (rather than by pointer) from ParseArgs
Author: dblaikie Date: Mon Jun 22 17:06:58 2015 New Revision: 240348 URL: http://llvm.org/viewvc/llvm-project?rev=240348view=rev Log: Update for LLVM API change to return by InputArgList directly (rather than by pointer) from ParseArgs Modified: clang-tools-extra/trunk/modularize/Modularize.cpp Modified: clang-tools-extra/trunk/modularize/Modularize.cpp URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/Modularize.cpp?rev=240348r1=240347r2=240348view=diff == --- clang-tools-extra/trunk/modularize/Modularize.cpp (original) +++ clang-tools-extra/trunk/modularize/Modularize.cpp Mon Jun 22 17:06:58 2015 @@ -323,9 +323,9 @@ static std::string findInputFile(const C E = CLArgs.end(); I != E; ++I) Argv.push_back(I-c_str()); - std::unique_ptrInputArgList Args(Opts-ParseArgs( - Argv, MissingArgIndex, MissingArgCount, IncludedFlagsBitmask)); - std::vectorstd::string Inputs = Args-getAllArgValues(OPT_INPUT); + InputArgList Args = Opts-ParseArgs(Argv, MissingArgIndex, MissingArgCount, + IncludedFlagsBitmask); + std::vectorstd::string Inputs = Args.getAllArgValues(OPT_INPUT); return ModularizeUtilities::getCanonicalPath(Inputs.back()); } ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] clarify ownership of BugReport objects
On Mon, Jun 22, 2015 at 10:48 AM, Aaron Ballman aa...@aaronballman.com wrote: Updated patch attached. On Mon, Jun 22, 2015 at 12:23 PM, David Blaikie dblai...@gmail.com wrote: I'm assuming emitReport always takes ownership? (it doesn't look like it has any API surface area to express to the caller (in the current raw pointer API) that it didn't take ownership) In that case, best to pass by value rather than (lvalue or rvalue) reference so caller's explicitly pass off ownership (std::move(R)) to emitReport. Fixed. You'll have to use llvm::make_unique, rather than std::make_unique - since we're still compiling as C++11, not C++14. Fixed. I probably wouldn't bother renaming R to UniqueR in emitReport - don't think it adds/changes much. Ah, I see - there already was a UniqueR and R. Probably just use R, though? (now that it's the only thing, so there's no need to distinguish it as the unique one) Fixed. Looks like a reformat of an unchanged/unrelated line: - BugReportEquivClass* EQ = EQClasses.FindNodeOrInsertPos(ID, InsertPos); + BugReportEquivClass *EQ = EQClasses.FindNodeOrInsertPos(ID, InsertPos); Removed (will commit separately). Will leave it to Anna to sign off on, but looks like an improvement to me. (my usual generic question on changes like this (should probably be treated separately from this patch, if you've interest): could we use this by value instead of by pointer? I see BugReport has virtual functions but not sure it has any derived classes (the Doxygen docs don't seem to indicate any?)) ~Aaron And where does emitReport actually take ownership? On Mon, Jun 22, 2015 at 8:07 AM, Aaron Ballman aa...@aaronballman.com wrote: Currently, when the analyzer wants to emit a report, it takes a naked pointer, and the emitReport function eventually takes over ownership of that pointer. I think this is a dangerous API because it's not particularly clear that this ownership transfer will happen, or that the pointer must be unique. This patch makes the ownership semantics more clear by encoding it as part of the API. There should be no functional changes, and I do not think it caught any bugs, but I do think this is an improvement. Thoughts or opinions? ~Aaron ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
[clang-tools-extra] r240239 - Update for ParseARgs ArrayRef-ification
Author: dblaikie Date: Sun Jun 21 01:58:19 2015 New Revision: 240239 URL: http://llvm.org/viewvc/llvm-project?rev=240239view=rev Log: Update for ParseARgs ArrayRef-ification Modified: clang-tools-extra/trunk/modularize/Modularize.cpp Modified: clang-tools-extra/trunk/modularize/Modularize.cpp URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/modularize/Modularize.cpp?rev=240239r1=240238r2=240239view=diff == --- clang-tools-extra/trunk/modularize/Modularize.cpp (original) +++ clang-tools-extra/trunk/modularize/Modularize.cpp Sun Jun 21 01:58:19 2015 @@ -323,9 +323,8 @@ static std::string findInputFile(const C E = CLArgs.end(); I != E; ++I) Argv.push_back(I-c_str()); - std::unique_ptrInputArgList Args( - Opts-ParseArgs(Argv.data(), Argv.data() + Argv.size(), MissingArgIndex, - MissingArgCount, IncludedFlagsBitmask)); + std::unique_ptrInputArgList Args(Opts-ParseArgs( + Argv, MissingArgIndex, MissingArgCount, IncludedFlagsBitmask)); std::vectorstd::string Inputs = Args-getAllArgValues(OPT_INPUT); return ModularizeUtilities::getCanonicalPath(Inputs.back()); } ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r240237 - ArrayRef-ify ParseArgs
Author: dblaikie
Date: Sun Jun 21 01:32:36 2015
New Revision: 240237
URL: http://llvm.org/viewvc/llvm-project?rev=240237view=rev
Log:
ArrayRef-ify ParseArgs
Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/tools/driver/cc1as_main.cpp
cfe/trunk/tools/driver/driver.cpp
Modified: cfe/trunk/lib/Driver/Driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=240237r1=240236r2=240237view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Sun Jun 21 01:32:36 2015
@@ -115,10 +115,9 @@ InputArgList *Driver::ParseArgStrings(Ar
getIncludeExcludeOptionFlagMasks();
unsigned MissingArgIndex, MissingArgCount;
- InputArgList *Args = getOpts().ParseArgs(ArgStrings.begin(),
ArgStrings.end(),
- MissingArgIndex, MissingArgCount,
- IncludedFlagsBitmask,
- ExcludedFlagsBitmask);
+ InputArgList *Args =
+ getOpts().ParseArgs(ArgStrings, MissingArgIndex, MissingArgCount,
+ IncludedFlagsBitmask, ExcludedFlagsBitmask);
// Check for missing argument error.
if (MissingArgCount)
Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=240237r1=240236r2=240237view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Sun Jun 21 01:32:36 2015
@@ -1848,8 +1848,8 @@ bool CompilerInvocation::CreateFromArgs(
const unsigned IncludedFlagsBitmask = options::CC1Option;
unsigned MissingArgIndex, MissingArgCount;
std::unique_ptrInputArgList Args(
- Opts-ParseArgs(ArgBegin, ArgEnd, MissingArgIndex, MissingArgCount,
- IncludedFlagsBitmask));
+ Opts-ParseArgs(llvm::makeArrayRef(ArgBegin, ArgEnd), MissingArgIndex,
+ MissingArgCount, IncludedFlagsBitmask));
// Check for missing argument error.
if (MissingArgCount) {
Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=240237r1=240236r2=240237view=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Sun Jun 21 01:32:36 2015
@@ -161,9 +161,8 @@ bool AssemblerInvocation::CreateFromArgs
const unsigned IncludedFlagsBitmask = options::CC1AsOption;
unsigned MissingArgIndex, MissingArgCount;
- std::unique_ptrInputArgList Args(
- OptTbl-ParseArgs(Argv.begin(), Argv.end(), MissingArgIndex,
MissingArgCount,
-IncludedFlagsBitmask));
+ std::unique_ptrInputArgList Args(OptTbl-ParseArgs(
+ Argv, MissingArgIndex, MissingArgCount, IncludedFlagsBitmask));
// Check for missing argument error.
if (MissingArgCount) {
Modified: cfe/trunk/tools/driver/driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/driver.cpp?rev=240237r1=240236r2=240237view=diff
==
--- cfe/trunk/tools/driver/driver.cpp (original)
+++ cfe/trunk/tools/driver/driver.cpp Sun Jun 21 01:32:36 2015
@@ -321,12 +321,12 @@ static void FixupDiagPrefixExeName(TextD
// This lets us create the DiagnosticsEngine with a properly-filled-out
// DiagnosticOptions instance.
static DiagnosticOptions *
-CreateAndPopulateDiagOpts(SmallVectorImplconst char * argv) {
+CreateAndPopulateDiagOpts(ArrayRefconst char * argv) {
auto *DiagOpts = new DiagnosticOptions;
std::unique_ptrOptTable Opts(createDriverOptTable());
unsigned MissingArgIndex, MissingArgCount;
- std::unique_ptrInputArgList Args(Opts-ParseArgs(
- argv.begin() + 1, argv.end(), MissingArgIndex, MissingArgCount));
+ std::unique_ptrInputArgList Args(
+ Opts-ParseArgs(argv.slice(1), MissingArgIndex, MissingArgCount));
// We ignore MissingArgCount and the return value of ParseDiagnosticArgs.
// Any errors that would be diagnosed here will also be diagnosed later,
// when the DiagnosticsEngine actually exists.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] make use of default parameter for IRBuilder.Createcall
Looks good - thanks!
On Jun 14, 2015 1:21 PM, servuswiege...@yahoo.de wrote:
From: Pete Abred servuswiege...@yahoo.de
Adapt users of IRBuilder.CreateCall function with no function parameters
to make use of the added default parameter value.
---
lib/CodeGen/CGBuiltin.cpp | 18 +-
lib/CodeGen/CGClass.cpp | 2 +-
lib/CodeGen/CGDecl.cpp | 2 +-
lib/CodeGen/CGExpr.cpp | 2 +-
lib/CodeGen/CGObjC.cpp | 2 +-
lib/CodeGen/CGObjCRuntime.cpp | 2 +-
lib/CodeGen/CodeGenFunction.cpp | 2 +-
lib/CodeGen/ItaniumCXXABI.cpp | 8
8 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp
index d86534d..d17629b 100644
--- a/lib/CodeGen/CGBuiltin.cpp
+++ b/lib/CodeGen/CGBuiltin.cpp
@@ -489,7 +489,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
FunctionDecl *FD,
}
case Builtin::BI__builtin_readcyclecounter: {
Value *F = CGM.getIntrinsic(Intrinsic::readcyclecounter);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__builtin___clear_cache: {
Value *Begin = EmitScalarExpr(E-getArg(0));
@@ -499,11 +499,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
FunctionDecl *FD,
}
case Builtin::BI__builtin_trap: {
Value *F = CGM.getIntrinsic(Intrinsic::trap);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__debugbreak: {
Value *F = CGM.getIntrinsic(Intrinsic::debugtrap);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__builtin_unreachable: {
if (SanOpts.has(SanitizerKind::Unreachable)) {
@@ -881,7 +881,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
FunctionDecl *FD,
}
case Builtin::BI__builtin_unwind_init: {
Value *F = CGM.getIntrinsic(Intrinsic::eh_unwind_init);
-return RValue::get(Builder.CreateCall(F, {}));
+return RValue::get(Builder.CreateCall(F));
}
case Builtin::BI__builtin_extend_pointer: {
// Extends a pointer to the size of an _Unwind_Word, which is
@@ -920,7 +920,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
FunctionDecl *FD,
// Store the stack pointer to the setjmp buffer.
Value *StackAddr =
-Builder.CreateCall(CGM.getIntrinsic(Intrinsic::stacksave), {});
+Builder.CreateCall(CGM.getIntrinsic(Intrinsic::stacksave));
Value *StackSaveSlot =
Builder.CreateGEP(Buf, ConstantInt::get(Int32Ty, 2));
Builder.CreateStore(StackAddr, StackSaveSlot);
@@ -3301,7 +3301,7 @@ Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned
BuiltinID,
: InlineAsm::get(FTy, .inst 0x + utohexstr(ZExtValue),
,
/*SideEffects=*/true);
-return Builder.CreateCall(Emit, {});
+return Builder.CreateCall(Emit);
}
if (BuiltinID == ARM::BI__builtin_arm_dbg) {
@@ -3445,7 +3445,7 @@ Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned
BuiltinID,
if (BuiltinID == ARM::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::arm_clrex);
-return Builder.CreateCall(F, {});
+return Builder.CreateCall(F);
}
// CRC32
@@ -4204,7 +4204,7 @@ Value
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
if (BuiltinID == AArch64::BI__builtin_arm_clrex) {
Function *F = CGM.getIntrinsic(Intrinsic::aarch64_clrex);
-return Builder.CreateCall(F, {});
+return Builder.CreateCall(F);
}
// CRC32
@@ -6133,7 +6133,7 @@ Value *CodeGenFunction::EmitX86BuiltinExpr(unsigned
BuiltinID,
break;
}
-Value *Call = Builder.CreateCall(CGM.getIntrinsic(ID), {});
+Value *Call = Builder.CreateCall(CGM.getIntrinsic(ID));
Builder.CreateStore(Builder.CreateExtractValue(Call, 0), Ops[0]);
return Builder.CreateExtractValue(Call, 1);
}
diff --git a/lib/CodeGen/CGClass.cpp b/lib/CodeGen/CGClass.cpp
index cd75da2..a048a11 100644
--- a/lib/CodeGen/CGClass.cpp
+++ b/lib/CodeGen/CGClass.cpp
@@ -2215,7 +2215,7 @@ void CodeGenFunction::EmitVTablePtrCheck(const
CXXRecordDecl *RD,
Builder.CreateCondBr(BitSetTest, ContBlock, TrapBlock);
EmitBlock(TrapBlock);
- Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::trap), {});
+ Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::trap));
Builder.CreateUnreachable();
EmitBlock(ContBlock);
diff --git a/lib/CodeGen/CGDecl.cpp b/lib/CodeGen/CGDecl.cpp
index 579a041..fdbf1f6 100644
--- a/lib/CodeGen/CGDecl.cpp
+++ b/lib/CodeGen/CGDecl.cpp
@@ -990,7 +990,7 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl D) {
llvm::Value *Stack = CreateTempAlloca(Int8PtrTy, saved_stack);
llvm::Value *F = CGM.getIntrinsic(llvm::Intrinsic::stacksave);
- llvm::Value *V = Builder.CreateCall(F, {});
+
Re: r239665 - Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics in VerifyDiagnosticsConsumer
On Sat, Jun 13, 2015 at 9:32 AM, Eric Fiselier e...@efcs.ca wrote:
On Sat, Jun 13, 2015 at 12:16 PM, David Blaikie dblai...@gmail.com
wrote:
On Sat, Jun 13, 2015 at 12:11 AM, Eric Fiselier e...@efcs.ca wrote:
Author: ericwf
Date: Sat Jun 13 02:11:40 2015
New Revision: 239665
URL: http://llvm.org/viewvc/llvm-project?rev=239665view=rev
Log:
Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics
in
VerifyDiagnosticsConsumer
Summary:
The goal of this patch is to make `-verify` easier to use when testing
libc++. The `notes` attached to compile error diagnostics are numerous
and
relatively unstable when they reference libc++ header internals. This
patch
allows libc++ to write stable compilation failure tests by allowing
unexpected diagnostic messages to be ignored where they are not
relevant.
Would it be better to have a flag that only ignores notes (or do we have
a
flag that disables notes? That might be generically useful?).
-verify-ignore-unexpected=note will only ignore notes.
I'd be concerned that ignoring unexpected diagnostics could hide
warnings/errors in libc++?
I agree with your concerns. Within libc++ I was only planning on
ignoring notes, and possibly
warnings in some contexts (C++11 extensions warnings for example).
However I felt that providing '-verify-ignore-unexpected' and
'-verify-ignore-unexpected=Levels'
was a better, more generic, solution than just providing something
like '-verify-ignore-unexpected-notes'.
Oh, fair enough - seems I could've read a bit more carefully/completely.
Sorry for the noise thanks for the explanation!
- Dave
/Eric
This patch adds a new CC1 flag called `-verify-ignore-unexpected`.
`-verify-ignore-unexpected` tells `VerifyDiagnosticsConsumer` to ignore
*all* unexpected diagnostic messages.
`-verify-ignore-unexpected=LevelList` can be used to only ignore
certain
diagnostic levels. `LevelList` is a comma separated list of diagnostic
levels to ignore. The supported levels are `note`, `remark`, `warning`
and
`error`.
Reviewers: bogner, grosser, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10138
Added:
cfe/trunk/lib/Basic/DiagnosticOptions.cpp
cfe/trunk/test/Frontend/verify-ignore-unexpected.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticOptions.def
cfe/trunk/include/clang/Basic/DiagnosticOptions.h
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticOptions.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticOptions.def?rev=239665r1=239664r2=239665view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.def (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.def Sat Jun 13
02:11:40 2015
@@ -69,7 +69,10 @@ ENUM_DIAGOPT(ShowOverloads, OverloadsSho
DIAGOPT(VerifyDiagnostics, 1, 0) /// Check that diagnostics match the
expected
/// diagnostics, indicated by markers
in
the
/// input source file.
-
+ENUM_DIAGOPT(VerifyIgnoreUnexpected, DiagnosticLevelMask, 4,
+ DiagnosticLevelMask::None) /// Ignore unexpected
diagnostics
of
+/// the specified levels when
using
+/// -verify.
DIAGOPT(ElideType, 1, 0) /// Elide identical types in template
diffing
DIAGOPT(ShowTemplateTree, 1, 0) /// Print a template tree when diffing
DIAGOPT(CLFallbackMode, 1, 0)/// Format for clang-cl fallback mode
Modified: cfe/trunk/include/clang/Basic/DiagnosticOptions.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticOptions.h?rev=239665r1=239664r2=239665view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.h (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.h Sat Jun 13
02:11:40
2015
@@ -13,6 +13,7 @@
#include clang/Basic/LLVM.h
#include llvm/ADT/IntrusiveRefCntPtr.h
#include string
+#include type_traits
#include vector
namespace clang {
@@ -24,6 +25,38 @@ enum OverloadsShown : unsigned {
Ovl_Best /// Show just the best overload candidates.
};
+/// \brief A bitmask representing the diagnostic levels used by
+/// VerifyDiagnosticConsumer.
+enum class DiagnosticLevelMask : unsigned {
+ None= 0,
+ Note= 1 0,
+ Remark = 1 1,
+ Warning = 1 2,
+ Error = 1 3,
+ All = Note | Remark | Warning | Error
Re: r239665 - Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics in VerifyDiagnosticsConsumer
On Sat, Jun 13, 2015 at 12:11 AM, Eric Fiselier e...@efcs.ca wrote:
Author: ericwf
Date: Sat Jun 13 02:11:40 2015
New Revision: 239665
URL: http://llvm.org/viewvc/llvm-project?rev=239665view=rev
Log:
Add `-verify-ignore-unexpected` option to ignore unexpected diagnostics in
VerifyDiagnosticsConsumer
Summary:
The goal of this patch is to make `-verify` easier to use when testing
libc++. The `notes` attached to compile error diagnostics are numerous and
relatively unstable when they reference libc++ header internals. This patch
allows libc++ to write stable compilation failure tests by allowing
unexpected diagnostic messages to be ignored where they are not relevant.
Would it be better to have a flag that only ignores notes (or do we have a
flag that disables notes? That might be generically useful?).
I'd be concerned that ignoring unexpected diagnostics could hide
warnings/errors in libc++?
This patch adds a new CC1 flag called `-verify-ignore-unexpected`.
`-verify-ignore-unexpected` tells `VerifyDiagnosticsConsumer` to ignore
*all* unexpected diagnostic messages.
`-verify-ignore-unexpected=LevelList` can be used to only ignore certain
diagnostic levels. `LevelList` is a comma separated list of diagnostic
levels to ignore. The supported levels are `note`, `remark`, `warning` and
`error`.
Reviewers: bogner, grosser, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10138
Added:
cfe/trunk/lib/Basic/DiagnosticOptions.cpp
cfe/trunk/test/Frontend/verify-ignore-unexpected.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticOptions.def
cfe/trunk/include/clang/Basic/DiagnosticOptions.h
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/VerifyDiagnosticConsumer.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticOptions.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticOptions.def?rev=239665r1=239664r2=239665view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.def (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.def Sat Jun 13
02:11:40 2015
@@ -69,7 +69,10 @@ ENUM_DIAGOPT(ShowOverloads, OverloadsSho
DIAGOPT(VerifyDiagnostics, 1, 0) /// Check that diagnostics match the
expected
/// diagnostics, indicated by markers in
the
/// input source file.
-
+ENUM_DIAGOPT(VerifyIgnoreUnexpected, DiagnosticLevelMask, 4,
+ DiagnosticLevelMask::None) /// Ignore unexpected diagnostics
of
+/// the specified levels when
using
+/// -verify.
DIAGOPT(ElideType, 1, 0) /// Elide identical types in template
diffing
DIAGOPT(ShowTemplateTree, 1, 0) /// Print a template tree when diffing
DIAGOPT(CLFallbackMode, 1, 0)/// Format for clang-cl fallback mode
Modified: cfe/trunk/include/clang/Basic/DiagnosticOptions.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticOptions.h?rev=239665r1=239664r2=239665view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticOptions.h (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticOptions.h Sat Jun 13 02:11:40
2015
@@ -13,6 +13,7 @@
#include clang/Basic/LLVM.h
#include llvm/ADT/IntrusiveRefCntPtr.h
#include string
+#include type_traits
#include vector
namespace clang {
@@ -24,6 +25,38 @@ enum OverloadsShown : unsigned {
Ovl_Best /// Show just the best overload candidates.
};
+/// \brief A bitmask representing the diagnostic levels used by
+/// VerifyDiagnosticConsumer.
+enum class DiagnosticLevelMask : unsigned {
+ None= 0,
+ Note= 1 0,
+ Remark = 1 1,
+ Warning = 1 2,
+ Error = 1 3,
+ All = Note | Remark | Warning | Error
+};
+
+inline DiagnosticLevelMask operator~(DiagnosticLevelMask M) {
+ using UT = std::underlying_typeDiagnosticLevelMask::type;
+ return static_castDiagnosticLevelMask(~static_castUT(M));
+}
+
+inline DiagnosticLevelMask operator|(DiagnosticLevelMask LHS,
+ DiagnosticLevelMask RHS) {
+ using UT = std::underlying_typeDiagnosticLevelMask::type;
+ return static_castDiagnosticLevelMask(
+static_castUT(LHS) | static_castUT(RHS));
+}
+
+inline DiagnosticLevelMask operator(DiagnosticLevelMask LHS,
+ DiagnosticLevelMask RHS) {
+ using UT = std::underlying_typeDiagnosticLevelMask::type;
+ return static_castDiagnosticLevelMask(
+static_castUT(LHS) static_castUT(RHS));
+}
+
+raw_ostream operator(raw_ostream Out, DiagnosticLevelMask M);
+
/// \brief Options
Re: [PATCH] [CodeGen] Use IRBuilder to create llvm.lifetime intrinsics.
On Fri, Jun 12, 2015 at 2:11 PM, Alexey Samsonov vonos...@gmail.com wrote:
Hi aadg, dblaikie,
In addition to easier syntax, IRBuilder makes sure to set correct
debug locations for newly added instructions (bitcast and
llvm.lifetime itself). This restores the original behavior, which
was modified by r234581 (reapplied as r235553).
Extend one of the tests to check for debug locations.
http://reviews.llvm.org/D10418
Files:
lib/CodeGen/CGDecl.cpp
test/CodeGen/cleanup-destslot-simple.c
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -864,20 +864,17 @@
return nullptr;
llvm::Value *SizeV = llvm::ConstantInt::get(Int64Ty, Size);
- llvm::Value *Args[] = {
- SizeV,
- new llvm::BitCastInst(Addr, Int8PtrTy, ,
Builder.GetInsertBlock())};
- llvm::CallInst *C =
llvm::CallInst::Create(CGM.getLLVMLifetimeStartFn(), Args,
- ,
Builder.GetInsertBlock());
+ Addr = Builder.CreateBitCast(Addr, Int8PtrTy);
+ llvm::Value *Args[] = {SizeV, Addr};
+ llvm::CallInst *C = Builder.CreateCall(CGM.getLLVMLifetimeStartFn(),
Args);
Seems simple enough/good to me. Please commit.
(if anyone feels like simplifying this code a bit, it could be written as:
... CreateCall(..., {SizeV, Addr});
drop the Args variable entirely.
C-setDoesNotThrow();
return SizeV;
}
void CodeGenFunction::EmitLifetimeEnd(llvm::Value *Size, llvm::Value
*Addr) {
- llvm::Value *Args[] = {Size, new llvm::BitCastInst(Addr, Int8PtrTy, ,
-
Builder.GetInsertBlock())};
- llvm::CallInst *C = llvm::CallInst::Create(CGM.getLLVMLifetimeEndFn(),
Args,
- ,
Builder.GetInsertBlock());
+ Addr = Builder.CreateBitCast(Addr, Int8PtrTy);
+ llvm::Value *Args[] = {Size, Addr};
+ llvm::CallInst *C = Builder.CreateCall(CGM.getLLVMLifetimeEndFn(),
Args);
C-setDoesNotThrow();
}
Index: test/CodeGen/cleanup-destslot-simple.c
===
--- test/CodeGen/cleanup-destslot-simple.c
+++ test/CodeGen/cleanup-destslot-simple.c
@@ -13,7 +13,9 @@
return *p;
// CHECK: [[X:%.*]] = alloca i32
// CHECK: [[P:%.*]] = alloca i32*
-// LIFETIME: call void @llvm.lifetime.start(i64 4, i8* %{{.*}})
-// LIFETIME: call void @llvm.lifetime.start(i64 8, i8* %{{.*}})
+// LIFETIME: call void @llvm.lifetime.start(i64 4, i8* %{{.*}}){{(
#[0-9]+)?}}, !dbg
+// LIFETIME: call void @llvm.lifetime.start(i64 8, i8* %{{.*}}){{(
#[0-9]+)?}}, !dbg
// CHECK-NOT: store i32 %{{.*}}, i32* %cleanup.dest.slot
+// LIFETIME: call void @llvm.lifetime.end(i64 8, {{.*}}){{( #[0-9]+)?}},
!dbg
+// LIFETIME: call void @llvm.lifetime.end(i64 4, {{.*}}){{( #[0-9]+)?}},
!dbg
}
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r239600 - clang-format: Always add space before lambda-{
On Fri, Jun 12, 2015 at 2:59 AM, Daniel Jasper djas...@google.com wrote:
Author: djasper
Date: Fri Jun 12 04:59:16 2015
New Revision: 239600
URL: http://llvm.org/viewvc/llvm-project?rev=239600view=rev
Log:
clang-format: Always add space before lambda-{
Before:
int c = []() - int *{ return 2; }();
After:
int c = []() - int * { return 2; }();
Side note ( perhaps this is impossible to test in LLVM now, given how much
clang-formatting has already happened): Do people usually put a space
before the '*' when the type is mentioned in a non-declarative context
(when they're not declaring a variable)
My usual habit, in things like template parameters, was not to bother with
the space: std::vectorint* - I've not really minded clang-format adding
the space there and maybe that's other people's habit anyway, but here on
the lambda return type it feels a bit more odd to me.
- Dave
Based on patch by James Dennett (http://reviews.llvm.org/D10410), thank
you!
Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTest.cpp
Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=239600r1=239599r2=239600view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Fri Jun 12 04:59:16 2015
@@ -1800,6 +1800,7 @@ bool TokenAnnotator::spaceRequiredBetwee
return true;
if (Left.is(TT_PointerOrReference))
return Right.Tok.isLiteral() || Right.is(TT_BlockComment) ||
+ (Right.is(tok::l_brace) Right.BlockKind == BK_Block) ||
(!Right.isOneOf(TT_PointerOrReference,
TT_ArraySubscriptLSquare,
tok::l_paren)
(Style.PointerAlignment != FormatStyle::PAS_Right
Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=239600r1=239599r2=239600view=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Fri Jun 12 04:59:16 2015
@@ -10098,6 +10098,7 @@ TEST_F(FormatTest, FormatsLambdas) {
// Lambdas with return types.
verifyFormat(int c = []() - int { return 2; }();\n);
+ verifyFormat(int c = []() - int * { return 2; }();\n);
verifyFormat(int c = []() - vectorint { return {2}; }();\n);
verifyFormat(Foo([]() - std::vectorint { return {2}; }()););
verifyGoogleFormat(auto a = [b, c](D* d) - D* {};);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r238547 - Refactor MacroInfo so macro arguments can be iterated with range-based for loops.
On Fri, May 29, 2015 at 2:15 AM, Daniel Marjamaki
daniel.marjam...@evidente.se wrote:
Author: danielmarjamaki
Date: Fri May 29 04:15:24 2015
New Revision: 238547
URL: http://llvm.org/viewvc/llvm-project?rev=238547view=rev
Log:
Refactor MacroInfo so macro arguments can be iterated with range-based for
loops.
No functional change intended.
Patch by Sebastian Edman!
Modified:
cfe/trunk/include/clang/Lex/MacroInfo.h
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
Modified: cfe/trunk/include/clang/Lex/MacroInfo.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/MacroInfo.h?rev=238547r1=238546r2=238547view=diff
==
--- cfe/trunk/include/clang/Lex/MacroInfo.h (original)
+++ cfe/trunk/include/clang/Lex/MacroInfo.h Fri May 29 04:15:24 2015
@@ -178,10 +178,13 @@ public:
arg_iterator arg_begin() const { return ArgumentList; }
arg_iterator arg_end() const { return ArgumentList + NumArguments; }
unsigned getNumArgs() const { return NumArguments; }
+ ArrayRefconst IdentifierInfo * args() const {
+return ArrayRefconst IdentifierInfo *(ArgumentList, NumArguments);
Perhaps we should just roll these two members into one ArrayRef member to
begin with?
+ }
/// \brief Return the argument number of the specified identifier,
/// or -1 if the identifier is not a formal argument identifier.
- int getArgumentNum(IdentifierInfo *Arg) const {
+ int getArgumentNum(const IdentifierInfo *Arg) const {
for (arg_iterator I = arg_begin(), E = arg_end(); I != E; ++I)
if (*I == Arg)
return I - arg_begin();
Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=238547r1=238546r2=238547view=diff
==
--- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
+++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Fri May 29 04:15:24 2015
@@ -362,12 +362,8 @@ static bool isTrivialSingleTokenExpansio
// If this is a function-like macro invocation, it's safe to trivially
expand
// as long as the identifier is not a macro argument.
- for (MacroInfo::arg_iterator I = MI-arg_begin(), E = MI-arg_end();
- I != E; ++I)
-if (*I == II)
- return false; // Identifier is a macro argument.
+ return std::find(MI-arg_begin(), MI-arg_end(), II) == MI-arg_end();
- return true;
}
Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=238547r1=238546r2=238547view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp Fri May 29 04:15:24 2015
@@ -2135,9 +2135,8 @@ void ASTWriter::WritePreprocessor(const
Record.push_back(MI-isGNUVarargs());
Record.push_back(MI-hasCommaPasting());
Record.push_back(MI-getNumArgs());
- for (MacroInfo::arg_iterator I = MI-arg_begin(), E = MI-arg_end();
- I != E; ++I)
-AddIdentifierRef(*I, Record);
+ for (const IdentifierInfo *Arg : MI-args())
+AddIdentifierRef(Arg, Record);
}
// If we have a detailed preprocessing record, record the macro
definition
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] C99 partial re-initialization behavior (DR-253)
() + 1486 36 clang 0x013a8ac1 clang::FrontendAction::Execute() + 139 37 clang 0x0136c902 clang::CompilerInstance::ExecuteAction(clang::FrontendAction) + 772 38 clang 0x0132dadb clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 993 39 clang 0x01318d68 cc1_main(llvm::ArrayRefchar const*, char const*, void*) + 770 40 clang 0x01327500 41 clang 0x01327ae7 main + 1074 42 libc.so.6 0x7fedcc106ec5 __libc_start_main + 245 43 clang 0x01317469 Stack dump: 0. Program arguments: build/Debug+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -disable-free -main-file-name test.cpp -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.24 -dwarf-column-info -coverage-file /tmp/- -resource-dir build/Debug+Asserts/bin/../lib/clang/3.7.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/local/include -internal-isystem build/Debug+Asserts/bin/../lib/clang/3.7.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 205 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o - -x c++ test.cpp 1. eof parser at end of file 2. test.cpp:4:7: LLVM IR generation of declaration 'r' 3. test.cpp:4:7: Generating code for declaration 'r' clang: error: unable to execute command: Aborted (core dumped) clang: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.7.0 (trunk 238351) Target: x86_64-unknown-linux-gnu Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/test-d13456.cpp clang: note: diagnostic msg: /tmp/test-d13456.sh clang: note: diagnostic msg: From: David Blaikie [dblai...@gmail.com] Sent: Wednesday, May 27, 2015 3:26 PM To: reviews+d5789+public+1cf6f6f096f4f...@reviews.llvm.org Cc: Gao, Yunzhong; Richard Smith; dccitali...@gmail.com; Robinson, Paul; arthur.j.odwyer+phab+git...@gmail.com; Anton Korobeynikov; llvm cfe Subject: Re: [PATCH] C99 partial re-initialization behavior (DR-253) On Wed, May 27, 2015 at 1:34 PM, Yunzhong Gao yunzhong_...@playstation.sony.commailto:yunzhong_...@playstation.sony.com wrote: Ping. Also add David Blaikie. He might have some insight on whether lib/CodeGen/CGExprCXX.cpp#952-953 indicates any actual problem. Don't think I have any particular light to shed here... if you/we want to dive into this deeper, the backtrace from the assertion might be useful. http://reviews.llvm.org/D5789?id=22530#inline-76127 http://reviews.llvm.org/D5789 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] C99 partial re-initialization behavior (DR-253)
On Wed, May 27, 2015 at 1:34 PM, Yunzhong Gao yunzhong_...@playstation.sony.com wrote: Ping. Also add David Blaikie. He might have some insight on whether lib/CodeGen/CGExprCXX.cpp#952-953 indicates any actual problem. Don't think I have any particular light to shed here... if you/we want to dive into this deeper, the backtrace from the assertion might be useful. http://reviews.llvm.org/D5789?id=22530#inline-76127 http://reviews.llvm.org/D5789 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Refactor: Simplify boolean conditional return statements in lib/Edit
Comment at: lib/Edit/RewriteObjCFoundationAPI.cpp:631 @@ -630,6 +630,3 @@ -if (Vals.size() != Keys.size()) - return false; - -return true; +return Vals.size() == Keys.size(); } Looks like a chain (see prior review on your changes for more detail on what I mean by this) http://reviews.llvm.org/D10014 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Refactor: Simplify boolean conditional return statements in lib/Lex
LGTM http://reviews.llvm.org/D10017 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Refactor: Simplify boolean conditional return statements in lib/Sema
Got only part way through this one. We should come to some conclusion about these chained return cases - they seem fairly benign/not buggy/not worth changing. Basically what I mean when I say chain or possible chain is that it looks like this last if/return is just another case of several in the same function and shouldn't be treated differently by being rolled into one final return statement. Mostly the question I think that's worth asking is could I reasonably add another condition on to the end of this function? and if so, it hurts readability/writability by rolling it in and making it somehow different from the other cases in the function. I think this was a concern John McCall raised a few weeks ago on the same sort of changes you'd been proposing. Comment at: lib/Sema/SemaChecking.cpp:4627 @@ -4626,6 +4626,3 @@ - if (!isaTranslationUnitDecl(ND-getDeclContext())) -return false; - - return true; + return isaTranslationUnitDecl(ND-getDeclContext()); } Possible chain Comment at: lib/Sema/SemaChecking.cpp:8687 @@ -8692,6 +8686,3 @@ - if (checkUnsafeAssignObject(*this, Loc, LT, RHS, false)) -return true; - - return false; + return checkUnsafeAssignObject(*this, Loc, LT, RHS, false); } Possible chain Comment at: lib/Sema/SemaChecking.cpp:8782 @@ -8790,6 +8781,3 @@ // Warn if null statement and body are on the same line. - if (StmtLine != BodyLine) -return false; - - return true; + return StmtLine == BodyLine; } Possible chain Comment at: lib/Sema/SemaDecl.cpp:2531 @@ -2530,5 +2530,3 @@ return true; - if (OldLinkage == CLanguageLinkage New-isInExternCXXContext()) -return true; - return false; + return OldLinkage == CLanguageLinkage New-isInExternCXXContext(); } Possible chain Comment at: lib/Sema/SemaDecl.cpp:13607 @@ -13610,6 +13606,3 @@ - if (castEnumDecl(TagDecl::castFromDeclContext(ECD-getDeclContext())) != - Enum) -return true; - - return false; + return castEnumDecl(TagDecl::castFromDeclContext(ECD-getDeclContext())) != + Enum; Possible chain Comment at: lib/Sema/SemaDeclAttr.cpp:366 @@ -365,6 +365,3 @@ S.Context.DeclarationNames.getCXXOperatorName(OO_Arrow)); - if (Res2.empty()) -return false; - - return true; + return !Res2.empty(); } possible chain Comment at: lib/Sema/SemaDeclAttr.cpp:457 @@ -459,6 +456,3 @@ - if (checkRecordTypeForCapability(S, Ty)) -return true; - - return false; + return checkRecordTypeForCapability(S, Ty); } Possible chain Comment at: lib/Sema/SemaDeclAttr.cpp:1805 @@ -1813,6 +1804,3 @@ - if (BeforeIsOkay X Y) -return true; - - return false; + return BeforeIsOkay X Y; } possible chain http://reviews.llvm.org/D10019 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] __attribute__((enable_if)) and non-overloaded member functions
+Nick, conjurer of the enable_if attribute On Tue, May 26, 2015 at 1:20 PM, Ettore Speziale speziale.ett...@gmail.com wrote: Hello, the attached patch fixes the case where __attribute__((enable_if)) is sticked to a member function with no overloads. It seems that in these case clang does not execute the code about overload resolution which contains the check about __attribute__((enable_if)). Hence it would be possible to use a function protected by __attribute__((enable_if)) even if the __attribute__((enable_if)) predicate is false. Thanks, Ettore Speziale ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Refactor: Simplify boolean conditional return statements in lib/AST
Comment at: lib/AST/ASTImporter.cpp:401 @@ -400,6 +400,3 @@ return false; - if (Array1-getIndexTypeQualifiers() != Array2-getIndexTypeQualifiers()) -return false; - - return true; + return Array1-getIndexTypeQualifiers() == Array2-getIndexTypeQualifiers(); } Isn't this the sort of chained conditional you/we decided not to flag/suggest changes on? Comment at: lib/AST/Decl.cpp:2384 @@ -2383,5 +2383,3 @@ - if (isaCompoundStmt(S) castCompoundStmt(S)-body_empty()) -return true; - return false; + return isaCompoundStmt(S) castCompoundStmt(S)-body_empty(); } this should probably be: if (auto *CS = dyn_castCompoundStmt(S)) return CS-body_empty(); return false; Comment at: lib/AST/DeclBase.cpp:305 @@ -304,6 +304,3 @@ // Check for used attribute. - if (CheckUsedAttr hasAttrUsedAttr()) -return true; - - return false; + return CheckUsedAttr hasAttrUsedAttr(); } another possible 'chain' style return Comment at: lib/AST/DeclCXX.cpp:413 @@ -412,5 +412,3 @@ // -- has a trivial destructor. - if (!hasTrivialDestructor()) return false; - - return true; + return hasTrivialDestructor(); } Another chain return Comment at: lib/AST/Expr.cpp:2669 @@ -2668,6 +2668,3 @@ // - opaque values (all) - if (isaOpaqueValueExpr(E)) -return false; - - return true; + return !isaOpaqueValueExpr(E); } Possible chain Comment at: lib/AST/ExprConstant.cpp:207 @@ -206,5 +206,3 @@ return true; - if (MostDerivedArraySize - Entries[MostDerivedPathLength - 1].ArrayIndex == MostDerivedArraySize) -return true; - return false; + return MostDerivedArraySize + Entries[MostDerivedPathLength - 1].ArrayIndex == possible chain Comment at: lib/AST/ExprConstant.cpp:2220 @@ -2220,7 +2219,3 @@ // If we modified a bit-field, truncate it to the right width. - if (handler.AccessKind != AK_Read - LastField LastField-isBitField() - !truncateBitfieldValue(Info, E, *O, LastField)) -return false; - - return true; + return handler.AccessKind == AK_Read || !LastField || + !LastField-isBitField() || possible chain Comment at: lib/AST/ItaniumMangle.cpp:1869 @@ -1868,6 +1868,3 @@ return true; - if (Ty-isBuiltinType()) -return false; - - return true; + return !Ty-isBuiltinType(); } chain Comment at: lib/AST/ItaniumMangle.cpp:3728 @@ -3730,6 +3727,3 @@ - if (!isCharSpecialization(TemplateArgs[1].getAsType(), char_traits)) -return false; - - return true; + return isCharSpecialization(TemplateArgs[1].getAsType(), char_traits); } chain http://reviews.llvm.org/D10010 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Refactor: Simplify boolean conditional return statements in lib/Sema
On Tue, May 26, 2015 at 4:06 PM, Richard legal...@xmission.com wrote: In http://reviews.llvm.org/D10019#178722, @dblaikie wrote: We should come to some conclusion about these chained return cases - they seem fairly benign/not buggy/not worth changing. Ah... I see what you mean. So like the other case where it was something like `if (expr) var = true; else if (expr2) var = true; else if (expr3) var = true; else var = false;`, you'd like the option of disabling this check when it is a series of chained return statements? Yeah, they seem equivalent That's great feedback and is something I can do to enhance the check. http://reviews.llvm.org/D10019 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r237729 - [opaque pointer type] Pass the explicit call type when creating calls from LazyRuntimeFunctions
Author: dblaikie
Date: Tue May 19 16:31:34 2015
New Revision: 237729
URL: http://llvm.org/viewvc/llvm-project?rev=237729view=rev
Log:
[opaque pointer type] Pass the explicit call type when creating calls from
LazyRuntimeFunctions
The implicit conversion was causing issues for a helper being added that
would take an llvm::Function rather than an llvm::Value to make the
CallInst. Since we'll eventually need to specify the type of the call
explicitly anyway, fix these up to avoid the future ambiguity.
Modified:
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCGNU.cpp?rev=237729r1=237728r2=237729view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Tue May 19 16:31:34 2015
@@ -46,7 +46,7 @@ namespace {
/// avoids constructing the type more than once if it's used more than once.
class LazyRuntimeFunction {
CodeGenModule *CGM;
- std::vectorllvm::Type* ArgTys;
+ llvm::FunctionType *FTy;
const char *FunctionName;
llvm::Constant *Function;
@@ -64,30 +64,25 @@ public:
CGM = Mod;
FunctionName = name;
Function = nullptr;
-ArgTys.clear();
+std::vectorllvm::Type * ArgTys;
va_list Args;
va_start(Args, RetTy);
while (llvm::Type *ArgTy = va_arg(Args, llvm::Type *))
ArgTys.push_back(ArgTy);
va_end(Args);
-// Push the return type on at the end so we can pop it off easily
-ArgTys.push_back(RetTy);
+FTy = llvm::FunctionType::get(RetTy, ArgTys, false);
}
+
+ llvm::FunctionType *getType() { return FTy; }
+
/// Overloaded cast operator, allows the class to be implicitly cast to an
/// LLVM constant.
operator llvm::Constant *() {
if (!Function) {
if (!FunctionName)
return nullptr;
- // We put the return type on the end of the vector, so pop it back off
- llvm::Type *RetTy = ArgTys.back();
- ArgTys.pop_back();
- llvm::FunctionType *FTy = llvm::FunctionType::get(RetTy, ArgTys, false);
Function =
castllvm::Constant(CGM-CreateRuntimeFunction(FTy, FunctionName));
- // We won't need to use the types again, so we may as well clean up the
- // vector now
- ArgTys.resize(0);
}
return Function;
}
@@ -2687,7 +2682,7 @@ llvm::Value * CGObjCGNU::EmitObjCWeakRea
llvm::Value *AddrWeakObj) {
CGBuilderTy B = CGF.Builder;
AddrWeakObj = EnforceType(B, AddrWeakObj, PtrToIdTy);
- return B.CreateCall(WeakReadFn, AddrWeakObj);
+ return B.CreateCall(WeakReadFn.getType(), WeakReadFn, AddrWeakObj);
}
void CGObjCGNU::EmitObjCWeakAssign(CodeGenFunction CGF,
@@ -2695,7 +2690,7 @@ void CGObjCGNU::EmitObjCWeakAssign(CodeG
CGBuilderTy B = CGF.Builder;
src = EnforceType(B, src, IdTy);
dst = EnforceType(B, dst, PtrToIdTy);
- B.CreateCall(WeakAssignFn, {src, dst});
+ B.CreateCall(WeakAssignFn.getType(), WeakAssignFn, {src, dst});
}
void CGObjCGNU::EmitObjCGlobalAssign(CodeGenFunction CGF,
@@ -2706,7 +2701,7 @@ void CGObjCGNU::EmitObjCGlobalAssign(Cod
dst = EnforceType(B, dst, PtrToIdTy);
// FIXME. Add threadloca assign API
assert(!threadlocal EmitObjCGlobalAssign - Threal Local API NYI);
- B.CreateCall(GlobalAssignFn, {src, dst});
+ B.CreateCall(GlobalAssignFn.getType(), GlobalAssignFn, {src, dst});
}
void CGObjCGNU::EmitObjCIvarAssign(CodeGenFunction CGF,
@@ -2715,7 +2710,7 @@ void CGObjCGNU::EmitObjCIvarAssign(CodeG
CGBuilderTy B = CGF.Builder;
src = EnforceType(B, src, IdTy);
dst = EnforceType(B, dst, IdTy);
- B.CreateCall(IvarAssignFn, {src, dst, ivarOffset});
+ B.CreateCall(IvarAssignFn.getType(), IvarAssignFn, {src, dst, ivarOffset});
}
void CGObjCGNU::EmitObjCStrongCastAssign(CodeGenFunction CGF,
@@ -2723,7 +2718,7 @@ void CGObjCGNU::EmitObjCStrongCastAssign
CGBuilderTy B = CGF.Builder;
src = EnforceType(B, src, IdTy);
dst = EnforceType(B, dst, PtrToIdTy);
- B.CreateCall(StrongCastAssignFn, {src, dst});
+ B.CreateCall(StrongCastAssignFn.getType(), StrongCastAssignFn, {src, dst});
}
void CGObjCGNU::EmitGCMemmoveCollectable(CodeGenFunction CGF,
@@ -2734,7 +2729,7 @@ void CGObjCGNU::EmitGCMemmoveCollectable
DestPtr = EnforceType(B, DestPtr, PtrTy);
SrcPtr = EnforceType(B, SrcPtr, PtrTy);
- B.CreateCall(MemMoveFn, {DestPtr, SrcPtr, Size});
+ B.CreateCall(MemMoveFn.getType(), MemMoveFn, {DestPtr, SrcPtr, Size});
}
llvm::GlobalVariable *CGObjCGNU::ObjCIvarOffsetVariable(
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r237625 - API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init
Author: dblaikie
Date: Mon May 18 17:14:03 2015
New Revision: 237625
URL: http://llvm.org/viewvc/llvm-project?rev=237625view=rev
Log:
API update for streamlining of IRBuilder::CreateCall to just use
ArrayRef/initializer_list+braced init
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/CodeGen/CGExprScalar.cpp
cfe/trunk/lib/CodeGen/CGObjC.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CGObjCRuntime.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenPGO.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=237625r1=237624r2=237625view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Mon May 18 17:14:03 2015
@@ -205,7 +205,7 @@ static llvm::Value *EmitOverflowIntrinsi
arguments have the same integer width?));
llvm::Value *Callee = CGF.CGM.getIntrinsic(IntrinsicID, X-getType());
- llvm::Value *Tmp = CGF.Builder.CreateCall2(Callee, X, Y);
+ llvm::Value *Tmp = CGF.Builder.CreateCall(Callee, {X, Y});
Carry = CGF.Builder.CreateExtractValue(Tmp, 1);
return CGF.Builder.CreateExtractValue(Tmp, 0);
}
@@ -254,8 +254,8 @@ RValue CodeGenFunction::EmitBuiltinExpr(
DstPtr = Builder.CreateBitCast(DstPtr, Type);
SrcPtr = Builder.CreateBitCast(SrcPtr, Type);
-return RValue::get(Builder.CreateCall2(CGM.getIntrinsic(Intrinsic::vacopy),
- DstPtr, SrcPtr));
+return RValue::get(Builder.CreateCall(CGM.getIntrinsic(Intrinsic::vacopy),
+ {DstPtr, SrcPtr}));
}
case Builtin::BI__builtin_abs:
case Builtin::BI__builtin_labs:
@@ -333,7 +333,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::Type *ResultType = ConvertType(E-getType());
Value *ZeroUndef = Builder.getInt1(getTarget().isCLZForZeroUndef());
-Value *Result = Builder.CreateCall2(F, ArgValue, ZeroUndef);
+Value *Result = Builder.CreateCall(F, {ArgValue, ZeroUndef});
if (Result-getType() != ResultType)
Result = Builder.CreateIntCast(Result, ResultType, /*isSigned*/true,
cast);
@@ -350,7 +350,7 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::Type *ResultType = ConvertType(E-getType());
Value *ZeroUndef = Builder.getInt1(getTarget().isCLZForZeroUndef());
-Value *Result = Builder.CreateCall2(F, ArgValue, ZeroUndef);
+Value *Result = Builder.CreateCall(F, {ArgValue, ZeroUndef});
if (Result-getType() != ResultType)
Result = Builder.CreateIntCast(Result, ResultType, /*isSigned*/true,
cast);
@@ -366,9 +366,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(
Value *F = CGM.getIntrinsic(Intrinsic::cttz, ArgType);
llvm::Type *ResultType = ConvertType(E-getType());
-Value *Tmp = Builder.CreateAdd(Builder.CreateCall2(F, ArgValue,
- Builder.getTrue()),
- llvm::ConstantInt::get(ArgType, 1));
+Value *Tmp =
+Builder.CreateAdd(Builder.CreateCall(F, {ArgValue, Builder.getTrue()}),
+ llvm::ConstantInt::get(ArgType, 1));
Value *Zero = llvm::Constant::getNullValue(ArgType);
Value *IsZero = Builder.CreateICmpEQ(ArgValue, Zero, iszero);
Value *Result = Builder.CreateSelect(IsZero, Zero, Tmp, ffs);
@@ -421,8 +421,8 @@ RValue CodeGenFunction::EmitBuiltinExpr(
return RValue::get(ArgValue);
Value *FnExpect = CGM.getIntrinsic(Intrinsic::expect, ArgType);
-Value *Result = Builder.CreateCall2(FnExpect, ArgValue, ExpectedValue,
-expval);
+Value *Result =
+Builder.CreateCall(FnExpect, {ArgValue, ExpectedValue}, expval);
return RValue::get(Result);
}
case Builtin::BI__builtin_assume_aligned: {
@@ -473,7 +473,8 @@ RValue CodeGenFunction::EmitBuiltinExpr(
// FIXME: Get right address space.
llvm::Type *Tys[] = { ResType, Builder.getInt8PtrTy(0) };
Value *F = CGM.getIntrinsic(Intrinsic::objectsize, Tys);
-return RValue::get(Builder.CreateCall2(F,
EmitScalarExpr(E-getArg(0)),CI));
+return RValue::get(
+Builder.CreateCall(F, {EmitScalarExpr(E-getArg(0)), CI}));
}
case Builtin::BI__builtin_prefetch: {
Value *Locality, *RW, *Address = EmitScalarExpr(E-getArg(0));
@@ -484,25 +485,25 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::ConstantInt::get(Int32Ty, 3);
Value *Data = llvm::ConstantInt::get(Int32Ty, 1);
r237631 - Fix indentation
Author: dblaikie
Date: Mon May 18 17:51:39 2015
New Revision: 237631
URL: http://llvm.org/viewvc/llvm-project?rev=237631view=rev
Log:
Fix indentation
Modified:
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCGNU.cpp?rev=237631r1=237630r2=237631view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Mon May 18 17:51:39 2015
@@ -49,51 +49,51 @@ class LazyRuntimeFunction {
std::vectorllvm::Type* ArgTys;
const char *FunctionName;
llvm::Constant *Function;
- public:
-/// Constructor leaves this class uninitialized, because it is intended to
-/// be used as a field in another class and not all of the types that are
-/// used as arguments will necessarily be available at construction time.
-LazyRuntimeFunction()
- : CGM(nullptr), FunctionName(nullptr), Function(nullptr) {}
-/// Initialises the lazy function with the name, return type, and the types
-/// of the arguments.
-LLVM_END_WITH_NULL
-void init(CodeGenModule *Mod, const char *name,
-llvm::Type *RetTy, ...) {
- CGM =Mod;
- FunctionName = name;
- Function = nullptr;
- ArgTys.clear();
- va_list Args;
- va_start(Args, RetTy);
- while (llvm::Type *ArgTy = va_arg(Args, llvm::Type*))
- ArgTys.push_back(ArgTy);
- va_end(Args);
- // Push the return type on at the end so we can pop it off easily
- ArgTys.push_back(RetTy);
- }
- /// Overloaded cast operator, allows the class to be implicitly cast to an
- /// LLVM constant.
- operator llvm::Constant*() {
- if (!Function) {
- if (!FunctionName) return nullptr;
- // We put the return type on the end of the vector, so pop it back off
- llvm::Type *RetTy = ArgTys.back();
- ArgTys.pop_back();
- llvm::FunctionType *FTy = llvm::FunctionType::get(RetTy, ArgTys, false);
- Function =
- castllvm::Constant(CGM-CreateRuntimeFunction(FTy, FunctionName));
- // We won't need to use the types again, so we may as well clean up the
- // vector now
- ArgTys.resize(0);
- }
- return Function;
- }
- operator llvm::Function*() {
- return castllvm::Function((llvm::Constant*)*this);
- }
+public:
+ /// Constructor leaves this class uninitialized, because it is intended to
+ /// be used as a field in another class and not all of the types that are
+ /// used as arguments will necessarily be available at construction time.
+ LazyRuntimeFunction()
+ : CGM(nullptr), FunctionName(nullptr), Function(nullptr) {}
+ /// Initialises the lazy function with the name, return type, and the types
+ /// of the arguments.
+ LLVM_END_WITH_NULL
+ void init(CodeGenModule *Mod, const char *name, llvm::Type *RetTy, ...) {
+CGM = Mod;
+FunctionName = name;
+Function = nullptr;
+ArgTys.clear();
+va_list Args;
+va_start(Args, RetTy);
+while (llvm::Type *ArgTy = va_arg(Args, llvm::Type *))
+ ArgTys.push_back(ArgTy);
+va_end(Args);
+// Push the return type on at the end so we can pop it off easily
+ArgTys.push_back(RetTy);
+ }
+ /// Overloaded cast operator, allows the class to be implicitly cast to an
+ /// LLVM constant.
+ operator llvm::Constant *() {
+if (!Function) {
+ if (!FunctionName)
+return nullptr;
+ // We put the return type on the end of the vector, so pop it back off
+ llvm::Type *RetTy = ArgTys.back();
+ ArgTys.pop_back();
+ llvm::FunctionType *FTy = llvm::FunctionType::get(RetTy, ArgTys, false);
+ Function =
+ castllvm::Constant(CGM-CreateRuntimeFunction(FTy, FunctionName));
+ // We won't need to use the types again, so we may as well clean up the
+ // vector now
+ ArgTys.resize(0);
+}
+return Function;
+ }
+ operator llvm::Function *() {
+return castllvm::Function((llvm::Constant *)*this);
+ }
};
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r237401 - Fix Clang -Wsequence-point
Author: dblaikie
Date: Thu May 14 17:47:19 2015
New Revision: 237401
URL: http://llvm.org/viewvc/llvm-project?rev=237401view=rev
Log:
Fix Clang -Wsequence-point
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=237401r1=237400r2=237401view=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Thu May 14 17:47:19 2015
@@ -108,7 +108,7 @@ DiagnoseAvailabilityOfDecl(Sema S, Name
// For typedefs, if the typedef declaration appears available look
// to the underlying type to see if it is more restrictive.
- while (const TypedefNameDecl *TD = TD = dyn_castTypedefNameDecl(D)) {
+ while (const TypedefNameDecl *TD = dyn_castTypedefNameDecl(D)) {
if (Result == AR_Available) {
if (const TagType *TT = TD-getUnderlyingType()-getAsTagType()) {
D = TT-getDecl();
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r237326 - Add missing #include, found by modules build.
On May 13, 2015 6:17 PM, Richard Smith richard-l...@metafoo.co.uk wrote:
Author: rsmith
Date: Wed May 13 20:08:58 2015
New Revision: 237326
URL: http://llvm.org/viewvc/llvm-project?rev=237326view=rev
Log:
Add missing #include, found by modules build.
Modified:
cfe/trunk/include/clang/Lex/ExternalPreprocessorSource.h
Modified: cfe/trunk/include/clang/Lex/ExternalPreprocessorSource.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/ExternalPreprocessorSource.h?rev=237326r1=237325r2=237326view=diff
==
--- cfe/trunk/include/clang/Lex/ExternalPreprocessorSource.h (original)
+++ cfe/trunk/include/clang/Lex/ExternalPreprocessorSource.h Wed May 13
20:08:58 2015
@@ -17,6 +17,7 @@
namespace clang {
class IdentifierInfo;
+class Module;
So... His doesn't look like a #include ;)
/// \brief Abstract interface for external sources of preprocessor
/// information.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Fixed double-free in case of module loading error.
On Fri, May 8, 2015 at 3:11 PM, Artem Belevich t...@google.com wrote:
Hi echristo, rnk, dblaikie,
GetOutputStream() owns the stream it returns pointer to and the
pointer should never be freed by us. When we fail to load and exit
early, unique_ptr still holds the pointer and frees it which leads to
compiler crash when CompilerInstance attempts to free it again.
Added regression test for failed bitcode linking.
http://reviews.llvm.org/D9625
Files:
lib/CodeGen/CodeGenAction.cpp
test/CodeGen/link-bitcode-file.c
Index: lib/CodeGen/CodeGenAction.cpp
===
--- lib/CodeGen/CodeGenAction.cpp
+++ lib/CodeGen/CodeGenAction.cpp
@@ -629,7 +629,7 @@
std::unique_ptrASTConsumer
CodeGenAction::CreateASTConsumer(CompilerInstance CI, StringRef InFile) {
BackendAction BA = static_castBackendAction(Act);
- std::unique_ptrraw_pwrite_stream OS(GetOutputStream(CI, InFile, BA));
+ raw_pwrite_stream *OS(GetOutputStream(CI, InFile, BA));
Use = rather than () where both are valid (such as here):
raw_pwrite_stream *OS = GetOutputStream(...);
Otherwise looks good.
If you wanted to do some cleanup, perhaps GetOutputStream should return by
reference so there's no confusion about ownership passing.
if (BA != Backend_EmitNothing !OS)
return nullptr;
@@ -666,7 +666,7 @@
std::unique_ptrBackendConsumer Result(new BackendConsumer(
BA, CI.getDiagnostics(), CI.getCodeGenOpts(), CI.getTargetOpts(),
CI.getLangOpts(), CI.getFrontendOpts().ShowTimers, InFile,
- LinkModuleToUse, OS.release(), *VMContext, CoverageInfo));
+ LinkModuleToUse, OS, *VMContext, CoverageInfo));
BEConsumer = Result.get();
return std::move(Result);
}
Index: test/CodeGen/link-bitcode-file.c
===
--- test/CodeGen/link-bitcode-file.c
+++ test/CodeGen/link-bitcode-file.c
@@ -1,6 +1,9 @@
// RUN: %clang_cc1 -triple i386-pc-linux-gnu -DBITCODE -emit-llvm-bc -o
%t.bc %s
// RUN: %clang_cc1 -triple i386-pc-linux-gnu -mlink-bitcode-file %t.bc
-O3 -emit-llvm -o - %s | FileCheck -check-prefix=CHECK-NO-BC %s
// RUN: not %clang_cc1 -triple i386-pc-linux-gnu -DBITCODE
-mlink-bitcode-file %t.bc -O3 -emit-llvm -o - %s 21 | FileCheck
-check-prefix=CHECK-BC %s
+// Make sure we deal with failure to load the file.
+// RUN: not %clang_cc1 -triple i386-pc-linux-gnu -mlink-bitcode-file
no-such-file.bc \
+// RUN:-emit-llvm -o - %s 21 | FileCheck
-check-prefix=CHECK-NO-FILE %s
int f(void);
@@ -22,3 +25,5 @@
// CHECK-NO-BC-LABEL: define i32 @f
#endif
+
+// CHECK-NO-FILE: fatal error: cannot open file 'no-such-file.bc'
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r236751 - [opaque pointer type] Correctly pass the pointee type when creating a GEP constant expression
Author: dblaikie Date: Thu May 7 12:27:56 2015 New Revision: 236751 URL: http://llvm.org/viewvc/llvm-project?rev=236751view=rev Log: [opaque pointer type] Correctly pass the pointee type when creating a GEP constant expression 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=236751r1=236750r2=236751view=diff == --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original) +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Thu May 7 12:27:56 2015 @@ -2690,7 +2690,8 @@ CodeGenModule::GetAddrOfConstantCFString } // String. - Fields[2] = llvm::ConstantExpr::getGetElementPtr(GV-getType(), GV, Zeros); + Fields[2] = + llvm::ConstantExpr::getGetElementPtr(GV-getValueType(), GV, Zeros); if (isUTF16) // Cast the UTF16 string to the correct type. ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Have clang list the imported modules in the debug info
On Wed, May 6, 2015 at 3:15 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 2:52 PM, David Blaikie dblai...@gmail.com wrote: On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 2:35 PM, Eric Christopher echri...@gmail.com wrote: That said, add enough to the name for hashing purposes to make it hash uniquely? Or you can go down the path of hashing the type similar to the fission CU hashing (which is what type units were arguably designed to do in the first place if you take a look at the standard, we just only use them for ODR compliant languages etc right now). I suppose one could hash the entire module configuration + the mangled name and get something that is relatively stable. For implementation reasons it would be terrible to do the full fission hashing because that would mean that we would actually have to look up (and deserialize the type) in order to get to its ID when emitting an external type reference, which would void at least some of the performance gains we want from module debugging. I thought you were proposing using the mangled name of the type for the identifier anyway? Perhaps I misunderstood - what are you proposing to use? In any case, I'd prefer to see whatever it is hashed and used as the type unit signature for compatibility with DWARF5, rather than adding an extra/separate/new/non-standard way to do cross-unit/cross-fission type references. In the IR I’d /like/ to have a DIExternalTypeRef(DW_TAG_class_type, !”_ZTC6TypeName”, !1) with !1 being a reference to either the DIModule or the skeleton CU. Then the backend would emit the hash of the name if type units are enabled (C++/gdb) or the mangled name (+ the accelerator table entry) otherwise (ObjC and/or Darwin). If there is significant pushback to the latter, I’d be willing to have the backend emit a hash in both cases but we’d have to careful about what to exactly to hash for all the aforementioned reasons. I don't follow - if the mangled name is sufficient, then a hash of the mangled name should be what am I missing? If you don't have an ODR to rely on, then a mangled name seems insufficient just as the hash would be. -- adrian ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Have clang list the imported modules in the debug info
On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl apra...@apple.com wrote: On May 6, 2015, at 2:35 PM, Eric Christopher echri...@gmail.com wrote: On Wed, May 6, 2015 at 2:26 PM Adrian Prantl apra...@apple.com wrote: On May 5, 2015, at 8:07 PM, David Blaikie dblai...@gmail.com wrote: If we believe hash collisions to be an issue - then type units are broken and I'd like to figure out how to fix them, then use the same feature here. This led me to perform a little experiment: I had a python script calculate the MD5 sum of ~60.000 unique mangled type names that I extracted from the IR of a clang LTO build. There was not a single collision in the abbreviated 64-bit hashes, and I had to truncate the length of the hash values to 32 bits before I was able to produced even a single collision. I think now that hash collisions might be a red herring and a calculable risk that we can decide to ignore. The only thing that we cannot ignore here is that for ODR-less languages two types may legally have the same mangled name (and thus hash) when they are defined in two different modules. This means we can’t use type units for these languages and external type reference must be a pair of mangled name and module. If it's a new language then you designed your language poorly ;) I was actually referring to Objective-C(++) here :-) That said, add enough to the name for hashing purposes to make it hash uniquely? Or you can go down the path of hashing the type similar to the fission CU hashing (which is what type units were arguably designed to do in the first place if you take a look at the standard, we just only use them for ODR compliant languages etc right now). I suppose one could hash the entire module configuration + the mangled name and get something that is relatively stable. For implementation reasons it would be terrible to do the full fission hashing because that would mean that we would actually have to look up (and deserialize the type) in order to get to its ID when emitting an external type reference, which would void at least some of the performance gains we want from module debugging. I thought you were proposing using the mangled name of the type for the identifier anyway? Perhaps I misunderstood - what are you proposing to use? In any case, I'd prefer to see whatever it is hashed and used as the type unit signature for compatibility with DWARF5, rather than adding an extra/separate/new/non-standard way to do cross-unit/cross-fission type references. - David ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Have clang list the imported modules in the debug info
On Tue, May 5, 2015 at 5:00 PM, Adrian Prantl apra...@apple.com wrote: On May 5, 2015, at 3:14 PM, David Blaikie dblai...@gmail.com wrote: On Tue, May 5, 2015 at 3:01 PM, Adrian Prantl apra...@apple.com wrote: On May 5, 2015, at 9:59 AM, David Blaikie dblai...@gmail.com wrote: On Mon, May 4, 2015 at 4:46 PM, Adrian Prantl apra...@apple.com wrote: On May 4, 2015, at 1:31 PM, David Blaikie dblai...@gmail.com wrote: ... So you're going to need to implement fission (to at least some degree) support in LLDB, then? (to support the case where you haven't linked debug info with llvm-dsymutil, but you've hit one of these lookup problems where you need to cross possibly-conflicting modules) Yes. Specifically, it won’t support type units, and it will look up types by name rather than by signature. (cf. the second part of http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html ) How are you going to reference the types in the module's fission CU without type units/signatures? Are you going to emit type declarations into the normal CU and rely on the debugger to know that these declarations can be resolved by looking elsewhere? (just without the benefit of constraining that search to just looking for a matching TU?) If you look at the example in http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html, there will be an external type index (using the usual accelerator table format) that maps an external type’s UID to a pcm. In the pcm there is an extra accelerator table entry that maps UID to DIE offset. I mean I guess that's up to you, but seems like a relatively large workaround compared to supporting type units... (I mean certainly seems like strictly less work to do the workaround than implementing type units in LLDB, but a relatively large amount of work to do/throw away eventually once LLDB supports type units) It’s not primarily meant to be a workaround so LLDB doesn’t need to implement type units; the UIDs double as the key (decl context + name) to import types directly from the AST. The other advantage is that we won’t have to worry about MD5 hash collisions, but that’s more of a theoretical advantage. If there's a concern about collisions, we should fix that regardless (because we'll have the same problem with normal type units or modularized type units). My understanding is that split DWARF is disambiguating hash collisions by adding the full decl context and name to both the definition and the forward declaration: No, that's not a requirement. It's just an aspect of our implementation so we can put entities in the type when needed (such as for putting member function declarations in there to refererence from out of line member function definitions) In the simplest case, you can reference a type unit directly: DW_TAG_variable DW_AT_type [DW_FORM_ref_sig8] You’re right. The standard allows this, although all the examples in the appendix show the long form that LLVM also emits. Without any DW_TAG_structure_type/namespaces/etc. Once we have Bag O' DWARF, we'd move to that representation almost entirely. (the signature we're using for this is the mangled name of the type so it includes the decl context in the hash anyway) .. which, incidentally, will look a lot like this UID example, right? (for completeness, the UID type reference would look like this: DW_TAG_variable DW_AT_name “myC” DW_AT_type [DW_FORM_strp] “_ZTN1AS1BS1C” ) Oh I see, you mean hashing the mangled name and using it as a signature rather than emitting the name directly. Yes, that's what LLVM does for type units today. But then, to disambiguate, it would still be beneficial to have the mangled name available. If we believe hash collisions to be an issue - then type units are broken and I'd like to figure out how to fix them, then use the same feature here. So I think that hash collisions are actually handled for normal fission and we don’t need to worry about them. The bag o’dwarf will still contain the full decl context in the DWO, so it will be fine there, too. If we've already got ( have to use in the case of DWARF fallback for modules) to support a hash or other numeric identifier, it might be good to use that for everything rather than having two mechanisms? Generally, one way to do it is of course better than maintaining two :-) But using the UIDs in the .o file allows us to elide the the forward declarations from the .o file It doesn't, though - because we need the forward declarations to put members into (such as member function definitions - this'll come up even for modules quite commonly with any inline member function, for example - its definition will appear in the .o file and the definition DW_TAG_subprogram will need to DW_AT_specification pointing to the declaration of the member function - which
Re: [PATCH] Have clang list the imported modules in the debug info
On Tue, May 5, 2015 at 9:58 AM, Greg Clayton gclay...@apple.com wrote:
I much prefer the PCM/external type ref method we just implemented to the
current version of type units.
I don't follow LLDB development - is it a feature implemented in LLDB
you're referring to? How does it work?
Or you're referring to the mangled-name based identification that Adrian
was describing? (not implemented yet, just under discussion)
That is unless we fix the type units like we previously talked about to be
able to contain more than one type signature and then they become useful
again. As they are implemented right now, they are a hack to get type
uniquing working cheaply (COMDAT)
Cheaply as opposed to what expensive option? Having a debug aware linker?
That's a pretty big step for non-Darwin, so far as I know. (OK, so gold is
semi-debug-aware so it can build the gdb_index, but that's pretty
orthogonal to actually rebuilding the debug_info)
at the expense of and spread the types out over many many type units and
duplicating all decl contexts over and over and over for each type. I would
think that just referring to external types would also make compiling much
faster as you wouldn't have to emit type units for everything in each .o
file.
Sorry, not sure I'm following which parts you're referring to. The original
plan/prototype was to use type units in the module debug info - not to emit
them into each .o file. This allows existing DWARF consumers supporting
Fission and Type Units (granted that set is essentially {GDB}) to work with
module debug info for free (with the slight 'cheat' that type unit
references from .o files would refer to types not included in the .o file -
but that would be accessible somewhere in the total referenced debug info).
We could cheat in the other way and just emit all references from .o files
to modularized types as declarations, and let the DWARF consumer go looking
for a definition (and then the module debug info wouldn't have to be in the
form of type units).
But I think we agreed when we first talked about module debug info that an
improved type unit that could refer to arbitrary DIEs would be an ideal
design (essentially take echristo's proposal to roll type units back into
debug_info then extend the header to support a list of referencable DIEs
rather than just a single one, and use that).
- David
Greg
On May 4, 2015, at 4:46 PM, Adrian Prantl apra...@apple.com wrote:
On May 4, 2015, at 1:31 PM, David Blaikie dblai...@gmail.com wrote:
...
So you're going to need to implement fission (to at least some
degree) support in LLDB, then? (to support the case where you haven't
linked debug info with llvm-dsymutil, but you've hit one of these lookup
problems where you need to cross possibly-conflicting modules)
Yes. Specifically, it won’t support type units, and it will look up
types by name rather than by signature. (cf. the second part of
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html
)
How are you going to reference the types in the module's fission CU
without type units/signatures? Are you going to emit type declarations into
the normal CU and rely on the debugger to know that these declarations can
be resolved by looking elsewhere? (just without the benefit of constraining
that search to just looking for a matching TU?)
If you look at the example in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html,
there will be an external type index (using the usual accelerator table
format) that maps an external type’s UID to a pcm. In the pcm there is an
extra accelerator table entry that maps UID to DIE offset.
I mean I guess that's up to you, but seems like a relatively large
workaround compared to supporting type units... (I mean certainly seems
like strictly less work to do the workaround than implementing type units
in LLDB, but a relatively large amount of work to do/throw away eventually
once LLDB supports type units)
It’s not primarily meant to be a workaround so LLDB doesn’t need to
implement type units; the UIDs double as the key (decl context + name) to
import types directly from the AST. The other advantage is that we won’t
have to worry about MD5 hash collisions, but that’s more of a theoretical
advantage.
OK, so I think it's probably reasonable for now to just add
DW_TAG_modules to the CU for each referenced module (or does it have to be
each referenced submodule? (can two submodules within a single module be
contradictory/conflicting?)). Since we don't have any good way to reference
the module is a foreign unit while deduplicating that unit... there's not
much point having the imported_module - but if you think it adds anything,
I'm open to ideas.
It could help keeping things simpler.
Emitting it doesn’t add much semantic value because module imports
always occur at the top level, but it will make
Re: [PATCH] Have clang list the imported modules in the debug info
On Mon, May 4, 2015 at 4:46 PM, Adrian Prantl apra...@apple.com wrote:
On May 4, 2015, at 1:31 PM, David Blaikie dblai...@gmail.com wrote:
...
So you're going to need to implement fission (to at least some degree)
support in LLDB, then? (to support the case where you haven't linked debug
info with llvm-dsymutil, but you've hit one of these lookup problems where
you need to cross possibly-conflicting modules)
Yes. Specifically, it won’t support type units, and it will look up
types by name rather than by signature. (cf. the second part of
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html
)
How are you going to reference the types in the module's fission CU
without type units/signatures? Are you going to emit type declarations into
the normal CU and rely on the debugger to know that these declarations can
be resolved by looking elsewhere? (just without the benefit of constraining
that search to just looking for a matching TU?)
If you look at the example in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html,
there will be an external type index (using the usual accelerator table
format) that maps an external type’s UID to a pcm. In the pcm there is an
extra accelerator table entry that maps UID to DIE offset.
I mean I guess that's up to you, but seems like a relatively large
workaround compared to supporting type units... (I mean certainly seems
like strictly less work to do the workaround than implementing type units
in LLDB, but a relatively large amount of work to do/throw away eventually
once LLDB supports type units)
It’s not primarily meant to be a workaround so LLDB doesn’t need to
implement type units; the UIDs double as the key (decl context + name) to
import types directly from the AST. The other advantage is that we won’t
have to worry about MD5 hash collisions, but that’s more of a theoretical
advantage.
If there's a concern about collisions, we should fix that regardless
(because we'll have the same problem with normal type units or modularized
type units).
If we've already got ( have to use in the case of DWARF fallback for
modules) to support a hash or other numeric identifier, it might be good to
use that for everything rather than having two mechanisms?
OK, so I think it's probably reasonable for now to just add
DW_TAG_modules to the CU for each referenced module (or does it have to be
each referenced submodule? (can two submodules within a single module be
contradictory/conflicting?)). Since we don't have any good way to reference
the module is a foreign unit while deduplicating that unit... there's not
much point having the imported_module - but if you think it adds anything,
I'm open to ideas.
It could help keeping things simpler.
Emitting it doesn’t add much semantic value because module imports
always occur at the top level, but it will make the transition to the
deduplicated TAG_modules easier — It could be easier to teach consumers
once about imported_module({ref to TAG_module}) rather than having them
also recognize top-level TAG_modules as an intermediate step. It’s also
slightly easier to implement in LLVM because the imported_module allows us
to anchor the TAG_module in the CU, but that’s not a very strong argument.
Agreed on all counts (not a strong argument, but convenient enough,
etc, etc).
I'm still not entirely sure what the right answer is here, though,
which is why I'm hesitant to bake anything in too strongly.
To come back to one of the outstanding questions: Do you need submodule
import information, or just module level (if modules cannot have internal
conflicts and you can't avoid cross-module conflicts just by lack of
visibility (I have no idea if either of those things are true) then you may
just need per-module not per-submodule info)?
At the moment I do not think that it makes sense for two submodules to
conflict, but there is nothing in the clang documentation that explicitly
forbids this. With this in mind, I think it is reasonable to not support
submodules (at least initially) and always emit an import for the parent
module.
Thats what I wanted to write ... but I as I’m browsing through our
documentation,
http://clang.llvm.org/docs/Modules.html#conflict-declarations explicitly
gives an example of two conflicting submodules, so maybe this is not a
reasonable simplification after all. On the other hand, a quick grep over
all system module maps on OS X doesn’t show a single conflict declaration.
I still believe we do not need to support submodules right from the
start, but we should have a story for getting there if we need to.
Given the simple example that demonstrates the possibility, it seems fair
to have a story for what that looks like, yes - even if a first
pass/prototype doesn't support it.
Sure.
Also, does each submodule need different special attributes/flags
Re: [PATCH] Have clang list the imported modules in the debug info
On Tue, May 5, 2015 at 3:01 PM, Adrian Prantl apra...@apple.com wrote:
On May 5, 2015, at 9:59 AM, David Blaikie dblai...@gmail.com wrote:
On Mon, May 4, 2015 at 4:46 PM, Adrian Prantl apra...@apple.com wrote:
On May 4, 2015, at 1:31 PM, David Blaikie dblai...@gmail.com wrote:
...
So you're going to need to implement fission (to at least some
degree) support in LLDB, then? (to support the case where you haven't
linked debug info with llvm-dsymutil, but you've hit one of these lookup
problems where you need to cross possibly-conflicting modules)
Yes. Specifically, it won’t support type units, and it will look
up types by name rather than by signature. (cf. the second part of
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html
)
How are you going to reference the types in the module's fission CU
without type units/signatures? Are you going to emit type declarations into
the normal CU and rely on the debugger to know that these declarations can
be resolved by looking elsewhere? (just without the benefit of constraining
that search to just looking for a matching TU?)
If you look at the example in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150427/128278.html,
there will be an external type index (using the usual accelerator table
format) that maps an external type’s UID to a pcm. In the pcm there is an
extra accelerator table entry that maps UID to DIE offset.
I mean I guess that's up to you, but seems like a relatively large
workaround compared to supporting type units... (I mean certainly seems
like strictly less work to do the workaround than implementing type units
in LLDB, but a relatively large amount of work to do/throw away eventually
once LLDB supports type units)
It’s not primarily meant to be a workaround so LLDB doesn’t need to
implement type units; the UIDs double as the key (decl context + name) to
import types directly from the AST. The other advantage is that we won’t
have to worry about MD5 hash collisions, but that’s more of a theoretical
advantage.
If there's a concern about collisions, we should fix that regardless
(because we'll have the same problem with normal type units or modularized
type units).
My understanding is that split DWARF is disambiguating hash collisions by
adding the full decl context and name to both the definition and the
forward declaration:
No, that's not a requirement. It's just an aspect of our implementation so
we can put entities in the type when needed (such as for putting member
function declarations in there to refererence from out of line member
function definitions)
In the simplest case, you can reference a type unit directly:
DW_TAG_variable
DW_AT_type [DW_FORM_ref_sig8]
Without any DW_TAG_structure_type/namespaces/etc. Once we have Bag O'
DWARF, we'd move to that representation almost entirely. (the signature
we're using for this is the mangled name of the type so it includes the
decl context in the hash anyway)
so if a module defines:
namespace A { struct B { struct C {} } }
we’ll end up with
DW_TAG_variable
DW_AT_name “myC”
DW_AT_type [DW_FORM_ref4] 0x20
DW_TAG_namespace
DW_AT_name “A”
DW_TAG_structure_type
DW_AT_name “B”
0x20:
DW_TAG_structure_type
DW_AT_name “C”
DW_AT_signature 0x1234ABCD
DW_AT_declaration
and in the DWO there will be:
DW_TAG_type_unit 0x1234ABCD
DW_TAG_namespace
DW_AT_name “A”
DW_TAG_structure_type
DW_AT_name “B”
DW_TAG_structure_type
DW_AT_name “C”
...
--
(for completeness, the UID type reference would look like this:
DW_TAG_variable
DW_AT_name “myC”
DW_AT_type [DW_FORM_strp] “_ZTN1AS1BS1C” )
So I think that hash collisions are actually handled for normal fission
and we don’t need to worry about them. The bag o’dwarf will still contain
the full decl context in the DWO, so it will be fine there, too.
If we've already got ( have to use in the case of DWARF fallback for
modules) to support a hash or other numeric identifier, it might be good to
use that for everything rather than having two mechanisms?
Generally, one way to do it is of course better than maintaining two :-)
But using the UIDs in the .o file allows us to elide the the forward
declarations from the .o file
It doesn't, though - because we need the forward declarations to put
members into (such as member function definitions - this'll come up even
for modules quite commonly with any inline member function, for example -
its definition will appear in the .o file and the definition
DW_TAG_subprogram will need to DW_AT_specification pointing to the
declaration of the member function - which is a DW_TAG_subprogram inside
the DW_TAG_class that is a declaration with a signature that refers to the
type unit).
Only once we've got Bag O' DWARF do we remove the need for these
declarations.
Granted we can
Re: r236075 - Add -Wpessimizing-move and -Wredundant-move warnings.
On Sat, May 2, 2015 at 11:47 AM, Nico Weber tha...@chromium.org wrote: On Wed, Apr 29, 2015 at 2:41 AM, Benjamin Kramer benny@gmail.com wrote: On Wed, Apr 29, 2015 at 5:59 AM, Richard Trieu rtr...@google.com wrote: Since this warning did not exist when std::move was first introduced, and many people are not familiar with copy elision rules, there have been a lot of uses of the pessimizing move pattern. In relative numbers, the pessimizing move warning is over 5x more common than either the range loop warning (-Wrange-loop-analysis) or the proposed comma warning (-Wcomma). With such a high occurrence, it seemed better not to have it on by default. And every single occurence is a potential performance issue and easy to fix. While this may be too noisy for default, it's definitely a candidate for -Wall imho. +1. As-is, nobody will find this warning. And in general, the bar for warnings is useful enough to be in -Wall, or it shouldn't be there, right? (Which this warning definitely is.) I think the bar at least used to be useful enough to be on by default or it shouldn't be there (the big exception in any analysis based warning because building the CFG costs some non-trivial % - so we keep /all/ of those off by default). Doug particularly espoused this notion I've mostly been promoting it since then on the assumption that that was still the goal - though I don't agree with it entirely myself. - David ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Have clang list the imported modules in the debug info
On Fri, May 1, 2015 at 8:52 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 5:25 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 5:19 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 4:39 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 10:01 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I
Re: [PATCH] Have clang list the imported modules in the debug info
On Mon, May 4, 2015 at 11:24 AM, Adrian Prantl apra...@apple.com wrote: On May 4, 2015, at 10:53 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 8:52 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 5:25 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 5:19 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 4:39 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 10:01 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp
Re: [PATCH] Have clang list the imported modules in the debug info
On Mon, May 4, 2015 at 12:27 PM, Adrian Prantl apra...@apple.com wrote: On May 4, 2015, at 11:38 AM, David Blaikie dblai...@gmail.com wrote: On Mon, May 4, 2015 at 11:24 AM, Adrian Prantl apra...@apple.com wrote: On May 4, 2015, at 10:53 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 8:52 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 5:25 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 5:19 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 4:39 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 10:01 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module
Re: [PATCH] Have clang list the imported modules in the debug info
On Fri, May 1, 2015 at 5:19 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 4:39 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 10:01 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure
Re: [PATCH] Have clang list the imported modules in the debug info
On Fri, May 1, 2015 at 4:39 PM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 10:01 AM, David Blaikie dblai...@gmail.com wrote: On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. DW_TAG_module DW_AT_name(“Foundation”) DW_AT_LLVM_sysroot(“/“) DW_AT_LLVM_include_dir
Re: [PATCH] Have clang list the imported modules in the debug info
On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. DW_TAG_module DW_AT_name(“Foundation”) DW_AT_LLVM_sysroot(“/“) DW_AT_LLVM_include_dir(“”) DW_AT_LLVM_macros(“-DNDEBUG”) ... ELF (comdat, with imports) -- But now let’s go back to ELF. Since the skeleton with the partial unit is comdat'd, I assume that this breaks the FORM_ref_addr used in the DW_AT_import. We could reuse the module hash as a signature for the module: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c
Re: [PATCH] Have clang list the imported modules in the debug info
On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. DW_TAG_module DW_AT_name(“Foundation”) DW_AT_LLVM_sysroot(“/“) DW_AT_LLVM_include_dir(“”) DW_AT_LLVM_macros(“-DNDEBUG”) ... ELF (comdat, with imports) -- But now let’s go back to ELF. Since the skeleton with the partial unit is comdat'd, I assume that this breaks the FORM_ref_addr used
Re: [PATCH] Have clang list the imported modules in the debug info
On Fri, May 1, 2015 at 9:52 AM, Adrian Prantl apra...@apple.com wrote: On May 1, 2015, at 9:23 AM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 5:21 PM, Adrian Prantl apra...@apple.com wrote: On Apr 30, 2015, at 4:55 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. DW_TAG_module DW_AT_name(“Foundation”) DW_AT_LLVM_sysroot(“/“) DW_AT_LLVM_include_dir(“”) DW_AT_LLVM_macros(“-DNDEBUG”) ... ELF (comdat, with imports) -- But now let’s go back to ELF. Since the skeleton with the partial unit is comdat'd, I assume that this breaks the FORM_ref_addr used
Re: [PATCH] [Profile] Clang support for setting profile output from command line
On Thu, Apr 30, 2015 at 1:08 PM, Justin Bogner m...@justinbogner.com wrote: Teresa Johnson tejohn...@google.com writes: On Thu, Apr 30, 2015 at 11:54 AM, Richard Smith rich...@metafoo.co.uk wrote: LGTM, do you need someone to commit this for you? Thanks and yes, but I am still waiting for the LGTM/commit on the LLVM patch this depends on so it can't be committed just yet. If you want to take a look at that one too the link is http://reviews.llvm.org/D9334. I don't think that patch ever made it to the llvm-commits mailing list. Phabricator issue maybe? Looks like it came through to cfe-commits to me, but perhaps there's some latency, etc. (check spam folder?) Teresa http://reviews.llvm.org/D9407 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Have clang list the imported modules in the debug info
On Thu, Apr 30, 2015 at 4:31 PM, Adrian Prantl apra...@apple.com wrote: On Mar 19, 2015, at 5:37 PM, David Blaikie dblai...@gmail.com wrote: On Thu, Mar 19, 2015 at 5:24 PM, Adrian Prantl apra...@apple.com wrote: On Mar 16, 2015, at 2:55 PM, David Blaikie dblai...@gmail.com wrote: On Mon, Mar 16, 2015 at 2:45 PM, Robinson, Paul paul_robin...@playstation.sony.com wrote: Beyond the above (that using a new tag would mean this would go from 'free' to 'not free' for GDB) having a new top level tag is pretty substantial (we only have two at the moment, and with our talk of modules being a bag of dwarf might go back to having one top level tag? (it's not clear to me from DWARF4 whether DW_TAG_module is currently a top-level tag, I don't think it is?) The .debug_info section contains one or more compilation units, partial units, or in DWARF 5, type units. DW_TAG_module isn't a unit, if you want it to be handled independently then it would need to be wrapped in a DW_TAG_partial_unit. You would probably then use DW_TAG_imported_unit to refer to it, rather than DW_TAG_imported_module. This makes a fair bit of sense - though the terminology's never going to quite line up with modules, I suspect, and this would still require modifying existing consumers (well, GDB) that can handle split-dwarf today, I suspect (not sure how it'd handle partial_unit - maybe that does work? - and still don't know how existing consumers would handle imported_unit either - could be worth some testing, as it sounds sort of right out of several less right options). Thanks for all the input so far! To concretize this end of the discussion up let’s sketch some dwarf of how this could look like in practice. ELF (no imports) On ELF or COFF a foo.c referencing types from the module Foundation looks like this: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) .debug_info.dwo (on ELF: group 0x1234ABCDE, comdat) DW_TAG_partial_unit For now I'd suggest we use compile_unit - that way it'll just work with existing split-dwarf consumers. We can see about standardizing a top-level DW_TAG_module or using DW_TAG_partial_unit here later, perhaps? I'm not sure. DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Side question: Is .debug_info.dwo the right section to put the module skeleton in, or should it be a .debug_info section like normal fission skeletons? Skeletons go in .debug_info, the dwo sections are just for the .dwo file (or the module file, in our new case - the extension isn't actually important). It might be worth you compiling an example or two of split-dwarf to see how this all works hands-on. Mach-O (no comdat, no imports) -- Mach-O doesn’t do comdat, so with -split-dwarf=Disable (not sure if that option is the best discriminator) this could look like: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) Mach-O (no comdat, with imports) -- If we add the module import information to this, we get: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x10) Since we got went down the tangent of explaining split-dwarf many emails ago, I've forgotten ( can't readily find) what we were discussing about what ways the imported_module could work. The simplest representation I can think of would be to have it reference, by signature, the module unit (whatever tag it uses) - DW_FORM_ref_sig8, seems the simplest thing to do. DW_TAG_partial_unit DW_AT_dwo_name(“/tmp/org.llvm.clang/ModuleCache/1234ABCDE/Foundation.pcm”) DW_AT_dwo_id(“0x1234ABCDE”) 0x10: This is inside the partial unit? I figured we'd just put these attributes on the top level (compile_unit, or whatever it might be later) - potentially conditionalized on platform, sure. DW_TAG_module DW_AT_name(“Foundation”) DW_AT_LLVM_sysroot(“/“) DW_AT_LLVM_include_dir(“”) DW_AT_LLVM_macros(“-DNDEBUG”) ... ELF (comdat, with imports) -- But now let’s go back to ELF. Since the skeleton with the partial unit is comdat'd, I assume that this breaks the FORM_ref_addr used in the DW_AT_import. We could reuse the module hash as a signature for the module: .debug_info: DW_TAG_compile_unit DW_AT_name(“foo.c”) DW_TAG_imported_module DW_AT_import(DW_FORM_ref_addr 0x1234ABCDE) Still only really need these imported_modules for lldb, right? I'd consider having them off-by-default for non-darwin, but I'm not strictly wedded to that notion
Re: r236059 - Debug Info: Represent local anonymous unions as anonymous unions
On Wed, Apr 29, 2015 at 8:16 AM, Adrian Prantl apra...@apple.com wrote:
On Apr 28, 2015, at 6:26 PM, David Blaikie dblai...@gmail.com wrote:
On Tue, Apr 28, 2015 at 4:01 PM, Adrian Prantl apra...@apple.com
wrote:
Author: adrian
Date: Tue Apr 28 18:01:24 2015
New Revision: 236059
URL: http://llvm.org/viewvc/llvm-project?rev=236059view=rev
Log:
Debug Info: Represent local anonymous unions as anonymous unions
in the debug info. This patch deletes a hack that emits the members
of local anonymous unions as local variables.
Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits
the 32-bit storage for the local variable c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
Seems we're not so lucky:
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/21650/steps/gdb-75-check/logs/gdb.cp__anon-union.exp
Could you revert I'll look into getting you a reduced test
case/demonstration of the issue? (can you run GDB 7.5? Perhaps a simple
test case would demonstrate the issue if you're lucky, otherwise I can
reduce one from the failing test case)
I reverted the commit in r236110. I probably won’t need a reduction — my
guess from the log is that gdb expects a local variable to be present.
OK
My suggestion is to emit local artificial shadow variables and then weaken
the Verifier to not verify artificial variables. In a next step, we could
use the new debugger tuning target feature to make the artificial local
variables and the weakened verifier a gdb-specific behavior, file a bug
against gdb, and eventually remove it altogether.
Sounds reasonable to me
-- adrian
rdar://problem/20730771
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=236059r1=236058r2=236059view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Apr 28 18:01:24 2015
@@ -2835,31 +2835,6 @@ void CGDebugInfo::EmitDeclare(const VarD
return;
} else if (isaVariableArrayType(VD-getType()))
Expr.push_back(llvm::dwarf::DW_OP_deref);
- } else if (const RecordType *RT =
dyn_castRecordType(VD-getType())) {
-// If VD is an anonymous union then Storage represents value for
-// all union fields.
-const RecordDecl *RD = castRecordDecl(RT-getDecl());
-if (RD-isUnion() RD-isAnonymousStructOrUnion()) {
- for (const auto *Field : RD-fields()) {
-llvm::MDType *FieldTy = getOrCreateType(Field-getType(), Unit);
-StringRef FieldName = Field-getName();
-
-// Ignore unnamed fields. Do not ignore unnamed records.
-if (FieldName.empty() !isaRecordType(Field-getType()))
- continue;
-
-// Use VarDecl's Tag, Scope and Line number.
-auto *D = DBuilder.createLocalVariable(
-Tag, Scope, FieldName, Unit, Line, FieldTy,
-CGM.getLangOpts().Optimize, Flags, ArgNo);
-
-// Insert an llvm.dbg.declare into the current block.
-DBuilder.insertDeclare(Storage, D,
DBuilder.createExpression(Expr),
- llvm::DebugLoc::get(Line, Column, Scope),
- Builder.GetInsertBlock());
- }
- return;
-}
}
// Create the descriptor for the variable.
Modified: cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp?rev=236059r1=236058r2=236059view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp Tue Apr 28
18:01:24 2015
@@ -21,8 +21,26 @@ int test_it() {
return (c == 1);
}
+// This is not necessary (and actually harmful because it breaks IR
assumptions)
+// for local variables.
+void foo() {
+ union {
+int i;
+char c;
+ };
+ i = 8
Re: r236059 - Debug Info: Represent local anonymous unions as anonymous unions
On Wed, Apr 29, 2015 at 10:48 AM, Adrian Prantl apra...@apple.com wrote: On Apr 29, 2015, at 10:04 AM, Eric Christopher echri...@gmail.com wrote: On Wed, Apr 29, 2015 at 9:58 AM Eric Christopher echri...@gmail.com wrote: On Wed, Apr 29, 2015 at 8:20 AM Adrian Prantl apra...@apple.com wrote: On Apr 28, 2015, at 6:26 PM, David Blaikie dblai...@gmail.com wrote: Could you revert I'll look into getting you a reduced test case/demonstration of the issue? (can you run GDB 7.5? Perhaps a simple test case would demonstrate the issue if you're lucky, otherwise I can reduce one from the failing test case) I reverted the commit in r236110. I probably won’t need a reduction — my guess from the log is that gdb expects a local variable to be present. My suggestion is to emit local artificial shadow variables and then weaken the Verifier to not verify artificial variables. In a next step, we could use the new debugger tuning target feature to make the artificial local variables and the weakened verifier a gdb-specific behavior, file a bug against gdb, and eventually remove it altogether. FWIW I don't want to use the tuning parameters to also affect correctness. OK. Dave and I debated this a little in person, here's a proposal: by default it will have the gdb specific behavior, but if you're tuning for lldb (or any other debugger I guess?) it won't be there. Thoughts? I think it’s a fair assumption that many debuggers won’t deal very well with anonymous local variables, from that perspective this is the right decision. (Nitpick: If it is only needed for GDB then it doesn’t seem right to make it the global default, because tuning for gdb will be the default on all non-lldb/sce platforms anyway.) I really want to push towards making the debug info handling stricter, so I’m unhappy about having the frontend willfully emit broken IR at the moment. But, I also haven’t found a way to emit the local shadow variables in a way that makes the verifier happy and isn’t entirely gross in other respects. I’ll keep looking for a better way to emit this without having to relax the verifier. Im curious though - why is this harder to support than, say, ASan's habit of smooshing all the variables into a single alloca? They seem rather similar to me, but I'm probably missing something. - David -- adrian ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r236059 - Debug Info: Represent local anonymous unions as anonymous unions
On Wed, Apr 29, 2015 at 11:35 AM, Adrian Prantl apra...@apple.com wrote: On Apr 29, 2015, at 11:15 AM, David Blaikie dblai...@gmail.com wrote: On Wed, Apr 29, 2015 at 10:48 AM, Adrian Prantl apra...@apple.com wrote: On Apr 29, 2015, at 10:04 AM, Eric Christopher echri...@gmail.com wrote: On Wed, Apr 29, 2015 at 9:58 AM Eric Christopher echri...@gmail.com wrote: On Wed, Apr 29, 2015 at 8:20 AM Adrian Prantl apra...@apple.com wrote: On Apr 28, 2015, at 6:26 PM, David Blaikie dblai...@gmail.com wrote: Could you revert I'll look into getting you a reduced test case/demonstration of the issue? (can you run GDB 7.5? Perhaps a simple test case would demonstrate the issue if you're lucky, otherwise I can reduce one from the failing test case) I reverted the commit in r236110. I probably won’t need a reduction — my guess from the log is that gdb expects a local variable to be present. My suggestion is to emit local artificial shadow variables and then weaken the Verifier to not verify artificial variables. In a next step, we could use the new debugger tuning target feature to make the artificial local variables and the weakened verifier a gdb-specific behavior, file a bug against gdb, and eventually remove it altogether. FWIW I don't want to use the tuning parameters to also affect correctness. OK. Dave and I debated this a little in person, here's a proposal: by default it will have the gdb specific behavior, but if you're tuning for lldb (or any other debugger I guess?) it won't be there. Thoughts? I think it’s a fair assumption that many debuggers won’t deal very well with anonymous local variables, from that perspective this is the right decision. (Nitpick: If it is only needed for GDB then it doesn’t seem right to make it the global default, because tuning for gdb will be the default on all non-lldb/sce platforms anyway.) I really want to push towards making the debug info handling stricter, so I’m unhappy about having the frontend willfully emit broken IR at the moment. But, I also haven’t found a way to emit the local shadow variables in a way that makes the verifier happy and isn’t entirely gross in other respects. I’ll keep looking for a better way to emit this without having to relax the verifier. Im curious though - why is this harder to support than, say, ASan's habit of smooshing all the variables into a single alloca? They seem rather similar to me, but I'm probably missing something. When ASan puts variables int the middle of a large alloca it creates a pointer to the variable’s storage deep inside the alloca. It then emits a dbg.declare describing the pointer (with the correct type) rather than the alloca so it does never emit illegal IR. If this is about the IR type of the pointer passed to the dbg.declare... those are going away (see: the copious changes I've been making to LLVM over the last couple of months). So if the verifier is relying on that... it shouldn't. -- adrian ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r236161 - [opaque pointer type] update for LLVM API change
Author: dblaikie
Date: Wed Apr 29 16:22:47 2015
New Revision: 236161
URL: http://llvm.org/viewvc/llvm-project?rev=236161view=rev
Log:
[opaque pointer type] update for LLVM API change
Modified:
cfe/trunk/lib/CodeGen/CGCXX.cpp
cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
Modified: cfe/trunk/lib/CodeGen/CGCXX.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXX.cpp?rev=236161r1=236160r2=236161view=diff
==
--- cfe/trunk/lib/CodeGen/CGCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCXX.cpp Wed Apr 29 16:22:47 2015
@@ -182,8 +182,8 @@ bool CodeGenModule::TryEmitDefinitionAsA
return true;
// Create the alias with no name.
- auto *Alias = llvm::GlobalAlias::create(AliasType-getElementType(), 0,
- Linkage, , Aliasee, getModule());
+ auto *Alias =
+ llvm::GlobalAlias::create(AliasType, Linkage, , Aliasee, getModule());
// Switch any previous uses to the alias.
if (Entry) {
Modified: cfe/trunk/lib/CodeGen/CGObjCGNU.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCGNU.cpp?rev=236161r1=236160r2=236161view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCGNU.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCGNU.cpp Wed Apr 29 16:22:47 2015
@@ -1060,7 +1060,7 @@ llvm::Value *CGObjCGNU::GetSelector(Code
}
if (!SelValue) {
SelValue = llvm::GlobalAlias::create(
-SelectorTy-getElementType(), 0, llvm::GlobalValue::PrivateLinkage,
+SelectorTy, llvm::GlobalValue::PrivateLinkage,
.objc_selector_ + Sel.getAsString(), TheModule);
Types.push_back(TypedSelector(TypeEncoding, SelValue));
}
@@ -1266,14 +1266,14 @@ CGObjCGNU::GenerateMessageSendSuper(Code
if (IsClassMessage) {
if (!MetaClassPtrAlias) {
MetaClassPtrAlias = llvm::GlobalAlias::create(
-IdTy-getElementType(), 0, llvm::GlobalValue::InternalLinkage,
+IdTy, llvm::GlobalValue::InternalLinkage,
.objc_metaclass_ref + Class-getNameAsString(), TheModule);
}
ReceiverClass = MetaClassPtrAlias;
} else {
if (!ClassPtrAlias) {
ClassPtrAlias = llvm::GlobalAlias::create(
-IdTy-getElementType(), 0, llvm::GlobalValue::InternalLinkage,
+IdTy, llvm::GlobalValue::InternalLinkage,
.objc_class_ref + Class-getNameAsString(), TheModule);
}
ReceiverClass = ClassPtrAlias;
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=236161r1=236160r2=236161view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Apr 29 16:22:47 2015
@@ -2523,7 +2523,7 @@ void CodeGenModule::EmitAliasDefinition(
// Create the new alias itself, but don't set a name yet.
auto *GA = llvm::GlobalAlias::create(
- castllvm::PointerType(Aliasee-getType())-getElementType(), 0,
+ castllvm::PointerType(Aliasee-getType()),
llvm::Function::ExternalLinkage, , Aliasee, getModule());
if (Entry) {
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=236161r1=236160r2=236161view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Wed Apr 29 16:22:47 2015
@@ -3220,8 +3220,8 @@ static void emitConstructorDestructorAli
llvm::PointerType *AliasType = Aliasee-getType();
// Create the alias with no name.
- auto *Alias = llvm::GlobalAlias::create(
- AliasType-getElementType(), 0, Linkage, , Aliasee, CGM.getModule());
+ auto *Alias = llvm::GlobalAlias::create(AliasType, Linkage, , Aliasee,
+ CGM.getModule());
// Switch any previous uses to the alias.
if (Entry) {
Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=236161r1=236160r2=236161view=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Wed Apr 29 16:22:47 2015
@@ -1560,9 +1560,8 @@ llvm::GlobalVariable *MicrosoftCXXABI::g
C-setSelectionKind(llvm::Comdat::Largest);
}
VFTable = llvm::GlobalAlias::create(
-castllvm::SequentialType(VTableGEP-getType())-getElementType(),
-/*AddressSpace=*/0, VFTableLinkage, VFTableName.str(), VTableGEP,
-
Re: [PATCH] Debug Info: Represent local anonymous unions as anonymous unions.
On Tue, Apr 28, 2015 at 3:45 PM, Adrian Prantl apra...@apple.com wrote:
Hi echristo, dblaikie,
Debug Info: Represent local anonymous unions as anonymous unions in the
debug info.
This patch deletes a hack that emits the members of local anonymous unions
as local variables.
Why? Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits the
32-bit storage for the local variable c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
Eric, do you know whether the local variable trick is necessary for GDB
compatibility?
Throwing it at the GDB buildbot's probably the best way to find out. Don't
too much mind committing it first seeing if it fails (unless you guys can
run it these days, in which case a preliminary run would be nice).
GCC produces something vaguely interesting:
0x002d: DW_TAG_subprogram [2] *
...
0x004e: DW_TAG_lexical_block [3] *
...
0x0063: DW_TAG_variable [4]
DW_AT_name [DW_FORM_string] (i)
DW_AT_type [DW_FORM_ref4] (cu + 0x0098 =
{0x0098})
DW_AT_artificial [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x006d: DW_TAG_variable [4]
DW_AT_name [DW_FORM_string] (c)
DW_AT_type [DW_FORM_ref4] (cu + 0x009f =
{0x009f})
DW_AT_artificial [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x0077: DW_TAG_variable [5]
DW_AT_type [DW_FORM_ref4] (cu + 0x0080 =
{0x0080})
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x007f: NULL
0x0080: DW_TAG_union_type [6] *
DW_AT_byte_size [DW_FORM_data1] (0x04)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (2)
0x0084: DW_TAG_member [7]
DW_AT_name [DW_FORM_string] (i)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (3)
DW_AT_type [DW_FORM_ref4] (cu + 0x0098 =
{0x0098})
0x008d: DW_TAG_member [7]
DW_AT_name [DW_FORM_string] (c)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (4)
DW_AT_type [DW_FORM_ref4] (cu + 0x009f =
{0x009f})
0x0096: NULL
0x0097: NULL
REPOSITORY
rL LLVM
http://reviews.llvm.org/D9329
Files:
lib/CodeGen/CGDebugInfo.cpp
test/CodeGenCXX/debug-info-anon-union-vars.cpp
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2835,31 +2835,6 @@
return;
} else if (isaVariableArrayType(VD-getType()))
Expr.push_back(llvm::dwarf::DW_OP_deref);
- } else if (const RecordType *RT = dyn_castRecordType(VD-getType())) {
-// If VD is an anonymous union then Storage represents value for
-// all union fields.
-const RecordDecl *RD = castRecordDecl(RT-getDecl());
-if (RD-isUnion() RD-isAnonymousStructOrUnion()) {
- for (const auto *Field : RD-fields()) {
-llvm::MDType *FieldTy = getOrCreateType(Field-getType(), Unit);
-StringRef FieldName = Field-getName();
-
-// Ignore unnamed fields. Do not ignore unnamed records.
-if (FieldName.empty() !isaRecordType(Field-getType()))
- continue;
-
-// Use VarDecl's Tag, Scope and Line number.
-auto *D = DBuilder.createLocalVariable(
-Tag, Scope, FieldName, Unit, Line, FieldTy,
-CGM.getLangOpts().Optimize, Flags, ArgNo);
-
-// Insert an llvm.dbg.declare into the current block.
-DBuilder.insertDeclare(Storage, D,
DBuilder.createExpression(Expr),
- llvm::DebugLoc::get(Line, Column, Scope),
- Builder.GetInsertBlock());
- }
- return;
-}
}
// Create the descriptor for the variable.
Index:
Re: r236059 - Debug Info: Represent local anonymous unions as anonymous unions
On Tue, Apr 28, 2015 at 4:01 PM, Adrian Prantl apra...@apple.com wrote:
Author: adrian
Date: Tue Apr 28 18:01:24 2015
New Revision: 236059
URL: http://llvm.org/viewvc/llvm-project?rev=236059view=rev
Log:
Debug Info: Represent local anonymous unions as anonymous unions
in the debug info. This patch deletes a hack that emits the members
of local anonymous unions as local variables.
Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits
the 32-bit storage for the local variable c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
Seems we're not so lucky:
http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu-gdb-75/builds/21650/steps/gdb-75-check/logs/gdb.cp__anon-union.exp
Could you revert I'll look into getting you a reduced test
case/demonstration of the issue? (can you run GDB 7.5? Perhaps a simple
test case would demonstrate the issue if you're lucky, otherwise I can
reduce one from the failing test case)
rdar://problem/20730771
Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=236059r1=236058r2=236059view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Apr 28 18:01:24 2015
@@ -2835,31 +2835,6 @@ void CGDebugInfo::EmitDeclare(const VarD
return;
} else if (isaVariableArrayType(VD-getType()))
Expr.push_back(llvm::dwarf::DW_OP_deref);
- } else if (const RecordType *RT = dyn_castRecordType(VD-getType())) {
-// If VD is an anonymous union then Storage represents value for
-// all union fields.
-const RecordDecl *RD = castRecordDecl(RT-getDecl());
-if (RD-isUnion() RD-isAnonymousStructOrUnion()) {
- for (const auto *Field : RD-fields()) {
-llvm::MDType *FieldTy = getOrCreateType(Field-getType(), Unit);
-StringRef FieldName = Field-getName();
-
-// Ignore unnamed fields. Do not ignore unnamed records.
-if (FieldName.empty() !isaRecordType(Field-getType()))
- continue;
-
-// Use VarDecl's Tag, Scope and Line number.
-auto *D = DBuilder.createLocalVariable(
-Tag, Scope, FieldName, Unit, Line, FieldTy,
-CGM.getLangOpts().Optimize, Flags, ArgNo);
-
-// Insert an llvm.dbg.declare into the current block.
-DBuilder.insertDeclare(Storage, D,
DBuilder.createExpression(Expr),
- llvm::DebugLoc::get(Line, Column, Scope),
- Builder.GetInsertBlock());
- }
- return;
-}
}
// Create the descriptor for the variable.
Modified: cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp?rev=236059r1=236058r2=236059view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-anon-union-vars.cpp Tue Apr 28
18:01:24 2015
@@ -21,8 +21,26 @@ int test_it() {
return (c == 1);
}
+// This is not necessary (and actually harmful because it breaks IR
assumptions)
+// for local variables.
+void foo() {
+ union {
+int i;
+char c;
+ };
+ i = 8;
+}
+
// CHECK: [[FILE:.*]] = !MDFile(filename:
{{.*}}debug-info-anon-union-vars.cpp,
// CHECK: !MDGlobalVariable(name: c,{{.*}} file: [[FILE]], line:
6,{{.*}} isLocal: true, isDefinition: true
// CHECK: !MDGlobalVariable(name: d,{{.*}} file: [[FILE]], line:
6,{{.*}} isLocal: true, isDefinition: true
// CHECK: !MDGlobalVariable(name: a,{{.*}} file: [[FILE]], line:
6,{{.*}} isLocal: true, isDefinition: true
// CHECK: !MDGlobalVariable(name: b,{{.*}} file: [[FILE]], line:
6,{{.*}} isLocal: true, isDefinition: true
+// CHECK: !MDLocalVariable(
+// CHECK-NOT: name:
+// CHECK: type: ![[UNION:[0-9]+]]
+// CHECK: ![[UNION]] = !MDCompositeType(tag: DW_TAG_union_type,
+// CHECK-NOT: name:
+// CHECK: elements
+// CHECK: !MDDerivedType(tag: DW_TAG_member, name: i, scope: ![[UNION]],
Re: [PATCH] Debug Info: Represent local anonymous unions as anonymous unions.
On Tue, Apr 28, 2015 at 3:52 PM, Adrian Prantl apra...@apple.com wrote:
On Apr 28, 2015, at 3:50 PM, David Blaikie dblai...@gmail.com wrote:
On Tue, Apr 28, 2015 at 3:45 PM, Adrian Prantl apra...@apple.com wrote:
Hi echristo, dblaikie,
Debug Info: Represent local anonymous unions as anonymous unions in the
debug info.
This patch deletes a hack that emits the members of local anonymous
unions as local variables.
Why? Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits the
32-bit storage for the local variable c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
Eric, do you know whether the local variable trick is necessary for GDB
compatibility?
Throwing it at the GDB buildbot's probably the best way to find out. Don't
too much mind committing it first seeing if it fails (unless you guys can
run it these days, in which case a preliminary run would be nice).
GCC produces something vaguely interesting:
0x002d: DW_TAG_subprogram [2] *
...
0x004e: DW_TAG_lexical_block [3] *
...
0x0063: DW_TAG_variable [4]
DW_AT_name [DW_FORM_string] (i)
DW_AT_type [DW_FORM_ref4] (cu + 0x0098 =
{0x0098})
DW_AT_artificial [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x006d: DW_TAG_variable [4]
DW_AT_name [DW_FORM_string] (c)
DW_AT_type [DW_FORM_ref4] (cu + 0x009f =
{0x009f})
DW_AT_artificial [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x0077: DW_TAG_variable [5]
DW_AT_type [DW_FORM_ref4] (cu + 0x0080 =
{0x0080})
DW_AT_location [DW_FORM_exprloc](0x2 91 60 )
0x007f: NULL
0x0080: DW_TAG_union_type [6] *
DW_AT_byte_size [DW_FORM_data1] (0x04)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (2)
0x0084: DW_TAG_member [7]
DW_AT_name [DW_FORM_string] (i)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (3)
DW_AT_type [DW_FORM_ref4] (cu + 0x0098 =
{0x0098})
0x008d: DW_TAG_member [7]
DW_AT_name [DW_FORM_string] (c)
DW_AT_decl_file [DW_FORM_data1]
(/tmp/dbginfo/union.c)
DW_AT_decl_line [DW_FORM_data1] (4)
DW_AT_type [DW_FORM_ref4] (cu + 0x009f =
{0x009f})
0x0096: NULL
0x0097: NULL
That’s pretty much the output that this patch produces, too (anonymous
local variable + anonymous union). If we can use GCC as a precedent, I’m
happy to commit this and see whether it breaks.
The interesting thing in GCC's output is that it produced 3 variables in
the function - one is the union, the other two are named variables that are
marked artificial. I hope that's not necessary, but don't rightly know.
The code change + test seem good - feel free to commit keep an eye on the
GDB buildbot. If it fails for good reasons it's probably best to revert
I'll try to get you a reduction.
- David
-- adrian
REPOSITORY
rL LLVM
http://reviews.llvm.org/D9329
Files:
lib/CodeGen/CGDebugInfo.cpp
test/CodeGenCXX/debug-info-anon-union-vars.cpp
Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2835,31 +2835,6 @@
return;
} else if (isaVariableArrayType(VD-getType()))
Expr.push_back(llvm::dwarf::DW_OP_deref);
- } else if (const RecordType *RT = dyn_castRecordType(VD-getType()))
{
-// If VD is an anonymous union then Storage represents value for
-// all union fields.
-const RecordDecl *RD = castRecordDecl(RT-getDecl());
-if (RD-isUnion() RD-isAnonymousStructOrUnion()) {
- for (const auto *Field : RD-fields()) {
-llvm::MDType *FieldTy = getOrCreateType(Field-getType(), Unit
Re: r235981 - Silencing a spurious -Wuninitialized warning with this local; NFC.
On Tue, Apr 28, 2015 at 5:36 AM, Aaron Ballman aa...@aaronballman.com wrote: Author: aaronballman Date: Tue Apr 28 07:36:54 2015 New Revision: 235981 URL: http://llvm.org/viewvc/llvm-project?rev=235981view=rev Log: Silencing a spurious -Wuninitialized warning with this local; NFC. Which compiler warned on this? It looks like this initialization is not needed - the switch over ImpCaptureStyle (speaking of which, the declaration of this variable could be moved down to closer to this switch - it isn't used before the switch) seems to initialize the variable on all paths that are reachable. (the usual excessive initialization hampers checkers like msan and doesn't make the code better because the default value is never intended to be used - so the program's already off the rails if it's used) Modified: cfe/trunk/lib/Sema/SemaLambda.cpp Modified: cfe/trunk/lib/Sema/SemaLambda.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=235981r1=235980r2=235981view=diff == --- cfe/trunk/lib/Sema/SemaLambda.cpp (original) +++ cfe/trunk/lib/Sema/SemaLambda.cpp Tue Apr 28 07:36:54 2015 @@ -1482,7 +1482,7 @@ ExprResult Sema::BuildLambdaExpr(SourceL // Collect information from the lambda scope. SmallVectorLambdaCapture, 4 Captures; SmallVectorExpr *, 4 CaptureInits; - LambdaCaptureDefault CaptureDefault; + LambdaCaptureDefault CaptureDefault = LCD_None; SourceLocation CaptureDefaultLoc; CXXRecordDecl *Class; CXXMethodDecl *CallOperator; ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [cuda] Preserve TLS storage class of host variable during device-side compilation.
On Tue, Apr 28, 2015 at 1:31 PM, Artem Belevich t...@google.com wrote:
Added better explanation of the test.
http://reviews.llvm.org/D9327
Files:
lib/Sema/SemaDecl.cpp
test/SemaCUDA/qualifiers.cu
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5769,12 +5769,16 @@
diag::err_thread_non_global)
DeclSpec::getSpecifierName(TSCS);
else if (!Context.getTargetInfo().isTLSSupported()) {
- if (getLangOpts().CUDA)
+ if (getLangOpts().CUDA) {
// Postpone error emission until we've collected attributes
required to
// figure out whether it's a host or device variable and whether
the
// error should be ignored.
EmitTLSUnsupportedError = true;
- else
+// We still need to mark the variable as TLS so it shows up in
AST with
+// proper storage class for other tools to use even if we're not
going
+// to emit any code for it.
+NewVD-setTSCSpec(TSCS);
+ } else
Diag(D.getDeclSpec().getThreadStorageClassSpecLoc(),
diag::err_thread_unsupported);
} else
Index: test/SemaCUDA/qualifiers.cu
===
--- test/SemaCUDA/qualifiers.cu
+++ test/SemaCUDA/qualifiers.cu
@@ -1,21 +1,35 @@
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -verify
%s
// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fsyntax-only -verify
-fcuda-is-device %s
+//
+// We run clang_cc1 with 'not' because source file contains
+// intentional errors. CC1 failure is expected and must be ignored
+// here. We're interested in what ends up in AST and that's what
+// FileCheck verifies.
Why are there errors? (the ast of code that is incorrect isn't really
guaranteed, so this might be an unstable/unreliable test - perhaps we could
split out the error cases from the successful cases ( I'd still like to
consider IRGen testing the successful cases, rather than checking the AST -
the former seems like a better contract for Clang to abide by (the AST is a
bit more of an implementation detail)))
+// RUN: not %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only
-ast-dump %s \
+// RUN: | FileCheck %s --check-prefix=CHECK-ALL
--check-prefix=CHECK-HOST
+// RUN: not %clang_cc1 -triple nvptx-unknown-cuda -fsyntax-only -ast-dump
-fcuda-is-device %s \
+// RUN: | FileCheck %s --check-prefix=CHECK-ALL
--check-prefix=CHECK-DEVICE
#include Inputs/cuda.h
// Host (x86) supports TLS and device-side compilation should ignore
// host variables. No errors in either case.
int __thread host_tls_var;
+// CHECK-ALL: host_tls_var 'int' tls
#if defined(__CUDA_ARCH__)
// NVPTX does not support TLS
__device__ int __thread device_tls_var; // expected-error {{thread-local
storage is not supported for the current target}}
+// CHECK-DEVICE: device_tls_var 'int' tls
__shared__ int __thread shared_tls_var; // expected-error {{thread-local
storage is not supported for the current target}}
+// CHECK-DEVICE: shared_tls_var 'int' tls
#else
// Device-side vars should not produce any errors during host-side
// compilation.
__device__ int __thread device_tls_var;
+// CHECK-HOST: device_tls_var 'int' tls
__shared__ int __thread shared_tls_var;
+// CHECK-HOST: shared_tls_var 'int' tls
#endif
__global__ void g1(int x) {}
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] [cuda] Preserve TLS storage class of host variable during device-side compilation.
On Tue, Apr 28, 2015 at 2:24 PM, Artem Belevich t...@google.com wrote:
On Tue, Apr 28, 2015 at 1:47 PM, David Blaikie dblai...@gmail.com wrote:
--- test/SemaCUDA/qualifiers.cu
+++ test/SemaCUDA/qualifiers.cu
@@ -1,21 +1,35 @@
// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only
-verify %s
// RUN: %clang_cc1 -triple nvptx-unknown-cuda -fsyntax-only -verify
-fcuda-is-device %s
+//
+// We run clang_cc1 with 'not' because source file contains
+// intentional errors. CC1 failure is expected and must be ignored
+// here. We're interested in what ends up in AST and that's what
+// FileCheck verifies.
Why are there errors? (the ast of code that is incorrect isn't really
guaranteed, so this might be an unstable/unreliable test - perhaps we could
split out the error cases from the successful cases ( I'd still like to
consider IRGen testing the successful cases, rather than checking the AST -
the former seems like a better contract for Clang to abide by (the AST is a
bit more of an implementation detail)))
The source code is syntactically valid. TLS is not supported by NVPTX and
that's what produces the errors.
IRGen is not going to work here, because host variables will not generate
any code during device-side compilation.
I guess I could extract a subset of this test that does not produce any
errors but which would still allow me to check correctness of AST in a
subset of practically useful cases. It does not help with potential
instability of AST, though.
So what's the observable behavior of this change? we've lost information
which is useful during source analysis. - useful for what? Diagnostic
messages? Then could we -verify check one of those diagnostics?
--Artem
+// RUN: not %clang_cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only
-ast-dump %s \
+// RUN: | FileCheck %s --check-prefix=CHECK-ALL
--check-prefix=CHECK-HOST
+// RUN: not %clang_cc1 -triple nvptx-unknown-cuda -fsyntax-only
-ast-dump -fcuda-is-device %s \
+// RUN: | FileCheck %s --check-prefix=CHECK-ALL
--check-prefix=CHECK-DEVICE
#include Inputs/cuda.h
// Host (x86) supports TLS and device-side compilation should ignore
// host variables. No errors in either case.
int __thread host_tls_var;
+// CHECK-ALL: host_tls_var 'int' tls
#if defined(__CUDA_ARCH__)
// NVPTX does not support TLS
__device__ int __thread device_tls_var; // expected-error
{{thread-local storage is not supported for the current target}}
+// CHECK-DEVICE: device_tls_var 'int' tls
__shared__ int __thread shared_tls_var; // expected-error
{{thread-local storage is not supported for the current target}}
+// CHECK-DEVICE: shared_tls_var 'int' tls
#else
// Device-side vars should not produce any errors during host-side
// compilation.
__device__ int __thread device_tls_var;
+// CHECK-HOST: device_tls_var 'int' tls
__shared__ int __thread shared_tls_var;
+// CHECK-HOST: shared_tls_var 'int' tls
#endif
__global__ void g1(int x) {}
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
--Artem Belevich
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r235981 - Silencing a spurious -Wuninitialized warning with this local; NFC.
On Tue, Apr 28, 2015 at 10:11 AM, Aaron Ballman aa...@aaronballman.com wrote: On Tue, Apr 28, 2015 at 12:22 PM, David Blaikie dblai...@gmail.com wrote: On Tue, Apr 28, 2015 at 5:36 AM, Aaron Ballman aa...@aaronballman.com wrote: Author: aaronballman Date: Tue Apr 28 07:36:54 2015 New Revision: 235981 URL: http://llvm.org/viewvc/llvm-project?rev=235981view=rev Log: Silencing a spurious -Wuninitialized warning with this local; NFC. Which compiler warned on this? I believe it's gcc, but I do not have the version information handy. It's the bot responsible for building our attribute documentation, which I keep warning-free. (Tanya would probably be able to get that information for us if it was important.) Can sometimes make a reasonable guess based on the diagnostic style/text - though GCC 5-ish has started doing the quoted samples like Clang (though it doesn't highlight ranges, so that's still a distinguishing feature even in non-colored output) It looks like this initialization is not needed - the switch over ImpCaptureStyle (speaking of which, the declaration of this variable could be moved down to closer to this switch - it isn't used before the switch) seems to initialize the variable on all paths that are reachable. Correct, that's why I called it a spurious warning. ;-) Ah, sorry, missed that. (the usual excessive initialization hampers checkers like msan and doesn't make the code better because the default value is never intended to be used - so the program's already off the rails if it's used) Also agreed. If you have a better idea of how to silence the warning so that build remains warning-free, I would welcome suggestions. Disable bad warnings - we've certainly disabled a few of GCC's for just this reason before, I'm surprised this variation on the theme has survived this long, honestly (I guess -Wmaybe-uninitialized was the biggest culprit). If we really want to avoid that, you could pull out the switch into a helper function that you call to retrieve the desired value. The llvm_unreachable will stop GCC from warning about -Wreturn-type and the variable initialized with the result of the call will be always initialized. ( then different sanitizers would catch the sort of bugs that would lead to the unreachable or otherwise exiting the function without a return value) - also makes the code easier to read/reason about, since you don't have to scan the switch to check that the variable's initialized. - David ~Aaron Modified: cfe/trunk/lib/Sema/SemaLambda.cpp Modified: cfe/trunk/lib/Sema/SemaLambda.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=235981r1=235980r2=235981view=diff == --- cfe/trunk/lib/Sema/SemaLambda.cpp (original) +++ cfe/trunk/lib/Sema/SemaLambda.cpp Tue Apr 28 07:36:54 2015 @@ -1482,7 +1482,7 @@ ExprResult Sema::BuildLambdaExpr(SourceL // Collect information from the lambda scope. SmallVectorLambdaCapture, 4 Captures; SmallVectorExpr *, 4 CaptureInits; - LambdaCaptureDefault CaptureDefault; + LambdaCaptureDefault CaptureDefault = LCD_None; SourceLocation CaptureDefaultLoc; CXXRecordDecl *Class; CXXMethodDecl *CallOperator; ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r235981 - Silencing a spurious -Wuninitialized warning with this local; NFC.
On Tue, Apr 28, 2015 at 10:38 AM, Aaron Ballman aa...@aaronballman.com wrote: On Tue, Apr 28, 2015 at 1:23 PM, David Blaikie dblai...@gmail.com wrote: On Tue, Apr 28, 2015 at 10:11 AM, Aaron Ballman aa...@aaronballman.com wrote: On Tue, Apr 28, 2015 at 12:22 PM, David Blaikie dblai...@gmail.com wrote: On Tue, Apr 28, 2015 at 5:36 AM, Aaron Ballman aa...@aaronballman.com wrote: Author: aaronballman Date: Tue Apr 28 07:36:54 2015 New Revision: 235981 URL: http://llvm.org/viewvc/llvm-project?rev=235981view=rev Log: Silencing a spurious -Wuninitialized warning with this local; NFC. Which compiler warned on this? I believe it's gcc, but I do not have the version information handy. It's the bot responsible for building our attribute documentation, which I keep warning-free. (Tanya would probably be able to get that information for us if it was important.) Can sometimes make a reasonable guess based on the diagnostic style/text - though GCC 5-ish has started doing the quoted samples like Clang (though it doesn't highlight ranges, so that's still a distinguishing feature even in non-colored output) Yeah, that's why I was guessing GCC. Doesn't look like Clang output to me. It looks like this initialization is not needed - the switch over ImpCaptureStyle (speaking of which, the declaration of this variable could be moved down to closer to this switch - it isn't used before the switch) seems to initialize the variable on all paths that are reachable. Correct, that's why I called it a spurious warning. ;-) Ah, sorry, missed that. (the usual excessive initialization hampers checkers like msan and doesn't make the code better because the default value is never intended to be used - so the program's already off the rails if it's used) Also agreed. If you have a better idea of how to silence the warning so that build remains warning-free, I would welcome suggestions. Disable bad warnings - we've certainly disabled a few of GCC's for just this reason before, I'm surprised this variation on the theme has survived this long, honestly (I guess -Wmaybe-uninitialized was the biggest culprit). I don't think this warning is a reasonable candidate to disable based on how infrequently we run into FPs with it. My tolerance is fairly low because it seems it doesn't buy us much, so even a small false positive count seems enough to disable it when we'll catch the good cases with clang anyway. ( it means I don't have to worry about missing a code review motivated by the warning) If we really want to avoid that, you could pull out the switch into a helper function that you call to retrieve the desired value. The llvm_unreachable will stop GCC from warning about -Wreturn-type and the variable initialized with the result of the call will be always initialized. ( then different sanitizers would catch the sort of bugs that would lead to the unreachable or otherwise exiting the function without a return value) - also makes the code easier to read/reason about, since you don't have to scan the switch to check that the variable's initialized. This seems reasonable. I've implemented it in r236002. Thank you for the suggestion! cool cool :) - David ~Aaron - David ~Aaron Modified: cfe/trunk/lib/Sema/SemaLambda.cpp Modified: cfe/trunk/lib/Sema/SemaLambda.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLambda.cpp?rev=235981r1=235980r2=235981view=diff == --- cfe/trunk/lib/Sema/SemaLambda.cpp (original) +++ cfe/trunk/lib/Sema/SemaLambda.cpp Tue Apr 28 07:36:54 2015 @@ -1482,7 +1482,7 @@ ExprResult Sema::BuildLambdaExpr(SourceL // Collect information from the lambda scope. SmallVectorLambdaCapture, 4 Captures; SmallVectorExpr *, 4 CaptureInits; - LambdaCaptureDefault CaptureDefault; + LambdaCaptureDefault CaptureDefault = LCD_None; SourceLocation CaptureDefaultLoc; CXXRecordDecl *Class; CXXMethodDecl *CallOperator; ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
r235756 - [opaque pointer type] Update test cases now that the type for an invoke is just a function type, not a pointer-to-function type
Author: dblaikie
Date: Fri Apr 24 14:33:25 2015
New Revision: 235756
URL: http://llvm.org/viewvc/llvm-project?rev=235756view=rev
Log:
[opaque pointer type] Update test cases now that the type for an invoke is just
a function type, not a pointer-to-function type
Modified:
cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m
Modified: cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m?rev=235756r1=235755r2=235756view=diff
==
--- cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m (original)
+++ cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m Fri Apr 24 14:33:25 2015
@@ -34,7 +34,7 @@ void test1(id x) {
void NSLog(id, ...);
// CHECK-LABEL: define void @test2(
-// CHECK: invoke void (i8*, ...)* @NSLog(i8* bitcast
(%struct.NSConstantString* @_unnamed_cfstring_ to i8*), i32* %{{.*}})
+// CHECK: invoke void (i8*, ...) @NSLog(i8* bitcast (%struct.NSConstantString*
@_unnamed_cfstring_ to i8*), i32* %{{.*}})
// CHECK: to label %{{.*}} unwind label %{{.*}},
!clang.arc.no_objc_arc_exceptions !
// NO-METADATA-LABEL: define void @test2(
// NO-METADATA-NOT: !clang.arc.no_objc_arc_exceptions
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Diagnose variadic main
LGTM On Thu, Apr 23, 2015 at 8:31 AM, Aaron Ballman aa...@aaronballman.com wrote: Ping On Thu, Apr 9, 2015 at 2:55 PM, Aaron Ballman aa...@aaronballman.com wrote: This patch diagnoses a variadic main declaration as being an extension. While it could conceivably be an error instead of a warning, I figured that this is a conforming extension and has less chance of breaking existing code (though I'm not strongly tied to one diagnostic over the other). It addresses PR17905. ~Aaron ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: [PATCH] Enable format specifier checking for fields
LGTM On Thu, Apr 23, 2015 at 8:32 AM, Aaron Ballman aa...@aaronballman.com wrote: Ping On Thu, Apr 9, 2015 at 11:46 AM, Aaron Ballman aa...@aaronballman.com wrote: This patch extends the format specifier checking code to include field function pointers in addition to variable function pointers. It addresses PR21082. ~Aaron ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r235166 - Move fixit for const init from note to diag, weaken to warning in MS mode.
On Fri, Apr 17, 2015 at 1:32 AM, Nico Weber nicolaswe...@gmx.de wrote:
Author: nico
Date: Fri Apr 17 03:32:38 2015
New Revision: 235166
URL: http://llvm.org/viewvc/llvm-project?rev=235166view=rev
Log:
Move fixit for const init from note to diag, weaken to warning in MS mode.
There's a general rule that we don't put fixits on warnings because in
-fix-it mode we need to recover exactly as if the fixit were applied
( since it's only a warning we can't change the recovery path to do
something different based on the fact that the warning occurred). I'm
not sure if there are exceptions to this rule.
- David
r235046 turned extern __declspec(selectany) int a; from a declaration into
a definition to fix PR23242 (required for compatibility with mc.exe output).
However, this broke parsing Windows headers: A d3d11 headers contain
something
like
struct SomeStruct {};
extern const __declspec(selectany) SomeStruct some_struct;
This is now a definition, and const objects either need an explicit default
ctor or an initializer so this errors out with
d3d11.h(1065,48) :
error: default initialization of an object of const type
'const CD3D11_DEFAULT' without a user-provided default constructor
(cl.exe just doesn't implement this rule, independent of selectany.)
To work around this, weaken this error into a warning for selectany decls
in microsoft mode, and recover with zero-initialization.
Doing this is a bit hairy since it adds a fixit on an error emitted
by InitializationSequence – this means it needs to build a correct AST, which
in turn means InitializationSequence::Failed() cannot return true when this
fixit is applied. As a workaround, the patch adds a fixit member to
InitializationSequence, and InitializationSequence::Perform() prints the
diagnostic if the fixit member is set right after its call to Diagnose.
That function is usually called when InitializationSequences are used –
InitListChecker::PerformEmptyInit() doesn't call it, but the InitListChecker
case never performs default-initialization, so this is technically OK.
This is the alternative, original fix for PR20208 that got reviewed in the
thread [patch] Improve diagnostic on default-initializing const variables
(PR20208). This change basically reverts r213725, adds the original fix for
PR20208, and makes the error a warning in Microsoft mode.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Initialization.h
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p9.cpp
cfe/trunk/test/CXX/dcl.decl/dcl.fct.def/dcl.fct.def.default/p2.cpp
cfe/trunk/test/CXX/dcl.decl/dcl.init/p6.cpp
cfe/trunk/test/CXX/drs/dr0xx.cpp
cfe/trunk/test/CXX/drs/dr4xx.cpp
cfe/trunk/test/FixIt/fixit.cpp
cfe/trunk/test/SemaCXX/attr-selectany.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
cfe/trunk/test/SemaCXX/constexpr-value-init.cpp
cfe/trunk/test/SemaCXX/cxx0x-cursory-default-delete.cpp
cfe/trunk/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=235166r1=235165r2=235166view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Apr 17 03:32:38
2015
@@ -5470,8 +5470,11 @@ def err_address_space_qualified_delete :
def err_default_init_const : Error
default initialization of an object of const type %0
%select{| without a user-provided default constructor}1;
-def note_add_initializer : Note
- add an explicit initializer to initialize %0;
+def ext_default_init_const : ExtWarn
+ default initialization of an object of const type %0
+ %select{| without a user-provided default constructor}1
+ is a Microsoft extension,
+ InGroupMicrosoft;
def err_delete_operand : Errorcannot delete expression of type %0;
def ext_delete_void_ptr_operand : ExtWarn
cannot delete expression with pointer-to-'void' type %0,
Modified: cfe/trunk/include/clang/Sema/Initialization.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Initialization.h?rev=235166r1=235165r2=235166view=diff
==
--- cfe/trunk/include/clang/Sema/Initialization.h (original)
+++ cfe/trunk/include/clang/Sema/Initialization.h Fri Apr 17 03:32:38 2015
@@ -844,6 +844,21 @@ private:
/// \brief The incomplete type that caused a failure.
QualType FailedIncompleteType;
+
+ /// \brief The fixit that needs to be applied to make this initialization
+ /// succeed.
+ std::string ZeroInitializationFixit;
+ SourceLocation ZeroInitializationFixitLoc;
+
+public:
+ ///
r235147 - [opaque pointer types] Explicit non-pointer type for call expressions
Author: dblaikie
Date: Thu Apr 16 18:25:00 2015
New Revision: 235147
URL: http://llvm.org/viewvc/llvm-project?rev=235147view=rev
Log:
[opaque pointer types] Explicit non-pointer type for call expressions
(migration for recent LLVM change to textual IR for calls)
Modified:
cfe/trunk/test/CodeGen/2007-02-25-C-DotDotDot.c
cfe/trunk/test/CodeGen/2008-07-29-override-alias-decl.c
cfe/trunk/test/CodeGen/arm-abi-vector.c
cfe/trunk/test/CodeGen/arm-homogenous.c
cfe/trunk/test/CodeGen/arm64-abi-vector.c
cfe/trunk/test/CodeGen/arm64-arguments.c
cfe/trunk/test/CodeGen/blocks-seq.c
cfe/trunk/test/CodeGen/builtin-expect.c
cfe/trunk/test/CodeGen/call.c
cfe/trunk/test/CodeGen/catch-undef-behavior.c
cfe/trunk/test/CodeGen/mrtd.c
cfe/trunk/test/CodeGen/ms-setjmp.c
cfe/trunk/test/CodeGen/pr5406.c
cfe/trunk/test/CodeGen/variadic-null-win64.c
cfe/trunk/test/CodeGen/x86_32-arguments-darwin.c
cfe/trunk/test/CodeGen/x86_32-arguments-linux.c
cfe/trunk/test/CodeGen/x86_64-arguments.c
cfe/trunk/test/CodeGenCXX/conditional-gnu-ext.cpp
cfe/trunk/test/CodeGenCXX/convert-to-fptr.cpp
cfe/trunk/test/CodeGenCXX/dllexport.cpp
cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp
cfe/trunk/test/CodeGenCXX/member-functions.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-methods.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-structors.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-virtual-member-pointers.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-vmemptr-conflicts.cpp
cfe/trunk/test/CodeGenCXX/switch-case-folding-2.cpp
cfe/trunk/test/CodeGenCXX/unknown-anytype.cpp
cfe/trunk/test/CodeGenCXX/vararg-non-pod-ms-compat.cpp
cfe/trunk/test/CodeGenCXX/varargs.cpp
cfe/trunk/test/CodeGenObjC/arc-blocks.m
cfe/trunk/test/CodeGenObjC/arc-literals.m
cfe/trunk/test/CodeGenObjC/arc-ternary-op.m
cfe/trunk/test/CodeGenObjC/arc.m
cfe/trunk/test/CodeGenObjC/blocks.m
cfe/trunk/test/CodeGenObjC/objfw.m
cfe/trunk/test/CodeGenObjC/property.m
cfe/trunk/test/CodeGenObjC/stret_lookup.m
cfe/trunk/test/CodeGenObjC/tentative-cfconstantstring.m
cfe/trunk/test/CodeGenObjC/variadic-sends.m
cfe/trunk/test/CodeGenObjCXX/arc.mm
cfe/trunk/test/CodeGenObjCXX/lambda-expressions.mm
cfe/trunk/test/OpenMP/for_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/for_lastprivate_codegen.cpp
cfe/trunk/test/OpenMP/parallel_codegen.cpp
cfe/trunk/test/OpenMP/parallel_copyin_codegen.cpp
cfe/trunk/test/OpenMP/parallel_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/parallel_if_codegen.cpp
cfe/trunk/test/OpenMP/parallel_num_threads_codegen.cpp
cfe/trunk/test/OpenMP/parallel_private_codegen.cpp
cfe/trunk/test/OpenMP/parallel_reduction_codegen.cpp
cfe/trunk/test/OpenMP/parallel_sections_codegen.cpp
Modified: cfe/trunk/test/CodeGen/2007-02-25-C-DotDotDot.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2007-02-25-C-DotDotDot.c?rev=235147r1=235146r2=235147view=diff
==
--- cfe/trunk/test/CodeGen/2007-02-25-C-DotDotDot.c (original)
+++ cfe/trunk/test/CodeGen/2007-02-25-C-DotDotDot.c Thu Apr 16 18:25:00 2015
@@ -3,7 +3,7 @@
// Make sure the call to foo is compiled as:
// call float @foo()
// not
-// call float (...)* bitcast (float ()* @foo to float (...)*)( )
+// call float (...) bitcast (float ()* @foo to float (...)*)( )
static float foo() { return 0.0; }
// CHECK: call float @foo
Modified: cfe/trunk/test/CodeGen/2008-07-29-override-alias-decl.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2008-07-29-override-alias-decl.c?rev=235147r1=235146r2=235147view=diff
==
--- cfe/trunk/test/CodeGen/2008-07-29-override-alias-decl.c (original)
+++ cfe/trunk/test/CodeGen/2008-07-29-override-alias-decl.c Thu Apr 16 18:25:00
2015
@@ -14,6 +14,6 @@ int h() {
return f();
}
-// CHECK: [[call:%.*]] = call i32 (...)* @f()
+// CHECK: [[call:%.*]] = call i32 (...) @f()
// CHECK: ret i32 [[call]]
Modified: cfe/trunk/test/CodeGen/arm-abi-vector.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-abi-vector.c?rev=235147r1=235146r2=235147view=diff
==
--- cfe/trunk/test/CodeGen/arm-abi-vector.c (original)
+++ cfe/trunk/test/CodeGen/arm-abi-vector.c Thu Apr 16 18:25:00 2015
@@ -37,9 +37,9 @@ double varargs_vec_2i(int fixed, ...) {
double test_2i(__int2 *in) {
// CHECK: test_2i
-// CHECK: call arm_aapcscc double (i32, ...)* @varargs_vec_2i(i32 3, 2 x i32
{{%.*}})
+// CHECK: call arm_aapcscc double (i32, ...) @varargs_vec_2i(i32 3, 2 x i32
{{%.*}})
// APCS-GNU: test_2i
-// APCS-GNU: call double (i32,
r235150 - Improve const-ness
Author: dblaikie
Date: Thu Apr 16 19:19:34 2015
New Revision: 235150
URL: http://llvm.org/viewvc/llvm-project?rev=235150view=rev
Log:
Improve const-ness
This allows callers to pass a char ** (such as the one coming from the
standard decreed main declaration - even though everyone usually puts
const on that themselves).
Modified:
cfe/trunk/include/clang/Tooling/CompilationDatabase.h
cfe/trunk/lib/Tooling/CompilationDatabase.cpp
Modified: cfe/trunk/include/clang/Tooling/CompilationDatabase.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/CompilationDatabase.h?rev=235150r1=235149r2=235150view=diff
==
--- cfe/trunk/include/clang/Tooling/CompilationDatabase.h (original)
+++ cfe/trunk/include/clang/Tooling/CompilationDatabase.h Thu Apr 16 19:19:34
2015
@@ -178,7 +178,7 @@ public:
/// \param Argv Points to the command line arguments.
/// \param Directory The base directory used in the FixedCompilationDatabase.
static FixedCompilationDatabase *loadFromCommandLine(int Argc,
- const char **Argv,
+ const char *const *Argv,
Twine Directory = .);
/// \brief Constructs a compilation data base from a specified directory
Modified: cfe/trunk/lib/Tooling/CompilationDatabase.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/CompilationDatabase.cpp?rev=235150r1=235149r2=235150view=diff
==
--- cfe/trunk/lib/Tooling/CompilationDatabase.cpp (original)
+++ cfe/trunk/lib/Tooling/CompilationDatabase.cpp Thu Apr 16 19:19:34 2015
@@ -283,11 +283,9 @@ static bool stripPositionalArgs(std::vec
return true;
}
-FixedCompilationDatabase *
-FixedCompilationDatabase::loadFromCommandLine(int Argc,
- const char **Argv,
- Twine Directory) {
- const char **DoubleDash = std::find(Argv, Argv + Argc, StringRef(--));
+FixedCompilationDatabase *FixedCompilationDatabase::loadFromCommandLine(
+int Argc, const char *const *Argv, Twine Directory) {
+ const char *const *DoubleDash = std::find(Argv, Argv + Argc,
StringRef(--));
if (DoubleDash == Argv + Argc)
return nullptr;
std::vectorconst char * CommandLine(DoubleDash + 1, Argv + Argc);
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Re: r234964 - Change range-based for-loops to be -Wrange-loop-analysis clean.
On Tue, Apr 14, 2015 at 6:21 PM, Richard Trieu rtr...@google.com wrote:
Author: rtrieu
Date: Tue Apr 14 20:21:42 2015
New Revision: 234964
URL: http://llvm.org/viewvc/llvm-project?rev=234964view=rev
Log:
Change range-based for-loops to be -Wrange-loop-analysis clean.
No functionality change.
Modified:
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
Modified: cfe/trunk/lib/AST/MicrosoftMangle.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/MicrosoftMangle.cpp?rev=234964r1=234963r2=234964view=diff
==
--- cfe/trunk/lib/AST/MicrosoftMangle.cpp (original)
+++ cfe/trunk/lib/AST/MicrosoftMangle.cpp Tue Apr 14 20:21:42 2015
@@ -1680,7 +1680,7 @@ void MicrosoftCXXNameMangler::mangleFunc
Out 'X';
} else {
// Happens for function pointer type arguments for example.
-for (const QualType Arg : Proto-param_types())
+for (const QualType Arg : Proto-param_types())
mangleArgumentType(Arg, Range);
// builtin-type ::= Z # ellipsis
if (Proto-isVariadic())
Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=234964r1=234963r2=234964view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Apr 14 20:21:42 2015
@@ -3431,7 +3431,7 @@ void CodeGenModule::ClearUnusedCoverageM
void CodeGenModule::EmitDeferredUnusedCoverageMappings() {
std::vectorconst Decl * DeferredDecls;
- for (const auto I : DeferredEmptyCoverageMappingDecls) {
+ for (const auto I : DeferredEmptyCoverageMappingDecls) {
if (!I.second)
continue;
DeferredDecls.push_back(I.first);
Modified: cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp?rev=234964r1=234963r2=234964view=diff
==
--- cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp (original)
+++ cfe/trunk/lib/CodeGen/CoverageMappingGen.cpp Tue Apr 14 20:21:42 2015
@@ -748,7 +748,7 @@ struct CounterCoverageMappingBuilder
size_t Index =
pushRegion(Counter::getZero(), getStart(CS-body_front()),
getEnd(CS-body_back()));
-for (const auto Child : CS-children())
+for (const auto *Child : CS-children())
Visit(Child);
popRegions(Index);
}
Modified: cfe/trunk/lib/Sema/SemaLookup.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaLookup.cpp?rev=234964r1=234963r2=234964view=diff
==
--- cfe/trunk/lib/Sema/SemaLookup.cpp (original)
+++ cfe/trunk/lib/Sema/SemaLookup.cpp Tue Apr 14 20:21:42 2015
@@ -3070,7 +3070,7 @@ static void LookupVisibleDecls(DeclConte
Result.getSema().ForceDeclarationOfImplicitMembers(Class);
// Enumerate all of the results in this context.
- for (const auto R : Ctx-lookups()) {
+ for (const auto R : Ctx-lookups()) {
Could we put the concrete type in here when we're not using reference,
just to make it clear that that's the right choice? (I realize the
warning will help us not make the accidentally used auto by value
instead of by reference mistake, but it's helpful to justify it in
the source for readers)
for (auto *D : R) {
if (auto *ND = Result.getAcceptableDecl(D)) {
Consumer.FoundDecl(ND, Visited.checkHidden(ND), Ctx, InBaseClass);
Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp?rev=234964r1=234963r2=234964view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp Tue Apr 14 20:21:42 2015
@@ -1747,7 +1747,7 @@ Sema::SubstBaseSpecifiers(CXXRecordDecl
const MultiLevelTemplateArgumentList
TemplateArgs) {
bool Invalid = false;
SmallVectorCXXBaseSpecifier*, 4 InstantiatedBases;
- for (const auto Base : Pattern-bases()) {
+ for (const auto Base : Pattern-bases()) {
if (!Base.getType()-isDependentType()) {
if (const CXXRecordDecl *RD = Base.getType()-getAsCXXRecordDecl()) {
if (RD-isInvalidDecl())
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing
