search for: typeprinter

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 othe...

...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, > > u...

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 te...

...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' diagnosti...

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

...> >>> 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 doe...

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 ask...

I am trying to parse LLVM IR from a bit code file. I went through the following steps. hello.cpp #include <iostream> int main() { std::cout << "Hello world!" << "\n"; return 0;} dump.cpp #include <llvm/IR/Module.h>#include <llvm/IRReader/IRReader.h>#include <llvm/IR/LLVMContext.h>#include <llvm/Support/SourceMgr.h> using

Hello. I generated in the back end by hand (in C++ code, not with TableGen) some fancy assembly code using Inline ASM expressions and if I use 2 functions in my source code (but NOT just 1 function; I will not present the functions, but each requires me to generate an Inline ASM expression) I get this error at compilation (at scheduling): BB#0: derived from LLVM BB %entry

Are you calling llvm_shutdown() at the end of your program? You should. valgrind reports "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

At 2013-07-14 13:20:42,"Tobias Grosser" <tobias at grosser.es> wrote: >On 07/13/2013 09:18 PM, Star Tan wrote: >> >> >> At 2013-07-14 02:30:07,"Tobias Grosser" <tobias at grosser.es> wrote: >>> On 07/13/2013 10:13 AM, Star Tan wrote: >>>> Hi Tobias, >>> >>> Hi Star, >[...] >>> Before we write a

Are these known to be broken right now? I get failure when using either. $ llc -march=arm -print-machineinstrs hw.bc ... BB#0: derived from LLVM BB %entry Live Ins: %LR %R7 %SP<def> = SUBri %SP<kill>, 8, 14, %reg0, %reg0 STR %LR<kill>, %SP, %reg0, 4, 14, %reg0; mem:ST4[0 llc 0x008b3304 PrintStackTrace(void*) + 45 1 llc 0x008b390c

Tobi, it looks like this code is the problem: for (std::vector<Value *>::iterator PI = Pointers.begin(), PE = Pointers.end(); ;) { Value *V = *PI; if (V->getName().size() == 0) OS << "\"" << *V << "\""; else OS << "\"" << V->getName() <<

Hi Jeffrey, Listed below the Full valgrind report (using latest revision r99309) The program creates many thousands of instructions and values as you can see from the report below ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==20504==