search for: typeprinting

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.

On Mon, Dec 9, 2013 at 5:18 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > 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.

> 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

I think we need to relax the test cases. MSVC usually prints the calling convention, and it's often useful information. Maybe we can make the diagnostic text smaller by using the __thiscall, __cdecl, __stdcall, etc keywords when printing types with LangOpts.MicrosoftExt, but it will require moving the attribute from after the identifier to before, which is exciting. On Tue, Dec 10, 2013 at

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

On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: > I think we need to relax the test cases. MSVC usually prints the calling > convention, and it's often useful information. I was going to argue that MSVC doesn't print them, but then I tried, and you're right - it does :) I'll start relaxing the tests then. > Maybe we can make the

Hi, See fuller extract below. I am curious about the for loop. for (unsigned i = 1, e = CA->getNumElements(); i != e; ++i) { What happens when 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 =

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 :/

+cfe-dev at lists.llvm.org On Thu, Jan 10, 2019 at 2:16 PM Jacob Lifshay <programmerjake at gmail.com> wrote: > > Stash a lookup table from integers to strings in Context and dynamically allocate integers for new strings. You can then keep integers in most of the code, writing/displaying strings for the integers with an entry in the table when writing to files or displaying. > >

On Tue, Dec 10, 2013 at 5:08 PM, Hans Wennborg <hans at chromium.org> wrote: > On Tue, Dec 10, 2013 at 4:39 PM, Reid Kleckner <rnk at google.com> wrote: >> I think we need to relax the test cases. MSVC usually prints the calling >> convention, and it's often useful information. > > I was going to argue that MSVC doesn't print them, but then I tried, >

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

Hello, We would like to propose a way for improving the diagnostics for address_space by being able to pass strings as an argument to it instead of just an integer. This was initially proposed before (http://lists.llvm.org/pipermail/cfe-dev/2018-August/058702.html) but did not focus on it at the time. Reasoning: Clang's __attribute__((address_space(...))) feature uses an arbitrary integer as

...::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, > AA...

...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 0x00007f5...

..."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'll...

...() 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::pr...

...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*) () > #4...

...: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::o...