diff options
author | Jakub Jelinek <jakub@redhat.com> | 2022-06-29 17:04:50 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2022-06-29 17:04:50 +0200 |
commit | c022c0de2a6c9110350cd50275be97d061a19530 (patch) | |
tree | 8d3d09a2201cf1bfb6e57d08ce2219eab240d281 /libgfortran/libgfortran.h | |
parent | aa87b7541b4c11f59c521154513f844ea6b5c977 (diff) | |
download | gcc-c022c0de2a6c9110350cd50275be97d061a19530.zip gcc-c022c0de2a6c9110350cd50275be97d061a19530.tar.gz gcc-c022c0de2a6c9110350cd50275be97d061a19530.tar.bz2 |
libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported and long double isn't IEEE quad precision.
Which is targets that support __float128 type which we have been testing
for before - _Float128 is supported on those targets and on targets where
long double is IEEE quad precision.
So, the following patch restores check for whether __float128 is supported
into the LIBGFOR_CHECK_FLOAT128 check which determines whether
HAVE_FLOAT128 is defined or whether to use libquadmath, so that e.g. on
aarch64 where long double is IEEE quad we don't do that.
2022-06-29 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/106137
* acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Adjust comment.
Also test for __float128.
(HAVE_FLOAT128): Adjust description.
* config.h.in: Regenerated.
* configure: Regenerated.
Diffstat (limited to 'libgfortran/libgfortran.h')
0 files changed, 0 insertions, 0 deletions