Agreed!
On 04/15/2016 11:46 PM, Jeff Squyres (jsquyres) wrote:
> All sounds like good reasons to amend the Bull test suite to no longer check
> for character and logical. :-)
>
>
>> On Apr 15, 2016, at 5:38 PM, Larry Baker <ba...@usgs.gov> wrote:
>>
>> I also remember reading in the past about problems with C sizeof and
>> multibyte characters. I just looked over the C90 standard. In C90 code,
>> the sizeof operator returns size_t in bytes. Except that it always returns
>> 1 for char, signed char, or unsigned char. For an array, C90 says sizeof
>> returns the number of bytes. I interpret this to mean that when the
>> execution character set is a 16-bit multibyte character set, sizeof a char
>> is 1, while sizeof a char[1] is 2. I've never actually tested this.
>>
>> Any programs that marshall character strings for interchange have to be
>> quite specific, I think, in the character set being exchanged. I don't
>> think MPI SIZEOF has a way to know or specify the semantics of the character
>> set.
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> ba...@usgs.gov
>>
>>
>>
>> On 15 Apr 2016, at 2:23 PM, Larry Baker wrote:
>>
>>> Be careful what you wish for.
>>>
>>> I remember looking at this issue a while ago, but I can't remember why or
>>> how I ran into it. I do remember convincing myself that the MPI standard
>>> was correct in restricting SIZEOF to numeric types. For one thing, a
>>> character variable type is a string container in Fortran, while in C it is
>>> a single character. What would be the correct interpretation for SIZEOF in
>>> Fortran? The maximum length? The TRIM'd length? What would be the
>>> correct interpretation in C? 1? strlen()? strlen()+1? The size of a
>>> character itself may not be the same on either end of an MPI connection if,
>>> for example, one program is compiled using 8-bit characters and the other
>>> is compiled using uses 16-bit characters. Interchanging strings opens up a
>>> can of worms. As far as logical, there is no C logical type. In Fortran,
>>> while the size of a logical variable is specified as a "storage unit" (the
>>> same as an integer), the representation of true and false is unspecified,
>>> and, thus, is processor dep
> endent. On VAXes, only a single bit matters; the instruction set supports
> this logical data type. (In C, thought there is no logical data type, the C
> standard does specify 0=false and 1=true for the result of relational and
> logical operators and 0=false and not 0=true for logical operator operands.)
> This means it is problematic to exchange logical data between Fortran
> programs (C makes no sense, since there is no logical data type) when
> different compilers (part of what Fortran calls a processor) are used.
>>>
>>> Better to find out what discussions took place in the MPI standards
>>> committee before adding extensions to SIZEOF. They may very well have good
>>> reasons to avoid character and logical data, as I concluded.
>>>
>>> Larry Baker
>>> US Geological Survey
>>> 650-329-5608
>>> ba...@usgs.gov
>>>
>>>
>>>
>>> On 15 Apr 2016, at 5:34 AM, Jeff Squyres (jsquyres) wrote:
>>>
>>>> Nadia --
>>>>
>>>> I believe that the character and logical types are not in this script
>>>> already because the description of MPI_SIZEOF in MPI-3.1 says that the
>>>> input choice buffer parameter is:
>>>>
>>>> IN x a Fortran variable of numeric intrinsic type (choice)
>>>>
>>>> As I understand it (and my usual disclaimer here: I am *not* a Fortran
>>>> expert), CHARACTER and LOGICAL types are not numeric in Fortran.
>>>>
>>>> However, we could add such interfaces as an extension.
>>>>
>>>> I just checked MPICH 3.2, and they *do* include MPI_SIZEOF interfaces for
>>>> CHARACTER and LOGICAL, but they are missing many of the other MPI_SIZEOF
>>>> interfaces that we have in OMPI. Meaning: OMPI and MPICH already diverge
>>>> wildly on MPI_SIZEOF. :-\
>>>>
>>>> I guess I don't have a strong opinion here. If you file a PR for this
>>>> patch, I won't object. :-)
>>>>
>>>>
>>>>> On Apr 15, 2016, at 3:22 AM, DERBEY, NADIA <nadia.der...@atos.net> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> The following trivial example doesn't compile because of 2 missing types
>>>>> in the MPI_SIZEOF subroutines (in mpi_sizeof.f90).
>>>>>
>>>>> [derbeyn@btp0 test]$ cat mpi_sizeof.f90
>>>>> program main
>>>>> ! use mpi
>>>>> include 'mpif.h'
>>>>>
>>>>> integer ierr, sz, mpisize
>>>>> real r1
>>>>> integer i1
>>>>> character ch1
>>>>> logical l1
>>>>>
>>>>> call MPI_INIT(ierr)
>>>>> call MPI_SIZEOF(r1, sz, ierr)
>>>>> call MPI_SIZEOF(i1, sz, ierr)
>>>>> call MPI_SIZEOF(l1, sz, ierr)
>>>>> call MPI_SIZEOF(ch1, sz, ierr)
>>>>> call MPI_FINALIZE(ierr)
>>>>>
>>>>> end
>>>>> [derbeyn@btp0 test]$ mpif90 -o mpi_sizeof mpi_sizeof.f90
>>>>> mpi_sizeof.f90(14): error #6285: There is no matching specific
>>>>> subroutine for this generic subroutine call. [MPI_SIZEOF]
>>>>> call MPI_SIZEOF(ch1, sz, ierr)
>>>>> -------------^
>>>>> mpi_sizeof.f90(15): error #6285: There is no matching specific
>>>>> subroutine for this generic subroutine call. [MPI_SIZEOF]
>>>>> call MPI_SIZEOF(l1, sz, ierr)
>>>>> -------------^
>>>>> compilation aborted for mpi_sizeof.f90 (code 1)
>>>>>
>>>>>
>>>>> This problem happens both on master and v2.x. The following patch seems
>>>>> to solve the issue:
>>>>>
>>>>> diff --git a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
>>>>> b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
>>>>> index 5ea3dca3..a2a99924 100755
>>>>> --- a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
>>>>> +++ b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
>>>>> @@ -145,6 +145,9 @@ sub generate {
>>>>> # Main
>>>>>
>>>>> #############################################################################
>>>>>
>>>>> +queue_sub("character", "char", "character_kinds");
>>>>> +queue_sub("logical", "logical", "logical_kinds");
>>>>> +
>>>>> for my $size (qw/8 16 32 64/) {
>>>>> queue_sub("integer(int${size})", "int${size}", "int${size}");
>>>>> }
>>>>>
>>>>> Regards,
>>>>> Nadia
>>>>>
>>>>> --
>>>>> Nadia Derbey - B1-387
>>>>> HPC R&D - MPI
>>>>> Tel: +33 4 76 29 77 62
>>>>> nadia.der...@atos.net
>>>>> 1 Rue de Provence BP 208
>>>>> 38130 Echirolles Cedex, France
>>>>> www.atos.com
>>>>> _______________________________________________
>>>>> 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/2016/04/18765.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/2016/04/18766.php
>>>
>>
>
>
--
Nadia Derbey - B1-387
HPC R&D - MPI
Tel: +33 4 76 29 77 62
nadia.der...@atos.net
1 Rue de Provence BP 208
38130 Echirolles Cedex, France
www.atos.com
