Hi,
On Wed, 28 May 2014 22:36:17, Jan Hubicka wrote:
>
> 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?
>
No, that was my first attempt, but unfortunately this did not make a difference,
What seems to be important is if DECL_INITIAL(decl) == NULL that
means it is in BSS segment, and -fzero-initialized-in-bss (the default) it
looks also
at the initial data if they are zero.
I but for RELRO, it seems also to be important, if the TREE_CONSTANT
flag is set on the DECL_INITIAL(decl).
Other properties of the DECL_INITIAL are not important.
except, if the TREE_CODE of the DECL_INITIAL is STRING_CST,
then the section may be also different....
And look at compute_reloc_for_constant, this inspects the initial
value if it binds to locals or externals, or not. That tells us if it has
relocations or not.
Hmm, I am not sure, if it is possible to leave the DECL_INITIAL away...
> /* 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?
>
I just tried it, and ... Yes, it worked, somehow ...
> 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.
>
Thanks !
Unfortunately this is not the only bug at the time.
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61331
which is even more painful...
I can currently only build anything if I do this:
svn diff -r210963:210965 | patch -p0 -R
Bernd.
> 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.
>>
