On Fri, Mar 01, 2013 at 09:41:27AM +0100, Richard Biener wrote:
> On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers
> <jos...@codesourcery.com> wrote:
> > On Wed, 27 Feb 2013, Richard Biener wrote:
> >
> >> Wouldn't it be better to simply pass this using the variable size handling
> >> code? Thus, initialize args_size.var for too large constant size instead?
> >
> > Would that be compatible with the ABI definition of how a large (constant
> > size) argument should be passed?
>
> I'm not sure. Another alternative is to expand to __builtin_trap (), but
> that's
> probably not easy at this very point.
>
> Or simply fix the size calculation to not overflow (either don't count bits
> or use a double-int).
I don't think double_int will help us here. We won't detect overflow,
because we overflowed here (when lower_bound is an int):
lower_bound = INTVAL (XEXP (XEXP (arg->stack_slot, 0), 1));
The value from INTVAL () fits when lower_bound is a double_int, but
then:
i = lower_bound;
...
stack_usage_map[i]
the size of stack_usage_map is stored in highest_outgoing_arg_in_use,
which is an int, so we're limited by an int size here.
Changing the type of highest_outgoing_arg_in_use from an int to a
double_int isn't worth the trouble, IMHO.
Maybe the original approach, only with sorry () instead of error ()
and e.g. HOST_BITS_PER_INT - 1 instead of 30 would be appropriate
after all. Dunno.
Marek
