[U-Boot] [PATCH 2/3] md5: Fix gcc-4.7 build problem in md5
Marek Vasut
marex at denx.de
Tue Nov 6 01:56:50 CET 2012
Dear Pavel Machek,
> 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
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?
Best regards,
Marek Vasut
More information about the U-Boot
mailing list