Hello,
I'm seeing a number of failures in Fortran test cases on the SPU,
but none of those actually seems to point to a real bug in the
compiler. The following patch cleans up the test suite to avoid
those failures:
- The bessel_6.f90 and bessel_7.f90 tests fail because the SPU
library implementation is simply not accurate. That's a bug,
but not one the compiler can do anything about, so I'd suggest
to XFAIL those tests.
- Similarly, the erf_2.F90 test fails at -O0 because the library
implementation is not accurate. However, it passes at all other
optimization levels, because there the test is simply opimized
away completely. I'd suggest to XFAIL on SPU, and at the same
time always run the test at -O0 to avoid spurious XPASSes.
- With complex_intrinsics_5.f90 and sum_init_expr.f03, at some but
not all optimization levels, I'm seeing test failures due to the
result being just slightly outside the expected "epsilon", probably
because of different rounding modes on SPU. I'd suggest to just
increase the test's tolerance levels slightly.
- The realloc_on_assign_2.f03 test is not suitable on the SPU because
it just tries to allocate too much memory. I'd suggest to just skip
the test on the SPU.
- The lto/20091016-1_0.f90 test links with -shared, which just does
not work on platforms that do no support shared libraries. Similar
tests in the C and C++ LTO test suites have been changed to use
-r -nostdlib instead of -shared:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01547.html
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00183.html
I'd suggest to do the same with this Fortran LTO test.
- The vect/fast-math-vect-8.f90 test fails a check for a vectorized
loop because the compiler doesn't support a int->float vector op.
This should be handled via a vect_intfloat_cvt target support
check, as is done in other situations.
Tested on spu-elf.
OK for mainline?