On Mon, Sep 6, 2021 at 7:21 AM Sandra Loosemore <san...@codesourcery.com> wrote:
> 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. > > I'm not really in a position to make a comment, but any patch aiming at skipping pr100914.f90 only will have no effect on the other errors I reported, which are related to __float128 vs _Float128. Christophe > -Sandra >
