Re: How To Add a Sequence Point?
Andrew Pinski writes: > On Sat, Feb 2, 2013 at 5:10 PM, Jeffrey Walton wrote: >> Thanks Andrew. >> >> So, it looks like I don't understand sequence points. Please forgive >> my ignorance. >> >> What does C/C++ and GCC offer to ensure writes are complete before >> reads are performed on a value in a multi-threaded program? > > GCC offers some builtins which start with __atomic_* (older versions > of GCC [4.2.x-4.6.x] only offer __sync_* builtins functions). C++11 > offers some atomic functions too (which in turn calls the __atomic_* > functions). I don't remember if C11 offers those similar functions or > not. Even atomics do not guarantee that writes are finished before any other read on other threads. There's usually no way to do that in modern computer architectures (except for MMIO), short of adding an explicit dependency. Typically you don't want to do it anyways for performance reasons. But that's off topic for this mailing list and should probably be discussed somewhere else. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: How To Add a Sequence Point?
On 03/02/13 02:10, Jeffrey Walton wrote:
Thanks Andrew.
So, it looks like I don't understand sequence points. Please forgive
my ignorance.
What does C/C++ and GCC offer to ensure writes are complete before
reads are performed on a value in a multi-threaded program?
Jeff
You are probably looking for a "memory barrier", rather than a "sequence
point". But even that will not be enough if you have an SMP system -
though it might let you get better results from your Googling. If
possible, your best bet is probably to use facilities provided by your
OS - but that is very much outside the scope of this mailing list.
Anyway, the simplest memory barrier in gcc is :
asm volatile("" ::: "memory");
This tells gcc that memory may be used in unexpected ways at this point
in the code - so any outstanding writes are handled before this point,
and no reads are started until after it. But that only applies at the
assembly code level - the compiler does not control things like caches,
write buffers, read-ahead buffers, etc.
mvh.,
David
On Sat, Feb 2, 2013 at 8:07 PM, Andrew Pinski wrote:
On Sat, Feb 2, 2013 at 4:59 PM, Jeffrey Walton wrote:
Hi All,
How do I add a sequence point in my C/C++ code?
A semi-colon (end of the statement), a comma (but not as an argument
separator though) are both sequence points.
Thanks,
Andrew Pinski
Googling brings up a lot of 'volatile' hits, but I believe that's an
abuse of GCC's interpretation of volatile since I'm not working with
memory mapped hardware or registers.
Re: System V Application Binary Interface 0.99.5
> On 02/01/2013 12:38 AM, Jan Hubicka wrote: > > Doing the extensions at caller side always is however IMO a preformance bug > > in > > GCC. We can definitly drop them at -Os, for non-PRS targets and for calls > > within compilation unit where we know that GCC is not really producing > > code like in Michael's testcase. > > Well we can, yeah, at the cost of breaking interworking with LLVM. > Do we care? ;-) Yes, we (at least I) care ;) The bug ought to be fixed at LLVM side, is there PR filled in? For time being we can optimize local calls. I remember that in the past I ran over benchmarks where these extra casts was making us to lose compared to other compilers, so it is not 100% uninteresting detail. Honza > > Andrew.
Re: How To Add a Sequence Point?
On Sun, Feb 3, 2013 at 2:47 PM, David Brown wrote:
> On 03/02/13 02:10, Jeffrey Walton wrote:
>>
>> So, it looks like I don't understand sequence points. Please forgive
>> my ignorance.
>>
>> What does C/C++ and GCC offer to ensure writes are complete before
>> reads are performed on a value in a multi-threaded program?
>>
> You are probably looking for a "memory barrier", rather than a "sequence
> point". But even that will not be enough if you have an SMP system - though
> it might let you get better results from your Googling. If possible, your
> best bet is probably to use facilities provided by your OS - but that is
> very much outside the scope of this mailing list.
>
> Anyway, the simplest memory barrier in gcc is :
>
> asm volatile("" ::: "memory");
>
> This tells gcc that memory may be used in unexpected ways at this point in
> the code - so any outstanding writes are handled before this point, and no
> reads are started until after it. But that only applies at the assembly
> code level
Thanks David. That's what I thought (memory barriers and ASM), but I
did not want to taint other's answers, especially since it seemed like
sequence points should have addressed my use cases.
> the compiler does not control things like caches, write
> buffers, read-ahead buffers, etc.
So I am clear: caches, buffers etc are OS - and not CPU caches?
Sorry to ask. I'm trying to figure out (or understand) where the
disconnect occurs between the language and the implementation.
Jeff
Re: How To Add a Sequence Point?
On 03/02/13 21:20, Jeffrey Walton wrote:
On Sun, Feb 3, 2013 at 2:47 PM, David Brown wrote:
On 03/02/13 02:10, Jeffrey Walton wrote:
So, it looks like I don't understand sequence points. Please forgive
my ignorance.
What does C/C++ and GCC offer to ensure writes are complete before
reads are performed on a value in a multi-threaded program?
You are probably looking for a "memory barrier", rather than a "sequence
point". But even that will not be enough if you have an SMP system - though
it might let you get better results from your Googling. If possible, your
best bet is probably to use facilities provided by your OS - but that is
very much outside the scope of this mailing list.
Anyway, the simplest memory barrier in gcc is :
asm volatile("" ::: "memory");
This tells gcc that memory may be used in unexpected ways at this point in
the code - so any outstanding writes are handled before this point, and no
reads are started until after it. But that only applies at the assembly
code level
Thanks David. That's what I thought (memory barriers and ASM), but I
did not want to taint other's answers, especially since it seemed like
sequence points should have addressed my use cases.
the compiler does not control things like caches, write
buffers, read-ahead buffers, etc.
So I am clear: caches, buffers etc are OS - and not CPU caches?
No, I am talking about CPU caches and buffers. OS-related concepts of
buffers and caches are controlled by OS system calls.
Sorry to ask. I'm trying to figure out (or understand) where the
disconnect occurs between the language and the implementation.
There are assembly-level instructions that can influence things like CPU
caches (details vary according to processor), but "normal" C code cannot
generate them. A few C compilers on some targets will generate
cache-control code, such as forcing a volatile write to skip the cache -
but that is not common behaviour. So to affect the cache, enforce
memory access orders, etc., you need to either use assembly code, OS
functions, additional compiler intrinsic functions or features, or
additional library code. The assembly memory barrier above will /not/
affect data caches or write buffers, and will therefore not affect
memory ordering. You have to use something like a cpu-specific
instruction (such as asm volatile("msync" ::: "memory") on a PPC
target), or atomic access using the gcc extensions or the newer C11
atomic types, or an OS-specific feature.
gcc-4.8-20130203 is now available
Snapshot gcc-4.8-20130203 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130203/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 195703 You'll find: gcc-4.8-20130203.tar.bz2 Complete GCC MD5=cd63746924695fbe5a18dd5d23591e20 SHA1=e9d5125e460357503745c8d8cf61da27fd4a2530 Diffs from 4.8-20130127 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
more 4.7 backports?
Are there plans to do more backports of regression fixes to 4.7 before 4.7.3? Here is a list of bugs that have patches applied to 4.8 to fix the bug, but which are still listed as 4.7 regressions: 48189 - ice-on-valid 55018 - wrong-code 54563 - ice-on-valid - already backported? 54974 - [arm] wrong-code (last comment was asking about 4.7 backport) 54051 - [arm] wrong-code? 55043 - rejects-valid 55964 - ice 55890 - ice-on-invalid 55660 - [lto] ice-on-invalid 55107 - compile-time-hog 54767 - wrong-code 53844 - missed-optimization (fixed back in July and waiting to see if any fallout?) 53676 - missed-optimization (discussion about 4.7 backport after some more 4.8 exposure since August) 44061 - diagnostic 35634 - bad-code, however 'Unlikely going to be backported.' 53636 - wrong-code 54295 - wrong-code 55614 - alignment issue/tree-optimization 54919 - wrong-code, however 'no plans to work on back-ports of my patch for the release branches' 54073 - missed-optimization 'not planning to backport it right now.' 51447 - wrong-code, however 'Could be back-ported, but IMHO this issue is not important enough for that so I'm not going to work on back-ports.' 48766 - ice-on-valid 43961 - [arm] target Hope this is helpful. thanks, -Kenny
Re: How To Add a Sequence Point?
On Sat, Feb 2, 2013 at 5:10 PM, Jeffrey Walton wrote: > > What does C/C++ and GCC offer to ensure writes are complete before > reads are performed on a value in a multi-threaded program? The write must be done using __atomic_store(pointer, value, __ATOMIC_RELEASE); The read must be done using __atomic_load(pointer, pointer_to_value, __ATOMIC_ACQUIRE); Or you must use other atomic operations with a similar release/acquire sequence, or using a more strict memory model. Ian
Re: How To Add a Sequence Point?
On Sun, Feb 3, 2013 at 11:47 AM, David Brown wrote:
>
> Anyway, the simplest memory barrier in gcc is :
>
> asm volatile("" ::: "memory");
That is a compilation level memory barrier, but it clearly does
nothing at the machine level.
To get a machine level (and compilation level) memory barrier using
current GCC, use
__atomic_thread_fence (__ATOMIC_SEQ_CST);
Ian
