simon-git: spigot (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  0daf164 Fix off-by-1 exponent in IEEE overflow detection.

Repository:     git://git.tartarus.org/simon/spigot.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=spigot.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2016-06-21 19:07:58

commit 0daf1647529fb3963fbc09a3b2f9faa0d47d3673
web diff http://tartarus.org/~simon-git/gitweb/?p=spigot.git;a=commitdiff;h=0daf1647529fb3963fbc09a3b2f9faa0d47d3673;hp=1aa8cbb73f8fcbfd569bb1132054c52f61aeb625
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jun 21 18:58:06 2016 +0100

    Fix off-by-1 exponent in IEEE overflow detection.
    
    Values up to a factor of 2 above the largest representable number, in
    all IEEE float formats, were being output as values in the NaN space,
    as if an all-1s exponent field signified nothing unusual and was just
    another value used for expressing slightly larger finite numbers. For
    example, asking for 'ieee:7f000001 * 2' in IEEE single precision would
    come out as the nonsensical 7f800001, where it should have output
    7f800000 representing an overflow to infinity.
    
    That's quite an embarrassing goof to have failed to spot in all the
    time since last year's base-output rewrite! I think how it happened
    was that my existing test cases for overflow didn't overflow by
    _enough_ to point it out, because I was anticipating a totally
    different class of mistake. There are rounding-mode-dependent
    subtleties in the exact position of the dividing line between overflow
    and not-overflow, which I know are easy to get wrong, and so my test
    cases arranged to _only just_ overflow to infinity, or _only just_
    avoid doing so, so that I could check whether each tricky case got the
    right one of those two possibilities.
    
    But that's the one kind of test in which you _don't_ find out about
    this particular class of error, because the bit pattern representing
    infinity is identical to the one that would represent the next finite
    power of two if the exponent field permitted it. So the answers to all
    those borderline overflow cases come out as 7f800000 (or other-width
    equivalent) either way. If I'd had any test case that overflowed as
    far as 7f800001, _that_ would have shown up the difference.
    
    Anyway. The fix is trivial, and now we have some new regression tests
    that overflow by enough to spot this problem should it recur.

 baseout.cpp |    2 +-
 test.sh     |    8 ++++++++
 2 files changed, 9 insertions(+), 1 deletion(-)