lkml.org 
[lkml]   [2013]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: current_thread_info() not respecting program order with gcc 4.8.x
Am 20.11.2013 01:41, schrieb Linus Torvalds:

> It seems that some gcc alias analysis completely incorrectly thinks
> that they are not the same memory location, and do not alias. My guess
> would be that gcc sees that that they are based on the stack pointer
> with "different" offsets, and decides that the memory locations must
> be different - without noticing that the "& ~(THREAD_SIZE - 1)" will
> end up generating the same address for both of them.

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.

I'm writing this message because his mail doesn't have an in-reply-to
header, so it might be missed in this thread.

As Luis said, declaring current_thread_info() as a const function is
wrong. The gcc manual says:

----
const

Many functions do not examine any values except their arguments, and
have no effects except the return value. Basically this is just slightly
more strict class than the pure attribute below, since function is not
allowed to read global memory.

Note that a function that has pointer arguments and examines the data
pointed to must not be declared const. Likewise, a function that calls a
non-const function usually must not be const. It does not make sense for
a const function to return void.
----

So current_thread_info() clearly violates the constrain to not read
global memory. Or in other words, that __attribute_const__ tells gcc
explicitly that the two reads are pointing to different locations
because they are assumed to be local (through the const).

So This might be the reason why gcc misses that different calls to
current_thread_info() might point to the same memory location.


As I've an arm gcc 4.8.1 ready too, I'm joining Luis question where the
reordering can be found. If someone would point me to the source/object
where this happens, I could have a look if removing the
__attribute_const__ makes a difference.

Regards,

Alexander Holler


\
 
 \ /
  Last update: 2013-11-21 18:01    [W:1.449 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site