From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 48D223858C83; Wed, 9 Mar 2022 07:52:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48D223858C83 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104800] reodering of potentially trapping operations and volatile stores Date: Wed, 09 Mar 2022 07:52:50 +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: rguenther at suse dot de 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: Wed, 09 Mar 2022 07:52:50 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104800 --- Comment #13 from rguenther at suse dot de --- On Wed, 9 Mar 2022, muecker at gwdg dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104800 >=20 > --- Comment #11 from Martin Uecker --- > (In reply to Richard Biener from comment #9) > > (In reply to Martin Uecker from comment #8) > > > The standard specifies in 5.1.2.3p6 that > > >=20 > > > "=E2=80=94 Volatile accesses to objects are evaluated strictly > > > according to the rules of the abstract machine." > > >=20 > > > and > > >=20 > > > "This is the observable behavior of the program." > > >=20 > > >=20 > > > If a trap is moved before a volatile access so that the access never > > > happens, than this changes the observable behavior because the volati= le > > > access was then not evaluated strictly according to the abstract mach= ine. > >=20 > > Well, the volatile access _was_ evaluated strictly according to the abs= tract > > machine.=20 >=20 > Not if there is a trap. >=20 > > Can't your argument be stretched in a way that for > >=20 > > global =3D 2; > > *volatile =3D 1; > >=20 > > your reasoning says that since the volatile has to be evaluated strictly > > according to the abstract machine that the full abstract machine status > > has to be reflected at the point of the volatile and thus the write of > > the global (non-volatile) memory has to be observable at that point > > and so we may not move accesses to global memory across (earlier or lat= er) > > volatile accesses? >=20 > The state of the global variables is not directly observable. >=20 > > IMHO the case with the division is similar, you just introduce the extra > > twist of a trap. >=20 > The point is that the trap prevents the volatile store to happen. >=20 > > The two volatile accesses in your example are still evaluated according > > to the abstract machine, just all non-volatile (and non-I/O) statements > > are not necessarily. >=20 > The problem is that the volatile store might not be evaluated if there is= a > trap. So? The abstract machine evaluation simply does not have reached the second volatile store then. All indirect memory accesses might trap (again undefined behavior), direct stores might trap if they are mapped to readonly memory (again undefined behavior). General FP operations might trap (sNaNs), other general operations might trap (certain CPU insns trap on overflow, some CPUs have NaTs that trap, etc.). I'm raising these issues because while the case at hand (division by zero trap and volatiles) might be an obvious candidate to "fix" just for the sake of QOI the question is where to stop? Take volatile flag; void foo (int *p) { if (p =3D=3D NULL) { flag =3D 1; *p =3D 1; } } it's an artifact that we currently fail to eliminate the branch because it leads to UB *p =3D 1, and I think it would be valid to eliminate it. Would that be in violation of your desired reading of the standard since it elides the volatile store (the UB happens later)?=