Hi George,
This fix seems insufficient for multibyte datatypes...
The correct increment of the pointers is length * extent, isn't it?
(2012/04/06 23:50), bosi...@osl.iu.edu wrote:
> Author: bosilca
> Date: 2012-04-06 10:50:04 EDT (Fri, 06 Apr 2012)
> New Revision: 26243
> URL: https://svn.open-mp
+1 here too.
--td
On 4/6/2012 11:19 PM, Barrett, Brian W wrote:
Agreed.
Brian
On Apr 6, 2012, at 7:31 PM, Ralph Castain wrote:
+1 for SJ - much easier to be someplace with a major airport.
On Apr 5, 2012, at 7:54 AM, Gutierrez, Samuel K wrote:
My vote is for San Jose.
Sam
After looking at Oracles MTT results there seem to be a (some??)
regressions between r26240 and 26249 detected by the ibm and intel tests
suites. An example of this is the failures in the comm_join, final and
loop_spawn tests of the ibm test suite as seen in
http://www.open-mpi.org/mtt/index.p
This is totally not related to the bug report, but a neat trick in Trac.
My question was "what were the commits between r26240 and 26249"?
In the search box type:
log:@26240:26249
Or use the direct url:
https://svn.open-mpi.org/trac/ompi/log/?revs=26240-26249
nifty...
-- Josh
On Mon, Apr 9,
FWIW: this isn't a bug in orte_dpm, but in the MPI binding for comm_join. The
problem is that both sides in the comm_join are setting "send_first" to true -
i.e., both sides are trying to be the first to send on the handshake. We got
away with this before because of a bug in orte_dpm that made t
Nobody stepped up, so I fixed this in r26257
On Apr 9, 2012, at 9:21 AM, Ralph Castain wrote:
> FWIW: this isn't a bug in orte_dpm, but in the MPI binding for comm_join. The
> problem is that both sides in the comm_join are setting "send_first" to true
> - i.e., both sides are trying to be the
Should all be fixed now.
On Apr 9, 2012, at 7:17 AM, TERRY DONTJE wrote:
> After looking at Oracles MTT results there seem to be a (some??) regressions
> between r26240 and 26249 detected by the ibm and intel tests suites. An
> example of this is the failures in the comm_join, final and loop_s
