http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54332
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.8.0
--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-21
08:26:03 UTC ---
(In reply to comment #4)
> It was introduced between revision 189101 and revision 189664
> on cxx-conversion branch. Unfortunately, since branch was broken
> between those 2 revisions, I can't bisect further.
I only see
r189664 | dnovillo | 2012-07-19 16:40:11 +0200 (Thu, 19 Jul 2012) | 3 lines
Merge from trunk rev 189106.
"inbetween" those two revisions. r189668 is another merge from trunk,
so is r188963. So I suspect a mismerge in r189106, r188963 was
r188963 | dnovillo | 2012-06-25 23:10:33 +0200 (Mon, 25 Jun 2012) | 7 lines
Merge from trunk
Merged revisions
188725-188729,188731,188733,188738-188749,188751-188755,188759,
188764-188765,188771,188776,188778,188780-188789,188791-188796,188802-188808,188
814-188815,188818,188820-188824,188826-188827,188829,188833,188838,188840-188843
,188847,188849,188852-188853,188856-188860,188865-188872,188874-188876,188880-18
8881,188884-188885,188891,188893,188900-188902,188906-188909,188913,188915-18891
8,188922 via svnmerge from
svn+ssh://gcc.gnu.org/svn/gcc/trunk
HJ, maybe you can help narrowing down things by trying different optimization
levels? I see that using a memleak checker may not be possible with
10G memory usage.
Note that -fmem-report does not track all allocations, esp. heap hashtables
are not tracked.
