On Tue, Nov 12, 2013 at 5:43 PM, Kenneth Zadeck <zad...@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