Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Wed, Jul 30, 2014 at 6:20 PM, Paul Hargrove wrote: > > On Wed, Jul 30, 2014 at 6:15 PM, wrote: > [...] > >> Strange thing is that openmpi-1.8 with PGI14.7 works fine. >> What's the difference with openmpi-1.8 and openmpi-1.8.2rc2? >> > [...] >

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

On Wed, Jul 30, 2014 at 8:53 PM, Paul Hargrove wrote: [...] > I have a clear answer to *what* is different (below) and am next looking > into the why/how now. > It seems that 1.8.1 has included all dependencies into libmpi_usempif08 > while 1.8.2rc2 does not. > [...] The

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Hi Paul, Thank you for your investigation. I'm sure it's very close to fix the problem although I myself can't do that. So I must owe you something... Please try Awamori, which is Okinawa's sake and very good in such a hot day. Tetsuya > On Wed, Jul 30, 2014 at 8:53 PM, Paul Hargrove

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Paul and all, For what it's worth, with openmpi 1.8.2rc2 and the intel fortran compiler version 14.0.3.174 : $ nm libmpi_usempif08.so| grep -i sizeof there is no such undefined symbol (mpi_f08_sizeof_) as a temporary workaround, did you try to force the linker use

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Paul, in .../ompi/mpi/fortran/use-mpi-f08, can you create the following dumb test program, compile and run nm | grep f08 on the object : $ cat foo.f90 program foo use mpi_f08_sizeof implicit none real :: x integer :: size, ierror call MPI_Sizeof_real_s_4(x, size, ierror) stop end program

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Gilles, Just as you speculate, PGI is creating a _-suffixed reference to the module name: $ pgf90 -c test.f90 $ nm -u test.o | grep f08 U mpi_f08_sizeof_ U mpi_f08_sizeof_mpi_sizeof_real_s_4_ You suggested the following work-around in a previous email: $

Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

Doesn't namespacing obviate the need for this convoluted identifier scheme? See, for example, UML package import and include behaviors. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Dave Goodell (dgoodell) Sent: Wednesday, July 30, 2014 3:35 PM To: Open

[OMPI devel] RFC: Change default behavior of calling ibv_fork_init

WHAT: Change default behavior in openib to not call ibv_fork_init() even if available. WHY: There are some strange interactions with ummunotify that cause errors. In addition, see the additional points below. WHEN: After next weekly meeting, August 5, 2014 DETAILS: This change will just be a

Re: [OMPI devel] RFC: job size info in OPAL

+2^1000 This information is absolutely necessary at this point. If someone has a better solution they can provide it as an alternative RFC. Until then this is how it should be done... Otherwise we loose uGNI support on the trunk. Because we ARE NOT going to remove the mailbox size

Re: [OMPI devel] RFC: job size info in OPAL

Hi Folks, I think given the way we want to use the btl's in lower levels like opal, it is pretty disgusting for a btl to need to figure out on its own something like a "global job size". That's not its business. Can't we add some attributes to the component's initialization method that

Re: [OMPI devel] RFC: job size info in OPAL

What is your definition of “global job size”? George. On Jul 31, 2014, at 11:06 , Pritchard Jr., Howard wrote: > Hi Folks, > > I think given the way we want to use the btl's in lower levels like opal, > it is pretty disgusting for a btl to need to figure out on its own

Re: [OMPI devel] RFC: job size info in OPAL

I'd like to suggest an alternative solution. A BTL can exploit whatever data it wants, but should first test if the data is available. If the data is *required*, then the BTL gracefully disqualifies itself. If the data is *desirable* for optimization, then the BTL writer (if they choose) can

Re: [OMPI devel] RFC: job size info in OPAL

The maximum number of peer processes that may be added over the course of the job will suffice. So either the world or universe size. This is a reasonable piece of information to expect the upper layers to provide to the communication layer. And the impact of providing this information is no

Re: [OMPI devel] RFC: job size info in OPAL

I definitively think you misunderstood this scope of this RFC. The information that is so important to you to configure the mailbox size is available to you when you need it. This information is made available by the PML through the call to add_procs, which comes with all the procs in the

Re: [OMPI devel] RFC: job size info in OPAL

Hi George, The ompi_process_info.num_procs thing that seems to have been an object of some contention yesterday. The ugni use of this is cloned off of the way I designed the mpich netmod. Leveraging off size of the job was an easy way to scale the mailbox size. If I'd been asked to have the

Re: [OMPI devel] RFC: job size info in OPAL

I do not like the fact that add_procs is called with every proc in the MPI_COMM_WORLD. That needs to change, so, I will not rely on the number of procs being added being the same as the world or universe size. -Nathan On Thu, Jul 31, 2014 at 09:22:00AM -0600, George Bosilca wrote: >I

Re: [OMPI devel] RFC: job size info in OPAL

Like I said, why don't we just do the following: > I'd like to suggest an alternative solution. A BTL can exploit whatever data > it wants, but should first test if the data is available. If the data is > *required*, then the BTL gracefully disqualifies itself. If the data is > *desirable* for

Re: [OMPI devel] RFC: job size info in OPAL

This approach will work now but we need to start thinking about how we want to support multiple simultaneous btl users. Does each user call add_procs with a single module (or set of modules) or does each user call btl_component_init and get their own module? If we do the latter then it might make

Re: [OMPI devel] RFC: job size info in OPAL

Fair enough - yeah, that is an issue I've been avoiding :-) On Jul 31, 2014, at 9:14 AM, Nathan Hjelm wrote: > > This approach will work now but we need to start thinking about how we > want to support multiple simultaneous btl users. Does each user call > add_procs with a

Re: [OMPI devel] mca_PROJECT_FRAMEWORK_COMPONENT_symbol vs. mca_FRAMEWORK_COMPONENT_symbol

Yeah, I forgot that pure ANSI C doesn't really have namespaces, other than to fully qualify modules and variables. Bummer. Makes writing large, maintainable middleware more difficult. -Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Kenneth A. Lloyd Sent:

[OMPI devel] Further questions about BTL OPAL move...

George -- Got 2 questions for ya: 1. I see some orte_* specific symbols/functions in ompi_mpi_init.c. Was that intentional? Shouldn't that stuff be in the RTE framework, or some such? 2. In tracking down some stuff relating to process names, it looks like names are now setting set by

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

All, Here is the patch that change the meaning of the atomics to make them always return the previous value (similar to sync_fetch_and_<*>). I tested this with the following atomics: OS X, gcc style intrinsics and AMD64. I did not change the base assembly files used when GCC style assembly

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca wrote: > Paul, I know you have a pretty diverse range computers. Can you try to > compile and run a "make check" with the following patch? I will see what I can do for ARMv7, MIPS, PPC and IA64 (or whatever subset of those is

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove wrote: > > On Thu, Jul 31, 2014 at 4:13 PM, George Bosilca > wrote: > >> Paul, I know you have a pretty diverse range computers. Can you try to >> compile and run a "make check" with the following patch? > >

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

Awesome, thanks Paul. When the results will be in we will fix whatever is needed for these less common architectures. George. On Thu, Jul 31, 2014 at 7:24 PM, Paul Hargrove wrote: > > > On Thu, Jul 31, 2014 at 4:22 PM, Paul Hargrove wrote: > >> >>

Re: [OMPI devel] Further questions about BTL OPAL move...

On Jul 31, 2014, at 3:41 PM, George Bosilca wrote: > > On Jul 31, 2014, at 18:26 , Jeff Squyres (jsquyres) > wrote: > >> George -- >> >> Got 2 questions for ya: >> >> 1. I see some orte_* specific symbols/functions in ompi_mpi_init.c. Was >> that

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Many thanks guys, this thread was most helpful in finding the fix. Paul H. nailed 80% of it on the head in the post where he identified the Makefile.am change. That Makefile.am change was due to three things: 1. Fixing a real bug (elsewhere in that commit) 2. My misunderstanding of how module

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Related question: If I am understanding PGI's list of fixed-TPRs (bugs) then it looks like one (certainly not the only) difference between 13.x and 14.1 is a fix to a problem with PROCEDURE and zero-argument subroutines. As it happens, the configure probe for PROCEEDURE is a zero-argument

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Nevermind my suggestion to revise examples/hello_usempif08.f90 I've just determined that it is already sufficient to reproduce the problem. (So now I need to see what's wrong in my testing scripts). -Paul On Thu, Jul 31, 2014 at 7:04 PM, Paul Hargrove wrote: > Second

Re: [OMPI devel] openmpi-1.8.2rc2 and f08 interface built with PGI-14.7 causes link error

Paul, the ibm test suite from the non public ompi-tests repository has several tests for usempif08. Cheers, Gilles On 2014/08/01 11:04, Paul Hargrove wrote: > Second related issue: > > Can/should examples/hello_usempif08.f90 be extended to use more of the > module such that it would have

Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

George: Have a failure with your patch applied on PPC64/Linux and gcc-4.4.6: Making all in asm make[2]: Entering directory `/home/hargrov1/OMPI/openmpi-trunk-linux-ppc64-gcc/BLD/opal/asm' CC asm.lo In file included from

[hwloc-devel] Create success (hwloc git dev-170-gabee241)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-170-gabee241 Start time: Thu Jul 31 21:01:01 EDT 2014 End time: Thu Jul 31 21:02:31 EDT 2014 Your friendly daemon, Cyrador