This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: builtin_return_addr vs frame_pointer_needed vs -O3
- From: Richard Henderson <rth at redhat dot com>
- To: ian at beware dot dropbear dot id dot au
- Cc: dj at redhat dot com, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 26 Jun 2002 07:45:38 -0700
- Subject: Re: builtin_return_addr vs frame_pointer_needed vs -O3
- References: <200101312226.RAA29943@greed.delorie.com> <20010131170452.A13854@redhat.com> <15641.30554.720720.529367@gargle.gargle.HOWL>
On Wed, Jun 26, 2002 at 05:42:10PM +0930, Ian Dall wrote:
> The problem is, test4a() uses __builtin_return_address(1). Turning of
> FRAME_POINTER_REQUIRED for the current function if it accesses a
> previous frame does not work for __builtin_return_address(n) when n
> greater than 1. To do that, you need to ensure that there are frame
> pointers in all the intervening frames, not just the current frame.
True, but so what?
> It is not practical (or maybe even determinable) to work out all the
> functions which could be in the stack trace, so I think a better
> solution would be for RETURN_ADDR_RTX to do something like:
>
> ((COUNT > 0 && flag_omit_frame_pointer) ? NULL_RTX: GEN_RTX (...))
*shrug* Perhaps. My thought had been that just because this
translation unit uses flag_omit_frame_pointer doesn't mean
that the calling translation unit did. But on the other hand
I suppose it's a relatively safe assumption that the entire
application is compiled with the same cflags.
r~