From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7918 invoked by alias); 23 Mar 2011 12:16:02 -0000 Received: (qmail 7879 invoked by uid 22791); 23 Mar 2011 12:16:00 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Mar 2011 12:15:55 +0000 From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Target Milestone Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 23 Mar 2011 12:58:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-03/txt/msg02418.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 Rainer Orth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011.03.23 12:15:19 CC| |dnovillo at google dot com, | |rguenther at suse dot de Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth 2011-03-23 12:15:19 UTC --- While I'm considering how to apply the prunes from lto.exp (lto_prune_warns) to tests not yet using lto.exp, I've got a more fundamental question: what's the point of trying to use visibility support on targets that don't support that and later pruning the resulting warning? It seems far more sensible to me not to try this in the first place and thus avoid the resulting mess.