This is the mail archive of the gcc-patches@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]

[PATCH]: Fix java failure and ada bootstrap failure


The first problem (the java problem) is that in some cases, like java, we don't have any block tree before lowering. In other cases, it's not what the debug writer expects (IE the used flag weirdities).j
In the case that a function gets completely inlined and never output at all,
it won't be lowered, and thus, isn't guaranteed to have a correct block tree.
When that occurs, not all of the abstract origins will be able to be found, because
we won't have outputted some or all of variables (because they don't appear in the block tree).


There is nothing we can really do about this right now.  Tree-profiling happens to fix it because
all functions are lowered before they are attempted to be inlined, so you always
have a correct block tree.  Thus, i've chosen to simply generate degenerate debug info.
When we can't find an abstract origin, we simply won't output one.  We lose
a somewhat valuable assert here (it was verifying the correctness of the order of output
when we had a full block tree), but i intend to put that back on the tree-profiling branch
so that it comes in again during the merge.

As for the used flag weirdities, i've simply partially reverted the last patch, in favor of
making the debug writer not cut out when it sees a block without a used flag, and instead
to do what it would normally do for that block, *expect* output variables.

I have documented the reason for the assert removal in the place it used to exist.
I have also documented the used flag semantics for blocks as they stand now.
 in tree.h, for future reference.

The second problem we now hit is that we sometimes try to output the same regular
debug info twice. This can occur when dwarf2out_decl ends up being called twice on
the same function, once through the inlining machinery, and then once
by the regular machinery. Only the second call here could possibly know whether
the function is going to be output, and there is no easy place in which to insert
a check. I hope to add some flags to the cgraph node to specify whether we've outputted
complete debug info for a function to avoid the second call in the future, but i don't
believe this is completely approriate for 4.0 at this stage.
For now, there is no harm here in simply ignoring the second attempt to output, as the ??? comment used to say.


Bootstrapped and regtested (including ada, though i can't get the ada testsuite to not hang on this machine, with or without this patch) on i686-pc-linux-gnu. Okay for mainline?

Attachment: fixadajava.diff
Description: Text document


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