(j3.2006) parameterized derived types
Robert Corbett
robert.corbett
Tue Dec 8 23:24:03 EST 2015
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.
>>
>>
More information about the J3
mailing list