| Message ID | 87bnuyexv7.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com |
|---|---|
| State | New |
| Headers | show |
> This is the second part of PR 61084, which it seems I'd forgotten to post. > pdist calculates a wide result from narrower inputs, so I should have > used widest_int rather than wide_int. Is that documented? Because, if even you wide-int guys got it wrong... > PR target/61084 > * config/sparc/sparc.c (sparc_fold_builtin): Use widest_int rather > than wide_int. OK, thanks.
Eric Botcazou <ebotcazou@adacore.com> writes: >> This is the second part of PR 61084, which it seems I'd forgotten to post. >> pdist calculates a wide result from narrower inputs, so I should have >> used widest_int rather than wide_int. > > Is that documented? Because, if even you wide-int guys got it wrong... Well, I understood the distinction between wide_int and widest_int. I just didn't understand what pdist did. :-) The difference is documented (a bit verbosely) in wide-int.h. Does anyone have any suggestions for a better name than "wide_int" though? The main property of wide_int is that it has a variable precision, whereas widest_int and offset_int have constant precisions. Thanks, Richard
> Well, I understood the distinction between wide_int and widest_int. > I just didn't understand what pdist did. :-) > > The difference is documented (a bit verbosely) in wide-int.h. Yes, but not really why it's not correct to use wide_int for the computation made in pdist (and whether the use of widest_int could be avoided altogether by using a common type throughout the computation).
Eric Botcazou <ebotcazou@adacore.com> writes: >> Well, I understood the distinction between wide_int and widest_int. >> I just didn't understand what pdist did. :-) >> >> The difference is documented (a bit verbosely) in wide-int.h. > > Yes, but not really why it's not correct to use wide_int for the computation > made in pdist It was wrong to use wide_int because the calculation does arithmetic on mixed QImode and DImode values. 1) wide_int (the default). This flavor does the math in the precision of its input arguments. It is assumed (and checked) that the precisions of the operands and results are consistent. The precisions weren't consistent in this case and we failed the assertion checks. > (and whether the use of widest_int could be avoided altogether > by using a common type throughout the computation). That would work too, but widest_int seemed simpler. Thanks, Richard
On May 19, 2014, at 12:27 AM, Richard Sandiford <rdsandiford@googlemail.com> wrote: > Does anyone have any suggestions for a better name than "wide_int" though? Please, no. > The main property of wide_int is that it has a variable precision, whereas > widest_int and offset_int have constant precisions. Right, I'd clarify that all wide_ints have a fixed precision over their lifetime; but during the creation of each, the precision for that object can be set arbitrarily (within a certain range).
Index: gcc/config/sparc/sparc.c =================================================================== --- gcc/config/sparc/sparc.c 2014-05-15 13:49:25.425654068 +0100 +++ gcc/config/sparc/sparc.c 2014-05-16 12:56:48.578349758 +0100 @@ -10915,8 +10915,8 @@ sparc_fold_builtin (tree fndecl, int n_a && TREE_CODE (arg2) == INTEGER_CST) { bool overflow = false; - wide_int result = arg2; - wide_int tmp; + widest_int result = wi::to_widest (arg2); + widest_int tmp; unsigned i; for (i = 0; i < VECTOR_CST_NELTS (arg0); ++i) @@ -10926,8 +10926,8 @@ sparc_fold_builtin (tree fndecl, int n_a bool neg1_ovf, neg2_ovf, add1_ovf, add2_ovf; - tmp = wi::neg (e1, &neg1_ovf); - tmp = wi::add (e0, tmp, SIGNED, &add1_ovf); + tmp = wi::neg (wi::to_widest (e1), &neg1_ovf); + tmp = wi::add (wi::to_widest (e0), tmp, SIGNED, &add1_ovf); if (wi::neg_p (tmp)) tmp = wi::neg (tmp, &neg2_ovf); else