This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: VTA merge?
> It would be nice if it worked this way, but the dozens of patches to fix
> -g/-g0 compile differences I posted over the last several months show
> it's really not that simple, because the codegen IR does not tell the
> whole story. We have kind of IR extensions for debug info, for types
> and templates, for aliasing information, even for GC of internal data
> structures, and all of these do affect codegen, sometimes in very subtle
> ways.
Yes, precisely, they are IR extensions, most passes shouldn't have to bother
with them. Fixing bugs there can probably be done once for all passes.
> Speaking specifically of debug information, the little attention given
> to preserving information needed to generate correct debug info means
> that introducing errors is not just a matter of active mistakes. Most
> of the debug information errors we have now do not follow from actively
> breaking debug info data structures, but rather from passively failing
> to keep them up to date, or even missing data structures to that end.
I was only talking about code generation, not debug info generation.
> I can certainly understand the wish to keep debug info IR out of sight,
> and have it all be maintained sort of by magic, without need for
> developers to even think about it. While I share that wish and even
> tried to satisfy it in the design, I've come to the conclusion that it
> can't be done. And it's not just a âit can't be done without major
> surgery in GCC as it is todayâ, it's a âit can't be done at allâ.
Well understood. So, in the end, we seem to agree that your approach is
fundamentally different from what we have now. I only added that in my
opinion it is inherently less robust as far as -g vs -g0 code is concerned
(unless it is enabled unconditionally) and we shouldn't trade this loss of
robustness for nothing.
--
Eric Botcazou