This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: linux says it is a bug
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Hannes Frederic Sowa <hannes at stressinduktion dot org>, lin zuojian <manjian2006 at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 4 Mar 2014 10:23:20 +0100
- Subject: Re: linux says it is a bug
- Authentication-results: sourceware.org; auth=none
- References: <20140304064026 dot GE8019 at ubuntu> <CAFiYyc3bVGgG=dmozPG5m4Vx_oJbR=rR=TsZfj+01dvXmWiJmw at mail dot gmail dot com> <20140304091703 dot GE17043 at order dot stressinduktion dot org> <CAH6eHdQ2mrDYm5s2FiGWdQnp7V_cV0JdwGA381SXzp3D79j+=Q at mail dot gmail dot com>
On Tue, Mar 4, 2014 at 10:19 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa <hannes@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 <manjian2006@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.
Doesn't sound like a bug but a feature. We can move
asm ("" : : : "memory") around freely up to the next/previous
instruction involving memory.
Richard.