[RFC]: Patch to support Fortran derived type - Revised

[RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

Hello all,

I revised the patch to add derived type support.  Now it can print 
the nested type such like this:

Type foo
    int4 :: a
    Type bar
        real :: b
    End Type bar :: x
End Type foo

It could also handle the member access like q%x%b.  So I think it is 
better than before.  Any more place is needed to be improved, please let 
me know.  Here is the patch:

2005-11-16  Wu Zhou  <woodzltc@cn.ibm.com>

	* f-exp.y: Symbol '%' is not used as modular operator in Fortran.
	Delete this from Fortran expression. 
	It is now used by Fortran 95 to access the member of derived type.
	Add this into Fortran expression.
	* f-valprint.c (f_val_print): Add code to handle TYPE_CODE_STRUCT.
	Print each elements in the derived type.
	* f-typeprint.c (print_equivalent_f77_float_type): Add a parameter
	level into the function definition to do indented printing. And 
	call fprintfi_filtered instead to do indented printing.
	(f_type_print_base): Replace fprintf_filtered with the indented
	version (fprintfi_filtered).
	(f_type_print_base): Call indented print_equivalent_f77_float_type.
	(f_type_print_base): Add code to handle TYPE_CODE_STRUCT. Print
	the definition of the derived type.
		
Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.18
diff -u -p -r1.18 f-exp.y
--- f-exp.y	20 Sep 2005 06:25:34 -0000	1.18
+++ f-exp.y	16 Nov 2005 07:04:49 -0000
@@ -177,6 +177,7 @@ static int parse_number (char *, int, in
 %token <lval> BOOLEAN_LITERAL
 %token <ssym> NAME 
 %token <tsym> TYPENAME
+%type <sval> name
 %type <ssym> name_not_typename
 
 /* A NAME_OR_INT is a symbol which is not known in the symbol table,
@@ -216,8 +217,9 @@ static int parse_number (char *, int, in
 %left LSH RSH
 %left '@'
 %left '+' '-'
-%left '*' '/' '%'
+%left '*' '/'
 %right STARSTAR
+%right '%'
 %right UNARY 
 %right '('
 
@@ -331,6 +333,12 @@ exp	:	'(' type ')' exp  %prec UNARY
 			  write_exp_elt_opcode (UNOP_CAST); }
 	;
 
+exp     :       exp '%' name
+                        { write_exp_elt_opcode (STRUCTOP_STRUCT);
+                          write_exp_string ($3);
+                          write_exp_elt_opcode (STRUCTOP_STRUCT); }
+        ;
+
 /* Binary operators in order of decreasing precedence.  */
 
 exp	:	exp '@' exp
@@ -349,10 +357,6 @@ exp	:	exp '/' exp
 			{ write_exp_elt_opcode (BINOP_DIV); }
 	;
 
-exp	:	exp '%' exp
-			{ write_exp_elt_opcode (BINOP_REM); }
-	;
-
 exp	:	exp '+' exp
 			{ write_exp_elt_opcode (BINOP_ADD); }
 	;
@@ -634,6 +638,10 @@ nonempty_typelist
 		}
 	;
 
+name	:	NAME
+		{  $$ = $1.stoken; }
+	;
+
 name_not_typename :	NAME
 /* These would be useful if name_not_typename was useful, but it is just
    a fake for "variable", so these cause reduce/reduce conflicts because
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.30
diff -u -p -r1.30 f-valprint.c
--- f-valprint.c	9 May 2005 21:20:30 -0000	1.30
+++ f-valprint.c	16 Nov 2005 07:04:53 -0000
@@ -366,6 +366,7 @@ f_val_print (struct type *type, const gd
   struct type *elttype;
   LONGEST val;
   CORE_ADDR addr;
+  int index;
 
   CHECK_TYPEDEF (type);
   switch (TYPE_CODE (type))
@@ -576,6 +577,22 @@ f_val_print (struct type *type, const gd
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_STRUCT:
+      /* Starting from Fortran 90 standard, Fortran language began to support
+         derived type. The type code is TYPE_CODE_STRUCT.  */
+      fprintf_filtered (stream, "{ ");
+      for (index = 0; index < TYPE_NFIELDS (type); index++)
+        {
+          char * field_addr = valaddr + TYPE_FIELD_BITPOS (type, index) / 8;
+          f_val_print (TYPE_FIELD_TYPE (type, index), field_addr,
+                       embedded_offset, address, stream,
+                       format, deref_ref, recurse, pretty);
+          if (index != TYPE_NFIELDS (type) - 1)
+            fputs_filtered (", ", stream);
+        }
+      fprintf_filtered (stream, "}");
+      break;     
+
     default:
       error (_("Invalid F77 type code %d in symbol table."), TYPE_CODE (type));
     }
Index: f-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-typeprint.c,v
retrieving revision 1.13
diff -u -p -r1.13 f-typeprint.c
--- f-typeprint.c	11 Feb 2005 04:05:47 -0000	1.13
+++ f-typeprint.c	16 Nov 2005 07:04:55 -0000
@@ -1,7 +1,7 @@
 /* Support for printing Fortran types for GDB, the GNU debugger.
 
    Copyright 1986, 1988, 1989, 1991, 1993, 1994, 1995, 1996, 1998,
-   2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+   2000, 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
 
    Contributed by Motorola.  Adapted from the C version by Farooq Butt
    (fmbutt@engage.sps.mot.com).
@@ -41,7 +41,7 @@
 static void f_type_print_args (struct type *, struct ui_file *);
 #endif
 
-static void print_equivalent_f77_float_type (struct type *,
+static void print_equivalent_f77_float_type (int level, struct type *,
 					     struct ui_file *);
 
 static void f_type_print_varspec_suffix (struct type *, struct ui_file *,
@@ -260,13 +260,13 @@ f_type_print_varspec_suffix (struct type
 }
 
 static void
-print_equivalent_f77_float_type (struct type *type, struct ui_file *stream)
+print_equivalent_f77_float_type (int level, struct type *type, struct ui_file *stream)
 {
   /* Override type name "float" and make it the
      appropriate real. XLC stupidly outputs -12 as a type
      for real when it really should be outputting -18 */
 
-  fprintf_filtered (stream, "real*%d", TYPE_LENGTH (type));
+  fprintfi_filtered (level, stream, "real*%d", TYPE_LENGTH (type));
 }
 
 /* Print the name of the type (or the ultimate pointer target,
@@ -289,6 +289,8 @@ f_type_print_base (struct type *type, st
   int retcode;
   int upper_bound;
 
+  int index;
+
   QUIT;
 
   wrap_here ("    ");
@@ -304,7 +306,7 @@ f_type_print_base (struct type *type, st
   if ((show <= 0) && (TYPE_NAME (type) != NULL))
     {
       if (TYPE_CODE (type) == TYPE_CODE_FLT)
-	print_equivalent_f77_float_type (type, stream);
+	print_equivalent_f77_float_type (level, type, stream);
       else
 	fputs_filtered (TYPE_NAME (type), stream);
       return;
@@ -335,25 +337,25 @@ f_type_print_base (struct type *type, st
       break;
 
     case TYPE_CODE_VOID:
-      fprintf_filtered (stream, "VOID");
+      fprintfi_filtered (level, stream, "VOID");
       break;
 
     case TYPE_CODE_UNDEF:
-      fprintf_filtered (stream, "struct <unknown>");
+      fprintfi_filtered (level, stream, "struct <unknown>");
       break;
 
     case TYPE_CODE_ERROR:
-      fprintf_filtered (stream, "<unknown type>");
+      fprintfi_filtered (level, stream, "<unknown type>");
       break;
 
     case TYPE_CODE_RANGE:
       /* This should not occur */
-      fprintf_filtered (stream, "<range type>");
+      fprintfi_filtered (level, stream, "<range type>");
       break;
 
     case TYPE_CODE_CHAR:
       /* Override name "char" and make it "character" */
-      fprintf_filtered (stream, "character");
+      fprintfi_filtered (level, stream, "character");
       break;
 
     case TYPE_CODE_INT:
@@ -362,24 +364,24 @@ f_type_print_base (struct type *type, st
          C-oriented, we must change these to "character" from "char".  */
 
       if (strcmp (TYPE_NAME (type), "char") == 0)
-	fprintf_filtered (stream, "character");
+	fprintfi_filtered (level, stream, "character");
       else
 	goto default_case;
       break;
 
     case TYPE_CODE_COMPLEX:
-      fprintf_filtered (stream, "complex*%d", TYPE_LENGTH (type));
+      fprintfi_filtered (level, stream, "complex*%d", TYPE_LENGTH (type));
       break;
 
     case TYPE_CODE_FLT:
-      print_equivalent_f77_float_type (type, stream);
+      print_equivalent_f77_float_type (level, type, stream);
       break;
 
     case TYPE_CODE_STRING:
       /* Strings may have dynamic upperbounds (lengths) like arrays. */
 
       if (TYPE_ARRAY_UPPER_BOUND_TYPE (type) == BOUND_CANNOT_BE_DETERMINED)
-	fprintf_filtered (stream, "character*(*)");
+	fprintfi_filtered (level, stream, "character*(*)");
       else
 	{
 	  retcode = f77_get_dynamic_upperbound (type, &upper_bound);
@@ -391,6 +393,21 @@ f_type_print_base (struct type *type, st
 	}
       break;
 
+    case TYPE_CODE_STRUCT:
+      fprintfi_filtered (level, stream, "Type ");
+      fputs_filtered (TYPE_TAG_NAME (type), stream);
+      fputs_filtered ("\n", stream);
+      for (index = 0; index < TYPE_NFIELDS (type); index++)
+	{
+	  f_print_type (TYPE_FIELD_TYPE (type, index), "", stream, show, level + 4);
+	  fputs_filtered (" :: ", stream);
+	  fputs_filtered (TYPE_FIELD_NAME (type, index), stream);
+	  fputs_filtered ("\n", stream);
+	} 
+      fprintfi_filtered (level, stream, "End Type ");
+      fputs_filtered (TYPE_TAG_NAME (type), stream);
+      break;
+
     default_case:
     default:
       /* Handle types not explicitly handled by the other cases,
@@ -398,7 +415,7 @@ f_type_print_base (struct type *type, st
          the type name is, as recorded in the type itself.  If there
          is no type name, then complain. */
       if (TYPE_NAME (type) != NULL)
-	fputs_filtered (TYPE_NAME (type), stream);
+	fprintfi_filtered (level, stream, "%s ", TYPE_NAME (type));
       else
 	error (_("Invalid type code (%d) in symbol table."), TYPE_CODE (type));
       break;

Re: [RFC]: Patch to support Fortran derived type - Revised

[Eli Zaretskii]

> Date: Wed, 16 Nov 2005 15:20:18 +0800 (CST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: Thomas.Koenig@online.de
> 
> I revised the patch to add derived type support.  Now it can print 
> the nested type such like this:
> 
> Type foo
>     int4 :: a
>     Type bar
>         real :: b
>     End Type bar :: x
> End Type foo
> 
> It could also handle the member access like q%x%b.

Thanks.

> Any more place is needed to be improved, please let me know.

How about mentioning this in the manual?  It would be good to document
how these values and types are printed, in case a user is not fluent
with these f9x features.

Re: [RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

By the way, anyone has any idea or comments about the patch?  I am more 
than happy to improve it if you have any idea. 

According to the new maintenance policy, how long should I ping for my 
un-reviewed patch.  If it still gets no reply in a specified time, is 
there anything I can do to get some attention, escalate this to the SC or 
anything else?

P.S: I am asking this because I don't have any knowledge about them ever 
since I join in the GDB community.  I think other new members might also 
feel this way.  Someone ever told me to wait for one or two weeks.  But 
I am not sure.  

Regards
- Wu Zhou

On Tue, 22 Nov 2005, Wu Zhou wrote:

> Thanks for your comments.  
> 
> Yes. I am thinking of adding these to gdb manual.  But I am not sure how 
> to organize them. As you know, we already have three subsection: Fortran 
> operators, Fortran defaults and special Fortran command.  Which section 
> should this kind of text gets into?  Maybe special Fortran commands? 
> But They are in fact common GDB command, only with somewhat different 
> output format. Maybe it make sense to add another new section?  What do 
> you think?
> 
> However I did added a few words in the Fortran operators section.  Here is 
> the patch:
> 
> Index: gdb.texinfo
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
> retrieving revision 1.296
> diff -u -p -r1.296 gdb.texinfo
> --- gdb.texinfo	20 Nov 2005 06:12:59 -0000	1.296
> +++ gdb.texinfo	22 Nov 2005 07:05:01 -0000
> @@ -9159,6 +9159,10 @@ of the second one.
>  @item :
>  The range operator.  Normally used in the form of array(low:high) to
>  represent a section of array.
> +
> +@item %
> +Fortran 90 and afterwards use this to access the members of derived
> +type, which is also introduced after the Fortran 90.
>  @end table
>  
>  @node Fortran Defaults
> 
> 
> Regards
> - Wu Zhou
> 

Re: [RFC]: Patch to support Fortran derived type - Revised

[Daniel Jacobowitz]

On Tue, Nov 22, 2005 at 03:47:03PM +0800, Wu Zhou wrote:
> By the way, anyone has any idea or comments about the patch?  I am more 
> than happy to improve it if you have any idea. 
> 
> According to the new maintenance policy, how long should I ping for my 
> un-reviewed patch.  If it still gets no reply in a specified time, is 
> there anything I can do to get some attention, escalate this to the SC or 
> anything else?

There is no new policy.  It's a proposal, still under discussion.  Even
if it were adopted, escalating to the SC is almost never the right
thing to do: the SC is completely uninvolved in day-to-day development.

As always, I review code patches as frequently as I am able.  I'll get
to it.  If any of the other global maintainers out there want to, of
course, they're invited to review contributions too!


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

Hi Eli,

On Wed, 16 Nov 2005, Eli Zaretskii wrote:

> > Date: Wed, 16 Nov 2005 15:20:18 +0800 (CST)
> > From: Wu Zhou <woodzltc@cn.ibm.com>
> > cc: Thomas.Koenig@online.de
> > 
> > I revised the patch to add derived type support.  Now it can print 
> > the nested type such like this:
> > 
> > Type foo
> >     int4 :: a
> >     Type bar
> >         real :: b
> >     End Type bar :: x
> > End Type foo
> > 
> > It could also handle the member access like q%x%b.
> 
> Thanks.
> 
> > Any more place is needed to be improved, please let me know.
> 
> How about mentioning this in the manual?  It would be good to document
> how these values and types are printed, in case a user is not fluent
> with these f9x features.
> 
Thanks for your comments.  

Yes. I am thinking of adding these to gdb manual.  But I am not sure how 
to organize them. As you know, we already have three subsection: Fortran 
operators, Fortran defaults and special Fortran command.  Which section 
should this kind of text gets into?  Maybe special Fortran commands? 
But They are in fact common GDB command, only with somewhat different 
output format. Maybe it make sense to add another new section?  What do 
you think?

However I did added a few words in the Fortran operators section.  Here is 
the patch:

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.296
diff -u -p -r1.296 gdb.texinfo
--- gdb.texinfo	20 Nov 2005 06:12:59 -0000	1.296
+++ gdb.texinfo	22 Nov 2005 07:05:01 -0000
@@ -9159,6 +9159,10 @@ of the second one.
 @item :
 The range operator.  Normally used in the form of array(low:high) to
 represent a section of array.
+
+@item %
+Fortran 90 and afterwards use this to access the members of derived
+type, which is also introduced after the Fortran 90.
 @end table
 
 @node Fortran Defaults


Regards
- Wu Zhou

Re: [RFC]: Patch to support Fortran derived type - Revised

[Eli Zaretskii]

> Date: Tue, 22 Nov 2005 15:20:50 +0800 (CST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com, Thomas.Koenig@online.de
> 
> Yes. I am thinking of adding these to gdb manual.  But I am not sure how 
> to organize them. As you know, we already have three subsection: Fortran 
> operators, Fortran defaults and special Fortran command.  Which section 
> should this kind of text gets into?  Maybe special Fortran commands? 

Yes, Fortran commands sounds like the right place.

> However I did added a few words in the Fortran operators section.  Here is 
> the patch:
> 
> Index: gdb.texinfo
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
> retrieving revision 1.296
> diff -u -p -r1.296 gdb.texinfo
> --- gdb.texinfo	20 Nov 2005 06:12:59 -0000	1.296
> +++ gdb.texinfo	22 Nov 2005 07:05:01 -0000
> @@ -9159,6 +9159,10 @@ of the second one.
>  @item :
>  The range operator.  Normally used in the form of array(low:high) to
>  represent a section of array.
> +
> +@item %
> +Fortran 90 and afterwards use this to access the members of derived
> +type, which is also introduced after the Fortran 90.

Thanks, this is fine.

Re: [RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

On Tue, 22 Nov 2005, Daniel Jacobowitz wrote:

> On Tue, Nov 22, 2005 at 03:47:03PM +0800, Wu Zhou wrote:
> > By the way, anyone has any idea or comments about the patch?  I am more 
> > than happy to improve it if you have any idea. 
> > 
> > According to the new maintenance policy, how long should I ping for my 
> > un-reviewed patch.  If it still gets no reply in a specified time, is 
> > there anything I can do to get some attention, escalate this to the SC or 
> > anything else?
> 
> There is no new policy.  It's a proposal, still under discussion.  Even
> if it were adopted, escalating to the SC is almost never the right
> thing to do: the SC is completely uninvolved in day-to-day development.

OK.  Understand.  Hope that this is adopted soon.
 
> As always, I review code patches as frequently as I am able.  I'll get
> to it.  If any of the other global maintainers out there want to, of
> course, they're invited to review contributions too!

Thanks! You are really a big help here, for me and also many others I 
believe!

Regards
- Wu Zhou 

Re: [RFC]: Patch to support Fortran derived type - Revised

[Daniel Jacobowitz]

On Wed, Nov 16, 2005 at 03:20:18PM +0800, Wu Zhou wrote:
> Hello all,
> 
> I revised the patch to add derived type support.  Now it can print 
> the nested type such like this:
> 
> Type foo
>     int4 :: a
>     Type bar
>         real :: b
>     End Type bar :: x
> End Type foo
> 
> It could also handle the member access like q%x%b.  So I think it is 
> better than before.  Any more place is needed to be improved, please let 
> me know.  Here is the patch:

Hi Wu, sorry about the delay.  Just a couple of small comments.  First
of all, I'd prefer not to approve this without documentation and a
testcase.

> 2005-11-16  Wu Zhou  <woodzltc@cn.ibm.com>
> 
> 	* f-exp.y: Symbol '%' is not used as modular operator in Fortran.
> 	Delete this from Fortran expression. 
> 	It is now used by Fortran 95 to access the member of derived type.
> 	Add this into Fortran expression.

You want "is not used as the modulus operator" here, I believe.  There's
a "modular operator" also, which seems to be something complicated in
operator theory - completely different.

> +name	:	NAME
> +		{  $$ = $1.stoken; }
> +	;
> +

Why not just use name_not_typename instead of adding "name"?

Also, the comments in name_not_typename don't apply here; you could
also handle exp : exp % NAME_OR_INT as a name.  But, I don't think that
adds much value.  The whole NAME_OR_INT thing seems like overkill.

> +      /* Starting from Fortran 90 standard, Fortran language began to support
> +         derived type. The type code is TYPE_CODE_STRUCT.  */

/* Starting from the Fortran 90 standard, Fortran supports derived
   types.  */

Two periods after period, please :-)  I think you can skip mentioning
TYPE_CODE_STRUCT, since it's the case label.

> +print_equivalent_f77_float_type (int level, struct type *type, struct ui_file *stream)

Needs to be wrapped.

The rest looks fine.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC]: Patch to support Fortran derived type - Revised

[Eli Zaretskii]

> Date: Wed, 7 Dec 2005 18:25:41 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com, Thomas.Koenig@online.de
> 
> /* Starting from the Fortran 90 standard, Fortran supports derived
>    types.  */
> 
> Two periods after period, please :-)

Daniel meant two blanks after the period.

Re: [RFC]: Patch to support Fortran derived type - Revised

[Daniel Jacobowitz]

On Thu, Dec 08, 2005 at 06:30:33AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 7 Dec 2005 18:25:41 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com, Thomas.Koenig@online.de
> > 
> > /* Starting from the Fortran 90 standard, Fortran supports derived
> >    types.  */
> > 
> > Two periods after period, please :-)
> 
> Daniel meant two blanks after the period.

Er.  Thank you, Eli!

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

Hi, Daniel/Eli

Thanks a lot for your kind comments.  My replies is as follows.

On Wed, 7 Dec 2005, Daniel Jacobowitz wrote:

> Hi Wu, sorry about the delay.  Just a couple of small comments.  First
> of all, I'd prefer not to approve this without documentation and a
> testcase.

No problem.  I know your guys are really busy.  :-)

I had submitted a testcase and a little document in other mails. I will 
now include them in one mail this time, with a little more document about 
the type and value print.

> > 2005-11-16  Wu Zhou  <woodzltc@cn.ibm.com>
> > 
> > 	* f-exp.y: Symbol '%' is not used as modular operator in Fortran.
> > 	Delete this from Fortran expression. 
> > 	It is now used by Fortran 95 to access the member of derived type.
> > 	Add this into Fortran expression.
> 
> You want "is not used as the modulus operator" here, I believe.  There's
> a "modular operator" also, which seems to be something complicated in
> operator theory - completely different.

OK. Thanks for pointing this out.
 
> > +name	:	NAME
> > +		{  $$ = $1.stoken; }
> > +	;
> > +
> 
> Why not just use name_not_typename instead of adding "name"?
> 
> Also, the comments in name_not_typename don't apply here; you could
> also handle exp : exp % NAME_OR_INT as a name.  But, I don't think that
> adds much value.  The whole NAME_OR_INT thing seems like overkill.

AFAICT, adding "name" might be a more direct and easier way to handle 
that. I am not sure yet how to handle name_not_typename or NAME_OR_INT, 
but it seems that some more work is needed in either the parsing or 
evaluation phase.  What is more, using "name" is the same way as that in
c and c++ expression parser, which looks to be more consistent. 

Does these make sense?

> > +      /* Starting from Fortran 90 standard, Fortran language began to support
> > +         derived type. The type code is TYPE_CODE_STRUCT.  */
> 
> /* Starting from the Fortran 90 standard, Fortran supports derived
>    types.  */
> 
> Two periods after period, please :-)  I think you can skip mentioning
> TYPE_CODE_STRUCT, since it's the case label.

Thanks. Your words is much more concise than mine.

> > +print_equivalent_f77_float_type (int level, struct type *type, struct ui_file *stream)
> 
> Needs to be wrapped.

Yes. It needs wrapping.

> The rest looks fine.

Here is the revised patch, testcase and documents.

2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>

	* f-exp.y: Symbol '%' is not used as the modular operator in
	Fortran.  Delete this from Fortran expression.
	It is now used by Fortran 90 and afterwards to access the member
	of derived type.  Add this into Fortran expression.
	* f-valprint.c (f_val_print): Add code to handle TYPE_CODE_STRUCT.
	Print each elements in the derived type.
	* f-typeprint.c (print_equivalent_f77_float_type): Add a parameter
	level into the function definition to do indented printing.  And
	call fprintfi_filtered instead to do indented printing.
	(f_type_print_base): Replace fprintf_filtered with the indented
	version (fprintfi_filtered).
	(f_type_print_base): Call indented print_equivalent_f77_float_type.
	(f_type_print_base): Add code to handle TYPE_CODE_STRUCT.  Print
	the definition of the derived type.

Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.18
diff -c -p -r1.18 f-exp.y
*** f-exp.y	20 Sep 2005 06:25:34 -0000	1.18
--- f-exp.y	10 Dec 2005 06:50:50 -0000
*************** static int parse_number (char *, int, in
*** 177,182 ****
--- 177,183 ----
  %token <lval> BOOLEAN_LITERAL
  %token <ssym> NAME 
  %token <tsym> TYPENAME
+ %type <sval> name
  %type <ssym> name_not_typename
  
  /* A NAME_OR_INT is a symbol which is not known in the symbol table,
*************** static int parse_number (char *, int, in
*** 216,223 ****
  %left LSH RSH
  %left '@'
  %left '+' '-'
! %left '*' '/' '%'
  %right STARSTAR
  %right UNARY 
  %right '('
  
--- 217,225 ----
  %left LSH RSH
  %left '@'
  %left '+' '-'
! %left '*' '/'
  %right STARSTAR
+ %right '%'
  %right UNARY 
  %right '('
  
*************** exp	:	'(' type ')' exp  %prec UNARY
*** 331,336 ****
--- 333,344 ----
  			  write_exp_elt_opcode (UNOP_CAST); }
  	;
  
+ exp     :       exp '%' name
+                         { write_exp_elt_opcode (STRUCTOP_STRUCT);
+                           write_exp_string ($3);
+                           write_exp_elt_opcode (STRUCTOP_STRUCT); }
+         ;
+ 
  /* Binary operators in order of decreasing precedence.  */
  
  exp	:	exp '@' exp
*************** exp	:	exp '/' exp
*** 349,358 ****
  			{ write_exp_elt_opcode (BINOP_DIV); }
  	;
  
- exp	:	exp '%' exp
- 			{ write_exp_elt_opcode (BINOP_REM); }
- 	;
- 
  exp	:	exp '+' exp
  			{ write_exp_elt_opcode (BINOP_ADD); }
  	;
--- 357,362 ----
*************** nonempty_typelist
*** 634,639 ****
--- 638,647 ----
  		}
  	;
  
+ name	:	NAME
+ 		{  $$ = $1.stoken; }
+ 	;
+ 
  name_not_typename :	NAME
  /* These would be useful if name_not_typename was useful, but it is just
     a fake for "variable", so these cause reduce/reduce conflicts because
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.30
diff -c -p -r1.30 f-valprint.c
*** f-valprint.c	9 May 2005 21:20:30 -0000	1.30
--- f-valprint.c	10 Dec 2005 06:50:50 -0000
*************** f_val_print (struct type *type, const gd
*** 366,371 ****
--- 366,372 ----
    struct type *elttype;
    LONGEST val;
    CORE_ADDR addr;
+   int index;
  
    CHECK_TYPEDEF (type);
    switch (TYPE_CODE (type))
*************** f_val_print (struct type *type, const gd
*** 576,581 ****
--- 577,598 ----
        fprintf_filtered (stream, "<incomplete type>");
        break;
  
+     case TYPE_CODE_STRUCT:
+       /* Starting from the Fortran 90 standard, Fortran supports derived
+          types.  */
+       fprintf_filtered (stream, "{ ");
+       for (index = 0; index < TYPE_NFIELDS (type); index++)
+         {
+           char * field_addr = valaddr + TYPE_FIELD_BITPOS (type, index) / 8;
+           f_val_print (TYPE_FIELD_TYPE (type, index), field_addr,
+                        embedded_offset, address, stream,
+                        format, deref_ref, recurse, pretty);
+           if (index != TYPE_NFIELDS (type) - 1)
+             fputs_filtered (", ", stream);
+         }
+       fprintf_filtered (stream, "}");
+       break;     
+ 
      default:
        error (_("Invalid F77 type code %d in symbol table."), TYPE_CODE (type));
      }
Index: f-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-typeprint.c,v
retrieving revision 1.13
diff -c -p -r1.13 f-typeprint.c
*** f-typeprint.c	11 Feb 2005 04:05:47 -0000	1.13
--- f-typeprint.c	10 Dec 2005 06:50:50 -0000
***************
*** 1,7 ****
  /* Support for printing Fortran types for GDB, the GNU debugger.
  
     Copyright 1986, 1988, 1989, 1991, 1993, 1994, 1995, 1996, 1998,
!    2000, 2001, 2002, 2003 Free Software Foundation, Inc.
  
     Contributed by Motorola.  Adapted from the C version by Farooq Butt
     (fmbutt@engage.sps.mot.com).
--- 1,7 ----
  /* Support for printing Fortran types for GDB, the GNU debugger.
  
     Copyright 1986, 1988, 1989, 1991, 1993, 1994, 1995, 1996, 1998,
!    2000, 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
  
     Contributed by Motorola.  Adapted from the C version by Farooq Butt
     (fmbutt@engage.sps.mot.com).
***************
*** 41,47 ****
  static void f_type_print_args (struct type *, struct ui_file *);
  #endif
  
! static void print_equivalent_f77_float_type (struct type *,
  					     struct ui_file *);
  
  static void f_type_print_varspec_suffix (struct type *, struct ui_file *,
--- 41,47 ----
  static void f_type_print_args (struct type *, struct ui_file *);
  #endif
  
! static void print_equivalent_f77_float_type (int level, struct type *,
  					     struct ui_file *);
  
  static void f_type_print_varspec_suffix (struct type *, struct ui_file *,
*************** f_type_print_varspec_suffix (struct type
*** 260,272 ****
  }
  
  static void
! print_equivalent_f77_float_type (struct type *type, struct ui_file *stream)
  {
    /* Override type name "float" and make it the
       appropriate real. XLC stupidly outputs -12 as a type
       for real when it really should be outputting -18 */
  
!   fprintf_filtered (stream, "real*%d", TYPE_LENGTH (type));
  }
  
  /* Print the name of the type (or the ultimate pointer target,
--- 260,273 ----
  }
  
  static void
! print_equivalent_f77_float_type (int level, struct type *type,
! 				 struct ui_file *stream)
  {
    /* Override type name "float" and make it the
       appropriate real. XLC stupidly outputs -12 as a type
       for real when it really should be outputting -18 */
  
!   fprintfi_filtered (level, stream, "real*%d", TYPE_LENGTH (type));
  }
  
  /* Print the name of the type (or the ultimate pointer target,
*************** f_type_print_base (struct type *type, st
*** 289,294 ****
--- 290,297 ----
    int retcode;
    int upper_bound;
  
+   int index;
+ 
    QUIT;
  
    wrap_here ("    ");
*************** f_type_print_base (struct type *type, st
*** 304,310 ****
    if ((show <= 0) && (TYPE_NAME (type) != NULL))
      {
        if (TYPE_CODE (type) == TYPE_CODE_FLT)
! 	print_equivalent_f77_float_type (type, stream);
        else
  	fputs_filtered (TYPE_NAME (type), stream);
        return;
--- 307,313 ----
    if ((show <= 0) && (TYPE_NAME (type) != NULL))
      {
        if (TYPE_CODE (type) == TYPE_CODE_FLT)
! 	print_equivalent_f77_float_type (level, type, stream);
        else
  	fputs_filtered (TYPE_NAME (type), stream);
        return;
*************** f_type_print_base (struct type *type, st
*** 335,359 ****
        break;
  
      case TYPE_CODE_VOID:
!       fprintf_filtered (stream, "VOID");
        break;
  
      case TYPE_CODE_UNDEF:
!       fprintf_filtered (stream, "struct <unknown>");
        break;
  
      case TYPE_CODE_ERROR:
!       fprintf_filtered (stream, "<unknown type>");
        break;
  
      case TYPE_CODE_RANGE:
        /* This should not occur */
!       fprintf_filtered (stream, "<range type>");
        break;
  
      case TYPE_CODE_CHAR:
        /* Override name "char" and make it "character" */
!       fprintf_filtered (stream, "character");
        break;
  
      case TYPE_CODE_INT:
--- 338,362 ----
        break;
  
      case TYPE_CODE_VOID:
!       fprintfi_filtered (level, stream, "VOID");
        break;
  
      case TYPE_CODE_UNDEF:
!       fprintfi_filtered (level, stream, "struct <unknown>");
        break;
  
      case TYPE_CODE_ERROR:
!       fprintfi_filtered (level, stream, "<unknown type>");
        break;
  
      case TYPE_CODE_RANGE:
        /* This should not occur */
!       fprintfi_filtered (level, stream, "<range type>");
        break;
  
      case TYPE_CODE_CHAR:
        /* Override name "char" and make it "character" */
!       fprintfi_filtered (level, stream, "character");
        break;
  
      case TYPE_CODE_INT:
*************** f_type_print_base (struct type *type, st
*** 362,385 ****
           C-oriented, we must change these to "character" from "char".  */
  
        if (strcmp (TYPE_NAME (type), "char") == 0)
! 	fprintf_filtered (stream, "character");
        else
  	goto default_case;
        break;
  
      case TYPE_CODE_COMPLEX:
!       fprintf_filtered (stream, "complex*%d", TYPE_LENGTH (type));
        break;
  
      case TYPE_CODE_FLT:
!       print_equivalent_f77_float_type (type, stream);
        break;
  
      case TYPE_CODE_STRING:
        /* Strings may have dynamic upperbounds (lengths) like arrays. */
  
        if (TYPE_ARRAY_UPPER_BOUND_TYPE (type) == BOUND_CANNOT_BE_DETERMINED)
! 	fprintf_filtered (stream, "character*(*)");
        else
  	{
  	  retcode = f77_get_dynamic_upperbound (type, &upper_bound);
--- 365,388 ----
           C-oriented, we must change these to "character" from "char".  */
  
        if (strcmp (TYPE_NAME (type), "char") == 0)
! 	fprintfi_filtered (level, stream, "character");
        else
  	goto default_case;
        break;
  
      case TYPE_CODE_COMPLEX:
!       fprintfi_filtered (level, stream, "complex*%d", TYPE_LENGTH (type));
        break;
  
      case TYPE_CODE_FLT:
!       print_equivalent_f77_float_type (level, type, stream);
        break;
  
      case TYPE_CODE_STRING:
        /* Strings may have dynamic upperbounds (lengths) like arrays. */
  
        if (TYPE_ARRAY_UPPER_BOUND_TYPE (type) == BOUND_CANNOT_BE_DETERMINED)
! 	fprintfi_filtered (level, stream, "character*(*)");
        else
  	{
  	  retcode = f77_get_dynamic_upperbound (type, &upper_bound);
*************** f_type_print_base (struct type *type, st
*** 391,396 ****
--- 394,414 ----
  	}
        break;
  
+     case TYPE_CODE_STRUCT:
+       fprintfi_filtered (level, stream, "Type ");
+       fputs_filtered (TYPE_TAG_NAME (type), stream);
+       fputs_filtered ("\n", stream);
+       for (index = 0; index < TYPE_NFIELDS (type); index++)
+ 	{
+ 	  f_print_type (TYPE_FIELD_TYPE (type, index), "", stream, show, level + 4);
+ 	  fputs_filtered (" :: ", stream);
+ 	  fputs_filtered (TYPE_FIELD_NAME (type, index), stream);
+ 	  fputs_filtered ("\n", stream);
+ 	} 
+       fprintfi_filtered (level, stream, "End Type ");
+       fputs_filtered (TYPE_TAG_NAME (type), stream);
+       break;
+ 
      default_case:
      default:
        /* Handle types not explicitly handled by the other cases,
*************** f_type_print_base (struct type *type, st
*** 398,404 ****
           the type name is, as recorded in the type itself.  If there
           is no type name, then complain. */
        if (TYPE_NAME (type) != NULL)
! 	fputs_filtered (TYPE_NAME (type), stream);
        else
  	error (_("Invalid type code (%d) in symbol table."), TYPE_CODE (type));
        break;
--- 416,422 ----
           the type name is, as recorded in the type itself.  If there
           is no type name, then complain. */
        if (TYPE_NAME (type) != NULL)
! 	fprintfi_filtered (level, stream, "%s ", TYPE_NAME (type));
        else
  	error (_("Invalid type code (%d) in symbol table."), TYPE_CODE (type));
        break;

2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>

	* gdb.fortran/derived-type.f90: New file.
	* .fortran/derived-type.exp: New testcase.

Index: gdb.fortran/derived-type.f90
===================================================================
RCS file: gdb.fortran/derived-type.f90
diff -N gdb.fortran/derived-type.f90
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.fortran/derived-type.f90	16 Nov 2005 06:50:22 -0000
@@ -0,0 +1,22 @@
+program main
+
+  type bar
+    integer :: c
+    real :: d
+  end type
+  type foo
+    real :: a
+    type(bar) :: x
+    character*7 :: b 
+  end type foo
+  type(foo) :: q
+  type(bar) :: p
+
+  p = bar(1, 2.375)
+  q%a = 3.125
+  q%b = "abcdefg"
+  q%x%c = 1
+  q%x%d = 2.375
+  print *,p,q 
+
+end program main
Index: gdb.fortran/derived-type.exp
===================================================================
RCS file: gdb.fortran/derived-type.exp
diff -N gdb.fortran/derived-type.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.fortran/derived-type.exp	16 Nov 2005 06:50:22 -0000
@@ -0,0 +1,65 @@
+# Copyright 2005 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# This file was written by Wu Zhou. (woodzltc@cn.ibm.com)
+
+# This file is part of the gdb testsuite.  It contains tests for type-printing
+# and value-printing Fortran derived types.
+
+if $tracelevel then {
+	strace $tracelevel
+}
+
+set testfile "derived-type"
+set srcfile ${testfile}.f90
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug f77 quiet}] != "" } {
+    untested "Couldn't compile ${srcfile}"
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+if ![runto MAIN__] then {
+    perror "couldn't run to breakpoint MAIN__"
+    continue
+}
+
+gdb_test "ptype p" \
+    "type = Type bar.*int4.*\:\: c.*real.*\:\: d.*End Type bar" \
+    "ptype p"
+gdb_test "ptype q" \
+    "type = Type foo.*real.*\:\: a.*Type bar.*int4.*\:\: c.*real.*\:\: d.*End Type bar \:\: x.*character.*\\(7\\) \:\: b.*End Type foo" \
+    "type-printing for derived type"
+
+gdb_breakpoint [gdb_get_line_number "print"]
+gdb_continue_to_breakpoint "print"
+
+gdb_test "print p" "\\$\[0-9\]+ = \\{ 1, 2.375\\}"
+gdb_test "print p%c" "\\$\[0-9\]+ = 1"
+gdb_test "print p%d" "\\$\[0-9\]+ = 2.375"
+gdb_test "print q%a" "\\$\[0-9\]+ = 3.125"
+gdb_test "print q%b" "\\$\[0-9\]+ = \\(.*a.*b.*c.*d.*e.*f.*g.*\\)"
+gdb_test "print q%x%c" "\\$\[0-9\]+ = 1"
+gdb_test "print q%x%d" "\\$\[0-9\]+ = 2.375"
+gdb_test "print q" \
+    "\\$\[0-9\]+ = \\{ 3.125, \\{ 1, 2.375\\}, \\(.*a.*b.*c.*d.*e.*f.*g.*\\)\\}" \
+    "print q"
+

2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>

	* gdb.texinfo (Fortran): Document the "%" operator for member
	access.
	(Fortran): 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.282.2.4
diff -c -p -r1.282.2.4 gdb.texinfo
*** gdb.texinfo	23 Nov 2005 02:35:06 -0000	1.282.2.4
--- gdb.texinfo	10 Dec 2005 06:49:36 -0000
*************** of the second one.
*** 9157,9162 ****
--- 9157,9166 ----
  @item :
  The range operator.  Normally used in the form of array(low:high) to
  represent a section of array.
+ 
+ @item %
+ ortran 90 and afterwards 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
*** 9185,9190 ****
--- 9189,9263 ----
  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 afterwards support derived type (a.k.a structure).  For
+ a variable of derived type, 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
+ 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
+ 
+ @noindent
+ 
+ @cindex Structure value-print
+ @item print @var{derived-type}
+ For a variable of derived type, 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
+ 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
+ 
+ @noindent
+ 
  @end table
  
  @node Pascal


Regards
- Wu Zhou

Re: [RFC]: Patch to support Fortran derived type - Revised

[Eli Zaretskii]

> Date: Sat, 10 Dec 2005 15:24:29 +0800 (CST)
> From: Wu Zhou <woodzltc@cn.ibm.com>
> cc: gdb-patches@sources.redhat.com, Thomas.Koenig@online.de
> 
> Here is the revised patch, testcase and documents.

Thanks.  My comments about the documentation patch are below.

> 2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>
> 
> 	* gdb.texinfo (Fortran): Document the "%" operator for member
> 	access.
> 	(Fortran): Document the type-print and value-print operation of
> 	Fortran 90 derived types.

These two entries reference the same node "Fortran", so there's no
need to mention the node twice.  Just write the two sentences one
after the other; you don't even need a newline between them.

> + @item %
> + ortran 90 and afterwards use this to access the members of derived
    ^^^^^^
A typo.

Also, I'd prefer "and later" instead of "and afterwards".

> + @cindex Structure type-print

Index entries by convention should begin with a lower-case letter.

> + Fortran 90 and afterwards support derived type (a.k.a structure).  For
               ^^^^^^^^^^^^^^
"and later"

> + a variable of derived type, ptype command will output all its members,
                                ^^^^^
Please give each command the @code markup: @code{ptype}.  Actually,
"the @code{ptype} command" is more correct English, I think.

> + @noindent
> + ptype commands give this output:
    ^^^^^^^^^^^^^^
"the @code{ptype} commands"

> + @end smallexample
> + 
> + @noindent
> + 

This @noindent looks unnecessary to me.  Why did you add it?

> + @cindex Structure value-print

Again, please begin all index entries with a lower-case letter.

> + @item print @var{derived-type}
> + For a variable of derived type, print command will output the value of
                                    ^^^^^^^^^^^^^
"the @code{print} command"

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

`q' and `foo' are Fortran symbols, so both of them should have the
@code markup: "for a variable @code{q} of type @code{foo} defined above".

> + @noindent
> + print command will output this:
    ^^^^^^^^^^^^^
"the @code{print} command"

> + $1 = @{ 3.125, @{ 1, 2.375@}, (97 'a', 98 'b', 99 'c', 100 'd', 101 'e', 102 'f', 103 'g')@}

This is too long for a single line (TeX will not break lines inside
@smallexample).  Please break it into 2 lines, and please add text
saying that it's a single long line, broken only for clarity.

Re: [RFC]: Patch to support Fortran derived type - Revised

[Daniel Jacobowitz]

On Sat, Dec 10, 2005 at 03:24:29PM +0800, Wu Zhou wrote:
> > > +name	:	NAME
> > > +		{  $$ = $1.stoken; }
> > > +	;
> > > +
> > 
> > Why not just use name_not_typename instead of adding "name"?
> > 
> > Also, the comments in name_not_typename don't apply here; you could
> > also handle exp : exp % NAME_OR_INT as a name.  But, I don't think that
> > adds much value.  The whole NAME_OR_INT thing seems like overkill.
> 
> AFAICT, adding "name" might be a more direct and easier way to handle 
> that. I am not sure yet how to handle name_not_typename or NAME_OR_INT, 
> but it seems that some more work is needed in either the parsing or 
> evaluation phase.  What is more, using "name" is the same way as that in
> c and c++ expression parser, which looks to be more consistent. 
> 
> Does these make sense?

I suppose.

> 2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>
> 
> 	* gdb.fortran/derived-type.f90: New file.
> 	* .fortran/derived-type.exp: New testcase.

Typo there.

> +++ gdb.fortran/derived-type.f90	16 Nov 2005 06:50:22 -0000
> @@ -0,0 +1,22 @@
> +program main

Please add a copyright notice to all new tests.

Otherwise the code and testcase look fine; Eli had some additional
comments on the texinfo bits.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC]: Patch to support Fortran derived type - Revised

[Wu Zhou]

On Mon, 20 Feb 2006, Daniel Jacobowitz wrote:

> On Sat, Dec 10, 2005 at 03:24:29PM +0800, Wu Zhou wrote:
> > > > +name	:	NAME
> > > > +		{  $$ = $1.stoken; }
> > > > +	;
> > > > +
> > > 
> > > Why not just use name_not_typename instead of adding "name"?
> > > 
> > > Also, the comments in name_not_typename don't apply here; you could
> > > also handle exp : exp % NAME_OR_INT as a name.  But, I don't think that
> > > adds much value.  The whole NAME_OR_INT thing seems like overkill.
> > 
> > AFAICT, adding "name" might be a more direct and easier way to handle 
> > that. I am not sure yet how to handle name_not_typename or NAME_OR_INT, 
> > but it seems that some more work is needed in either the parsing or 
> > evaluation phase.  What is more, using "name" is the same way as that in
> > c and c++ expression parser, which looks to be more consistent. 
> > 
> > Does these make sense?
> 
> I suppose.
> 
> > 2005-12-10  Wu Zhou  <woodzltc@cn.ibm.com>
> > 
> > 	* gdb.fortran/derived-type.f90: New file.
> > 	* .fortran/derived-type.exp: New testcase.
> 
> Typo there.
> 
> > +++ gdb.fortran/derived-type.f90	16 Nov 2005 06:50:22 -0000
> > @@ -0,0 +1,22 @@
> > +program main
> 
> Please add a copyright notice to all new tests.
> 
> Otherwise the code and testcase look fine; Eli had some additional
> comments on the texinfo bits.

Hi Daniel,

Thanks for the review.  I had fix the above typo and add the copyright 
notice to gdb.fortran/derived-type.f90 and committed them into the CVS.

For the document patch, I will resend a modified version for review.

Here is what I checked in:

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

	* f-exp.y: Symbol '%' is not used as the modulus operator in
	Fortran.  Delete this from Fortran expression.
	It is now used by Fortran 90 and later to access the member
	of derived type.  Add this into Fortran expression.
	* f-valprint.c (f_val_print): Add code to handle TYPE_CODE_STRUCT.
	Print each elements in the derived type.
	* f-typeprint.c (print_equivalent_f77_float_type): Add a parameter
	level into the function definition to do indented printing.  And
	call fprintfi_filtered instead to do indented printing.
	(f_type_print_base): Replace fprintf_filtered with the indented
	version (fprintfi_filtered).
	(f_type_print_base): Call indented print_equivalent_f77_float_type.
	(f_type_print_base): Add code to handle TYPE_CODE_STRUCT.  Print
	the definition of the derived type.

Index: f-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/f-exp.y,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- src/gdb/f-exp.y	2005/12/17 22:33:59	1.19
+++ src/gdb/f-exp.y	2006/02/24 07:26:10	1.20
@@ -1,6 +1,6 @@
 /* YACC parser for Fortran expressions, for GDB.
    Copyright (C) 1986, 1989, 1990, 1991, 1993, 1994, 1995, 1996, 2000, 
2001,
-   2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+   2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
 
    Contributed by Motorola.  Adapted from the C parser by Farooq Butt
    (fmbutt@engage.sps.mot.com).
@@ -178,6 +178,7 @@
 %token <lval> BOOLEAN_LITERAL
 %token <ssym> NAME 
 %token <tsym> TYPENAME
+%type <sval> name
 %type <ssym> name_not_typename
 
 /* A NAME_OR_INT is a symbol which is not known in the symbol table,
@@ -217,8 +218,9 @@
 %left LSH RSH
 %left '@'
 %left '+' '-'
-%left '*' '/' '%'
+%left '*' '/'
 %right STARSTAR
+%right '%'
 %right UNARY 
 %right '('
 
@@ -332,6 +334,12 @@
 			  write_exp_elt_opcode (UNOP_CAST); }
 	;
 
+exp     :       exp '%' name
+                        { write_exp_elt_opcode (STRUCTOP_STRUCT);
+                          write_exp_string ($3);
+                          write_exp_elt_opcode (STRUCTOP_STRUCT); }
+        ;
+
 /* Binary operators in order of decreasing precedence.  */
 
 exp	:	exp '@' exp
@@ -350,10 +358,6 @@
 			{ write_exp_elt_opcode (BINOP_DIV); }
 	;
 
-exp	:	exp '%' exp
-			{ write_exp_elt_opcode (BINOP_REM); }
-	;
-
 exp	:	exp '+' exp
 			{ write_exp_elt_opcode (BINOP_ADD); }
 	;
@@ -635,6 +639,10 @@
 		}
 	;
 
+name	:	NAME
+		{  $$ = $1.stoken; }
+	;
+
 name_not_typename :	NAME
 /* These would be useful if name_not_typename was useful, but it is just
    a fake for "variable", so these cause reduce/reduce conflicts because
Index: f-valprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-valprint.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- src/gdb/f-valprint.c	2006/01/18 21:24:19	1.32
+++ src/gdb/f-valprint.c	2006/02/24 07:26:10	1.33
@@ -366,6 +366,7 @@
   struct type *elttype;
   LONGEST val;
   CORE_ADDR addr;
+  int index;
 
   CHECK_TYPEDEF (type);
   switch (TYPE_CODE (type))
@@ -583,6 +584,22 @@
       fprintf_filtered (stream, "<incomplete type>");
       break;
 
+    case TYPE_CODE_STRUCT:
+      /* Starting from the Fortran 90 standard, Fortran supports derived
+         types.  */
+      fprintf_filtered (stream, "{ ");
+      for (index = 0; index < TYPE_NFIELDS (type); index++)
+        {
+          int offset = TYPE_FIELD_BITPOS (type, index) / 8;
+          f_val_print (TYPE_FIELD_TYPE (type, index), valaddr + offset,
+                       embedded_offset, address, stream,
+                       format, deref_ref, recurse, pretty);
+          if (index != TYPE_NFIELDS (type) - 1)
+            fputs_filtered (", ", stream);
+        }
+      fprintf_filtered (stream, "}");
+      break;     
+
     default:
       error (_("Invalid F77 type code %d in symbol table."), TYPE_CODE 
(type));
     }
Index: f-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/f-typeprint.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- src/gdb/f-typeprint.c	2005/12/17 22:33:59	1.14
+++ src/gdb/f-typeprint.c	2006/02/24 07:26:10	1.15
@@ -1,7 +1,7 @@
 /* Support for printing Fortran types for GDB, the GNU debugger.
 
    Copyright (C) 1986, 1988, 1989, 1991, 1993, 1994, 1995, 1996, 1998,
-   2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+   2000, 2001, 2002, 2003, 2006 Free Software Foundation, Inc.
 
    Contributed by Motorola.  Adapted from the C version by Farooq Butt
    (fmbutt@engage.sps.mot.com).
@@ -41,7 +41,7 @@
 static void f_type_print_args (struct type *, struct ui_file *);
 #endif
 
-static void print_equivalent_f77_float_type (struct type *,
+static void print_equivalent_f77_float_type (int level, struct type *,
 					     struct ui_file *);
 
 static void f_type_print_varspec_suffix (struct type *, struct ui_file *,
@@ -260,13 +260,14 @@
 }
 
 static void
-print_equivalent_f77_float_type (struct type *type, struct ui_file *stream)
+print_equivalent_f77_float_type (int level, struct type *type,
+				 struct ui_file *stream)
 {
   /* Override type name "float" and make it the
      appropriate real. XLC stupidly outputs -12 as a type
      for real when it really should be outputting -18 */
 
-  fprintf_filtered (stream, "real*%d", TYPE_LENGTH (type));
+  fprintfi_filtered (level, stream, "real*%d", TYPE_LENGTH (type));
 }
 
 /* Print the name of the type (or the ultimate pointer target,
@@ -289,6 +290,8 @@
   int retcode;
   int upper_bound;
 
+  int index;
+
   QUIT;
 
   wrap_here ("    ");
@@ -304,7 +307,7 @@
   if ((show <= 0) && (TYPE_NAME (type) != NULL))
     {
       if (TYPE_CODE (type) == TYPE_CODE_FLT)
-	print_equivalent_f77_float_type (type, stream);
+	print_equivalent_f77_float_type (level, type, stream);
       else
 	fputs_filtered (TYPE_NAME (type), stream);
       return;
@@ -335,25 +338,25 @@
       break;
 
     case TYPE_CODE_VOID:
-      fprintf_filtered (stream, "VOID");
+      fprintfi_filtered (level, stream, "VOID");
       break;
 
     case TYPE_CODE_UNDEF:
-      fprintf_filtered (stream, "struct <unknown>");
+      fprintfi_filtered (level, stream, "struct <unknown>");
       break;
 
     case TYPE_CODE_ERROR:
-      fprintf_filtered (stream, "<unknown type>");
+      fprintfi_filtered (level, stream, "<unknown type>");
       break;
 
     case TYPE_CODE_RANGE:
       /* This should not occur */
-      fprintf_filtered (stream, "<range type>");
+      fprintfi_filtered (level, stream, "<range type>");
       break;
 
     case TYPE_CODE_CHAR:
       /* Override name "char" and make it "character" */
-      fprintf_filtered (stream, "character");
+      fprintfi_filtered (level, stream, "character");
       break;
 
     case TYPE_CODE_INT:
@@ -362,24 +365,24 @@
          C-oriented, we must change these to "character" from "char".  */
 
       if (strcmp (TYPE_NAME (type), "char") == 0)
-	fprintf_filtered (stream, "character");
+	fprintfi_filtered (level, stream, "character");
       else
 	goto default_case;
       break;
 
     case TYPE_CODE_COMPLEX:
-      fprintf_filtered (stream, "complex*%d", TYPE_LENGTH (type));
+      fprintfi_filtered (level, stream, "complex*%d", TYPE_LENGTH (type));
       break;
 
     case TYPE_CODE_FLT:
-      print_equivalent_f77_float_type (type, stream);
+      print_equivalent_f77_float_type (level, type, stream);
       break;
 
     case TYPE_CODE_STRING:
       /* Strings may have dynamic upperbounds (lengths) like arrays. */
 
       if (TYPE_ARRAY_UPPER_BOUND_TYPE (type) == BOUND_CANNOT_BE_DETERMINED)
-	fprintf_filtered (stream, "character*(*)");
+	fprintfi_filtered (level, stream, "character*(*)");
       else
 	{
 	  retcode = f77_get_dynamic_upperbound (type, &upper_bound);
@@ -391,6 +394,21 @@
 	}
       break;
 
+    case TYPE_CODE_STRUCT:
+      fprintfi_filtered (level, stream, "Type ");
+      fputs_filtered (TYPE_TAG_NAME (type), stream);
+      fputs_filtered ("\n", stream);
+      for (index = 0; index < TYPE_NFIELDS (type); index++)
+	{
+	  f_print_type (TYPE_FIELD_TYPE (type, index), "", stream, show, level + 4);
+	  fputs_filtered (" :: ", stream);
+	  fputs_filtered (TYPE_FIELD_NAME (type, index), stream);
+	  fputs_filtered ("\n", stream);
+	} 
+      fprintfi_filtered (level, stream, "End Type ");
+      fputs_filtered (TYPE_TAG_NAME (type), stream);
+      break;
+
     default_case:
     default:
       /* Handle types not explicitly handled by the other cases,
@@ -398,7 +416,7 @@
          the type name is, as recorded in the type itself.  If there
          is no type name, then complain. */
       if (TYPE_NAME (type) != NULL)
-	fputs_filtered (TYPE_NAME (type), stream);
+	fprintfi_filtered (level, stream, "%s ", TYPE_NAME (type));
       else
 	error (_("Invalid type code (%d) in symbol table."), TYPE_CODE 
(type));
       break;




Regards
- Wu Zhou