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