https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111077
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed| |2023-08-20
Ever confirmed|0 |1
Target Milestone|--- |13.3
Status|UNCONFIRMED |ASSIGNED
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to comexk from comment #0)
> [See also:
> https://github.com/rust-lang/unsafe-code-guidelines/issues/449#issuecomment-
> 1677985851, which has a comparison of different compilers.]
"GCC does nothing to handle this" is incorrect. Only the case of an initial
value with non-zero padding is not handled, because atomic_ref doesn't control
the variable's initial value. atomic_ref::store and atomic_ref::exchange clear
padding bits, and so does a successful compare_exchange_{weak,strong}.
But we do have a bug here, because if that initial value has non-zero padding
bits even a compare_exchange_strong loop won't eventually settle, because we
keep zeroing the padding in the 'expected' value, which means it never matches.
We return the current value (with padding bits preserved), but then the next
call using that exact value will get the padding zeroed again, and fail to
match.
