This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH][C] Fix GNU extern inline heuristic again (fix C++ memory usage regression)
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Richard Guenther'" <rguenther at suse dot de>, <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 27 Aug 2007 15:59:52 +0100
- Subject: RE: [PATCH][C] Fix GNU extern inline heuristic again (fix C++ memory usage regression)
- References: <Pine.LNX.4.64.0708271509250.4343@s68.fhfr.qr>
On 27 August 2007 14:12, Richard Guenther wrote:
> --- 3302,3334 ----
> {
> struct tree_decl_non_common common;
>
> + struct function *f;
> +
> /* In a FUNCTION_DECL for which DECL_BUILT_IN holds, this is
> ! DECL_FUNCTION_CODE. Otherwise unused.
> ! ??? The bitfield needs to be able to hold all target function
> ! codes as well. */
> ! ENUM_BITFIELD(built_in_function) function_code : 10;
> ! ENUM_BITFIELD(built_in_class) built_in_class : 2;
Couldn't this use a compile-time assertion of some sort? We're already
anything up to two-thirds of the way there, by the crudest possible measurement:
/gnu/gcc/gcc/gcc $ grep ^DEF_ builtins.def sync-builtins.def omp-builtins.def |
wc -l
685
> Index: c-decl.c
> ===================================================================
> *** c-decl.c.orig 2007-08-27 11:25:41.000000000 +0200
> --- c-decl.c 2007-08-27 14:01:38.000000000 +0200
> *************** finish_function (void)
> *** 6771,6776 ****
> --- 6776,6786 ----
> /* Finalize the ELF visibility for the function. */
> c_determine_visibility (fndecl);
>
> + /* For GNU C extern inline functions disregard inline limits. */
> + if (DECL_EXTERNAL (fndecl)
> + && DECL_DECLARED_INLINE_P (fndecl))
> + DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;
> +
> /* Genericize before inlining. Delay genericizing nested functions
> until their parent function is genericized. Since finalizing
> requires GENERIC, delay that as well. */
I don't understand why the comment says "GNU C extern inline functions". I
couldn't find any reason this wouldn't also affect C99 extern inline functions.
Is the comment just too specific?
cheers,
DaveK
--
Can't think of a witty .sigline today....