optimization/8959: gcc-2.95/3.2 add/subtract results are wrong for a short time when optimising on x86

optimization/8959: gcc-2.95/3.2 add/subtract results are wrong for a short time when optimising on x86

[conrad]

>Number:         8959
>Category:       optimization
>Synopsis:       gcc-2.95/3.2 add/subtract results are wrong for a short time when optimising on x86
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 16 04:26:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Conrad Hughes
>Release:        2.95.4 20011002 (Debian prerelease) and 3.2.1 20020924 (Debian prerelease)
>Organization:
>Environment:
Debian GNU/Linux running kernel 2.2.21 on AMD K6-3+ and other Linux versions on other x86 platforms (including old Pentiums and new Athlons).
>Description:
The result of an addition or subtraction which uses the full precision of double seems to be briefly wrong when optimising on various x86 platforms.  Specifically, computing the same operation twice and immediately comparing the two results will not produce ==, but instead < or > will be true.  Trying the *exact* *same* comparison again *will* produce the expected ==, contradicting the first comparison.  I've been able to reproduce this under several versions of gcc (including the two mentioned above) on several Linux/x86 platforms, ranging from Pentium through K6-3+ to Athlon.  On one tested system I couldn't reproduce it, but I'm afraid I can't identify its underlying hardware architecture; the code it produced failed when run on one of the failing systems (.s files were identical anyway).  Sample exploit (no includes necessary) attached.  Includes output of gcc -v in comments.
>How-To-Repeat:
If you call the above-attached file equal-not-equal.c:
gcc -O equal-not-equal.c && a.out will return 1 (indicating misbehaviour)
gcc equal-not-equal.c && a.out will return 0 (indicating correct behaviour)

Source file without comments just in case attachment doesn't work:
static int
just_that(int x)
{
  return x;
}
int
main()
{
  double d[] = {4.5, 3.0, 8.0 / 3.0};
  double sum1 = 0.0;
  double sum2 = 0.0;
  int i;
  int eq0;
  int eq1;
  for(i = 0; i < 3; ++i)
    sum1 += d[i];
  for(i = 0; i < 3; ++i)
    sum2 += d[i];
  eq0 = just_that(sum1 == sum2);
  eq1 = just_that(sum1 == sum2);
  return eq0 == 1 && eq1 == 1 ? 0 : 1;
}
>Fix:
Don't use -O.  Alternatively, identify points in your code which are susceptible to this bug and insert something else which uses the value you're testing (and gives it time to settle down) before you try to compare.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="equal-not-equal.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="equal-not-equal.c"

LyogU2hvdWxkIHJldHVybiAwIHRvIHNoZWxsLCBidXQgZG9lc24ndCB3aGVuIG9wdGltaXNpbmcg
b24gdmFyaW91cyB4ODYKICogbWFjaGluZXMuCiAqCiAqIEZyb20gZ2NjLTIuOTUuNCAtdiAtc2F2
ZS10ZW1wcyAtTzoKICoKICogUmVhZGluZyBzcGVjcyBmcm9tIC91c3IvbGliL2djYy1saWIvaTM4
Ni1saW51eC8yLjk1LjQvc3BlY3MKICogZ2NjIHZlcnNpb24gMi45NS40IDIwMDExMDAyIChEZWJp
YW4gcHJlcmVsZWFzZSkKICogIC91c3IvbGliL2djYy1saWIvaTM4Ni1saW51eC8yLjk1LjQvY3Bw
MCAtbGFuZy1jIC12IC1EX19HTlVDX189MiAtRF9fR05VQ19NSU5PUl9fPTk1IC1EX19FTEZfXyAt
RHVuaXggLURfX2kzODZfXyAtRGxpbnV4IC1EX19FTEZfXyAtRF9fdW5peF9fIC1EX19pMzg2X18g
LURfX2xpbnV4X18gLURfX3VuaXggLURfX2xpbnV4IC1Bc3lzdGVtKHBvc2l4KSAtRF9fT1BUSU1J
WkVfXyAtQWNwdShpMzg2KSAtQW1hY2hpbmUoaTM4NikgLURpMzg2IC1EX19pMzg2IC1EX19pMzg2
X18gZXF1YWwtbm90LWVxdWFsLmMgZXF1YWwtbm90LWVxdWFsLmkKICogR05VIENQUCB2ZXJzaW9u
IDIuOTUuNCAyMDAxMTAwMiAoRGViaWFuIHByZXJlbGVhc2UpIChpMzg2IExpbnV4L0VMRikKICog
I2luY2x1ZGUgIi4uLiIgc2VhcmNoIHN0YXJ0cyBoZXJlOgogKiAjaW5jbHVkZSA8Li4uPiBzZWFy
Y2ggc3RhcnRzIGhlcmU6CiAqICAvdXNyL2xvY2FsL2luY2x1ZGUKICogIC91c3IvbGliL2djYy1s
aWIvaTM4Ni1saW51eC8yLjk1LjQvaW5jbHVkZQogKiAgL3Vzci9pbmNsdWRlCiAqIEVuZCBvZiBz
ZWFyY2ggbGlzdC4KICogVGhlIGZvbGxvd2luZyBkZWZhdWx0IGRpcmVjdG9yaWVzIGhhdmUgYmVl
biBvbWl0dGVkIGZyb20gdGhlIHNlYXJjaCBwYXRoOgogKiAgL3Vzci9saWIvZ2NjLWxpYi9pMzg2
LWxpbnV4LzIuOTUuNC8uLi8uLi8uLi8uLi9pbmNsdWRlL2crKy0zCiAqICAvdXNyL2xpYi9nY2Mt
bGliL2kzODYtbGludXgvMi45NS40Ly4uLy4uLy4uLy4uL2kzODYtbGludXgvaW5jbHVkZQogKiBF
bmQgb2Ygb21pdHRlZCBsaXN0LgogKiAgL3Vzci9saWIvZ2NjLWxpYi9pMzg2LWxpbnV4LzIuOTUu
NC9jYzEgZXF1YWwtbm90LWVxdWFsLmkgLXF1aWV0IC1kdW1wYmFzZSBlcXVhbC1ub3QtZXF1YWwu
YyAtTyAtdmVyc2lvbiAtbyBlcXVhbC1ub3QtZXF1YWwucwogKiBHTlUgQyB2ZXJzaW9uIDIuOTUu
NCAyMDAxMTAwMiAoRGViaWFuIHByZXJlbGVhc2UpIChpMzg2LWxpbnV4KSBjb21waWxlZCBieSBH
TlUgQyB2ZXJzaW9uIDIuOTUuNCAyMDAxMTAwMiAoRGViaWFuIHByZXJlbGVhc2UpLgogKiAgYXMg
LVYgLVF5IC1vIGVxdWFsLW5vdC1lcXVhbC5vIGVxdWFsLW5vdC1lcXVhbC5zCiAqIEdOVSBhc3Nl
bWJsZXIgdmVyc2lvbiAyLjEzLjkwLjAuMTAgKGkzODYtbGludXgpIHVzaW5nIEJGRCB2ZXJzaW9u
IDIuMTMuOTAuMC4xMCAyMDAyMTAxMCBEZWJpYW4gR05VL0xpbnV4CiAqICAvdXNyL2xpYi9nY2Mt
bGliL2kzODYtbGludXgvMi45NS40L2NvbGxlY3QyIC1tIGVsZl9pMzg2IC1keW5hbWljLWxpbmtl
ciAvbGliL2xkLWxpbnV4LnNvLjIgL3Vzci9saWIvY3J0MS5vIC91c3IvbGliL2NydGkubyAvdXNy
L2xpYi9nY2MtbGliL2kzODYtbGludXgvMi45NS40L2NydGJlZ2luLm8gLUwvdXNyL2xpYi9nY2Mt
bGliL2kzODYtbGludXgvMi45NS40IGVxdWFsLW5vdC1lcXVhbC5vIC1sZ2NjIC1sYyAtbGdjYyAv
dXNyL2xpYi9nY2MtbGliL2kzODYtbGludXgvMi45NS40L2NydGVuZC5vIC91c3IvbGliL2NydG4u
bwogKgogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqCiAqIEZyb20gZ2NjLTMuMiAtdiAtc2F2ZS10ZW1w
cyAtTwogKgogKiBSZWFkaW5nIHNwZWNzIGZyb20gL3Vzci9saWIvZ2NjLWxpYi9pMzg2LWxpbnV4
LzMuMi4xL3NwZWNzCiAqIENvbmZpZ3VyZWQgd2l0aDogL21udC9kYXRhL2djYy0zLjEvZ2NjLTMu
Mi0zLjIuMWRzMi9zcmMvY29uZmlndXJlIC12IC0tZW5hYmxlLWxhbmd1YWdlcz1jLGMrKyxqYXZh
LGY3Nyxwcm90byxvYmpjLGFkYSAtLXByZWZpeD0vdXNyIC0tbWFuZGlyPS91c3Ivc2hhcmUvbWFu
IC0taW5mb2Rpcj0vdXNyL3NoYXJlL2luZm8gLS13aXRoLWd4eC1pbmNsdWRlLWRpcj0vdXNyL2lu
Y2x1ZGUvYysrLzMuMiAtLWVuYWJsZS1zaGFyZWQgLS13aXRoLXN5c3RlbS16bGliIC0tZW5hYmxl
LW5scyAtLXdpdGhvdXQtaW5jbHVkZWQtZ2V0dGV4dCAtLWVuYWJsZS1qYXZhLWdjPWJvZWhtIC0t
ZW5hYmxlLW9iamMtZ2MgaTM4Ni1saW51eAogKiBUaHJlYWQgbW9kZWw6IHBvc2l4CiAqIGdjYyB2
ZXJzaW9uIDMuMi4xIDIwMDIwOTI0IChEZWJpYW4gcHJlcmVsZWFzZSkKICogIC91c3IvbGliL2dj
Yy1saWIvaTM4Ni1saW51eC8zLjIuMS9jcHAwIC1sYW5nLWMgLXYgLURfX0dOVUNfXz0zIC1EX19H
TlVDX01JTk9SX189MiAtRF9fR05VQ19QQVRDSExFVkVMX189MSAtRF9fR1hYX0FCSV9WRVJTSU9O
PTEwMiAtRF9fRUxGX18gLUR1bml4IC1EX19nbnVfbGludXhfXyAtRGxpbnV4IC1EX19FTEZfXyAt
RF9fdW5peF9fIC1EX19nbnVfbGludXhfXyAtRF9fbGludXhfXyAtRF9fdW5peCAtRF9fbGludXgg
LUFzeXN0ZW09cG9zaXggLURfX09QVElNSVpFX18gLURfX1NURENfSE9TVEVEX189MSAtQWNwdT1p
Mzg2IC1BbWFjaGluZT1pMzg2IC1EaTM4NiAtRF9faTM4NiAtRF9faTM4Nl9fIC1EX190dW5lX2kz
ODZfXyBlcXVhbC1ub3QtZXF1YWwuYyBlcXVhbC1ub3QtZXF1YWwuaQogKiBHTlUgQ1BQIHZlcnNp
b24gMy4yLjEgMjAwMjA5MjQgKERlYmlhbiBwcmVyZWxlYXNlKSAoY3BwbGliKSAoaTM4NiBMaW51
eC9FTEYpCiAqIGlnbm9yaW5nIG5vbmV4aXN0ZW50IGRpcmVjdG9yeSAiL3Vzci9pMzg2LWxpbnV4
L2luY2x1ZGUiCiAqICNpbmNsdWRlICIuLi4iIHNlYXJjaCBzdGFydHMgaGVyZToKICogI2luY2x1
ZGUgPC4uLj4gc2VhcmNoIHN0YXJ0cyBoZXJlOgogKiAgL3Vzci9sb2NhbC9pbmNsdWRlCiAqICAv
dXNyL2xpYi9nY2MtbGliL2kzODYtbGludXgvMy4yLjEvaW5jbHVkZQogKiAgL3Vzci9pbmNsdWRl
CiAqIEVuZCBvZiBzZWFyY2ggbGlzdC4KICogIC91c3IvbGliL2djYy1saWIvaTM4Ni1saW51eC8z
LjIuMS9jYzEgLWZwcmVwcm9jZXNzZWQgZXF1YWwtbm90LWVxdWFsLmkgLXF1aWV0IC1kdW1wYmFz
ZSBlcXVhbC1ub3QtZXF1YWwuYyAtTyAtdmVyc2lvbiAtbyBlcXVhbC1ub3QtZXF1YWwucwogKiBH
TlUgQ1BQIHZlcnNpb24gMy4yLjEgMjAwMjA5MjQgKERlYmlhbiBwcmVyZWxlYXNlKSAoY3BwbGli
KSAoaTM4NiBMaW51eC9FTEYpCiAqIEdOVSBDIHZlcnNpb24gMy4yLjEgMjAwMjA5MjQgKERlYmlh
biBwcmVyZWxlYXNlKSAoaTM4Ni1saW51eCkKICogICAgICAgICBjb21waWxlZCBieSBHTlUgQyB2
ZXJzaW9uIDMuMi4xIDIwMDIwOTI0IChEZWJpYW4gcHJlcmVsZWFzZSkuCiAqICBhcyAtViAtUXkg
LW8gZXF1YWwtbm90LWVxdWFsLm8gZXF1YWwtbm90LWVxdWFsLnMKICogR05VIGFzc2VtYmxlciB2
ZXJzaW9uIDIuMTMuOTAuMC4xMCAoaTM4Ni1saW51eCkgdXNpbmcgQkZEIHZlcnNpb24gMi4xMy45
MC4wLjEwIDIwMDIxMDEwIERlYmlhbiBHTlUvTGludXgKICogIC91c3IvbGliL2djYy1saWIvaTM4
Ni1saW51eC8zLjIuMS9jb2xsZWN0MiAtLWVoLWZyYW1lLWhkciAtbSBlbGZfaTM4NiAtZHluYW1p
Yy1saW5rZXIgL2xpYi9sZC1saW51eC5zby4yIC91c3IvbGliL2djYy1saWIvaTM4Ni1saW51eC8z
LjIuMS8uLi8uLi8uLi9jcnQxLm8gL3Vzci9saWIvZ2NjLWxpYi9pMzg2LWxpbnV4LzMuMi4xLy4u
Ly4uLy4uL2NydGkubyAvdXNyL2xpYi9nY2MtbGliL2kzODYtbGludXgvMy4yLjEvY3J0YmVnaW4u
byAtTC91c3IvbGliL2djYy1saWIvaTM4Ni1saW51eC8zLjIuMSAtTC91c3IvbGliL2djYy1saWIv
aTM4Ni1saW51eC8zLjIuMS8uLi8uLi8uLiBlcXVhbC1ub3QtZXF1YWwubyAtbGdjYyAtbGdjY19l
aCAtbGMgLWxnY2MgLWxnY2NfZWggL3Vzci9saWIvZ2NjLWxpYi9pMzg2LWxpbnV4LzMuMi4xL2Ny
dGVuZC5vIC91c3IvbGliL2djYy1saWIvaTM4Ni1saW51eC8zLjIuMS8uLi8uLi8uLi9jcnRuLm8K
ICovCgovKiBSZXR1cm5zIGV4YWN0bHkgd2hhdCBpdCdzIGdpdmVuLiAqLwpzdGF0aWMgaW50Cmp1
c3RfdGhhdChpbnQgeCkKewogIHJldHVybiB4Owp9CgppbnQKbWFpbigpCnsKICBkb3VibGUgIGRb
XSA9IHs0LjUsIDMuMCwgOC4wIC8gMy4wfTsKICBkb3VibGUgIHN1bTEgPSAwLjA7CiAgZG91Ymxl
ICBzdW0yID0gMC4wOwogIGludCAgICAgaTsKICBpbnQgICAgIGVxMDsKICBpbnQgICAgIGVxMTsK
CiAgLyogU3VtIG51bWJlcnMgZnJvbSBkW10gaW50byBzdW0xLiAqLwogIGZvcihpID0gMDsgaSA8
IDM7ICsraSkKICAgIHN1bTEgKz0gZFtpXTsKCiAgLyogU3VtIG51bWJlcnMgZnJvbSBkW10gaW50
byBzdW0yLiAgWWVzLCB3ZSd2ZSBiZWVuIGhlcmUgYmVmb3JlLiAgVGhlIHJlc3VsdAogICAqICpz
aG91bGQqIGJlIGlkZW50aWNhbC4gKi8KICBmb3IoaSA9IDA7IGkgPCAzOyArK2kpCiAgICBzdW0y
ICs9IGRbaV07CgogIC8qIGp1c3RfdGhhdCgpIHJldHVybnMgZXhhY3RseSB3aGF0IHlvdSBnaXZl
IGl0LCBidXQgZm9yIG91ciBwdXJwb3NlcyBkb2VzCiAgICogbm90IGhhdmUgdGhlIHNhbWUgYWZm
ZWN0IGFzIGRpcmVjdGx5IHNheWluZyAiZXEwID0gc3VtMSA9PSBzdW0yIi4gIEFmdGVyCiAgICog
dGhpcyBvcGVyYXRpb24sIGVxMCBzaG91bGQgYmUgMS4gIFdoZW4gb3B0aW1pc2luZyBhbmQgcnVu
bmluZyB1bmRlciBMaW51eAogICAqIG9uIGEgdmFyaWV0eSBvZiB4ODYgcGxhdGZvcm1zIChvbGQg
UGVudGl1bSwgQU1EIEs2LTMrLCBBdGhsb24gWFApLCBpdCBoYXMKICAgKiB2YWx1ZSAwIC0gaS5l
LiB0aGUgcmVzdWx0IG9mIHRoZSBhYm92ZSB0d28gaWRlbnRpY2FsIHN1bW1hdGlvbiBvcGVyYXRp
b25zCiAgICogaXMgbm90IHRoZSBzYW1lIHR3byB0aW1lcyBydW5uaW5nLiAqLwogIGVxMCA9IGp1
c3RfdGhhdChzdW0xID09IHN1bTIpOwoKICAvKiBCdXQgaWYgd2UncmUgc3VycHJpc2VkIGJ5IHRo
aXMsIGRvIGEgZG91YmxlIHRha2UsIGFuZCBhc2sgYWdhaW4sIHdlIGdldCBhCiAgICogMSB0aGlz
IHRpbWUgYXJvdW5kLiAgU28gdGhlIHdyb25nIGFuc3dlciBzZWVtcyB0byBiZSBhdmFpbGFibGUg
b25seQogICAqIG1vbWVudGFyaWx5LiAgQ3JhenkuICovCiAgZXExID0ganVzdF90aGF0KHN1bTEg
PT0gc3VtMik7CgogIHJldHVybiBlcTAgPT0gMSAmJiBlcTEgPT0gMSA/IDAgOiAxOwp9Cg==

Re: optimization/8959: gcc-2.95/3.2 add/subtract results are wrong for a short time when optimising on x86

[ehrhardt]

Synopsis: gcc-2.95/3.2 add/subtract results are wrong for a short time when optimising on x86

State-Changed-From-To: open->closed
State-Changed-By: cae
State-Changed-When: Mon Dec 16 06:53:21 2002
State-Changed-Why:
    You cannot reliably use == with float values not even in your case.
    Most likely what happens is that the first comparison compares a
    saved value of sum1 with the value computed for sum2 that is still
    in some register. As registers have higher precision than memory values
    (i.e. storing a float/double value to memory truncates the value)
    the precision of sum2 is higher than that of sum1, consequently the
    values are different. The first call to just_that will force the compiler
    to write sum2 to memory and truncate the value along the way. Thus the
    result of the second comparison is true because both values were stored
    and truncated.
    
        regards   Christian

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8959