public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
@ 2002-11-01 0:46 Giovanni Bajo
0 siblings, 0 replies; 3+ messages in thread
From: Giovanni Bajo @ 2002-11-01 0:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c++/8417; it has been noted by GNATS.
From: "Giovanni Bajo" <bagio@zh.t2-design.com>
To: <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <germain@cs.utah.edu>,
<gcc-bugs@gcc.gnu.org>, <nobody@gcc.gnu.org>
Cc:
Subject: Re: c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
Date: Fri, 1 Nov 2002 16:38:07 +0800
This is a multi-part message in MIME format.
------=_NextPart_000_1771_01C281C5.0E6A1990
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
gcc&pr=3D8417
The value of this can be changed by the compiler at any time, there is =
no guarantee (in the C++ standard) that it remains the same across the =
derived class tree. For example, it is very usual that the value changes =
when you are using multiple inheritance. This is not a bug in the =
compiler.
------=_NextPart_000_1771_01C281C5.0E6A1990
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4916.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><A=20
href=3D"http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&a=
mp;database=3Dgcc&pr=3D8417">http://gcc.gnu.org/cgi-bin/gnatsweb.pl?c=
md=3Dview%20audit-trail&database=3Dgcc&pr=3D8417</A></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The value of this can be changed by the =
compiler at=20
any time, there is no guarantee (in the C++ standard) that it remains =
the same=20
across the derived class tree. For example, it is very usual that the =
value=20
changes when you are using multiple inheritance. This is not a bug in =
the=20
compiler.</FONT></DIV></BODY></HTML>
------=_NextPart_000_1771_01C281C5.0E6A1990--
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
@ 2002-11-01 17:50 bangerth
0 siblings, 0 replies; 3+ messages in thread
From: bangerth @ 2002-11-01 17:50 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, germain, nobody
Synopsis: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Fri Nov 1 17:50:01 2002
State-Changed-Why:
What you try is calling for trouble: you should not assume
anything about where member variables are located relative
to "this". Also, "this" may change from sub- to superclass,
depending on the layout of vtables, etc. You should only
try to zero out data pointed to by "this" if you absolutely
know what you do, and stick to the ABI that is relevant to
your platform.
This said, the ABI gcc uses on Linux has changed between
2.95 and 3.2, so the inconsistent behavior is not surprising.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8417
^ permalink raw reply [flat|nested] 3+ messages in thread
* c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
@ 2002-10-31 13:36 germain
0 siblings, 0 replies; 3+ messages in thread
From: germain @ 2002-10-31 13:36 UTC (permalink / raw)
To: gcc-gnats
>Number: 8417
>Category: c++
>Synopsis: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Oct 31 13:36:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Jim Germain
>Release: g++ 3.2
>Organization:
>Environment:
linux
>Description:
Greetings Compiler World.
I believe there is an error in the g++ 3.2 compiler that is not
present in the 2.95.4 compiler. (Unfortunately, because of the
complexity of the code involved I am not able to narrow this
down to a stand alone code junk. Hopefully the information
I can provide will help resolve the issue.)
Version Info:
Reading specs from /data3/germain/gcc/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ./configure --prefix=/data3/germain/gcc
Thread model: posix
gcc version 3.2
System: Linux (Debian)
The behavior that I am getting is that during a call to a superclass
constructor, the value of 'this' is different between the two calls.
Consider the following code:
// a function that simply calls the memory type constructor
// with the passed in or computed size of the object.
object_type::object_type( size_t s ) :
memory_block_type( s ? s : sizeof( object_type ) )
{
}
memory_block_type::memory_block_type(size_t size)
{
memset( this, 0, size ); // clear memory
memory_size = size; // set size field
}
under g++ 3.2, using gdb, I find that the value of 'this' in the
object_type constructor (and all sub class constructors, for that
matter) is correct and consistent. The call to the memory_block_type
constructor shows a value of 'this' 4 bytes offset from the proper
value. see below (where I am stepping down the stack list of
constructors. in each case the value of this is consistent until I
get to the final call to memory_block_type where it is 4 larger. (FYI
that the object_type is a super class of a list object, which is
a super class for an attirubte class, which is a super class for
a point class.)).
(gdb)
#4 0x0817ea6c in pt_obj (this=0x8c16d69) at /data1/germain/alpha1/src/lib/object/pt_ctors.C:73
(gdb) down
#3 0x08522a4f in attr_obj (this=0x8c16d69, s=80) at /data1/germain/alpha1/src/kernel/lib/alpha1/support/attr.C:19
(gdb) down
#2 0x08515667 in list_obj (this=0x8c16d69, s=80) at /data1/germain/alpha1/src/kernel/lib/alpha1/boot/list.C:23
(gdb) down
#1 0x0851a5de in object_type (this=0x8c16d69, s=80) at /data1/germain/alpha1/src/kernel/lib/alpha1/boot/object.C:25
(gdb) down
#0 memory_block_type (this=0x8c16d6d, size=80, this_check=0x8c16d69) at /data1/germain/alpha1/src/kernel/lib/alpha1/boot/memory_block.C:200
using g++ 2.95.4 the value of 'this' is consistent for all calls.
Here is the relevant assembly generated by the 2.95.4 compiler and the 3.2
compiler (disassembled via gdb).
2.95.4 (correct code (?))
0x8542340 <__11object_typeUi>: push %ebp
0x8542341 <__11object_typeUi+1>: mov %esp,%ebp
0x8542343 <__11object_typeUi+3>: sub $0x14,%esp
0x8542346 <__11object_typeUi+6>: push %ebx
0x8542347 <__11object_typeUi+7>: mov 0x8(%ebp),%ebx
0x854234a <__11object_typeUi+10>: add $0xfffffffc,%esp
0x854234d <__11object_typeUi+13>: push %ebx
0x854234e <__11object_typeUi+14>: mov 0xc(%ebp),%eax
0x8542351 <__11object_typeUi+17>: cmpl $0x0,0xc(%ebp)
0x8542355 <__11object_typeUi+21>: jne 0x854235c <__11object_typeUi+28>
0x8542357 <__11object_typeUi+23>: mov $0x1c,%eax
0x854235c <__11object_typeUi+28>: push %eax
0x854235d <__11object_typeUi+29>: push %ebx
0x854235e <__11object_typeUi+30>: call 0x853ea18 <__17memory_block_typeUiPv>
3.2 (code showing bad behavior)
0x851a5a8 <object_type>: push %ebp
0x851a5a9 <object_type+1>: mov %esp,%ebp
0x851a5ab <object_type+3>: push %ebx
0x851a5ac <object_type+4>: sub $0x24,%esp
0x851a5af <object_type+7>: mov 0x8(%ebp),%eax
0x851a5b2 <object_type+10>: add $0x4,%eax
0x851a5b5 <object_type+13>: mov %eax,(%esp,1)
0x851a5b8 <object_type+16>: mov 0xc(%ebp),%eax
0x851a5bb <object_type+19>: mov %eax,0xfffffff8(%ebp)
0x851a5be <object_type+22>: cmpl $0x0,0xc(%ebp)
0x851a5c2 <object_type+26>: jne 0x851a5cb <object_type+35>
0x851a5c4 <object_type+28>: movl $0x1c,0xfffffff8(%ebp)
0x851a5cb <object_type+35>: mov 0xfffffff8(%ebp),%eax
0x851a5ce <object_type+38>: mov %eax,0x4(%esp,1)
0x851a5d2 <object_type+42>: mov 0x8(%ebp),%eax
0x851a5d5 <object_type+45>: mov %eax,0x8(%esp,1)
0x851a5d9 <object_type+49>: call 0x8516e70 <memory_block_type>
i'm not an expert on the assembly codes, but i'm concerned by that add
command adding 4 to the eax register.
>How-To-Repeat:
see description. (but briefly, its buried deep in a complex system and i'm not
able to get a stand alone version...)
>Fix:
i hope you can help me....
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-11-02 1:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-01 0:46 c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4 Giovanni Bajo
-- strict thread matches above, loose matches on Subject: below --
2002-11-01 17:50 bangerth
2002-10-31 13:36 germain
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).