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 understan
Steven Bosscher wrote:
contains
subroutine sub(c)
character*10 c
end subroutine
end
produces as a GIMPLE dump:
sub (c, _c)
{
(void) 0;
}
where _c is strlen("Hi World!"). From a user perspective, it would be better
to hide _c for the deb
Diego Novillo wrote:
Ian Lance Taylor wrote on 10/21/06 14:59:
That is, we are not going to write out DWARF. We can't, because DWARF
is not designed to represent all the details which the compiler needs
to represent. What we are going to write out is a superset of DWARF.
And in fact, if it he
Ian Lance Taylor wrote on 10/21/06 14:59:
That is, we are not going to write out DWARF. We can't, because DWARF
is not designed to represent all the details which the compiler needs
to represent. What we are going to write out is a superset of DWARF.
And in fact, if it helps, I think that we s
Steven Bosscher <[EMAIL PROTECTED]> writes:
> 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 h
On Sat, Oct 21, 2006 at 06:35:40PM +0200, Steven Bosscher wrote:
> where _c is strlen("Hi World!"). From a user perspective, it would be better
> to hide _c for the debugger because it is not something that the user had in
> the original program. I have a patch to hide that parameter, that is,
Hello,
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
