From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5C5193858438; Mon, 7 Mar 2022 17:47:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C5193858438 From: "paulmckrcu at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104800] reodering of potentially trapping operations and volatile stores Date: Mon, 07 Mar 2022 17:47:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: paulmckrcu at gmail 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: 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: Mon, 07 Mar 2022 17:47:35 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104800 --- Comment #7 from Paul McKenney --- (In reply to Richard Biener from comment #6) > Generally GCCs middle-end considers volatile stores (or loads) to not have > any side-effects that are not visible in the IL. That includes (synchron= ous) > raise of signals (and thus effects on control flow), effects on other > (non-volatile) memory, etc. If a volatile access has to be considered ha= ving > an effect on control flow then the standard should explicitely mention th= at, > I don't think it does that at the moment, it merely says those statements > invoke "changes in the state of the execution environment" >=20 > So volatile "issues" like this are no different from issues that arise > with respect to observability when you consider asynchronous events and > the effect of re-ordering of statements. In fact C17 especially notes > that objects that are not volatile sig_atomic_t have unspecified value > on such events, so that IMHO also covers generating a trap from a volatile > access. >=20 > Volatile accesses are deemed observable but we do not re-order those, this > bug is about re-ordering unrelated stmts with respect to such accesses. >=20 > I don't think the standard requires us to fix this reported behavior. >=20 > A mitigation in the middle-end requires volatile accesses to behave as > possibly altering control flow. That's iffy if they continue to be > represented as simple assign statements, the closest would be to always > mark them as possibly trapping (something we cannot do right now). >=20 > The PRE "fix" is just covering up a single place in the compiler that fai= ls > to consider volatile accesses as altering control flow. Understood that normal accesses can be reordered with volatile accesses. C= ases where this is a problem can prevent it, for example, using an asm with the "memory" clobber. The concern here is not the memory access, but the potential for trapping, which in this case is the potential division by zero.=