From: Tobias Burnus <tobias@codesourcery.com>
To: Jakub Jelinek <jakub@redhat.com>, <fortran@gcc.gnu.org>,
<gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libgfortran: Fix up LIBGFOR_CHECK_FLOAT128 [PR106137]
Date: Wed, 29 Jun 2022 16:42:45 +0200 [thread overview]
Message-ID: <6f4ceb9a-ba6b-d514-7623-7ce95cfba8e2@codesourcery.com> (raw)
In-Reply-To: <YrxBzaWQC/1cHvUA@tucnak>
On 29.06.22 14:13, Jakub Jelinek via Fortran wrote:
> 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.
>
> Tested by Tamar on aarch64 and by me on x86_64-linux, ok for trunk?
> 2022-06-29 Jakub Jelinek <jakub@redhat.com>
>
> PR bootstrap/106137
> * acinclude.m4 (LIBGFOR_CHECK_FLOAT128): Also test for __float128.
> * configure: Regenerated.
>
> --- libgfortran/acinclude.m4.jj 2022-06-28 13:14:45.327799267 +0200
> +++ libgfortran/acinclude.m4 2022-06-29 11:45:19.286551469 +0200
> @@ -276,7 +276,6 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
> GCC_TRY_COMPILE_OR_LINK([
> _Float128 foo (_Float128 x)
...
> + __float128 baz (__float128 x)
As now both __float128 and _Float128 is tested, can you also update:
dnl Check whether we have a __float128 type
AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
...
AC_CACHE_CHECK([whether we have a usable _Float128 type],
libgfor_cv_have_float128, [
I note that your follow-up patch adds _Float128 to the dnl comment,
but I think __float128 should also be added to the cache output to
make clear that both _Float128/__float128 are checked.
Otherwise: LGTM.
Thanks,
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
prev parent reply other threads:[~2022-06-29 14:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 12:13 Jakub Jelinek
2022-06-29 14:42 ` Tobias Burnus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6f4ceb9a-ba6b-d514-7623-7ce95cfba8e2@codesourcery.com \
--to=tobias@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).