Messages in this thread | | | Date | Thu, 21 Nov 2013 14:32:34 -0800 | Subject | Re: current_thread_info() not respecting program order with gcc 4.8.x | From | Linus Torvalds <> |
| |
On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@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
| |