[Bug other/24692] New: Atomic builtins for v3

[Bug other/24692] New: Atomic builtins for v3

[pcarlini at suse dot de]

This is to track this issue:

  http://gcc.gnu.org/ml/gcc/2005-11/msg00285.html

In a nutshell, we need an easy way to exploit the new atomic builtins in the
library, irrespective of the actual target.


-- 
           Summary: Atomic builtins for v3
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pcarlini at suse dot de


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

[Bug other/24692] Atomic builtins for v3

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement


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

[Bug other/24692] Atomic builtins for v3

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2005-11-06 14:10 -------
Maybe the easy way to fix this is just have the distro change their policy of
compiling with i386 to compile always with i686.


-- 


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

[Bug other/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #2 from pcarlini at suse dot de  2005-11-06 14:13 -------
(In reply to comment #1)
> Maybe the easy way to fix this is just have the distro change their policy of
> compiling with i386 to compile always with i686.

Indeed, that's one point. However, there isn't only i386 to cause problems,
also
old Sparc. And targets which *may* have builtins but are simply not
implemented,
for one reason or another. And situations at the border, e.g., hppa.

Really, we want a *uniform* way to call the builtins from the library.


-- 


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

[Bug other/24692] Atomic builtins for v3

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-11-06 14:25 -------
(In reply to comment #2)
Let first point out i486 is more than 15 years old.
Second why do you really need an uniform way?  This seems like a way to make
everything in the compiler.  Maybe next you will be asking for the template
string to be part of the compiler and not the library (maybe I am going over
board here)?

Oh, for libobjc I need a way to describe the alignment and sizes of a struct
can that be built into the compiler too please (Really I don't think it
should).


-- 


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

[Bug other/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #4 from pcarlini at suse dot de  2005-11-06 14:28 -------
(In reply to comment #3)
> Let first point out i486 is more than 15 years old.

Sure, but it's not up to me and you to decide what is on the market, in
embedded form or otherwise. And it's not only about i386, again, please
read my previous message.
.................................................(maybe I am going over
> board here)?

Definitely.


-- 


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

[Bug other/24692] Atomic builtins for v3

[rth at gcc dot gnu dot org]

------- Comment #5 from rth at gcc dot gnu dot org  2005-11-06 23:40 -------
http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html

In short, you'll never get a completely unified way to implement these
routines.


-- 


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

[Bug other/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #6 from pcarlini at suse dot de  2005-11-07 02:49 -------
(In reply to comment #5)
> http://gcc.gnu.org/ml/gcc/2005-11/msg00326.html
> 
> In short, you'll never get a completely unified way to implement these
> routines.

Disagree, see: http://gcc.gnu.org/ml/gcc/2005-11/msg00332.html


-- 


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

[Bug other/24692] Atomic builtins for v3

[rth at gcc dot gnu dot org]

------- Comment #7 from rth at gcc dot gnu dot org  2005-11-07 08:48 -------
I stand by my statement.  This cannot go in libgcc.


-- 


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

[Bug other/24692] Atomic builtins for v3

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2005-11-07 10:16 -------
Paolo, the only viable way to get these inlined looks like a libstdc++
configure-time choice to say --disable-i386-support or sth like that.  You then
build libstdc++ against the atomic builtin primitives and at application
build-time either try falling back with preprocessor stuff rth suggested, or
don't do it and fail either at compile-time or later (maybe) at runtime with
some SIGILL or whatever you'll get.

Supporting different architectures and inlining at the same time is not
possible (well, apart from fixup by binary-patching at program startup, like
the kernel does (or did?), of course ;))


-- 


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

[Bug other/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #9 from pcarlini at suse dot de  2005-11-07 10:23 -------
(In reply to comment #8)
> Paolo, the only viable way to get these inlined looks like a libstdc++
> configure-time choice to say --disable-i386-support or sth like that.  You then
> build libstdc++ against the atomic builtin primitives and at application
> build-time either try falling back with preprocessor stuff rth suggested, or
> don't do it and fail either at compile-time or later (maybe) at runtime with
> some SIGILL or whatever you'll get.

I would certainly be in favor of something like that, it's a real pity that
the vetust i386 blocks us in using the new builtins and inlining the atomic
operations. 

I'm still convinced that something more general would be better, but I can
(rather easily) implement Rth idea too, otherwise. Of course it's still open
the task of preparing inline assembly implementing the various atomic
operations
for arches which don't have (for one reason or another) the builtins...

> Supporting different architectures and inlining at the same time is not
> possible (well, apart from fixup by binary-patching at program startup, like
> the kernel does (or did?), of course ;))

Please provide a detailed scenario, again. 


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #10 from pcarlini at suse dot de  2005-11-08 10:58 -------
Ok, apparently short-term at least, "smart" solutions using libgcc and dynamic
linking will not be implemented (one blocker are systems using a static
libgcc.a).
Therefore this one becomes a pure libstdc++-v3 PR. Then what we can improve is
rather limited: we can inline the atomics on architecture families that
uniformly implement the builtins (e.g., powerpc -> ok, i?86 -> not ok). The
atomics will also remain in the library, however, for ABI stability reasons.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|rth at gcc dot gnu dot org  |
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
          Component|other                       |libstdc++
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-08 10:58:34
               date|                            |
   Target Milestone|---                         |4.2.0


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

[Bug libstdc++/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #11 from pcarlini at suse dot de  2005-11-08 13:37 -------
Changing the declarations in include/bits/atomicity.h to inline definitions
forwarding to the builtins and including <bits/atomic_word.h> instead of
<bits/atomicity.h> in config/cpu/*/atomicity.h for the supported arch families
would be most of it, probably.


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pinskia at gcc dot gnu dot org]

------- Comment #12 from pinskia at gcc dot gnu dot org  2006-05-21 20:21 -------
Any news on this bug?


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #13 from pcarlini at suse dot de  2006-05-21 20:30 -------
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-05-21 20:33 -------
(In reply to comment #13)
> No news about this one. Frankly, since x86-* would not benefit in any way, I
> consider the work low priority.

What about x86_64 or even PowerPC64 both of which are becoming more popular
than x86.  In fact in a few years PPC64 might even supass x86 usage (but only
because of the PS3).


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #15 from pcarlini at suse dot de  2006-05-21 20:36 -------
(In reply to comment #14)
> (In reply to comment #13)
> > No news about this one. Frankly, since x86-* would not benefit in any way, I
> > consider the work low priority.
> 
> What about x86_64

Of course by x86-* I meant to include x86_64.


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[paolo at gcc dot gnu dot org]

------- Comment #16 from paolo at gcc dot gnu dot org  2006-05-29 20:00 -------
Subject: Bug 24692

Author: paolo
Date: Mon May 29 20:00:29 2006
New Revision: 114215

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114215
Log:
2006-05-29  Paolo Carlini  <pcarlini@suse.de>

        PR libstdc++/24692
        * include/bits/atomicity.h (__exchange_and_add_multi,
        __atomic_add_multi): New, depending on _GLIBCXX_ATOMIC_BUILTINS,
        inline the atomic builtins.
        (__exchange_and_add_dispatch, __atomic_add_dispatch): Adjust.
        * configure.ac: Define _GLIBCXX_ATOMIC_BUILTINS when the atomic
        builtins are available.
        * configure: Regenerate.
        * config.h.in: Likewise.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config.h.in
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/configure.ac
    trunk/libstdc++-v3/include/bits/atomicity.h


-- 


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

[Bug libstdc++/24692] Atomic builtins for v3

[pcarlini at suse dot de]

------- Comment #17 from pcarlini at suse dot de  2006-05-29 20:01 -------
Fixed.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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