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