This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-1.1 release schedule
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Subject: Re: egcs-1.1 release schedule
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 22 Jun 1998 23:25:45 -0600
- cc: "David S. Miller" <davem at dm dot cobaltmicro dot com>, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <9806222039.AA04066@moene.indiv.nluug.nl>you write:
> PS: I agree with Jeff (even I don't know all the details
Quick lesson then :-) Ignore if you're not really interested in
the guts of why increasing STACK_BOUNDARY is a bad idea.
GCC assumes that the stack pointer must always be a multiple of
STACK_BOUNDARY. And it even has optimizations which use that info.
combine will actually notice cases where the masking off of low bits
should be unnecessary due to the value of STACK_BOUNDARY. ie if
STACK_BOUNDARY is 64, then ((sp + x) & 0xfffffffc)) can be resolved
to just (sp + x) (assuming X is a multiple of STACK_BOUNDARY).
This optimization will generate code which does not work if somehow
we get into a function where the stack is improperly aligned. The
canonical example would be a callback from libc like the comparison
routine for qsort.
jeff