[Bug fortran/33271] nint_2.f90 abort compiled with -O0

["fxcoudert at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #17 from fxcoudert at gcc dot gnu dot org  2007-09-07 12:06 -------
(In reply to comment #16)
> This way to fix the problem shakes the (little) confidence I have in the test
> suite!

You're, as always, welcome to improve it! (both by submitting code and general
ideas to make it better)

> Would not it be better to let the tests fail for the mentionned platforms until
> a (real) fix is found (as it is done for large_real_kind_2.F90 and
> large_real_kind_form_io_2.f90 on Darwin)?

I'm not sure I understand what you suggest. nint_2.f90 fails on ppc-aix and
ppc-linux because those targets have a system math library that contains a bug.
The code that gfortran create is OK, and the testcase would not fail if the AIX
and powerpc-glibc didn't have a buggy lround(). In fact, it is passing on all
other targets.

So, in that case, and contrarily to large_real_kind_2.F90, the bug here is not
in GCC, all we can do is really to wait for AIX and glibc to fix their
libraries. This is not going to happen soon (especially for AIX), and we
certainly have no control over it. This leaves two options: keep the testcase
failing on these two platforms, which means that people will probably report
the failure again, or at least investigate it. The nice thing in a testsuite is
that every single failure should be indicating a bug that we can act on: it's
not the case here. The other option is to XFAIL it on these two targets, which
means (a) we don't see the failure, (b) there is a record that this should, in
a perfect world, pass, but due to circumstances out of our control it is
expected to fail, and (c) when it starts passing (because glibc/AIX will have
been fixed), it will show up in test results as XPASS, and we can act (remove
the xfail).

If I understood you, you'd like option 1 above, am I right? Why do you think it
is better for the project?


PS: I should note that the bug in question is a relatively minor one: lround(),
on ppc-glibc and AIX, returns a wrong answer for the floating-point number
immediately lower than 0.5, Prec(0.5). All values are fine, except Prec(0.5),
-Prec(0.5), 4503599627370497 and -4503599627370497.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33271