[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40988

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect the inline-asm is broken, I am 90% sure of it.

[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40988

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So yes I was correct in saying the inline-asm was incorrect. it should have
been:
```

        __asm__ __volatile__(
                "btrl %2,%1\n\tsbbl %0,%0"
                :"=r" (oldbit), "+m" (ADDR)
                :"Ir" (nr) : "memory");
        return oldbit;
```

as this both reads and write the memory.

[Bug target/40988] incorrect code when using ..._bit macros from asm/bitops.h in a loop in userspace program

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40988

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
One more note the Linux kernel sources has been corrected already.

They do now:
        asm volatile(__ASM_SIZE(btr) " %2,%1"
                     CC_SET(c)
                     : CC_OUT(c) (oldbit)
                     : ADDR, "Ir" (nr) : "memory");
        return oldbit;


and 

        asm volatile(__ASM_SIZE(bts) " %1,%0" : : ADDR, "Ir" (nr) : "memory");

Which describes the same thing as "+" as the memory clobber says it will update
memory too.

Linux commit 5b77e95dd7790 changed it from "+" to the above.
Linux commit 92934bcbf96bc (in 2006 which was included in 2.6.16) fixed it to
be "+" so you must have copied the linux sources from FC6 and didn't look to
see if the Linux kernel header was updated in your FC11 system.