On Sat, Jan 4, 2014 at 9:13 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> wrote:
> On Wed, Jan 01, 2014 at 07:49:16PM -0800, Mike Stump wrote:
>> On Nov 23, 2013, at 12:16 PM, Steve Kargl 
>> <s...@troutmask.apl.washington.edu> wrote:
>>> On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote:
>>>> Richi has asked the we break the wide-int patch so that the
>>>> individual port and front end maintainers can review their
>>>> parts without have to go through the entire patch.    This
>>>> patch covers the fortran front end.
>>>>
>>>> Ok?
>>>>
>>>> +  *logical = wi::eq_p (t, 0) ? 0 : 1;
>>>
>>> I can't find the meaning of :: in n1256.pdf.  What does this do?
>>>
>>> Also, given the complete lack of a description of what this
>>> patch does and no pointer to a discussion of what this
>>> patch does, and no description of its benefit to gfortran,
>>> I vote "no".
>>
>> I don't like the notion that one person says yes, and one says no,
>> and then we ignore the no, and use the yes to approve a patch.  Can
>> the fortran come up with a final unified answer?  Thanks.
>
> My original comment had nothing to do with the technical merit
> of the patch.  My comment, as shown above, objected to dropping
> a patch on (gfortran) developers with *no* explanation of the
> patch and *no* pointer to where a discussion may have occurred.

Note that at least some of the patch, like

@@ -430,7 +431,7 @@ gfc_interpret_logical (int kind, unsigned char
*buffer, size_t buffer_size,
 {
   tree t = native_interpret_expr (gfc_get_logical_type (kind), buffer,
                                  buffer_size);
-  *logical = tree_to_double_int (t).is_zero () ? 0 : 1;
+  *logical = wi::eq_p (t, 0) ? 0 : 1;
   return size_logical (kind);
 }

could have used a proper tree interface instead.  In the above case
simply

  *logical = integer_zerop (t) ? 0 : 1;

@@ -2083,13 +2083,14 @@ gfc_conv_cst_int_power (gfc_se * se, tree lhs, tree rhs)
   HOST_WIDE_INT m;
   unsigned HOST_WIDE_INT n;
   int sgn;
+  wide_int wrhs = rhs;

   /* If exponent is too large, we won't expand it anyway, so don't bother
      with large integer values.  */
-  if (!TREE_INT_CST (rhs).fits_shwi ())
+  if (!wi::fits_shwi_p (wrhs))
     return 0;

similar, tree_fits_swhi_p ().

Not sure if that helps wrt acceptance.

Richard.

> --
> Steve

Reply via email to