https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #52 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 > > --- Comment #51 from Venkataramanan <venkataramanan.kumar at amd dot com> --- > (In reply to rguent...@suse.de from comment #35) > > On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 > > > > > > --- Comment #34 from Venkataramanan <venkataramanan.kumar at amd dot com> > > > --- > > > Richard, What I understand is that instead of using tune flags for garbage > > > collection, need to try and fix the object code differences? > > > > Yes, it points at real bugs. OTOH fixing that may not be suitable > > for the release branches, neither is passing fixed values for GC > > parameters. So I'm not quite sure what a suitable workaround is > > (well, make sure !defined ENABLE_GC_CHECKING && !defined > > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 > > for bootstrap-lto, that is, init_ggc_heuristics () is executed > > in the same way) > > Hi richard, > > In Stage1 we add --enable-checking=yes,types and it sets ENABLE_GC_CHECKING > as > true > > In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the > check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT" > will be true for stage2 only. > > ENABLE_GC_ALWAYS_COLLECT is false in both stages. > > Do we need to make sure stage 1 and stage 2 executes the function > init_ggc_heuristics and will it set the parameters to same value? Well, it would be a workaround only. The real fix is to track down and fix all remaining issues we have with regarding to IL differences caused by collection changes. First one is fixed, 2nd one is not yet tracked down completely (feel free to continue - it takes a lot of time and I have other stuff to do right now)
