Re: [patch, fortran] Optionally improve debugging of auxiliary variables

[Iain Sandoe <idsandoe@googlemail.com>]

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>