From dda69cbfb766b86ee8f9e04d0256f660ced51342 Mon Sep 17 00:00:00 2001 From: Mark Shinwell Date: Mon, 12 Jun 2006 12:56:52 +0000 Subject: builtins.c (expand_builtin_return_addr): Only use frame_pointer_rtx when count == 0 and we are expanding... gcc/ * builtins.c (expand_builtin_return_addr): Only use frame_pointer_rtx when count == 0 and we are expanding __builtin_return_address. From-SVN: r114567 --- gcc/ChangeLog | 6 ++++++ gcc/builtins.c | 14 +++++++++----- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 475c36f..4569635 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 603106a..80f2fbb 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 { -- cgit v1.1