Re: middle-end/9998: Lost update on bitfield manipulation via pointer

Re: middle-end/9998: Lost update on bitfield manipulation via pointer

[bangerth]

Synopsis: Lost update on bitfield manipulation via pointer

State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Mon Mar 10 15:31:35 2003
State-Changed-Why:
    This was fixed between 3.2 and 3.2.2:
    
    g/x> /home/bangerth/bin/gcc-3.2/bin/gcc -ggdb bug1.i -O2
    g/x> ./a.out
    0
    g/x> /home/bangerth/bin/gcc-3.2.2-pre/bin/gcc -ggdb bug1.i -O2
    g/x> ./a.out
    1
    
    However, you may be violating aliasing rules in your code,
    by accessing an object of type M as an object of type N.
    In fact, with gcc3.0.4, the code works as expected by
    using -fno-strict-aliasing:
    g/x> /home/bangerth/bin/gcc-3.0.4/bin/gcc -ggdb bug1.i -O0 && ./a.out
    1
    g/x> /home/bangerth/bin/gcc-3.0.4/bin/gcc -ggdb bug1.i -O2 && ./a.out
    0
    g/x> /home/bangerth/bin/gcc-3.0.4/bin/gcc -ggdb bug1.i -O2 -fno-strict-aliasing && ./a.out
    1
    
    It might therefore well be that the "fix" between 3.2 and
    3.2.2 just doesn't exercise rights to optimize, with your
    code still being faulty.
    
    3.3 and mainline work, by the way.
    
    W.

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

middle-end/9998: Lost update on bitfield manipulation via pointer

[eriksoe]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]


>Number:         9998
>Category:       middle-end
>Synopsis:       Lost update on bitfield manipulation via pointer
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 08 06:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Erik Søe Sørensen
>Release:        gcc version 3.1.1
>Organization:
>Environment:
(Red Hat Linux 7.3 2.96-113)
>Description:
Under certain circumstances involving two or more write operations on a bitfield, one of the writes may be lost.
The reason is that code like this is emitted:
	movl	8(%ebp), %ecx
	orb	$1, 8(%ebp)
        ...
	movl	%eax, 8(%ebp)
- the first two instructions are in the wrong order.

I first noticed this with gcc version 2.96 20000731 - which only generated wrong code with -O2 or higher; in gcc 3.1.1 the problem occurs even without optimizations.
>How-To-Repeat:
gcc -ggdb bug1.c -O0
The attached program ought to print '1'.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="bug1.i"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bug1.i"

IyAxICJidWcxLmMiCiMgMSAiPGJ1aWx0LWluPiIKIyAxICI8Y29tbWFuZCBsaW5lPiIKIyAxICJi
dWcxLmMiCmV4dGVybiBpbnQgcHJpbnRmKGNvbnN0IGNoYXIqIGZvcm1hdCwuLi4pOwoKc3RydWN0
IE0gewogICAgICAgIHVuc2lnbmVkIGEgOiAxOwogICAgICAgIHVuc2lnbmVkIGIgOiAyOwp9OwoK
c3RydWN0IE4gewogICAgICAgIHVuc2lnbmVkIGEgOiAxOwogICAgICAgIHVuc2lnbmVkIGIgOiAy
Owp9OwoKc3RydWN0IE4qIGZvbyhzdHJ1Y3QgTSBtKSB7CiAgICAgICAgc3RydWN0IE0gc2F2ZSA9
IG07CiAgICAgICAgc3RydWN0IE4gKm4gPSAoc3RydWN0IE4qKSAmbTsKICAgICAgICBuLT5hID0g
MTsKICAgICAgICBuLT5iID0gc2F2ZS5iXjI7CiAgICAgICAgcmV0dXJuIG47Cn0KCmludCBtYWlu
KCkgewogICAgICAgIHN0cnVjdCBNIG07CiAgICAgICAgc3RydWN0IE4qIG47CiAgICAgICAgbS5h
ID0gMDsKICAgICAgICBuPWZvbyhtKTsKICAgICAgICBwcmludGYoIiVkXG4iLCBuLT5hKTsKfQo=