This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]Fix computation of offset in ivopt


On Fri, Oct 18, 2013 at 2:26 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 10/18/2013 02:10 PM, Richard Biener wrote:
>> On Fri, Oct 18, 2013 at 2:02 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
>>> On 10/18/2013 01:18 PM, Richard Biener wrote:
>>>
>>>> Index: gcc/fold-const.c
>>>> ===================================================================
>>>> --- gcc/fold-const.c (revision 203267)
>>>> +++ gcc/fold-const.c (working copy)
>>>> @@ -7270,8 +7270,8 @@ fold_plusminus_mult_expr (location_t loc, enum tre
>>>>        HOST_WIDE_INT int01, int11, tmp;
>>>>        bool swap = false;
>>>>        tree maybe_same;
>>>> -      int01 = TREE_INT_CST_LOW (arg01);
>>>> -      int11 = TREE_INT_CST_LOW (arg11);
>>>> +      int01 = int_cst_value (arg01);
>>>> +      int11 = int_cst_value (arg11);
>>>>
>>>> this is not correct - it will mishandle all large unsigned numbers.
>>>>
>>>> The real issue is that we rely on twos-complement arithmetic to work
>>>> when operating on pointer offsets (because we convert them all to
>>>> unsigned sizetype).  That makes interpreting the offsets or expressions
>>>> that compute offsets hard (or impossible in some cases), as you can
>>>> see from the issues in IVOPTs.
>>>
>>> I still have patches to keep pointer types in ivopts (using a new
>>> POINTER_PLUSV_EXPR). Would that help in this case? Last time I posted
>>> them they met an unenthusiastic reception so I've never bothered to
>>> repost them.
>>
>> Can you point me to that patch?  Or shortly elaborate on "keep pointer types
>> in ivopts"?  I think this issue is about decomposing offset computations into
>> a constant and a variable part, which after foldings messed up the unsigned
>> computation can result in "odd" constant offset parts.  So it's rather
>> because the offset operand of POINTER_PLUS_EXPR is fixed as
>> sizetype.
>
> Okay, my patch doesn't address that part, it only ensures the pointer
> base values are kept and arithmetic on them is done using POINTER_PLUS.

Ah, I recently fixed parts of that I think ...

2013-09-02  Richard Biener  <rguenther@suse.de>

        * tree-affine.c (add_elt_to_tree): Avoid converting all pointer
        arithmetic to sizetype.

maybe you can double-check if the result is what you desired ;)

Richard.

> The original patch was here.
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01104.html
>
>
> Bernd
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]