[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 27.06.05 in <[EMAIL PROTECTED]>:
> Nathan Sidwell <[EMAIL PROTECTED]> writes: > > | Gabriel Dos Reis wrote: > | > | > But a compiler could define them to be modulo -- that is the whole > | > point. The paragraph does not say they don't "modulo". > | > | of course it could do so, but then to be useful it should document it, > | and it would be an extension. > > We're in violent agreement there. I think there are actually two different interesting properties here. One is that operations on signed integers can or can not do modulo arithmetic. The other is that for control flow purposes, the compiler can or can not assume that no such overflow actually happens. I think it might be useful to handle these separately - that is, have one set of flags handling modulo behaviour (-frapv, -ftrapv, neither, possibly others) and a different set for specifying control flow assumptions (-fassume-no-wraps, -f-no-assume-no-wraps). -fassume-no-wraps would then allow the compiler to take control flow shortcuts based on the assumption that no overflow actually happens, and -fno-assume-no-wraps would guarantee that control flow handles all possible overflow cases. I don't think it would make sense to specifically call out loops here. We've already seen an example where the actual difference happens outside the loop. It might be a little tricky to get the combination of -fassume-no-wraps and -fwrapv/-ftrapv right. Or not, I wouldn't know. In any case, especially the -ftrapv variant seems useful (assume for control flow that no overflows happen, but if they do happen, trap). It seems to me that most C programs will probably want -f-no-assume and neither wrapv option. MfG Kai
