This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR13376
- From: Roger Sayle <roger at eyesopen dot com>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 11 Jan 2004 18:59:54 -0700 (MST)
- Subject: Re: PR13376
On Sun, 11 Jan 2004, Steven Bosscher wrote:
> Another attempt to fix the current_function_name issue. Roger, I
> don't like your suggestion to make current_function_name a define
> for lang_hooks.printable_name, because it would require including
> langhooks.h in more places...
>
> So I made it a function in function.c.
>
> * function.h (struct function): Kill `name' field.
> (current_function_name): Make it an extern function.
> * function.c (current_function_name): New function.
> * graph.c: Update all uses of current_function_name.
> * gcse.c: Likewise.
> * config/alpha/alpha.c, config/avr/avr.c, config/c4x/c4x.c,
> config/mips/mips.c, config/pdp11/pdp11.c: Likewise.
> * config/ip2k/ip2k.c (function_prologue): Use MAIN_NAME_P
> instead of a strcmp with "main".
This is OK for mainline. Thanks.
Another strategy that may also have worked is to name the function
"get_current_function_name" and then we could retain the macro form
current_function_name by defining it as "get_current_function_name()".
The suggestion to keep "current_function_name" as a macro was just
to minimize the number of files affected by such an "API" change.
Roger
--