search for: getpointeetyp

...pp @@ -399,10 +399,16 @@ void TypePrinter::printMemberPointerBefore(const MemberPointerType *T, raw_ostream &OS) { IncludeStrongLifetimeRAII Strong(Policy); SaveAndRestore<bool> NonEmptyPH(HasEmptyPlaceHolder, false); - printBefore(T->getPointeeType(), OS); + + // Suppress the printing of implied calling conventions. + QualType Pointee = T->getPointeeType(); + if (const AdjustedType *AT = dyn_cast<AdjustedType>(Pointee)) + Pointee = AT->getOriginalType(); + + printBefore(Pointee, OS); // Handle things like 'int (Cls:...

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.

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

Hello, I am writing a compiler which outputs LLVM for my own custom language. Thanks to everybody who has contributed to the project it really is an impressive tool chain. I downloaded the 3.7 release from the website and I noticed that there had been a change to getelementptr. I can see the new syntax in the latest version of the Language Reference Manual but I could find no other reference to

...the need arise. > Also this works for writing, but not for reading - if code was expecting > to read IR and assumed that pointers had types and bitcasts were present, > etc - it's going to have a Bad Time reading new IR... the APIs wouldn't > make any sense (there would be no getPointeeType on PointerType anymore - > there would be no Type that could be returned in response to that query) > > That's part of Eric's point, I think, once the API is low level enough, it > will churn with every change in LLVM or possible require some heroics to > avoid that churn wh...

...ever executes abort function. So, I debug source code of clang. In the 3167 line of ExprConstant.cpp(tools/clang/lib/AST/ExprConstant.cpp), these codes are 3166: // Don't call function pointers which have been cast to some other type. 3167: if (!Info.Ctx.hasSameType(CalleeType->getPointeeType(), FD->getType())) 3168: return Error(E); It returns Error(E) . Then, the expression "foo(((~0U)>>1))" is optimized out in the later stage. Here FD is foo's function pointer, so I think it should not return Error. Maybe it is bug, could someone help me with t...

There are two C++ signatures for CreateConstGEP1_32: Value * CreateConstGEP1_32 (Value *Ptr, unsigned Idx0, const Twine &Name="") Value * CreateConstGEP1_32 (Type *Ty, Value *Ptr, unsigned Idx0, const Twine &Name="") I'm assuming that this means that the caller can supply the expected type, and get error checking or casting? Or choose to not supply the

As someone who used the LLVM C API for an experiment back in 2009ish (porting the SBCL lisp compiler to target LLVM as a backend -- never finished), I thought it was great that LLVM provided the C API. I was sad that it wasn't properly updated to include support for all the newly introduced IR features, though. (E.g. atomics). I tried to send patches for some of that stuff a while later, but