[lttng-dev] current_thread_info() not respecting program order with gcc 4.8.x

[torvalds@linux-foundation.org (Linus Torvalds)]

On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler at ahsoftware.de> wrote:
>
> Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that
> current_thread_info() has the prototype
>
> static inline struct thread_info *current_thread_info(void)
> __attribute_const__;
>
> on arm (and arm64 and unicore32, something the paste from Mathieu missed so
> most people here might have missed that detail too). It's a very good
> finding from Luis.

No, because it is immaterial.

We *want* gcc to optimize away multiple accesses to "sp". Because it
doesn't *matter* whether "sp" changes or not, the *result* is always
the same. That's what the "const" means.

The "& ~(THREAD_SIZE - 1)" part will remove all the bits that can
change. Really. So the result *is* constant (within one thread).
Marking it constant and telling gcc that it can combine these things
is correct.

Guys, read my email again.

The bug is not that gcc can re-order or combine the accesses to "sp".
WE WANT THAT TO HAPPEN.

The bug is *outside* that "current_thread_info()" macro/inline
function. It's the *dereference* of the pointer that gcc re-orders.
AND THAT IS WRONG.

Gcc seems to mess up the alias analysis, and decide that the
deferences cannot alias. Which is wrong. They clearly *can* alias,
exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
the same value all the time.

                 Linus