The 177.mesa test fails on Sparc (seraph). The numerical output does not match that generated by the native version of 177.mesa.
How does this test fail? Are the numbers close, but slightly different? Or is it obviously wrong in some major way? I'm seeing mesa fail on X86 with LARGE_PROBLEM_SIZE, but I think that it's roundoff or similar issues... -Chris
*** Bug 145 has been marked as a duplicate of this bug. ***
(Bug 145 notes that the SPARC also apparently fails in the JIT on Mesa.)
I'm just going to make this a general "the sparc backend has issues" bug. Many spec benchmarks don't work, many multisource benchmarks don't work, and noone is interested in fixing them. -Chris
*** Bug 144 has been marked as a duplicate of this bug. ***
It seems that the sparc backend (as of 26-Feb) can't seem to compile simple programs (e.g. nestedloop.llvm.bc) that come out of the x86 backend. This is not the usual case, admittedly, but I don't think that it should cause a crash. It crashes in InstructionSelection::SelectInstructionsForTree().
Changing all of these bugs who do not have people looking at them to be assigned to "unassignedbugs", indicating that if someone is feeling ambitious, they can take ownership of the bug. If I stole your bug, and you still want it, feel free to take ownership back. -Chris
The sparcv9 code generator will sometimes generate branches for which the displacement is too large to fit in the appropriate field of the branch instruction. This bug afflicts 252.eon in llc. It manifests itself as invalid output from llc - the Solaris assembler fails to assemble the branch instruction(s) in question and prints an error message. The sparcv9 code generator will also sometimes let the SETSW pseudo-instruction be seen by the JIT code emitter. This bug afflicts 252.eon in the JIT. It manifests itself in SparcV9CodeEmitter: it hits the end of the giant switch statement, prints an error message, and aborts.
The following spec2000 programs are also currently known to fail with llvm for sparcv9: 177.mesa llc - fails assertion in TargetRegInfo 177.mesa cbe - fails diffs 177.mesa jit - fails diffs 175.vpr llc - fails diffs (FP problem?) 186.crafty llc - fails assertion in PhyRegAlloc 252.eon llc - output fails to assemble (see above) 252.eon jit - fails assertion in SparcV9CodeEmitter (see above) 253.perlbmk llc - fails diffs 253.perlbmk cbe - fails diffs
MallocBench/cfrac does not work on the sparc using the native 64-bit sparc gcc, or using the LLVM tools configured for sparcv9. It does work using native 32-bit sparc gcc, which suggests that it is not 64-bit clean.
MultiSource/Benchmarks/Olden: power fails in cbe. This is because Solaris doesn't have the (new in C99) printf %a format specifier. voronoi fails in jit (but not llc!). Not quite sure why. SingleSource/UnitTests: 2003-05-26-Shorts.c appears to fail, but in fact, the LLVM compiler produces the correct output, and native GCC is wrong.
The following SPEC2000 programs are failing on sparcv9. This supersedes the previous list. 175.vpr llc - "word displacement will not fit in 16 bits" error from SPARC as 252.eon llc - "word displacement will not fit in 16 bits" error from SPARC as 253.perlbmk llc - "word displacement will not fit in 16 bits" error from SPARC as 176.gcc cbe,jit - segmentation fault 252.eon jit - segmentation fault 253.perlbmk jit - segmentation fault 176.gcc native,llc - aborts in expand_expr() 177.mesa cbe - fails diffs 177.mesa llc - Assertion failed: UserRegType == RegTypeWanted && "Default method is probably incorrect for class with multiple types.", file SparcV9RegInfo.h, line 62 186.crafty native,llc,cbe,jit - cpu time limit exceeded (time limit = 2000) 252.eon native - can't find output files pixels_out.kajiya, pixels_out.rushmeier? 253.perlbmk native,cbe - bus error
This testcase crashes the V9 code generator: ---- implementation ; Functions: void %Warning(double %level, sbyte* %format, ...) { entry: ret void } ---- llc: SparcV9RegInfo.cpp:459: void llvm::SparcV9RegInfo::colorMethodArgs(const llvm::Function*, llvm::LiveRangeInfo&, std::vector<llvm::MachineInstr*, std::allocator<llvm::MachineInstr*> >&, std::vector<llvm::MachineInstr*, std::allocator<llvm::MachineInstr*> >&) const: Assertion `0 && "This could should work but it is not tested yet"' failed. -Chris
This is what you get when you run bugpoint after taking out the "This should work" assertion. It's a very slightly expanded version of the previous testcase: --------- implementation ; Functions: void %Warning(double %level, sbyte* %format, ...) { entry: %tmp.7 = setgt double 0x0, %level ; <bool> [#uses=0] ret void } --------- The "This should work" assertion failure Chris posted in comment#14 is actually obscuring another, more serious problem: the sparcv9 register allocator is trying to allocate %level to an odd-numbered %f-register, which is not OK; on sparcv9, doubles are supposed to be allocated to (even,odd)-numbered pairs of (32-bit-wide) %f-registers addressed by the lower, even-numbered register in the pair. (It's explained in the ABI doc.) I'm not sure how to fix this yet.
SparcV9 llc fails an assertion on the following test case. It's a stupid program, but all the other code generators can handle it. ---------- implementation ; Functions: void %main() { entry: call void null( ) ret void } ----------
This test case produces bad assembly code (rejected by solaris as): ------------------- target endian = big target pointersize = 64 %struct..TorRec = type { int, void ()* } %llvm.global_ctors = internal constant [2 x %struct..TorRec] [ %struct..TorRec { int 65535, void ()* %ctor }, %struct..TorRec { int 2147483647, void ()* null } ] ; <[2 x %struct..TorRec]*> [#uses=2] %llvm.global_dtors = internal constant [2 x %struct..TorRec] [ %struct..TorRec { int 65535, void ()* %dtor }, %struct..TorRec { int 2147483647, void ()* null } ] ; <[2 x %struct..TorRec]*> [#uses=2] implementation ; Functions: internal void %ctor() { entry: ret void } internal void %dtor() { entry: ret void } ------------------- I think it's due to the recent sparcv9 assembly writer changes. The assembly writer is emitting zero bytes in the global_ctors and global_dtors arrays using .xword, at a point at which the current location in the assembly file is not 64-bit aligned. I haven't completely analyzed this yet. It affects many large (MultiSource and SPEC) programs.
Comment#16 and comment#17 are now out of date. Here is a partial list of failing SPEC benchmarks as of 10-Sep-2004. CFP2000/177.mesa An assertion fails trying to generate assembly code with llc: /home/vadve/gaeke/llvm_seraph/tools/Debug/llc -f Output/177.mesa.llvm.bc -o Output/ 177.mesa.llc.s Assertion failed: UserRegType == RegTypeWanted && "Default method is probably incorrect for class with multiple types.", file SparcV9RegInfo.h, line 62 CINT2000/175.vpr, CINT2000/253.perlbmk, and CINT2000/252.eon Branches (using the "brz" opcode) are being emitted too far away from their targets, resulting in assembler errors of the following form. The specified lines of the llc output file are shown for reference. /usr/dcs/software/evaluation/bin/gcc Output/175.vpr.llc.s -lm -lm -lm -o Output/175.vpr.llc /usr/ccs/bin/as: "Output/175.vpr.llc.s", line 47777: error: word displacement will not fit in 16 bits 47777 brz %o0, .L_main_l2_loopexit_2E_3_2E_i /usr/ccs/bin/as: "Output/175.vpr.llc.s", line 47963: error: word displacement will not fit in 16 bits 47963 brz %o0, .L_main_l2_loopexit_2E_3_2E_i_2E_loopexit /usr/dcs/software/evaluation/bin/gcc Output/252.eon.llc.s -lm -lstdc++ -lm -o Output/252.eon.llc /usr/ccs/bin/as: "Output/252.eon.llc.s", line 81541: error: word displacement will not fit in 16 bits 81541 brz %l0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8 /usr/ccs/bin/as: "Output/252.eon.llc.s", line 115522: error: word displacement will not fit in 16 bits 115522 brz %o0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8 /usr/ccs/bin/as: "Output/252.eon.llc.s", line 115533: error: word displacement will not fit in 16 bits 115533 brz %o0, .L_l64__ZN7mrScene4ReadERSi_l2_invoke_catch_2E_8 [etc.] CINT2000/176.gcc A miscompilation is causing the llc-generated code for gcc to crash with a segfault. The stack trace is as follows: Core was generated by `../../Output/176.gcc.llc cp-decl.i -o - -quiet'. Program terminated with signal 11, Segmentation fault. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... #0 0x100027cb8 in l73_decl_attributes () #0 0x100027cb8 in l73_decl_attributes () #1 0x100067be0 in l101_finish_struct () #2 0x1000a2f68 in l184_yyparse () #3 0x100370710 in l177__2E_compile_file_28 () #4 0x100387f5c in main () CINT2000/253.perlbmk The gcc-compiled ("native") benchmark does not work - it crashes with a bus error, and the stack trace is as follows: Core was generated by `../../Output/253.perlbmk.native scrabbl.pl'. Program terminated with signal 10, Bus error. (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... #0 0x10007f6cc in reganode () #0 0x10007f6cc in reganode () #1 0x10007aed8 in reg () #2 0x10007d2d8 in regatom () #3 0x10007c410 in regpiece () #4 0x10007c2ec in regbranch () #5 0x10007aee8 in reg () #6 0x10007a598 in Perl_pregcomp () #7 0x10002fcb0 in Perl_pmruntime () #8 0x100042bcc in Perl_yyparse () #9 0x100039560 in perl_parse () #10 0x1000b04e0 in main () CINT95/126.gcc An assertion fails trying to generate assembly code with llc: /home/vadve/gaeke/llvm_seraph/tools/Debug/llc -f Output/126.gcc.llvm.bc -o Output/126.gcc.llc.s Assertion failed: (!isBranch || AddedInstrMap[MInst].InstrnsAfter.size() <= TM.getInstrInfo()- >getNumDelaySlots(MInst->getOpcode())) && "Cannot put more than #delaySlots instrns after " "branch or return! Need to handle temps differently.", file PhyRegAlloc.cpp, line 570 CINT95/132.ijpeg This benchmark doesn't link because it can't find the symbol sys_errlist.