Re: gnu_inline attribute for C++

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul 10, 2007, Mark Mitchell <mark@codesourcery.com> wrote:

> Alexandre Oliva wrote:
>> This patch introduces support for attribute gnu_inline in C++.  Since
>> extern inline in C++ doesn't have any special meaning, I decided not
>> to take it into account at all, and rely only on the presence of the
>> attribute along with inline to trigger the inline-only behavior, and
>> on their absence for the out-of-line version of the function.

> +In C++, this flag does not depend on @code{extern} in any way, but it
> +still requires the @code{inline} keyword to enable its special behavior.

> s|flag|attribute

Uhh, thanks.

> +	  if ((DECL_DECLARED_INLINE_P (old_result)
> +	       && lookup_attribute ("gnu_inline",
> +				    DECL_ATTRIBUTES (old_result)))
> +	      != (DECL_DECLARED_INLINE_P (new_result)
> +		  && lookup_attribute ("gnu_inline",
> +				       DECL_ATTRIBUTES (new_result)))

> If gnu_inline-ness only matters for functions otherwise declared inline,
> then we shouldn't need to check DECL_DECLARED_INLINE_P here.

And indeed we don't.  I left the tests for DECL_DECLARED_INLINE_P
before attribute lookups mainly as an optimization, because
lookup_attribute is potentially so inefficient.

> I'm not confident that you can undo the effects of
> DECL_INTERFACE_KNOWN and such after the fact, in the way that you're
> trying to do.

AFAICT we can, because C++ forces unit-at-a-time mode.  In which case
we completely ignore the gnu_inline definition.  It's simply
overridden by the non-gnu_inline definition, before we ever get a
chance to use the gnu_inline definition.

> I also don't understand the conditionalization here of setting things
> like DECL_EXTERNAL, etc.  Why does it make sense to do that only when
> one of the function is gnu_inline and the other is not?

The gnu_inline definition is always defined first, and it's always
inline-only, no-local-definition, whereas the non-gnu_inline
definition is always a local definition.

> Why doesn't it *always* make sense to use the values associated with
> whichever function is the definition?

I'm not sure I understand this question.

> And, why are we setting these, or using them, on the FUNCTION_DECLS that
> are DECL_TEMPLATE_RESULTS, instead of on the TEMPLATE_DECLs directly?

I just tried to follow existing practice.  I remember having tried
some variations, but they didn't work for various reasons, depending
on the order of introduction of the declarations, template
specializations et al.

> +	  bool olda = lookup_attribute ("gnu_inline",
> +					DECL_ATTRIBUTES (olddecl)) != NULL;

> This should become a gnu_inline_p() macro, just for tidyness.

Will do.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}