[OMPI devel] [2.0.1rc1] ppc64 atomics (still) broken w/ xlc-12.1

2016-08-27 Thread Paul Hargrove 
I didn't get to test 2.0.1rc1 with xlc-12.1 until just now because I need a
CRYPTOCard for access (== not fully automated like my other tests).

It appears that the problem I reported in 2.0.0rc2 and thought to be as
fixed by pr1140  was
never /fully/ fixed.
The commit in that PR includes only ONE of the TWO patch hunks in my
original email (URL in the PR's initial comment).
So, opal_atomic_ll_32() was fixed but opal_atomic_ll_64() was not.

The same half-fixed state exists on master as well, but is masked by the
default use of "__sync builtin atomics".

-Paul


-- 
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
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] [2.0.1rc1] type warnings from clang

2016-08-27 Thread Paul Hargrove 
Building w/ clang-3.4.2 on Linux/x86-64:

/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang/openmpi-2.0.1rc1/opal/mca/btl/openib/btl_openib_component.c:2158:21:
warning: implicit conversion from enumeration type
'btl_openib_receive_queues_source_t' to different enumeration type
'mca_base_var_source_t' [-Wenum-conversion]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang/openmpi-2.0.1rc1/opal/mca/pmix/pmix112/pmix1_client.c:408:19:
warning: implicit conversion from enumeration type 'opal_pmix_scope_t' to
different enumeration type 'pmix_scope_t' [-Wenum-conversion]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/adio/common/utils.c:97:3:
warning: passing 'const MPI_Aint *' (aka 'const long *') to parameter of
type 'MPI_Aint *' (aka 'long *') discards qualifiers
[-Wincompatible-pointer-types-discards-qualifiers]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang/openmpi-2.0.1rc1/oshmem/mca/spml/yoda/spml_yoda.c:644:33:
warning: incompatible pointer types passing 'oshmem_proc_t **' (aka 'struct
oshmem_proc_t **') to parameter of type 'struct ompi_proc_t **'
[-Wincompatible-pointer-types]

Adding -m32 yields the following which all seem to show ROMIO's ADIO_Offset
being 64-bits wide, while MPI_Offset and MPI_Count are only 32-bits wide:

/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/get_bytoff.c:66:44:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/get_posn.c:55:33:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/get_posn_sh.c:56:36:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/seek.c:76:30:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/seek.c:97:32:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/seek_sh.c:104:37:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/mpi-io/seek_sh.c:133:36:
warning: incompatible pointer types passing 'MPI_Offset *' (aka 'long *')
to parameter of type 'ADIO_Offset *' (aka 'long long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/adio/common/ad_coll_exch_new.c:160:35:
warning: incompatible pointer types passing 'ADIO_Offset *' (aka 'long long
*') to parameter of type 'MPI_Count *' (aka 'long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/adio/common/ad_read_coll.c:857:5:
warning: incompatible pointer types passing 'ADIO_Offset *' (aka 'long long
*') to parameter of type 'const MPI_Count *' (aka 'const long *')
[-Wincompatible-pointer-types]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/io/romio314/romio/adio/common/ad_write_coll.c:615:8:
warning: incompatible pointer types passing 'ADIO_Offset *' (aka 'long long
*') to parameter of type 'const MPI_Count *' (aka 'const long *')
[-Wincompatible-pointer-types]



Use of -m32 also generates the printf format warnings (after removing the
ones for types of equal size but different signedness):

/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/fcoll/two_phase/fcoll_two_phase_support_fns.c:175:36:
warning: format specifies type 'long long' but the argument has type 'long'
[-Wformat]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1/ompi/mca/fcoll/two_phase/fcoll_two_phase_support_fns.c:175:44:
warning: format specifies type 'long long' but the argument has type 'long'
[-Wformat]
/scratch/phargrov/OMPI/openmpi-2.0.1rc1-linux-x86_64-clang-m32/openmpi-2.0.1rc1

[OMPI devel] [2.0-latest] unreachable code

2016-08-27 Thread Paul Hargrove 
Oracle Studio 12.5 C compiler on a recent v2.0 nightly tarball points out
the following unreachable code:

"/shared/OMPI/openmpi-2.0-latest-solaris11-x86-ib-ss12u5/openmpi-v2.0.0-227-g917d293/opal/mca/base/mca_base_component_repository.c",
line 265: warning: statement not reached
"/shared/OMPI/openmpi-2.0-latest-solaris11-x86-ib-ss12u5/openmpi-v2.0.0-227-g917d293/opal/mca/btl/openib/btl_openib.c",
line 498: warning: statement not reached
"/shared/OMPI/openmpi-2.0-latest-solaris11-x86-ib-ss12u5/openmpi-v2.0.0-227-g917d293/opal/mca/btl/openib/connect/btl_openib_connect_udcm.c",
line 2735: warning: statement not reached
"/shared/OMPI/openmpi-2.0-latest-solaris11-x86-ib-ss12u5/openmpi-v2.0.0-227-g917d293/ompi/mca/io/romio314/romio/adio/common/ad_fstype.c",
line 306: warning: statement not reached
"/shared/OMPI/openmpi-2.0-latest-solaris11-x86-ib-ss12u5/openmpi-v2.0.0-227-g917d293/ompi/mca/io/romio314/romio/adio/common/ad_threaded_io.c",
line 31: warning: statement not reached

I will ignore the ROMIO ones, leaving 3 to diagnose.

1) opal/mca/base/mca_base_component_repository.c, line 265:
   260  *framework_components = NULL;
   261  #if OPAL_HAVE_DL_SUPPORT
   262  return opal_hash_table_get_value_ptr
(&mca_base_component_repository, framework->framework_name,
   263strlen
(framework->framework_name), (void **) framework_components);
   264  #endif
 > 265  return OPAL_ERR_NOT_FOUND;
   266  }
   267
   268  #if OPAL_HAVE_DL_SUPPORT
   269  static void mca_base_component_repository_release_internal
(mca_base_component_repository_item_t *ri) {
   270  int group_id;

The unreachable warning easily fixed with an '#else' clause as follows:

--- opal/mca/base/mca_base_component_repository.c~  Sat Aug 27 02:03:23
2016
+++ opal/mca/base/mca_base_component_repository.c   Sat Aug 27 02:03:41
2016
@@ -261,8 +261,9 @@
 #if OPAL_HAVE_DL_SUPPORT
 return opal_hash_table_get_value_ptr (&mca_base_component_repository,
framework->framework_name,
   strlen
(framework->framework_name), (void **) framework_components);
-#endif
+#else
 return OPAL_ERR_NOT_FOUND;
+#endif
 }

 #if OPAL_HAVE_DL_SUPPORT



2) opal/mca/btl/openib/btl_openib.c line 498 is also due to a return right
after an #endif, and can also be fixed with an #else.

   493  case IBV_LINK_LAYER_UNSPECIFIED:
   494  default:
   495  return MCA_BTL_OPENIB_TRANSPORT_UNKNOWN;
   496  }
   497  #endif
 > 498  return MCA_BTL_OPENIB_TRANSPORT_IB;
   499
   500  case IBV_TRANSPORT_IWARP:
   501  return MCA_BTL_OPENIB_TRANSPORT_IWARP;
   502
   503  case IBV_TRANSPORT_UNKNOWN:

3) opal/mca/btl/openib/connect/btl_openib_connect_udcm.c line 2735 looks
like debugging code (the "while(1)" on line 2734) that maybe was not
intended to be committed:

  2730  IBV_QP_PORT | IBV_QP_ACCESS_FLAGS);
  2731  if (ret) {
  2732  BTL_ERROR(("Error modifying XRC recv QP[%x] to
IBV_QPS_INIT, errno says: %s [%d]",
  2733 lcl_ep->xrc_recv_qp_num, strerror(ret), ret));
  2734  while(1);
> 2735  return OPAL_ERROR;
  2736  }
  2737  #endif
  2738
  2739  memset(&attr, 0, sizeof(struct ibv_qp_attr));
  2740  attr.qp_state   = IBV_QPS_RTR;


-Paul


-- 
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
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

[OMPI devel] C89 support

2016-08-27 Thread C Bergström 
I realize a number of changes have been made to make the codebase C99.
As I'm setting up more testing platforms, I found that this caused
Clang (and us) to be broken on SLES10. While I realize that platform
is quite *old*, it is still used in production at more than one sight
which we support. If there isn't a strong feeling against it, would
you guys accept a patch to get this building again..

Thanks
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread Jeff Squyres (jsquyres) 
On Aug 27, 2016, at 8:38 AM, C Bergström  wrote:
> 
> I realize a number of changes have been made to make the codebase C99.
> As I'm setting up more testing platforms, I found that this caused
> Clang (and us) to be broken on SLES10. While I realize that platform
> is quite *old*, it is still used in production at more than one sight
> which we support. If there isn't a strong feeling against it, would
> you guys accept a patch to get this building again..

Would that mean backing out all of our C99 support?  If so, I am doubtful that 
we would accept such a patch for our development master / v2.x branches.

Can you use an older version of Open MPI?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread Nathan Hjelm 
Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10 
dates back to 2004 I find this surprising. Clangs goal from the beginning was 
full C99 support. Checking back it looks like llvm 1.0 (2003) had C99 support. 
What version of clang/llvm are you using?

-Nathan

> On Aug 27, 2016, at 6:38 AM, C Bergström  wrote:
> 
> I realize a number of changes have been made to make the codebase C99.
> As I'm setting up more testing platforms, I found that this caused
> Clang (and us) to be broken on SLES10. While I realize that platform
> is quite *old*, it is still used in production at more than one sight
> which we support. If there isn't a strong feeling against it, would
> you guys accept a patch to get this building again..
> 
> Thanks
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread Gilles Gouaillardet 
out of curiosity, does Open MPI fails in configure (because it does not
detect a valid C99 compiler) ?
or does it fail in make (because some C99 syntax is not supported, and that
was not detected at configure time) ?

Cheers,

Gilles

On Saturday, August 27, 2016, C Bergström  wrote:

> I realize a number of changes have been made to make the codebase C99.
> As I'm setting up more testing platforms, I found that this caused
> Clang (and us) to be broken on SLES10. While I realize that platform
> is quite *old*, it is still used in production at more than one sight
> which we support. If there isn't a strong feeling against it, would
> you guys accept a patch to get this building again..
>
> Thanks
> ___
> devel mailing list
> devel@lists.open-mpi.org 
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread cbergstrom 
It's well documented that the version of glibc that goes with SLES10 is not 
c99. As well as that gcc's claimed c99 is not in fact conformant. Newer glibc 
fixed this but SLES10 is stuck. I can provide exact documentation links if 
necessary. 

Clang and any real c99 compiler fails at link time.

This effects all versions of clang or us up to svn trunk.

The patch is simple and non-performance impacting.

  Original Message  
From: Nathan Hjelm
Sent: Saturday, August 27, 2016 20:23
To: Open MPI Developers
Reply To: Open MPI Developers
Subject: Re: [OMPI devel] C89 support

Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10 
dates back to 2004 I find this surprising. Clangs goal from the beginning was 
full C99 support. Checking back it looks like llvm 1.0 (2003) had C99 support. 
What version of clang/llvm are you using?

-Nathan

> On Aug 27, 2016, at 6:38 AM, C Bergström  wrote:
> 
> I realize a number of changes have been made to make the codebase C99.
> As I'm setting up more testing platforms, I found that this caused
> Clang (and us) to be broken on SLES10. While I realize that platform
> is quite *old*, it is still used in production at more than one sight
> which we support. If there isn't a strong feeling against it, would
> you guys accept a patch to get this building again..
> 
> Thanks
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread Jeff Squyres (jsquyres) 
Can we see the patch?

> On Aug 27, 2016, at 9:41 AM, cbergst...@pathscale.com wrote:
> 
> It's well documented that the version of glibc that goes with SLES10 is not 
> c99. As well as that gcc's claimed c99 is not in fact conformant. Newer glibc 
> fixed this but SLES10 is stuck. I can provide exact documentation links if 
> necessary. 
> 
> Clang and any real c99 compiler fails at link time.
> 
> This effects all versions of clang or us up to svn trunk.
> 
> The patch is simple and non-performance impacting.
> 
>   Original Message  
> From: Nathan Hjelm
> Sent: Saturday, August 27, 2016 20:23
> To: Open MPI Developers
> Reply To: Open MPI Developers
> Subject: Re: [OMPI devel] C89 support
> 
> Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10 
> dates back to 2004 I find this surprising. Clangs goal from the beginning was 
> full C99 support. Checking back it looks like llvm 1.0 (2003) had C99 
> support. What version of clang/llvm are you using?
> 
> -Nathan
> 
>> On Aug 27, 2016, at 6:38 AM, C Bergström  wrote:
>> 
>> I realize a number of changes have been made to make the codebase C99.
>> As I'm setting up more testing platforms, I found that this caused
>> Clang (and us) to be broken on SLES10. While I realize that platform
>> is quite *old*, it is still used in production at more than one sight
>> which we support. If there isn't a strong feeling against it, would
>> you guys accept a patch to get this building again..
>> 
>> Thanks
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] C89 support

2016-08-27 Thread Nathan Hjelm 
We do not depend on any C99 specific behavior out of libc that I know of. We 
depend on the types (stdint.h) and syntax (sub-object naming, variadic macros, 
etc). A little surprised there are any linking failures with Open MPI even with 
an ancient glibc.

If the patch is simple please send it to us and we will take a look. If it 
doesn’t disrupt anything we will consider it.

-Nathan

> On Aug 27, 2016, at 7:41 AM, cbergst...@pathscale.com wrote:
> 
> It's well documented that the version of glibc that goes with SLES10 is not 
> c99. As well as that gcc's claimed c99 is not in fact conformant. Newer glibc 
> fixed this but SLES10 is stuck. I can provide exact documentation links if 
> necessary. 
> 
> Clang and any real c99 compiler fails at link time.
> 
> This effects all versions of clang or us up to svn trunk.
> 
> The patch is simple and non-performance impacting.
> 
>   Original Message  
> From: Nathan Hjelm
> Sent: Saturday, August 27, 2016 20:23
> To: Open MPI Developers
> Reply To: Open MPI Developers
> Subject: Re: [OMPI devel] C89 support
> 
> Considering gcc more or less had full C99 support in 3.1 (2002) and SLES10 
> dates back to 2004 I find this surprising. Clangs goal from the beginning was 
> full C99 support. Checking back it looks like llvm 1.0 (2003) had C99 
> support. What version of clang/llvm are you using?
> 
> -Nathan
> 
>> On Aug 27, 2016, at 6:38 AM, C Bergström  wrote:
>> 
>> I realize a number of changes have been made to make the codebase C99.
>> As I'm setting up more testing platforms, I found that this caused
>> Clang (and us) to be broken on SLES10. While I realize that platform
>> is quite *old*, it is still used in production at more than one sight
>> which we support. If there isn't a strong feeling against it, would
>> you guys accept a patch to get this building again..
>> 
>> Thanks
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] [2.0.1rc1] ppc64 atomics (still) broken w/ xlc-12.1

2016-08-27 Thread George Bosilca 
Paul,

Sorry for the half-fix. I'll submit a patch and PRs to the releases asap.

  George.


On Sat, Aug 27, 2016 at 4:14 AM, Paul Hargrove  wrote:

> I didn't get to test 2.0.1rc1 with xlc-12.1 until just now because I need
> a CRYPTOCard for access (== not fully automated like my other tests).
>
> It appears that the problem I reported in 2.0.0rc2 and thought to be as
> fixed by pr1140  was
> never /fully/ fixed.
> The commit in that PR includes only ONE of the TWO patch hunks in my
> original email (URL in the PR's initial comment).
> So, opal_atomic_ll_32() was fixed but opal_atomic_ll_64() was not.
>
> The same half-fixed state exists on master as well, but is masked by the
> default use of "__sync builtin atomics".
>
> -Paul
>
>
> --
> 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
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel

Re: [OMPI devel] [2.0.1rc1] ppc64 atomics (still) broken w/ xlc-12.1

2016-08-27 Thread George Bosilca 
v2.x: https://github.com/open-mpi/ompi-release/pull/1344
master: https://github.com/open-mpi/ompi/commit/a6d515b

Thanks,
  George.


On Sat, Aug 27, 2016 at 12:45 PM, George Bosilca 
wrote:

> Paul,
>
> Sorry for the half-fix. I'll submit a patch and PRs to the releases asap.
>
>   George.
>
>
> On Sat, Aug 27, 2016 at 4:14 AM, Paul Hargrove  wrote:
>
>> I didn't get to test 2.0.1rc1 with xlc-12.1 until just now because I need
>> a CRYPTOCard for access (== not fully automated like my other tests).
>>
>> It appears that the problem I reported in 2.0.0rc2 and thought to be as
>> fixed by pr1140  was
>> never /fully/ fixed.
>> The commit in that PR includes only ONE of the TWO patch hunks in my
>> original email (URL in the PR's initial comment).
>> So, opal_atomic_ll_32() was fixed but opal_atomic_ll_64() was not.
>>
>> The same half-fixed state exists on master as well, but is masked by the
>> default use of "__sync builtin atomics".
>>
>> -Paul
>>
>>
>> --
>> 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
>>
>> ___
>> devel mailing list
>> devel@lists.open-mpi.org
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel