apply romio314 patch to romio321

When romio314 was first pulled in an extra patch was applied to it, see commit
92f6c7c1e210c559471a05aaac9b19e0bd3d71bb. Most of that patch is already present
in vanilla romio321, but the fix for MPIO_DATATYPE_ISCOMMITTED() isn't.

If that macro doesn't set err_ then some paths end up with a variable being used
uninitialized. In particular you can trace through romio321/romio/mpi-io/read.c
to see what happens with error_code. It's an uninitialized stack variable that goes
through three MPIO_CHECK_* macros none of which set it. The macros consistently set
error_code to a failure if they see something wrong, but they don't consistently
set it to success when things are fine.

And then in the last macro MPIO_CHECK_DATATYPE it tries to look at the value
of error_code that was never set.

Signed-off-by: Mark Allen <markalle@us.ibm.com>

ompi/mca/io/romio321/romio/mpi-io/mpioimpl.h

@@ -2,6 +2,8 @@
 /* 
  *
  *   Copyright (C) 1997 University of Chicago. 
+ *   Copyright (c) 2018 IBM Corporation. All rights reserved.
+ *   $COPYRIGHT$
  *   See COPYRIGHT notice in top-level directory.
  */
 
@@ -36,7 +38,12 @@
 #define ROMIO_THREAD_CS_ENTER()
 #define ROMIO_THREAD_CS_EXIT()
 #define ROMIO_THREAD_CS_YIELD()
-#define MPIO_DATATYPE_ISCOMMITTED(dtype_, err_) do {} while (0)
+/* The MPI_DATATYPE_ISCOMMITTED macro now always sets err_=0.
+   This is an optimistic approach for Open MPI, but it is likely other
+   upper layers already checked the datatype was committed.
+   Not setting err_ is incorrect since it can lead to use of
+   uninitialized variable.*/
+#define MPIO_DATATYPE_ISCOMMITTED(dtype_, err_) do { err_ = 0; } while (0)
 #ifdef HAVE_WINDOWS_H
 #define MPIU_UNREFERENCED_ARG(a) a
 #else