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

2020-12-15 Thread Thomas Koenig via Gcc-patches
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 necessa

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

2020-12-13 Thread Iain Sandoe via Gcc-patches
Hi Thomas, Thomas Koenig via Fortran 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 cas

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

2020-12-13 Thread Thomas Koenig via Gcc-patches
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, p

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

2020-12-13 Thread Iain Sandoe via Gcc-patches
Thomas Koenig via Fortran 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 wh

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

2020-12-13 Thread Thomas Koenig via 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 unders

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

2020-12-13 Thread Iain Sandoe via Gcc-patches
Hi Thomas, Thomas Koenig 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 character

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

2020-12-13 Thread Thomas Koenig via 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.

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

2020-12-13 Thread Iain Sandoe via Gcc-patches
Thomas Koenig via Fortran 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 re