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 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
On Mar 5, 2014, at 10:07 AM, Richard Henderson r...@redhat.com 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 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. The term optimization barrier isn't well-defined. Richard.
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 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). Greetings, Hannes
Re: linux says it is a bug
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.
Re: linux says it is a bug
On Tue, Mar 4, 2014 at 10:19 AM, Jonathan Wakely jwakely@gmail.com 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. 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 Tue, Mar 04, 2014 at 09:19:40AM +, 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?
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: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 Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa han...@stressinduktion.org 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 12:08:19PM +0100, Richard Biener wrote: On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa han...@stressinduktion.org 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
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, 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
On Tue, Mar 4, 2014 at 1:01 PM, Hans-Peter Nilsson h...@bitrange.com 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, Mar 04, 2014 at 12:08:19PM +0100, Richard Biener wrote: On Tue, Mar 4, 2014 at 10:33 AM, Hannes Frederic Sowa han...@stressinduktion.org 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 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 Mar 4, 2014, at 2:30 PM, Richard Henderson r...@redhat.com 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
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
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
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
