On 3/13/19 6:20 PM, Jakub Jelinek wrote:
On Mon, Mar 11, 2019 at 11:21:00PM +0100, Jakub Jelinek wrote:
The following testcase ICEs since my recent cxx_eval_loop_expr changes.
The problem is that the Forget saved values of SAVE_EXPRs. inside of the
loop can remove SAVE_EXPRs from new_ctx.values and if that is the last
iteration, we can also do the loop at the end of function (which has been
added there mainly to handle cases where the main loop breaks earlier)
and new_ctx.values->remove ICEs because *iter is already not in the table.
While I could e.g. add some bool whether there is anything to be removed
after the loop or not which would fix the regression part of this PR,
I believe there is a latent issue as well. The thing is, new_ctx.save_exprs
That is actually not true, the bug is fully my fault and previously it was
ok, as cxx_eval_loop_expr used to do:
do
{
hash_set<tree> save_exprs;
new_ctx.save_exprs = &save_exprs;
...
}
while (...)
and thus there was a new hash_set for each iteration, it was just me moving
it out of the loop (so that I don't have to repeat the ->remove loop on each
break or use gotos).
Yet another possibility might be to turn save_exprs into a vec, from what
That said, I believe using a vec must be faster and the hash_set seems
overkill, as if SAVE_EXPR wasn't seen yet in the current iteration, it is
desirable to add it to the vec and if it has been added there,
ctx->value->get will be non-NULL, so we'll never add a duplicate, and by
using a vec we don't have to allocate storage for each iteration etc.
So, here is a variant patch I've bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?
This is OK. Is my hash-table.h fix also OK for trunk? It does also fix
the testcase.
Jason
