I have a simple object allocator that overrides the class new & delete
operators, and maintains simple bucketed linked lists of freed objects. This
code has worked with g++ since 1995 or so. It breaks with optimization on 3.3.1
and 3.3.2 because the code from operator delete that writes the free list
pointer at the head of the object gets executed *before* the object's vtable ptr
is twiddled for the call to the base class's destructor (at least I assume
that's what that store is for). The free list pointer is clobbered by the
vtable modification, meaning that some subsequent call to operator new treats
the vtable ptr as a pointer to a free memory block, leading eventually to a
The attached output is from g++ 3.3.2 on a RH9 machine, though I've seen the bug
also using g++ 3.3.1 on Debian.
output from gcc -v etc.:
eading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: /z/stever/gcc-3.3.2/configure --program-suffix=-3.3.2
Thread model: posix
gcc version 3.3.2
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/cc1plus -E -D__GNUG__=3 -quiet
-v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -D_GNU_SOURCE
fast_alloc.cc -Wall -O5 fast_alloc.ii
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
End of search list.
fast_alloc.ii -quiet -dumpbase fast_alloc.cc -auxbase fast_alloc -O5 -Wall
-version -o fast_alloc.s
GNU C++ version 3.3.2 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.2.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128721
as -V -Qy -o fast_alloc.o fast_alloc.s
GNU assembler version 220.127.116.11.18 (i386-redhat-linux) using BFD version
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
-L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../.. fast_alloc.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
Created attachment 5345 [details]
bzip2'ed .ii file
The reinterpret_casts smell a bit of aliasing violations. Does
(In reply to comment #2)
> The reinterpret_casts smell a bit of aliasing violations. Does
> -fno-strict-aliasing help?
Yes, that seems to take care of it (for my test case at least). Let me try to
fix it for my application and I'll close out the bug if that's all it is.
Closing as you are violating aliasing rules.
Reopening to ...
Mark as a dup of bug 21920.
*** This bug has been marked as a duplicate of 21920 ***