On Wed, Mar 4, 2020 at 1:26 AM Martin Sebor <mse...@gmail.com> wrote: > > On 3/3/20 11:50 AM, Richard Biener wrote: > > 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. > > Yes, I realize that. But it seems like six of one vs half a dozen > of the other. Either way some variables need converting. I don't > really have a preference for either approach. I just copied > the solution I already used in gimple_call_alloc_size, and I chose > that one there because the get_range calls take wide_int, and > because gimple_call_alloc_size's caller (the function I'm changing > now) also uses wide_int. > > Everything could be changed to widest_int instead but I'm not sure > it would make sense (e.g., get_range_info). And unless everything > is changed, the APIs that interoperate need to convert between one > another. > > I went ahead and rewrote the patch to use widest_int. It let me get > rid of some conversions but it introduced others. Most of them look > pretty much the same between the two approaches but there are more > of them with widest_int because of the extra variables. The updated > patch is also about one and half times longer. > > Is one approach significantly better than the other or were you just > pointing out another way of doing it?
I was just pointing out other ways of doing it since you weren't happy. > Either way, please choose one and approve. The widest_int one is OK, it looks slightly better to me (no explicit precisions). Thanks, Richard. > Thanks > Martin > > > > > 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 > > >
