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: Jeff Law <law at redhat dot com>
- To: Alexander Monakov <amonakov at ispras dot ru>, Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 14 Jul 2016 14:31:09 -0600
- 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>
On 06/23/2016 08:45 AM, Alexander Monakov wrote:
Hi,
I've discovered that this assert in my patch was too restrictive:
+ if (DECL_HAS_VALUE_EXPR_P (pv->decl))
+ {
+ gcc_checking_assert (lookup_attribute ("omp declare target link",
+ DECL_ATTRIBUTES (pv->decl)));
Testing for the nvptx target uncovered that there's another case where a
global variable would have a value expr: emutls. Sorry for not spotting it
earlier (but at least the new assert did its job). I think we should always
skip here over decls that have value-exprs, just like hard-reg vars are
skipped. The following patch does that. Is this still OK?
(bootstrapped/regtested on x86-64)
Alexander
* cgraphunit.c (cgraph_order_sort_kind): New entry ORDER_VAR_UNDEF.
(output_in_order): Loop over undefined variables too. Output them
via assemble_undefined_decl. Skip variables that correspond to hard
registers or have value-exprs.
* varpool.c (symbol_table::output_variables): Handle undefined
variables together with defined ones.
OK. Thanks for your patience.
jeff