Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h
On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote: > > The testcase gfortran.dg/PR100914.f90 that I recently checked in > (originally written by José Rui Faustino de Sousa) depends on the > 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 , I prefer either of 2 patches enclosed here. -- H.J. p1.diff Description: Binary data p2.diff Description: Binary data
Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h
On 9/5/21 7:31 AM, H.J. Lu wrote: On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote: The testcase gfortran.dg/PR100914.f90 that I recently checked in (originally written by José Rui Faustino de Sousa) depends on the 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 , 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. 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
Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h
On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore wrote: > > On 9/5/21 7:31 AM, H.J. Lu wrote: > > On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore > > wrote: > >> > >> The testcase gfortran.dg/PR100914.f90 that I recently checked in > >> (originally written by José Rui Faustino de Sousa) depends on the > >> 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 , 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 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.
Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h
On 9/5/21 7:29 PM, H.J. Lu wrote: On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore wrote: On 9/5/21 7:31 AM, H.J. Lu wrote: On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote: The testcase gfortran.dg/PR100914.f90 that I recently checked in (originally written by José Rui Faustino de Sousa) depends on the 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 , 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 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
