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: toon at moene dot indiv dot nluug dot nl
- Subject: Re: Finally a main line version that passes LAPACK's test suite ...
- From: craig at jcb-sc dot com
- Date: 26 Feb 1999 13:34:49 -0000
- Cc: egcs at egcs dot cygnus dot com
- Cc: craig at jcb-sc dot com
- References: <36D69A4F.3CC03D4A@moene.indiv.nluug.nl>
>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).
tq vm, (burley)