On March 3, 2020 4:39:34 PM GMT+01:00, Martin Sebor <mse...@gmail.com> wrote: >On 3/3/20 2:42 AM, Richard Biener wrote: >> On Tue, Mar 3, 2020 at 12:04 AM Martin Sebor <mse...@gmail.com> >wrote: >>> >>> The wide_int APIs expect operands to have the same precision and >>> abort when they don't. This is especially insidious in code where >>> the operands normally do have the same precision but where mixed >>> precision arguments can come up as a result of unusual combinations >>> optimization options. That is also what precipitated pr93986. >> >> If you want sth like (signed) arbitrary precision arithmetic then you >can >> use widest_int instead. Or, since you're working with offsets, >offset_int >> is another good choice. > >Yes, I would much prefer not to have to do all this myself (and >risk getting it wrong). Unfortunately, the APIs that obtain >the ranges all use wide_int, so I'd have to convert them one way >or the other. I could change some of the APIs but not all of >them (e.g., get_range_info).
You can convert wide_int to both offset and widest int. Richard. >Martin > > >> >>> The attached patch adjusts the code to extend all wide_int operands >>> to the same precision to avoid the ICE. >>> >>> Besides the usual bootstrap/testing I also compiled all string tests >>> in gcc.dg with the same options as in the test case in pr93986 in >>> an effort to weed out any lingering bugs like it (found none). >>> >>> Martin
