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 dependent. 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
>
