aboutsummaryrefslogtreecommitdiff
path: root/libgfortran/libgfortran.h
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2022-06-29 17:04:50 +0200
committerJakub Jelinek <jakub@redhat.com>2022-06-29 17:04:50 +0200
commitc022c0de2a6c9110350cd50275be97d061a19530 (patch)
tree8d3d09a2201cf1bfb6e57d08ce2219eab240d281 /libgfortran/libgfortran.h
parentaa87b7541b4c11f59c521154513f844ea6b5c977 (diff)
downloadgcc-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