[U-Boot] [PATCH 2/3] md5: Fix gcc-4.7 build problem in md5

[Marek Vasut <marex@denx.de>]

Dear Pavel Machek,

> 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

I dont think -fno-strict-aliasing is the way to go, it'll only hide the problem, 
no?

Best regards,
Marek Vasut