[SparcV9] The SparcV9 backend miscompiles several programs #432
Comments
|
How does this test fail? Are the numbers close, but slightly different? Or is -Chris |
|
*** Bug llvm/llvm-bugzilla-archive#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 -Chris |
|
*** Bug llvm/llvm-bugzilla-archive#144 has been marked as a duplicate of this bug. *** |
|
It seems that the sparc backend (as of 26-Feb) can't |
|
Changing all of these bugs who do not have people looking at them to be assigned If I stole your bug, and you still want it, feel free to take ownership back. -Chris |
1 similar comment
|
Changing all of these bugs who do not have people looking at them to be assigned 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 The sparcv9 code generator will also sometimes let the SETSW pseudo-instruction be seen by the JIT |
|
The following spec2000 programs are also currently known to fail with llvm for sparcv9: 177.mesa llc - fails assertion in TargetRegInfo |
|
MallocBench/cfrac does not work on the sparc using the native 64-bit sparc gcc, or |
|
MultiSource/Benchmarks/Olden: SingleSource/UnitTests: |
|
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 176.gcc cbe,jit - segmentation fault 176.gcc native,llc - aborts in expand_expr() |
|
This testcase crashes the V9 code generator: implementation ; Functions: void %Warning(double %level, sbyte* %format, ...) {
|
|
This is what you get when you run bugpoint after taking out the "This should work" implementation ; Functions: void %Warning(double %level, sbyte* %format, ...) {
|
|
SparcV9 llc fails an assertion on the following test case. It's a stupid implementation ; Functions: void %main() {
|
|
This test case produces bad assembly code (rejected by solaris as): target endian = big implementation ; Functions: internal void %ctor() { internal void %dtor() {
|
|
Comment#16 and comment#17 are now out of date. 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/ 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 /usr/dcs/software/evaluation/bin/gcc Output/175.vpr.llc.s -lm -lm -lm -o Output/175.vpr.llc CINT2000/176.gcc A miscompilation is causing the llc-generated code for gcc to crash with a segfault. The stack trace is Core was generated by `../../Output/176.gcc.llc cp-decl.i -o - -quiet'. CINT2000/253.perlbmk The gcc-compiled ("native") benchmark does not work - it crashes with a bus error, and the stack trace Core was generated by `../../Output/253.perlbmk.native scrabbl.pl'. 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
CINT95/132.ijpeg This benchmark doesn't link because it can't find the symbol sys_errlist. |
Quuxplusone
added
the
wontfix
This is part 3 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.cmp` which implements the relational comparison operators (`== != < > <= >=`) on vector types. A new operation was created rather than reusing `cir.cmp` because the result is a vector of a signed intergral type, not a `bool`. Add CodeGen and Lowering tests for vector comparisons. Fix the floating-point comparison predicate when lowering to LLVM. To handle NaN values correctly, the comparisons need to be ordered rather than unordered. (Except for `!=`, which needs to be unordered.) For example, "ueq" was changed to "oeq".
This is part 3 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.cmp` which implements the relational comparison operators (`== != < > <= >=`) on vector types. A new operation was created rather than reusing `cir.cmp` because the result is a vector of a signed intergral type, not a `bool`. Add CodeGen and Lowering tests for vector comparisons. Fix the floating-point comparison predicate when lowering to LLVM. To handle NaN values correctly, the comparisons need to be ordered rather than unordered. (Except for `!=`, which needs to be unordered.) For example, "ueq" was changed to "oeq".
This is part 3 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.cmp` which implements the relational comparison operators (`== != < > <= >=`) on vector types. A new operation was created rather than reusing `cir.cmp` because the result is a vector of a signed intergral type, not a `bool`. Add CodeGen and Lowering tests for vector comparisons. Fix the floating-point comparison predicate when lowering to LLVM. To handle NaN values correctly, the comparisons need to be ordered rather than unordered. (Except for `!=`, which needs to be unordered.) For example, "ueq" was changed to "oeq".
…tream_merge_20250201055914 merge main into amd-staging
This is part 3 of implementing vector types and vector operations in ClangIR, issue llvm#284. Create new operation `cir.vec.cmp` which implements the relational comparison operators (`== != < > <= >=`) on vector types. A new operation was created rather than reusing `cir.cmp` because the result is a vector of a signed intergral type, not a `bool`. Add CodeGen and Lowering tests for vector comparisons. Fix the floating-point comparison predicate when lowering to LLVM. To handle NaN values correctly, the comparisons need to be ordered rather than unordered. (Except for `!=`, which needs to be unordered.) For example, "ueq" was changed to "oeq".
Extended Description
The 177.mesa test fails on Sparc (seraph). The numerical output does not match
that generated by the native version of 177.mesa.
The text was updated successfully, but these errors were encountered: