This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Handle undefined extern vars in output_in_order
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jeff Law <law at redhat dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 14 Jul 2016 21:33:57 +0300 (MSK)
- Subject: Re: [PATCH] Handle undefined extern vars in output_in_order
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LNX.2.20.1606091554200.19352@monopod.intra.ispras.ru> <alpine.LNX.2.20.1606161659170.16817@monopod.intra.ispras.ru> <20160616142524.GA93274@kam.mff.cuni.cz> <alpine.LNX.2.20.1606161733020.16817@monopod.intra.ispras.ru> <20160616152403.GA38925@kam.mff.cuni.cz> <alpine.LNX.2.20.1606161826460.16817@monopod.intra.ispras.ru> <20160616154239.GA416@kam.mff.cuni.cz> <alpine.LNX.2.20.1606231729280.9974@monopod.intra.ispras.ru> <fb05909d-51ea-8c8c-8179-08d27c5982e6@redhat.com>
On Thu, 14 Jul 2016, Jeff Law wrote:
> Is the point here to be able to deduce what symbols are external & undefined
> and emit some kind of directive to the assembler in that case?
Yes, PTX assembly requires that properly typed declarations are emitted for
external references. Today, the NVPTX backend in GCC performs that internally
for function symbols, and relies on the middle-end to do that for data symbols,
but when the port was added that was implemented only when -ftoplevel-reorder is
in effect (the default).
The point of my patch is to handle it under -fno-toplevel-reorder in the same
way.
> Avoiding duplicates
this is not required for PTX, but nevertheless a good cleanup we get for free
> as well as symbols which may have had originally looked like external &
> undefined, but later we find a definition?
I think this only would be a problem if GCC continued to support
-fno-unit-at-a-time. AFAIK today GCC's symtab reflects symbol availability
exactly, because the whole translation unit has been read upfront.
> The reason I ask someone might be able to simplify a bit of the PA backend if
> that's the goal here. The PA (when using the SOM object format) has similar
> needs. We solved it by queuing up everything that might need "importing".
> Then at the end of the compilation unit, we'd walk that queue of symbols
> emitting the proper magic.
*nod*, although as I mentioned above today it's handled in a generic way only
for undefined data symbols, not undefined function symbols.
Alexander