[PATCH] tree: Fix -fcompare-debug issues due to protected_set_expr_location [PR94323]
Alexandre Oliva
oliva@gnu.org
Fri Mar 27 01:21:16 GMT 2020
On Mar 26, 2020, Jakub Jelinek <jakub@redhat.com> wrote:
> The hardest issue I gave up completely on after trying 3 different
> approaches is PR93786, I just don't know what to do in that case.
struct S {virtual void v();};
void f(S * s) {
({ s; })->v();
}
Thanks, I can now see how markers create situations that were not
possible with binds.
The statement 's;' in the expression statement doesn't have any side
effects, but it will have a marker associated with it.
Without side effects, a statement wouldn't give rise to binds, so this
situation wouldn't arise.
Such a simple, side-effect-free statement wouldn't even have location
data associated with it, I suppose. We might have a wrapper to annotate
the expression with the location in which it is used, and we might
augment such a wrapper with pre- and post- debug stmts, but odds are
we'd eventually end up without means to carry the info any further.
This suggests two potential ways to address this problem:
- when gimplifying a STATEMENT_LIST without side effects, if it contains
a single nondebug statement, gimplify only that one stmt, discarding
any of the debug stmts that we can't hold on to.
- wherever we might have a sequence of statements, create a statement
list instead of working very hard in a premature (?) optimization that
makes it harder (impossible?) to retain debug info in cases we'd like
to. This would grow memory use a little during parsing, but since we
gimplify functions early on and that would address most of the
differences, and optimizers would take care of any unnecessary
SAVE_EXPRs, it might not matter much, and avoiding the current runtime
overheads in skipping debug stmts early on might more than make up for
that.
--
Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer Live long and free, and prosper ethically
More information about the Gcc-patches
mailing list