Unfortunately that broke bootstrap.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668700.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668711.html
bootstrap/regtest fine, but if
Are any of these all committed?
No, this is late stage1, everybody is trying to post last minute
enhancements/new features. Richard briefly replied on the first patch,
but it hasn't been fully reviewed/approved.
Jakub
Bah, I cant seem to get those as a patch from the webpages.. Can you
just email me a diff or diffs which has them all in it, including the
faulty change, and I'll go look.
Although, looking at the traceback I think I can see what is happening.
The cache is designed to update only one name at a time as best as
possible before moving to another name. This prevents us from getting
into cycles and other bad things when you ask for the range of something
at the bottom of a loop for instance. The assert being triggered is
the one that says, "make sure there isnt another update going on"
So the cache is propagating andn calculating, and checks for an inferred
range.. and the infer manager is in the "use immeidate_uses to see if
there are any inferred ranges of this ssa name anywhere in the IL"
That in turn i causing a new query when the new attribute causes a new
search to be made to resolve the values on the statement. This then
triggers a new cache update which then triggers the assert because the
first one wasn't finished yet..
SO. the question is what to do about that. Yuo can safely change the
query to a global query:
if (get_range_query (cfun)->range_of_expr (r, arg2, s) &&
becomes
if (get_global_range_query (cfun)->range_of_expr (r, arg2, s) &&
because that will never trigger a lookup. It will successfully
handle any constants as well, but unfortunately will not pick up any
contextual ranges.. so your new testcase is likely to fail :-(
Meanwhile, Let me think about it. The cache itself is also a
range_query, and it has a read-only lookup which would solve this
problem, but Id need to tweak the infer manager so we can provide a
range_query to it.. OR maybe from the cache we shouldn't do the
lookup,. or maybe we should do any infer lookup before anything else.
It needs a little thought. And its probably easier for me to do once
the rest of the code is checked in.
So I suggest make the above global query change, then get the code
checked in, and then open a defect against me for this testcase.
Meanwhile I will think about how best to approach it and then adjust the
infer manager for it. Is that reasonable?
Andrew
