This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Finally a main line version that passes LAPACK's test suite ...
- To: craig at jcb-sc dot com
- Subject: Re: Finally a main line version that passes LAPACK's test suite ...
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Fri, 26 Feb 1999 12:41:36 -0700
- cc: toon at moene dot indiv dot nluug dot nl, egcs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
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