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)); > > > > > > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
