User account creation filtered due to spam.

Bug 13418 - optimized code calls operator delete before finishing destructor
Summary: optimized code calls operator delete before finishing destructor
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2003-12-16 18:49 UTC by Steve Reinhardt
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

bzip2'ed .ii file (80.71 KB, application/octet-stream)
2003-12-16 18:50 UTC, Steve Reinhardt

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Reinhardt 2003-12-16 18:49:24 UTC
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 -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.
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/cc1plus -fpreprocessed
fast_alloc.ii -quiet -dumpbase -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 (i386-redhat-linux) using BFD version 20030206
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ /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
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/crtend.o /usr/lib/crtn.o
Comment 1 Steve Reinhardt 2003-12-16 18:50:21 UTC
Created attachment 5345 [details]
bzip2'ed .ii file
Comment 2 Falk Hueffner 2003-12-16 18:56:31 UTC
The reinterpret_casts smell a bit of aliasing violations. Does
-fno-strict-aliasing help?
Comment 3 Steve Reinhardt 2003-12-16 19:15:25 UTC
(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.

Comment 4 Andrew Pinski 2003-12-16 19:18:00 UTC
Closing as you are violating aliasing rules.
Comment 5 Andrew Pinski 2005-06-05 08:33:27 UTC
Reopening to ...
Comment 6 Andrew Pinski 2005-06-05 08:33:43 UTC
Mark as a dup of bug 21920.

*** This bug has been marked as a duplicate of 21920 ***