gnu_inline attribute for C++

Jason Merrill jason@redhat.com
Fri Jul 13 19:39:00 GMT 2007


Alexandre Oliva wrote:
> On Jul 12, 2007, Jason Merrill <jason@redhat.com> wrote:
> 
>> Alexandre Oliva wrote:
> 
>>> +      if (!old_decl_gnu_inline)
>>> +	DECL_INTERFACE_KNOWN (newdecl) |= DECL_INTERFACE_KNOWN (olddecl);
>>> DECL_NOT_REALLY_EXTERN (newdecl) |= DECL_NOT_REALLY_EXTERN (olddecl);
>>> DECL_COMDAT (newdecl) |= DECL_COMDAT (olddecl);
> 
>> It seems to me that if we don't copy DECL_INTERFACE_KNOWN from a
>> previous gnu_inline declaration, we shouldn't copy the other linkage
>> flags either.
> 
> Both will work, we know the state of those flags when we get at that
> point anyway, and they're work the way they are.  I could take that
> out if you think it's important.

Please; I think the logic is clearer if all those flags are controlled 
by the if.

>>> +      if (DECL_INITIAL (nt) && DECL_INITIAL (ot)
>>> +	  && (!DECL_DECLARED_INLINE_P (ot)
>>> +	      || !lookup_attribute ("gnu_inline",
>>> +				    DECL_ATTRIBUTES (ot))
>>> +	      || TREE_USED (ot)
>>> +	      || (DECL_DECLARED_INLINE_P (nt)
>>> +		  && lookup_attribute ("gnu_inline",
>>> +				       DECL_ATTRIBUTES (nt)))))
> 
>> Checking TREE_USED in redeclaration_error_message seems incompatible
>> with the change in duplicate_decls to force out debug info for a
>> function that might have been inlined.  Do we want to allow people to
>> redefine gnu_inline functions that have previously been called, or
>> not? I think we do.
> 
> We would, but since C++ is always unit-at-a-time, this never happens,
> so I didn't worry too much about ensuring it would work.  I tried to
> keep it relatively similar to C where it made some sense, but that's
> no guarantee that it would work without unit-at-a-time.

Ah, in that case I probably wouldn't bother adding the 
!flag_unit_at_a_time code in duplicate_decls.  There isn't any other 
code in the C++ front end that checks the flag.

And I'm still not clear why you check TREE_USED in the quoted code.

Jason



More information about the Gcc-patches mailing list