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?
Jason
