g++ 3.4.1 core dump with -O2

[Ralf Fassel]

Hi all,
g++ 3.4.1 on IRIX 6.5.15m, core dump when compiling our program with
-O2 (or any level of optimization).

% g++ -v
Reading specs from 
/disk1/software/gcc/3.4.1/IRIX-6/bin/../lib/gcc/mips-sgi-irix6.5/3.4.1/specs
Configured with: /disk4/tmp/ralf/Software/gcc-3.4.1/configure 
--prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6 
--with-local-prefix=/work --enable-languages=c,c++ --enable-shared 
--disable-multilib : (reconfigured) 
/hosts/jupiter/disk4/tmp/ralf/Software/gcc-3.4.1/configure 
--prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6 
--with-local-prefix=/work --enable-languages=c,c++ --enable-shared 
--disable-multilib : (reconfigured) 
/hosts/jupiter/disk4/tmp/ralf/Software/gcc-3.4.1/configure 
--prefix=/software/gcc/3.4.1 --exec-prefix=/software/gcc/3.4.1/IRIX-6 
--with-local-prefix=/work --enable-languages=c,c++ --enable-shared 
--disable-multilib
Thread model: single
gcc version 3.4.1

We have a nasty coredump which occurs at all optimization level -O --
-O3, but is not present at -O0/-g.  It happens when our code executes
    new foo*[0]
i.e. tries to allocate an array of pointers of size 0.  The same call
executes several times w/o problems, and then reproducably crashes on
the same code position.  Other programs use the same library calls and
do not crash at that position.

Unfortunately gdb is not of much help (5.3 and 6.1.1), since it can't
make anything out of the stack in the core dump:
    Core was generated by `fweightx'.
    Program terminated with signal 10, Bus error.
    Reading symbols from 
/homes/ulrike/si++.4.0.C198/lib/mips/libsimath.so...done.
    Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libsimath.so
    Reading symbols from /homes/ulrike/si++.4.0.C198/lib/mips/libsi++.so...done.
    Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libsi++.so
    Reading symbols from /homes/ulrike/si++.4.0.C198/lib/mips/libhdio.so...done.
    Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libhdio.so
    Reading symbols from 
/homes/ulrike/si++.4.0.C198/lib/mips/libstdc++.so.7...done.
    Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libstdc++.so.7
    Reading symbols from /usr/lib32/libmx.so...done.
    Loaded symbols for /usr/lib32/libmx.so
    Reading symbols from /usr/lib32/libm.so...done.
    Loaded symbols for /usr/lib32/libm.so
    Reading symbols from 
/homes/ulrike/si++.4.0.C198/lib/mips/libgcc_s.so.1...done.
    Loaded symbols for /homes/ulrike/si++.4.0.C198/lib/mips/libgcc_s.so.1
    Reading symbols from /usr/lib32/libc.so.1...done.
    Loaded symbols for /usr/lib32/libc.so.1
    Reading symbols from /usr/lib32/libfpe.so...done.
    Loaded symbols for /usr/lib32/libfpe.so
    #0  0x0fa3a8bc in _aio_realloc_fds () at ainit.c:160
    160 ainit.c: No such file or directory.
            in ainit.c
    (gdb) where
    where
    #0  0x0fa3a8bc in _aio_realloc_fds () at ainit.c:160
    #1  0x0fa3a774 in _aio_sgi_init () at ainit.c:96
    warning: Warning: GDB can't find the start of the function at 0x809.

        GDB is unable to find the start of the function at 0x809
    and thus can't determine the size of that function's stack frame.
    This means that GDB may be unable to access that stack frame, or
    the frames below it.
        This problem is most likely caused by an invalid program counter or
    stack pointer.

The code right before the crash is

    std::cerr << "a1d:: " << (void*)this << " length/1, oldlen " <<
        len << " newlen " << newlen << std::endl; 
    type **nv = new type* [newlen];
    std::cerr << "a1d:: new DONE " << (void*)this << std::endl;

I can set a breakpoint at the middle line and confirm that newlen is
0 (non-negative).  Nevertheless the crash at `next' in the debugger
happens, and gdb can't `up' back to that code position.

I have tried to attach the dmalloc library, but if I use it in every
module, the error does not happen any longer.  Also no problems are
detected by dmalloc.

Since I would like to compile the library with -O (the same code runs
ok on HP with g++ 3.4.1, and on Windows using the 2003 .net compiler),
I would like to eliminate this problem :-/

Anybody any tips how to proceed further?

R'