Re: [OMPI devel] inline asm patch

2007-12-20 Thread Jeff Squyres
It turned out to be a little more than that, actually -- the GCC_INLINE_ASSEMBLY was a red-herring: https://svn.open-mpi.org/trac/ompi/changeset/17005 The real problem was that for platforms that fall back to the inline C for opal_atomic_[add|sub]_[32|64], the prototypes were still

Re: [OMPI devel] inline asm patch

2007-12-20 Thread Jeff Squyres
I agree -- Ethan's is better. George? On Dec 20, 2007, at 12:41 PM, Ethan Mallove wrote: Can this logic be up-leveled into sys/atomic.h (see below) such that we have it in one atomic.h file instead of nine atomic.h files? This would mean that if a given lower-level /atomic.h file defines a

Re: [OMPI devel] inline asm patch

2007-12-20 Thread Ethan Mallove
On Thu, Dec/20/2007 08:50:41AM, Jeff Squyres wrote: > After Ethan's inline assembly patch (to make the > upper-level atomic.h declarations match the lower-level > inline definitions -- if they exist), I've had a problem > with the PGI compiler on Linux. > > I finally tracked down the issue this

Re: [OMPI devel] [ofa-general] [RFC] XRC -- make receiving XRC QP independent of any one user process

2007-12-20 Thread Tang, Changqing
Jack: Thanks for adding this new function, this is what we need. There is one issue I want to make clear, This new "kernel" owned QP "will be destroyed when the XRC domain is closed (i.e., as part of a ibv_close_xrc_domain call, but only when the domain's reference count goes to

[OMPI devel] Peter Wong/Austin/IBM is out of the office.

2007-12-20 Thread Peter Wong
I will be out of the office starting 12/20/2007 and will not return until 01/07/2008.

Re: [OMPI devel] Making an embeddable libev

2007-12-20 Thread Terry Dontje
Marc, Jeff is one of the most professional individuals, that rationally discusses technical issues and aims to reach a compromises, that I know of. The Open MPI community relies on him continually to broker solid technical compromises in our community. So to see such vitriol leads me to