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