[Bug c/52190] New: question about atomic intrinsics -- test and documentation vary -- please clarify

[Bug c/52190] New: question about atomic intrinsics -- test and documentation vary -- please clarify

[mib.bugzilla at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

             Bug #: 52190
           Summary: question about atomic intrinsics -- test and
                    documentation vary -- please clarify
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mib.bugzilla@gmail.com


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!

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[amacleod at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> 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

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-10
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-10 11:14:02 UTC ---
Confirmed thus.

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[amacleod at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> 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

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 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?

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[amacleod at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> 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

[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed.