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.
The PGI compile picked up on this because it's the only compiler on my
platform (EM64T) that falls back to the amd64/atomic.h implementation
(which doesn't have inline assembly for these functions) -- all the
other compilers use ia32/atomic.h (which *does* have inline assembly
for these functions).
On Dec 20, 2007, at 3:33 PM, George Bosilca wrote:
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 Squyres wrote:
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
<arch>/atomic.h file defines a non-GCC-style inline atomic,
that file would have to set an OPAL_HAVE_INLINE_* macro, but
I don't see any cases like this currently (there is only
XLC-style inline assembly in powerpc/atomic.h).
Index: opal/include/opal/sys/atomic.h
===================================================================
--- opal/include/opal/sys/atomic.h (revision 17003)
+++ opal/include/opal/sys/atomic.h (working copy)
@@ -111,19 +111,27 @@
/
**********************************************************************
*
- * Zero these macros in the architecture-specific atomic.h files if
we
- * need to define their corresponding functions as non-inline
(e.g.,
- * in an opal/asm/base/<arch>.asm file). These macros allow us to
make
- * the signatures of the prototype and definition identical.
- *
+ * Set or unset these macros in the architecture-specific atomic.h
+ * files if we need to specify them as inline or non-inline
+ *
*********************************************************************/
+#if !OMPI_GCC_INLINE_ASSEMBLY
+#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 0
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 0
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 0
+#define OPAL_HAVE_INLINE_ATOMIC_ADD_64 0
+#define OPAL_HAVE_INLINE_ATOMIC_SUB_64 0
+#else
#define OPAL_HAVE_INLINE_ATOMIC_MEM_BARRIER 1
#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_32 1
-#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1
#define OPAL_HAVE_INLINE_ATOMIC_ADD_32 1
#define OPAL_HAVE_INLINE_ATOMIC_SUB_32 1
+#define OPAL_HAVE_INLINE_ATOMIC_CMPSET_64 1
#define OPAL_HAVE_INLINE_ATOMIC_ADD_64 1
#define OPAL_HAVE_INLINE_ATOMIC_SUB_64 1
+#endif
/
**********************************************************************
*
--
Jeff Squyres
Cisco Systems
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
Cisco Systems
