I'm entangled in a discussion with Open MPI folks about whether the struct datatype constructor should or should not add padding depending on the oldtypes having or not explicit lb/ub markers.
https://github.com/open-mpi/ompi/issues/8560
Please see the attached example. It basically creates a simple struct datatype with type signature {unsigned short, unsigned char} in different ways (which I would expect to be all equivalent).
Running it with latest MPICH 3.4.1
$ for i in `seq 0 5`; do mpicc -DCASE=$i align.c; ./a.out; done
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
For Open MPI, up to v4.0.x, that was the case, too.
However, with latest Open 4.1.0, now I get:
$ for i in `seq 0 5`; do mpicc -DCASE=$i align.c; ./a.out; done
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=4
c-sizeof=4 mpi-extent=3
c-sizeof=4 mpi-extent=2
Open MPI folks claim that their behavior is correct and in line with the MPI standard. Maybe they have a point regarding the ub/lb definition in page 105 of MPI-3.1, despite such behavior being quite unintuitive.
On the other hand, MPICH's struct datatype constructor always adjusts the ub to account for padding. Open MPI obviously don't. I don't see any wording in the standard where this could be implementation-defined behavior. If Open MPI folks are right, then MPICH is wrong, or the other way around. But we cannot have the two major competing implementations disagree on this.
Regards,
--
Lisandro Dalcin
============
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/