From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17417 invoked by alias); 7 Dec 2010 23:18:51 -0000 Received: (qmail 17402 invoked by uid 22791); 7 Dec 2010 23:18:50 -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; Tue, 07 Dec 2010 23:18:45 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.5.2 X-Bugzilla-Changed-Fields: Component 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: Tue, 07 Dec 2010 23:18: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/msg00802.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Component|middle-end |target --- Comment #62 from Jakub Jelinek 2010-12-07 23:18:05 UTC --- On a closer look, the reason why DSE deletes it is because there is a stvewx insn in between, and the pattern of the insn is just plain wrong. rs6000_expand_vector_extract has called assign_stack_temp, which gave for a V4SImode something that is at r1+256, 16 bytes. But rs6000_expand_vector_extract adjusts the address by elt * 4 bytes, here for elt 3, so it is r1+268. The pattern wrongly says that a V4SImode register is stored into (mem:V4SI (r1 + 268)), which is not true (the insn stores just 4 bytes, i.e. SImode, into r1 + 268. The r1+272 address which was given for one of the spilled CCmode pseudos is then considered to be clobbered by DSE, because (mem:V4SI (r1 + 268)) overlaps it, thus the removed (mem:CC (r1 + 272)) store by DSE. I think the stve* insns need to be represented as what it really does, i.e. (set (mem:SI ...) (either vec_select or perhaps unspec with the V4SImode reg inside of it)).