This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 12 Jan 2015 14:34:36 +0000
- Subject: [Bug tree-optimization/63288] [5 Regression] gcc.c-torture/execute/20140326-1.c FAILs with -Og -fgcse -fif-conversion2
- Auto-submitted: auto-generated
- References: <bug-63288-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63288
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
PR60452 only taught rtx_addr_can_trap_p_1 about frame_pointer + offset,
the others are not handled right now:
/* ??? Need to add a similar guard for nonsensical offsets. */
if (x == hard_frame_pointer_rtx
|| x == stack_pointer_rtx
/* The arg pointer varies if it is not a fixed register. */
|| (x == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]))
return 0;
In this particular case it is the stack_pointer_rtx.
The question is how to derive limits on what is and what is not acceptable
around stack_pointer_rtx. Negative range needs to include red zone range if
any, positive can be very large if the current function uses VLAs or alloca
(but then hopefully the nonsensical offsets are used against frame/hard frame
pointer, not stack pointer).