From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Holler Date: Wed, 22 Dec 2010 10:56:52 +0100 Subject: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends. In-Reply-To: <4D11A281.9080706@free.fr> References: <1292711230-3234-1-git-send-email-holler@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> <4D10BAB2.9080300@free.fr> <20101221195215.DB74C126EB1A@gemini.denx.de> <4D110866.6020209@googlemail.com> <4D11424C.4090708@ahsoftware.de> <4D11A281.9080706@free.fr> Message-ID: <4D11CB64.7040201@ahsoftware.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 22.12.2010 08:02, schrieb Albert ARIBAUD: > Le 22/12/2010 01:11, Alexander Holler a ?crit : >> Am 21.12.2010 21:04, schrieb Dirk Behme: >>> On 21.12.2010 20:52, Wolfgang Denk wrote: >>>> Dear Albert& friends, >>>> >>>> what is your opinion? Should we include the memory barrier patch into >>>> the upcoming release (and eventually delay it for further testing), or >>>> release as is and solve this issue in the next release? >>>> >>>> I tend to leave it as is, as I expect that most people will disappear >>>> in the next few days for holidays, so no much testing will be done >>>> anyway, and we then can solve this with less pressure in the next >>>> release - but I'm not really sure if this is a good idea? >>> >>> I somehow tend to leave it as is, too. >>> >>> We have issues with some recent compilers. For these we found a fix >>> using the io.h somehow the same way the Linux kernel does. But this >>> introduces new issues for us, we haven't found a proper fix yet >>> (except changing the code to the 'old' io.h style). But we don't know >>> where we might have this issue additionally, yet. >> >> The only real problem found with that patch was one with a register >> which doesn't like an (unmotivated) read after write. > > Yes, and this is enough for me to not want it right away: we caught this > one, but how many others, so far unseen, will creep up? > >> On the other side, without that patch, using gcc>= 4.5.x (at least on >> arm) proved to fail. In contrast to that problem of gcc 4.5.x ignoring >> that volatile, 4.5.x still fixes many bugs for arm and gcc>= 4.5.x is >> necessary for hardfloat. So it's likely that more people will start >> using 4.5.x (4.5.2 was just released). > > Do we need hard floating point in u-boot? IIRC, and unless this changed, > the kernel does not want floating point, so I wonder why u-boot would. Most people won't use U-Boot as base for the decision which compiler version to use. > As for getting 4.5 to work, for the next cycle people can still use pre > 4.5 gccs / toolchains, so this is important but not urgent to the point > of rushing decisions. I've just written down my opinion. Regards, Alexander