search for: forwardtype

Ok that works but why on earth would I get a runtime error of: Type.cpp:132: const llvm::Type* llvm::Type::getForwardedTypeInternal() const: Assertion `ForwardType && "This type is not being forwarded to another type!"' failed. Aborted For the line of code: MyModule = new Module( std::string("IDontWork")); > -----Original Message----- > From: llvmdev-admin at cs.uiuc.edu [mailto:llvmdev-admin at cs.uiuc.edu] On > Be...

> Ok that works but why on earth would I get a runtime error of: > > Type.cpp:132: const llvm::Type* llvm::Type::getForwardedTypeInternal() > const: Assertion `ForwardType && "This type is not being forwarded to > another type!"' failed. > Aborted > > For the line of code: > > MyModule = new Module( std::string("IDontWork")); I was getting these recently when we made the switch from -fshort-enums to -fno-short-enum...

Hi LLVMdev, I am trying to add declarations of some functions in a module, and the following assert is failing test_task_inst: Type.cpp:130: const Type* Type::getForwardedTypeInternal() const: Assertion `ForwardType && "This type is not being forwarded to another type!"' failed. Any idea what the bug might be? The code was working about 3 months ago, and I am not aware of any changes that might cause it to fail. Thanks, Rahul

...: FAIL , expected PASS Script: /usr/home/wanderer/pkg/build/llvm/obj/test/tmp/trConstantExprFold.llx/testsc ript.ConstantExprFold.llx Output: /usr/home/wanderer/pkg/build/llvm/obj/test/tmp/trConstantExprFold.llx/testsc ript.ConstantExprFold.llx.out Regression.C++Frontend.2003-08-28-ForwardType : XPASS Regression.C++Frontend.2003-09-30-ForIncrementExprBug2: XPASS Regression.CFrontend.2003-01-30-UnionInit : FAIL , expected PASS Compiling C code failed Regression.CFrontend.2003-06-29-MultipleFunctionDefinition: XPASS Regression.CFrontend.2003-08-30-AggregateInitialize...

...0x921f6fc}, UseList = 0x8d5a550, Name = 0x8e06088} This is the output when I type "print *V1->getType()" in gdb: {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x92184c0}, ID = 72, Abstract = true, SubclassData = 299242, RefCount = 153191633, Context = @0x89f3aac, ForwardType = 0x0, AbstractTypeUsers = {<std::_Vector_base<llvm::AbstractTypeUser*, std::allocator<llvm::AbstractTypeUser*> >> = { _M_impl = {<std::allocator<llvm::AbstractTypeUser*>> = {<__gnu_cxx::new_allocator<llvm::AbstractTypeUser*>> = {<No data field...

...ture.cc.packed : FAIL , expected PASS Failed to convert /usr/home/llvm/obj/test/tmp/feature-cc-packed.ll to C code. qmtest.target: local And finally: Feature.cc.weirdnames /usr/home/llvm/obj/../test/Regression/C++Frontend/2003-08-28-ForwardType.cpp:3: warning: inline function `void* operator new(unsigned int, void*)' used but n ever defined /usr/home/llvm/obj/../test/Regression/CFrontend/2002-02-18-64bitConstant.c: In function `main': /usr/home/llvm/obj/../test/Regression/CFrontend/2002-02-18-64bitConstant.c:3: warning: return ty...

You'll need to include the "support" library to resolve these LeakDetector symbols. You can do this by either placing the path to "support.o" or -lsupport on your link line (in your Makefile). Note that if you use the -l option, you'll likely need to use -L<path> as well to tell the linker where to find "libsupport.a" (file included by the

Can anyone help with these crazy linking errors?? /home/kgibbs/CS321/CVS/llvm/lib/Debug/vmcore.o(.gnu.linkonce.t._ZN4llvm12Lea kDetector16addGarbageObjectEPKNS_5ValueE+0xd): In function `llvm::LeakDetector::addGarbageObject(llvm::Value const*)': /usr/include/c++/3.2.1/bits/stl_pair.h:148: undefined reference to `llvm::LeakDetector::addGarbageObjectImpl(llvm::Value const*)'

Thanks Vladimir. That's great! Glad you got it working. BTW, the failures you're seeing have been experienced by Chris and I as well. Chris is diligently working on making the LLVM processing more consistent so he track down the problem. A week ago or so, these tests passed at 100%. Reid. On Sun, 2004-06-20 at 15:50, Vladimir Merzliakov wrote: > In attached file. > > Vladimir

In attached file. Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: test2004_06_20.log Type: application/octet-stream Size: 88488 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040620/98042f01/attachment.obj>

...cript: > /usr/home/wanderer/pkg/build/llvm/obj/test/tmp/trConstantExprFold.llx/testsc > ript.ConstantExprFold.llx > Output: > /usr/home/wanderer/pkg/build/llvm/obj/test/tmp/trConstantExprFold.llx/testsc > ript.ConstantExprFold.llx.out > > Regression.C++Frontend.2003-08-28-ForwardType : XPASS > > Regression.C++Frontend.2003-09-30-ForIncrementExprBug2: XPASS > > Regression.CFrontend.2003-01-30-UnionInit : FAIL , expected PASS > Compiling C code failed > > Regression.CFrontend.2003-06-29-MultipleFunctionDefinition: XPASS > > Regression...

On Fri, 1 Sep 2006, Michael McCracken wrote: > Here's what works now, and I have a separate test case for each of these: > > statement functions > intrinsic functions (print, cos, etc) > loops, goto statments > scalarized array operations > function calls with *no arguments* > simple common blocks Great! > Function calls with more than one argument don't work.

Jeff, Actually, that was my fault. I forgot to remove the non-existent directories from the configure.ac file. That's done and committed now, so the advice is still the same: update configure script :) Reid. On Sun, 2004-09-05 at 09:53, Jeff Cohen wrote: > Configure gives me these errors on FreeBSD. I'm proceding with the build anyway to see what happens. Don't worry :)

...est/tmp/feature-cc-packed.ll to C code. > > qmtest.target: > local > Incomplete feature. The Packed lowering pass hasn't been implemented yet. > And finally: > > Feature.cc.weirdnames /usr/home/llvm/obj/../test/Regression/C++Frontend/2003-08-28-ForwardType.cpp:3: warning: inline function `void* operator new(unsigned int, void*)' used but n > ever defined > /usr/home/llvm/obj/../test/Regression/CFrontend/2002-02-18-64bitConstant.c: In function `main': > > /usr/home/llvm/obj/../test/Regression/CFrontend/2002-02-18-64bitConstant.c:3...

The NIST F77 test suite doesn't seem to be compatible with gfortran at all, so I had to work from my own sample codes, and generate test cases from them. Here's what works now, and I have a separate test case for each of these: statement functions intrinsic functions (print, cos, etc) loops, goto statments scalarized array operations function calls with *no arguments* simple common

Hi all, We're hitting some walls here when generating the correct structure layout for specific C++ ABI requirements, and I was wondering how much StructLayout could help. For instance, the ABI has some complicated rules on the size of derived classes (http://www.codesourcery.com/public/cxx-abi/abi.html#class-types) and LLVM struct type cannot reflect that in full. Example: // CHECK: