From: Nils-Christian Kempke <nils-christian.kempke@intel.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 07/11] gdb/fortran: Change GDB print for fortran default types
Date: Wed, 9 Mar 2022 11:39:18 +0100 [thread overview]
Message-ID: <20220309103922.3257803-8-nils-christian.kempke@intel.com> (raw)
In-Reply-To: <20220309103922.3257803-1-nils-christian.kempke@intel.com>
Currently, when asking GDB to print the type of a Fortran default type
such as INTEGER or REAL, GDB will return the deafult name of that type,
e.g. "integer"/"real":
(gdb) ptype integer
type = integer
(gdb) ptype real
type = real
For LOGICAL and COMPLEX it would return the actual underlying types
(gdb) ptype logical
type = logical*4
(gdb) ptype complex
type = complex*4
Similarly, GDB would print the default integer type for the underlying
default type:
(gdb) ptype integer*4
type = integer
(gdb) ptype real*4
type = real
(gdb) ptype logical
type = logical*4
(gdb) ptype complex*4
type = complex*4
This is inconsistent and a bit confusing. Both options somehow indicate
what the internal underlying type for the default type is - but I think
the logical/complex version is a bit clearer.
Consider again:
(gdb) ptype integer
type = integer
This indicates to a user that the type of "integer" is Fortran's default
integer type. Without examining "ptype integer*4" I would expect, that
any variable declared integer in the actual code would also fit into a
GDB integer. But, since we cannot adapt out internal types to the
compiler flags used at compiler time of a debugged binary, this might be
wrong. Consider debugging Fortran code compiled with GNU and e.g. the
"-fdefault-integer-8" flag. In this case the gfortran default integer
would be integer*8 while GDB internally still would use a builtin_integer,
so an integer of the size of an integer*4 type. On the other hand having
GDB print
(gdb) ptype integer
type = integer*4
makes this clearer. I would still be tempted to fit a variable declared
integer in the code into a GDB integer - but at least ptype would
directly tell me what is going on. Note, that when debugging a binary
compiled with "-fdefault-integer-8" a user will always see the actual
underlying type of any variable declared "integer" in the Fortran code.
So having the code
program test
integer :: a = 5
print *, a ! breakpt
end program test
will, when breaking at breakpt print
(gdb) ptype var
type = integer(kind=4)
or
(gdb) ptype var
type = integer(kind=8)
depending on the compiler flag.
This patch changes the outputs for the REAL and INTEGER default types to
actually print the internally used type over the default type name.
The new behavior for the above examples is:
(gdb) ptype integer
type = integer*4
(gdb) ptype integer*4
type = integer*4
Existing testcases have been adapted to reflect the new behavior.
gdb/ChangeLog:
2022-03-02 Nils-Christian Kempke <nils-christian.kempke@intel.com>
* f-lang.c (build_fortran_types): Change output for default
types.
gdb/testsuite/ChangeLog:
2022-03-02 Nils-Christian Kempke <nils-christian.kempke@intel.com>
* gdb.fortran/complex.exp: Change expected output for default
types.
* gdb.fortran/types.exp: Change test for default types.
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
gdb/f-lang.c | 4 ++--
gdb/testsuite/gdb.fortran/complex.exp | 4 ++--
gdb/testsuite/gdb.fortran/types.exp | 19 +++++++------------
3 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/gdb/f-lang.c b/gdb/f-lang.c
index 5a97beada2..bea24ce0ca 100644
--- a/gdb/f-lang.c
+++ b/gdb/f-lang.c
@@ -1636,7 +1636,7 @@ build_fortran_types (struct gdbarch *gdbarch)
= arch_integer_type (gdbarch, gdbarch_short_bit (gdbarch), 0, "integer*2");
builtin_f_type->builtin_integer
- = arch_integer_type (gdbarch, gdbarch_int_bit (gdbarch), 0, "integer");
+ = arch_integer_type (gdbarch, gdbarch_int_bit (gdbarch), 0, "integer*4");
builtin_f_type->builtin_integer_s8
= arch_integer_type (gdbarch, gdbarch_long_long_bit (gdbarch), 0,
@@ -1644,7 +1644,7 @@ build_fortran_types (struct gdbarch *gdbarch)
builtin_f_type->builtin_real
= arch_float_type (gdbarch, gdbarch_float_bit (gdbarch),
- "real", gdbarch_float_format (gdbarch));
+ "real*4", gdbarch_float_format (gdbarch));
builtin_f_type->builtin_real_s8
= arch_float_type (gdbarch, gdbarch_double_bit (gdbarch),
diff --git a/gdb/testsuite/gdb.fortran/complex.exp b/gdb/testsuite/gdb.fortran/complex.exp
index 60f7c8e255..f4a80fbf78 100644
--- a/gdb/testsuite/gdb.fortran/complex.exp
+++ b/gdb/testsuite/gdb.fortran/complex.exp
@@ -45,13 +45,13 @@ gdb_test "print c16" " = \\(-874,19\\)"
gdb_test "whatis c" "type = $complex4"
gdb_test "print \$_creal (c)" " = 1000"
with_test_prefix "c" {
- gdb_test "whatis \$" " = real"
+ gdb_test "whatis \$" " = real\\*4"
}
gdb_test "whatis c4" "type = $complex4"
gdb_test "print \$_creal (c4)" " = 1000"
with_test_prefix "c4" {
- gdb_test "whatis \$" " = real"
+ gdb_test "whatis \$" " = real\\*4"
}
gdb_test "whatis c8" "type = $complex8"
gdb_test "print \$_creal (c8)" " = 321"
diff --git a/gdb/testsuite/gdb.fortran/types.exp b/gdb/testsuite/gdb.fortran/types.exp
index 5ab44b10a3..594276f3a7 100644
--- a/gdb/testsuite/gdb.fortran/types.exp
+++ b/gdb/testsuite/gdb.fortran/types.exp
@@ -73,26 +73,21 @@ proc test_float_literal_types_accepted {} {
# Test the default primitive Fortran types.
proc test_default_types {} {
- gdb_test "ptype integer*4" "type = integer"
- gdb_test "ptype integer_4" "type = integer"
-
- gdb_test "ptype logical" "type = logical*4"
-
- gdb_test "ptype real*4" "type = real"
- gdb_test "ptype real_4" "type = real"
-
- gdb_test "ptype complex" "type = complex*4"
+ gdb_test "ptype integer" "type = integer\\*4"
+ gdb_test "ptype logical" "type = logical\\*4"
+ gdb_test "ptype real" "type = real\\*4"
+ gdb_test "ptype complex" "type = complex\\*4"
}
# Test the the primitive Fortran types, those that GDB should always
# know, even if the program does not define them, are in fact, known.
proc test_primitive_types_known {} {
foreach type {void character \
- integer*1 integer*2 integer integer*8 \
- integer_1 integer_2 integer_8 \
+ integer*1 integer*2 integer*4 integer*8 \
+ integer_1 integer_2 integer_4 integer_8 \
logical*1 logical*2 logical*4 logical*8 \
logical_1 logical_2 logical_4 logical_8 \
- real real*8 real*16 real_8 real_16 \
+ real*4 real*8 real*16 real_4 real_8 real_16 \
complex*4 complex*8 complex*16 \
complex_4 complex_8 complex_16} {
--
2.25.1
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2022-03-09 10:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 10:39 [PATCH 00/11] Improve Fortran intrinsic types and procedures Nils-Christian Kempke
2022-03-09 10:39 ` [PATCH 01/11] gdb/f-lang: add Integer*1 to Fortran builtin types Nils-Christian Kempke
2022-04-07 14:28 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 02/11] gdb/f-lang: remove hidden ^L characters Nils-Christian Kempke
2022-04-07 14:28 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 03/11] gdb/fortran: fix complex type in Fortran builtin types Nils-Christian Kempke
2022-04-07 14:30 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 04/11] gdb/fortran: reformat build_fortran_types in f-lang.c Nils-Christian Kempke
2022-04-07 14:30 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 05/11] gdb/fortran: change default logical type to builtin_logical Nils-Christian Kempke
2022-04-07 14:32 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 06/11] gdb/fortran: clean-up Fortran intrinsic types Nils-Christian Kempke
2022-04-07 14:33 ` Tom Tromey
2022-03-09 10:39 ` Nils-Christian Kempke [this message]
2022-04-07 14:37 ` [PATCH 07/11] gdb/fortran: Change GDB print for fortran default types Tom Tromey
2022-03-09 10:39 ` [PATCH 08/11] gdb/fortran: rename f77_keywords to f_keywords Nils-Christian Kempke
2022-04-07 14:37 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 09/11] gdb/fortran: rewrite intrinsic handling and add some missing overloads Nils-Christian Kempke
2022-04-07 14:49 ` Tom Tromey
2022-04-08 12:49 ` Kempke, Nils-Christian
2022-04-13 5:14 ` Tom de Vries
2022-04-20 16:10 ` Kempke, Nils-Christian
2022-03-09 10:39 ` [PATCH 10/11] gdb/fortran/testsuite: add complex from integers test Nils-Christian Kempke
2022-04-07 14:49 ` Tom Tromey
2022-04-07 14:50 ` Tom Tromey
2022-03-09 10:39 ` [PATCH 11/11] gdb/doc: add section about fortran intrinsic functions and types Nils-Christian Kempke
2022-03-09 12:49 ` Eli Zaretskii
2022-03-09 17:01 ` Kempke, Nils-Christian
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=20220309103922.3257803-8-nils-christian.kempke@intel.com \
--to=nils-christian.kempke@intel.com \
--cc=gdb-patches@sourceware.org \
/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).