Ping.
On Tue, Mar 05, 2013 at 05:06:21PM +0100, Marek Polacek wrote: > 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
