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
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
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
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
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
