This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug testsuite/51057] FAIL: gfortran.dg/quad_2.f90 -O0 execution test on powerpc*-*-*


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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-12-03 20:46:36 UTC ---
On Sat, Dec 03, 2011 at 08:36:43PM +0000, iains at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51057
> 
> --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-03 20:36:43 UTC ---
> whilst I appreciate that there are wider issues with IBM long double (and its
> availability) 
> [I read the two PRs you cross-referenced].
> 
> In this case, it appears to be a different situation.
> - what Dominique is indicating is that the tests are likely failing on an IBM
> long double target because the number of mantissa bits is 106 rather than the
> 112 for float128.

113 bits for IEEE binary 128 format.


> So I wonder what opportunities exist for adjusting the test expectation
> depending on the target.
> (since this, presumably, will affect all IBM long double targets).
> 
> from 'c' we have some #defines that would allow us to detect the IBM case on
> ppc  (although, presumably because it's provided by a library, we don't get the
> same for x86).  It would even be a reasonable first approximation to assume IBM
> long double on ppc and float128 on x86.

This test came into being when libquadmath came into the tree.
The correct, and only, solution for targets whose long double
representation is double-double math is to XFAIL the test on those
targets.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]