[PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

[Sandra Loosemore]

On 9/5/21 7:29 PM, H.J. Lu wrote:
> On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
> <sandra@codesourcery.com> wrote:
>>
>> On 9/5/21 7:31 AM, H.J. Lu wrote:
>>> On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore <sandra@codesourcery.com> wrote:
>>>>
>>>> The testcase gfortran.dg/PR100914.f90 that I recently checked in
>>>> (originally written by José Rui Faustino de Sousa) depends on the
>>>> <quadmath.h> header file to obtain a typedef for __complex128.  It
>>>> appears not to be possible to define an equivalent type in a portable
>>>> way in the testcase itself (see
>>>> https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Floating-Types.html) so
>>>> this patch skips the test entirely on targets where quadmath.h is not
>>>> available.
>>>>
>>>> The target-supports.exp change was cut-and-pasted from similar code in
>>>> that file, but I haven't figured out how to test this change in a build
>>>> that doesn't provide quadmath.h (e.g., my aarch64-linux-gnu toolchain
>>>> build attempt croaked with an unrelated compilation error in glibc).
>>>> Perhaps someone who previously encountered the FAILs on this testcase
>>>> can confirm that it's skipped with this change?
>>>
>>> Since libqaudmath provides <quadmath.h>, I prefer either of 2 patches
>>> enclosed here.
>>
>> Of these two, the first one looks better to me, and seems to work OK in
>> my x86 build.  But, I'm not sure it is the right thing for ARM/Aarch64
>> targets, which apparently have _Float128 support without the __float128
>> type or libquadmath.  It's pretty clear quadmath.h depends on having
>> __float128.
> 
> The only <quadmath.h> used by GCC is the one in libquadmath.  I
> will check in my first patch tomorrow if there are no objections.
> 
>> See Christophe's mail here:
>>
>> https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html
>>
>> As I said in my last mail, I ran into some problems getting an aarch64
>> toolchain built so I haven't been able to do any testing or experiments
>> on that target myself yet.  :-(

I finally got an aarch64-linux-gnu toolchain built and confirmed that it 
is still broken there:  it indeed does not define __float128, and 
including quadmath.h results in a gazillion errors like

/path/to/quadmath.h:47:8: error: unknown type name '__float128'

I also observed that _Float128 is the same type as long double on this 
target.

Unless the aarch64 maintainers think it is a bug that __float128 is not 
supported, I think the right solution here is the one I was thinking of 
previously, to fix the Fortran front end to tie the C_FLOAT128 kind to 
_Float128 rather than __float128, and fix the runtime support and test 
cases accordingly.  Then there should be no need to depend on quadmath.h 
at all.  C_FLOAT128 is a GNU extension and _Float128 is supported on a 
superset of targets that __float128 is, so there should be no issue with 
backward compatibility.

-Sandra