| Message ID | 006401d83648$fbdbc960$f3935c20$@nextmovesoftware.com |
|---|---|
| State | New |
| Headers | show |
| Series | PR middle-end/104885: Fix ICE with large stack frame on powerpc64. | expand |
On 3/12/2022 12:40 PM, Roger Sayle wrote: > My recent testcase for PR c++/84964.C stress tests the middle-end by > attempting to pass a UINT_MAX sized structure on the stack. Although > my fix to PR84964 avoids the ICE after sorry() on x86_64 and similar > targets, a related issue still exists on powerpc64 (and similar > ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't > issue a "sorry, unimplemented" message, but instead ICE elsewhere. > > After attempting several alternate fixes, the simplest solution is > to just defensively check in mark_stack_region_used that the upper > bound of the region lies within the allocated stack_usage_map > array, which is of size highest_outgoing_arg_in_use. When this isn't > the case, the code now follows the same path as for variable sized > regions, and uses stack_usage_watermark rather than a map. > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap > and make -k check to confirm there are no surprises, and with the cc1plus > of a cross-compiler to powerpc64-linux-gnu to confirm the new test > case no longer ICEs. Ok for mainline? > > > 2022-03-12 Roger Sayle <roger@nextmovesoftware.com> > > gcc/ChangeLog > PR middle-end/104885 > * calls.cc (mark_stack_region_used): Check that the region > is within the allocated size of stack_usage_map. OK jeff
On Sat, Mar 12, 2022 at 07:40:08PM -0000, Roger Sayle wrote: > My recent testcase for PR c++/84964.C stress tests the middle-end by > attempting to pass a UINT_MAX sized structure on the stack. Although > my fix to PR84964 avoids the ICE after sorry() on x86_64 and similar > targets, a related issue still exists on powerpc64 (and similar > ACCUMULATE_OUTGOING_ARGS/ARGS_GROW_DOWNWARD targets) which don't > issue a "sorry, unimplemented" message, but instead ICE elsewhere. > > After attempting several alternate fixes, the simplest solution is > to just defensively check in mark_stack_region_used that the upper > bound of the region lies within the allocated stack_usage_map > array, which is of size highest_outgoing_arg_in_use. When this isn't > the case, the code now follows the same path as for variable sized > regions, and uses stack_usage_watermark rather than a map. Thanks for the fix! Segher
diff --git a/gcc/calls.cc b/gcc/calls.cc index 50fa7b8..1ca96e7 100644 --- a/gcc/calls.cc +++ b/gcc/calls.cc @@ -201,7 +201,8 @@ mark_stack_region_used (poly_uint64 lower_bound, poly_uint64 upper_bound) { unsigned HOST_WIDE_INT const_lower, const_upper; const_lower = constant_lower_bound (lower_bound); - if (upper_bound.is_constant (&const_upper)) + if (upper_bound.is_constant (&const_upper) + && const_upper <= highest_outgoing_arg_in_use) for (unsigned HOST_WIDE_INT i = const_lower; i < const_upper; ++i) stack_usage_map[i] = 1; else