public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Carl Love <cel@us.ibm.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Will Schmidt <will_schmidt@vnet.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Subject: Re: [PATCH] Add IEEE FLOAT128 support to test gdb.base/whatis-ptype-typedefs.exp
Date: Mon, 18 Jul 2022 16:22:58 +0100	[thread overview]
Message-ID: <8ae117dd-17c2-382d-637a-64a3be7b185b@palves.net> (raw)
In-Reply-To: <3fe4fcaf067f3bc3d4124df3ed6ba009a174f933.camel@us.ibm.com>

On 2022-07-13 8:38 p.m., Carl Love via Gdb-patches wrote:

> GCC enabled IEEE FLOAT 128-bit support starting with GCC 12 by default.
> Previously long double was the default for 128-bit floating point support.
> This patch updates the expected result for the "long doube" tests to
> _Float128 if GCC 12 is used.  The previous "long double" result is
> expected for GCC 11 and older versions.

This whole paragraph reads as if all archs were changed, but it was just Power, right?

And isn't it the case that after the change, for GCC, "long double" _IS_ IEEE FLOAT 128-bit?

Doesn't that mean that GCC and GDB now have a mismatch of what they think "long double" is?
Like for example, if the user copies an expression from their program and evaluates in gdb,
and that expression uses "long double", then GDB will evaluate it differently from how GCC would?

Shouldn't GDB instead adjust its "long double" type depending on the ABI, mapping "long double"
to the right format?  And then, the testcase (probably) wouldn't change?

BTW, I was expecting to see GCC's default change mentioned at:

  https://gcc.gnu.org/gcc-12/changes.html

but I can't seem to find it there, other than a Fortran reference which seems related.  I did find:

  https://gcc.gnu.org/wiki/Ieee128PowerPC#Transition

> 
> The patch has been run on Power 7 (gcc version 4.8.5), Power 10 (gcc
> version 12.1) and Intel x86_64 (gcc version 11.2.0) to verify the patch
> fixes the 74 test failures on Power 10 with GCC 12 and does not introduce
> any regression failures on older versions of GCC.

Seems like x86 with gcc 12 would better be tested as well.

> ---
>  .../gdb.base/whatis-ptype-typedefs.exp        | 26 ++++++++++++++-----
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp b/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp
> index be76183ca79..a17084a19ec 100644
> --- a/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp
> +++ b/gdb/testsuite/gdb.base/whatis-ptype-typedefs.exp
> @@ -77,6 +77,12 @@ proc prepare {lang} {
>  #
>  # This can be "c" or "c++".
>  #
> +
> +# GCC 12 uses IEEE 128-bit floating point as the default starting with GCC 12.

On all archs?

> +# The table below consists of the compiler independent tests.  The GCC version
> +# specific tests are appended to the end of the table based on the compiler
> +# version.
> +
>  # Columns in the table represent:
>       # EXP                # whatis           # ptype           # language
>  set table {
> @@ -97,12 +103,6 @@ set table {
>      {"double_typedef2"    "double_typedef"   "double"}
>      {"v_double_typedef"   "double_typedef"   "double"}
>      {"v_double_typedef2"  "double_typedef2"  "double"}
> -
> -    {"long_double_typedef"    "long double"           "long double"}
> -    {"long_double_typedef2"   "long_double_typedef"   "long double"}
> -    {"v_long_double_typedef"  "long_double_typedef"   "long double"}
> -    {"v_long_double_typedef2" "long_double_typedef2"  "long double"}
> -
>      {"colors_typedef"     "(enum )?colors"   "enum colors( : unsigned int)? {red, green, blue}"}
>      {"colors_typedef2"    "colors_typedef"   "enum colors( : unsigned int)? {red, green, blue}"}
>      {"v_colors_typedef"   "colors_typedef"   "enum colors( : unsigned int)? {red, green, blue}"}
> @@ -151,6 +151,20 @@ set table {
>  	"c++"}
>  }
>  
> +# Add the long double tests on the version of GCC
> +if { [test_compiler_info gcc-*] && [gcc_major_version] >= 12 } {

What about x86 + gcc 12 ?

> +    lappend table {"long_double_typedef"    "long double"           "_Float128"}
> +    lappend table {"long_double_typedef2"   "long_double_typedef"   "_Float128"}
> +    lappend table {"v_long_double_typedef"  "long_double_typedef"   "_Float128"}
> +    lappend table {"v_long_double_typedef2" "long_double_typedef2"  "_Float128"}
> +
> +} else {
> +    lappend table {"long_double_typedef"    "long double"           "long double"}
> +    lappend table {"long_double_typedef2"   "long_double_typedef"   "long double"}
> +    lappend table {"v_long_double_typedef"  "long_double_typedef"   "long double"}
> +    lappend table {"v_long_double_typedef2" "long_double_typedef2"  "long double"}
> +}



  parent reply	other threads:[~2022-07-18 15:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13 19:38 Carl Love
2022-07-15 11:42 ` Ulrich Weigand
2022-07-18 15:22 ` Pedro Alves [this message]
2022-07-18 15:40   ` Carl Love
2022-07-18 15:55     ` Carl Love

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=8ae117dd-17c2-382d-637a-64a3be7b185b@palves.net \
    --to=pedro@palves.net \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=will_schmidt@vnet.ibm.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).