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]

Re: Finally a main line version that passes LAPACK's test suite ...



  In message <19990226133449.22215.qmail@deer>you write:
  > >A further disturbing feature of the 19990225 snapshot is that the
  > >forecast part of the run took 54 Megabytes of RSS (as reported by ps and
  > >top) in stark contrast with 43 Megabytes of the 19990127 snapshot.
  > >
  > >Note that this is *Resident* size, so we're not talking about unused
  > >virtual memory here, but memory that's really *used*.
  > >
  > >Unfortunately, due to the long time between the two successful runs,
  > >it's hard to pinpoint the change that brought this about.
  > 
  > Well, I noticed some "interesting" expansions in the stack-frame
  > sizes of compiled codes (from my private test suite), and the only
  > thing offhand I could see that might be responsible was:
  > 
  > Thu Feb 18 18:47:09 1999  Jeffrey A Law  (law@cygnus.com)
  > 
  > 	* function.c (assign_stack_temp_for_type): Round SIZE before calling
  > 	assign_stack_local for BLKmode slots.
  > 
  > But I haven't looked into whether that's the culprit, or even what
  > the patch *is*, yet, and probably won't have time.
  > 
  > Anyway, it seemed offhand as though COMPLEX variables were the ones
  > getting much more space allocated to them on the stack (at least).
This should have only put back previous behavior.  I've got a tweak from
John to that code, but I doubt either would be responsible for this kind of
increase in RSS.

The only way (of course) to find out is to debug the problem.

jeff


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