Re: [PATCH -v2 14/33] locking,m68k: Implement atomic_fetch_{add,sub,and,or,xor}()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 20 Jun 2016, Andreas Schwab wrote:

Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:

Could either of you comment on the below patch?

All atomic functions that return a value should imply full memory 
barrier semantics -- this very much includes a compiler barrier / 
memory clobber.

I wonder if it is possible to find a case where this makes a real 
difference, ie. where the compiler erroneously reused a value due to the 
missing barrier.

What the compiler does erroneously is a compiler bug by definition. But I 
think that was not what you meant.

Perhaps you're asking whether gcc in particular does what you expect, 
despite ambiguous source code. But what about other tools like static 
analyzers?

Ambiguous code is likely to attract patches like this for as long as it 
remains ambiguous. That's a waste of everyone's time, if patches like this 
could be written and reviewed just once.

-- 


Andreas.


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux