From: Dirk Behme <dirk.behme@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3] ARM: Avoid compiler optimization for usages of readb, writeb and friends.
Date: Mon, 10 Jan 2011 17:13:42 +0100 [thread overview]
Message-ID: <4D2B3036.4010506@googlemail.com> (raw)
In-Reply-To: <20110109222550.81536150A44@gemini.denx.de>
Dear Wolfgang,
On 09.01.2011 23:25, Wolfgang Denk wrote:
> Dear Dirk Behme,
>
> In message<4D1F1841.5060508@googlemail.com> you wrote:
>>
>> Do you like to test the patch in the attachment? I named it 'v4'.
>
> Please send patches inline.
>
>> After some thinking and testing, it seems to me that the volatile
>> optimization issue this patch shall fix is only with the readx()
>> macros. So the idea is to drop all writex() changes done in the v3
>> version of this patch. With dropping the writex() changes, we would
>> drop all issues we discussed with e.g. the GCC statement-expression
>> and the do while workaround, too.
>
> This makes no sense. Even if we experience problems only with read*()
> at the moment, we should to the Rigth Thing (TM) and fix both the
> read*() and write*() functions.
The question I was thinking about with my patch was "what's Right
Thing?" ;)
It's my understanding that we don't fix read*() and write*() because
they are broken. We touch them to work around a broken tool chain.
We saw that this specific tool chain has issues with read*(). While
working around this, we touched write*(), too. This was done in the
wrong way. So while read*() was fine, write*() was accidentally broken
(with all tool chains), then. So we could
(a) do write*() correctly, too (as you do in your patch below)
or
(b) just don't touch write*() as it isn't needed to work around the
read*() tool chain issue (as I proposed in my patch v4)
Anyway:
> Please have a look a the patch I just posted,
> http://patchwork.ozlabs.org/patch/78056/
I'm fine with that patch.
Thanks
Dirk
next prev parent reply other threads:[~2011-01-10 16:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 11:04 [U-Boot] [PATCH v3] ARM: Avoid compiler optimization for usages of readb, writeb and friends Alexander Holler
2010-12-22 14:50 ` Dirk Behme
2010-12-22 15:07 ` Alexander Holler
2011-01-01 12:04 ` Dirk Behme
2011-01-01 17:52 ` Alexander Holler
2011-01-01 18:25 ` Dirk Behme
2011-01-01 18:47 ` Alexander Holler
2011-01-01 19:21 ` Dirk Behme
2011-01-02 12:43 ` Alexander Holler
2011-01-02 13:29 ` Dirk Behme
2011-01-02 21:00 ` Alexander Holler
2011-01-10 14:53 ` Alexander Holler
2011-01-10 15:05 ` Wolfgang Denk
2011-01-11 3:53 ` Alexander Holler
2011-01-09 22:25 ` Wolfgang Denk
2011-01-10 16:13 ` Dirk Behme [this message]
2011-01-17 21:59 ` Wolfgang Denk
2011-01-09 22:19 ` [U-Boot] [PATCH v4] ARM: Avoid compiler optimization for " Wolfgang Denk
2011-01-12 15:17 ` Thomas Weber
2011-01-12 15:39 ` Alexander Holler
2011-01-12 16:40 ` Wolfgang Denk
2011-01-12 16:49 ` Alexander Holler
2011-01-15 13:13 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D2B3036.4010506@googlemail.com \
--to=dirk.behme@googlemail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox