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.
I haven't followed this issue at all. So bear with me if I ask a
question you've already answered.
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?
Avoiding duplicates as well as symbols which may have had originally
looked like external & undefined, but later we find a definition?
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.
Jeff
