Joe Buck <[EMAIL PROTECTED]> writes: | On Tue, Jun 28, 2005 at 07:02:49PM +0200, Gabriel Dos Reis wrote: | > | Since behavior on integer overflow is undefined, we can optimize assuming | > | that overflow has not occurred. Then a > c, so the for loop always | > | executes b+1 times, and we end up with | > | | > | if (b > 0) | > | some_func(b+1); | > | | > | Any attempt to assign meaning to integer overflow would prevent this | > | optimization. | > | > We document that | > | > a = (int) ((unsigned) b + c) | > | > is well-defined and given by the wrapping semantics. Does the current | > optimizer takes that into account or will it assume b+1 execution times? | | C/C++ require unsigned to be modulo, and I think it is perfectly | appropriate to define the cast from unsigned to int to assume two's | complement behavior. But if unsigned variables are involved, in my | example the compiler is forced to produce worse code (it must cover | the case of wraparound).
>From Diego's mail, I understand that the loop optimizer was way too aggressive in its assumptions and it is fixed now. So, the next logical step would be to have the semantics well-documented. | > If the optimizer takes that into account, then the question becomes | > when do we consider breaking the ABI to switch numeric_limits<signed | > type>::is_modulo back to old behaviour. | | I think that defining signed types as is_modulo is broken, but I'm not | sure what consequences follow from this problem (e.g. what kind of user | code is using this feature, and for what). numeric_limits<T>::is_modulo is part of the core C++ language (not just the library) and any change to that value implies an ABI change, in the sense any use of numeric_limits<T>::is_modulo in template declarations (e.g. SFINAE hackery) gets mangled the same but instantiate to a different function. I would expect such hackery to be localized, but it is an ABI change and we must know that (whatever is decided after). -- Gaby
