public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [patch, fortran] Optionally improve debugging of auxiliary variables
@ 2020-12-12 18:59 Thomas Koenig
  2020-12-13 12:21 ` Iain Sandoe
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Koenig @ 2020-12-12 18:59 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 3081 bytes --]

Hello world,

I have struggled with debugging the GENERIC generated by the
Fortran front end because it is only possible to look at the
code via -fdump-tree-original, but it is not possible to
inspect the values; additionally, the D.3456 form makes it
hard to read which variable is which.

This patch adds a flag which gives all variables generated by
Fortran a name and makes them visible to debuggers. As an
example, compiler-generated variables now look like this
(for a "Hello, world" program):

   {
     struct __st_parameter_dt dt_parm:0;

     dt_parm:0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
     dt_parm:0.common.line = 2;
     dt_parm:0.common.flags = 128;
     dt_parm:0.common.unit = 6;
     _gfortran_st_write (&dt_parm:0);
     _gfortran_transfer_character_write (&dt_parm:0, &"Hello, 
world"[1]{lb: 1 sz: 1}, 12);
     _gfortran_st_write_done (&dt_parm:0);
   }

Note the colon in the variable name, which I chose because it is
not in the user's namespace, and gdb does not choke on it.
In order to inspect the variables, you usually have to step
a bit through the generated assembly code, but you can then
print the values, manipulate them etc (and sometimes also hit
an internal error in gdb).

Example of a debugging session:

(gdb) b _gfortran_st_write
Breakpoint 1 at 0x4005f0
(gdb) r
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, _gfortran_st_write (dtp=0x7fffffffd9f0) at 
../../../coarray_native/libgfortran/io/transfer.c:4398
4398    {
(gdb) fin
Run till exit from #0  _gfortran_st_write (dtp=0x7fffffffd9f0) at 
../../../coarray_native/libgfortran/io/transfer.c:4398
0x0000000000400719 in MAIN__ () at hello.f90:2
2         print *,"Hello, world"
(gdb) info local
dt_parm:0 = ( common = ( flags = 128, unit = 6, filename = 0x400810, 
line = 2, iomsg_len = 0, iomsg = 0x0, iostat = 0x0 ), rec = 0, size = 
0x0, iolength = 0x0, internal_unit_desc = 0x0, format = 0x0, format_len 
= 0, advance_len = 0, advance = 0x0, internal_unit = 0x0, 
internal_unit_len = 0, namelist_name_len = 0, namelist_name = 0x0, id = 
0x2, pos = -9223372036854775802, asynchronous = 0x0, asynchronous_len = 
4569374499253603072, blank_len = 0, blank = 0x3f69ade5c1bd4b00, decimal 
= 0x7ffff79490f0 <_gfortrani_backtrace_handler>, decimal_len = 
140737335317407, delim_len = 140737347096816, delim = 0x1000000, pad = 
0x0, pad_len = 0, round_len = 0, round = 0x0, sign = 0x0, sign_len = 0, 
u = 
'`&\270\367\377\177\000\000\060H`\000\000\000\000\000\000\000\000\000\001', 
'\000' <repeats 35 times>, '\002', '\000' <repeats 71 times>, 
'\377\377\377\377\377\377\377\377', '\000' <repeats 81 times>... )
(gdb) p dt_parm:0%common
$1 = ( flags = 128, unit = 6, filename = 0x400810, line = 2, iomsg_len = 
0, iomsg = 0x0, iostat = 0x0 )
(gdb) p dt_parm:0%common%filename
$2 = (PTR TO -> ( character(kind=1) )) 0x400810

There is no user impact (only developers will use this), so it is not
surprising that there is no regression. So, OK for trunk?

Best regards

	Thomas

[-- Attachment #2: p2.diff --]
[-- Type: text/x-patch, Size: 2745 bytes --]

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 8bdc8a6b038..58e4e50b315 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1227,6 +1227,17 @@ compiler itself. The output generated by this option might change
 between releases.  This option may also generate internal compiler
 errors for features which have only recently been added.
 
+@item -fdebug-aux-vars
+@opindex @code{debug-aux-vars}
+Make internal variables generated by the gfortran front end visible to a
+debugger.  This option also renames these internal variables shown by
+@code{-fdump-tree-original} to a form @code{string:number} and enables
+compiler warnings on them.
+
+This option is only really useful when debugging the gfortran compiler
+itself together with @code{-g} or @code{-ggdb3} and
+@code{-fdump-tree-original}.
+
 @item -ffpe-trap=@var{list}
 @opindex @code{ffpe-trap=}@var{list}
 Specify a list of floating point exception traps to enable.  On most
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 96ed208cb85..57b0264458e 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -452,6 +452,10 @@ fd-lines-as-comments
 Fortran RejectNegative
 Treat lines with 'D' in column one as comments.
 
+fdebug-aux-vars
+Fortran Var(flag_debug_aux_vars)
+Issue debug information for compiler-generated auxiliary variables.
+
 fdec
 Fortran Var(flag_dec)
 Enable all DEC language extensions.
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 025abe38985..1d5f6c28c7a 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -73,6 +73,40 @@ gfc_advance_chain (tree t, int n)
   return t;
 }
 
+static int num_var;
+
+#define MAX_PREFIX_LEN 20
+
+static tree
+create_var_debug_raw (tree type, const char *prefix)
+{
+  /* Space for prefix + @ + 9-digit-number + \0.  */
+  char name_buf[MAX_PREFIX_LEN + 1 + 9 + 1];
+  tree t;
+
+  if (prefix == NULL)
+    prefix = "gfc";
+  else
+    gcc_assert (strlen(prefix) <= MAX_PREFIX_LEN);
+
+  snprintf (name_buf, sizeof(name_buf), "%s:%d", prefix, num_var++);
+  t = build_decl (input_location, VAR_DECL, get_identifier (name_buf), type);
+
+  /* We want debug info for it.  */
+  DECL_IGNORED_P (t) = 0;
+  /* It should not be nameless.  */
+  DECL_NAMELESS (t) = 0;
+
+  /* Make the variable writable.  */
+  TREE_READONLY (t) = 0;
+
+  DECL_EXTERNAL (t) = 0;
+  TREE_STATIC (t) = 0;
+  TREE_USED (t) = 1;
+
+  return t;
+}
+
 /* Creates a variable declaration with a given TYPE.  */
 
 tree
@@ -80,6 +114,9 @@ gfc_create_var_np (tree type, const char *prefix)
 {
   tree t;
 
+  if (flag_debug_aux_vars)
+    return create_var_debug_raw (type, prefix);
+
   t = create_tmp_var_raw (type, prefix);
 
   /* No warnings for anonymous variables.  */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-12 18:59 [patch, fortran] Optionally improve debugging of auxiliary variables Thomas Koenig
@ 2020-12-13 12:21 ` Iain Sandoe
  2020-12-13 14:20   ` Thomas Koenig
  0 siblings, 1 reply; 9+ messages in thread
From: Iain Sandoe @ 2020-12-13 12:21 UTC (permalink / raw)
  To: Thomas Koenig; +Cc: Fortran List, gcc-patches

Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:

> Hello world,
>
> I have struggled with debugging the GENERIC generated by the
> Fortran front end because it is only possible to look at the
> code via -fdump-tree-original, but it is not possible to
> inspect the values; additionally, the D.3456 form makes it
> hard to read which variable is which.
>
> This patch adds a flag which gives all variables generated by
> Fortran a name and makes them visible to debuggers. As an
> example, compiler-generated variables now look like this
> (for a "Hello, world" program):
>
>  {
>    struct __st_parameter_dt dt_parm:0;
>
>    dt_parm:0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
>    dt_parm:0.common.line = 2;
>    dt_parm:0.common.flags = 128;
>    dt_parm:0.common.unit = 6;
>    _gfortran_st_write (&dt_parm:0);
>    _gfortran_transfer_character_write (&dt_parm:0, &"Hello, world"[1]{lb: 1 sz: 1}, 12);
>    _gfortran_st_write_done (&dt_parm:0);
>  }
>
> Note the colon in the variable name, which I chose because it is
> not in the user's namespace, and gdb does not choke on it.

If it’s part of a symbol used by the rest of the toolchain (assembler, linker
debugger) then it’s also important to note that some OS/tool pairs might
be more constrained than the one you’ve tested.  In particular, some
assemblers will not accept all characters in an  identifier.

> In order to inspect the variables, you usually have to step
> a bit through the generated assembly code, but you can then
> print the values, manipulate them etc (and sometimes also hit
> an internal error in gdb).

> --- a/gcc/fortran/trans.c
> +++ b/gcc/fortran/trans.c
> @@ -73,6 +73,40 @@ gfc_advance_chain (tree t, int n)
>    return t;

> +  /* We want debug info for it.  */
> +  DECL_IGNORED_P (t) = 0;
> +  /* It should not be nameless.  */
> +  DECL_NAMELESS (t) = 0;


>  tree
> @@ -80,6 +114,9 @@ gfc_create_var_np (tree type, const char *prefix)
>  {
>    tree t;
>
> +  if (flag_debug_aux_vars)
> +    return create_var_debug_raw (type, prefix);
> +
>    t = create_tmp_var_raw (type, prefix);
>

You could take advantage of the understanding of assembler identifier rules
built into create_var_debug_raw()

.. perhaps (totally untested)….

if (flag_debug_aux_vars)
   prefix = prefix ? prefix :  “gfc”;

t = create_tmp_var_raw (type, prefix);
if (flag_debug_aux_vars)
   {
      /* We want debug info for it.  */
     DECL_IGNORED_P (t) = false;
     /* It should not be nameless.  */
     DECL_NAMELESS (t) = false;
   }

  return t;


… or doens’t this approach work for some reason?
cheers
Iain



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 12:21 ` Iain Sandoe
@ 2020-12-13 14:20   ` Thomas Koenig
  2020-12-13 14:29     ` Iain Sandoe
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Koenig @ 2020-12-13 14:20 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: Fortran List, gcc-patches


Hi Iain,


> If it’s part of a symbol used by the rest of the toolchain (assembler, 
> linker
> debugger) then it’s also important to note that some OS/tool pairs might
> be more constrained than the one you’ve tested.  In particular, some
> assemblers will not accept all characters in an  identifier.

That is, of course, true.  What I have works for the usual Linux
toolchain.  Since I do not have access to other systems where
I can compile gcc (see the recent *BSD desaster when I tried this),
the most I could do is to make the character configurable - use
: by default, use something else if specified.


> You could take advantage of the understanding of assembler identifier rules
> built into create_var_debug_raw()
> 
> .. perhaps (totally untested)….
> 
> if (flag_debug_aux_vars)
>    prefix = prefix ? prefix :  “gfc”;
> 
> t = create_tmp_var_raw (type, prefix);
> if (flag_debug_aux_vars)
>    {
>       /* We want debug info for it.  */
>      DECL_IGNORED_P (t) = false;
>      /* It should not be nameless.  */
>      DECL_NAMELESS (t) = false;
>    }
> 
>   return t;
> 
> 
> … or doens’t this approach work for some reason?

This doesn't work for gdb because gdb searches for
a variable called "S" when trying to access "S.0".
I also tried out @ as a separation character; that
is also interpreted by gdb in a special way.

And I wanted to avoid anything in the namespace of
Fortran identifiers, even with options, so _ and $ were
out.

Do you have any other suggestions?

Best regards

	Thomas

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 14:20   ` Thomas Koenig
@ 2020-12-13 14:29     ` Iain Sandoe
  2020-12-13 14:50       ` Thomas Koenig
  0 siblings, 1 reply; 9+ messages in thread
From: Iain Sandoe @ 2020-12-13 14:29 UTC (permalink / raw)
  To: Thomas Koenig; +Cc: Fortran List, gcc-patches

Hi Thomas,

Thomas Koenig <tkoenig@netcologne.de> wrote:

>> If it’s part of a symbol used by the rest of the toolchain (assembler,  
>> linker
>> debugger) then it’s also important to note that some OS/tool pairs might
>> be more constrained than the one you’ve tested.  In particular, some
>> assemblers will not accept all characters in an  identifier.
>
> That is, of course, true.  What I have works for the usual Linux
> toolchain.  Since I do not have access to other systems where
> I can compile gcc (see the recent *BSD desaster when I tried this),
> the most I could do is to make the character configurable - use
> : by default, use something else if specified.

yes a configure option is a possible way around a conflict.

>> You could take advantage of the understanding of assembler identifier  
>> rules
>> built into create_var_debug_raw()
>> .. perhaps (totally untested)….
>> if (flag_debug_aux_vars)
>>   prefix = prefix ? prefix :  “gfc”;
>> t = create_tmp_var_raw (type, prefix);
>> if (flag_debug_aux_vars)
>>   {
>>      /* We want debug info for it.  */
>>     DECL_IGNORED_P (t) = false;
>>     /* It should not be nameless.  */
>>     DECL_NAMELESS (t) = false;
>>   }
>>  return t;
>> … or doens’t this approach work for some reason?
>
> This doesn't work for gdb because gdb searches for
> a variable called "S" when trying to access "S.0".
> I also tried out @ as a separation character; that
> is also interpreted by gdb in a special way.

and there are other debug consumers in common use - at
least lldb.

> And I wanted to avoid anything in the namespace of
> Fortran identifiers, even with options, so _ and $ were
> out.
>
> Do you have any other suggestions?

At the moment none other than the obvious..
.. test the current proposal on a wider range of systems - I expect
someone would volunteer to test on Darwin (Dominique or me)
.. you could use the cfarm for AIX, Solaris and others (I mention
AIX, Solaris and Darwin as three known to use non-GNU
assemblers and linkers).

Iain


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 14:29     ` Iain Sandoe
@ 2020-12-13 14:50       ` Thomas Koenig
  2020-12-13 15:02         ` Iain Sandoe
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Koenig @ 2020-12-13 14:50 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: Fortran List, gcc-patches


Hi Iain,

> yes a configure option is a possible way around a conflict.

I was thinking more along making it a run-time option.

This is an option which will only be used by a developer,
who should know what the source code contains and what
the tool chain supports (and who can try out an underscore
if nothing else works).

So, something along the lines of -fdebug-aux-vars=: would be
equivalent to -fdebug-aux-vars, -fdebug-aux-vars=_ should work
on any system, with the (small) risk of colliding with user code.

How does that sound?

Best regards

	Thomas

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 14:50       ` Thomas Koenig
@ 2020-12-13 15:02         ` Iain Sandoe
  2020-12-13 19:04           ` Thomas Koenig
  0 siblings, 1 reply; 9+ messages in thread
From: Iain Sandoe @ 2020-12-13 15:02 UTC (permalink / raw)
  To: Thomas Koenig; +Cc: gcc-patches, Fortran List

Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:

>> yes a configure option is a possible way around a conflict.
>
> I was thinking more along making it a run-time option.
>
> This is an option which will only be used by a developer,
> who should know what the source code contains and what
> the tool chain supports (and who can try out an underscore
> if nothing else works).

I guess the hard thing is for the developer to know that (s)he wants
the option and what to do when a conflict occurs.

> So, something along the lines of -fdebug-aux-vars=: would be
> equivalent to -fdebug-aux-vars, -fdebug-aux-vars=_ should work
> on any system, with the (small) risk of colliding with user code.

naming is ever hard - although I suppose, if this is very infrequent in
use, having a long name isn’t so terrible

maybe:

-fdebug-aux-vars-with-separator=x

and

-fdebug-aux-vars
as an alias to '-fdebug-aux-vars-with-separator=:'

(so that, unless one needs something different, the shorter version is
  available).

FAOD, this is ‘thinking aloud’ about what might make it easier to
understand; your version is equivalent other than the names.

> How does that sound?

A reasonable compromise (at this point I will defer to those folks
who are actually likely to use the facility).

cheers
Iain



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 15:02         ` Iain Sandoe
@ 2020-12-13 19:04           ` Thomas Koenig
  2020-12-13 19:59             ` Iain Sandoe
  0 siblings, 1 reply; 9+ messages in thread
From: Thomas Koenig @ 2020-12-13 19:04 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: gcc-patches, Fortran List

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]


Hi Iain,

> I guess the hard thing is for the developer to know that (s)he wants
> the option and what to do when a conflict occurs.

Actually, I just hit on a much simpler solution.

We translate all symbols to lower case (except for those
with BIND(C), which do not matter in this context).  So,
prefixing everything with GFC_ (upper case) should work on
any toolchain that can handle C, which is all we care about.

So, here is a patch which implements this method. The tree
dump now looks like this:

     struct __st_parameter_dt GFC_dt_parm_0;

     GFC_dt_parm_0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
     GFC_dt_parm_0.common.line = 2;
     GFC_dt_parm_0.common.flags = 128;
     GFC_dt_parm_0.common.unit = 6;
     _gfortran_st_write (&GFC_dt_parm_0);
     _gfortran_transfer_character_write (&GFC_dt_parm_0, &"Hello, 
world"[1]{lb: 1 sz: 1}, 12);
     _gfortran_st_write_done (&GFC_dt_parm_0);

So, thanks for raising your concerns, I like this much better now :-)

Regression-tested. Also tested with "make dvi" and "make pdf".
If there are no other comments, I'd like to commit this as having
no user impact and kind of obvious (now :-) tomorrow or so.

Best regards

	Thomas

[-- Attachment #2: p3.diff --]
[-- Type: text/x-patch, Size: 3206 bytes --]

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 8bdc8a6b038..0386818a93d 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -160,7 +160,7 @@ and warnings}.
 @item Debugging Options
 @xref{Debugging Options,,Options for debugging your program or GNU Fortran}.
 @gccoptlist{-fbacktrace -fdump-fortran-optimized -fdump-fortran-original @gol
--fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
+-fdebug-aux-vars -fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
 -ffpe-summary=@var{list}
 }
 
@@ -1219,6 +1219,15 @@ change between releases. This option may also generate internal
 compiler errors for features which have only recently been added. This
 option is deprecated; use @code{-fdump-fortran-original} instead.
 
+@item -fdebug-aux-vars
+@opindex @code{fdebug-aux-vars}
+Renames internal variables created by the gfortran front end and makes
+them accessible to a debugger.  The name of the internal variables then
+start with @code{GFC_}. This option is useful for debugging the
+compiler's code generation together with @code{-fdump-tree-original} and
+enabling debugging of the executable program by using @code{-g} or
+@code{-ggdb3}.
+
 @item -fdump-fortran-global
 @opindex @code{fdump-fortran-global}
 Output a list of the global identifiers after translating into
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 96ed208cb85..57b0264458e 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -452,6 +452,10 @@ fd-lines-as-comments
 Fortran RejectNegative
 Treat lines with 'D' in column one as comments.
 
+fdebug-aux-vars
+Fortran Var(flag_debug_aux_vars)
+Issue debug information for compiler-generated auxiliary variables.
+
 fdec
 Fortran Var(flag_dec)
 Enable all DEC language extensions.
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 025abe38985..0219115812a 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -73,6 +73,42 @@ gfc_advance_chain (tree t, int n)
   return t;
 }
 
+static int num_var;
+
+#define MAX_PREFIX_LEN 20
+
+static tree
+create_var_debug_raw (tree type, const char *prefix)
+{
+  /* Space for "GFC_" + prefix + "_" + 10-digit-number + \0.  */
+  char name_buf[4 + MAX_PREFIX_LEN + 1 + 10 + 1];
+  tree t;
+
+  if (prefix != NULL)
+    {
+      gcc_assert (strlen (prefix) <= MAX_PREFIX_LEN);
+      snprintf (name_buf, sizeof (name_buf), "GFC_%s_%d", prefix, num_var++);
+    }
+  else
+    snprintf (name_buf, sizeof (name_buf), "GFC_%d", num_var++);
+
+  t = build_decl (input_location, VAR_DECL, get_identifier (name_buf), type);
+
+  /* We want debug info for it.  */
+  DECL_IGNORED_P (t) = 0;
+  /* It should not be nameless.  */
+  DECL_NAMELESS (t) = 0;
+
+  /* Make the variable writable.  */
+  TREE_READONLY (t) = 0;
+
+  DECL_EXTERNAL (t) = 0;
+  TREE_STATIC (t) = 0;
+  TREE_USED (t) = 1;
+
+  return t;
+}
+
 /* Creates a variable declaration with a given TYPE.  */
 
 tree
@@ -80,6 +116,9 @@ gfc_create_var_np (tree type, const char *prefix)
 {
   tree t;
 
+  if (flag_debug_aux_vars)
+    return create_var_debug_raw (type, prefix);
+
   t = create_tmp_var_raw (type, prefix);
 
   /* No warnings for anonymous variables.  */

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 19:04           ` Thomas Koenig
@ 2020-12-13 19:59             ` Iain Sandoe
  2020-12-15 16:17               ` Thomas Koenig
  0 siblings, 1 reply; 9+ messages in thread
From: Iain Sandoe @ 2020-12-13 19:59 UTC (permalink / raw)
  To: Thomas Koenig; +Cc: gcc-patches, Fortran List

Hi Thomas,

Thomas Koenig via Fortran <fortran@gcc.gnu.org> wrote:

>> I guess the hard thing is for the developer to know that (s)he wants
>> the option and what to do when a conflict occurs.
>
> Actually, I just hit on a much simpler solution.

:) .. I’m all in favour of simplicity.

> We translate all symbols to lower case (except for those
> with BIND(C), which do not matter in this context).  So,
> prefixing everything with GFC_ (upper case) should work on
> any toolchain that can handle C, which is all we care about.

For bonus points you can prefix with _GFC_ which puts the symbols
in the implementation’s namespace (at least for C-Family purposes)
and therefore means that a clash with a user’s symbols is the user’s
problem …

> So, here is a patch which implements this method. The tree
> dump now looks like this:
>
>    struct __st_parameter_dt GFC_dt_parm_0;
>
>    GFC_dt_parm_0.common.filename = &"hello.f90"[1]{lb: 1 sz: 1};
>    GFC_dt_parm_0.common.line = 2;
>    GFC_dt_parm_0.common.flags = 128;
>    GFC_dt_parm_0.common.unit = 6;
>    _gfortran_st_write (&GFC_dt_parm_0);
>    _gfortran_transfer_character_write (&GFC_dt_parm_0, &"Hello, world"[1]{lb: 1 sz: 1}, 12);
>    _gfortran_st_write_done (&GFC_dt_parm_0);
>
> So, thanks for raising your concerns, I like this much better now :-)
>
> Regression-tested. Also tested with "make dvi" and "make pdf".
> If there are no other comments, I'd like to commit this as having
> no user impact and kind of obvious (now :-) tomorrow or so.
>
> Best regards
>
> 	Thomas
> <p3.diff>



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [patch, fortran] Optionally improve debugging of auxiliary variables
  2020-12-13 19:59             ` Iain Sandoe
@ 2020-12-15 16:17               ` Thomas Koenig
  0 siblings, 0 replies; 9+ messages in thread
From: Thomas Koenig @ 2020-12-15 16:17 UTC (permalink / raw)
  To: Iain Sandoe; +Cc: gcc-patches, Fortran List

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Am 13.12.20 um 20:59 schrieb Iain Sandoe via Fortran:
> For bonus points you can prefix with _GFC_ which puts the symbols
> in the implementation’s namespace (at least for C-Family purposes)
> and therefore means that a clash with a user’s symbols is the user’s
> problem …

I don't think this is necessary.  Specifying uppercase letters is
already a technical impossibility, we don't need to add convention
to it as well :-)

After reading some tree dumps, I have also now come to the conclusion
that adding GFC_ to everything makes for poor reading.  In the
version I have committed as r11-6087, I have now capitalized
all prefixes, if present, and used GFC_ otherweise.

Just one more remark: This version lets you set a watchpoint on
num_var so you can easily stop if a certain variable is generated.
That also helps :-)

Best regards, and thanks again for the comments.

	Thomas

Add the -fdebug-aux-vars flag to debug variables generated by Fortran.

gcc/fortran/ChangeLog:

	PR fortran/90207
	* invoke.texi: Document -fdebug-aux-vars.
	* lang.opt: Add -fdebug-aux-vars.
	* trans.c (MAX_PREFIX_LEN): New macro.
         (create_var_debug_raw): New function.
         (gfc_create_var_np): Call create_var_debug_raw if
         flag_debug_aux_vars is set.


[-- Attachment #2: p4.diff --]
[-- Type: text/x-patch, Size: 3255 bytes --]

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 8bdc8a6b038..069ccd339f3 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -160,7 +160,7 @@ and warnings}.
 @item Debugging Options
 @xref{Debugging Options,,Options for debugging your program or GNU Fortran}.
 @gccoptlist{-fbacktrace -fdump-fortran-optimized -fdump-fortran-original @gol
--fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
+-fdebug-aux-vars -fdump-fortran-global -fdump-parse-tree -ffpe-trap=@var{list} @gol
 -ffpe-summary=@var{list}
 }
 
@@ -1219,6 +1219,15 @@ change between releases. This option may also generate internal
 compiler errors for features which have only recently been added. This
 option is deprecated; use @code{-fdump-fortran-original} instead.
 
+@item -fdebug-aux-vars
+@opindex @code{fdebug-aux-vars}
+Renames internal variables created by the gfortran front end and makes
+them accessible to a debugger.  The name of the internal variables then
+start with upper-case letters followed by an underscore.  This option is
+useful for debugging the compiler's code generation together with
+@code{-fdump-tree-original} and enabling debugging of the executable
+program by using @code{-g} or @code{-ggdb3}.
+
 @item -fdump-fortran-global
 @opindex @code{fdump-fortran-global}
 Output a list of the global identifiers after translating into
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 96ed208cb85..57b0264458e 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -452,6 +452,10 @@ fd-lines-as-comments
 Fortran RejectNegative
 Treat lines with 'D' in column one as comments.
 
+fdebug-aux-vars
+Fortran Var(flag_debug_aux_vars)
+Issue debug information for compiler-generated auxiliary variables.
+
 fdec
 Fortran Var(flag_dec)
 Enable all DEC language extensions.
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index 025abe38985..ca0b10ca73d 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -73,6 +73,45 @@ gfc_advance_chain (tree t, int n)
   return t;
 }
 
+static int num_var;
+
+#define MAX_PREFIX_LEN 20
+
+static tree
+create_var_debug_raw (tree type, const char *prefix)
+{
+  /* Space for prefix + "_" + 10-digit-number + \0.  */
+  char name_buf[MAX_PREFIX_LEN + 1 + 10 + 1];
+  tree t;
+  int i;
+
+  if (prefix == NULL)
+    prefix = "gfc";
+  else
+    gcc_assert (strlen (prefix) <= MAX_PREFIX_LEN);
+
+  for (i = 0; prefix[i] != 0; i++)
+    name_buf[i] = gfc_wide_toupper (prefix[i]);
+
+  snprintf (name_buf + i, sizeof (name_buf) - i, "_%d", num_var++);
+
+  t = build_decl (input_location, VAR_DECL, get_identifier (name_buf), type);
+
+  /* We want debug info for it.  */
+  DECL_IGNORED_P (t) = 0;
+  /* It should not be nameless.  */
+  DECL_NAMELESS (t) = 0;
+
+  /* Make the variable writable.  */
+  TREE_READONLY (t) = 0;
+
+  DECL_EXTERNAL (t) = 0;
+  TREE_STATIC (t) = 0;
+  TREE_USED (t) = 1;
+
+  return t;
+}
+
 /* Creates a variable declaration with a given TYPE.  */
 
 tree
@@ -80,6 +119,9 @@ gfc_create_var_np (tree type, const char *prefix)
 {
   tree t;
 
+  if (flag_debug_aux_vars)
+    return create_var_debug_raw (type, prefix);
+
   t = create_tmp_var_raw (type, prefix);
 
   /* No warnings for anonymous variables.  */

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-12-15 16:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-12 18:59 [patch, fortran] Optionally improve debugging of auxiliary variables Thomas Koenig
2020-12-13 12:21 ` Iain Sandoe
2020-12-13 14:20   ` Thomas Koenig
2020-12-13 14:29     ` Iain Sandoe
2020-12-13 14:50       ` Thomas Koenig
2020-12-13 15:02         ` Iain Sandoe
2020-12-13 19:04           ` Thomas Koenig
2020-12-13 19:59             ` Iain Sandoe
2020-12-15 16:17               ` Thomas Koenig

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).