From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 98BBD3858D1E; Fri, 22 Mar 2024 18:02:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 98BBD3858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711130536; bh=fmxW45n4/ZR+WW9D8pL1XgNM/d52heH8gBqhKnYj8NA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nXqlYCA3uLYfNk6+pN7IYSjl+//RsLsqMbhqp0q8dbnnQi1BpcGT3dmSeTEWpZb7z 6/mVgehH6RzkEcfu47VCxKh6UXoRRr7X2QL46Rbd+QtgeUUCfseMmQnn8rImDChe47 vkDm64NEq0Ij20La31HBYGOau9onQqr2fgQJDlvA= From: "rearnsha at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working) Date: Fri, 22 Mar 2024 18:02:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.2.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rearnsha at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.4 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111231 --- Comment #19 from Richard Earnshaw --- This is another problem with (I suspect) incorrect aliasing information. I= f I compile with -fno-strict-aliasing, I get 88: f4432a1f vst1.8 {d18-d19}, [r3 :64] // {>E} SP+96/16 8c: f4420a1f vst1.8 {d16-d17}, [r2 :64] // {>A} SP+32/16 90: e893000f ldm r3, {r0, r1, r2, r3} // {G} SP+128/16 98: eddd0b20 vldr d16, [sp, #128] ; 0x80 // {B} SP+48/16 a4: e28dc040 add ip, sp, #64 ; 0x40 a8: e885000f stm r5, {r0, r1, r2, r3} // {>F} SP+112/16 ac: f2d80570 vshl.s16 q8, q8, #8 b0: f3f503e0 vneg.s16 q8, q8 b4: edcd0b20 vstr d16, [sp, #128] ; 0x80 // {>G.l} SP+128/8 b8: edcd1b22 vstr d17, [sp, #136] ; 0x88 // {>G.h} SP+136/8 bc: e894000f ldm r4, {r0, r1, r2, r3} // {C} SP+64/16 c4: e28dc050 add ip, sp, #80 ; 0x50 c8: e88c000f stm ip, {r0, r1, r2, r3} // {>D} SP+80/16 cc: e885000f stm r5, {r0, r1, r2, r3} // {>F} SP+112/16 I've annotated each memory access with its stack address and labeled each 16-byte slot from A to G. With -fstrict-aliasing this becomes: 88: f4420a1f vst1.8 {d16-d17}, [r2 :64] // {>A} SP+32/16 8c: eddd0b20 vldr d16, [sp, #128] ; 0x80 // {E} SP+96/16 98: e893000f ldm r3, {r0, r1, r2, r3} // {B} SP+48/16 a0: e28dc040 add ip, sp, #64 ; 0x40 a4: f2d80570 vshl.s16 q8, q8, #8 a8: e884000f stm r4, {r0, r1, r2, r3} // {>G} SP+128/16= =20=20=20=20 ! ac: e885000f stm r5, {r0, r1, r2, r3} // {>F} SP+112/16 b0: f3f503e0 vneg.s16 q8, q8 b4: edcd0b20 vstr d16, [sp, #128] ; 0x80 // {>G.l} SP+128/8 b8: edcd1b22 vstr d17, [sp, #136] ; 0x88 // {>G.h} SP+136/8 bc: e894000f ldm r4, {r0, r1, r2, r3} // {C} SP+64/16 c4: e28dc050 add ip, sp, #80 ; 0x50 c8: e88c000f stm ip, {r0, r1, r2, r3} // {>D} SP+80/16 cc: e885000f stm r5, {r0, r1, r2, r3} // {>F} SP+112/16 And we see that the initial store to G has been moved after the reads from = it.=20 I'm still digging, but it may be pertinent that the reads have been split i= nto two separate instructions; perhaps when the split was done the alias sets weren't copied correctly.=