search for: __powitf2

...PARC. The compilation with a self-build gcc-4.2.4 goes pretty well, however, I hit a seemingly widely know error during llvm-gcc's bootstrap in getting an assertion during the compile of /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c: In function '__powitf2': /data/LLVM/src/GCC/RELEASE_26/gcc/libgcc2.c:1765: internal compiler error: in HandleArgument, at llvm-abi.h:535 Looking into the code of llvm-abi.h, I added the following patch to it: --- /data/LLVM/src/GCC/RELEASE_26/gcc/llvm-abi.h.jnz Thu Oct 29 00:32:52 2009 +++ /data/LLVM/src/GCC/REL...

Hello, Juergen > With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', > so I wonder what needs to be done in order to get LLVM to produce > code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function. > > > Does anyone have an idea? And why does this only happen on SPARC? What is the value of "Ty" in your case?

Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep

Hello, Juergen > Ty->dump() prints "{double, double}" in the failing case (just before my > introduced assert). The answer is simple. The code in question contains extended IEEE FP argument / return type (aka 'long double'). By default it's lowered into struct {double, double} as you already saw and sparc currently does not provide any argument layout hooks. There

Hi Anton, thanks for the fast response. Ty->dump() prints "{double, double}" in the failing case (just before my introduced assert). HTH, and regards, Juergen On 10/30/09 16:19, Anton Korobeynikov wrote: > Hello, Juergen > >> With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', >> so I wonder what needs to be done in order to get

...libdecnumber -I../libdecnumber -I/Users/luked/install/obj/llvm-svn/include -I/Users/luked/install/src/llvm-svn/include -DL_powitf2 -fvisibility=hidden -DHIDE_EXPORTS -c ../../../../src/llvm-gcc-svn/gcc/libgcc2.c -o libgcc/./_powitf2.o ../../../../src/llvm-gcc-svn/gcc/libgcc2.c: In function '__powitf2': ../../../../src/llvm-gcc-svn/gcc/libgcc2.c:1765: internal compiler error: in HandleArgument, at llvm-abi.h:520 It seems like the sparc-sun-solaris2.10 triple isn't currently supported correctly. I'm considering trying to fix it myself, but my research is in scalable shared memory...

Mike Stump wrote: > On Oct 31, 2008, at 1:10 PM, Luke Dalessandro wrote: >> I've started trying by trying to get sparc-sun-solaris2.10 (niagara) >> working. It appears that neither llvm nor llvm-gcc will build natively >> on the system, so I think that I need to build an llvm-gcc cross >> compiler. > > Get a gcc binary from someplace, use that to then build