(j3.2006) parameterized derived types

[Robert Corbett]

On 12/08/15 16:00, Bill Long wrote:
> An example might help.   I could see a potential rounding issue with something like a component declaration
>
>
>     real,dimension(INT( SQRT(25.0) * SQRT(121.0) )) :: X
>
> but this is not unique to PDTs.  The type parameters themselves are always type integer.
Of course there has been an issue with floating-point subexpressions of 
specification expressions since floating-point subexpressions were allowed in 
specification expressions.  What is new with PDTs is that bounds and lengths 
that depend on length parameters are determined dynamically (at run-time) rather 
than statically.  Absent length parameters, the bound and length expressions can 
all be evaluated by the compiler, which can control the rounding mode.

Consider the derived type definition

       TYPE T(N)
         INTEGER, LEN :: N
         REAL A(INT(SQRT(REAL(N))*SQRT(5.0)))
       END TYPE T!(N)

A variable X might be declared as

       TYPE(T(5)) X

A pointer P might be defined as

       TYPE(T(:)), POINTER :: P

The pointer P might be allocated by the statement

       ALLOCATE (T(5) :: P)

If the rounding mode in effect at the time the variable X was declared was 
round-to-nearest and the rounding mode in effect at the time the ALLOCATE 
statement was executed was round-toward-zero, the component array A of X should 
have one more element than the component array A of P.  The intrinsic assignment 
statement

       X = (P)

satisfies item (8) of Subclause 7.2.1.2 15-007r2, even though the array 
components have different sizes.  I assume that the assignment will fail to be 
standard conforming because of the attempt to assign an array component to a 
nonconformable array component.

If the example were changed to use a scalar character component of length 
INT(SQRT(REAL(N))*SQRT(5.0)) instead of an array component, the assignment 
appears to be standard conforming.

Bob Corbett

>
> Cheers,
> Bill
>
>
> On Dec 8, 2015, at 2:52 AM, Robert Corbett<robert.corbett at oracle.com>  wrote:
>
>> Constraints placed on components of derived types appear to be intended to
>> ensure that the values of expressions that appear in derived type definitions
>> shall not depend on any nonconstant values other than the values of the type
>> parameters.  One way in which the constraints fail to do so is that the
>> expressions can include floating-point operations whose value depend on the
>> rounding mode.  The rounding mode might be considered a hidden variable, but the
>> standard does not say that.  Does any implementation of parameterized derived
>> types take the possibility of changing rounding modes into account?
>>
>> I considered changing the rounding mode to the processor-dependent initial
>> rounding mode during elaboration of a type specifier with parameters, but the
>> standard does not appear to allow that.
>>
>> Ensuring that floating-point expressions produce the same values under a single
>> rounding mode is difficult but possible given the backends I need to support.
>> By default, the optimizers reorder floating-point expressions to produce more
>> efficient code.  Forcing them not to do so requires giving up many optimization
>> that are harmless.  The x87 environments are particularly difficult to handle.
>>
>>