https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92692
--- Comment #5 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #4) > (In reply to Wilco from comment #3) > > (In reply to Andrew Pinski from comment #2) > > > I think this has been a latent bug since revision 243200: > > > [AArch64] Separate shrink wrapping hooks implementation > > > > > > I think aarch64_disqualify_components would be a location which should > > > disqualify the Separate for the register 19. > > > > What is the "exclusives reservation granule" size? It could only fail if the > > granule is large and the spill happens to be in the same granule as the > > stxr. > NO "exclusives reservation granule" does not matter here, please read the > ARMv8 spec again copied below (B2-142): > LoadExcl/StoreExcl loops are guaranteed to make forward progress only if, > for any LoadExcl/StoreExcl loop > within a single thread of execution, the software meets all of the following > conditions: > 1 Between the Load-Exclusive and the Store-Exclusive, there are ****no > explicit memory accesses****, > preloads, direct or indirect System register writes, address translation > instructions, cache or TLB > maintenance instructions, exception generating instructions, exception > returns, or indirect branches. > --- CUT ---- > > ****no explicit memory accesses**** > Is a requirement so it does not matter what "exclusives reservation granule" > size is really. > We had gone through this beforehand with the ARM architectures and made sure > that the specifications was worded correctly to the above effect. The > wording change happened in 2016. Well I'm looking at the latest version (https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in figure B2-5 it explicitly states that a store that does not match the reservation granule on the same CPU must not change the exclusive state. However if a store does match the granule it is implementation defined, hence the reason for the text you quote to guarantee forward progress - otherwise a random store in the loop could accidentally match the exclusive granule and block progress. However I don't see it saying anywhere that all stores must clear the exclusive state.
