On Wed, 11 Mar 2026 at 11:49, Jonathan Wakely <[email protected]> wrote:
>
> On Wed, 11 Mar 2026 at 11:41, Jonathan Wakely <[email protected]> wrote:
> >
> > On Wed, 11 Mar 2026 at 10:56, Alexandre Oliva <[email protected]> wrote:
> > >
> > > On Mar 11, 2026, Jonathan Wakely <[email protected]> wrote:
> > >
> > > > On Wed, 11 Mar 2026, 05:29 Alexandre Oliva, <[email protected]> wrote:
> > > >>
> > > >> compare_exchange_weak is allowed to fail spuriously, and we're
> > > >> actually hitting such spurious failures quite often on ppc-vx7r2,
> > > >> presumably when random interrupts hit between ll and sc.
> > > >>
> > > >> Tolerate one such failure, hopefully that will suffice.
> > >
> > > > This is a bit of a problem, because we can't tell if the padding was
> > > > cleared or not. If it was not clear, the first compare_exchange_weak 
> > > > would
> > > > clear it, and the refund would succeed. But we want the test to fail in
> > > > that case.
> > >
> > > Erhm...  My understanding is that, when it returns false, no memory is
> > > changed, so the second attempt would start from exactly the same state
> > > as the first.
> >
> > "Remarks: A weak compare-and-exchange operation may fail spuriously.
> > That is, even when the contents of memory referred to by expected and
> > ptr are equal, it may return false and store back to expected the same
> > memory contents that were originally there."
> >
> > So `expected` is updated on a spurious failure, even if that doesn't
> > change any bits.
>
> I might have got a bit carried away, but I rewrote the whole test. How
> does this look? This should solve the problem with spurious weak
> failures, and no longer require -fno-tree-sra to retrieve the padding
> bits from the value in the atomic.

Oh and also changed the struct to ensure there actually *is* some
padding, otherwise on byte-aligned targets like cris-elf it's a 3-byte
struct with no padding. I'll add that to the commit message.

Reply via email to