This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

oballoc, try_combine, and such



Folks --

  I just tracked down a nasty bug in the C++ front-end that might have
been more easily caught with some changes to the back-end.  In
particular, the C++ front-end was calling rest_of_compilation with
current_obstack and saveable_obstack set to permanent_obstack, rather
than the usual temporary_obstack and function_maybepermanent_obstack.
(Basically, we had pushed permanent obstacks and not popped them.)
Normally, this would just be a colossal and undetectable waste of
space.

  But, try_combine did:

  /* Save the current high-water-mark so we can free storage if we didn't
     accept this combination.  */
  undobuf.storage = (char *) oballoc (0);

Then, it called immed_double_const, which hooked something on the
const_double_chain.  Finally, it called:

      undo_all ();

which freed the memory, leaving the const_double_chain in tatters.
The tricky thing here is that immed_double_const inentionally
allocates on the saveable_obstack; try_combine is therefore implicitly
assuming that oballoc is not allocating from the saveable_obstack.  

  I suggest that we put in one or more of the following asserts:

    o That saveable_obstack != current_obstack in try_combine.
    o That current_obstack == temporary_obstack in oballoc.
    o ???

  I'm not sure what's most appropriate, here, but I'm sure that a
simple assert like this would help prevent another bug like this
popping up.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]