This is the mail archive of the
mailing list for the GCC project.
RE: Build problems on arm-linux-gnueabihf
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 29 May 2014 00:13:48 +0200
- Subject: RE: Build problems on arm-linux-gnueabihf
- Authentication-results: sourceware.org; auth=none
- References: <DUB118-W3976CBD40A79D5C2CFE23BE4250 at phx dot gbl>,<20140528203617 dot GA5389 at kam dot mff dot cuni dot cz>
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.
Unfortunately this is not the only bug at the time.
which is even more painful...
I can currently only build anything if I do this:
svn diff -r210963:210965 | patch -p0 -R
>> 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)
>> 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?