problems with constructors

["C. van Reeuwijk" <C dot vanReeuwijk at twi dot tudelft dot nl>]

I'm sorry I cannot provide a small test program, but in this case it
would take a lot of work, and I'm not sure I can do it in a reasonable
time. I can only hope that reporting it in this form somehow helps to
nail the bug earlier.

I'm having problems with some class constructors in one of my programs.
It appears that in some circumstances the code that implements the
constructor of a class does not return 'this', but an unspecified
value. It does not seem to be an optimizer bug, since it occurs even
without any optimizations on.

A constructor like this (details shown to indicate they're not so
complicated):

------------
WordListIndex::WordListIndex()
{
    magic = 0x576c552;                  // 'WlXI'
    stamppos = (long) header_sz;
    header_sz += sizeof( uint32 );
    fprintf( stderr, "WordListIndex: this = %p\n", this );
}
------------

would be used like this:

------------
    fullindex = new WordListIndex();
    fprintf( stderr, "fullindex = %p\n", fullindex );
------------

During a run it would produce something like

this = 0x40934fd8
fullindex = 0x40934ff8

Which shows that something is wrong. Unfortunately, I have not been able
to take it any further than that. Constructors work for most classes,
but for this class, and a number of sibling classes, something is wrong.

Details of my setup (the bug has been there in at least the october
snapshots):

falcon:~/notebase> g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.92.17/specs
gcc version egcs-2.92.17 19981025 (gcc2 ss-980609 experimental)

The latest snapshot gives complaints about vararg functions, and I didn't
have the time to sort that out.

I'm running Debian 2.0, which implies Linux 2.0.35 and libc6.


Reducing this to a small test case is problematic, since the error only
occurs at run-time, and the failing classes are deeply entangled in
the program.

Upon request I am happy to provide assembly for the code fragments
I've shown.

-- 
Kees van Reeuwijk, Delft University of Technology
http://www.pds.twi.tudelft.nl/~reeuwijk