Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

Thanks for the heads up.  Fixed -- sorry about that.


> On Jul 4, 2015, at 12:11 PM, George Bosilca  wrote:
> 
> On OS X the generating the MPI library fails with the following error message:
> 
> duplicate symbol _ompi_buffer_detach_f08 in:
> .libs/buffer_detach_f.o
> profile/.libs/libmpi_mpifh_pmpi.a(pbuffer_detach_f.o)
> ld: 1 duplicate symbol for architecture x86_64
> 
> I came up with the following patch, but I'm not sure this is the real fix. It 
> does fix the issue in my particular configuration.
> 
> diff --git a/ompi/mpi/fortran/mpif-h/buffer_detach_f.c 
> b/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
> index e2114d7..5d2c530 100644
> --- a/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
> +++ b/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
> @@ -88,6 +88,7 @@ void ompi_buffer_detach_f(char *buffer, MPI_Fint *size, 
> MPI_Fint *ierr)
>  }
>  }
> 
> +#if !OMPI_PROFILE_LAYER
>  /*
>   * Per above, this is the mpi_f08 module implementation of
>   * MPI_BUFFER_DETACH.  It handles the buffer arugment just like the C
> @@ -107,3 +108,4 @@ void ompi_buffer_detach_f08(char *buffer, MPI_Fint *size, 
> MPI_Fint *ierr)
>  OMPI_SINGLE_INT_2_FINT(size);
>  }
>  }
> +#endif  /* !OMPI_PROFILE_LAYER */ 
> 
> George.
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/07/17594.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] Fortran issue

[George Bosilca]

On OS X the generating the MPI library fails with the following error
message:

duplicate symbol _ompi_buffer_detach_f08 in:
.libs/buffer_detach_f.o
profile/.libs/libmpi_mpifh_pmpi.a(pbuffer_detach_f.o)
ld: 1 duplicate symbol for architecture x86_64

I came up with the following patch, but I'm not sure this is the real fix.
It does fix the issue in my particular configuration.

diff --git a/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
b/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
index e2114d7..5d2c530 100644
--- a/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
+++ b/ompi/mpi/fortran/mpif-h/buffer_detach_f.c
@@ -88,6 +88,7 @@ void ompi_buffer_detach_f(char *buffer, MPI_Fint *size,
MPI_Fint *ierr)
 }
 }

+#if !OMPI_PROFILE_LAYER
 /*
  * Per above, this is the mpi_f08 module implementation of
  * MPI_BUFFER_DETACH.  It handles the buffer arugment just like the C
@@ -107,3 +108,4 @@ void ompi_buffer_detach_f08(char *buffer, MPI_Fint
*size, MPI_Fint *ierr)
 OMPI_SINGLE_INT_2_FINT(size);
 }
 }
+#endif  /* !OMPI_PROFILE_LAYER */

George.

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

Thankfully, I didn't understand it.  :-)

> On Feb 20, 2015, at 2:49 PM, Paul Hargrove  wrote:
> 
> 
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
> 
> If you can understand that, you should probably pretend you can't :-)
> 
> -Paul [who has actually used Computed GO TO and Arithmetic IF]
> 
> On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker  wrote:
> Excellent, Mr. Fortran.  Thank you.
> 
> By the way, I meant to write Branch ON Low Bit Set/Clear.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
> On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
> 
>> On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
>>> 
>>> Beware, this has/may not always be the case.  This is due to C's historical 
>>> confusion/misuse of integers as boolean data types.  On VAX hardware, the 
>>> low bit was the only significant part of a Fortran LOGICAL data type, owing 
>>> to the architectural support (Branch of Low Bit Set/Clear) for the low bit 
>>> in a status word meaning success/failure.  I doubt anyone uses VAXes and 
>>> MPI, so this is not likely to cause users problems.
>> 
>> Note that this comment was referring to two things:
>> 
>> 1. 0/1 array index issues
>> 2. .true./.false. issues
>> 
>> We actually check for the value of .true. in configure, and use that 
>> everywhere.  I believe this particular portion of the code simply looks for 
>> .false.==(C int)0, and .true. is anything else.  That was deemed good enough 
>> because this portion of the code is simply *checking* for true/false.  Where 
>> we *assign* true/false in the Fortran boolean sense, we use the value 
>> determined by configure.
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/02/17012.php
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17013.php
> 
> 
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Computer Languages & Systems Software (CLaSS) Group
> Computer Science Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17014.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[Larry Baker]

Good grins.  Thanks Paul.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



On 20 Feb 2015, at 11:49 AM, Paul Hargrove wrote:

> 
>INTEGER JEFF(3)
>DATA JEFF/4HMR. ,4HFORT,3HRAN/
> 
> If you can understand that, you should probably pretend you can't :-)
> 
> -Paul [who has actually used Computed GO TO and Arithmetic IF]
> 
> On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker  wrote:
> Excellent, Mr. Fortran.  Thank you.
> 
> By the way, I meant to write Branch ON Low Bit Set/Clear.
> 
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
> 
> 
> 
> On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
> 
>> On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
>>> 
>>> Beware, this has/may not always be the case.  This is due to C's historical 
>>> confusion/misuse of integers as boolean data types.  On VAX hardware, the 
>>> low bit was the only significant part of a Fortran LOGICAL data type, owing 
>>> to the architectural support (Branch of Low Bit Set/Clear) for the low bit 
>>> in a status word meaning success/failure.  I doubt anyone uses VAXes and 
>>> MPI, so this is not likely to cause users problems.
>> 
>> Note that this comment was referring to two things:
>> 
>> 1. 0/1 array index issues
>> 2. .true./.false. issues
>> 
>> We actually check for the value of .true. in configure, and use that 
>> everywhere.  I believe this particular portion of the code simply looks for 
>> .false.==(C int)0, and .true. is anything else.  That was deemed good enough 
>> because this portion of the code is simply *checking* for true/false.  Where 
>> we *assign* true/false in the Fortran boolean sense, we use the value 
>> determined by configure.
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/02/17012.php
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17013.php
> 
> 
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Computer Languages & Systems Software (CLaSS) Group
> Computer Science Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17014.php

Re: [OMPI devel] Fortran issue

[Paul Hargrove]

   INTEGER JEFF(3)
   DATA JEFF/4HMR. ,4HFORT,3HRAN/

If you can understand that, you should probably pretend you can't :-)

-Paul [who has actually used Computed GO TO and Arithmetic IF]

On Fri, Feb 20, 2015 at 11:28 AM, Larry Baker  wrote:

> Excellent, Mr. Fortran.  Thank you.
>
> By the way, I meant to write Branch ON Low Bit Set/Clear.
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
>
>
> On 20 Feb 2015, at 11:22 AM, Jeff Squyres (jsquyres) wrote:
>
> On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
>
>
> Beware, this has/may not always be the case.  This is due to C's
> historical confusion/misuse of integers as boolean data types.  On VAX
> hardware, the low bit was the only significant part of a Fortran LOGICAL
> data type, owing to the architectural support (Branch of Low Bit Set/Clear)
> for the low bit in a status word meaning success/failure.  I doubt anyone
> uses VAXes and MPI, so this is not likely to cause users problems.
>
>
> Note that this comment was referring to two things:
>
> 1. 0/1 array index issues
> 2. .true./.false. issues
>
> We actually check for the value of .true. in configure, and use that
> everywhere.  I believe this particular portion of the code simply looks for
> .false.==(C int)0, and .true. is anything else.  That was deemed good
> enough because this portion of the code is simply *checking* for
> true/false.  Where we *assign* true/false in the Fortran boolean sense, we
> use the value determined by configure.
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17012.php
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17013.php
>



-- 
Paul H. Hargrove  phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

On Feb 20, 2015, at 2:12 PM, Larry Baker  wrote:
> 
> Beware, this has/may not always be the case.  This is due to C's historical 
> confusion/misuse of integers as boolean data types.  On VAX hardware, the low 
> bit was the only significant part of a Fortran LOGICAL data type, owing to 
> the architectural support (Branch of Low Bit Set/Clear) for the low bit in a 
> status word meaning success/failure.  I doubt anyone uses VAXes and MPI, so 
> this is not likely to cause users problems.

Note that this comment was referring to two things:

1. 0/1 array index issues
2. .true./.false. issues

We actually check for the value of .true. in configure, and use that 
everywhere.  I believe this particular portion of the code simply looks for 
.false.==(C int)0, and .true. is anything else.  That was deemed good enough 
because this portion of the code is simply *checking* for true/false.  Where we 
*assign* true/false in the Fortran boolean sense, we use the value determined 
by configure.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[Larry Baker]

On 20 Feb 2015, at 3:09 AM, Gilles Gouaillardet wrote:

> George,
> 
> this is correctly handled in ompi_testany_f :
> 
> /* Increment index by one for fortran conventions.  Note that
>all Fortran compilers have FALSE==0; we just need to check
>for any nonzero value (because TRUE is not always 1) */
> 
> Cheers,
> 
> Gilles


Beware, this has/may not always be the case.  This is due to C's historical 
confusion/misuse of integers as boolean data types.  On VAX hardware, the low 
bit was the only significant part of a Fortran LOGICAL data type, owing to the 
architectural support (Branch of Low Bit Set/Clear) for the low bit in a status 
word meaning success/failure.  I doubt anyone uses VAXes and MPI, so this is 
not likely to cause users problems.

See http://h71000.www7.hp.com/doc/82final/6443/6443pro_026.html:

> 8.3 Logical Data Representations
> 
> Logical data can be one, two, four, or eight bytes in length.
> 
> The default size used for a LOGICAL data declaration without a kind parameter 
> (or size specifier) is LOGICAL (KIND=4) (same as LOGICAL*4), unless you do 
> one of the following:
> 
>   • Explicitly declare the length of a LOGICAL declaration by using a 
> kind parameter, such as LOGICAL (KIND=4). HP Fortran provides intrinsic 
> LOGICAL kinds of 1, 2, 4, and 8. Each LOGICAL kind number corresponds to 
> number of bytes used by that intrinsic representation. 
> You can also use a size specifier, such as LOGICAL*4, but be aware this is an 
> extension to the Fortran 90 standard.
> 
>   • Use the FORTRAN command /INTEGER_SIZE=nn qualifier to control the 
> size of default (without a kind parameter or size specifier) LOGICAL and 
> INTEGER declarations (see Section 2.3.26).
> To improve performance, avoid using 2-byte or 1-byte logical declarations 
> (see Chapter 5).
> 
> Intrinsic LOGICAL*1 or LOGICAL (KIND=1) values are stored in a single byte.
> 
> Logical (intrinsic) values can also be stored in the following sizes of 
> contiguous bytes starting on an arbitrary byte boundary:
> 
>   • Two bytes (LOGICAL (KIND=2) or LOGICAL*2)
>   • Four bytes (LOGICAL (KIND=4) or LOGICAL*4)
>   • Eight bytes (LOGICAL (KIND=8) or LOGICAL*8)
> 
> The low-order bit determines whether the logical value is true or false. 
> Logical variables can also be interpreted as integer data (an extension to 
> the Fortran 90 standard). For example, in addition to having logical values 
> .TRUE. and .FALSE., LOGICAL*1 data can also have values in the range --128 to 
> 127.
> 
> LOGICAL*1, LOGICAL*2, LOGICAL*4, and LOGICAL*8 data representations appear in 
> Figure 8-5.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

On Feb 20, 2015, at 10:01 AM, George Bosilca  wrote:
> 
> Great. Using grep I couldn't find how this is handled anywhere in the source 
> directory. But it seems to me that the Fortran layer is now way more 
> complicated than I initially thought.

Fortran is your friend.
(repeat until you believe it)

FWIW, that increment has been there since the very beginning.  So this 
particular aspect is nothing new.

But there are other aspects of the Fortran layer that are more complicated than 
I wish they were.  Honestly, if I could dedicate a week, I would love to re-do 
the Fortran layer from scratch and generate (almost) all the Fortran code based 
on the results of compiler tests from configure.  I.e., we already have a fixed 
set of the Fortran API prototypes; we already generate all the relevant Fortran 
header files from it.  It would be great to generate (almost) all the relevant 
Fortran function definitions from it, too.  That would eliminate a LOT of the 
complexity in our Fortran bindings implementation.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[George Bosilca]

Great. Using grep I couldn't find how this is handled anywhere in the
source directory. But it seems to me that the Fortran layer is now way more
complicated than I initially thought.

  George.


On Fri, Feb 20, 2015 at 8:27 AM, Jeff Squyres (jsquyres)  wrote:

> Gilles is correct.  The same kind of increment happens in all the
> test/wait Fortran code that returns indexes.
>
> "Mr. Fortran"?  Ouch.  :-)
>
>
> > On Feb 20, 2015, at 6:09 AM, Gilles Gouaillardet <
> gilles.gouaillar...@iferc.org> wrote:
> >
> > George,
> >
> > this is correctly handled in ompi_testany_f :
> >
> > /* Increment index by one for fortran conventions.  Note that
> >all Fortran compilers have FALSE==0; we just need to check
> >for any nonzero value (because TRUE is not always 1) */
> >
> > Cheers,
> >
> > Gilles
> >
> > On 2015/02/20 1:15, George Bosilca wrote:
> >> While looking the MPI_Testany issue, I came across a very unsettling
> >> sentence in the MPI standard (3.0 page 58 line 36).
> >>
> >>
> >>> The array is indexed from zero in C, and from one in Fortran.
> >>>
> >> This sentence seems to indicate that the index returned by the TestAny
> and
> >> TestSome (as well as the corresponding Wait functions) should be indexed
> >> starting from 1 in Fortran, but from 0 in C. Our C code returns all
> indexes
> >> starting from 0 (C), but I failed to find where we handle this case in
> >> Fortran? Or maybe I am interpreting too much the MPI standard?
> >>
> >>   George.
> >>
> >>
> >>
> >>
> >> ___
> >> devel mailing list
> >>
> >> de...@open-mpi.org
> >>
> >> Subscription:
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >>
> >> Link to this post:
> >> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php
> >
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17005.php
>
>
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17006.php
>

Re: [OMPI devel] Fortran issue

[Jeff Squyres (jsquyres)]

Gilles is correct.  The same kind of increment happens in all the test/wait 
Fortran code that returns indexes.

"Mr. Fortran"?  Ouch.  :-)


> On Feb 20, 2015, at 6:09 AM, Gilles Gouaillardet 
>  wrote:
> 
> George,
> 
> this is correctly handled in ompi_testany_f :
> 
> /* Increment index by one for fortran conventions.  Note that
>all Fortran compilers have FALSE==0; we just need to check
>for any nonzero value (because TRUE is not always 1) */
> 
> Cheers,
> 
> Gilles
> 
> On 2015/02/20 1:15, George Bosilca wrote:
>> While looking the MPI_Testany issue, I came across a very unsettling
>> sentence in the MPI standard (3.0 page 58 line 36).
>> 
>> 
>>> The array is indexed from zero in C, and from one in Fortran.
>>> 
>> This sentence seems to indicate that the index returned by the TestAny and
>> TestSome (as well as the corresponding Wait functions) should be indexed
>> starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes
>> starting from 0 (C), but I failed to find where we handle this case in
>> Fortran? Or maybe I am interpreting too much the MPI standard?
>> 
>>   George.
>> 
>> 
>> 
>> 
>> ___
>> devel mailing list
>> 
>> de...@open-mpi.org
>> 
>> Subscription: 
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> 
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/17005.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Fortran issue

[Gilles Gouaillardet]

George,

this is correctly handled in ompi_testany_f :

/* Increment index by one for fortran conventions.  Note that
   all Fortran compilers have FALSE==0; we just need to check
   for any nonzero value (because TRUE is not always 1) */

Cheers,

Gilles

On 2015/02/20 1:15, George Bosilca wrote:
> While looking the MPI_Testany issue, I came across a very unsettling
> sentence in the MPI standard (3.0 page 58 line 36).
>
>> The array is indexed from zero in C, and from one in Fortran.
> This sentence seems to indicate that the index returned by the TestAny and
> TestSome (as well as the corresponding Wait functions) should be indexed
> starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes
> starting from 0 (C), but I failed to find where we handle this case in
> Fortran? Or maybe I am interpreting too much the MPI standard?
>
>   George.
>
>
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/02/16994.php

Re: [OMPI devel] Fortran issue

[George Bosilca]

Sorry but I miss the connection between this test and the issue of TestAny
in Fortran?


On Thu, Feb 19, 2015 at 2:00 PM, Dave Goodell (dgoodell)  wrote:

> On Feb 19, 2015, at 10:15 AM, George Bosilca  wrote:
>
> > While looking the MPI_Testany issue, I came across a very unsettling
> sentence in the MPI standard (3.0 page 58 line 36).
> >
> > > The array is indexed from zero in C, and from one in Fortran.
> >
> > This sentence seems to indicate that the index returned by the TestAny
> and TestSome (as well as the corresponding Wait functions) should be
> indexed starting from 1 in Fortran, but from 0 in C. Our C code returns all
> indexes starting from 0 (C), but I failed to find where we handle this case
> in Fortran? Or maybe I am interpreting too much the MPI standard?
>
> Jeff is Mr. Fortran, so I'll let him answer more definitely, but in the
> meantime you could try running this test from the MPICH test suite:
>
> http://git.mpich.org/mpich.git/blob/v3.0:/test/mpi/f77/pt2pt/allpairf.f
>
> Surely there must be a test in ompi-tests that covers this area too.
>
> -Dave
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/02/17001.php
>

Re: [OMPI devel] Fortran issue

[Dave Goodell (dgoodell)]

On Feb 19, 2015, at 10:15 AM, George Bosilca  wrote:

> While looking the MPI_Testany issue, I came across a very unsettling sentence 
> in the MPI standard (3.0 page 58 line 36).
> 
> > The array is indexed from zero in C, and from one in Fortran.
> 
> This sentence seems to indicate that the index returned by the TestAny and 
> TestSome (as well as the corresponding Wait functions) should be indexed 
> starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes 
> starting from 0 (C), but I failed to find where we handle this case in 
> Fortran? Or maybe I am interpreting too much the MPI standard?

Jeff is Mr. Fortran, so I'll let him answer more definitely, but in the 
meantime you could try running this test from the MPICH test suite:

http://git.mpich.org/mpich.git/blob/v3.0:/test/mpi/f77/pt2pt/allpairf.f

Surely there must be a test in ompi-tests that covers this area too.

-Dave

[OMPI devel] Fortran issue

[George Bosilca]

While looking the MPI_Testany issue, I came across a very unsettling
sentence in the MPI standard (3.0 page 58 line 36).

> The array is indexed from zero in C, and from one in Fortran.

This sentence seems to indicate that the index returned by the TestAny and
TestSome (as well as the corresponding Wait functions) should be indexed
starting from 1 in Fortran, but from 0 in C. Our C code returns all indexes
starting from 0 (C), but I failed to find where we handle this case in
Fortran? Or maybe I am interpreting too much the MPI standard?

  George.