Hi Sandra, hi all,
On 06.09.21 07:20, Sandra Loosemore 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.
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.
Can't we just use the following in the testcase?
typedef _Complex _Float128 __complex128;
That avoids the including quadmath.h – and my impression is
that the only reason for including quadmath.h is this single
function. Or does this run into issues with the proper mode?
At least when I tried it, it did compile on x86-64. On the
other hand, there is the following remark in the header file:
/* Define the complex type corresponding to __float128
("_Complex __float128" is not allowed) */
#if (!defined(_ARCH_PPC)) || defined(__LONG_DOUBLE_IEEE128__)
typedef _Complex float __attribute__((mode(TC))) __complex128;
#else
typedef _Complex float __attribute__((mode(KC))) __complex128;
#endif
The '#else' was added with
https://gcc.gnu.org/g:0c949f0a1ce9cfa8c48e62628493140d60e65ea7
for https://gcc.gnu.org/PR81848
The comment about _Complex __float128 was in the original patch.
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.
Which means that it is pointless to provide libquadmath on this target
as as the libc's long double math functions are sufficient. – Or not, I
recall that that on PowerPC libquadmath has a effective higher precision
than libc's long double. But in terms of checking type =
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.
Whorks for me – I assume that includes updating the documentation. As on
many systems __float128 and _Float128 is available, I don't think it has
to be mentioned in the release notes (but it can).
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
