[J3] [SC22WG5.6538] question about storage sequences and default kind modification

[Jeff Hammond]

I agree with you and Bill that these options are awful and there are better solutions but MPI doesn’t have the luxury of breaking legacy HPC codes. All I can do is minimize the risk. 

Jeff

> 
> On Feb 1, 2024, at 20:35, Steven G. Kargl <kargl at uw.edu> wrote:
> 
> External email: Use caution opening links or attachments
> 
> 
> Jeff,
> 
> Having dealt with many bugs reports about gfortran's
> -fdefault-*, -freal-*, and -finteger-* options, I'll
> suggest that you may not want to go down the route of
> supporting users redefining storage association.
> Consider the following with gfortran on an AMD64 system,
> 
>   program foo
>   real dr              ! Default real
>   double precision dd  ! Default double precision
>   real(4)  sp          ! gfortran kind=4 (single precision )
>   real(8)  dp          ! gfortran kind=8 (double precision)
>   real(10) xp          ! gfortran kind=10 (Intel 80-bit extended DP)
>   real(16) qp          ! gfortran kind=16 (quad precision)
> 
>   print '(A,*(1X,I0))', 'Default:', &
>   &  storage_size(dr), storage_size(dd)
>   print '(A,*(1X,I0))', '  Kinds:', &
>   &  storage_size(sp), storage_size(dp), storage_size(xp), storage_size(qp)
>   end program foo
> 
> % gfortran13 -o z a.f90 && ./z
> Default: 32 64
>  Kinds: 32 64 128 128
> 
> % gfortran13 -o z -fdefault-real-8 a.f90 && ./z
> Default: 64 128
>  Kinds: 32 64 128 128
> 
> Default REAL is now 8 bytes and default DOUBLE PRECISION
> is 16 bytes.  The entities declared via KIND= are unchanged.
> 
> % gfortran13 -o z -freal-4-real-8 a.f90 && ./z
> Default: 64 64
>  Kinds: 64 64 128 128
> 
> All entities that map to a 4-byte real are promoted to
> an 8-byte real.
> 
> --
> steve
> 
> 
>> On Thu, Feb 01, 2024 at 04:30:27PM +0000, Jeff Hammond via J3 wrote:
>> Bill has mentioned this to me before but I want to verify my understand of storage sequences.
>> 
>> If I have a compiler like Intel Fortran that offers many options to the size of INTEGER to 2/4/8 bytes and REAL to 4/8/16 bytes, the only conforming options set INTEGER and REAL to the same size and DOUBLE PRECISION to twice that, correct?
>> 
>> This is not intended to pick on Intel because most implementations have these options, they just have the most as far as I can see.  My goal is to bound the scope of the MPI ABI proposal by only bothering to support conforming uses of these options, or these plus the most widely used non-conforming use (-integer-size 8 -double-size 8).
>> 
>> Thanks,
>> 
>> Jeff
>> 
>> 19.5.3.2 Storage sequence
>> 
>> A storage sequence is a sequence of storage units. The size of a storage sequence is the number of storage units in the storage sequence. A storage unit is a character storage unit, a numeric storage unit, a file storage unit (12.3.5), or an unspecified storage unit. The sizes of the numeric storage unit, the character storage unit and the file storage unit are the values of constants in the ISO_FORTRAN_ENV intrinsic module (16.10.2).
>> 
>> In a storage association context
>> 
>> (1) a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit,
>> (2) a nonpointer scalar object that is double precision real or default complex occupies two contiguous numeric storage units,
>> 
>> 
>> $ ifort -help data
>> 
>> Data
>> ----
>> 
>> -i{2|4|8}
>>          set default KIND of integer and logical variables to 2, 4, or 8
>> -integer-size <size>
>>          specifies the default size of integer and logical variables
>>            size:  16, 32, 64
>> -r{8|16}  set default size of real to 8 or 16 bytes
>> -real-size <size>
>>          specify the size of REAL and COMPLEX declarations, constants,
>>          functions, and intrinsics
>>            size: 32, 64, 128
>> -autodouble
>>          same as -real-size 64 or -r8
>> -double-size <size>
>>          defines the size of DOUBLE PRECISION and DOUBLE COMPLEX declarations,
>>          constants, functions, and intrinsics
>>            size:  64, 128
> 
> --
> Steve