Nathan, I test sparcv8+, sparcv9, ia64 and mips in release candidates. That isn't the same as *using* any of those platforms in production. I just mean to say that the implementations are known to pass "make check".
-Paul On Thu, Mar 26, 2015 at 8:48 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > > As a follow-on. How many of our supported architectures should we > continue to support. The current supported list is: > > alpha > amd64* > arm* > ia32* > ia64 > mips > osx* > powerpc* > sparcv9 > sync_builtin* > > * - known to be in-use. > > Additionally, should we continue to support the atomics in opal/asm? > Some of those are known to be wrong and most compilers support in-line > assembly. > > -Nathan > > On Thu, Mar 26, 2015 at 09:22:39AM -0600, Nathan Hjelm wrote: > > > > I am working on cleaning up the atomics in opal and I noticed something > > odd. We define opal_atomic_sub_32 and opal_atomic_sub_64 yet only use > > opal_atomic_sub_32 once: > > > > ./opal/runtime/opal_progress.c: val = > opal_atomic_sub_32(&num_event_users, 1); > > > > This could easily be changed to: > > > > val = opal_atomic_add_32(&num_event_users, -1); > > > > And then we could remove all both opal_atomic_sub_32 and > > opal_atomic_sub_64. Is there a reason to leave these functions in opal? > > > > > > -Nathan > > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/03/17160.php > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/03/17162.php > -- Paul H. Hargrove phhargr...@lbl.gov Computer Languages & Systems Software (CLaSS) Group Computer Science Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
