gc problem with nested functions

Jeffrey A Law law@cygnus.com
Fri Oct 15 02:11:00 GMT 1999

  In message <Pine.LNX.4.10.9909131632570.3332-100000@biriani.cygnus.co.uk>you 
  > > No, I don't want to try that either.  But I think there is a simpler
  > > solution, which is to have a separate obstack for memory allocated in
  > > immed_double_const.  I'll try to come up with a patch for this quickly.
  > > This should be a temporary fix, until we enable GC for all frontends.
  > Here's a patch that changes varasm.c so that all constants get allocated on
  > a different, permanent obstack.  This means we are leaking a bit of memory.
  > An alternative would be to have per-function obstacks for constants, but I'
  > m
  > not entirely sure whether this would cause problems for static variables
  > declared inside a function (i.e. if we allocate constants for their
  > initializers, do we need to keep these constants around past the compilatio
  > n
  > of the enclosing function?).
  > All in all I'm not convinved that this is indeed a better solution than you
  > r
  > fix.  (Note however that your change only changed immed_double_const, but t
  > he
  > same problem exists in immed_real_const_1).
  > Tested on i686-linux, but that's not very meaningful, as the bug isn't
  > reproducible with check-gcc on that target.
  > Bernd
  > 	* varasm.c (constants_obstack): New.
  > 	(init_varasm_once): Initialize it.
  > 	(immed_double_const): Allocate constants on this obstack.
  > 	(immed_real_const_1): Likewise.
Did this issue ever get resolved?


More information about the Gcc-patches mailing list