On Fri, 2026-02-06 at 07:56 +0100, Richard Biener wrote: > On Fri, Feb 6, 2026 at 1:25 AM Andrew MacLeod <[email protected]> > wrote: > > > > > > On 2/5/26 18:53, David Malcolm wrote: > > > PR analyzer/98447 covers a false positive from -fanalyzer. > > > The root cause is that the analyzer's constraint-handling code > > > doesn't "know" that if X := Y / 64, then X < 64. > > > > > > This patch adds some minimal usage of value_range and range_op to > > > -fanalyzer. It adds a new svalue::maybe_get_value_range vfunc, > > > which > > > attempts to get a value_range for an svalue (but bails out for > > > awkward > > > cases), and if value_ranges are available, uses them in > > > eval_condition > > > to determine if the result is known based on range_op. > > > > > > Doing so fixes the above false positive, improves a couple of > > > other > > > tests in the DejaGnu testsuite, and eliminates 31 false +ves in > > > the > > > analyzer integration testsuite (out of ~2200), along with a > > > slight > > > speedup to the latter (albeit testing with a debug build of gcc). > > > > > > A deeper integration with ranger could probably be made, but that > > > is > > > clearly stage 1 material. > > > > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. > > > Successful run of analyzer integration tests on x86_64-pc-linux- > > > gnu. > > > > > > Andrew: is this OK for trunk? (from a value_range/range_op > > > perspective) > > > Jakub/Richi: is it OK to push this in stage 4, or do you want me > > > to > > > wait to stage 1? > > OK with me. > > > Range op parts are fine for this. as we discussed offline.
Thanks; pushed to trunk as r16-7365-g498fb8a24516b1. > > > > We can do some more interesting things in stage 1 :-) I have lots of ideas here, but will try to focus on bugfixing :-) Dave
