From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 792193858D39; Thu, 28 Oct 2021 08:25:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 792193858D39 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102949] [12 regression] gcc.dg/vect/slp-reduc-1.c FAIL Date: Thu, 28 Oct 2021 08:25:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 08:25:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102949 --- Comment #5 from Richard Biener --- (In reply to Eric Botcazou from comment #4) > > Hm, I tried --target=3Dsparcv8-sun-solaris2.11 but that seems to fail to > > reproduce any vectorization with -O2 -ftree-vectorize. If I add -mvis = I get > > something that could resemble the code you quote: >=20 > Do you mean sparc-sun-solaris2.11 I presume? V8 is the 32-bit architectu= re > of the 90's, everything is V9 nowadays (but sparcv9-*-* is the 64-bit > compiler). > But yes, in any case, -mvis is indeed always required to enable > vectorization on the SPARC V9. >=20 > > But somehow we end up with: > >=20 > > .section ".data" > > .align 4 > > .type uc, #object > > .size uc, 64 > > uc: > > .long 0 > > .long 1 > > .long 2 > > .long 3 > >=20 > > so 'uc' is not properly aligned even though the vectorizer thinks it fo= rces > > that. And the rev in question likely caused that to misbehave. >=20 > Possibly too low BIGGEST_ALIGNMENT in 32-bit mode? For the default to work, yes - but I'm testing a patch fixing the vectorizer which attemts to override DECL_ALIGN but fails because of a mistake in the mentioned revision.=