This is the mail archive of the gcc-patches@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]

Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90


On Mon, Dec 24, 2018 at 9:42 PM Steve Kargl <
sgk@troutmask.apl.washington.edu> wrote:

> On Mon, Dec 24, 2018 at 09:29:50PM +0200, Janne Blomqvist wrote:
> > On Mon, Dec 24, 2018 at 8:05 PM Steve Kargl <
> > sgk@troutmask.apl.washington.edu> wrote:
> >
> > > I've added the following patch to a recently committed testcase.
> > >
> > > Index: gcc/testsuite/gfortran.dg/ieee/ieee_9.f90
> > > ===================================================================
> > > --- gcc/testsuite/gfortran.dg/ieee/ieee_9.f90   (revision 267413)
> > > +++ gcc/testsuite/gfortran.dg/ieee/ieee_9.f90   (working copy)
> > > @@ -1,4 +1,4 @@
> > > -! { dg-do run }
> > > +! { dg-do run { xfail arm*-*-gnueabi arm*-*-gnueabihf } }
> > >  program foo
> > >     use ieee_arithmetic
> > >     use iso_fortran_env
> > >
> >
> > The problem seems to be that GFortran says the real128 kind value is > 0
> > (i.e. that the target supports quad precision floating point (with
> software
> > emulation, presumably)), but then trying to use it fails.
> >
> > Would be nice if somebody who cares about arm-none-linux-gnueabihf could
> > help figure out the proper resolution instead of papering over it with
> > XFAIL.
> >
> > But I guess XFAIL is good enough until said somebody turns up.
> >
>
> Thanks for chasing down the details.  I have no access to arm*-*-*.
>
> It's a shame the real128 is defined, and arm*-*-* doesn't
> actually use it.  I certainly have no time or interest in
> fix this.
>

I think there are arm systems on the compile farm, but I haven't actually
checked myself, just going by the error messages Sudi Das reported.

That being said, having slept over it, I actually think there is a problem
with the testcase, and not with arm*. So the errors in the testcase occurs
in code like

if (real128 > 0) then
    p = int(ieee_scalb(real(x, real128), int(i, int8)))
    if (p /= 64) stop 3
end if

So if real128 is negative, as it should be if the target doesn't support
quad precision float, the branch will never be taken, but the frontend will
still generate code for it (though it will later be optimized away as
unreachable), and that's where the error occurs. So the testcase would need
something like

integer, parameter :: large_real = max (real64, real128)
! ...
if (real128 > 0) then
    p = int(ieee_scalb(real(x, large_real), int(i, int8)))
    if (p /= 64) stop 3
end if

If you concur, please consider a patch fixing the testcase and removing the
xfail pre-approved.

-- 
Janne Blomqvist


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