...and cmr to v1.5. ;-)
(see https://svn.open-mpi.org/trac/ompi/ticket/2133)
On Dec 8, 2009, at 12:33 PM, George Bosilca wrote:
> Rainer,
>
> The patch looks correct. Please feel free to push it in the trunk.
>
> Thanks,
>george.
>
> On Dec 7, 2009, at 11:27 , Rainer Keller wrote:
>
Rainer,
The patch looks correct. Please feel free to push it in the trunk.
Thanks,
george.
On Dec 7, 2009, at 11:27 , Rainer Keller wrote:
> Hello Sylvain,
>
> On Friday 04 December 2009 02:27:22 pm Sylvain Jeaugey wrote:
>> There is definetly something wrong in types.
> Yes, the new ids
Thanks Rainer for the patch. I confirm it solves my testcase as well as
the real application that triggered the bug.
Sylvain
On Mon, 7 Dec 2009, Rainer Keller wrote:
Hello Sylvain,
On Friday 04 December 2009 02:27:22 pm Sylvain Jeaugey wrote:
There is definetly something wrong in types.
Ye
Hello Sylvain,
On Friday 04 December 2009 02:27:22 pm Sylvain Jeaugey wrote:
> There is definetly something wrong in types.
Yes, the new ids for optional Fortran datatypes are wrong.
So, as with other Fortran types, IMHO they need to map to C types, aka the IDs
should map. Therefore, we should _
There is definetly something wrong in types.
OMPI_DATATYPE_MAX_PREDEFINED is set to 45, while there are 55 predefined
types. When accessing ompi_op_ddt_map[ddt->id] with MPI_REAL8
(ddt->id=54), we're reading the ompi_mpi_op_bxor struct.
Depending on various things (padding, uninitialized memo
For the record, and to try to explain why all MTT tests may have missed
this "bug", configuring without --enable-debug makes the bug disappear.
Still trying to figure out why.
Sylvain
On Thu, 3 Dec 2009, Sylvain Jeaugey wrote:
Hi list,
I hope this time I won't be the only one to suffer this
Hi list,
I hope this time I won't be the only one to suffer this bug :)
It is very simple indeed, just perform an allreduce with MPI_REAL8
(fortran) and you should get a crash in ompi/op/op.h:411. Tested with
trunk and v1.5, working fine on v1.3.
From what I understand, in the trunk, MPI_REA
