[U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for usages of readb, writeb and friends.

[Alexander Holler <holler@ahsoftware.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