Displaying 6 results from an estimated 6 matches for "isforwarddecl".
2012 Aug 09
3
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
...n:
CGDebugInfo.h:
std::vector<std::pair<void *, llvm::WeakVH> >ReplaceMap;
but then in
CGDebugInfo.cpp:
llvm::DIType TC = getTypeOrNull(Ty);
void * v = Ty.getAsOpaquePtr();
std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC);
if (TC.Verify() && TC.isForwardDecl())
ReplaceMap.push_back(Ty.getTypeOrNull(), TC);
Note that TC is of type llvm:DIType and not WeakVH.
What am I missing, as this does not compile under Visual Studio 2012 RC?
Regards,
Ben
- Benedict R. Gaster
Enjoy Berlin and submit a paper to Multiprog 2013: http://multiprog.ac.upc.edu/
-...
2012 Aug 09
1
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
..._Ty3=void *,
_Ty4=llvm::WeakVH
]
The reason it gives is std::pair<_Ty1,_Ty2>' to 'std::pair<_Ty3,_Ty4>, but as you point out there is indeed a conversion operator for DITYPE to WeakVH. Putting the explicit cast to give:
if (T.Verify() && T.isForwardDecl())
ReplaceMap.push_back(std::make_pair(Ty.getAsOpaquePtr(), (llvm::MDNode *)T));
and all it well again. This does indeed seem to be a bug in VS, unless there is some C++11 changes that stops implicit conversion under std::pair.
Regards,
Ben
- Benedict R. Gaster
Enjoy Berlin and submit a pap...
2012 Aug 09
0
[LLVMdev] Type inconsistency in LLVM 3.1: CGDebugInfo.cpp
...lvm::WeakVH> >ReplaceMap;
>
> but then in
>
> CGDebugInfo.cpp:
>
> llvm::DIType TC = getTypeOrNull(Ty);
>
> void * v = Ty.getAsOpaquePtr();
> std::pair<void *, llvm::WeakVH> tmp = std::make_pair(v, TC);
>
> if (TC.Verify() && TC.isForwardDecl())
> ReplaceMap.push_back(Ty.getTypeOrNull(), TC);
>
> Note that TC is of type llvm:DIType and not WeakVH.
>
> What am I missing, as this does not compile under Visual Studio 2012 RC?
Tricky code, DIType (or rather its superclass DIDescriptor) implicitly converts to MDNode*...
2013 Sep 30
1
[LLVMdev] [patch] Prototype/proof-of-concept for DWARF type units
This isn't a realistic/viable implementation, just a hacked up "can I make
it produce the right output" kind of thing, but while I hammer out a few
more details (like fixing MC to allow multiple sections with the same name
but different comdat groups) I figured I'd throw it out there to have a bit
of a chat about it.
I've tested simple cases of a single type and they seem to
2016 Apr 01
0
[cfe-dev] RFC: Up front type information generation in clang and llvm
...RecordDecl *RD) {
- if (DebugKind <= codegenoptions::DebugLineTablesOnly)
- return;
- QualType Ty = CGM.getContext().getRecordType(RD);
- void *TyPtr = Ty.getAsOpaquePtr();
- auto I = TypeCache.find(TyPtr);
- if (I != TypeCache.end() && !cast<llvm::DIType>(I->second)->isForwardDecl())
- return;
- llvm::DIType *Res = CreateTypeDefinition(Ty->castAs<RecordType>());
- assert(!Res->isForwardDecl());
- TypeCache[TyPtr].reset(Res);
}
static bool hasExplicitMemberDefinition(CXXRecordDecl::method_iterator I,
@@ -2169,6 +2159,9 @@ llvm::DIType *CGDebugInfo::getTy...
2016 Mar 30
5
[cfe-dev] RFC: Up front type information generation in clang and llvm
On Tue, Mar 29, 2016 at 11:20 PM Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:
> Skipping a serialization and doing something clever about LTO uniquing
> sounds awesome. I'm guessing you achieve this by extracting types out of
> DI metadata and packaging them as lumps-o-DWARF that the back-end can then
> paste together? Reading between the lines a bit