Re: linux says it is a bug
On Wed, Mar 05, 2014 at 10:39:51AM +0400, Yury Gribov wrote: > >What is volatile instructions? Can you give us an example? > > Check volatile_insn_p. AFAIK there are two classes of volatile instructions: > * volatile asm > * unspec volatiles (target-specific instructions for e.g. protecting > function prologues) > > -Y Thanks.
Re: linux says it is a bug
On Mar 5, 2014, at 10:07 AM, Richard Henderson wrote: > On 03/04/2014 10:12 PM, Yury Gribov wrote: Asms without outputs are automatically volatile. So there ought be zero change with and without the explicit use of the __volatile__ keyword. >>> >>> That’s what the documentation says but it wasn’t actually true >>> as of a couple of releases ago, as I recall. >> >> Looks like 2005: >> >> $ git annotate gcc/c/c-typeck.c >> ... >> 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm >> statements without outputs, including simple ones, are treated >> 89552023( bonzini 2005-10-05 12:17:16 + 9074) as >> volatile. */ >> 89552023( bonzini 2005-10-05 12:17:16 + 9075) >> ASM_INPUT_P (args) = simple; >> 89552023( bonzini 2005-10-05 12:17:16 + 9076) >> ASM_VOLATILE_P (args) = (noutputs == 0); > > Yep, that's the one. So, more than "a couple" of releases: gcc 4.2 and later. Thanks gentlemen. That explains it — we ran into this in GCC 3.3.3 and then upgraded from there straight to V4.6 or so. paul
Re: linux says it is a bug
On 03/04/2014 10:12 PM, Yury Gribov wrote: >>> Asms without outputs are automatically volatile. So there ought be zero >>> change >>> with and without the explicit use of the __volatile__ keyword. >> >> That’s what the documentation says but it wasn’t actually true >> as of a couple of releases ago, as I recall. > > Looks like 2005: > > $ git annotate gcc/c/c-typeck.c > ... > 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm > statements without outputs, including simple ones, are treated > 89552023( bonzini 2005-10-05 12:17:16 + 9074) as > volatile. */ > 89552023( bonzini 2005-10-05 12:17:16 + 9075) > ASM_INPUT_P (args) = simple; > 89552023( bonzini 2005-10-05 12:17:16 + 9076) > ASM_VOLATILE_P (args) = (noutputs == 0); Yep, that's the one. So, more than "a couple" of releases: gcc 4.2 and later. r~
Re: linux says it is a bug
What is volatile instructions? Can you give us an example? Check volatile_insn_p. AFAIK there are two classes of volatile instructions: * volatile asm * unspec volatiles (target-specific instructions for e.g. protecting function prologues) -Y
Re: linux says it is a bug
>> Asms without outputs are automatically volatile. So there ought be zero change >> with and without the explicit use of the __volatile__ keyword. > > That’s what the documentation says but it wasn’t actually true > as of a couple of releases ago, as I recall. Looks like 2005: $ git annotate gcc/c/c-typeck.c ... 89552023( bonzini 2005-10-05 12:17:16 + 9073) /* asm statements without outputs, including simple ones, are treated 89552023( bonzini 2005-10-05 12:17:16 + 9074) as volatile. */ 89552023( bonzini 2005-10-05 12:17:16 + 9075) ASM_INPUT_P (args) = simple; 89552023( bonzini 2005-10-05 12:17:16 + 9076) ASM_VOLATILE_P (args) = (noutputs == 0); -Y
Re: linux says it is a bug
On Mar 4, 2014, at 2:30 PM, Richard Henderson wrote:
> On 03/04/2014 01:23 AM, Richard Biener wrote:
>> Doesn't sound like a bug but a feature. We can move
>> asm ("" : : : "memory") around freely up to the next/previous
>> instruction involving memory.
>
> Asms without outputs are automatically volatile. So there ought be zero
> change
> with and without the explicit use of the __volatile__ keyword.
That’s what the documentation says but it wasn’t actually true as of a couple
of releases ago, as I recall.
paul
Re: linux says it is a bug
On 03/04/2014 01:23 AM, Richard Biener wrote:
> Doesn't sound like a bug but a feature. We can move
> asm ("" : : : "memory") around freely up to the next/previous
> instruction involving memory.
Asms without outputs are automatically volatile. So there ought be zero change
with and without the explicit use of the __volatile__ keyword.
r~
Re: linux says it is a bug
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > 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?
> >>
> >> Of course it will: it's a barrier.
> >
> > Sure. My question was about the volatile marker. asm("":::"memory") should
> > act
> > as the barrier alone.
>
> __asm__("":::"memory")
>
> is a memory barrier
>
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
Hi Andrew,
What is volatile instructions?Can you give us an example?
--
Regards
lin zuojian
Re: linux says it is a bug
On Tue, Mar 4, 2014 at 1:01 PM, Hans-Peter Nilsson wrote:
> On Tue, 4 Mar 2014, Yury Gribov wrote:
>> Richard wrote:
>> > volatile __asm__("":::"memory")
>> >
>> > is a memory barrier and a barrier for other volatile instructions.
>>
>> AFAIK asm without output arguments is implicitly marked as volatile. So it
>> may
>> not be needed in barrier() at all.
>
> Yes, exactly. Had it at some time been needed, that'd be a bug.
> (I have a faint recollection of that, faint enough to be a false
> memory.)
Ah, indeed.
> brgds, H-P
Re: linux says it is a bug
On Tue, 4 Mar 2014, Yury Gribov wrote:
> Richard wrote:
> > volatile __asm__("":::"memory")
> >
> > is a memory barrier and a barrier for other volatile instructions.
>
> AFAIK asm without output arguments is implicitly marked as volatile. So it may
> not be needed in barrier() at all.
Yes, exactly. Had it at some time been needed, that'd be a bug.
(I have a faint recollection of that, faint enough to be a false
memory.)
brgds, H-P
Re: linux says it is a bug
Richard wrote:
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
AFAIK asm without output arguments is implicitly marked as volatile. So
it may not be needed in barrier() at all.
-Y
Re: linux says it is a bug
On Tue, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
> wrote:
> > On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> >> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> >> > 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?
> >>
> >> Of course it will: it's a barrier.
> >
> > Sure. My question was about the volatile marker. asm("":::"memory") should
> > act
> > as the barrier alone.
>
> __asm__("":::"memory")
>
> is a memory barrier
>
> volatile __asm__("":::"memory")
>
> is a memory barrier and a barrier for other volatile instructions.
>
> Nothing more, nothing less.
>
> Neither is a "optimization barrier" or "compiler barrier" or whatever
> name you invent.
Being a bit more familiar with the kernel code I often think about a
memory barrier as "fencing" instruction.
Thanks for the clarification,
Hannes
Re: linux says it is a bug
On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa
wrote:
> On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
>> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
>> >> > 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?
>>
>> Of course it will: it's a barrier.
>
> Sure. My question was about the volatile marker. asm("":::"memory") should act
> as the barrier alone.
__asm__("":::"memory")
is a memory barrier
volatile __asm__("":::"memory")
is a memory barrier and a barrier for other volatile instructions.
Nothing more, nothing less.
Neither is a "optimization barrier" or "compiler barrier" or whatever
name you invent.
Richard.
Re: linux says it is a bug
On Tue, Mar 04, 2014 at 09:26:31AM +, Andrew Haley wrote:
> On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote:
> >> > 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?
>
> Of course it will: it's a barrier.
Sure. My question was about the volatile marker. asm("":::"memory") should act
as the barrier alone.
Re: linux says it is a bug
On 03/04/2014 09:24 AM, Hannes Frederic Sowa wrote: >> > 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? Of course it will: it's a barrier. Andrew.
Re: linux says it is a bug
On Tue, Mar 04, 2014 at 09:19:40AM +, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> 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 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?
Re: linux says it is a bug
On Tue, Mar 4, 2014 at 10:19 AM, Jonathan Wakely wrote:
> On 4 March 2014 09:17, Hannes Frederic Sowa
> 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 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.
Re: linux says it is a bug
On 4 March 2014 09:17, Hannes Frederic Sowa 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 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.
Re: linux says it is a bug
On Tue, Mar 04, 2014 at 10:10:21AM +0100, Richard Biener wrote:
> On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian 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).
Greetings,
Hannes
Re: linux says it is a bug
On Tue, Mar 4, 2014 at 7:40 AM, lin zuojian 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.
The term "optimization barrier" isn't well-defined.
Richard.
linux says it is a bug
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?
--
Regards
lin zuojian
