From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 21 Dec 2010 15:33:22 +0100 Subject: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends. In-Reply-To: <4D10ABDE.7010303@ahsoftware.de> References: <1292711230-3234-1-git-send-email-holler@ahsoftware.de> <4D0DB994.1020703@googlemail.com> <4D0DDCEF.2040806@ahsoftware.de> <4D0E643A.9040001@ahsoftware.de> <4D0EA9BB.4050002@ahsoftware.de> <4D0F8E75.2010107@ahsoftware.de> <4D105324.2080201@googlemail.com> <4D105583.8070703@free.fr> <4D1066CD.2040409@googlemail.com> <4D1083B4.2060704@free.fr> <20101221105303.4E3EDB715C@gemini.denx.de> <4D109F06.1040109@ahsoftware.de> <4D10A2E7.6050302@free.fr> <4D10ABDE.7010303@ahsoftware.de> Message-ID: <4D10BAB2.9080300@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 21/12/2010 14:30, Alexander Holler a ?crit : > Am 21.12.2010 13:51, schrieb Albert ARIBAUD: >> Le 21/12/2010 13:35, Alexander Holler a ?crit : >> >>> Hmm, is there actual somethinbg which should forbid the compiler to >>> generate such code which rereads something? It might not be nice, but I >>> don't think that it is forbidden for a compiler to do so. So the proper >>> way to handle such, might be to use asm to avoid that the compiler >>> touches that register. >> >> Yes there is something that should prevent a compiler from inserting >> reads: these accesses are to hardware, not memory, and may cause side >> effects even on read (these could be acknowledges, for instance; I've >> seen instances of that myself on some HW). >> >> Another way to look at it is that the semantics of " *ptr = value " is a >> pure write and should not result in a write-then-read. > > I think it's something like atomic_read. E.g. when reading an 32bit int > (uint32_t i = *bla;), nothing forbids that the compiler generates code > which reads those 4 bytes byte by byte (and so becoming a non-atomic > operation). It's unusual to do so on 32bit architectures but valid. OTOH, this still respects the semantics (the compiler is allowed to do a non-atomic read) while the bug we're seeing does not repect the semantics (the compiler is not asked to do any read but does one). > Regards, > > Alexander Amicalement, -- Albert.