[GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1)

[GHC]

#8695: Arithmetic overflow from (minBound :: Int) `quot` (-1)
------------------------------------------------+--------------------------
        Reporter:  rleslie                      |            Owner:
            Type:  bug                          |           Status:  patch
        Priority:  normal                       |        Milestone:  7.8.1
       Component:  libraries/haskell2010        |          Version:  7.6.3
      Resolution:                               |         Keywords:
Operating System:  Unknown/Multiple             |     Architecture:
 Type of failure:  Incorrect result at runtime  |  Unknown/Multiple
       Test Case:                               |       Difficulty:
        Blocking:                               |  Unknown
                                                |       Blocked By:
                                                |  Related Tickets:  #1042
------------------------------------------------+--------------------------

Comment (by carter):

 @lerkok isn't that tantamount to having the 2s complement ops defined as
 being the same operationally as the unsigned operations of the same size?

 you make an interesting point, At the same time haskell has more in common
 with coq / agda tradition than the SMT, though this is an informative
 remark.


 @hvr, so heres the thing, one thing i want to dig into in the near future
 (among several) is improve the native Int / Word / Float / Double
 optimizations, in both the "correct/no ____flow" and "who cares about
 underflow/overflow" variants  (the latter corresponding to -ffast-math in
 gcc / clang / llvm). Its kinda hard to provide decent optimization for
 those respective cases  with the former is done as a userland library.
 Also, theres the fact that, to keep compatibility for the near term, we'd
 probably have the default int/ word be the wrap around one, BUT we'd
 probably want to encourage new users to use a sounder default.  Its not
 about either or, but both. (I may have been a bit anti both the last time
 this debate)

 I really really want to be able to help ghc have better numerical
 optimization, on both the bit fiddling and floating fronts. To do that,
 having clear cases when we want to preserve values in an (over/under)flow
 / NAN etc evading way is key for those who want to work in the "theres a
 clear unique solution".

 Theres actually at least 3 different valid semantics for dealing with
 over/underflow for words/ints
  a) exception / interrupts on over/underflow etc
  b) wrapping style semantics
  c) saturating (theres a max and min value, you can't go farther than
 that), this is more common on embedded systems / signal processing
 algorithms than on desktop/server settings, but its another valid "give a
 unique solution" approach, and many architectures give instructions for
 this semantics too.

 the point being, the curren situation is a mess, and this whole discussion
 is symptomatic of a deeper problem that really gets in the way of
 improving the numerical sitch for ghc / haskell. Either solution is not
 unique, both are valid in different models, and currently theres not a
 clear stance on which model int's clearly fall on either side, because
 we're not providing consistent semantic models.

 in summary: theres several different ways we can give unique semantics to
 many of these operations, and i don't think the current Int situation sits
 clearly on either side, and perhaps we should seriously consider what the
 implications of only providing one choice in semantics in ghc is, and
 either do it whole sale or provide both.

 Providing both would actually be in alignment with some of the ideas i
 have for slightly decoupling Int proper from how array addressing works
 (because currently int is used implicitly as our model for doing address
 arithmetic on pointers, which even modern C has moved away from!)

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8695#comment:26>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler