From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DCBC03858410; Thu, 28 Oct 2021 08:23:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DCBC03858410 From: "ebotcazou 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:23:04 +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: ebotcazou 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:23:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102949 --- Comment #4 from Eric Botcazou --- > 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: Do you mean sparc-sun-solaris2.11 I presume? V8 is the 32-bit architecture= 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 vectorizati= on on the SPARC V9. > 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 forc= es > that. And the rev in question likely caused that to misbehave. Possibly too low BIGGEST_ALIGNMENT in 32-bit mode?=