c/808: &&error is calculated incorrectly under -O2
wstearns@pobox.com
wstearns@pobox.com
Tue Nov 14 20:46:00 GMT 2000
>Number: 808
>Category: c
>Synopsis: &&error is calculated incorrectly under -O2
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Tue Nov 14 20:46:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: William Stearns
>Release: gcc version 2.96 20000731 (Red Hat Linux 7.0)
>Organization:
>Environment:
Linux sparrow.websense.net 2.4.0-test11 #37 Sun Nov 12 00:55:35 EST 2000 i686 unknown
RedHat Linux 7.0
glibc 2.1.94
>Description:
In the following code, the &&error is calculated incorrectly under -O2,
but correctly under normal optimization. This is the assembly under -O2:
Dump of assembler code for function __copy_from_user:
0x80484a0 <__copy_from_user>: push %ebp
0x80484a1 <__copy_from_user+1>: mov %esp,%ebp
0x80484a3 <__copy_from_user+3>: push %edi
0x80484a4 <__copy_from_user+4>: push %esi
0x80484a5 <__copy_from_user+5>: push %ebx
0x80484a6 <__copy_from_user+6>: sub $0x18,%esp
0x80484a9 <__copy_from_user+9>: push $0x80484a0
0x80484ae <__copy_from_user+14>: mov 0x8(%ebp),%edi
0x80484b1 <__copy_from_user+17>: mov 0xc(%ebp),%esi
0x80484b4 <__copy_from_user+20>: mov 0x10(%ebp),%ebx
0x80484b7 <__copy_from_user+23>: call 0x804848c <set_fault_addr>
The instruction at 0x80484a9 is calculating &&error as 0x80484a0, which is
the start of the procedure.
>How-To-Repeat:
>Fix:
Removing -O2 (reverting to -O1, I suppose) solves the
problem. Unfortunately, the Linux Kernel requires -O2, and
the function that triggered this problem is part of the
User Mode port of the Linux kernel.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="foo.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="foo.c"
I2luY2x1ZGUgPHN0ZGxpYi5oPgoKdm9pZCBzZXRfZmF1bHRfYWRkcih2b2lkICpwdHIpCnsKcHJp
bnRmKCJISVxuIik7Cn0KCmludCBfX2NvcHlfZnJvbV91c2VyKHZvaWQgKnRvLCBjb25zdCB2b2lk
ICpmcm9tLCBpbnQgbikgewogICAgICAgIGludCByZXQgPSAwOwoKICAgICAgICBzZXRfZmF1bHRf
YWRkcigmJmVycm9yKTsKICAgICAgICBtZW1jcHkodG8sIGZyb20sIG4pOwogICAgICAgIGdvdG8g
b3V0OwogZXJyb3I6CiAgICAgICAgcmV0ID0gbiAtICgodW5zaWduZWQgbG9uZykgZ2V0X2ZhdWx0
X2FkZHIoKSAtICh1bnNpZ25lZCBsb25nKSBmcm9tKTsKIG91dDoKICAgICAgICBzZXRfZmF1bHRf
YWRkcihOVUxMKTsKICAgICAgICByZXR1cm4ocmV0KTsKfQoKbWFpbigpCnsKcHJpbnRmKCJISVxu
Iik7Cl9fY29weV9mcm9tX3VzZXIoImEiLCAiYiIsIDEwMCk7Cn0K
More information about the Gcc-bugs
mailing list