* [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 @ 2018-12-24 19:09 Steve Kargl 2018-12-24 19:42 ` Janne Blomqvist 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2018-12-24 19:09 UTC (permalink / raw) To: fortran, gcc-patches 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 -- Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-24 19:09 [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 Steve Kargl @ 2018-12-24 19:42 ` Janne Blomqvist 2018-12-24 19:59 ` Steve Kargl 0 siblings, 1 reply; 7+ messages in thread From: Janne Blomqvist @ 2018-12-24 19:42 UTC (permalink / raw) To: Steve Kargl; +Cc: Fortran List, GCC Patches, Sudi.Das 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 > > -- > Steve > 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. -- Janne Blomqvist ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-24 19:42 ` Janne Blomqvist @ 2018-12-24 19:59 ` Steve Kargl 2018-12-25 13:04 ` Janne Blomqvist 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2018-12-24 19:59 UTC (permalink / raw) To: Janne Blomqvist; +Cc: Fortran List, GCC Patches, Sudi.Das 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. -- Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-24 19:59 ` Steve Kargl @ 2018-12-25 13:04 ` Janne Blomqvist 2018-12-25 21:44 ` Steve Kargl 0 siblings, 1 reply; 7+ messages in thread From: Janne Blomqvist @ 2018-12-25 13:04 UTC (permalink / raw) To: Steve Kargl; +Cc: Fortran List, GCC Patches, Sudi.Das 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-25 13:04 ` Janne Blomqvist @ 2018-12-25 21:44 ` Steve Kargl 2018-12-27 11:24 ` Sudakshina Das 0 siblings, 1 reply; 7+ messages in thread From: Steve Kargl @ 2018-12-25 21:44 UTC (permalink / raw) To: Janne Blomqvist; +Cc: Fortran List, GCC Patches, Sudi.Das On Tue, Dec 25, 2018 at 09:51:03AM +0200, Janne Blomqvist wrote: > 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. > Indeed, you are probably correct that gfortran will generate intermediate code and then garbage collect it. This then will give an error for real(..., real128) in the statement for p. If real128 /= 4, 8, 10, or 16. I'll fix the testcase. Do you know if we can get gfortran to pre-define macros for cpp? That is, it would be nice if gfortran would recognize, say, HAVE_GFC_REAL_10 and HAVE_GFC_REAL_16 if the target supports those types. Then the testcase could be copied to ieee_9.F90, and modified to #ifdef HAVE_REAL_16 p = int(ieee_scalb(real(x, 16), int(i, int8))) if (p /= 64) stop 3 #endif -- Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-25 21:44 ` Steve Kargl @ 2018-12-27 11:24 ` Sudakshina Das 2018-12-27 11:54 ` Ramana Radhakrishnan 0 siblings, 1 reply; 7+ messages in thread From: Sudakshina Das @ 2018-12-27 11:24 UTC (permalink / raw) To: sgk, Janne Blomqvist Cc: Fortran List, GCC Patches, nd, kyrylo.tkachov, Ramana Radhakrishnan, Richard Earnshaw Hi On 25/12/18 5:13 PM, Steve Kargl wrote: > On Tue, Dec 25, 2018 at 09:51:03AM +0200, Janne Blomqvist wrote: >> 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. >> > Indeed, you are probably correct that gfortran will generate > intermediate code and then garbage collect it. This then will > give an error for real(..., real128) in the statement for p. > If real128 /= 4, 8, 10, or 16. I'll fix the testcase. > > Do you know if we can get gfortran to pre-define macros for cpp? > That is, it would be nice if gfortran would recognize, say, > HAVE_GFC_REAL_10 and HAVE_GFC_REAL_16 if the target supports those > types. Then the testcase could be copied to ieee_9.F90, and > modified to > > #ifdef HAVE_REAL_16 > p = int(ieee_scalb(real(x, 16), int(i, int8))) > if (p /= 64) stop 3 > #endif > Thanks for looking into this. Sorry I was on holiday for Christmas. CC'ing Arm maintainers in case they have something to add. Thanks Sudi ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 2018-12-27 11:24 ` Sudakshina Das @ 2018-12-27 11:54 ` Ramana Radhakrishnan 0 siblings, 0 replies; 7+ messages in thread From: Ramana Radhakrishnan @ 2018-12-27 11:54 UTC (permalink / raw) To: sgk, Janne Blomqvist, Sudakshina Das Cc: Fortran List, GCC Patches, nd, kyrylo.tkachov, Richard Earnshaw Still on holiday, but this maybe because long double is 64bit on arm32. Real128 may end up being mapped to long double for fortran on armhf ? Ramana ________________________________ From: Sudakshina Das Sent: Thursday, December 27, 2018 8:46:29 AM To: sgk@troutmask.apl.washington.edu; Janne Blomqvist Cc: Fortran List; GCC Patches; nd; kyrylo.tkachov@foss.arm.com; Ramana Radhakrishnan; Richard Earnshaw Subject: Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 Hi On 25/12/18 5:13 PM, Steve Kargl wrote: > On Tue, Dec 25, 2018 at 09:51:03AM +0200, Janne Blomqvist wrote: >> 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. >> > Indeed, you are probably correct that gfortran will generate > intermediate code and then garbage collect it. This then will > give an error for real(..., real128) in the statement for p. > If real128 /= 4, 8, 10, or 16. I'll fix the testcase. > > Do you know if we can get gfortran to pre-define macros for cpp? > That is, it would be nice if gfortran would recognize, say, > HAVE_GFC_REAL_10 and HAVE_GFC_REAL_16 if the target supports those > types. Then the testcase could be copied to ieee_9.F90, and > modified to > > #ifdef HAVE_REAL_16 > p = int(ieee_scalb(real(x, 16), int(i, int8))) > if (p /= 64) stop 3 > #endif > Thanks for looking into this. Sorry I was on holiday for Christmas. CC'ing Arm maintainers in case they have something to add. Thanks Sudi ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-12-27 8:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-12-24 19:09 [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90 Steve Kargl 2018-12-24 19:42 ` Janne Blomqvist 2018-12-24 19:59 ` Steve Kargl 2018-12-25 13:04 ` Janne Blomqvist 2018-12-25 21:44 ` Steve Kargl 2018-12-27 11:24 ` Sudakshina Das 2018-12-27 11:54 ` Ramana Radhakrishnan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).