Bug 24546

From the looks of it, some of these are really gdb issues as they work when you do:
set lang c

Yes. Some of these problems stems from gdb, like 24527; others from gfortran, like 22244, and yet others involve both. 

I could spare some time to work on fortran support in gdb.  And very willing to work with gfortran community to make progress on that.

There is a gfortran bug not listed here yet (I am too lazy to file a new bug).
Anyways the bug is that the type for arguments is wrong and gives you instead a reference (in the C++ sense) type instead of a normal type.  I think I might have a way to fix that.  If someone wants to file that bug and assign it to me, that would be nice.

Hi Andrew,

I opened PR 24790 to track this.  Wish that it is just what you thought of.  But I didn't figure out how to assign that to you.  So I add you the cc list.

Regards
- Wu Zhou

Just as a general note, the deadline for dwarf3 comments is Dec 1, 2005.  So if anyone with some clue about how to improve support for debugging fortran has some good suggestions that would require changes in the debug format, now is the time to send them.

I ever opened an issue to request to add something to identify the main function (such as Fortran MAIN__) in a program.  But that is deferred to DWARF 4.  So maybe now it is too late to add anything into DWARF 3.

Here is the link
http://dwarf.freestandards.org/ShowIssue.php?issue=050808.2&type=closed

Steven Bosscher had made significant progress on this, IIRC. Steven, what's the status of your patches?

PS: as a minor improvement, we might want to give numeric types a more Fortran-like name, with a patch such as the following:

Index: trans-types.c
===================================================================
--- trans-types.c       (revision 122038)
+++ trans-types.c       (working copy)
@@ -531,7 +531,7 @@
     {
       type = gfc_build_int_type (&gfc_integer_kinds[index]);
       gfc_integer_types[index] = type;
-      snprintf (name_buf, sizeof(name_buf), "int%d",
+      snprintf (name_buf, sizeof(name_buf), "integer(kind=%d)",
                gfc_integer_kinds[index].kind);
       PUSH_TYPE (name_buf, type);
     }
@@ -540,7 +540,7 @@
     {
       type = gfc_build_logical_type (&gfc_logical_kinds[index]);
       gfc_logical_types[index] = type;
-      snprintf (name_buf, sizeof(name_buf), "logical%d",
+      snprintf (name_buf, sizeof(name_buf), "logical(kind=%d)",
                gfc_logical_kinds[index].kind);
       PUSH_TYPE (name_buf, type);
     }
@@ -549,13 +549,13 @@
     {
       type = gfc_build_real_type (&gfc_real_kinds[index]);
       gfc_real_types[index] = type;
-      snprintf (name_buf, sizeof(name_buf), "real%d",
+      snprintf (name_buf, sizeof(name_buf), "real(kind=%d)",
                gfc_real_kinds[index].kind);
       PUSH_TYPE (name_buf, type);
 
       type = gfc_build_complex_type (type);
       gfc_complex_types[index] = type;
-      snprintf (name_buf, sizeof(name_buf), "complex%d",
+      snprintf (name_buf, sizeof(name_buf), "complex(kind=%d)",
                gfc_real_kinds[index].kind);
       PUSH_TYPE (name_buf, type);
     }

(In reply to comment #7)

> PS: as a minor improvement, we might want to give numeric types a more
> Fortran-like name, with a patch such as the following:

...

Hi FX,

are you planning to submit that patch?  It sounds like a good idea.

> Hi FX,
>
> are you planning to submit that patch?  It sounds like a good idea.

This patch seems to have been committed at least since 4.7.