master and v4.0.x: what should happen when an app compiles with a removed MPI interface?

[jsquyres]

From #6120, @gpaulsen noticed that both v4.0.x and master only use the compiler "deprecated" attribute to mark removed MPI functions. Take the following example program:

#include <mpi.h>

int main(int argc, char** argv[])
{
    int a;
    void *address;

    MPI_Address(&a, &address);
    return 0;
}

Case 1: master, with MPI-1 compatibility disabled.

• Functions like MPI_Address are marked with the __deprecated__ compiler attribute.
• Functions like MPI_Address are not included in the MPI library.

Meaning:

• The deprecating warning will be emitted
  • Including the word "deprecated", which may be a bit confusing (because MPI_Address is not deprecated -- it's removed)
• The example program will compile successfully
• But it will fail to link

I think it is anti-social to allow the compile to succeed when we know that the link will fail. I think we should somehow make the compile fail (see below).

Case 2: v4.0.x, with MPI-1 compatibility disabled

• Functions like MPI_Address are marked with the __deprecated__ compiler attribute.
• Functions like MPI_Address are included in the MPI library.

Meaning:

• The deprecating warning will be emitted
  • Including the word "deprecated", which may be a bit confusing (because MPI_Address is not deprecated -- it's removed)
• The example program will compile successfully
• The example program will also link successfully.

I'm not sure that this is the message that we want to convey to the community (i.e., that it's still ok to use the removed symbols -- i.e., if it's just a compiler warning, people will ignore it). I thought our intent was to raise the pain level (just a little) so that the greater MPI application community became aware of this issue. As such, my gut reaction is that we should make the compile fail.

Applications that were compiled against v3.0.x or v3.1.x (or even v4.0.x) with MPI_Address (etc.) will still work because MPI_Address (etc.) are still in the MPI library. -- which is desirable.

How to make the compile fail?

If we elect to make the compile fail, it's an open question on how to do this.

1. The __deprecated___ function attribute is just a warning.
2. @gpaulsen and I played with several ways to try to make a compile fail, but yet also still give a helpful error message (e.g., "Stop using MPI_Address. Use MPI_Get_address instead" yadda yadda yadda). This is surprisingly difficult. The only real way to make this happen is to introduce a syntax error somehow (e.g., via #define MPI_Address(a,b) some kind of syntax error containing the helpful message, but that's... tricky).

Are these cases really what we want?

1. On master: I think it's anti-social to allow the compile to succeed when we know the link will fail.
2. On v4.0.x: it's different there, because we know the link will succeed. ...but do we really want the compile to succeed?

[jsquyres]

We talked about this on the 2019-01-15 webex. Here's what we decided...

There are 3 cases:

1. User wants MPI-1 compatibility.
   1. MPI_Address (and friends) are declared in mpi.h with the deprecation notice
2. User does not want MPI-1 compatibility, and has a C11-capable compiler
   1. Declare an MPI_Address (etc.) macro in mpi.h like this (which will cause a compile-time error):

#if __STDC_VERSION__ >= 201101L
#define MPI_Address(a, b) _Static_assert (0, "MPI_Address was removed in MPI-3.0. Use MPI_Get_address instead")
#endif

3. User does not want MPI-1 compatibility, and does not have a C11-capable compiler
   1. Do not declare MPI_Address (etc.) in mpi.h at all.
   2. 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).
   3. 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).
   4. 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).

[ggouaillardet]

in the third case, how do you expect the user can compile his code if MPI_Address is not declared in mpi.h ? C99 does not allow missing prototypes. should 3.i be "declare MPI_Address with the deprecation warning on v4.0.x" ?

[jsquyres]

In the 3rd case (where MPI_Address is not in mpi.h), the user's application will either compile or it won't -- depending on the compiler and whether un-prototyped functions are considered an error or not (remember that we don't guarantee that the same compiler is used to build Open MPI as is used to build the user's MPI application). With v4.0.x, the application will even link (but it won't with master/v5.0.x).

For example:

$ mpicc --showme
gcc -I/home/jsquyres/bogus/include -pthread -Wl,-rpath -Wl,/home/jsquyres/bogus/lib -Wl,--enable-new-dtags -L/home/jsquyres/bogus/lib -lmpi
$ mpicc --version
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# address.c is the example code from the beginning of this issue
$ mpicc -c address.c
address.c: In function ‘main’:
address.c:8:5: warning: implicit declaration of function ‘MPI_Address’; did you mean ‘MPI_Test’? [-Wimplicit-function-declaration]
     MPI_Address(&a, &address);
     ^~~~~~~~~~~
     MPI_Test
$ mpicc address.o -o address
$

[bertwesarg]

There are two more options:

1. Use the error attribute. It gives this message:

void MPI_Address(void*,void*)
__attribute__((error ("MPI_Address was removed from this MPI, use MPI_Get_address")));

error: call to ‘MPI_Address’ declared with attribute error: MPI_Address was removed from this MPI, use MPI_Get_address
     MPI_Address(&a, &address);
     ^~~~~~~~~~~~~~~~~~~~~~~~~

1. Declare the removed function as a variable:

extern int MPI_Address;

But the error message is not that nice:

error: called object ‘MPI_Address’ is not a function or function pointer
     MPI_Address(&a, &address);
     ^~~~~~~~~~~
note: declared here
 extern int MPI_Address;
            ^~~~~~~~~~~

[jsquyres]

@bertwesarg Oh neat -- I didn't know about the error attribute. I see this as far back as gcc 4.3.6 (see https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Function-Attributes.html#Function-Attributes).

Do you know how portable is this with other compilers?

@gpaulsen This could be a 2nd option:

1. If C11 static assert is available, use that.
2. If the error attribute is available, use that.
3. Otherwise, just don't declare the function at all.

[bertwesarg]

@bertwesarg Oh neat -- I didn't know about the error attribute. I see this as far back as gcc 4.3.6 (see https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Function-Attributes.html#Function-Attributes).

Do you know how portable is this with other compilers?

Neither PGI nor Clang accept it. No Intel at hand right now.

[gpaulsen]

I've posted what I think are "final" solutions to master PR #6359 and v4.0.1 PR #6358.

[jsquyres]

@gpaulsen That's backwards. It's actually:

• Fix MPI1 function removal [master] Issue 6114 [API Change] #6358: Master PR
• Fix MPI1 function removal [v4.0.x] Issue 6114 #6359: v4.0.x PR

[gpaulsen]

Now that these PRs have been merged, can we close this issue?

[jsquyres]

🎉