On 9/5/21 7:29 PM, H.J. Lu wrote:
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore
<san...@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 <san...@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

Reply via email to