assign_stack_temp_for_type BLKmode size rounding
Jeffrey A Law
law@hurl.cygnus.com
Wed Mar 3 23:20:00 GMT 1999
In message <199902250652.BAA27787@jwlab.FEITH.COM>you write:
> Some comments about your change:
>
> 1) Since align is never suppose to be less than BIGGEST_ALIGNMENT /
> BITS_PER_UNIT when mode == BLKmode I would be incline to call abort
> if it ever happens.
Yea, but the abort is easily avoided by giving proper alignment. True that
may hide a bug elsewhere. I'm not sure what's best here.
> 2) The comments:
>
> /* The following slot size computation is necessary because we don't
> know the actual size of the temporary slot until assign_stack_local
> has performed all the frame alignment and size rounding for the
> requested temporary. Note that extra space added for alignment
> can be either above or below this stack slot depending on which
> way the frame grows. We include the extra space if and only if it
> is above this slot. */
> #ifdef FRAME_GROWS_DOWNWARD
> p->size = frame_offset_old - frame_offset;
> #else
> p->size = size;
> #endif
>
> seem to indicate that ->size should not include rounding done
> for alignment and (if I recall correctly) the original code
> did not (in general) include the rounding done for alignment.
The original code passed -1 to assign_stack_local for the alignment, which
is magic -- it caused assign_stack_local to perform the alignment.
If you go back a few weeks you'll find several bug reports because of this --
we were getting unaligned accesses into the stack which caused processors
with strict alignment requirements to blow up.
I suspect that you're right and we should just align the parameter rather
than modifying "size". I'll start a bootstrap on my PA with your patch to
verify that we don't re-introduce any alignment problems.
Thanks,
jeff
More information about the Gcc-patches
mailing list