From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5981D384AB69; Thu, 2 May 2024 23:42:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5981D384AB69 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1714693324; bh=9zIqvUc0y2kdSeZC/cDjVC3R9l2S0+IGmEwKbvE1wos=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HaT2GO9VlNvfIGLkQKsPoqpr2om9Kw5CalK7u1wgvxNaMJLY0gupMzVMxHU/7OAd7 F/ovh15zOcn9dfazGgioSOnB6X9E+N4HKLufw3jPFsG6HGqUSAjEebqNItecNpUjPd wA8bxre0cUW2jigpDTx0y+o2DZ/lcbu8lK0OXkTs= From: "pinskia at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/114923] gcc ignores escaping pointer and applies invalid optimization Date: Thu, 02 May 2024 23:42:04 +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: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pinskia at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114923 --- Comment #8 from Andrew Pinski --- (In reply to nfxjfg from comment #7) > > Note also the order of the writes to reg1 and reg2 might happen in a di= fferent order in HW so you need to have a full (HW) write barrier between t= hem to make sure the write is done in the correct order. >=20 > Seriously? That breaks literally all code that uses volatile for register > access (which, in our firmwares, is ALL code). This just fuels my belief > that gcc and C compiler developers in general turned C into a useless, > fragile language that can't do anything correctly. >=20 > Is there a way to prevent reordering of volatile accesses? Yes you need to use inline-asm to get a hw write barrier. This has been this way for the last 20+ years even when it comes to out of order processors.=20 https://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf should be very useful. Basically volatile means the compiler not to remove the store/= load from it but it does not mean the HW will reorder the stores/loads.=20 Oh and GCC even documents part of this: https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html "Accesses to non-volatile objects are not ordered with respect to volatile accesses. You cannot use a volatile object as a memory barrier to order a sequence of writes to non-volatile memory. " The documentation does not mention hw memory barriers since that is outside= of the compiler view really. This has been standard behavior with GCC and hard= ware with weak memory systems for over 20 years. That is even if GCC outputs the writes in order in the assembly the hardware (or future hardware depending on the definition of the hardware) might reor= der the writes. RISCV IIRC has both a weak and strong memory consistency models. https://riscv.org/wp-content/uploads/2018/05/14.25-15.00-RISCVMemoryModelTu= torial.pdf for more details on it. GCC will never output the needed instructions direc= tly.=