Testing tonight's trunk tarball on the Altix system I have access to
looks fine now.
Thanks, Brian.
-Paul
On 2/20/2012 11:49 AM, Paul H. Hargrove wrote:
Brian,
Thanks for looking into this.
I'll plan to take a look at the trunk tarball tonight and report back.
-Paul
On 2/20/2012 8:49 AM, Ba
The addition on Monday of the Java cases to examples/Makefile has shown
that the default "make" in Solaris-10 will stop on the first failed grep
command in the "all" rule:
$ make
mpicc -g -o hello_c hello_c.c
mpicc -g -o ring_c ring_c.c
mpicc -g -o connectivity_c connectivity_c.c
mpic++ -g
And while we are looking at examples/Makefile on Solaris-10, why are the
F77 examples getting built w/ mpif90?
Because w/ the Solaris make setting FC also silently sets F77 (yes, I am
NOT kidding)!
So, reordering the F77= and FC= lines in Makefile resolves that
mis-behavior.
Attached is my pat
I went ahead and applied this, with a tweak. There is no reason to call our
flag "FC" as all we use it for is to call the write wrapper. So I renamed it to
something less problematic.
On Feb 21, 2012, at 1:20 AM, Paul H. Hargrove wrote:
> And while we are looking at examples/Makefile on Solaris
Thanks, Ralph.
Excellent point about not needing to use the "FC" name with its special
(absurd?) behavior.
-Paul
On 2/21/2012 1:52 AM, Ralph Castain wrote:
I went ahead and applied this, with a tweak. There is no reason to
call our flag "FC" as all we use it for is to call the write wrapper.
That is truly bizarre "make" behavior.
Heads up that in the upcoming fortran revamp, we *only* use FC. I.E., there's
only mpifort wrapper compiler (mpif77 and mpif90 still exist, but only as sym
links to mpifort, signifying that mpifort is the way of the future).
This was done because there h
On 2/21/2012 5:55 AM, Jeff Squyres (jsquyres) wrote:
That is truly bizarre "make" behavior.
Heads up that in the upcoming fortran revamp, we *only* use FC. I.E.,
there's only mpifort wrapper compiler (mpif77 and mpif90 still exist,
but only as sym links to mpifort, signifying that mpifort is
On Feb 21, 2012, at 6:39 AM, TERRY DONTJE wrote:
>> Heads up that in the upcoming fortran revamp, we *only* use FC. I.E.,
>> there's only mpifort wrapper compiler (mpif77 and mpif90 still exist, but
>> only as sym links to mpifort, signifying that mpifort is the way of the
>> future).
>>
>> T
On 2/21/2012 2:55 AM, Jeff Squyres (jsquyres) wrote:
That is truly bizarre "make" behavior.
Heads up that in the upcoming fortran revamp, we *only* use FC. I.E.,
there's only mpifort wrapper compiler (mpif77 and mpif90 still exist,
but only as sym links to mpifort, signifying that mpifort is
Right.
The revamped fortran stuff is *coming* -- it's off in a Mercurial bitbucket
right now. It's not on the trunk yet. It's here, if you care:
https://bitbucket.org/jsquyres/mpi3-fortran
On Feb 21, 2012, at 7:57 AM, Paul H. Hargrove wrote:
>
>
> On 2/21/2012 2:55 AM, Jeff Squyres (j
Should be fixed on the trunk in r25982.
On Feb 18, 2012, at 7:39 AM, Paul Hargrove wrote:
> Same has been seen on Solaris11/x86-64 w/ the Studio 12.3 compiler.
> However, a gcc build on the same system was fine.
>
> -Paul
>
> On Fri, Feb 17, 2012 at 10:49 AM, Paul H. Hargrove wrote:
> Building
Committed and CMR'ed. Thanks!
On Feb 17, 2012, at 3:22 PM, Paul H. Hargrove wrote:
> When building trunk or 1.5.x on OpenBSD-5.0 (and maybe others), I get *LOTS*
> of the following:
>> /usr/include/arpa/inet.h:74: warning: 'struct in_addr' declared inside
>> parameter list
>> /usr/include/arpa
CMR filed; custom v1.5 patch attached:
https://svn.open-mpi.org/trac/ompi/ticket/3024
On Feb 20, 2012, at 4:52 PM, Jeff Squyres (jsquyres) wrote:
> Yo Brian --
>
> Do we need to bring this to v1.5, too?
>
>
> On Feb 20, 2012, at 11:49 AM, Barrett, Brian W wrote:
>
> > Hi Paul -
> >
> > T
Some supplements:
I tried several compilers for building Open MPI with enabled optimizations for
the AMD Bulldozer architecture:
* gcc 4.6.2 (-Ofast -mtune=bdver1 -march=bdver1)
* Open64 5.0 (-O3 -march=bgver1 -mtune=bdver1 -mso)
* Intel 12.1 (-O3 -msse4.2)
They all result in similar latencies
Building the v1.5 branch on Linux with the Solaris Studio 12.2 compilers
I see the following failure:
"[srcdir]/opal/event/event.h", line 797: Error: Type name expected
instead of "u_char".
"[srcdir]/opal/event/event.h", line 798: Error: Type name expected
instead of "u_char".
"[srcdir]/opal/eve
What: Allocate free list payload even if a payload size is specified even if no
mpool is specified.
When: Thursday, Feb 23, 2012
Why: The current behavior is to ignore the payload size if no mpool is
specified. I see no reason why a payload buffer should't be allocated in the no
mpool case. T
Opps, screwed up the title. Should be: RFC: Allocate requested free list
payload even if an mpool isn't specified.
-Nathan
On Tue, 21 Feb 2012, Nathan Hjelm wrote:
What: Allocate free list payload even if a payload size is specified even if
no mpool is specified.
When: Thursday, Feb 23, 201
I think I am OK with this.
Alternatively, you could have done something like is done in the TCP BTL where
the payload and header are added together for the frag size?
To state more clearly, I was trying to say you could do something similar to
what is done at line 1015 in btl_tcp_component.c a
On Tue, 21 Feb 2012, Rolf vandeVaart wrote:
I think I am OK with this.
Alternatively, you could have done something like is done in the TCP BTL where
the payload and header are added together for the frag size?
To state more clearly, I was trying to say you could do something similar to
what
We have some amount of MTT testing going on every night and on ONE of
our systems v1.5 has been dead since r25914. The system is
Linux burl-ct-v20z-10 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
and I'm encountering the problem with Intel (composer_xe_201
What's the output of running lstopo from hwloc 1.3.2? (this is the version
that's in the OMPI trunk and v1.5 branches)
http://www.open-mpi.org/software/hwloc/v1.3/
Is there any difference from v1.4 hwloc?
http://www.open-mpi.org/software/hwloc/v1.4/
On Feb 21, 2012, at 7:20 PM, Eugen
I have been testing v1.5 with slightly older Intel
"composerxe-2011.5.220" compilers.
I see a "make check" failure in opal_datatype_test which is not present
with any other compiler (such as gcc on the same node).
This has been seen most recently on the 1.5.5rc2r25990 tarball generated
earlier t
A few things to note:
1) This is NOT a problem w/ the SS12.3 compilers on the same machine.
So, one could say "upgrade your compiler" (a free download) and not
delay 1.5.5 for this issue.
2) This is ONLY a problem on Linux, and not on Solaris (both SS12.2 and
SS12.3 tested for x86, x86-64, Sp
Here are the first of the results of the testing I promised.
I am not 100% sure how to reach the code that Eugene reported as
problematic, so I tried just running the ring test with various
-bind-to-* options. I am quite willing to run additional test cases.
All runs are w/ OMPI_MCA_btl=sm,s
My build with the "2011_sp1.8.273" Intel compilers passes the same tests
as I detailed below for "2011_sp1.7.256".
I don't suspect any longer that the compiler is at fault, but am willing
to try additional/alternate tests to help confirm.
-Paul
On 2/21/2012 5:40 PM, Paul H. Hargrove wrote:
He
25 matches
Mail list logo
