http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #7 from Marc Glisse <marc.glisse at normalesup dot org> 2012-05-02 14:33:42 UTC --- (In reply to comment #6) > On Sat, 28 Apr 2012, marc.glisse at normalesup dot org wrote: > > I find it easier to use bignum and wrap at the end, instead of checking for > > each operation if it overflows. > I think using GMP is way too expensive for this (simple) task. As long as you only try to handle operations on types no larger than HOST_WIDE_INT, using double_int should be possible. But if you want to handle wrapping multiplication of __int128, that's going to be hard without a widening multiplication to __int256. I guess I could implement a mulhi on double_int... Or at least make sure the slow path is only used for __int128 and not for small types. Or even fall back to VR_VARYING when __int128 overflows, but that's sad. (as a side note, it is strange that double_int is signed, it seems it should break with strict overflow) > Well, my original idea was to simultanely do range propagation for > wrapping and undefined overflow, and in the case that both results > result in different final transforms warn (to avoid the fact that > we do not fully take advantage of undefined overflow during propagation > and to avoid false positives on the warnings for undefined overflow). Good idea. I guess one of my problems is that there are several possible notions of overflow and I don't really know which gcc wants. - wrap (unsigned and -fwrapv) - saturating (not currently) - trap (has to detect overflows and do something about them) - unspecified (don't know anything about the value produced by an overflow, but it is legal) - illegal (we are allowed to crash the computer if such a path is ever taken, but also to just keep going with a random value, that may not even be consistent between uses, I guess that's -fstrict-overflow) The comments at the definition of TYPE_OVERFLOW_UNDEFINED seem to indicate that it means "illegal", but tree-vrp tends to use: non-wrapping => unspecified. And I don't think value_range_d has a notion of an empty range (VR_UNDEFINED or VR_RANGE with max<min don't seem to be used that way, and just having TREE_OVERFLOW in one of the extremities of the interval is not preserved by enough operations).
