On 7/21/26 4:06 PM, Marek Polacek wrote:
On Mon, Jul 20, 2026 at 04:34:57PM -0400, Jason Merrill wrote:
On 7/20/26 1:00 PM, Marek Polacek wrote:
On Tue, Jul 14, 2026 at 11:35:04PM -0400, Jason Merrill wrote:
On 7/14/26 7:06 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/16?
-- >8 --
Like in PR110822, the attached test produces an ICE in verify_address:
error: constant not recomputed when 'ADDR_EXPR' changed
since r10-7718, but it wasn't fixed by r15-7762. The reason is that
here we have:
{.D.3013={.D.3006={.a={.ptr=&<retval>.D.3013.D.3006.a}},
.D.3007={.b={.ptr=&<retval>.D.3013.D.3007.b}}}}
and we replace '<retval>' with 'names', but we only call
recompute_tree_invariant_expr for the first ADDR_EXPR, not the latter.
For the second ADDR_EXPR d->changed will be false: the first replacement
changed the shared tree <retval>.D.3013. So I'm afraid we have to
recompute the flags unconditionally. It may be a bit slower, but it's
correct.
OK for 16.
But how do we end up with this sharing? It looks like
replace_placeholders_r properly does unshare_expr.
There are no PLACEHOLDER_EXPR so the unshare_expr in replace_placeholders_r
won't take place.
Surely there's a PLACEHOLDER_EXPR created and replaced at some point for
changing the 'this' in the DMI for bug::ptr to the two addresses above? If
not, how does it happen?
True, once we're done with check_return_expr, we do have an expression
with PLACEHOLDER_EXPRs:
TARGET_EXPR <D.3018, {.D.3013={.D.3006={.a={.ptr=&<PLACEHOLDER_EXPR struct bug>}},
.D.3007={.b={.ptr=&<PLACEHOLDER_EXPR struct bug>}}}}>
but they are replaced in cxx_eval_constant_expression/PLACEHOLDER_EXPR
when we call maybe_constant_value on the ctor containing them.
So maybe we should unshare then, perhaps in the return at the end of
lookup_placeholder?
Jason
