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

Pavel Machek pavel at denx.de
Mon Nov 5 23:51:41 CET 2012


Hi!
 
    In message <20121105200340.GA15821 at 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));
>    > > >
>    > > > This makes the code actually unreadable.  Please add at least a
>    > > > comment what this is doing.
>    > >
>    > > Actually I think this shoul dbe split into two memcpy commands,
>    using
>    > > the addresses of the respective array elements directly, without
>    such
>    > > manual pointer arithmetics.
>    >
>    > I guess bigger question is: why does gcc miscompile that, and is it
>    > guaranteed that it will not miscompile the memcpy?
> 
>      I did not see Simon mentioning anythin about incorrect compilation.
>      My understanding was that it's just the usual "dereferencing
>      type-punned pointer" warnings issue.


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.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


More information about the U-Boot mailing list