[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
rguenther at suse dot de
Tue Mar 5 15:09:00 GMT 2013
--- Comment #31 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-05 15:09:06 UTC ---
On Tue, 5 Mar 2013, ebotcazou at gcc dot gnu.org wrote:
> --- Comment #28 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-05 14:23:19 UTC ---
> > Hmm, but when I use the same contents for the two arrays in my simple
> > testcase I do get only a single .LC0 output referenced from two places.
> > We will end up sharing the same RTL for both (unmerged) DECLs - but
> > I don't see how this can be a problem? Maybe we fail to set
> > TREE_ASM_WRITTEN on the duplicate and output it anyway via other
> > mechanisms?
> We simply fail to set TREE_ASM_WRITTEN on the DECL_INITIAL (decl) because it is
> not shared anymore. So probably:
But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL
of the SYMBOL_REF_DECL ...
So it must be pure luck that we survived LTO bootstrap before my
patch (as far as I understand things). Before my patch we created
yet another decl for the constant pool entry. With my patch
we will have one less (we still have the decls from the constant
pool entries that end up being shared in the LTRANS unit).
So in the end I can agree to that my patch doesn't really fix
the original issue fully. So we can as well revert it and
instead avoid messing with alignment of the constant pool entries.
But then the underlying issue with multiple decls refering to
the same constant pool entry with LTO remains, it just happens
that it isn't triggered anymore.
> Index: varasm.c
> --- varasm.c (revision 196416)
> +++ varasm.c (working copy)
> @@ -3112,7 +3112,6 @@ build_constant_desc (tree exp, tree decl
> LTO mode. Instead we set the flag that will be recognized in
> make_decl_rtl. */
> DECL_IN_CONSTANT_POOL (decl) = 1;
> - DECL_INITIAL (decl) = desc->value;
> /* ??? CONSTANT_ALIGNMENT hasn't been updated for vector types on most
> architectures so use DATA_ALIGNMENT as well, except for strings. */
> if (TREE_CODE (exp) == STRING_CST)
> @@ -3125,6 +3124,8 @@ build_constant_desc (tree exp, tree decl
> align_variable (decl, 0);
> + DECL_INITIAL (decl) = desc->value;
> /* Now construct the SYMBOL_REF and the MEM. */
> if (use_object_blocks_p ())
Hmm, maybe. Then, why do we copy the constant in the first place ...
--- varasm.c (revision 196462)
+++ varasm.c (working copy)
@@ -3087,7 +3087,7 @@ build_constant_desc (tree exp, tree decl
desc = ggc_alloc_constant_descriptor_tree ();
- desc->value = copy_constant (exp);
+ desc->value = exp;
/* Propagate marked-ness to copied constant. */
if (flag_mudflap && mf_marked_p (exp))
should be an "equivalent" fix.
More information about the Gcc-bugs