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.
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
