search for: codegentypes

...t/lldb/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2430 #14 0x00007ffff4c46af0 in (anonymous namespace)::CGRecordLayoutBuilder::Layout (this=0x7fffffff66a8, D=0xd6a140) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:208 #15 0x00007ffff4c461ab in clang::CodeGen::CodeGenTypes::ComputeRecordLayout (this=0xd63d90, D=0xd6a140, Ty=0xd65c10) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:969 #16 0x00007ffff4cce43f in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0xd63d90, RD=0xd6a140) at /home/athirumurthi/git/lldb/tools/...

...t/lldb/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2430 #14 0x00007ffff4c46af0 in (anonymous namespace)::CGRecordLayoutBuilder::Layout (this=0x7fffffff66a8, D=0xd6a140) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:208 #15 0x00007ffff4c461ab in clang::CodeGen::CodeGenTypes::ComputeRecordLayout (this=0xd63d90, D=0xd6a140, Ty=0xd65c10) at /home/athirumurthi/git/lldb/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp:969 #16 0x00007ffff4cce43f in clang::CodeGen::CodeGenTypes::ConvertRecordDeclType (this=0xd63d90, RD=0xd6a140) at /home/athirumurthi/git/lldb/tools/...

...a7d8a97d05 gsignal + 53 4 libc.so.6 0x00002ba7d8a9bab6 abort + 390 5 libc.so.6 0x00002ba7d8a907c5 __assert_fail + 245 6 clang 0x00000000007774c7 7 clang 0x0000000000775aee 8 clang 0x0000000000777d1c 9 clang 0x0000000000782550 clang::CodeGen::CodeGenTypes::arrangeFunctionType(clang::CanQual<clang::Type>, llvm::ArrayRef<clang::CanQual<clang::Type> >, clang::FunctionType::ExtInfo const&, clang::CodeGen::RequiredArgs) + 384 10 clang 0x0000000000783228 clang::CodeGen::CodeGenTypes::arrangeCXXConstructorDeclaration(clang::...

Hi, I tried the little examples from here: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html clang -fsyntax-only worked fine, but clang -emit-llvm had problems: Assertion failed: (0 && "FIXME: Cannot get type of block pointer."), function ConvertNewType, file CodeGenTypes.cpp, line 329. I use svn revision 58329. Is it just a temporary problem or did it not work at all? Do I miss something? I only want to know how blocks and local stack stuff a represented in LLVM IR (.ll). Thanks a lot, Nico

...e the complete FILE > struct definition. The only difference between these two IR structs is that > a function pointer type field in the first form is replaced by {}* in the > second form. Could anyone tell me why this happens and how to disable the > {}* replacement? > > > See CodeGenTypes::isFuncTypeArgumentConvertible in clang/lib/CodeGen/CodeGenTypes.cpp; this behavior exists to protect the type conversion code from infinite recursion. Our behavior could probably be improved here; patches welcome (but be warned the code is rather complicated). Off the top of my head, I can't...

...a MSP430ABIInfo class derived from ABIInfo, check how other targets do it in the same file. The important part here is how you implement the classifyReturnType and classifyArgumentType functions, they should basically look like this: class MSP430ABIInfo : public ABIInfo { public: MSP430ABIInfo (CodeGenTypes &CGT) : ABIInfo(CGT) {} ABIArgInfo classifyReturnType(QualType RetTy) const; ABIArgInfo classifyArgumentType(QualType RetTy) const; virtual void computeInfo(CGFunctionInfo &FI) const { FI.getReturnInfo() = classifyReturnType(FI.getReturnType()); for (CGFunctionInfo::arg_iter...

...All, I’m working on a project that extends C. I’m adding a new type of pointer that is a fat pointer. It has some metadata about the pointed object besides the starting address of the object. Currently I implemented this pointer as an llvm:StructType. In llvm::Type generation function llvm::Type *CodeGenTypes::ConvertType(QualType T) in the case for clang::Type::Pointer, instead of creating an llvm::PointerType I create an llvm::StructType type for this new type of pointer. And I added some helper code in llvm::StructType and in multiple places I added code to trick the compiler to believe sometimes a s...

...type before calling it. Shouldn't be too hard to implement. 3. There are other CodeGen tests that fail with assertion failures, which I haven't investigated. (I'm starting to wonder if I went too far when I ripped out all the PointersToResolve / HandleLateResolvedPointers() stuff from CodeGenTypes.cpp.) 4. A bunch of the CodeGen tests need adjusting because we're generating slightly different IR from what they expect. > Can you create a branch of the clang repo or send an updated version of the patch to the list? I'd be very surprised if I have the authority to create a branch,...

Dear LLVM developers, My name is Ben Niu and I am a Ph.D. student at Lehigh University. I compiled the MUSL C library using Clang 3.3, and dumped the generated LLVM IR files. I found that the MUSL-defined FILE struct (aliasing __FILE_s) struct __FILE_s { unsigned flags; unsigned char *rpos, *rend; int (*close)(FILE *); unsigned char *wend, *wpos; unsigned char *mustbezero_1;

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >

An update on the type-system-rewrite branch (http://llvm.org/viewvc/llvm-project/llvm/branches/type-system-rewrite/): It's now to the point where it passes all regression tests all of single source (and most of externals/multisource) when using an LLVM 2.9 version of clang to compile programs to a rbc file. I have what looks like one more subtle type mapping bug to track down, which will

...all of the assumptions in the clang IRGen that was assuming that the type return by a field access load was sane (they'd blow up when they got an unexpected {}* instead of a function pointer or whatever). Once everything worked, I added the 'isSafeToConvert' logic in clang/lib/CodeGen/CodeGenTypes.cpp. The idea is that when converting the first "g" example, there is no way we can do better than {}*. OTOH, in the second "h" example there is no problem recursively converting X to a nice type, and isSafeToConvert returns true for it. Because we can recurse into it, we get...

Hi Chris, >> Chris made major changes to the LLVM type system, which requires major changes >> to dragonegg (c.f. the patch Chris applied to llvm-gcc). I'm on holiday which >> is why I haven't taken care of it yet. > > Yeah, sorry about that Duncan. I can't directly hack on the code, but I'm happy to answer questions when you get back. there seems to be

On Jul 18, 2011, at 1:32 PM, Duncan Sands wrote: > On 18/07/11 15:59, Jack Howarth wrote: >> Despite the commit of... > > Chris made major changes to the LLVM type system, which requires major changes > to dragonegg (c.f. the patch Chris applied to llvm-gcc). I'm on holiday which > is why I haven't taken care of it yet. Yeah, sorry about that Duncan. I

...use, so there's nothing else to change. > 3. There are other CodeGen tests that fail with assertion failures, > which I haven't investigated. (I'm starting to wonder if I went too > far when I ripped out all the PointersToResolve / > HandleLateResolvedPointers() stuff from CodeGenTypes.cpp.) Hmm... there shouldn't be anything you need to handle there, I think. > 4. A bunch of the CodeGen tests need adjusting because we're > generating slightly different IR from what they expect. > >> Can you create a branch of the clang repo or send an updated version of...