Re: c++/1920: g++ -O1 optimization bug in casting a reference argument

Re: c++/1920: g++ -O1 optimization bug in casting a reference argument

["Martin v. Löwis"]

The following reply was made to PR c++/1920; it has been noted by GNATS.

From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= <martin@v.loewis.de>
To: mdejong@redhat.com,  gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org, 
 gcc-bugs@gcc.gnu.org,  nobody@gcc.gnu.org
Cc:  
Subject: Re: c++/1920: g++ -O1 optimization bug in casting a reference argument
Date: Sun, 29 Dec 2002 00:02:26 +0100

 Notice that the extension from (gcc)Lvalues explicitly rules out taking 
 the address of a cast lvalue. Following the rationale for this 
 restriction, I believe the extension should also not allow passing a 
 cast lvalue as a reference. In addition, -pedantic should produce 
 diagnostics if the extension is used.
 
 Regards,
 Martin
 

Re: c++/1920: g++ -O1 optimization bug in casting a reference argument

[Wolfgang Bangerth]

The following reply was made to PR c++/1920; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/1920: g++ -O1 optimization bug in casting a reference argument
Date: Wed, 30 Oct 2002 20:03:32 -0600 (CST)

 The code in question invokes a gcc extension, casts as lvalues. The 
 manual says about this:
 
 >   Standard C++ allows compound expressions and conditional expressions
 > as lvalues, and permits casts to reference type, so use of this
 > extension is deprecated for C++ code.
 
 Still, if the compiler accepts the syntax, then it should get it right.
 
 W.
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

c++/1920: g++ -O1 optimization bug in casting a reference argument

[mdejong]

>Number:         1920
>Category:       c++
>Synopsis:       g++ -O1 optimization bug in casting a reference argument
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 09 01:26:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     mdejong@redhat.com
>Release:        unknown-1.0
>Organization:
>Environment:
I ran into this bug on a Red Hat Linux 6.2 (Intel) box.
>Description:
I tested this with older gccs (like 2.95.2) and with
a CVS snapshot from 02-04-2001, both display problems
when -O1 is used.

% g++ -v
Reading specs from /mnt/image/install_egcs/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.97/specs
Configured with: ../egcs/configure --prefix=/export/home/mdejong/jazz/install_egcs --enable-shared --enable-haifa --enable-threads=posix --enable-languages=c,c++,java --enable-java-gc=boehm --enable-fast-character
gcc version 2.97 20010204 (experimental)

>How-To-Repeat:
Compile without optimization, the compile
with optimization to see the bug in action.

% g++ -g -o foo foo.cc
% ./foo 
OK

% g++ -O1 -o foo foo.cc
% ./foo
ERROR : 40000000 80, should be 800000 80


When compiled with -O1, the following
asm code is generated for Foo::bar()

1	0x8048620	<Foo::bar(unsigned&)>:		        push   %ebp
2	0x8048621	<Foo::bar(unsigned&)+1>:		mov    %esp,%ebp
3	0x8048623	<Foo::bar(unsigned&)+3>:		mov    0xc(%ebp),%eax
4	0x8048626	<Foo::bar(unsigned&)+6>:		movl   $0x800000,(%eax)
5	0x804862c	<Foo::bar(unsigned&)+12>:		mov    $0x80,%eax
6	0x8048631	<Foo::bar(unsigned&)+17>:		pop    %ebp
7	0x8048632	<Foo::bar(unsigned&)+18>:		ret    


The ptr %eax was 0xbffff4a0, printing out this memory before
and after step 4 shows that it was changed from 0x40000000
to 0x00800000.

The problem is, the memory written to does not seem
to be the same memory location where the calling frame
thinks a lives. The calling frame seems to keep
a in the %ebx register, when returning from the
function you can see that the original a has
not been modified but the memory has.

(gdb) printf "%x",a
40000000
(gdb) printf "%x",*0xbffff4a0
800000
(gdb) print &a
Error: Address requested for identifier "a" which is in a register.

>Fix:

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

I2luY2x1ZGUgPHN0ZGlvLmg+CmNsYXNzIEZvbyB7CnB1YmxpYzoKICAgIGludCBiYXIodW5zaWdu
ZWQgJik7Cn07CgppbnQgRm9vOjpiYXIodW5zaWduZWQgJmJsYWgpIHsKICAgIGJsYWggPSAweDAw
ODAwMDAwOwogICAgcmV0dXJuIDEyODsKfQoKaW50IG1haW4gKGludCBhcmdjLCBjaGFyICoqYXJn
dikgewogICAgRm9vIGZvbzsKICAgIGludCBhID0gMHg0MDAwMDAwMDsKICAgIGludCBiID0gMDsK
ICAgIGIgPSBmb28uYmFyKCh1bnNpZ25lZCkgYSk7CiAgICBpZiAoYSA9PSAweDAwODAwMDAwICYm
CiAgICAgICAgYiA9PSAweDgwKSB7CiAgICAgICAgcHJpbnRmKCJPS1xuIik7CiAgICAgICAgcmV0
dXJuIDA7CiAgICB9IGVsc2UgewogICAgICAgIHByaW50ZigiRVJST1IgOiAleCAleCwgc2hvdWxk
IGJlICV4ICV4XG4iLCBhLCBiLCAweDAwODAwMDAwLCAweDgwKTsKICAgICAgICByZXR1cm4gMTsK
ICAgIH0KfQoK