From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25518 invoked by alias); 15 Dec 2010 17:59:17 -0000 Received: (qmail 25509 invoked by uid 22791); 15 Dec 2010 17:59:16 -0000 X-SWARE-Spam-Status: No, hits=-2.8 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, 15 Dec 2010 17:59:11 +0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/46232] [4.6 regression] 64-bit gcc.dg/tree-ssa/pr14814.c FAILs on SPARC X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.0 X-Bugzilla-Changed-Fields: 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, 15 Dec 2010 17:59: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: 2010-12/txt/msg01798.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46232 --- Comment #9 from Eric Botcazou 2010-12-15 17:58:51 UTC --- > I see. I think this is not a P1 stuff then and should definitely not > block a release. I'd rather not promise anything, but I'll add this > to my TODO list and hope I will try to address this for 4.7. Right, I think it should be marked XFAIL on the mainline. > As far as the MEM_REF instead of ARRAY_REF awkwardness is concerned, I > don't feel like discussing merits of the former here but trust me > there are reasons for this. If you want to have a look for yourself, > compare 4.5 and 4.6 build_ref_for_offset implementations (including > build_ref_for_model in 4.6) and especially their callers (and the > number of them). And of course there was PR 44972. Look at PR 46801 though. Scalarization of these records in simple contexts (i.e. no indirection in sight) worked in GCC 4.x up to very recently. Now it seems that MEM_REF has introduced artificial indirections all over the place, leading to the pessimization of these cases.