Hi folks
We are about to pull the release trigger on 1.7.4, so any last-second issues
should be surfaced immediately. Otherwise, we will release right after the OMPI
developer's telecon on Tues morning (Pacific time).
Thanks
Ralph
On Jan 27, 2014, at 1:24 PM, Nathan Hjelm wrote:
> On Mon, Jan 27, 2014 at 01:10:43PM -0800, Ralph Castain wrote:
>> Nathan, I have no idea what you are talking about. What I do know is that
>> you had me commit a patch to the trunk and v1.7.4 that caused multiple
>> warnings about 32-bit issu
On Mon, Jan 27, 2014 at 01:10:43PM -0800, Ralph Castain wrote:
> Nathan, I have no idea what you are talking about. What I do know is that you
> had me commit a patch to the trunk and v1.7.4 that caused multiple warnings
> about 32-bit issues to appear in both cases. George is reporting issues th
Nathan, I have no idea what you are talking about. What I do know is that you
had me commit a patch to the trunk and v1.7.4 that caused multiple warnings
about 32-bit issues to appear in both cases. George is reporting issues that
look very much like the ones I'd expect based on those warnings.
Nope. Vader will not work on non-xpmem systems in 1.7.4. The CMR is
still open for 1.7.5 (#4053. Issue like the one George reported are
why I chose to hold off on the new vader until 1.7.5.
The fix is complete. At this point I am waiting on some feedback on
changes to OMPI_CHECK_PACKAGE before com
Nathan,
To encourage you to focus on 1.7.4, I will delay testing vader on the SGI
UV until I've tested the next 1.7.4 release candidate (or final).
-Paul
On Mon, Jan 27, 2014 at 12:55 PM, Ralph Castain wrote:
> Just FWIW: I believe that problem did indeed make it over to 1.7.4, and
> that rel
Just FWIW: I believe that problem did indeed make it over to 1.7.4, and that
release is on "hold" pending your fix. So while I'm happy to hear about xpmem
on SGI, please do let us release 1.7.4!
On Jan 27, 2014, at 8:19 AM, Nathan Hjelm wrote:
> Yup. Has to do with not having 64-bit atomic ma
Yup. Has to do with not having 64-bit atomic math. The fix is complete
but I am working on another update to enable using xpmem on SGI
systems. I will push the changes once that is complete.
-Nathan
On Mon, Jan 27, 2014 at 04:00:08PM +, Jeff Squyres (jsquyres) wrote:
> Is this the same issue
Is this the same issue Absoft is seeing in 32 bit builds on the trunk? (i.e.,
100% failure rate)
http://mtt.open-mpi.org/index.php?do_redir=2142
On Jan 27, 2014, at 10:38 AM, Nathan Hjelm wrote:
> This shouldn't be affecting 1.7.4 since neither the vader or coll/ml
> updates have been mo
This shouldn't be affecting 1.7.4 since neither the vader or coll/ml
updates have been moved yet. As for trunk I am working on a 32-bit fix
for vader and it should be in later today. I will have to track down
what is going wrong the basesmuma initialization.
-Nathan
On Sun, Jan 26, 2014 at 04:10:
I noticed two major issues on 32 bits machines. The first one is with the vader
BTL and the second with the selection logic in basesmuma
(bcol_basesmuma_bank_init_opti). Both versions are impacted: trunk and 1.7.
If I turn off vader and boll via the MCA parameters everything runs just fine.
G
Sweet.
On Jan 24, 2014, at 7:09 PM, Paul Hargrove
wrote:
> On Fri, Jan 24, 2014 at 3:31 PM, Paul Hargrove wrote:
> On Fri, Jan 24, 2014 at 3:27 PM, Jeff Squyres (jsquyres)
> wrote:
> I just committed a change on the trunk to configure that should disqualify
> the older pathscale and open64
On Fri, Jan 24, 2014 at 3:31 PM, Paul Hargrove wrote:
> On Fri, Jan 24, 2014 at 3:27 PM, Jeff Squyres (jsquyres) <
> [email protected]> wrote:
>>
>> I just committed a change on the trunk to configure that should
>> disqualify the older pathscale and open64 compilers from compiling the
>> mpi_f0
On Fri, Jan 24, 2014 at 3:27 PM, Jeff Squyres (jsquyres) wrote:
>
> I just committed a change on the trunk to configure that should disqualify
> the older pathscale and open64 compilers from compiling the mpi_f08 module
> (like we did in 1.7.3 and earlier).
OK, I will plan to test tonight's trun
On Jan 24, 2014, at 1:18 AM, Paul Hargrove wrote:
> My understanding is that for (at least) pathscale and open64 compilers we
> have a regression because 1.7.3 automatically rejected the f08 bindings, but
> the current 1.7.4rc tarball fails while building usempif08 unless *manually*
> disabled
On Jan 24, 2014, at 1:18 AM, Paul Hargrove wrote:
> Can you give a quick summary of the status of fortran in v1.7 at the moment?
I had to mostly take the day off from 1.7 Fortran stuff yesterday to catch up
on my day job... :-\
> My understanding is that for (at least) pathscale and open64 co
Jeff,
Can you give a quick summary of the status of fortran in v1.7 at the moment?
My understanding is that for (at least) pathscale and open64 compilers we
have a regression because 1.7.3 automatically rejected the f08 bindings,
but the current 1.7.4rc tarball fails while building usempif08 unle
woot!!! Thanks Paul and Jeff!
On Jan 22, 2014, at 10:22 PM, Paul Hargrove wrote:
>
> On Wed, Jan 22, 2014 at 7:27 PM, Paul Hargrove wrote:
> After the 1.7 tests on the XLF, Open64 and PathScale platforms complete I'll
> be testing the trunk on those systems with the compiler-appropriate
> --
On Wed, Jan 22, 2014 at 7:27 PM, Paul Hargrove wrote:
> After the 1.7 tests on the XLF, Open64 and PathScale platforms complete
> I'll be testing the trunk on those systems with the compiler-appropriate
> --enable-mpi-fortran= settings.
The following are results (for trunk) for four compilers
Jeff,
Sorry to hear you spent the day dealing with both fortran and autoconf.
I spent mine dealing with my auto insurance company claims department.
So, we both had miserable days but you win.
The 1.7 tarball was ready by the time I read your message and I've launched
a flock of testers.
Were the
Ok, here's my update: I fixed a bunch of issues in the Fortran support today;
most are minor, but they took a while to verify (and some are slated for v1.7.5
because they aren't critical). I also added the ability to disable building
the mpi_f08 module.
Here's what's on the trunk / v1.7, and w
On Wed, Jan 22, 2014 at 2:40 PM, Paul Hargrove wrote:
>
> + PathScale and Open64 which fail building in ompi/mpi/fortran/use-mpi-f08/
>
I implied, but forgot to state the following explicitly:
Both PathScale and Open64 can build the Fortran support present in 1.7.3
(verified today).
So, as Ralp
Update: I've been working all day on Fortran issues (pulling on one
Paul-Fortran--sweater-thread revealed several other issues :-( ).
I'll be sending an update soon...
On Jan 22, 2014, at 5:40 PM, Paul Hargrove wrote:
>
> On Wed, Jan 22, 2014 at 1:33 PM, Ralph Castain wrote:
> My main co
On Wed, Jan 22, 2014 at 1:33 PM, Ralph Castain wrote:
> My main concern with 1.7.4 at the moment stems from all the Fortran
> changes we pushed into that release - this occurred *after* 1.7.3, and so
> those problems represent a regression in the 1.7 series.
Unless I am missing something, the c
ou remind me again about why the 1.8.0 by mid-March is a requirement?
>
> Thanks,
> Rolf
>
> >-Original Message-
> >From: devel [mailto:[email protected]] On Behalf Of Ralph
> >Castain
> >Sent: Tuesday, January 21, 2014 6:41 PM
> >To: Ope
in 1.7.5 CMRs and delaying it is less
> desirable to me.
>
> Can you remind me again about why the 1.8.0 by mid-March is a requirement?
>
> Thanks,
> Rolf
>
> >-Original Message-
> >From: devel [mailto:[email protected]] On Behalf Of Ralph
> >Castain
stain
>> Sent: Tuesday, January 21, 2014 6:41 PM
>> To: Open MPI Developers
>> Subject: [OMPI devel] 1.7.4 status update
>>
>> Hi folks
>>
>> I think it is safe to say that we are not going to get a release candidate
>> out
>> tonight - more For
n MPI Developers
>Subject: [OMPI devel] 1.7.4 status update
>
>Hi folks
>
>I think it is safe to say that we are not going to get a release candidate out
>tonight - more Fortran problems have surfaced, along with the need to
>complete the ROMIO review. I have therefore concluded w
Hi folks
I think it is safe to say that we are not going to get a release candidate out
tonight - more Fortran problems have surfaced, along with the need to complete
the ROMIO review. I have therefore concluded we cannot release 1.7.4 this week.
This leaves us with a couple of options:
1. con
Hi folks
If you've been following all the email on this list, you know that we are still
working on resolving portability issues with 1.7.4. We obviously will not meet
our milestone of releasing it today :-(
I'm hoping the delay will only last a week, and thus won't impact 1.7.5 too
much. The
Yeah, I can add those as we regularly run on them - see other note about
earlier versions
On Jan 9, 2014, at 3:00 PM, Paul Hargrove wrote:
> The README in the latest 1.7.4rc lists support for:
>
> - OS X (10.5, 10.6, 10.7), 32 and 64 bit (x86_64), with gcc and
> Absoft compilers (*)
>
>
The README in the latest 1.7.4rc lists support for:
- OS X (10.5, 10.6, 10.7), 32 and 64 bit (x86_64), with gcc and
Absoft compilers (*)
Should 10.8 (Mountain Lion) be listed?
What about 10.9 (Mavericks)?
I can test 10.5 through 10.8 but haven't been doing so assuming that is
covered by th
32 matches
Mail list logo
