c++ vs decl_external

c++ vs decl_external

[Richard Henderson]

Why is it that _all_ functions are marked DECL_EXTERNAL (in grokfndecl)?
I thought that was supposed to mean not-present-this-UOT.


r~

Re: c++ vs decl_external

[Mark Mitchell]

--On Wednesday, April 03, 2002 02:56:25 AM -0800 Richard Henderson 
<rth@redhat.com> wrote:

> Why is it that _all_ functions are marked DECL_EXTERNAL (in grokfndecl)?
> I thought that was supposed to mean not-present-this-UOT.

IIRC, they get unmarked later.  This is the 
slightly-odd-but-always-been-with-us DECL_NOT_REALLY_EXTERN bit.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: c++ vs decl_external

[Richard Henderson]

On Wed, Apr 03, 2002 at 01:19:02PM -0800, Mark Mitchell wrote:
> IIRC, they get unmarked later.  This is the 
> slightly-odd-but-always-been-with-us DECL_NOT_REALLY_EXTERN bit.

In a case I'm looking at, it doesn't.

I'll check in a patch and (failing) test case to mainline here
in a minute and someone familiar with that slightly-oddness can
look at it.  The problem is not urgent -- we simply fail to
emit an unused function warning when we ought.


r~

Re: c++ vs decl_external

[Mark Mitchell]

--On Wednesday, April 03, 2002 01:38:31 PM -0800 Richard Henderson 
<rth@redhat.com> wrote:

> On Wed, Apr 03, 2002 at 01:19:02PM -0800, Mark Mitchell wrote:
>> IIRC, they get unmarked later.  This is the
>> slightly-odd-but-always-been-with-us DECL_NOT_REALLY_EXTERN bit.
>
> In a case I'm looking at, it doesn't.
>
> I'll check in a patch and (failing) test case to mainline here
> in a minute and someone familiar with that slightly-oddness can
> look at it.  The problem is not urgent -- we simply fail to
> emit an unused function warning when we ought.

Ah.

The game we're playing is that we don't want the back end to see
definitions of functions it doesn't really need to generate RTL for,
and we prevent this by the somewhat extreme technique of setting
DECL_EXTERNAL.  Since we didn't need the function, we didn't ever
unset DECL_EXTERNAL, hence no warning.

There is also this cryptic comment in cp-tree.h:

/* DECL_EXTERNAL must be set on a decl until the decl is actually emitted,
   so that assemble_external will work properly.  So we have this flag to
   tell us whether the decl is really not external.  */

Definitely this is something of a mess.  It's always bad when you play
games with flags that are supposed to be shared in common code.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: c++ vs decl_external

[Jason Merrill]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

> The game we're playing is that we don't want the back end to see
> definitions of functions it doesn't really need to generate RTL for,
> and we prevent this by the somewhat extreme technique of setting
> DECL_EXTERNAL.  Since we didn't need the function, we didn't ever
> unset DECL_EXTERNAL, hence no warning.

Yes.

> There is also this cryptic comment in cp-tree.h:

> /* DECL_EXTERNAL must be set on a decl until the decl is actually emitted,
>    so that assemble_external will work properly.  So we have this flag to
>    tell us whether the decl is really not external.  */

What's cryptic about this?  If we don't emit a definition of the function,
we need references to pass through assemble_external.  It's just like a
prototype followed by a call, which may or may not be followed by a
definition.

> Definitely this is something of a mess.  It's always bad when you play
> games with flags that are supposed to be shared in common code.

I have a plan (and partial patch) to overhaul the linkage code, which I
intend to get back to after 3.1.0 goes out.  I meant to get it into 3.1,
but it didn't happen.

Jason

Re: c++ vs decl_external

[Mark Mitchell]

>> There is also this cryptic comment in cp-tree.h:
>
>> /* DECL_EXTERNAL must be set on a decl until the decl is actually
>> emitted, so that assemble_external will work properly.  So we have this
>>    flag to tell us whether the decl is really not external.  */
>
> What's cryptic about this?  If we don't emit a definition of the function,
> we need references to pass through assemble_external.  It's just like a
> prototype followed by a call, which may or may not be followed by a
> definition.

Crypticity is in the eye of the beholder. :-)

Perhaps I should just have said that I didn't fully understand it.

Thanks for the explanation!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com