(j3.2006) parameterized derived types

[Bill Long]

On Dec 8, 2015, at 10:24 PM, Robert Corbett <robert.corbett at oracle.com> wrote:

> 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 

Bounds have been determined dynamically at run time for ages. For example, automatic arrays and allocatable arrays.  Even explicit-shape arrays with variables used as the bounds. 



> 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)


How about

 integer,parameter :: N=13467
 REAL A(INT(SQRT(REAL(N))*SQRT(5.0)))
..
 CALL SUB (A, N)
?
  subroutine sub (a, n)
  integer :: n
  REAL A(INT(SQRT(REAL(N))*SQRT(5.0)))

  A = 0.34

In the caller, the nonsensical bounds expression is computed at compile time, whereas the bounds in the subroutine  are computed dynamically at run time.  If unfortunate rounding causes the subroutine bound to be one larger than the caller?s, then bad things could happen. 

I?ll agree that there is a problem.  I just don?t think the problem is tied to PDTs.   It?t rooted in the ability for users to change rounding modes combined with allowing specification expressions to involve floating point operations.

Cheers,
Bill


> 
> 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.
>>> 
>>> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101