Some wide-int review comments

[Richard Biener]

On Tue, Nov 12, 2013 at 5:43 PM, Kenneth Zadeck
<zadeck@naturalbridge.com> wrote:
> On 11/12/2013 11:27 AM, Joseph S. Myers wrote:
>>
>> On Tue, 12 Nov 2013, Kenneth Zadeck wrote:
>>
>>> Richi,
>>>
>>> i am having a little trouble putting this back the way that you want.
>>> The
>>> issue is rem.
>>> what is supposed to happen for INT_MIN % -1?
>>>
>>> I would assume because i am failing the last case of
>>> gcc.dg/c90-const-expr-8.c
>>> that INT_MIN %-1 should not overflow even if INT_MIN / -1 does.
>>> however,
>>
>> Given the conclusion in C11 that a%b should be considered undefined if a/b
>> is not representable, I think it's reasonable to say INT_MIN % -1 *should*
>> be considered to overflow (for all C standard versions) (and bug 30484 is
>> only a bug for -fwrapv).
>>
> however, my local question is what do we want the api to be
> int-const-binop-1?    The existing behavior seems to be that at least for
> common modes this function silently returns 0 and it is up to the front ends
> to put their own spin on it.

For wide-int you create 1:1 the behavior of current trunk (if a change of
behavior in TImode is not tested in the testsuite then you can ignore that).
Whatever change you do to semantics of functions you do separately
from wide-int (preferably first on trunk, or at your choice after the wide-int
merge).

For this case in question I'd say a % -1 should return 0, but for
INT_MIN % -1 that 0 should have TREE_OVERFLOW set (and
thus you need to adjust that c90-const-expr-8.c testcase).

Richard.

> kenny