On Mar 26, 2020, Jakub Jelinek <ja...@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