> Am 06.10.2026 um 18:24 schrieb Andrew MacLeod <[email protected]>:
>
>
>> On 10/6/26 3:31 AM, Richard Biener wrote:
>>> On Mon, Oct 5, 2026 at 9:11 PM Andrew MacLeod <[email protected]> wrote:
>>> The testcase triggers a problem that when an ssa_name was released by
>>> simple_dce_from_worklist. The same name was then used from a cached
>>> value i the relation oracle. This patch modifies release_ssa_name_fn
>>> such that when an ssa name is being released, it also clear any current
>>> range info. THis is similar to what is done during
>>> reset_flow_sensitive_info ().
>>>
>>> This also uncovered a bug in the def chains where clearing the def chain
>>> immediately rebuilds it. This is inadvisable when the name is being
>>> released!
>>>
>>> Bootstrapped on x86_64-pc-linux-gnu with no new regressions. Pushed.
>> Hmm. A ranger instance does not have to be in fn->x_range_query
>> (only with enable/disable_ranger ())? Also this feels a bit expensive - we
>> have arranged for released SSA names to be not re-usable immediately
>> by the current pass via dual free-lists, so a lazy approach should work
>> and queries to released SSA names can instead be catched in the
>> range oracle itself (for example by checking SSA_NAME_ON_FREELIST)
>
>
> Hmm. In theory every single request would have to do the check if the name is
> in the free list.. but in practice, I don't think that is necessary.
>
> I was also debating a follow up to change the 2 locations which fire up their
> own ranger (ch and threadbackward) to call enable _ranger... but I don't
> think that is needed either.
>
> However, we can also argue that this hasn't been an issue for any of the
> other cached values, it is just the new frontier expansion which is
> triggering the problem, so I can revert the change to release_ssa_name_fn and
> instead check the free list while doing the frontier expansion. That will
> cover the new code, and leave everything else as they are.
>
> valid_equivs in the oracle also uses this idiom already, so I think that
> should be good enough. I added this patch as a follow up which reverts the
> change to release_ssa_name.. So if there ever is a future problem related
> other cached values, this commit will show up as the the cause and maybe help
> us figure it out quicker.
That sounds good.
> Patch attached. Bootstrapped on x86_64-pc-linux-gnu with no new regressions.
> Pushed.
Thanks for following up.
Richard
> Andrew
>
>
> <0001-Check-free-list-before-using-a-relation.patch>
