On Wed, Mar 13, 2013 at 1:57 PM, Marek Polacek <pola...@redhat.com> wrote: > Ping.
Ok. (yay, oldest patch in my review queue ...) Thanks, Richard. > 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
