From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25618 invoked by alias); 2 Mar 2015 18:23:10 -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 Received: (qmail 25541 invoked by uid 55); 2 Mar 2015 18:23:06 -0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2" basic block vectorized using SLP" 1 Date: Mon, 02 Mar 2015 18:23:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 4.9.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg00183.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 --- Comment #23 from rguenther at suse dot de --- On March 2, 2015 7:13:25 PM CET, "msebor at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 > >--- Comment #22 from Martin Sebor --- >(In reply to rguenther@suse.de from comment #21) >> >g: >> > .quad .L.g,.TOC.@tocbase >> > .previous >> > .type g, @function >> >.L.g: >> > addis 9,2,.LC1@toc@ha >> > addis 10,2,.LC0@toc@ha >> > addi 9,9,.LC1@toc@l >> > lxvw4x 32,0,9 >> > ld 9,.LC0@toc@l(10) >> > li 10,4 >> > stxvw4x 32,9,10 >> >> But isn't this simply wrong-code?! > >I don't see anything wrong with it. The load seems straightforward >enough and, >AFAICS, the store code matches the stxvw4x example in the PowerISA 2.07 >reference (in Storing an Unaligned Quadword to Big-Endian Storage on >page 360). > r9 is the address of B and r10 is the byte offset of B[1] from B. Ah, i only tested with altivec as noted in the bug description. I'll check with vsx tomorrow.