https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323
--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Andrew Macleod from comment #6) > (In reply to Jakub Jelinek from comment #4) > > Or the ranger could do it itself, similarly to how it handles .ASSUME, but > > without actually querying anything but the global range of the return value > > if any. Though, doing that in the range means that we won't know ranges of > > functions which with LTO are in a different partition, while doing it as IPA > > optimization could allow even that to work. > > Aldy has been doing some IPA/LTO related cleanup with ranges... Hopefully we > can get this all connected next release. I'm sitting on a patchset for GCC 14 that will revamp all the range handling in ipa-*.* to be less ad-hoc, and use generic ranges (vrange even, so type-agnostic). The plan is to integrate this with the internal range storage used by IPA (currently pairs of wide ints or value_range's) so that IPA at least has the infrastructure to handle generic ranges. Some discussion upstream is still needed, but the general idea should be feasible for GCC 14. It will be up to the IPA maintainers to handle floats/etc internally though.
