On Tue, May 18, 2021 at 12:27 AM Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
> >
> > I wonder if the kernel should do the same, or whether there are still cases
> > where memcpy() isn't compiled optimally. armv6/7 used to be one such case, but
> > it was fixed in gcc 6.
>
> It would have to be memmove(), not memcpy() in this case, right?
No, it would simply be something like
#define __get_unaligned_t(type, ptr) \
({ type __val; memcpy(&__val, ptr, sizeof(type)); __val; })
#define get_unaligned(ptr) \
__get_unaligned_t(typeof(*(ptr)), ptr)
but honestly, the likelihood that the compiler generates something
horrible (possibly because of KASAN etc) is uncomfortably high.
I'd prefer the __packed thing. We don't actually use -O3, and it's
considered a bad idea, and the gcc bug is as such less likely than
just the above generating unacceptable code (we have several cases
where "bad code generation" ends up being an actual bug, since we
depend on inlining and depend on some code sequences not generating
calls etc).
But I hate how gcc is buggy in so many places here, and the
straightforward thing is made to explicitly not work.
I absolutely despise compiler people who think it's ok to generate
known bad code based on pointless "undefined behavior" arguments - and
then those same clever optimizations break even when you do things
properly. It's basically intellectual dishonesty - doing known
fragile things, blaming the user when it breaks, but then not
acknowledging that the fragile shit they did was broken even when the
user bent over backwards.
Linus
