Re: gnu_inline attribute for C++

[Mark Mitchell <mark at codesourcery dot com>]

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

Is there a good case for having this in GNU C++, other than that it's in
GNU C?  I'm not saying that's not a good reason; just curious if there's
some other motivating force.

+	  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.  Instead,
discard gnu_inline attributes (with a warning or error) earlier.

+	      && DECL_INITIAL (new_result))
+	    {
+	      if (DECL_INITIAL (old_result))
+		{
+		  DECL_INLINE (old_result) = 0;
+		  DECL_UNINLINABLE (old_result) = 1;
+		}
+	      else
+		{
+		  DECL_INLINE (old_result) = DECL_INLINE (new_result);
+		  DECL_UNINLINABLE (old_result) = DECL_UNINLINABLE (new_result);
+		}

Doesn't something already check that we don't have DECL_INITIAL for both
NEW_RESULT and OLD_RESULT?  If we have DECL_INITIAL for both, that means
the function is defined twice, which should be an error.  Or does
gnu_inline allow you to override the definition in the same translation
unit?  That's a pretty nasty complication.  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.

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?  Why doesn't it
*always* make sense to use the values associated with whichever function
is the definition?

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?
My opinion is that we should use one or the other, exclusively; I'm OK
with either option.  But, I'd rather not be in the situation where we
have to keep DECL_* consistent between the TEMPLATE_DECL and the
FUNCTION_DECL.

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

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

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713