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

Simon Glass sjg at chromium.org
Wed Nov 7 23:18:56 CET 2012


Hi,

On Tue, Nov 6, 2012 at 2:30 PM, Marek Vasut <marex at denx.de> wrote:
> Dear Pavel Machek,
>
>> On Tue 2012-11-06 01:56:50, Marek Vasut wrote:
>> > 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));
>> > >
>> > > 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?

Yes I agree.

I believe this problem might have been a mistake on my part. I think I
incorrectly merged Marek's change 'b68d63c GCC47: Fix warning in
md5.c' when I was testing. Or it could me that my compiler was broken,
as for a while it was generating these errors when it should not.

So I believe we can drop this patch as I am no longer seeing the warning.

If so, sorry for the noise.

Regards,
Simon

>
> Best regards,
> Marek Vasut
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


More information about the U-Boot mailing list