Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Warn user about deprecated MPI functionalityand "wrong" compiler usage
From: Paul H. Hargrove (PHHargrove_at_[hidden])
Date: 2009-05-18 15:19:48


IMHO there are two distinct issues being entangled here.
  1) Flagging deprecated functionality
  2) Informing the user about a change of compiler (possibly as an
#error or #warning)

I understand why solving #1 requires detecting the compiler change to
avoid a "bad attribute" (see BACKGROUND, below). However, I don't see
why this detection requires that one report it to the user. In the
naive implementation, a change of compiler would just silently loose the
ability to warn about deprecated functionality. No other user-visible
change in behavior would be required if the compiler were to change.
So, my recommendation is that Rainer and Jeff narrow their RFC to cover
just #1, and float an independent RFC for #2 only after #1 has been well
tested.

-Paul

BACKGROUND:

As Rainer acknowledged, this is based on some preprocessor code we've
been using in GASNet for some time now. Among other things, we use this
code to ensure that attributes that were detected at configure time are
still guaranteed valid at compile time. A simplified example from GASNet:

   /* detect when the compiler in use differs from the one tested by
configure,
    * indicating some of the configure-detected results may be invalid
for this compilation
    */
  #include <portable_platform.h>
  #if PLATFORM_COMPILER_ID != GASNETI_PLATFORM_COMPILER_ID || \
       PLATFORM_COMPILER_VERSION != GASNETI_PLATFORM_COMPILER_VERSION
     #define GASNETI_CONFIGURE_MISMATCH 1
  #endif
  
   #if GASNETI_CONFIGURE_MISMATCH
       #define GASNETI_ATTRIBUTE_FOO /* Not safe since compiler has
changed */
   #elif HAVE_GCC_ATTRIBUTE_FOO
       #define GASNETI_ATTRIBUTE_FOO __attribute__(__foo__)
   #else
       #define GASNETI_ATTRIBUTE_FOO /* Not detected at configure time */
   #endif

Jeff Squyres wrote:
> Agreed. Being able to handle such scenarios properly is one of the
> reasons that Rainer and I are iterating on this in a mercurial branch.
>
>
>
> On May 18, 2009, at 7:39 AM, Brian Barrett wrote:
>
>> I think care must be taken on this front. While I know we don't like
>> to admit it, there is no reason the C compilers have to match, and
>> indeed good reasons they might not. For example, at LANL, we
>> frequently compiled OMPI with GCC, then fixed up the wrapper compilers
>> to use Icc or whatever, to work around optimizer bugs. This is
>> functionality I don't think should be lost just to warn about
>> deprecated functions.
>>
>> Brian
>>
>> --
>> Brian Barrett
>>
>> There is an art . . . to flying. The knack lies in learning how to
>> throw yourself at the ground and miss.
>>
>> On May 18, 2009, at 1:34, Rainer Keller <keller_at_[hidden]> wrote:
>>
>> > What: Warn user about deprecated MPI functionality and "wrong"
>> > compiler usage
>> >
>> > Why: Because deprecated MPI functions, are ... deprecated
>> >
>> > Where: On trunk
>> >
>> > When: Apply on trunk before branching for v1.5 (it is user-visible)
>> >
>> > Timeout: 1 weeks - May 26, 2009 after the teleconf.
>> >
>> > ---------------------------------------------------------------------
>> >
>> > I'd like to propose a patch that addresses two issues:
>> > - Users shoot themselves in the foot compiling with a different
>> > compiler
>> > than what was used to compile OMPI (think ABI)
>> > - The MPI-2.1 std. defines several functions to be deprecated.
>> >
>> > This will warn Open MPI users, when accessing deprecated functions,
>> > even
>> > giving a proper warning such as:
>> > "MPI_TYPE_HVECTOR is superseded by MPI_TYPE_CREATE_HVECTOR"
>> > Also, now we may _warn_ when using a different compiler (gcc vs.
>> > intel vs.
>> > pgcc)
>> >
>> >
>> > This is achieved using __opal_attribute_deprecated__ and obviously
>> > needs to be
>> > added into mpi.h, therefore being a user-visible change.
>> >
>> > This however has a few caveats:
>> > 1.) Having Open MPI compiled with gcc and having users compiling
>> > with another
>> > compiler, which is not supporting __attribute__((deprecated)) is
>> > going to be a
>> > problem
>> > 2.) The attribute is most useful, when having a proper description
>> > (as above)
>> > -- which requires support for the optional argument to
>> > __deprecate__. This
>> > feature is offered only in gcc>4.4 (see http://gcc.gnu.org/ml/gcc-
>> > patches/2009-04/msg00087.html).
>> >
>> >
>> > Therefore, I added a configure-check for the compiler's support of the
>> > optional argument.
>> > And we need to store, which compiler is used to compile Open MPI and
>> > at (user-
>> > app) compile-time again check (within mpi.h), which compiler (and
>> > version!) is
>> > being used.
>> > This is then compared at user-level compile-time.
>> >
>> > To prevent users getting swamped with error msg. this can be turned
>> > off using
>> > the configure-option:
>> > --enable-mpi-interface-warning
>> > which turns on OMPI_WANT_MPI_INTERFACE_WARNING (default: DISabled), as
>> > suggested by Jeff.
>> >
>> > The user can however override that with (check mpi2basic_tests):
>> > mpicc -DOMPI_WANT_MPI_INTERFACE_WARNING -c lalala.c
>> > lots of warnings follow
>> >
>> > Please take a look into:
>> > http://bitbucket.org/jsquyres/ompi-deprecated/
>> >
>> >
>> > With best regards,
>> > Rainer
>> >
>> >
>> > PS:
>> > Also, we need to disable the warning, when building Open MPI
>> > itselve ;-)
>> >
>> > PPS:
>> > Thanks to Paul Hargrove and Dan Bonachea for the GASnet file
>> > portable_platform.h which offers the CPP magic to figure out
>> > compilers and
>> > esp. compiler-versions.
>> > --
>> > ---
>> > ---------------------------------------------------------------------
>> > Rainer Keller, PhD Tel: +1 (865) 241-6293
>> > Oak Ridge National Lab Fax: +1 (865) 241-4811
>> > PO Box 2008 MS 6164 Email: keller_at_[hidden]
>> > Oak Ridge, TN 37831-2008 AIM/Skype: rusraink
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel_at_[hidden]
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> >
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
>

-- 
Paul H. Hargrove                          PHHargrove_at_[hidden]
Future Technologies Group                 Tel: +1-510-495-2352
HPC Research Department                   Fax: +1-510-486-6900
Lawrence Berkeley National Laboratory