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. :-( > > -Sandra -- H.J.
