[RFC]: Document patch for F90 derived type support

[RFC]: Document patch for F90 derived type support

[Wu Zhou]

Eli,

Here is the modified document patch for F90 derived type support.  Please 
review and comment.

I had tested it with "make info".  It displays ok.

2006-02-24  Wu Zhou  <woodzltc@cn.ibm.com>

	* gdb.texinfo (Fortran): Document the "%" operator for member
	access.  Document the type-print and value-print operation of
	Fortran 90 derived types.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.314
diff -c -p -r1.314 gdb.texinfo
*** gdb.texinfo	18 Feb 2006 20:45:01 -0000	1.314
--- gdb.texinfo	24 Feb 2006 07:16:56 -0000
*************** of the second one.
*** 9399,9404 ****
--- 9399,9408 ----
  @item :
  The range operator.  Normally used in the form of array(low:high) to
  represent a section of array.
+ 
+ @item %
+ Fortran 90 and later use this to access the members of derived
+ type, which is also introduced after the Fortran 90.
  @end table
  
  @node Fortran Defaults
*************** This command prints the values contained
*** 9427,9432 ****
--- 9431,9506 ----
  block whose name is @var{common-name}.  With no argument, the names of
  all @code{COMMON} blocks visible at current program location are
  printed.
+ 
+ @cindex structure type-print
+ @item ptype @var{derived-type}
+ Fortran 90 and later support derived type (a.k.a structure).  For a
+ variable of derived type, the @code{ptype} command will output all its
+ members, including nested derived type.
+ 
+ For example, for this derived type declaration:
+ 
+ @smallexample
+ type bar
+   integer :: c
+   real :: d
+ end type
+ 
+ type foo
+   real :: a
+   type(bar) :: x
+   character*7 :: b
+ end type foo
+ @end smallexample
+ 
+ @noindent
+ the @code{ptype} commands give this output:
+ 
+ @smallexample
+ @group
+ (@value{GDBP}) ptype bar
+ type = Type bar
+     int4 :: c
+     real*4 :: d
+ End Type bar
+ (@value{GDBP}) ptype foo
+ type = Type foo
+     real*4 :: a
+     Type bar
+         int4  :: c
+         real*4 :: d
+     End Type bar :: x
+     character (7) :: b
+ End Type foo
+ @end group
+ @end smallexample
+ 
+ @cindex structure value-print
+ @item print @var{derived-type}
+ For a variable of derived type, the @code{print} command will output the
+ value of all its members, including its nested derived type .
+ 
+ For example, for variable q of type foo defined above:
+ 
+ @smallexample
+ type(foo) :: q
+ @end smallexample
+ 
+ @noindent
+ the @code{print} command will output this:
+ 
+ @smallexample
+ @group
+ (@value{GDBP}) print q
+ $1 = @{ 3.125, @{ 1, 2.375@}, 
+        (97 'a', 98 'b', 99 'c', 100 'd', 101 'e', 102 'f', 103 'g')@}
+ @end group
+ @end smallexample
+ 
+ Please be noted that in the above example, the result of @code{print q}
+ is a single long line, broken only for clarity.
+ @noindent
+ 
  @end table
  
  @node Pascal


Regards
- Wu Zhou

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Fri, 24 Feb 2006 02:54:16 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> 
> Here is the modified document patch for F90 derived type support.  Please 
> review and comment.

Reviewed; comments below.

> + Fortran 90 and later support derived type (a.k.a structure).  For a
                                               ^^^^^
This should be "a.k.a.@:".  You forgot the last period, and @: tells
TeX that this period does not end a sentence, so that TeX typeset it
correctly.

> + type = Type bar
> +     int4 :: c
> +     real*4 :: d
> + End Type bar

Btw, isn't it more consistent to print "integer*4" instead of "int4"?
Either that, or just "integer", I think.  Or is "int4" a valid type
name in f90?  (The last Fortran I used was f77, so please forgive my
ignorance.)

> + For example, for variable q of type foo defined above:

"q" and "foo" should be in @code (they are program symbols).

> + Please be noted that in the above example, the result of @code{print q}
    ^^^^^^^^^^^^^^^
"Please note".

Other than that, fine with me.  Thanks.

Re: [RFC]: Document patch for F90 derived type support

[Wu Zhou]

Eli,

Thanks for your quick review!  Please see my answers below.

On Fri, 24 Feb 2006, Eli Zaretskii wrote:

> > Date: Fri, 24 Feb 2006 02:54:16 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > 
> > Here is the modified document patch for F90 derived type support.  Please 
> > review and comment.
> 
> Reviewed; comments below.
> 
> > + Fortran 90 and later support derived type (a.k.a structure).  For a
>                                                ^^^^^
> This should be "a.k.a.@:".  You forgot the last period, and @: tells
> TeX that this period does not end a sentence, so that TeX typeset it
> correctly.

Thanks for the correction.  Modified.

> > + type = Type bar
> > +     int4 :: c
> > +     real*4 :: d
> > + End Type bar
> 
> Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> Either that, or just "integer", I think.  Or is "int4" a valid type
> name in f90?  (The last Fortran I used was f77, so please forgive my
> ignorance.)

Yes. I also think so.  But the name of "int4" is got from the DWARF tag:

 <1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
     DW_AT_name        : int4
     DW_AT_byte_size   : 4
     DW_AT_encoding    : 5      (signed)

Maybe we can suggest the compiler to generate integer or integer*4 
instead.

> > + For example, for variable q of type foo defined above:
> 
> "q" and "foo" should be in @code (they are program symbols).

Modified.

> 
> > + Please be noted that in the above example, the result of @code{print q}
>     ^^^^^^^^^^^^^^^
> "Please note".

Thanks.  The modified patch is appended below:

2006-02-27  Wu Zhou  <woodzltc@cn.ibm.com>

	* gdb.texinfo (Fortran): Document the "%" operator for member
	access.  Document the type-print and value-print operation of
	Fortran 90 derived types.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.314
diff -c -p -r1.314 gdb.texinfo
*** gdb.texinfo	18 Feb 2006 20:45:01 -0000	1.314
--- gdb.texinfo	27 Feb 2006 02:59:47 -0000
*************** of the second one.
*** 9399,9404 ****
--- 9399,9408 ----
  @item :
  The range operator.  Normally used in the form of array(low:high) to
  represent a section of array.
+ 
+ @item %
+ Fortran 90 and later use this to access the members of derived
+ type, which is also introduced after the Fortran 90.
  @end table
  
  @node Fortran Defaults
*************** This command prints the values contained
*** 9427,9432 ****
--- 9431,9506 ----
  block whose name is @var{common-name}.  With no argument, the names of
  all @code{COMMON} blocks visible at current program location are
  printed.
+ 
+ @cindex structure type-print
+ @item ptype @var{derived-type}
+ Fortran 90 and later support derived type (a.k.a.@: structure).  For a
+ variable of derived type, the @code{ptype} command will output all its
+ members, including nested derived type.
+ 
+ For example, for this derived type declaration:
+ 
+ @smallexample
+ type bar
+   integer :: c
+   real :: d
+ end type
+ 
+ type foo
+   real :: a
+   type(bar) :: x
+   character*7 :: b
+ end type foo
+ @end smallexample
+ 
+ @noindent
+ the @code{ptype} commands give this output:
+ 
+ @smallexample
+ @group
+ (@value{GDBP}) ptype bar
+ type = Type bar
+     int4 :: c
+     real*4 :: d
+ End Type bar
+ (@value{GDBP}) ptype foo
+ type = Type foo
+     real*4 :: a
+     Type bar
+         int4  :: c
+         real*4 :: d
+     End Type bar :: x
+     character (7) :: b
+ End Type foo
+ @end group
+ @end smallexample
+ 
+ @cindex structure value-print
+ @item print @var{derived-type}
+ For a variable of derived type, the @code{print} command will output the
+ value of all its members, including its nested derived type .
+ 
+ For example, for variable @code{q} of type @code{foo} defined above:
+ 
+ @smallexample
+ type(foo) :: q
+ @end smallexample
+ 
+ @noindent
+ the @code{print} command will output this:
+ 
+ @smallexample
+ @group
+ (@value{GDBP}) print q
+ $1 = @{ 3.125, @{ 1, 2.375@}, 
+        (97 'a', 98 'b', 99 'c', 100 'd', 101 'e', 102 'f', 103 'g')@}
+ @end group
+ @end smallexample
+ 
+ Please note that in the above example, the result of @code{print q} is
+ a single long line, broken only for clarity.
+ @noindent
+ 
  @end table
  
  @node Pascal


Regards
- Wu Zhou

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Sun, 26 Feb 2006 23:34:40 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
> 
> > > + type = Type bar
> > > +     int4 :: c
> > > +     real*4 :: d
> > > + End Type bar
> > 
> > Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> > Either that, or just "integer", I think.  Or is "int4" a valid type
> > name in f90?  (The last Fortran I used was f77, so please forgive my
> > ignorance.)
> 
> Yes. I also think so.  But the name of "int4" is got from the DWARF tag:
> 
>  <1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
>      DW_AT_name        : int4
>      DW_AT_byte_size   : 4
>      DW_AT_encoding    : 5      (signed)

Well, we don't need t print everything DWARF-2 throws at us verbatim.
If you agree with my suggestions, I say let's use them.  Are there any
problems with that?

> + For a variable of derived type, the @code{print} command will output the
> + value of all its members, including its nested derived type .
                                                               ^^
An extra space.

> + Please note that in the above example, the result of @code{print q} is

@kbd{print q}, since it's what the user types at her keyboard.

Otherwise okay, thanks.

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Tue, Feb 28, 2006 at 07:37:46AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 26 Feb 2006 23:34:40 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sources.redhat.com
> > 
> > > > + type = Type bar
> > > > +     int4 :: c
> > > > +     real*4 :: d
> > > > + End Type bar
> > > 
> > > Btw, isn't it more consistent to print "integer*4" instead of "int4"?
> > > Either that, or just "integer", I think.  Or is "int4" a valid type
> > > name in f90?  (The last Fortran I used was f77, so please forgive my
> > > ignorance.)
> > 
> > Yes. I also think so.  But the name of "int4" is got from the DWARF tag:
> > 
> >  <1><e6>: Abbrev Number: 4 (DW_TAG_base_type)
> >      DW_AT_name        : int4
> >      DW_AT_byte_size   : 4
> >      DW_AT_encoding    : 5      (signed)
> 
> Well, we don't need t print everything DWARF-2 throws at us verbatim.
> If you agree with my suggestions, I say let's use them.  Are there any
> problems with that?

Normally we try to honor the type names in debug info.  If int4 is a
bogus name for a type in Fortran, then this debug info is bogus -
gfortran should be fixed.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Tue, 28 Feb 2006 08:53:10 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> 
> Normally we try to honor the type names in debug info.

If they make sense, sure.  If they don't, I don't think we should
blindly follow them.

> If int4 is a bogus name for a type in Fortran, then this debug info
> is bogus - gfortran should be fixed.

I agree, but at least one version of gfortran that uses int4 is
already out there, so I suggest that GDB handles that as we think it's
right.

Re: [RFC]: Document patch for F90 derived type support

[Wu Zhou]

On Tue, 28 Feb 2006, Eli Zaretskii wrote:

> > Date: Tue, 28 Feb 2006 08:53:10 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > 
> > Normally we try to honor the type names in debug info.
> 
> If they make sense, sure.  If they don't, I don't think we should
> blindly follow them.

I did some comparison between g77 and gfortran.  In the aspect of the 
compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
respectively.  So it might also make some sense.  At lease the debugger 
user can guess the meaning from these words.  :-) 

> > If int4 is a bogus name for a type in Fortran, then this debug info
> > is bogus - gfortran should be fixed.
> 
> I agree, but at least one version of gfortran that uses int4 is
> already out there, so I suggest that GDB handles that as we think it's
> right.
> 

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Tue, Feb 28, 2006 at 09:51:24PM -0500, Wu Zhou wrote:
> 
> On Tue, 28 Feb 2006, Eli Zaretskii wrote:
> 
> > > Date: Tue, 28 Feb 2006 08:53:10 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > > 
> > > Normally we try to honor the type names in debug info.
> > 
> > If they make sense, sure.  If they don't, I don't think we should
> > blindly follow them.
> 
> I did some comparison between g77 and gfortran.  In the aspect of the 
> compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
> for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
> seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
> respectively.  So it might also make some sense.  At lease the debugger 
> user can guess the meaning from these words.  :-) 

I think they're close enough to display for now; I spoke with Paul
Brook and there shouldn't be any trouble changing them if we want to.

Eli, I agree that it would be reasonable to ignore them; but I don't
think there's any particularly easy way to do it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Tue, 28 Feb 2006 21:51:24 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
> 
> I did some comparison between g77 and gfortran.  In the aspect of the 
> compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
> for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
> seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
> respectively.  So it might also make some sense.  At lease the debugger 
> user can guess the meaning from these words.  :-) 

So you now think that it is not a good idea to display "integer*4"
instead of "int4"?  I thought you previously agreed with me that the
former was better, from the user point of view.

GDB is a debugger.  If it were a program to display DWARF-2 debug
info, then it should have displayed exactly what is written in there.
But as a debugger, it should display something that is sensible to the
user of a debugger, i.e. it needs to speak the programming language of
the source, not DWARF.

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Tue, 28 Feb 2006 23:32:03 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> 
> > I did some comparison between g77 and gfortran.  In the aspect of the 
> > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
> > for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
> > seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
> > respectively.  So it might also make some sense.  At lease the debugger 
> > user can guess the meaning from these words.  :-) 
> 
> I think they're close enough to display for now

``For now''?  Are we in a hurry to release GDB or something?

> I spoke with Paul Brook and there shouldn't be any trouble changing
> them if we want to.

But what about the versions that are already there?  We want GDB to
behave consistently, even of gfortran does not.

> Eli, I agree that it would be reasonable to ignore them; but I don't
> think there's any particularly easy way to do it.

??? Won't something as simple as

   if (strcmp ("int4", ...) == 0)
      printf_filtered ("integer*4");

do?  What am I missing?

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Wed, Mar 01, 2006 at 06:53:44AM +0200, Eli Zaretskii wrote:
> > > I did some comparison between g77 and gfortran.  In the aspect of the 
> > > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
> > > for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
> > > seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
> > > respectively.  So it might also make some sense.  At lease the debugger 
> > > user can guess the meaning from these words.  :-) 
> > 
> > I think they're close enough to display for now
> 
> ``For now''?  Are we in a hurry to release GDB or something?

No, but my point was that there is no urgency in fixing it, which
allows us to fix gfortran instead.

> > I spoke with Paul Brook and there shouldn't be any trouble changing
> > them if we want to.
> 
> But what about the versions that are already there?  We want GDB to
> behave consistently, even of gfortran does not.

This is the same name that, e.g., gfortran probably uses in some
error messages.  I believe there's value in being consistent with
the compiler that the user is actually using.

You can argue it either way, I don't disagree.  I don't see either
side as particularly more compelling than the other.  For C++
we've been leaning towards consistency within GDB, although
we mostly implement consistency with the user's compiler - and
in some cases there's no choice about it.

> > Eli, I agree that it would be reasonable to ignore them; but I don't
> > think there's any particularly easy way to do it.
> 
> ??? Won't something as simple as
> 
>    if (strcmp ("int4", ...) == 0)
>       printf_filtered ("integer*4");
> 
> do?  What am I missing?

No, it can't be quite that simple, because current versions of Fortran
do support user-named types - "int4" does not necessarily imply
integer(4).  And future versions of the language may even have typedefs
for basic types.

Paul also corrected me on the naming - this would be integer(4)
apparently, integer*4 is something different.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Wed, 1 Mar 2006 00:05:01 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> 
> This is the same name that, e.g., gfortran probably uses in some
> error messages.

If "int4" is the official gfortran name (is it?), then I agree we
should leave it alone.

> No, it can't be quite that simple, because current versions of Fortran
> do support user-named types - "int4" does not necessarily imply
> integer(4).

Perhaps I'm confused: isn't "int4" a 32-bit integer?  I thought it
was, but if I was mistaken, my apologies for the noise.

> Paul also corrected me on the naming - this would be integer(4)
> apparently, integer*4 is something different.

Can you (or someone else) elaborate, or point me to some document that
does?

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Wed, Mar 01, 2006 at 09:02:34PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 00:05:01 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > 
> > This is the same name that, e.g., gfortran probably uses in some
> > error messages.
> 
> If "int4" is the official gfortran name (is it?), then I agree we
> should leave it alone.

I'm not sure if "official" is really strong enough; I suspect it will
use it in some user messages, as well as in debug information.

> > No, it can't be quite that simple, because current versions of Fortran
> > do support user-named types - "int4" does not necessarily imply
> > integer(4).
> 
> Perhaps I'm confused: isn't "int4" a 32-bit integer?  I thought it
> was, but if I was mistaken, my apologies for the noise.

It's not reserved at all in the input to the compiler - it might be
something different than a type, or it might be the name of a record
type (whatever the correct name for that is).

> > Paul also corrected me on the naming - this would be integer(4)
> > apparently, integer*4 is something different.
> 
> Can you (or someone else) elaborate, or point me to some document that
> does?

I believe integer(4) is an integer with kind == 4.  Paul wrote:

> integer(4) is the standard way, though the "4" has no particular meaning.
> integer*4 is a nonstandard (but common) extension saying "I want an
> integer 4 somthings wide". This may or may not be the same as integer(4).

Make of that whatever you want to...

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Wu Zhou]

Maybe we can do this:

    case TYPE_CODE_INT:
      /* There may be some character types that attempt to come
         through as TYPE_CODE_INT since dbxstclass.h is so
         C-oriented, we must change these to "character" from "char".  */

      if (strcmp (TYPE_NAME (type), "char") == 0)
        fprintfi_filtered (level, stream, "character");
      else
        fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
      break;

The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to 
determine what should be displayed.  

This might be inconsistent with what the compiler generats (there is also 
a benefit in this too, we don't need't adapt to all these different 
compilers, which might generate different names for these types).  But it 
is acceptable by the programmer I believe.  And also conform to the 
language standard.

Any comment on this?

Regards
- Wu Zhou

On Wed, 1 Mar 2006, Daniel Jacobowitz wrote:

> On Wed, Mar 01, 2006 at 09:02:34PM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 1 Mar 2006 00:05:01 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Wu Zhou <woodzltc@cn.ibm.com>, gdb-patches@sources.redhat.com
> > > 
> > > This is the same name that, e.g., gfortran probably uses in some
> > > error messages.
> > 
> > If "int4" is the official gfortran name (is it?), then I agree we
> > should leave it alone.
> 
> I'm not sure if "official" is really strong enough; I suspect it will
> use it in some user messages, as well as in debug information.
> 
> > > No, it can't be quite that simple, because current versions of Fortran
> > > do support user-named types - "int4" does not necessarily imply
> > > integer(4).
> > 
> > Perhaps I'm confused: isn't "int4" a 32-bit integer?  I thought it
> > was, but if I was mistaken, my apologies for the noise.
> 
> It's not reserved at all in the input to the compiler - it might be
> something different than a type, or it might be the name of a record
> type (whatever the correct name for that is).
> 
> > > Paul also corrected me on the naming - this would be integer(4)
> > > apparently, integer*4 is something different.
> > 
> > Can you (or someone else) elaborate, or point me to some document that
> > does?
> 
> I believe integer(4) is an integer with kind == 4.  Paul wrote:
> 
> > integer(4) is the standard way, though the "4" has no particular meaning.
> > integer*4 is a nonstandard (but common) extension saying "I want an
> > integer 4 somthings wide". This may or may not be the same as integer(4).
> 
> Make of that whatever you want to...
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery
> 

Re: [RFC]: Document patch for F90 derived type support

[Wu Zhou]

On Wed, 1 Mar 2006, Eli Zaretskii wrote:

> > Date: Tue, 28 Feb 2006 21:51:24 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sources.redhat.com
> > 
> > I did some comparison between g77 and gfortran.  In the aspect of the 
> > compiler-generated DW_TAG_base_type, g77 uses "byte", "word" and "integer" 
> > for "integer*1", "integer*2" and "integer*4" respectively.  And gfortran 
> > seems to adopt a new mechanism, it uses "int1", "int2" and "int4" 
> > respectively.  So it might also make some sense.  At lease the debugger 
> > user can guess the meaning from these words.  :-) 
> 
> So you now think that it is not a good idea to display "integer*4"
> instead of "int4"?  I thought you previously agreed with me that the
> former was better, from the user point of view.

Eli, I am still with you.  The former is surely better for the user.  
But I am not sure yet which should be fixed, the compiler or the 
debugger.

I proposed another method, which depends on TYPE_CODE (type) and 
TYPE_LENGTH (type) to determine what to be displayed at last. How do you 
think on that?  (I sent out that proposal a while ago)

> GDB is a debugger.  If it were a program to display DWARF-2 debug
> info, then it should have displayed exactly what is written in there.
> But as a debugger, it should display something that is sensible to the
> user of a debugger, i.e. it needs to speak the programming language of
> the source, not DWARF.

Good stand.  I agree with you on this too.  :-)

Regards
- Wu Zhou

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Wed, Mar 01, 2006 at 09:44:07PM -0500, Wu Zhou wrote:
> Eli, I am still with you.  The former is surely better for the user.  
> But I am not sure yet which should be fixed, the compiler or the 
> debugger.

My preference is to fix the compiler rather than the debugger here; it
should output something sensible, and I think the heuristics in the
debugger will be fragile.  But, it's up to whoever does the work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Wed, 1 Mar 2006 14:38:29 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > Perhaps I'm confused: isn't "int4" a 32-bit integer?  I thought it
> > was, but if I was mistaken, my apologies for the noise.
> 
> It's not reserved at all in the input to the compiler - it might be
> something different than a type, or it might be the name of a record
> type (whatever the correct name for that is).

I'm still not sure I understand, but I think you do agree that this is
a 32-bit integer.  In that case, I maintain that we should display
"integer(4)", not "int4".

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Thu, Mar 02, 2006 at 06:25:56AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 14:38:29 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > Perhaps I'm confused: isn't "int4" a 32-bit integer?  I thought it
> > > was, but if I was mistaken, my apologies for the noise.
> > 
> > It's not reserved at all in the input to the compiler - it might be
> > something different than a type, or it might be the name of a record
> > type (whatever the correct name for that is).
> 
> I'm still not sure I understand, but I think you do agree that this is
> a 32-bit integer.  In that case, I maintain that we should display
> "integer(4)", not "int4".

Sorry, I am not expressing myself well.

The fact that it is named "int4" in debug output doesn't mean that it
is a 32-bit integer.  The fact that it is a 32-bit integer, in turn,
may mean that we could choose to ignore its name if that was
worthwhile.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sourceware.org
> 
> Maybe we can do this:
> 
>     case TYPE_CODE_INT:
>       /* There may be some character types that attempt to come
>          through as TYPE_CODE_INT since dbxstclass.h is so
>          C-oriented, we must change these to "character" from "char".  */
> 
>       if (strcmp (TYPE_NAME (type), "char") == 0)
>         fprintfi_filtered (level, stream, "character");
>       else
>         fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
>       break;
> 
> The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to 
> determine what should be displayed.  

This is okay with me.  Thanks.

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Wed, 1 Mar 2006 21:44:07 -0500 (EST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com
> 
> But I am not sure yet which should be fixed, the compiler or the 
> debugger.

I think they both should be fixed.  Your suggestion to use TYPE_LENGTH
does the right thing for the debugger, I think.

Re: [RFC]: Document patch for F90 derived type support

[Eli Zaretskii]

> Date: Wed, 1 Mar 2006 22:22:29 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
> 
> My preference is to fix the compiler rather than the debugger here; it
> should output something sensible

Again, the versions of the compiler that are already out there should
not produce wrong types in GDB, IMHO.

Re: [RFC]: Document patch for F90 derived type support

[Daniel Jacobowitz]

On Thu, Mar 02, 2006 at 06:36:03AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: gdb-patches@sourceware.org
> > 
> > Maybe we can do this:
> > 
> >     case TYPE_CODE_INT:
> >       /* There may be some character types that attempt to come
> >          through as TYPE_CODE_INT since dbxstclass.h is so
> >          C-oriented, we must change these to "character" from "char".  */
> > 
> >       if (strcmp (TYPE_NAME (type), "char") == 0)
> >         fprintfi_filtered (level, stream, "character");
> >       else
> >         fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
> >       break;
> > 
> > The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to 
> > determine what should be displayed.  
> 
> This is okay with me.  Thanks.

Me too, I suppose.  If you're going to go this route, take a look at
the full set of types that gfortran prints out useless names for,
please.  It's in gcc/fortran/trans-type.c.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Document patch for F90 derived type support

[Wu Zhou]

On Wed, 1 Mar 2006, Daniel Jacobowitz wrote:

> On Thu, Mar 02, 2006 at 06:36:03AM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 1 Mar 2006 21:33:35 -0500 (EST)
> > > From: Wu Zhou <woodzltc@cn.ibm.com>
> > > cc: gdb-patches@sourceware.org
> > > 
> > > Maybe we can do this:
> > > 
> > >     case TYPE_CODE_INT:
> > >       /* There may be some character types that attempt to come
> > >          through as TYPE_CODE_INT since dbxstclass.h is so
> > >          C-oriented, we must change these to "character" from "char".  */
> > > 
> > >       if (strcmp (TYPE_NAME (type), "char") == 0)
> > >         fprintfi_filtered (level, stream, "character");
> > >       else
> > >         fprintfi_filtered (level, stream, "integer (%d)", TYPE_LENGTH (type));
> > >       break;
> > > 
> > > The basic idea is to let the TYPE_CODE (type) and TYPE_LENGTH (type) to 
> > > determine what should be displayed.  
> > 
> > This is okay with me.  Thanks.
> 
> Me too, I suppose.  If you're going to go this route, take a look at
> the full set of types that gfortran prints out useless names for,
> please.  It's in gcc/fortran/trans-type.c.

OK.  I will.  If I have time, I will see if I can also make a patch 
for gfortran.  Thanks for the pointer.

Regards
- Wu Zhou