Bug 52190 - question about atomic intrinsics -- test and documentation vary -- please clarify
Summary: question about atomic intrinsics -- test and documentation vary -- please cla...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-09 18:46 UTC by mib.bugzilla
Modified: 2014-03-25 19:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-02-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mib.bugzilla 2012-02-09 18:46:47 UTC
This url http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

shows these 2 intrinsics declared like this:
Built-in Function: bool __atomic_always_lock_free (size_t size)
Built-in Function: bool __atomic_is_lock_free (size_t size)

But there are test cases for these 2 functions that have 2nd argument (memmodel) e.g. atomic-lockfree.c lines 23 and 24

    r1 = __atomic_always_lock_free (sizeof(char), 0); 
    r2 = __atomic_is_lock_free (sizeof(char), 0);

Please clarify, thanks!
Comment 1 Andrew Macleod 2012-02-09 20:40:05 UTC
Its a discrepancy due to vagueness :-)

The extra parameter is for an optional pointer to the object to allow the alignment to be examined.

The standard was unclear about alignment issues, and when the atomics were being designed and implemented, it was still unclear what direction things were going.  

The routines were designed so that an aligned object could be lock free and an unaligned object may be locked.  The last set of discussions I had indicate that it is undesirable for 2 objects of the same size not to both be lock-free or locked.  (ie, all objects of a given size must be the same).   We'll finalize it all in gcc 4.8, but I think going forward we are probably only going to support aligned atomic operations...

Anyway, thats why the extra parameter is there.  a 0 passed in instead of a pointer means "use standard alignment for an object of this size".

I will change the documentation to match reality.

Andrew
Comment 2 Richard Biener 2012-02-10 11:14:02 UTC
Confirmed thus.
Comment 3 Andrew Macleod 2012-02-10 18:37:22 UTC
Author: amacleod
Date: Fri Feb 10 18:37:18 2012
New Revision: 184112

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184112
Log:

2012-02-10  Andrew MacLeod  <amacleod@redhat.com>

	PR c/52190
	* doc/extend.texi : Update comments for __atomic_compare_exchange and
	__atomic_{is,always}_lock_free.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/extend.texi
Comment 4 Jonathan Wakely 2012-02-12 14:02:42 UTC
The docs for __atomic_compare_exchange_n say:
   "True is returned if *desired is written into *ptr"
but desired is not a pointer, that asterisk should go, right?
Comment 5 Andrew Macleod 2012-02-13 15:37:38 UTC
Author: amacleod
Date: Mon Feb 13 15:37:33 2012
New Revision: 184156

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184156
Log:

2012-02-13  Andrew MacLeod  <amacleod@redhat.com>

	PR c/52190
	* doc/extend.texi : Fix another __atomic_compare_exchange typo.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/doc/extend.texi
Comment 6 Marek Polacek 2014-03-25 19:14:02 UTC
Should be fixed.