Re: assign_stack_temp_for_type BLKmode size rounding

[John Wehle <john at feith dot com>]

> 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.

One reason that align might be incorrect is due to a bad LOCAL_ALIGNMENT
definition.  Aborting will increase the chances of this getting fix.
Keep in mind that LOCAL_ALIGNMENT is also use other places which don't
have your change which guarentees that BIGGEST_ALIGNMENT will be used
for BLKmode.  Actually ... this sort of begs the question of do we want
to check everywhere it's used?  And how is this macro any different from
CONSTANT_ALIGNMENT / DATA_ALIGNMENT which I don't believe we check?

> 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.

Saw the bug reports when I was catching up on my email and realize what
I broke when I started looking at it and saw your change.  I appreciate
you fixing my goof.

> 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.

Okay.

-- John