This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch Ping^2, C++] Move assemble_external call in cp/decl2.c.


On Fri, 2008-12-05 at 14:09 -0800, Mark Mitchell wrote:
> Steve Ellcey wrote:
> > This is a second ping for my C++ compiler patch to fix two libstdc++
> > test failures on IA64 HP-UX.  The original patch is at:
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00174.html
> 
> > 2008-10-06  Steve Ellcey  <sje@cup.hp.com>
> > 
> > 	* decl2.c (mark_used): Move assemble_external from here
> > 	(cp_write_global_declarations): to here.
> 
> If I understand correctly, on HP-UX, the invariant is that me must put
> out an external declaration directive in the assembly code if *and only
> if* we reference a function not included in the current file.

Correct.

> And, the
> problem here is that we're referencing a function which isn't defined in
> the current file -- but also isn't going to be defined anywhere else?

It depends on what you mean by a reference.  All the uses (calls)
for the function got optimized away (inlined) and since they were all
optimized away the compiler didn't put out an external version of the
function.  But it still put out a declaration (which could be considered
a reference) for it because it called assemble_external before it
realized that all the calls would be inlined and the function wasn't
actually needed.

With the HP-UX linker, if your assembly file has:

        .global foo#
        .type   foo#,@function

but you have no other references/uses/definitions of foo, then the
linker will complain about foo not being defined.  I believe the GNU
linker will basically ignore this global declaration for foo if there
are no references/uses/definitions of foo.

> But, it seems like your patch is going to make us only call
> assemble_external for functions whose body we actually need, which seems
> contrary to the idea of assemble_external.  In varasm.c,
> assemble_external does:
> 
>    if (!DECL_P (decl) || !DECL_EXTERNAL (decl) || !TREE_PUBLIC (decl))
>     return;
> 
> so won't the call in cp_write_global_declarations just be a no-op?

I don't think so but I will double check.  I definitely need to remove
the call to assemble_external from mark_used.  Maybe I didn't need to
put it in cp_write_global_declarations.  I will go back and check on
that.

> More broadly, in unit-at-a-time mode especially, why should the front
> end be involved in this at all?  It seems to me that we should be able
> to use cgraph to keep track of what functions we're actually going to
> reference, and then call assemble_external on all of them before
> actually emitting any code.

That would seem reasonable.  If I can't just remove the call to
assemble_external from cp_write_global_declarations I will see if it can
be called from the cgraph code instead.

Steve Ellcey
sje@cup.hp.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]