From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 048E23857B98; Sat, 8 Jul 2023 01:46:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 048E23857B98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1688780816; bh=vD5p8UKhXWZ921SFZyvCOzJ7yDIhY9Po3UWGGX/CKzc=; h=From:To:Subject:Date:From; b=fyGwCJw+bMnVimXT/r+dxQRuUkbs8P8QmrlyoiGat43uGNrIIQW43AYy/kAV+X1/V pdjT5RyGbWZI+0JQBRm3qAcvn19aySOd/RNZoY//tuLqPrrF+4HltV5cQmEIlJT440 QD1pfpJYpQN23GZHUU5kXBgZEpPCay6wgq46SPQY= From: "koachan+gccbugs at protonmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/110592] New: [SPARC] GCC should default to TSO memory model when compiling for sparc32 Date: Sat, 08 Jul 2023 01:46:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: koachan+gccbugs at protonmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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=3D110592 Bug ID: 110592 Summary: [SPARC] GCC should default to TSO memory model when compiling for sparc32 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: koachan+gccbugs at protonmail dot com Target Milestone: --- Created attachment 55501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D55501&action=3Dedit Reproducer of unwanted memory reordering under TSO processors Currently, when targeting sparc32 processors, GCC assumes that the hardware= has sequentially consistent memory ordering by default. This can cause problems when running generated binaries on v8 and later processors, which uses weaker TSO ordering. In the attached reproducer, when compiled with the default sparc32 target, = the resulting code is missing the required barriers: 00000fb0 : ... 104c: e0 26 00 00 st %l0, [ %i0 ] 1050: c2 06 40 00 ld [ %i1 ], %g1 1054: c2 26 80 00 st %g1, [ %i2 ] ... 0000108c : ... 1128: e0 26 00 00 st %l0, [ %i0 ] 112c: c2 06 40 00 ld [ %i1 ], %g1 1130: c2 26 80 00 st %g1, [ %i2 ] ... Compare with the result when explicitly specifying -mcpu=3Dv8: 00000fa4 : ... 1040: e0 26 00 00 st %l0, [ %i0 ] 1044: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1048: c0 6b bf ff ldstub [ %sp + -1 ], %g0 104c: c2 06 40 00 ld [ %i1 ], %g1 1050: c2 26 80 00 st %g1, [ %i2 ] 1054: c0 6b bf ff ldstub [ %sp + -1 ], %g0 ... 0000108c : ... 1128: e0 26 00 00 st %l0, [ %i0 ] 112c: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1130: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1134: c2 06 40 00 ld [ %i1 ], %g1 1138: c2 26 80 00 st %g1, [ %i2 ] 113c: c0 6b bf ff ldstub [ %sp + -1 ], %g0 ... This causes the default-target code to hit the assert condition. Since all code that works on TSO processors will work on processors with a stronger memory model (i.e sequential consistency), it is probably better if GCC uses TSO by default unless otherwise specified (e.g by explicitly using -mcpu=3Dv7).=