This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR 18096: Diagnose stack frame overflow in rs6000.c


The following patch is my proposed fix to PR middle-end/18096 which is
an ICE on valid, attempting to compile a function with a ridiculously
large stack frame.  On many platforms we just silently generate incorrect
code, but for the rs6000 backend, we generate an unrecognizable insn.

My proposed fix is to tweak "rs6000_emit_allocate_stack" to correctly
use gen_int_mode rather than GEN_INT to correct the problem, but then
to clear my conscience I also check for such an overflow, and generate
a diagnostic warning, and emit a trap instruction, such that if the
function is ever called at run-time we abort rather than introduce
undefined behaviour.

I'm not sure if this sort of stack frame overflow can be detected and
diagnosed in the middle-end, as frame calculations (including padding,
alignment etc...) are typically target specific.  In this case, using
gen_int_mode is clearly the correct thing to ensure that CONST_INTs
are correctly extended for their modes.

The following patch has been tested on powerpc-unknown-linux-gnu with
a full "make bootstrap", all default languages, and regression tested
with a top-level "make -k check" with no new failures.

Ok for mainline?  I'd also appreciate it if someone could annotate the
bugzilla PR to confirm this isn't a regression from 2.95 or 3.2.  TIA.



2004-10-30  Roger Sayle  <roger@eyesopen.com>

	PR middle-end/18096
	* config/rs6000/rs6000.c (rs6000_emit_allocate_stack): Check that
	the stack adjustment, "size", is valid for Pmode.  If the stack
	frame is too large, generate a trap insn and issue a warning.

	* gcc.dg/PR18096-1.c: New test case.


Index: rs6000.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.732
diff -c -3 -p -r1.732 rs6000.c
*** rs6000.c	28 Oct 2004 22:32:41 -0000	1.732
--- rs6000.c	29 Oct 2004 22:48:18 -0000
*************** rs6000_emit_allocate_stack (HOST_WIDE_IN
*** 13111,13117 ****
    rtx insn;
    rtx stack_reg = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
    rtx tmp_reg = gen_rtx_REG (Pmode, 0);
!   rtx todec = GEN_INT (-size);

    if (current_function_limit_stack)
      {
--- 13111,13124 ----
    rtx insn;
    rtx stack_reg = gen_rtx_REG (Pmode, STACK_POINTER_REGNUM);
    rtx tmp_reg = gen_rtx_REG (Pmode, 0);
!   rtx todec = gen_int_mode (-size, Pmode);
!
!   if (INTVAL (todec) != -size)
!     {
!       warning("stack frame too large");
!       emit_insn (gen_trap ());
!       return;
!     }

    if (current_function_limit_stack)
      {


/* PR middle-end/18096  */
/* { dg-do compile { target powerpc-*-* } } */
/* { dg-options "-O2" } */

void f(char*);

void mkcatdefs(char *fname)
{
  char line [2147483647];
  f(line);
} /* { dg-warning "stack frame too large" "stack frame too large" } */


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]