public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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: Sat, 01 Jan 2011 20:21:42 +0100	[thread overview]
Message-ID: <4D1F7EC6.9090607@googlemail.com> (raw)
In-Reply-To: <4D1F76D7.8060603@ahsoftware.de>

On 01.01.2011 19:47, Alexander Holler wrote:
> Am 01.01.2011 19:25, schrieb Dirk Behme:
>> On 01.01.2011 18:52, Alexander Holler wrote:
>>> Hello,
>>>
>>> Am 01.01.2011 13:04, schrieb Dirk Behme:
>>>> On 22.12.2010 12:04, Alexander Holler wrote:
>>>>> gcc 4.5.1 seems to ignore (at least some) volatile definitions,
>>>>> avoid that as done in the kernel.
>>>>>
>>>>> Reading C99 6.7.3 8 and the comment 114) there, I think it is a
>>>>> bug of
>>>>> that
>>>>> gcc version to ignore the volatile type qualifier used e.g. in
>>>>> __arch_getl().
>>>>> Anyway, using a definition as in the kernel headers avoids such
>>>>> optimizations when
>>>>> gcc 4.5.1 is used.
>>>>>
>>>>> Maybe the headers as used in the current linux-kernel should be
>>>>> used,
>>>>> but to avoid large changes, I've just added a small change to the
>>>>> current headers.
>>>
>>>> Do you like to test the patch in the attachment? I named it 'v4'.
>>>>
>>>> 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.
>>>
>>> I've come across a bug which reads as the problem might be fixed in
>>> gcc 4.5.2:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052
>>>
>>> I will test gcc 4.5.2 in the next days.
>>
>> Have you been able to test v4 of the patch I sent with gcc 4.5.1?
>
> No, sorry, I don't have a test case for consequent write* and I will
> have to write one.

?

If I remember correctly, the test case for this patch was compiling 
U-Boot with 4.5.1 and then check

a) if it boots at Beagle (correct clock.c)
b) if NAND works ok (correct omap_gpmc.c)

?

Thanks

Dirk

  reply	other threads:[~2011-01-01 19:21 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 [this message]
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
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=4D1F7EC6.9090607@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