The old opal_atomic_cmpset_32 worked:
static inline int opal_atomic_cmpset_32( volatile int32_t *addr,
unsigned char ret;
__asm__ __volatile__ (
SMPLOCK "cmpxchgl %1,%2 \n\t"
"sete %0 \n\t"
: "=qm" (ret)
: "q"(newval), "m"(*addr), "a"(oldval)
: "memory");
return (int)ret;
}
The new opal_atomic_cmpset_32 fails:
static inline int opal_atomic_cmpset_32( volatile int32_t *addr,
int32_t oldval, int32_t newval)
{
unsigned char ret;
__asm__ __volatile__ (
SMPLOCK "cmpxchgl %3,%4 \n\t"
"sete %0 \n\t"
: "=qm" (ret), "=a" (oldval), "=m" (*addr)
: "q"(newval), "m"(*addr), "1"(oldval)
return (int)ret;
}
**However** if you put back the "clobber" for memory line (3rd :), it works:
static inline int opal_atomic_cmpset_32( volatile int32_t *addr,
int32_t oldval, int32_t newval)
{
unsigned char ret;
__asm__ __volatile__ (
SMPLOCK "cmpxchgl %3,%4 \n\t"
"sete %0 \n\t"
: "=qm" (ret), "=a" (oldval), "=m" (*addr)
: "q"(newval), "m"(*addr), "1"(oldval)
: "memory");
return (int)ret;
}
This works in a test case for pathcc, gcc, icc, pgcc, SUN studio cc and open64
(pathscale
lineage - which also fails with 1.4.1).
Also the SMPLOCK above is defined as "lock; " - the ";" is a GNU as statement
delimter - is
that right? Seems to work with/without the ";".
Also, a question - I see you generate via perl another "lock" asm file which
you put into
opal/asm/generated/<whatever, e.g. atomic-amd64-linux.s> and stick into libasm
- what you
generate there for whatever usage hasn't changed 1.4->1.4.1->svn trunk?
DM
On Tue, 9 Feb 2010, Jeff Squyres wrote:
Perhaps someone with a pathscale compiler support contract can investigate this
with them.
Have them contact us if they want/need help understanding our atomics; we're
happy to explain, etc. (the atomics are fairly localized to a small part of
OMPI).
On Feb 9, 2010, at 11:42 AM, Mostyn Lewis wrote:
All,
FWIW, Pathscale is dying in the new atomics in 1.4.1 (and svn trunk) - actually
looping -
from gdb:
opal_progress_event_users_decrement () at
../.././opal/include/opal/sys/atomic_impl.h:61
61 } while (0 == opal_atomic_cmpset_32(addr, oldval, oldval - delta));
Current language: auto; currently asm
(gdb) where
#0 opal_progress_event_users_decrement () at
../.././opal/include/opal/sys/atomic_impl.h:61
#1 0x0000000000000001 in ?? ()
#2 0x00002aec4cf6a5e0 in ?? ()
#3 0x00000000000000eb in ?? ()
#4 0x00002aec4cfb57e0 in ompi_mpi_init () at
../.././ompi/runtime/ompi_mpi_init.c:818
#5 0x00007fff5db3bd58 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) list
56 {
57 int32_t oldval;
58
59 do {
60 oldval = *addr;
61 } while (0 == opal_atomic_cmpset_32(addr, oldval, oldval - delta));
62 return (oldval - delta);
63 }
64 #endif /* OPAL_HAVE_ATOMIC_SUB_32 */
65
(gdb)
DM
On Tue, 9 Feb 2010, Jeff Squyres wrote:
FWIW, I have had terrible luck with the patschale compiler over the years.
Repeated attempts to get support from them -- even when I was a paying customer
-- resulted in no help (e.g., a pathCC bug with the OMPI C++ bindings that I
filed years ago was never resolved).
Is this compiler even supported anymore? I.e., is there a support department
somewhere that you have a hope of getting any help from?
I can't say for sure, of course, but if MPI hello world hangs, it smells like a compiler
bug. You might want to attach to "hello world" in a debugger and see where
it's hung. You might need to compile OMPI with debugging symbols to get any meaningful
information.
** NOTE: My personal feelings about the pathscale compiler suite do not reflect
anyone else's feelings in the Open MPI community. Perhaps someone could change
my mind someday, but *I* have personally given up on this compiler. :-(
On Feb 8, 2010, at 2:38 AM, Rafael Arco Arredondo wrote:
Hello,
It does work with version 1.4. This is the hello world that hangs with
1.4.1:
#include <stdio.h>
#include <mpi.h>
int main(int argc, char **argv)
{
int node, size;
MPI_Init(&argc,&argv);
MPI_Comm_rank(MPI_COMM_WORLD, &node);
MPI_Comm_size(MPI_COMM_WORLD, &size);
printf("Hello World from Node %d of %d.\n", node, size);
MPI_Finalize();
return 0;
}
El mar, 26-01-2010 a las 03:57 -0500, Åke Sandgren escribió:
1 - Do you have problems with openmpi 1.4 too? (I don't, haven't built
1.4.1 yet)
2 - There is a bug in the pathscale compiler with -fPIC and -g that
generates incorrect dwarf2 data so debuggers get really confused and
will have BIG problems debugging the code. I'm chasing them to get a
fix...
3 - Do you have an example code that have problems?
--
Rafael Arco Arredondo
Centro de Servicios de Informática y Redes de Comunicaciones
Universidad de Granada
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
