This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug debug/23551] dwarf records for inlines appear incomplete



------- Comment #9 from wilson at gcc dot gnu dot org  2005-10-13 02:47 -------
If you compile with -dA you will get readable DWARF2 debug info in the .s file.

Case 1:
There is no location info for the parameter x because it has been optimized
away.  Change the variable x in main to y to avoid ambiguity, compile with
-fdump-tree-all, and look at the t27 and t29 dumps.  In the t27 dump, the
variable x is there and assigned to.  In the t29 dump, the variable x is there,
but no longer assigned to.  Since it is no longer assigned to, we never
allocate space for it, and hence no location attribute can be emitted.  t29 is
the copyrename dump file.  If I compile with -fno-tree-copyrename, then I do
get a location attribute for the parameter x in the inlined copy of foo.  I
don't think there is any bug here, but if there is, it would be in the tree
copyrename pass, because there is no longer any useful parameter x when it is
done.

Case 2:
Similar situation.  The tree-ssa optimizers optimize away all trace of the
inline foo function.  By the time we get to the end of tree-ssa, all we have
left is return 11.  If you look in the .00.expand RTL dump, there are no line
number notes or basic block notes associated with the inline foo.  Since there
is no inline foo, the debug output routines can't do anything here.  I tried
all of the -fno-tree-* options, but that doesn't help.  This is apparently
something that can't be turned off.  If we really want debug info in this case,
then the tree optimizers need to be modified to preserve lexical blocks and
variables that originated in inlined functions.  Not clear if this is
desirable.

Case 3:
The difference here is that the tree optimizers are not able to completely
optimize away the for loop in the inline function.  Since we still have lines
of code from the inline function, and stores to the parameter x, when the
tree-ssa optimizers are done, we get the debug info you expect.

Summary, these problems are all issues with tree optimizers destroying info
when optimizing.  Case 1 probably can't be fixed without hurting optimization,
and hence is probably not feasible to fix it.  A partial fix to Case 2 may be
feasible, as the tree optimizers can perhaps be taught to keep the lexical
block needed to represent the inline function foo.  However, as in case 1,
there will be no location attribute for x though, and this can't be fixed
without disabling optimizations.  Case 3 is the good example, there is nothing
broken here.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]