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

37 Коммитов

Автор SHA1 Сообщение Дата
Jeff Squyres
520147f209 Clean up the Fortran MPI sentinel values per problem reported on the
users mailing list:

  http://www.open-mpi.org/community/lists/users/2006/07/1680.php

Warning: this log message is not for the weak.  Read at your own
risk.

The problem was that we had several variables in Fortran common blocks
of various types, but their C counterparts were all of a type
equivalent to a fortran double complex.  This didn't seem to matter
for the compilers that we tested, but we never tested static builds
(which is where this problem seems to occur, at least with the Intel
compiler: the linker compilains that the variable in the common block
in the user's .o file was of one size/alignment but the one in the C
library was a different size/alignment).

So this patch fixes the sizes/types of the Fortran common block
variables and their corresponding C instantiations to be of the same
sizes/types. 

But wait, there's more.

We recently introduced a fix for the OSX linker where some C versions
of the fortran common block variables (e.g.,
_ompi_fortran_status_ignore) were not being found when linking
ompi_info (!).  Further research shows that the code path for
ompi_info to require ompi_fortran_status_ignore is, unfortunately,
necessary (a quirk of how various components pull in different
portions of the code base -- nothing in ompi_info itself requires
fortran or MPI knowledge, of course).

Hence, the real problem was that there was no code path from ompi_info
to the portion of the code base where the C globals corresponding to
the Fortran common block variables were instantiated.  This is because
the OSX linker does not automatically pull in .o files that only
contain unintialized global variables; the OSX linker typically only
pulls in a .o file from a library if it either has a function that is
used or have a global variable that is initialized (that's the short
version; lots of details and corner cases omitted).  Hence, we changed
the global C variables corresponding to the fortran common blocks to
be initialized, thereby causing the OSX linker to pull them in
automatically -- problem solved.  At the same time, we moved the
constants to another .c file with a function, just for good measure.

However, this didn't really solve the problem:

1. The function in the file with the C versions of the fortran common
   block variables (ompi/mpi/f77/test_constants_f.c) did not have a
   code path that was reachable from ompi_info, so the only reason
   that the constants were found (on OSX) was because they were
   initialized in the global scope (i.e., causing the OSX compiler to
   pull in that .o file).

2. Initializing these variable in the global scope causes problems for
   some linkers where -- once all the size/type problems mentioned
   above were fixed -- the alignments of fortran common blocks and C
   global variables do not match (even though the types of the Fortran
   and C variables match -- wow!).  Hence, initializing the C
   variables would not necessarily match the alignment of what Fortran
   expected, and the linker would issue a warning (i.e., the alignment
   warnings referenced in the original post).

The solution is two-fold:

1. Move the Fortran variables from test_constants_f.c to
   ompi/mpi/runtime/ompi_mpi_init.c where there are other global
   constants that *are* initialized (that had nothing to do with
   fortran, so the alignment issues described above are not a factor),
   and therefore all linkers (including the OSX linker) will pull in
   this .o file and find all the symbols that it needs.

2. Do not initialize the C variables corresponding to the Fortran
   common blocks in the global scope.  Indeed, never initialize them
   at all (because we never need their *values* - we only check for
   their *locations*).  Since nothing is ever written to these
   variables (particularly in the global scope), the linker does not
   see any alignment differences during initialization, but does make
   both the C and Fortran variables have the same addresses (this
   method has been working in LAM/MPI for over a decade).

There were some comments here in the OMPI code base and in the LAM
code base that stated/implied that C variables corresponding to
Fortran common blocks had to have the same alignment as the Fortran
common blocks (i.e., 16).  There were attempts in both code bases to
ensure that this was true.  However, the attempts were wrong (in both
code bases), and I have now read enough Fortran compiler documentation
to convince myself that matching alignments is not required (indeed,
it's beyond our control).  As long as C variables corresponding to
Fortran common blocks are not initialized in the global scope, the
linker will "figure it out" and adjust the alignment to whatever is
required (i.e., the greater of the alignments).  Specifically (to
counter comments that no longer exist in the OMPI code base but still
exist in the LAM code base):

- there is no need to make attempts to specially align C variables
  corresponding to Fortran common blocks
- the types and sizes of C variables corresponding to Fortran common
  blocks should match, but do not need to be on any particular
  alignment 

Finally, as a side effect of this effort, I found a bunch of
inconsistencies with the intent of status/array_of_statuses
parameters.  For all the functions that I modified they should be
"out" (not inout).

This commit was SVN r11057.
2006-07-31 15:07:09 +00:00
Jeff Squyres
0c102e6e5b Fix OSX linker problems with the Fortran bindings:
- ensure to initialize the values that we use for fortran constants
  (even tough their *values* don't matter -- only their *addresses* do,
  but initializing them or not has implications for the OSX linker)
- move the fortran constants to a file with functions in it, because
  the OSX linker sometimes does not import global variables from
  object files that do not have functions (I'm not even going to
  pretend to get all the subtle details about the OSX linker right
  here -- it's just "better" to have global variables in object files
  with functions that otherwise get pulled in during linker
  resolution).

This commit was SVN r10908.
2006-07-20 19:48:03 +00:00
Brian Barrett
2759212e16 * use LN_S instead of ln -s, in case ln -s doesn't work...
This commit was SVN r10839.
2006-07-15 22:02:19 +00:00
Jeff Squyres
720f38efc5 Fix for MPI_WTICK / MPI_WTIME F90 bindings issue. The previous hope
was that declaring the type of MPI_WTICK and MPI_TIME in mpif-common.h
would allow the F90 bindings to call through to the back end f77
function and have the right return type.  But upon reflection, that's
silly -- we were just declaring the variables MPI_WTICK and MPI_WTIME
that were of type double precision.  Duh.

So add some fixed (non-generated) wrapper F90 functions to call the
back-end *C* MPI_WTICK and MPI_TIME functions (vs. the back end *F77*
functions).  We have to call the back-end C functions because there's
a name conflict if we try to call the back-end F77 functions -- for
the same reasons that we can't "implicitly" define MPI_WTIME and
MPI_WTICK in the f90 module, we can't call such an implicitly-defined
function.  So we had to add new back-end C functions that are directly
callable from Fortran, the easiest implementation of which was to
provide 4 one-line functions for each (rather than muck around with
weak symbols).

This commit was SVN r10448.
2006-06-21 13:44:20 +00:00
Jeff Squyres
87a2458bb1 Make sure to use the C version of the string.
This commit was SVN r9796.
2006-05-03 03:29:06 +00:00
Brian Barrett
1aa13c1e5c * do proper fortran string handling for the MPI-IO functions that take string
arguments.  Thanks to Bernard Knaepen for bringing this to our attention.

This commit was SVN r9792.
2006-05-02 14:39:11 +00:00
Jeff Squyres
f8e634d6ca Bring over /tmp/f90-stuff branch to the trunk.
svn merge -r 9453:9609 https://svn.open-mpi.org/svn/ompi/tmp/f90-stuff .

Several improvements over the current F90 MPI bindings:

- The capability to make 4 sizes of the F90 bindings:
  - trivial: only the F90-specific MPI functions (sizeof and a few
    others)
  - small: (this is the default) all MPI functions that do not take
    choice buffers
  - medium: small + all MPI functions that take one choice buffer
    (e.g., MPI_SEND)
  - large: all MPI functions, but those that take 2 choice buffers
    (e.g., MPI_GATHER) only allow both buffers to be of the same type
- Remove all non-standard MPI types (LOGICAL*x, CHARACTER*x)
- Remove use of selected_*_kind() and only use MPI-defined types
  (INTEGER*x, etc.)
- Decrease complexity of the F90 configure and build system

This commit was SVN r9610.
2006-04-11 03:33:38 +00:00
Edgar Gabriel
073c6e6c32 The f2c interface of these routines have to do proper conversation of
fortran strings to c strings, else the name-publishing and name-lookup
and all subsequent calls (e.g. connect/accept) do not work with fortran.

This commit was SVN r9272.
2006-03-13 22:56:56 +00:00
Edgar Gabriel
be9ea4d1b0 we should pass c_command to MPI_Comm_spawn, and not the fortran version
of the string. Since it is relevant fix, however not affecting any other
part of the source code, should probably still go onto the 1.0 branch.

This commit was SVN r9214.
2006-03-07 23:13:42 +00:00
George Bosilca
bd109c90f5 One of the , was missing.
This commit was SVN r9199.
2006-03-04 17:41:57 +00:00
Jeff Squyres
c31e515db1 Since we've had problems recognizing the "special" Fortran constants,
add an explicit test case that checks for them.  It is necessary to
put this test function here because the OMPI_IS* macros are only
defined in this directory.

This commit was SVN r9195.
2006-03-04 13:23:19 +00:00
Jeff Squyres
adc6753fa9 Check for ARGVS_NULL, not ARGV_NULL
This commit was SVN r9194.
2006-03-04 13:22:12 +00:00
Brian Barrett
566a050c23 Next step in the project split, mainly source code re-arranging
- move files out of toplevel include/ and etc/, moving it into the
    sub-projects
  - rather than including config headers with <project>/include, 
    have them as <project>
  - require all headers to be included with a project prefix, with
    the exception of the config headers ({opal,orte,ompi}_config.h
    mpi.h, and mpif.h)

This commit was SVN r8985.
2006-02-12 01:33:29 +00:00
Brian Barrett
b1d2424013 Merge in present work on the MPI-2 onesided chapter. The current code is not
complete, but stable enough that it will have no impact on general development,
so into the trunk it goes.  Changes in this commit include:

 - Remove the --with option for disabling MPI-2 onesided support.  It
   complicated code, and has no real reason for existing
 - add a framework osc (OneSided Communication) for encapsulating
   all the MPI-2 onesided functionality
 - Modify the MPI interface functions for the MPI-2 onesided chapter
   to properly call the underlying framework and do the required
   error checking
 - Created an osc component pt2pt, which is layered over the BML/BTL
   for communication (although it also uses the PML for long message
   transfers).  Currently, all support functions, all communication
   functions (Put, Get, Accumulate), and the Fence synchronization
   function are implemented.  The PWSC active synchronization
   functions and Lock/Unlock passive synchronization functions are
   still not implemented

This commit was SVN r8836.
2006-01-28 15:38:37 +00:00
Jeff Squyres
ec08143923 Arrgh -- left a debugging printf in by accident.
This commit was SVN r8529.
2005-12-16 21:11:58 +00:00
Jeff Squyres
2bae18fd91 Fix MPI_IN_PLACE handling for Fortran collectives
This commit was SVN r8526.
2005-12-16 19:19:14 +00:00
Rainer Keller
bf0892bb32 - Implement correct Fortran Logical-handling in f77/f90 interface in
case of:
    sizeof(MPI_Flogical) != sizeof (int)
  and
    Fortran value of .TRUE. != 1
  as is often the case.
- Check in configure the value of .TRUE., the C-type coresponding to
  logical and check, that fortran compiler does not do something strange
  with arrays of logicals
- Convert all occurrences of logicals in the fortran wrappers, only
  in case it is needed.
  *Please note* Implementation of MPI_Cart_sub needed special treatment.
- Output these value in ompi_info -a
- Clean up the prototypes_mpi.h to just have a single definition and
  thereby deleting the necessity for prototypes_pmpi.h

- configured, compiled and tested with F90-program, which uses
  MPI_Cart_create and MPI_Cart_get:
  linux ia32, gcc (no testing, as no f90)
  linux ia32, gcc --disable-mpi-f77 --disable-mpi-f90 (had a bug there)
  linux ia32, icc-8.1
  linux opteron, gcc-3.3.5, pgcc, pathccx/pathf90 (tested just
pgi-compiler)
  linux em64t, gcc, icc-8.1 (tested just icc)

This commit was SVN r8254.
2005-11-24 16:52:35 +00:00
Jeff Squyres
6b823e3663 Remove a little extra memory that is no longer needed
This commit was SVN r8246.
2005-11-23 11:16:59 +00:00
Edgar Gabriel
c96e4d43c7 fixes for other routines which take an MPI-2 byte displacement or an address as
an argument.

This commit was SVN r8244.
2005-11-23 03:52:19 +00:00
Edgar Gabriel
a1b00e0a49 fixing the fortran interface for MPI_Get_address. Since the address
argument is defined to be 

integer (KIND=MPI_ADDRESS_KIND)

we have to map that to an MPI_Aint in the f->c interface, else the
typecast back from the C to the Fortran interface will be wrong as well.
The same holds (at least) for all other new MPI-2 datatype functions
which take a byte-displacement or an address as an argument.

This commit was SVN r8243.
2005-11-23 03:22:50 +00:00
Edgar Gabriel
b6ddb73f38 fixing the condition under which the values of the c-functions are
passed back to the fortran routines. Should probably go to v1.0.1, but
is unfortunatly just half of the overall fix. 

This commit was SVN r8242.
2005-11-23 03:12:40 +00:00
Jeff Squyres
6de5c208f2 Fix propblem with prototypes for wtick and wtime in prototypes_pmpi.h.
This commit was SVN r8043.
2005-11-08 19:45:51 +00:00
Jeff Squyres
a1ba3168d9 Remove extrameous comments
This commit was SVN r8017.
2005-11-07 22:44:26 +00:00
George Bosilca
9832d5d883 The OMPI_GENERATE_F77_BINDINGS work only for the most common F77 bindings, the
one that does not return any value. There are 2 exceptions MPI_Wtick and MPI_Wtime.
For these 2 we can insert the bindings manually.

This commit was SVN r8016.
2005-11-07 19:37:32 +00:00
Brian Barrett
28891d6de3 * Move MPI_Wtime and MPI_Wtick back out of mpi.h and into the C bindings library,
restoring the PMPI version.  A variety of reasons for this:

  - mpi.h was blinding using inline in a C header without the configrue mojo
    properly set it, as mpi.h doesn't include ompi_config.h.  This eventually
    would have caused a borked build.
  - mpi.h and mpif.h were never updated to not include PMPI_W{tick,time} as
    a proper prototype
  - The C++ and F90 bindings didn't do the right things when there was no
    PMPI version of the C call, but profiling was enabled
  - Since we only use gettimeofday, the function call overhead really doesn't
    matter

This should probably go to the 1.0 branch

This commit was SVN r8014.
2005-11-07 17:22:48 +00:00
Jeff Squyres
42ec26e640 Update the copyright notices for IU and UTK.
This commit was SVN r7999.
2005-11-05 19:57:48 +00:00
George Bosilca
43e37060a8 Correct a unfortunate typo in the fortran constants ... We still have untested code inside :)
Add a macro to convert from Fortran to C MPI_IN_PLACE.

This commit was SVN r7276.
2005-09-09 20:46:47 +00:00
George Bosilca
56f8607439 Adding MPI_IN_PLACE for both languages C and Fortran. Still working on the C++ and maybe F90 stuff. It's easilly
getting ugly ...

This commit was SVN r7275.
2005-09-09 20:44:04 +00:00
Brian Barrett
ed56e743b7 * update configure.ac to use the modern version of AC_INIT and
AM_INIT_AUTOMAKE, instead of the deprecated version.
* Work around dumbness in modern AC_INIT that requires the version
  number to be set at autoconf time (instead of at configure time, as
  it was before).  Set the version number, minus the subversion r number,
  at autoconf time.  Override the internal variables to include the r
  number (if needed) at configure time.  Basically, the right thing
  should always happen.  The only place it might not is the version
  reported as part of configure --help will not have an r number.
* Since AM_INIT_AUTOMAKE taks a list of options, no need to specify
  them in all the Makefile.am files.
* Addes support for subdir-objects, meaning that object files are put
  in the directory containing source files, even if the Makefile.am is
  in another directory.  This should start making it feasible to
  reduce the number of Makefile.am files we have in the tree, which
  will greatly reduce the time to run autogen and configure.

This commit was SVN r7211.
2005-09-07 05:54:53 +00:00
Jeff Squyres
85859af77b Fix compiler warnings
This commit was SVN r7000.
2005-08-24 10:46:44 +00:00
Jeff Squyres
cf16a521c8 Ensure to get ompi/include/constants.h
This commit was SVN r6845.
2005-08-12 21:42:07 +00:00
Edgar Gabriel
213be28613 minor fixes to make the trunk compile, if ompi has been configured with the --enable-mpi2-one-sided option
This commit was SVN r6518.
2005-07-15 13:53:10 +00:00
Brian Barrett
9f44b80291 * rename ompi_argv to opal_argv
* rename ompi_basename to opal_basename
* rename ompi bitop functions to opal
* rename ompi_cmd_line to opal_cmd_line
* rename ompi_sizet2int to opal_sizet2int
* rename orte_daemon_init to opal_daemon_init
* rename ompi_few to opal_few

This commit was SVN r6330.
2005-07-04 00:13:44 +00:00
Jeff Squyres
35c141aef6 While we're moving directories around, move ompi/mpi/runtime ->
ompi/runtime, for consistency and parallel-ness will orte/runtime.
Also remove a few useless #includes along the way.

This commit was SVN r6317.
2005-07-03 12:07:29 +00:00
Brian Barrett
e984f48ad9 * add missing Makefile to configure output
* Fix MPI profiling layer symlink code from src -> ompi
* Change some modex includes

This commit was SVN r6309.
2005-07-02 17:32:01 +00:00
Jeff Squyres
aa056f7bfd First cut of OMPI Makefile.am's, plus a few more catchup updates in orte
This commit was SVN r6286.
2005-07-02 15:06:47 +00:00
Jeff Squyres
4ab17f019b Rename src -> ompi
This commit was SVN r6269.
2005-07-02 13:43:57 +00:00