>
> When I debug and set a breakpoint in varasm.c line 314 it looks as if
> the flag SECTION_RELRO is different. This flag is set in
I see, it is the same message, but different reason from AIX.
> categorize_decl_for_section where it depends on
> TREE_CODE(decl), and if it is a VAR_DECL also on
> TREE_READONLY (decl)
> TREE_SIDE_EFFECTS (decl)
> DECL_INITIAL (decl)
> TREE_CONSTANT (DECL_INITIAL (decl))
> DECL_THREAD_LOCAL_P (decl)
the new variable is alias. As i wrote to ML and to Richard Henderson (who is
guru for this area),
I think it is wrong to determine section of alias from alias decl itself and
rather we should
use the same section as alias target (you can't place alias to different
section than taret).
So I think it is semi-latent varasm bug that I triggered. I think it should
walk to alias
tarets where it matters (see patch bellow)
On the other hand, the alias created ought to inherit properties form its
target, so yes, we probably want to copy flags that matters, including
DECL_THREAD_LOCAL_P. We however should not copy DECL_INITIAL - we never have
constructors for aliases and there is ctor_for_folding function that gets you
from decl to corresponding constructor that knows how to walk aliases.
So if varasm looks into DECL_INITIAL of an alias, I think it is a bug.
We probably want to copy other flags. Does the patch works if you copy
TREE_SIDE_EFFECTS
alone? But why that particular variable has side effects at first place?
/* In any expression, decl, or constant, nonzero means it has side effects or
reevaluation of the whole expression could produce a different value.
This is set if any subexpression is a function call, a side effect or a
reference to a volatile variable. In a ..._DECL, this is set only if the
declaration said `volatile'. This will never be set for a constant. */
I do not see how vtable may end up being volatile.
I posted following patch:
Index: varasm.c
===================================================================
--- varasm.c (revision 211028)
+++ varasm.c (working copy)
@@ -1083,6 +1083,9 @@
{
addr_space_t as = ADDR_SPACE_GENERIC;
int reloc;
+ symtab_node *snode = symtab_get_node (decl);
+ if (snode)
+ decl = symtab_alias_ultimate_target (snode)->decl;
if (TREE_TYPE (decl) != error_mark_node)
as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
which should make the variable sections to go according to alias target, I
suppose
it doesn't help to your build?
Sorry for slow reaction - I teach now monday-wednesday a class in linear algebra
(as part of my post-doc) and it is time consuming (since the semmester is only
6 weeks). I can do serious GCC hacking only thursday/friday/weekend thus.
I will try to fix this today however - I realize it is painful bug.
Honza
>
> maybe also on CONST_CAST_TREE (decl) in case of asan
> and various target hooks.
>
>
> now, since the error message names a ".localalias."
>
> I see your checkin from monday at the same area:
>
> r210919 | hubicka | 2014-05-26 02:50:24 +0200 (Mo, 26. Mai 2014) | 2 Zeilen
>
> * symtab.c (symtab_nonoverwritable_alias): Copy READONLY flag for
> variables.
>
> and I wonder if there are more flags missing:
>
> Index: symtab.c
> ===================================================================
> --- symtab.c (Revision 211028)
> +++ symtab.c (Arbeitskopie)
> @@ -1165,6 +1165,8 @@ symtab_nonoverwritable_alias (symtab_node *node)
> else
> {
> TREE_READONLY (new_decl) = TREE_READONLY (node->decl);
> + TREE_SIDE_EFFECTS (new_decl) = TREE_SIDE_EFFECTS (node->decl);
> + DECL_INITIAL (new_decl) = DECL_INITIAL (node->decl);
> new_node = varpool_create_variable_alias (new_decl, node->decl);
> }
> symtab_resolve_alias (new_node, node);
>
>
> This makes the build succeed for me, but I am not really sure, if that is
> the right direction to fix this, and if maybe even more flags may be missing,
> for instance: DECL_THREAD_LOCAL_P or CONST_CAST_TREE?
>
> What do you think?
>
>
>
> Bernd.
>
