* [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64.
@ 2022-03-12 19:40 Roger Sayle
2022-03-19 18:35 ` Jeff Law
2022-04-06 18:52 ` Segher Boessenkool
0 siblings, 2 replies; 3+ messages in thread
From: Roger Sayle @ 2022-03-12 19:40 UTC (permalink / raw)
To: 'GCC Patches'
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
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.
Thanks in advance,
Roger
--
[-- Attachment #2: patchpp.txt --]
[-- Type: text/plain, Size: 583 bytes --]
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64.
2022-03-12 19:40 [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64 Roger Sayle
@ 2022-03-19 18:35 ` Jeff Law
2022-04-06 18:52 ` Segher Boessenkool
1 sibling, 0 replies; 3+ messages in thread
From: Jeff Law @ 2022-03-19 18:35 UTC (permalink / raw)
To: Roger Sayle, 'GCC Patches'
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64.
2022-03-12 19:40 [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64 Roger Sayle
2022-03-19 18:35 ` Jeff Law
@ 2022-04-06 18:52 ` Segher Boessenkool
1 sibling, 0 replies; 3+ messages in thread
From: Segher Boessenkool @ 2022-04-06 18:52 UTC (permalink / raw)
To: Roger Sayle; +Cc: 'GCC Patches'
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-04-06 18:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-12 19:40 [PATCH] PR middle-end/104885: Fix ICE with large stack frame on powerpc64 Roger Sayle
2022-03-19 18:35 ` Jeff Law
2022-04-06 18:52 ` Segher Boessenkool
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).