Question about LTO dwarf reader vs. artificial variables and formal arguments

[Sandra Loosemore]

Steven Bosscher wrote:

> I want to make gfortran produce better debug information, but I want to do it 
> in a way that doesn't make it hard/impossible to read back in sufficient 
> information for LTO to work for gfortran.  
> 
> I haven't really been following the whole LTO thing much, but if I understand 
> correctly, the goal is to reconstruct information about declarations from 
> DWARF information that we write out for those declarations.  If that's the 
> case, I wonder how LTO will handle artificial "variables" and formal argument 
> lists. 

[much snippage]

The short answer is that I don't know the answer to your questions.  ;-)  So far 
I've been focusing on C in the LTO reader, with a few hooks for C++, and I'm not 
familiar enough with the Fortran front end to know what special challenges it 
might present.

If your goal is to produce better debug information, I'd just focus on doing 
that within the constraints of Dwarf, and forget about LTO entirely.  For 
instance, I agree with the suggestion that the Fortran front end ought to be 
tagging artificial variables with DW_AT_artificial instead of resorting to other 
hacks.  That's about keeping the debugger happy and really has nothing to do 
with LTO.

If Dwarf just isn't adequate to represent the full Fortran type information in a 
way that allows it to be fully reconstructed by the LTO front end, we can both 
extend Dwarf and extend the Gimple dumper, e.g., by dumping both the "real type" 
as well as the "declared type" you want the debugger to see.  Or we might end up 
not using Dwarf at all in the long run.

-Sandra