c++/8417: g++ 3.2 generating different (and incorrect?) code from g++ 2.95.4

[germain@cs.utah.edu]

>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: