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: s...@troutmask.apl.washington.edu; Janne Blomqvist
Cc: Fortran List; GCC Patches; nd; kyrylo.tkac...@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 <
>> s...@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 <
>>>> s...@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
