Re: [OMPI devel] Master broken

[Jeff Squyres (jsquyres) via devel]

Fix should now be merged.


> On Jun 4, 2018, at 1:20 PM, Peter Kjellström  wrote:
> 
> On Sun, 3 Jun 2018 08:41:42 -0700
> Thananon Patinyasakdikul  wrote:
> 
>> It is tested against 1.5. it should not work with lower version. I
>> will fix it.
> 
> FWIW, it also builds ok against up to date libfabric (1.6.1).
> 
> /Peter
> 
>> Arm
>> 
>> On Sun, Jun 3, 2018, 7:43 AM r...@open-mpi.org 
>> wrote:
>> 
>>> Here are more problems with a different version of libfabric:
>>> 
>>> *btl_ofi_component.c:* In function ‘*validate_info*’:
>>> *btl_ofi_component.c:64:23:* *error: *‘*FI_MR_VIRT_ADDR*’ undeclared
>>> (first use in this function)
>>>  (mr_mode & ~(*FI_MR_VIRT_ADDR* | FI_MR_ALLOCATED |
>>> FI_MR_PROV_KEY)) == 0)) {
>>>   *^~~*
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel


-- 
Jeff Squyres
jsquy...@cisco.com

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

Re: [OMPI devel] Master broken

[Peter Kjellström]

On Sun, 3 Jun 2018 08:41:42 -0700
Thananon Patinyasakdikul  wrote:

> It is tested against 1.5. it should not work with lower version. I
> will fix it.

FWIW, it also builds ok against up to date libfabric (1.6.1).

/Peter
 
> Arm
> 
> On Sun, Jun 3, 2018, 7:43 AM r...@open-mpi.org 
> wrote:
> 
> > Here are more problems with a different version of libfabric:
> >
> > *btl_ofi_component.c:* In function ‘*validate_info*’:
> > *btl_ofi_component.c:64:23:* *error: *‘*FI_MR_VIRT_ADDR*’ undeclared
> > (first use in this function)
> >   (mr_mode & ~(*FI_MR_VIRT_ADDR* | FI_MR_ALLOCATED |
> > FI_MR_PROV_KEY)) == 0)) {
> >*^~~*
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Master broken

[Thananon Patinyasakdikul]

It is tested against 1.5. it should not work with lower version. I will fix
it.

Arm

On Sun, Jun 3, 2018, 7:43 AM r...@open-mpi.org  wrote:

> Here are more problems with a different version of libfabric:
>
> *btl_ofi_component.c:* In function ‘*validate_info*’:
> *btl_ofi_component.c:64:23:* *error: *‘*FI_MR_VIRT_ADDR*’ undeclared
> (first use in this function)
>   (mr_mode & ~(*FI_MR_VIRT_ADDR* | FI_MR_ALLOCATED |
> FI_MR_PROV_KEY)) == 0)) {
>*^~~*
> *btl_ofi_component.c:64:23:* *note: *each undeclared identifier is
> reported only once for each function it appears in
> *btl_ofi_component.c:64:41:* *error: *‘*FI_MR_ALLOCATED*’ undeclared
> (first use in this function)
>   (mr_mode & ~(FI_MR_VIRT_ADDR | *FI_MR_ALLOCATED* |
> FI_MR_PROV_KEY)) == 0)) {
>  *^~~*
> *btl_ofi_component.c:64:59:* *error: *‘*FI_MR_PROV_KEY*’ undeclared
> (first use in this function)
>   (mr_mode & ~(FI_MR_VIRT_ADDR | FI_MR_ALLOCATED |
> *FI_MR_PROV_KEY*)) == 0)) {
>
> *^~*
> *btl_ofi_component.c:* In function ‘*mca_btl_ofi_init_device*’:
> *btl_ofi_component.c:410:42:* *error: *‘*FI_MR_VIRT_ADDR*’ undeclared
> (first use in this function)
>  ofi_info->domain_attr->mr_mode & *FI_MR_VIRT_ADDR*) {
>   *^~~*
> In file included from *../../../../opal/threads/thread_usage.h:31:0*,
>  from *../../../../opal/class/opal_object.h:126*,
>  from *../../../../opal/util/output.h:70*,
>  from *../../../../opal/include/opal/types.h:43*,
>  from *../../../../opal/mca/btl/btl.h:119*,
>  from *btl_ofi_component.c:27*:
> *btl_ofi_component.c:* In function ‘*mca_btl_ofi_component_progress*’:
> *btl_ofi_component.c:557:63:* *error: *‘*FI_EINTR*’ undeclared (first use
> in this function)
>  } else if (OPAL_UNLIKELY(ret != -FI_EAGAIN && ret != -*F*I_EINTR))
> {
>*^*
>
> *What the heck version was this tested against???*
>
>
> On Jun 3, 2018, at 7:32 AM, r...@open-mpi.org wrote:
>
> On my system, which has libfabric installed (but maybe an older version
> than expected?):
>
> *btl_ofi_component.c:* In function ‘*mca_btl_ofi_component_progress*’:
> *btl_ofi_component.c:557:63:* *error: *‘*FI_EINTR*’ undeclared (first use
> in this function)
>  } else if (OPAL_UNLIKELY(ret != -FI_EAGAIN && ret != -*F*I_EINTR))
> {
>
> Can someone please fix this?
> Ralph
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel
>
>
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel
___
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel

Re: [OMPI devel] Master broken

[r...@open-mpi.org]

Here are more problems with a different version of libfabric:

btl_ofi_component.c: In function ‘validate_info’:
btl_ofi_component.c:64:23: error: ‘FI_MR_VIRT_ADDR’ undeclared (first use in 
this function)
  (mr_mode & ~(FI_MR_VIRT_ADDR | FI_MR_ALLOCATED | FI_MR_PROV_KEY)) == 
0)) {
   ^~~
btl_ofi_component.c:64:23: note: each undeclared identifier is reported only 
once for each function it appears in
btl_ofi_component.c:64:41: error: ‘FI_MR_ALLOCATED’ undeclared (first use in 
this function)
  (mr_mode & ~(FI_MR_VIRT_ADDR | FI_MR_ALLOCATED | FI_MR_PROV_KEY)) == 
0)) {
 ^~~
btl_ofi_component.c:64:59: error: ‘FI_MR_PROV_KEY’ undeclared (first use in 
this function)
  (mr_mode & ~(FI_MR_VIRT_ADDR | FI_MR_ALLOCATED | FI_MR_PROV_KEY)) == 
0)) {
   ^~
btl_ofi_component.c: In function ‘mca_btl_ofi_init_device’:
btl_ofi_component.c:410:42: error: ‘FI_MR_VIRT_ADDR’ undeclared (first use in 
this function)
 ofi_info->domain_attr->mr_mode & FI_MR_VIRT_ADDR) {
  ^~~
In file included from ../../../../opal/threads/thread_usage.h:31:0,
 from ../../../../opal/class/opal_object.h:126,
 from ../../../../opal/util/output.h:70,
 from ../../../../opal/include/opal/types.h:43,
 from ../../../../opal/mca/btl/btl.h:119,
 from btl_ofi_component.c:27:
btl_ofi_component.c: In function ‘mca_btl_ofi_component_progress’:
btl_ofi_component.c:557:63: error: ‘FI_EINTR’ undeclared (first use in this 
function)
 } else if (OPAL_UNLIKELY(ret != -FI_EAGAIN && ret != -FI_EINTR)) {
   ^

What the heck version was this tested against???


> On Jun 3, 2018, at 7:32 AM, r...@open-mpi.org wrote:
> 
> On my system, which has libfabric installed (but maybe an older version than 
> expected?):
> 
> btl_ofi_component.c: In function ‘mca_btl_ofi_component_progress’:
> btl_ofi_component.c:557:63: error: ‘FI_EINTR’ undeclared (first use in this 
> function)
>  } else if (OPAL_UNLIKELY(ret != -FI_EAGAIN && ret != -FI_EINTR)) {
> 
> Can someone please fix this?
> Ralph
> 
> ___
> devel mailing list
> devel@lists.open-mpi.org
> https://lists.open-mpi.org/mailman/listinfo/devel

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

Re: [OMPI devel] master broken on (at least) OpenBSD-6

[Gilles Gouaillardet]

Thanks Paul,


i fixed that (and 4 more errors that popped up) in the attached patch


i opened https://github.com/open-mpi/ompi/pull/2110, but will likely 
merge the first 3 commits quite soon.


/* the last two commits fix autogen.pl on OpenBSD 6.0 and need a review */

so you'd better use the attached patch for now.


/* you need to run autogen.pl, if you do not have recent autotools on 
your OpenBSD 6.0 box, you can


apply the patch on an other platform, ./autogen.pl && ./configure && 
make dist, and copy the generated tarball to


OpenBSD */


Cheers,


Gilles



On 9/23/2016 3:33 AM, Paul Hargrove wrote:
When trying to test PR2107 on OpenBSD-6 I was blocked by the following 
error, which is also present in 'master'.


../../../ompi/opal/util/if.c: In function 'opal_ifisloopback':
../../../ompi/opal/util/if.c:710: error: 'IFF_LOOPBACK' undeclared 
(first use in this function)
../../../ompi/opal/util/if.c:710: error: (Each undeclared identifier 
is reported only once

../../../ompi/opal/util/if.c:710: error: for each function it appears in.)
../../../ompi/opal/util/if.c: In function 'opal_ifgetaliases':
../../../ompi/opal/util/if.c:791: error: 'IFF_LOOPBACK' undeclared 
(first use in this function)


The constant IFF_LOOPBACK is defined in net/if.h, as expected.
However, opal_config.h says:

/* #undef HAVE_NET_IF_H */


Related to that is the following output from configure:

checking net/if.h usability... no
checking net/if.h presence... yes
configure: WARNING: net/if.h: present but cannot be compiled
configure: WARNING: net/if.h: check for missing prerequisite
headers?
configure: WARNING: net/if.h: see the Autoconf documentation
configure: WARNING: net/if.h: section "Present But Cannot Be
Compiled"
configure: WARNING: net/if.h: proceeding with the compiler's result
configure: WARNING: ##
-- ##
configure: WARNING: ## Report this to
http://www.open-mpi.org/community/help/ ##
configure: WARNING: ##
-- ##
checking for net/if.h... no


Details from config.log:

configure:62402: checking net/if.h usability
configure:62402: gcc -std=gnu99 -c -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing  conftest.c >&5
In file included from conftest.c:433:
/usr/include/net/if.h:358: error: field 'ifru_addr' has incomplete
type
/usr/include/net/if.h:359: error: field 'ifru_dstaddr' has
incomplete type
/usr/include/net/if.h:360: error: field 'ifru_broadaddr' has
incomplete type
/usr/include/net/if.h:387: error: field 'ifrau_addr' has
incomplete type
/usr/include/net/if.h:393: error: field 'ifra_dstaddr' has
incomplete type
/usr/include/net/if.h:395: error: field 'ifra_mask' has incomplete
type
/usr/include/net/if.h:438: error: field 'addr' has incomplete type
/usr/include/net/if.h:439: error: field 'dstaddr' has incomplete type
/usr/include/net/if.h:445: error: expected
specifier-qualifier-list before 'sa_family_t'
In file included from /usr/include/net/if.h:454,
 from conftest.c:433:
/usr/include/net/if_arp.h:79: error: field 'arp_pa' has incomplete
type
/usr/include/net/if_arp.h:80: error: field 'arp_ha' has incomplete
type


Man page for if_nametoindex() and friends show:

 #include 
 #include 
 #include 


It looks like configure.ac  is *trying* to deal 
with the sys/socket.h dependency:


# Needed to work around Darwin requiring sys/socket.h for
# net/if.h
AC_CHECK_HEADERS([net/if.h], [], [],
[#include 
#if STDC_HEADERS
# include 
# include 
#else
# if HAVE_STDLIB_H
#  include 
# endif
#endif
#if HAVE_SYS_SOCKET_H
# include 
#endif
])


However, config.log suggests that the previous failure has been 
cached, making this (second) test for net/if.h a no-op:


configure:62453: checking for net/if.h
configure:62453: result: no



-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


diff --git a/config/ompi_fortran_check.m4 b/config/ompi_fortran_check.m4
index 46ecf24..51d1e03 100644
--- a/config/ompi_fortran_check.m4
+++ b/config/ompi_fortran_check.m4
@@ -11,7 +11,7 @@ dnl University of Stuttgart.  All 
rights reserved.
 dnl Copyright (c) 2004-2005 The Regents of the University of California.
 dnl All rights reserved.
 dnl Copyright (c) 2011-2012 Cisco Systems, Inc.  All rights reserved.
-dnl Copyright (c) 2015  

Re: [OMPI devel] Master broken for ILP32

[Hjelm, Nathan Thomas]

We have chosen to use the __sync builtins by default on master. There was an 
rfc on it awhile ago. Is there a good reason to go back to the inline by 
default or is this just surprising?



From: devel on behalf of Paul Hargrove
Sent: Monday, May 09, 2016 11:12:16 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] Master broken for ILP32

Regarding "distro":
This was happening, for instance, on OpenBSD and NetBSD (32-bit kernels on 
64-bit h/w) when testing your PR1643.
However, it sounds like Nathan knows how/where to fix this.

HOWEVER, that is not the only issue here.
Why is master is picking the BUILTIN (__sync) atomics (as shown in the 
configure output quoted below), while v2.x (same system and same config args) 
uses a .s file:
*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte compare-and-exchange... no
checking if gcc -std=gnu99 supports GCC inline assembly... yes
checking if gcc -std=gnu99 supports DEC inline assembly... no
checking if gcc -std=gnu99 supports XLC inline assembly... no
checking for assembly format... default-.text-.globl-:--.L-@-1-0-1-1-0
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_NO
checking for perl... perl
checking for pre-built assembly file... yes (atomic-ia32-linux-nongas.s)
checking for atomic assembly filename... atomic-ia32-linux-nongas.s


-Paul

On Mon, May 9, 2016 at 1:22 AM, Gilles Gouaillardet 
<gil...@rist.or.jp<mailto:gil...@rist.or.jp>> wrote:

Paul,


on which distro are you running ?

are you compiling on a 64 bit distro to generate a 32 bit library ?


it seems we are currently only testing a atomic on a long (32 bits on a 32 bits 
arch) and

then incorrectly assume it works also on 64 bits (!)


Cheers,


Gilles

On 5/9/2016 3:59 PM, Paul Hargrove wrote:
Perhaps this is already known.
Several builds I've tried recently from the ompi (not ompi-release) repo are 
failing on 32-bit platforms with
   ../../../opal/.libs/libopen-pal.so: undefined reference to 
`__sync_add_and_fetch_8'

This is impacting PRs that I am being asked to test (e.g. 1643).

Note that I did *not* configure with --enable-builtin-atomics, yet configure 
seems to show them being selected anyway:
*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking for __sync builtin atomics... yes
checking for processor support of __sync builtin atomic compare-and-swap on 
128-bit values... no
checking for __sync builtin atomic compare-and-swap on 128-bit values with 
-mcx16 flag... no
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte compare-and-exchange... no
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_SYNC
checking for atomic assembly filename... none

-Paul

--
Paul H. Hargrove  <mailto:phhargr...@lbl.gov> 
phhargr...@lbl.gov<mailto:phhargr...@lbl.gov>
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: 
+1-510-495-2352<tel:%2B1-510-495-2352>
Lawrence Berkeley National Laboratory Fax: 
+1-510-486-6900<tel:%2B1-510-486-6900>



___
devel mailing list
de...@open-mpi.org<mailto:de...@open-mpi.org>
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2016/05/18941.php


___
devel mailing list
de...@open-mpi.org<mailto:de...@open-mpi.org>
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/

Re: [OMPI devel] Master broken for ILP32

[Paul Hargrove]

Regarding "distro":
This was happening, for instance, on OpenBSD and NetBSD (32-bit kernels on
64-bit h/w) when testing your PR1643.
However, it sounds like Nathan knows how/where to fix this.

HOWEVER, that is not the only issue here.
Why is master is picking the BUILTIN (__sync) atomics (as shown in the
configure output quoted below), while v2.x (same system and same config
args) uses a .s file:

*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte compare-and-exchange... no
checking if gcc -std=gnu99 supports GCC inline assembly... yes
checking if gcc -std=gnu99 supports DEC inline assembly... no
checking if gcc -std=gnu99 supports XLC inline assembly... no
checking for assembly format... default-.text-.globl-:--.L-@-1-0-1-1-0
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_NO
checking for perl... perl
checking for pre-built assembly file... yes (atomic-ia32-linux-nongas.s)
checking for atomic assembly filename... atomic-ia32-linux-nongas.s



-Paul

On Mon, May 9, 2016 at 1:22 AM, Gilles Gouaillardet 
wrote:

> Paul,
>
>
> on which distro are you running ?
>
> are you compiling on a 64 bit distro to generate a 32 bit library ?
>
>
> it seems we are currently only testing a atomic on a long (32 bits on a 32
> bits arch) and
>
> then incorrectly assume it works also on 64 bits (!)
>
>
> Cheers,
>
>
> Gilles
>
> On 5/9/2016 3:59 PM, Paul Hargrove wrote:
>
> Perhaps this is already known.
> Several builds I've tried recently from the ompi (not ompi-release) repo
> are failing on 32-bit platforms with
>../../../opal/.libs/libopen-pal.so: undefined reference to
> `__sync_add_and_fetch_8'
>
> This is impacting PRs that I am being asked to test (e.g. 1643).
>
> Note that I did *not* configure with --enable-builtin-atomics, yet
> configure seems to show them being selected anyway:
>
> *** Assembler
> checking dependency style of gcc -std=gnu99... gcc3
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking for fgrep... /usr/bin/grep -F
> checking for __sync builtin atomics... yes
> checking for processor support of __sync builtin atomic compare-and-swap
> on 128-bit values... no
> checking for __sync builtin atomic compare-and-swap on 128-bit values with
> -mcx16 flag... no
> checking if .proc/endp is needed... no
> checking directive for setting text section... .text
> checking directive for exporting symbols... .globl
> checking for objdump... objdump
> checking if .note.GNU-stack is needed... no
> checking suffix for labels... :
> checking prefix for global symbol labels...
> checking prefix for lsym labels... .L
> checking prefix for function in .type... @
> checking if .size is needed... yes
> checking if .align directive takes logarithmic value... no
> checking if processor supports x86_64 16-byte compare-and-exchange... no
> checking for assembly architecture... IA32
> checking for builtin atomics... BUILTIN_SYNC
> checking for atomic assembly filename... none
>
> -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 listde...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2016/05/18941.php
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2016/05/18942.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

Re: [OMPI devel] Master broken for ILP32

[Hjelm, Nathan Thomas]

Nevermind. Looks like there are two different macros for 64-bit and one is 
wrong in this case. Fix incoming.



From: devel on behalf of Gilles Gouaillardet
Sent: Monday, May 09, 2016 2:22:24 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] Master broken for ILP32

Paul,


on which distro are you running ?

are you compiling on a 64 bit distro to generate a 32 bit library ?


it seems we are currently only testing a atomic on a long (32 bits on a 32 bits 
arch) and

then incorrectly assume it works also on 64 bits (!)


Cheers,


Gilles

On 5/9/2016 3:59 PM, Paul Hargrove wrote:
Perhaps this is already known.
Several builds I've tried recently from the ompi (not ompi-release) repo are 
failing on 32-bit platforms with
   ../../../opal/.libs/libopen-pal.so: undefined reference to 
`__sync_add_and_fetch_8'

This is impacting PRs that I am being asked to test (e.g. 1643).

Note that I did *not* configure with --enable-builtin-atomics, yet configure 
seems to show them being selected anyway:
*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking for __sync builtin atomics... yes
checking for processor support of __sync builtin atomic compare-and-swap on 
128-bit values... no
checking for __sync builtin atomic compare-and-swap on 128-bit values with 
-mcx16 flag... no
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte compare-and-exchange... no
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_SYNC
checking for atomic assembly filename... none

-Paul

--
Paul H. Hargrove  <mailto:phhargr...@lbl.gov> 
phhargr...@lbl.gov<mailto: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
de...@open-mpi.org<mailto:de...@open-mpi.org>
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2016/05/18941.php

Re: [OMPI devel] Master broken for ILP32

[Hjelm, Nathan Thomas]

This really isnt a problem with the atomics code. We have a macro to indicate 
whether 64-bit is really supported. Something in opal is using 64-bit atomics 
without checking if they are supported. With sync atomics we get a link error 
but with the others it is a compile error. I fixed a similar problem in vader 
but it looks like there are more places that need to be fixed.



From: devel on behalf of Gilles Gouaillardet
Sent: Monday, May 09, 2016 2:22:24 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] Master broken for ILP32

Paul,


on which distro are you running ?

are you compiling on a 64 bit distro to generate a 32 bit library ?


it seems we are currently only testing a atomic on a long (32 bits on a 32 bits 
arch) and

then incorrectly assume it works also on 64 bits (!)


Cheers,


Gilles

On 5/9/2016 3:59 PM, Paul Hargrove wrote:
Perhaps this is already known.
Several builds I've tried recently from the ompi (not ompi-release) repo are 
failing on 32-bit platforms with
   ../../../opal/.libs/libopen-pal.so: undefined reference to 
`__sync_add_and_fetch_8'

This is impacting PRs that I am being asked to test (e.g. 1643).

Note that I did *not* configure with --enable-builtin-atomics, yet configure 
seems to show them being selected anyway:
*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking for __sync builtin atomics... yes
checking for processor support of __sync builtin atomic compare-and-swap on 
128-bit values... no
checking for __sync builtin atomic compare-and-swap on 128-bit values with 
-mcx16 flag... no
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte compare-and-exchange... no
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_SYNC
checking for atomic assembly filename... none

-Paul

--
Paul H. Hargrove  <mailto:phhargr...@lbl.gov> 
phhargr...@lbl.gov<mailto: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
de...@open-mpi.org<mailto:de...@open-mpi.org>
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2016/05/18941.php

Re: [OMPI devel] Master broken for ILP32

[Gilles Gouaillardet]

Paul,


on which distro are you running ?

are you compiling on a 64 bit distro to generate a 32 bit library ?


it seems we are currently only testing a atomic on a long (32 bits on a 
32 bits arch) and


then incorrectly assume it works also on 64 bits (!)


Cheers,


Gilles


On 5/9/2016 3:59 PM, Paul Hargrove wrote:

Perhaps this is already known.
Several builds I've tried recently from the ompi (not ompi-release) 
repo are failing on 32-bit platforms with
 ../../../opal/.libs/libopen-pal.so: undefined reference to 
`__sync_add_and_fetch_8'


This is impacting PRs that I am being asked to test (e.g. 1643).

Note that I did *not* configure with --enable-builtin-atomics, yet 
configure seems to show them being selected anyway:


*** Assembler
checking dependency style of gcc -std=gnu99... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking for __sync builtin atomics... yes
checking for processor support of __sync builtin atomic
compare-and-swap on 128-bit values... no
checking for __sync builtin atomic compare-and-swap on 128-bit
values with -mcx16 flag... no
checking if .proc/endp is needed... no
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if processor supports x86_64 16-byte
compare-and-exchange... no
checking for assembly architecture... IA32
checking for builtin atomics... BUILTIN_SYNC
checking for atomic assembly filename... none

-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
de...@open-mpi.org
Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2016/05/18941.php