Real purpose for failure in "Too restrictive sanity check"

Jan Hubicka jh@suse.cz
Thu May 11 07:15:00 GMT 2000


> I tried to bootstrap the PA64 port, but it's still failing the test in
> calls.c:
Jeff, 
I just looking at PA machine description to figure out what might be wrong.
I believe that bug is not dirrectly in calls.c, since pa is
ACCUMULATE_OUTGOING_ARGS so pointer is constant in most cases and
missalignment can´t be introduced.  (again knowing of testcase would
help in this speculations).  I believe that problem will be related to
some other code handling stack pointer, perhaps alloca.
One of oddities that caugt my attention is that STACK_BOUNDARY is
128, while BIGGEST_BOUNDARY is only 64.

There may be some code aligning to BIGGEST_BOUNDARY where STACK_BOUNDARY
is necesary and also this setup looks nonsential to me.

Also I am not quite sure, whether calls code is able to handle cases
where STACK_BOUDNARY is greater than PARM_BOUNDARY, but it ought to
not be issue on ACCUMULATE_OUTGOING_ARGS.

Another (unrelated bit) is:
/* Keep the stack pointer constant throughout the function.
   This is both an optimization and a necessity: longjmp
   doesn't behave itself when the stack pointer moves within
   the function!  */
#define ACCUMULATE_OUTGOING_ARGS 1

WHats about functions containing alloca for calls where we pleallocate
(that happends for variable sized arguments (is this in use at all?)
and for large argument blocks I believe).

Honza
> 
> jeff


More information about the Gcc-patches mailing list