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 bel
I will be out of the office starting 12/20/2007 and will not return until
01/07/2008.
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 morning -- it seems that
OMPI_GCC_INLINE_ASSEMBLY is 0 for
Thanks Terry (and thanks to those who sent supportive off-list mails
to me).
For those of you who are wondering what this is all about, it's about
Open MPI upgrading to libev from libevent. Marc's mail was a cross-
post from the libev mailing list (he's the author of the libev
software).
Adding Open MPI and MVAPICH community to the thread.
Pasha (Pavel Shamis)
Jack Morgenstein wrote:
background: see "XRC Cleanup order issue thread" at
http://lists.openfabrics.org/pipermail/general/2007-December/043935.html
(userspace process which created the receiving XRC qp on a gi
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 ze
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 mor
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 no
I like Ethan's patch. If sometime in the future an enthusiastic
contributor have the time and willingness to write some assembly for
non-GCC compilers, at least we should give him/her the opportunity to
do it in the simplest way.
Thanks,
george.
On Dec 20, 2007, at 12:50 PM, Jeff Squ
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 wrong
Pasha --
I notice in the port info struct that you have a member for the lid,
but only #if HAVE_XRC. Per a comment in the code, this is supposed to
save bytes when we're using OOB (because we don't need this value in
the OOB CPC).
I think we should remove this #if and always have this st
11 matches
Mail list logo
