diff mbox series

dec_math.f90 needs to be xfailed

Message ID 20210102083439.GA8512@troutmask.apl.washington.edu
State New
Headers show
Series dec_math.f90 needs to be xfailed | expand

Commit Message

Steve Kargl Jan. 2, 2021, 8:34 a.m. UTC
Can someone, anyone, please commit the following trivially patch?
gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.

Comments

Jeff Law Jan. 4, 2021, 9:30 p.m. UTC | #1
On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
> Can someone, anyone, please commit the following trivially patch?
> gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
Why will the test never pass on that platform?  I don't mind installing
the patch, but I'd like to have a bit more background first :-)


Jeff
Steve Kargl Jan. 4, 2021, 10:28 p.m. UTC | #2
On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
> 
> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
> > Can someone, anyone, please commit the following trivially patch?
> > gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
> Why will the test never pass on that platform?  I don't mind installing
> the patch, but I'd like to have a bit more background first :-)
> 

The testcase assumes REAL(10) has 64-bits of precision.  On
i?86-*-freebsd, the i387 FPU control word is set to 53-bits.
The test program is not set up to deal with 11-bits of 
missing precision.

The current code uses the preprocessor to enable testing of
REAL(10) with something like

#ifdef __GFC_REAL_10__
   real(10) x
   print *, digits(x)
#endif

There are 44 instances of '#ifdef __GFC_REAL_10__'.  Each of those
would need to be modified to determine if __FreeBSD__ and __i386__
are defined, and gfortran would need to be modified to define
those macros!

IOW, xfailing the test is the easiest path forward for something
that will never pass.
Jeff Law Jan. 5, 2021, 6:26 p.m. UTC | #3
On 1/4/21 3:28 PM, Steve Kargl wrote:
> On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
>> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
>>> Can someone, anyone, please commit the following trivially patch?
>>> gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
>> Why will the test never pass on that platform?  I don't mind installing
>> the patch, but I'd like to have a bit more background first :-)
>>
> The testcase assumes REAL(10) has 64-bits of precision.  On
> i?86-*-freebsd, the i387 FPU control word is set to 53-bits.
> The test program is not set up to deal with 11-bits of 
> missing precision.
Thanks.  That's precisely what I needed to know.  I suspected it was
related to the differing state of the fpu control word.  But that begs
the question of whether or not the change should apply to the other BSD
variants.

jeff
Steve Kargl Jan. 5, 2021, 7:14 p.m. UTC | #4
On Tue, Jan 05, 2021 at 11:26:24AM -0700, Jeff Law wrote:
> 
> 
> On 1/4/21 3:28 PM, Steve Kargl wrote:
> > On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
> >> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
> >>> Can someone, anyone, please commit the following trivially patch?
> >>> gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
> >> Why will the test never pass on that platform?  I don't mind installing
> >> the patch, but I'd like to have a bit more background first :-)
> >>
> > The testcase assumes REAL(10) has 64-bits of precision.  On
> > i?86-*-freebsd, the i387 FPU control word is set to 53-bits.
> > The test program is not set up to deal with 11-bits of 
> > missing precision.
> Thanks.  That's precisely what I needed to know.  I suspected it was
> related to the differing state of the fpu control word.  But that begs
> the question of whether or not the change should apply to the other BSD
> variants.
> 

I don't know about other BSD variants.  The setting of the control
word was done some 27 years ago on i?86-FreeBSD.

Hmmm.  A little code spelunking back to original FreeBSD 2.0.5,

https://svnweb.freebsd.org/base/stable/2.0.5/sys/i386/include/npx.h?revision=4&view=markup

The lines 101-132 provide the justification for the control word.
AFIK, older FreeBSD sources are not published on FreeBSD.org due
to USL lawsuit.

If this file is current

http://mirror.nyi.net/NetBSD/misc/joerg/GENERIC/src/src/sys/arch/x86/include/cpu_extended_state.h.html

then NetBSD is not affected unless, you are using a older version.  See
lines 196-220.
Jeff Law Jan. 5, 2021, 10:26 p.m. UTC | #5
On 1/5/21 12:14 PM, Steve Kargl wrote:
> On Tue, Jan 05, 2021 at 11:26:24AM -0700, Jeff Law wrote:
>>
>> On 1/4/21 3:28 PM, Steve Kargl wrote:
>>> On Mon, Jan 04, 2021 at 02:30:43PM -0700, Jeff Law wrote:
>>>> On 1/2/21 1:34 AM, Steve Kargl via Gcc-patches wrote:
>>>>> Can someone, anyone, please commit the following trivially patch?
>>>>> gfortran.dg/dec_math.f90 will never pass on i?86-*-freebsd*.
>>>> Why will the test never pass on that platform?  I don't mind installing
>>>> the patch, but I'd like to have a bit more background first :-)
>>>>
>>> The testcase assumes REAL(10) has 64-bits of precision.  On
>>> i?86-*-freebsd, the i387 FPU control word is set to 53-bits.
>>> The test program is not set up to deal with 11-bits of 
>>> missing precision.
>> Thanks.  That's precisely what I needed to know.  I suspected it was
>> related to the differing state of the fpu control word.  But that begs
>> the question of whether or not the change should apply to the other BSD
>> variants.
>>
> I don't know about other BSD variants.  The setting of the control
> word was done some 27 years ago on i?86-FreeBSD.
Right, and I believe the other BSD variants are derived from the Net/2
and/or 386BSD where this originated.


>
> Hmmm.  A little code spelunking back to original FreeBSD 2.0.5,
>
> https://svnweb.freebsd.org/base/stable/2.0.5/sys/i386/include/npx.h?revision=4&view=markup
>
> The lines 101-132 provide the justification for the control word.
> AFIK, older FreeBSD sources are not published on FreeBSD.org due
> to USL lawsuit.
Right.  I could probably find stuff older than that, but it'd require
heading up to my old office at the U and grubbing around.  Unlikely
worth the effort.
>
> If this file is current
>
> http://mirror.nyi.net/NetBSD/misc/joerg/GENERIC/src/src/sys/arch/x86/include/cpu_extended_state.h.html
>
> then NetBSD is not affected unless, you are using a older version.  See
> lines 196-220.
ACK.   Probably the safe thing to do is keep it limited to FreeBSD.

Thanks for digging around.   I'll go ahead and install it as-is.

jeff
diff mbox series

Patch

diff --git a/gcc/testsuite/gfortran.dg/dec_math.f90 b/gcc/testsuite/gfortran.dg/dec_math.f90
index cc141aba412..d95233a5169 100644
--- a/gcc/testsuite/gfortran.dg/dec_math.f90
+++ b/gcc/testsuite/gfortran.dg/dec_math.f90
@@ -1,5 +1,5 @@ 
 ! { dg-options "-cpp -std=gnu" }
-! { dg-do run }
+! { dg-do run { xfail i?86-*-freebsd* } }
 !
 ! Test extra math intrinsics formerly offered by -fdec-math,
 ! now included with -std=gnu or -std=legacy.