gc problem with nested functions

[Jeffrey A Law]

  In message <Pine.LNX.4.10.9909131632570.3332-100000@biriani.cygnus.co.uk>you 
write:
  > > 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.
It could be significant for languages where nested functions are common;
pascal and modula 2 come immediately to mind, there may be others.

However, I would consider this relatively minor issue as we'll hopefully move
Pascal, Modula, etc to garbage collection soon after they're integrated.



  > 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
  > compilation of the enclosing function?).
I believe you would have to keep the constants, or at least provide some way
to mark those entries as invalid to prevent a parent function from trying to
re-use that constant.


  > All in all I'm not convinved that this is indeed a better solution than
  > your fix.  (Note however that your change only changed immed_double_const,
  >  but the 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.
I can live with this patch if you're reasonably happy with it.  

jeff