On Tue, Mar 04, 2014 at 09:19:40AM +0000, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa <han...@stressinduktion.org>
> wrote:
> > On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> >> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian <manjian2...@gmail.com> wrote:
> >> > Hi,
> >> > in include/linux/compiler-gcc.h :
> >> >
> >> > /* Optimization barrier */
> >> > /* The "volatile" is due to gcc bugs */
> >> > #define barrier() __asm__ __volatile__("": : :"memory")
> >> >
> >> > The comment of Linux says this is a gcc bug.But will any sane compiler
> >> > disable optimization without "volatile" key word?
> >>
> >> Depends what they call an "optimization barrier". A plain
> >> __asm__ ("" : : : "memory") is a memory barrier. Adding volatile
> >> to the asm makes it a barrier for every other volatile instruction,
> >> nothing more.
> >
> > This is meant to be a compiler barrier not a memory barrier and got
> > added by David Miller because of a problem in gcc-2.7.2:
> >
> > | Add __volatile__ to barrier() definition, I convinced Linus
> > | to eat this patch. The problem is that with gcc-2.7.2 derived
> > | compilers the instruction scheduler can move it around due to
> > | a bug. This bug appears on sparc64/SMP with our old compiler
> > | in that is miscompiles the beginning of exit.c:release() causing
> > | lockups if the race is hit in the SMP specific code there. I
> > | believe sparc32 gcc-2.7.2 sees this bug too, but I'm not too sure
> > | (Anton showed me something similar once).
>
>
>
> So the bug was probably fixed more than 15 years ago.
Probably :)
But the __volatile__ shoud do no harm and shouldn't influence code
generation in any way, no?
