search for: typeprint

On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > Does this patch fix any failures for you? It doesn't fix that test case, unfortunately. -------------- next part -----------...

...c\llvm\tools\clang\test\CXX\class.access\p6.cpp Line 180: 'operator void *(class test8::A::*)(void) __attribute__((thiscall)) const' is a private member of 'test8::A' 2 errors generated. There are a handful other tests failing in the same way. It would be nice if we could make the TypePrinter not print the calling convention if it's the default one for the ABI, but TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ - Hans

> There are a handful other tests failing in the same way. > > It would be nice if we could make the TypePrinter not print the > calling convention if it's the default one for the ABI, but > TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ They are all TypePrinter failures like this one? If so I would say we should not block on it since it is a small QOI issue. On the ot...

...ans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> > wrote: > >> > >> It would be nice if we could make the TypePrinter not print the > >> calling convention if it's the default one for the ABI, but > >> TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > > > > > > Does this patch fix any failures for you? It doesn't fix that test case, > >...

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> wrote: >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > > > Does this patch fix any failures for you? It doesn't fix that test case, > unfortunately. Unfortunately...

....org> wrote: >> >> On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: >> > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> >> > wrote: >> >> >> >> It would be nice if we could make the TypePrinter not print the >> >> calling convention if it's the default one for the ABI, but >> >> TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ >> > >> > >> > Does this patch fix any failures for you? It doesn't fix that...

...n CA->getNumElements() is zero ? Infinite loop???? Wouldn't the following be better. i.e. safer: for (unsigned i = 1; i < CA->getNumElements(); i++) { Kind Regards James At about line 1429: Type *ETy = CA->getType()->getElementType(); Out << '['; TypePrinter.print(ETy, Out); Out << ' '; WriteAsOperandInternal(Out, CA->getElementAsConstant(0), &TypePrinter, Machine, Context); for (unsigned i = 1, e = CA->getNumElements(); i != e; ++i) { Out << ",...

On Tue, Dec 10, 2013 at 2:36 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> There are a handful other tests failing in the same way. >> >> It would be nice if we could make the TypePrinter not print the >> calling convention if it's the default one for the ABI, but >> TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ > > They are all TypePrinter failures like this one? Yes, all except this one (I think): error: 'error' diagnos...

...trings and when storing them in a qualifier, part >> of the address space mask could be dedicated to indicating if this >> LangAS is a string or integer. The only thing I can't think of is how >> printing the AS would work in a diagnostic since, based off the >> existing TypePrinter/Qualifiers::print() method, I do not think I >> would be able to store a reference back to some mapping of addr spaces >> to strings since it seems that the Qualifiers class is meant to be 32 >> bits long and passed by value. >> >> I was going to come up with a proof...

...> >>> On Tue, Dec 10, 2013 at 3:57 PM, Reid Kleckner <rnk at google.com> wrote: >>> > On Tue, Dec 10, 2013 at 11:58 AM, Hans Wennborg <hans at chromium.org> >>> > wrote: >>> >> >>> >> It would be nice if we could make the TypePrinter not print the >>> >> calling convention if it's the default one for the ABI, but >>> >> TypePrinter doesn't have a lot of context.. no Sema, no ASTContext :/ >>> > >>> > >>> > Does this patch fix any failures for you? It d...

I came across a PDB that caused llvm-pdbdump to crash. I tracked it down to a missing overload for a data type in the variable printer. When I tried to provide an implementation, I discovered that there were some bugs in the existing overloads and it was easy to come up with combinations of types that weren't being dumped right. I created some test cases and tried to fix these problems but

...asses that take either integers or strings and when storing them in a qualifier, part of the address space mask could be dedicated to indicating if this LangAS is a string or integer. The only thing I can't think of is how printing the AS would work in a diagnostic since, based off the existing TypePrinter/Qualifiers::print() method, I do not think I would be able to store a reference back to some mapping of addr spaces to strings since it seems that the Qualifiers class is meant to be 32 bits long and passed by value. I was going to come up with a proof of concept in the meantime, but wanted to a...

...::getType(this=0x00000001013ffff6) const at > GlobalValue.h:265 > frame #10: 0x00000001004bad34 > dump`llvm::TypeFinder::run(this=0x00007ffeefbff530, M=0x0000000101401e80, > onlyNamed=false) at TypeFinder.cpp:38 > frame #11: 0x00000001001a97c9 dump`(anonymous > namespace)::TypePrinting::incorporateTypes(this=0x00007ffeefbff530, > M=0x0000000101401e80) at AsmWriter.cpp:491 > frame #12: 0x00000001001a964f dump`(anonymous > namespace)::AssemblyWriter::AssemblyWriter(this=0x00007ffeefbff510, > o=0x00007ffeefbff3f8, Mac=0x00007ffeefbff438, M=0x0000000101401e80, >...

...tadata, llvm::Metadata const*>::ret_type llvm::cast<llvm::ValueAsMetadata, llvm::Metadata const>(llvm::Metadata const*) /llvm/include/llvm/Support/Casting.h:239:0 #10 0x00007f50bc679010 WriteAsOperandInternal(llvm::raw_ostream&, llvm::Metadata const*, (anonymous namespace)::TypePrinting*, llvm::SlotTracker*, llvm::Module const*, bool) /llvm/lib/IR/AsmWriter.cpp:2045:0 #11 0x00007f50bc680e2c printMetadataImpl(llvm::raw_ostream&, llvm::Metadata const&, llvm::ModuleSlotTracker&, llvm::Module const*, bool) /llvm/lib/IR/AsmWriter.cpp:3504:0 #12 0x0000...

..."possible" leaks when it finds a pointer pointing inside a memory block (as opposed to at the first byte), and LLVM uses those a lot. llvm_shutdown() will free a lot of that memory, including the LLVMContext, which should remove any false leaks you might be seeing. On the other hand, the TypePrinting() leak looks like it should keep a pointer to the beginning of the block it allocates, and like it should delete that object on destruction, so something weird is going on. One weird thing might be if you built LLVM in -Asserts mode but didn't define NDEBUG in your own build, since that'...

...() 0xb7c1d754 in polly::ScopDetection::isValidInstruction(llvm::Instruction&, polly::ScopDetection::DetectionContext&) const () The detailed backtrace of "isValidMemoryAccess" is: #0 0x0907b780 in llvm::TypeFinder::run(llvm::Module const&, bool) () #1 0x08f76ebe in llvm::TypePrinting::incorporateTypes(llvm::Module const&) () #2 0x08f76fc9 in llvm::AssemblyWriter::init() () #3 0x08f77176 in llvm::AssemblyWriter::AssemblyWriter(llvm::formatted_raw_ostream&, llvm::SlotTracker&, llvm::Module const*, llvm::AssemblyAnnotationWriter*) () #4 0x08f79d1a in llvm::Value:...

...r(int) + 410 2 libSystem.B.dylib 0x93130b9b _sigtramp + 43 3 libSystem.B.dylib 0xffffffff _sigtramp + 1827468431 4 llc 0x0078d74b createSlotTracker(llvm::Value const*) + 114 5 llc 0x00790c21 WriteAsOperandInternal (llvm::raw_ostream&, llvm::Value const*, llvm::TypePrinting*, (anonymous namespace)::SlotTracker*) + 799 6 llc 0x00794089 llvm::WriteAsOperand (llvm::raw_ostream&, llvm::Value const*, bool, llvm::Module const*) + 126 7 llc 0x005dce23 llvm::operator<<(llvm::raw_ostream&, llvm::MachineMemOperand const&...

...::ScopDetection::isValidInstruction(llvm::Instruction&, > polly::ScopDetection::DetectionContext&) const () > > The detailed backtrace of "isValidMemoryAccess" is: > #0 0x0907b780 in llvm::TypeFinder::run(llvm::Module const&, bool) () > #1 0x08f76ebe in llvm::TypePrinting::incorporateTypes(llvm::Module const&) > () > #2 0x08f76fc9 in llvm::AssemblyWriter::init() () > #3 0x08f77176 in > llvm::AssemblyWriter::AssemblyWriter(llvm::formatted_raw_ostream&, > llvm::SlotTracker&, llvm::Module const*, llvm::AssemblyAnnotationWriter*) () >...

...:initialize(unsigned int) (in /home/gabi/vgen/Debug/vgen) ==20504==    by 0x41945A: main (main.cpp:39) ==20504== ==20504== 24 bytes in 1 blocks are possibly lost in loss record 15 of 205 ==20504==    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220) ==20504==    by 0x874282: llvm::TypePrinting::TypePrinting() (in /home/gabi/vgen/Debug/vgen) ==20504==    by 0x8D9FAD: llvm::LLVMContextImpl::LLVMContextImpl(llvm::LLVMContext&) (in /home/gabi/vgen/Debug/vgen) ==20504==    by 0x8D8BA8: llvm::LLVMContext::LLVMContext() (in /home/gabi/vgen/Debug/vgen) ==20504==    by 0x8D9055: void* llvm...