Fix MPI1 function removal [v4.0.x] Issue 6114

[gpaulsen]

NOTE: The intent of this PR is to fulfill the plan discussed in #6278 (comment), with the addition of the error attribute suggested in #6278 (comment).

1. Changes the prototypes for MPI removed functions in the
   following ways:

   There are 4 cases:

   • User wants MPI-1 compatibility (--enable-mpi1-compatibility)

     MPI_Address (and friends) are declared in mpi.h with
     deprecation notice

   • User does not want MPI-1 compatibility, and has a C11-capable
     compiler

     Declare an MPI_Address (etc.) macro in mpi.h, which will
     cause a compile-time error using _Static_assert C11 feature

   • User does not want MPI-1 compatibility, and does not have a
     C11-capable compiler, but the compiler supports error function
     attributes.

     Declare an MPI_Address (etc.) macro in mpi.h, which will
     cause a compile-time error using error function attribute.

   • User does not want MPI-1 compatibility, and does not have a
     C11-capable compiler, or a compiler that supports error
     function attributes.

     Do not declare MPI_Address (etc.) in mpi.h at all.
     Unless the user is compiling with something like -Werror,
     this will allow the user's code to compile. We are
     choosing this because it seems like a losing battle to
     make some kind of compile time error that is friendly to
     the user (and doesn't make it look like mpi.h itself is broken).

     On v4.0.x, this will allow the user code to both compile
     (albeit with a warning) and link (because the MPI_Address
     will be in the MPI library because we are preserving ABI
     back to 3.0.x).

     On master/v5.0.x, this will allow the user code to compile,
     but it will fail to link (because the MPI_Address symbol will
     not be in the MPI library).

(cherry picked from commit 4214b5a)
Signed-off-by: Geoffrey Paulsen [email protected]

Conflicts:
ompi/include/mpi.h.in

[gpaulsen]

Cherry picked for one of the commits on #6358

[gpaulsen]

Adding work in progress, because the autogenerated profiling API is not correct.

[gpaulsen]

Intended solution for #6278
and #6114

[ibm-ompi]

The IBM CI (GNU Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/996bac17bf0d8dfa2ae1491172c1aee1

[ibm-ompi]

The IBM CI (XL Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/c804b26d21d7689725509a6c83243884

[gpaulsen]

@jsquyres @hppritcha, I think this is finally ready to go.
I've tested all of the various test cases on two different platforms with two different compilers.
Once it passed all of that, I then did the same on Master in one commit, and cherry-picked it here, and added a 2nd commit on the master PR #6358 that ACTUALLY removes all of this on master.

[jsquyres]

Your commit message says that there are 4 cases, but you list 5 cases. One of them seems to be an incomplete duplicate (a copy-n-paste error?). The indenting is weird, too -- are you trying to make 3 of them be sub-bullets?

[jsquyres]

Requested changes on associated master PR (#6358).

[ibm-ompi]

The IBM CI (GNU Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/68faa9761389f8182c21cfa987ba3b2b

[ibm-ompi]

The IBM CI (XL Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/b10332a864f0a0f83982f03537b8768b

[gpaulsen]

@jsquyres I've addressed all of the issues, please re-review.

[jsquyres]

I updated the commit message on the commit on this PR (and updated the cherry pick hash to match the new hash on 6358) and also added a 2nd commit on this PR with the same suggestions I made in #6358 (comment).

[ibm-ompi]

The IBM CI (GNU Compiler) build failed! Please review the log, linked below.

Gist: https://gist.github.com/a1fb1812f804a714fa1e07e5e9aaa2f5

[jsquyres]

Squashed down to 1 commit; hash updated to match the hash from #6358.