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/