This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
- From: "jamborm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 20 Apr 2011 17:25:03 +0000
- Subject: [Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
- Auto-submitted: auto-generated
- References: <bug-48585-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585
--- Comment #8 from Martin Jambor <jamborm at gcc dot gnu.org> 2011-04-20 17:24:04 UTC ---
Looking into this a bit more, this has probably nothing to do with
IPA-CP at all. When I dump the body of the function being inlined I
get:
--------------------------------------------------
(gdb) call debug_function (id->src_fn, 0)
__base_ctor (struct XalanDOMStringPool * const this, long unsigned int
theBlockSize, long unsigned int theBucketCount, long unsigned int
theBucketSize)
{
struct XalanDOMStringHashTable * D.46218;
struct XalanDOMStringAllocator * D.46217;
<bb 2>:
this_1(D)->_vptr.XalanDOMStringPool =
&_ZTVN10xalanc_1_818XalanDOMStringPoolE[2];
D.46217_2 = &this_1(D)->m_stringAllocator;
__comp_ctor (D.46217_2, theBlockSize_3(D));
this_1(D)->m_stringCount = 0;
D.46218_4 = &this_1(D)->m_hashTable;
__comp_ctor (D.46218_4, theBucketCount_5(D), theBucketSize_6(D));
<bb 3>:
return;
<L0>:
__comp_dtor (D.46217_2);
resx 1
}
--------------------------------------------------
Yet when I look up the function in the pre-LTO release_ssa dump, I
see:
--------------------------------------------------
xalanc_1_8::XalanDOMStringPool::XalanDOMStringPool(unsigned long, unsigned
long, unsigned long) (struct XalanDOMStringPool * const this, block_size_type
theBlockSize, bucket_count_type theBucketCount, bucket_size_type theBucketSize)
{
struct XalanDOMStringHashTable * D.22278;
struct AllocatorType * D.22277;
<bb 2>:
this_1(D)->_vptr.XalanDOMStringPool =
&_ZTVN10xalanc_1_818XalanDOMStringPoolE[2];
D.22277_2 = &this_1(D)->m_stringAllocator;
xalanc_1_8::XalanDOMStringAllocator::XalanDOMStringAllocator (D.22277_2,
theBlockSize_3(D));
this_1(D)->m_stringCount = 0;
D.22278_4 = &this_1(D)->m_hashTable;
xalanc_1_8::XalanDOMStringHashTable::XalanDOMStringHashTable (D.22278_4,
theBucketCount_5(D), theBucketSize_6(D));
<bb 3>:
return;
<L0>:
xalanc_1_8::XalanDOMStringAllocator::~XalanDOMStringAllocator (D.22277_2);
resx 1
}
The call to the destructor is already there, it almost looks like we
lost the part of the call graph that represents it somewhere in
streaming, WPA, partitioning or streaming for LTRANS...