search for: _muldc3

everyone-- My build of LLVM-GCC from top-of-trunk sources is failing with the assertion in ARMISelTargetLowering at line 667, in LowerRET, where it says "Do not know how to return this many arguments!" This happens when the cross-compiler attempts to build _muldc3 for libgcc2. The more I have investigated this problem, them more convinced I have become that this isn't a stupid newbie bug, but something more troubling in the integration of ARM code generation with LLVM-GCC. For reasons I haven't been able to understand yet, there are nine oper...

...<llvm-gcc-4.2-source>/gcc -I<llvm-gcc-4.2-source>/gcc/. -I<llvm-gcc-4.2-source>/gcc/../include -I<llvm-gcc-4.2-source>/gcc/../libcpp/include -I<llvm-gcc-4.2-source>/gcc/../libdecnumber -I../libdecnumber -I<llvm-install>/llvm/include -I<llvm-src/llvm/include -DL_muldc3 -fvisibility=hidden -DHIDE_EXPORTS -c ../../../../src/llvm-gcc-4.2/gcc/libgcc2.c -o libgcc/./_muldc3.o cc1: <llvm-src>/llvm/lib/CodeGen/RegisterScavenging.cpp:273: void llvm::RegScavenger::forward(): Assertion `(isReserved(Reg) || isUnused(Reg) || IsImpDef || isImplicitlyDefined(Reg) || isLiv...

On Apr 30, 2008, at 11:19 PM, james woodyatt wrote: >> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not >> fixed up You need to run the compile with -save-temps and then look at the .s file. If you like it, it is an assembler bug. If you don't like it, it is a bug in the compiler. If you don't know if you like it, as your assembler vendor (binutils)

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something