From 1b74fde7ffa4a0a23401720de27f10b148dfbb97 Mon Sep 17 00:00:00 2001 From: shinwell Date: Mon, 12 Jun 2006 12:56:52 +0000 Subject: [PATCH 1/1] gcc/ * builtins.c (expand_builtin_return_addr): Only use frame_pointer_rtx when count == 0 and we are expanding __builtin_return_address. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@114567 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog | 6 ++++++ gcc/builtins.c | 14 +++++++++----- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 475c36fccae..45696359c28 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,9 @@ +2006-06-12 Mark Shinwell + + * builtins.c (expand_builtin_return_addr): Only use + frame_pointer_rtx when count == 0 and we are expanding + __builtin_return_address. + 2006-06-12 Fred Fish * config/mips/mips.c (mips_file_start): Create special section diff --git a/gcc/builtins.c b/gcc/builtins.c index 603106a6751..80f2fbbf4b7 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -509,12 +509,16 @@ expand_builtin_return_addr (enum built_in_function fndecl_code, int count) #else rtx tem; - /* For a zero count, we don't care what frame address we return, so frame - pointer elimination is OK, and using the soft frame pointer is OK. - For a nonzero count, we require a stable offset from the current frame - pointer to the previous one, so we must use the hard frame pointer, and + /* For a zero count with __builtin_return_address, we don't care what + frame address we return, because target-specific definitions will + override us. Therefore frame pointer elimination is OK, and using + the soft frame pointer is OK. + + For a non-zero count, or a zero count with __builtin_frame_address, + we require a stable offset from the current frame pointer to the + previous one, so we must use the hard frame pointer, and we must disable frame pointer elimination. */ - if (count == 0) + if (count == 0 && fndecl_code == BUILT_IN_RETURN_ADDRESS) tem = frame_pointer_rtx; else { -- 2.11.0