On 12/19/2015 09:47 AM, Nathan Sidwell wrote:
Either build_constant_desc (varasm.c) should put constants into the
varpool or decl_in_symtab_p should ignore constant pool VAR_DECLS. It
appears to me that the latter is the right choice, as constant pool
entries can't be related to regular varpool entries (right?)
Thus this patch augments the decl_in_symtab_p function to ignore
constant pool entries. While debugging I found the logic in
compare_base_decls of 'in_symtab1 != in_symtab2 || !in_symtab1' to be
rather confusing, and simplified it to be (the moral equivalent of)
'!in_symtab1 || !in_symtab2'.
This looks target-agnostic, and manifests on (at least) x86_64-linux too
-- except most targets don't need to emit declarations of undefined
externs, so they don't explode.
The only other target I'm aware of where this is an issue is the PA.
And it may only be an issue in the older 32-bit SOM runtime.
Essentially you have to "import" everything you use from other TUs and
bad things happen if you "import" something that is actually file scoped
in the current TU.
ok?
With some kind of comment in decl_in_symtab_p indicating why we need to
check and filter on !DECL_IN_CONSTANT_POOL this is OK.
jeff
