Message ID | 2c5076c5-ef4a-1b9a-337a-e90e965af93f@acm.org |
---|---|
State | New |
Headers | show |
On 05/01/2017 04:23 PM, Nathan Sidwell wrote: > I happened to notice that stack adjustment code was confusingly testing > for an unsigned value being > 0. In this case unadjusted_alignment is > of type unsigned HOST_WIDE_INT, so the 'else' portion of the has no effect. > > This patch simplifies the adjustment to be less confusing (IMHO). > > booted and tested on x86_64-linux-gnu, ok? > OK I guess. It's not obvious what would happen with a wrong direction target, but the one we've got (PA) doesn't use this code because it's an ACCUMULATE_OUTGOING_ARGS target. It appears that the size passed in would always be positive (it's a size after all), but I couldn't guarantee that without a lot more auditing. Jeff
Index: gcc/calls.c =================================================================== --- gcc/calls.c (revision 247416) +++ gcc/calls.c (working copy) @@ -2644,13 +2644,8 @@ combine_pending_stack_adjustment_and_cal adjustment = pending_stack_adjust; /* Push enough additional bytes that the stack will be aligned after the arguments are pushed. */ - if (preferred_unit_stack_boundary > 1) - { - if (unadjusted_alignment > 0) - adjustment -= preferred_unit_stack_boundary - unadjusted_alignment; - else - adjustment += unadjusted_alignment; - } + if (preferred_unit_stack_boundary > 1 && unadjusted_alignment) + adjustment -= preferred_unit_stack_boundary - unadjusted_alignment; /* Now, sets ARGS_SIZE->CONSTANT so that we pop the right number of bytes after the call. The right number is the entire