This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?


Hi,

On Sun, 28 Oct 2007, David Miller wrote:

> the program would have allowed them to occur, otherwise you risk
> taking exceptions.
> 
> Do you really think that:
> 
> 	the_pointer_is_valid = func(potentially_bad_pointer);
> 	if (the_pointer_is_valid)
> 		*potentially_bad_pointer++;
> 
> should generate any memory accesses when 'the_pointer_is_valid'
> evaluates to false?

No, it of course should not.  And, surprise, it doesn't.  But in the 
following example the store can be moved out of it's control region:

	the_pointer_is_valid = func(potentially_bad_pointer);
	*potentially_bad_pointer = 0;  // Oops, unchecked access
	if (the_pointer_is_valid)
		*potentially_bad_pointer++;

Due to the unchecked access above, GCC is entitled to assume that also the 
second access will not trap, hence it can be moved down.

> And yet this is just another form of our original "threading" example:
> 
> 	if (pthread_mutex_trylock(lock))
> 		*counter++;

As GCC can't know that *counter will not trap, this is maybe the same code 
as your first example, but like there GCC won't do anything interesting.

> Only if you can prove that the program would access said memory with 
> said kind of access (read or write) can you legally speculate.

Good, we agree.  Where does GCC currently break this?


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]