From: Pavel Machek <pavel@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/3] md5: Fix gcc-4.7 build problem in md5
Date: Tue, 6 Nov 2012 12:07:45 +0100 [thread overview]
Message-ID: <20121106110745.GA5494@elf.ucw.cz> (raw)
In-Reply-To: <201211060156.50580.marex@denx.de>
On Tue 2012-11-06 01:56:50, Marek Vasut wrote:
> Dear Pavel Machek,
>
> > Hi!
> >
> > In message <20121105200340.GA15821@xo-6d-61-c0.localdomain> you wrote:
> > > > > > > /* Append length in bits and transform */
> > > > > > >
> > > > > > > - ctx->in32[14] = ctx->bits[0];
> > > > > > > - ctx->in32[15] = ctx->bits[1];
> > > > > > > + memcpy(ctx->in + 14 * sizeof(__u32), ctx->bits, 2 *
> > >
> > > sizeof(__u32));
> > Is there some alternate solution? The memcpy is really ugly...
> >
> > Plus... does it solve the issue? The code does not look like being
> > compatible with strict pointer aliasing... and I don't think memcpy()
> > helps.
> >
> > arch/nds32/config.mk:PLATFORM_RELFLAGS += -fno-strict-aliasing
> > -fno-common -mrelax
> > arch/x86/config.mk:PLATFORM_CPPFLAGS += -fno-strict-aliasing
> >
> > We should really do that globally.
>
> Were you even able to replicate this problem in the first place? Isn't this
> whole "problem" a problem of a broken (ubuntu/linaro) toolchain again?
This is not something you can replicate. At least md5 code is unsafe
with strict aliasing, probably most of u-boot, because low-level
people write code like that. Thus we should do
-fno-strict-aliasing. Otherwise compiler may decide in future to
"miscompile" our code, even if it compiles it correctly now.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2012-11-06 11:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-03 21:45 [U-Boot] [PATCH 1/3] lzma: update to lzma sdk 9.20 Simon Glass
2012-11-03 21:45 ` [U-Boot] [PATCH 2/3] md5: Fix gcc-4.7 build problem in md5 Simon Glass
2012-11-04 0:32 ` Wolfgang Denk
2012-11-04 0:39 ` Wolfgang Denk
2012-11-05 20:03 ` Pavel Machek
2012-11-05 20:50 ` Wolfgang Denk
2012-11-05 21:15 ` Han Shen(沈涵)
2012-11-05 22:51 ` Pavel Machek
2012-11-06 0:56 ` Marek Vasut
2012-11-06 11:07 ` Pavel Machek [this message]
2012-11-06 22:30 ` Marek Vasut
2012-11-07 22:18 ` Simon Glass
2012-11-03 21:45 ` [U-Boot] [PATCH 3/3] Add stricmp() and strnicmp() Simon Glass
2012-11-04 0:31 ` Wolfgang Denk
2012-11-04 4:38 ` Simon Glass
2012-11-04 22:47 ` Albert ARIBAUD
2012-11-07 22:00 ` Simon Glass
2012-11-22 2:51 ` Simon Glass
2012-12-07 15:49 ` [U-Boot] [U-Boot,1/3] lzma: update to lzma sdk 9.20 Tom Rini
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=20121106110745.GA5494@elf.ucw.cz \
--to=pavel@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