http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-08-05
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-08-05
19:36:24 UTC ---
The analysis looks correct, and I think the patch is actually an improvement on
the old behaviour, correctly setting 'expected' to 0 for the first CAS but also
avoiding unnecessarily looping when the second CAS fails: we don't need to loop
and do the first CAS again to decide what to do, examining the result of that
second CAS tells you what needs to be done.
I don't particularly like the variable name 'expected' because it serves two
purposes: it holds the expected value and after the CAS it holds the actual
value, the name 'expected' only suits the first usage and makes comparisons
such as (expected == guard_bit) look odd. It's not the expected value that's
being compared, it's the actual value which was *not* what was expected. I
preferred the original name "old", or maybe better yet "current".
