From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-416937-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17734 invoked by alias); 5 Mar 2013 15:32:55 -0000
Received: (qmail 17466 invoked by uid 48); 5 Mar 2013 15:32:21 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
Date: Tue, 05 Mar 2013 15:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50494-4-ivM6G9KWq3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50494-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50494-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2013-03/txt/msg00379.txt.bz2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494

--- Comment #32 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-03-05 15:32:15 UTC ---
> But in all places I found we check TREE_ASM_WRITTEN on DECL_INITIAL
> of the SYMBOL_REF_DECL ...

Nope, maybe_output_constant_def_contents has:

  rtx symbol = XEXP (desc->rtl, 0);
  tree exp = desc->value;

  if (flag_syntax_only)
    return;

  if (TREE_ASM_WRITTEN (exp))
    /* Already output; don't do it again.  */
    return;

so the DECL_INITIAL of the SYMBOL_REF_DECL must be desc->value.

> 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).

We use LTO on heavy Ada applications with an unmodified 4.7 compiler (modulo a
patch for -g) so I don't think that luck has anything to do here.

> 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.

That would be my preference.

> Hmm, maybe.  Then, why do we copy the constant in the first place ...
> 
> Thus,
> 
> Index: varasm.c
> ===================================================================
> --- varasm.c    (revision 196462)
> +++ varasm.c    (working copy)
> @@ -3087,7 +3087,7 @@ build_constant_desc (tree exp, tree decl
>    int labelno;
> 
>    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.

This call to copy_constant has been there for ages though. so a little bit of
archeology would probably be in order before removing it.

In the meantime, I've successfully bootstrapped my patchlet so we can also go
for it.