From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Holler <holler@ahsoftware.de>
Date: Wed, 22 Dec 2010 12:23:32 +0100
Subject: [U-Boot] [RFC PATCH v2] ARM: Avoid compiler optimization for
 usages of readb, writeb and friends.
In-Reply-To: <20101222080206.A0CA3EA652A@gemini.denx.de>
References: <1292711230-3234-1-git-send-email-holler@ahsoftware.de>
	<20101222080206.A0CA3EA652A@gemini.denx.de>
Message-ID: <4D11DFB4.1050805@ahsoftware.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hello,

Am 22.12.2010 09:02, schrieb Wolfgang Denk:

> In message<1292711230-3234-1-git-send-email-holler@ahsoftware.de>  you wrote:
>> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
>> avoid that as done in the kernel.
> ...
>> +#define writeb(v,c)			({ __iowmb(); __arch_putb(v,c); })
>> +#define writew(v,c)			({ __iowmb(); __arch_putw(v,c); })
>> +#define writel(v,c)			({ __iowmb(); __arch_putl(v,c); })
>
> http://www.codesourcery.com/archives/arm-gnu/msg03990.html  explains
> why this construct is causing errors in cases where an additional read
> from the address is unsupported.
>
> Can you please try the following patch instead?

Indeed. Using do {} while (0) instead of that "GCC statement-expression" 
fixes the problem with the read after write.

I didn't know about that "GCC statement-expression" and my usage of 
({...}) was based on the writeb in the kernel-headers. But they (seem 
to) expand to something returning (void) which might avoid the problem.

Good that I've added the sentence that using the kernel-headers instead 
of that patch might be a better solution. But this might bring in much 
more changes, including real memory barriers. ;)

Anyway, now the master (including the GLOBAL...-patch) + patch v3 for 
read*/write* is good here. Just tested with both gcc 4.3.5 and gcc 4.5.1 
using binutils 2.20.1.

Regards,

Alexander