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).
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
