From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2] i.MX28: Drop __naked function from spl_mem_init
Date: Tue, 20 Mar 2012 10:17:13 +0100 [thread overview]
Message-ID: <4F684B19.2050306@denx.de> (raw)
In-Reply-To: <20120320083929.94A98202A50@gemini.denx.de>
On 20/03/2012 09:39, Wolfgang Denk wrote:
> Dear Stefano,
>
Hi Wolfgang,
>
> Yes, we should fix warnings. If you run a MAKEALL and can be sure
> that any message printed is a new problem you will not miss it, and
> act as needed. If youy know that a build will pop up a number or
> warnings, it's all too easy to miss if there is a new one - and
> checking takes much more concentration. This is to be avoided.
Yes, I understand your point - and generally I agree with you . Only
this special case let me think if the compiler is always right...
>
> On the other hand, I agree that we should avoid obscure code as
> well. But then, to me the assembler code "subs pc, r14, #4" is
> already obscure enough - I have to admit that I don't really grok it,
> nor why this needs to be a __naked function.
Well, but you should admit that if the comment is really an assembly
line and the next line itself is written directly in machine code, it is
quite normal to have doubts why we need a compiler and / or an assembler...
>
> My understanding is that to avoid the warning we can either use this
> "pre-compiled constant instruction" trick, or we would have to create
> a new assembler source file for this single instruction function.
>
> When Marek and I discussed this, the constant seemed to be the
> simplest approach (not the nicest, though).
>
> If you don't like it, then we I think we will end up with a new tiny
> assembler source file. Would that be preferred by you?
The current fix is at the moment an exception - personally I am aware of
it and I can live with it.
I wanted simply to raise a question about this odd case, when we are
sometimes constrained by the compiler to do very strange things...
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
next prev parent reply other threads:[~2012-03-20 9:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Message-Id: <1331903075-10468-1-git-send-email-marex@denx.de>
2012-03-16 21:32 ` [U-Boot] [PATCH V2] i.MX28: Drop __naked function from spl_mem_init Marek Vasut
2012-03-20 7:57 ` Stefano Babic
2012-03-20 8:21 ` Marek Vasut
2012-03-20 8:39 ` Wolfgang Denk
2012-03-20 9:09 ` Marek Vasut
2012-03-20 9:21 ` Stefano Babic
2012-03-20 17:38 ` Wolfgang Denk
2012-03-20 9:17 ` Stefano Babic [this message]
2012-03-20 10:43 ` Stefano Babic
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=4F684B19.2050306@denx.de \
--to=sbabic@denx.de \
--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