1
1
Граф коммитов

10 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
5f17bc3c2c Make the use of PROTECTED in the mpi_f08 module be optional.
Add a configure test to see if the Fortran compiler supports the
PROTECTED keyword.  If it does, use in mpi-f08-types.F90 (via a macro
defined in configure-fortran-output-bottom.h).

This is needed to support the PGI 9 Fortran compiler, which does not
support the PROTECTED keyword.

Note that regardless of whether we want to support the PGI 9 Fortran
compiler + mpi_f08, we need to correctly detect whether PROTECTED
works or not, and then use that determination as a criteria for
building the mpi_f08 module.  Previously, mpi-f08-types.F90 used
PROTECTED unconditionally, and we didn't test for it in configure.  So
if a compiler (e.g., PGI 9) supported everything else but didn't
support PROTECTED, it would try to compile the mpi_f08 stuff and choke
on the use of PROTECTED.

Refs trac:4093

This commit was SVN r30273.

The following Trac tickets were found above:
  Ticket 4093 --> https://svn.open-mpi.org/trac/ompi/ticket/4093
2014-01-13 18:35:42 +00:00
Jeff Squyres
cc4440147f Fix typos in Fortran configury: ensure to call the right m4 macros!
Refs trac:4093

This commit was SVN r30258.

The following Trac tickets were found above:
  Ticket 4093 --> https://svn.open-mpi.org/trac/ompi/ticket/4093
2014-01-11 14:34:53 +00:00
Jeff Squyres
b0ffdb3ae5 As noted by Paul Hargrove, older PGI compilers support ''some'' of
BIND(C), but not ''all'' of it.  So expand our configure checks to
look for multiple different forms of BIND(C):

 * ISO_C_BINDING
 * SUBROUTINE ... BIND(C)
 * TYPE, BIND(C)
 * TYPE(foo), BIND(C, name="bar")

If the compiler supports all of these, then declare that we support
BIND(C), and the rest of the mpi_f08 checks can continue.  If we miss
any one of those, don't bother continuing -- we won't build the
mpi_f08 module.

Also push the results of all of these tests down to ompi_info so that
they can be reported easily (e.g., "Hey, why doesn't my OMPI
installation have the mpi_f08 module?").

cmr=v1.7.4:reviewer=jsquyres:subject=Expand Fortran BIND(C) configure checks

This commit was SVN r30247.
2014-01-10 23:44:55 +00:00
Jeff Squyres
52b5e17d97 Eliminate some dead Fortran configury (these values are not used any
more).

cmr=v1.7.5:reviewer=dgoodell

This commit was SVN r30151.
2014-01-08 03:19:58 +00:00
Jeff Squyres
cc7e121b1c Per thread starting here:
http://www.open-mpi.org/community/lists/users/2013/10/22882.php, fix
the value of MPI_STATUS_SIZE for the -i8 case.  Thanks to Jim Parker
for bringing up the issue and providing the patch.

Separate patches are required for v1.6 and v1.7 (and will be attached
to their respective tickets), because this breaks ABI, so we need a
non-default configure option to fix the issue but knowingly break ABI.

cmr=v1.7.4:reviewer=bosilca:subject=Fix MPI_STATUS_SIZE for -i8 case
cmr=v1.6.6:reviewer=bosilca:subject=Fix MPI_STATUS_SIZE for -i8 case

This commit was SVN r29858.
2013-12-11 17:47:54 +00:00
Nathan Hjelm
c6e586a81d MPI-3: fortran support for large counts using derived datatypes
Jeff:
 - Make sure not to go over 72 characters.  Love Fortran!
 - Ensure to include 'mpif-config.h' in Type_size_x.

This commit was SVN r28933.
2013-07-23 15:36:03 +00:00
Jeff Squyres
7136dbb5b3 Fixes trac:3523. Discussed on the OMPI weekely teleconf today: add a
configure test to ensure that the Fortran compiler supports BIND(C)
with LOGICAL parameters (per
http://lists.mpi-forum.org/mpi-comments/2013/02/0076.php).

This may become moot shortly -- Pathscale tells me that they intend
upgrade their compiler to support BIND(C) with default LOGICAL in the
very near term (this week?).  But we still want this configure test so
that Open MPI won't even try to build the F08 bindings with older
versions of the Pathscale compilers (or any compiler that doesn't
support BIND(C) and LOGICAL parameters).

This commit was SVN r28110.

The following Trac tickets were found above:
  Ticket 3523 --> https://svn.open-mpi.org/trac/ompi/ticket/3523
2013-02-26 17:11:11 +00:00
Jeff Squyres
d65194a97d Fixes trac:3442: ensure that we don't call "basename" on an empty string.
cmr:v1.7

This commit was SVN r27925.

The following Trac tickets were found above:
  Ticket 3442 --> https://svn.open-mpi.org/trac/ompi/ticket/3442
2013-01-26 14:46:08 +00:00
Jeff Squyres
6d3f566f11 This PUSH is never POP'ed. And we don't want this variable to
disappear, anyway.

This commit was SVN r27913.
2013-01-25 22:15:11 +00:00
Jeff Squyres
b29b852281 Consolidate all the opal/orte/ompi .m4 files back to the top-level
config/ directory.  We split them apart a while ago in the hopes that
it would simplify things, but it didn't really (e.g., because there
were still some ompi/opal .m4 files in the top-level config/
directory, resulting in developer confusion where any given m4 macro
was defined).

So this commit consolidates them back into the top-level directory for
simplicity.  

There's still (at least) two changes that would be nice to make:

 1. Split any generated .m4 file (e.g., autogen-generated .m4 files)
    into a separate directory somewhere so that a top-level -Iconfig/
    will only get our explicitly defined macros, not the autogen stuff
    (e.g., with libevent2019 needing to get the visibility macro, but
    NOT all the autogen-generated inclusion of component configure.m4
    files).
 1. Change configure to be of the form:
{{{
# ...a small amount of preamble/setup...
OPAL_SETUP
m4_ifdef([project_orte], [ORTE_SETUP])
m4_ifdef([project_ompi], [OMPI_SETUP])
# ...a small amount of finishing stuff...
}}}

I doubt we'll ever get anything as clean as that, but that would be
the goal to shoot for.

This commit was SVN r27704.
2012-12-19 00:00:36 +00:00