(j3.2006) parameterized derived types

[Cohen Malcolm]

I certainly agree there is a problem here.  This is probably more obvious in 
argument association, e.g.

  ...
  TYPE(T(5)) x
  CALL ieee_set_rounding_mode(ieee_down)
  CALL sub(x,5)
  ...
  SUBROUTINE sub(y,n)
  TYPE(T(n)) y

As X and Y have the same type and type parameter values, obviously they have 
to have the same layout in memory etc.

Basically, this means that any floating-point expressions in a "component 
specification expression" (making that term up) would have to be evaluated 
with the arithmetic and rounding modes that the processor uses at compile 
time for this to work.

Alternatively we could forbid such code from appearing in component 
specification expressions, or forbid instantiation of such objects when the 
"floating-point environment" means that the values of any such expressions 
would differ.   The former seems hard to express without using the big 
hammer of forbidding floating-point in component specification expressions 
altogether, whilst the latter is profoundly user-unfriendly.

Unlike Robert, I do not think the first option would give up "many 
optimization"; there would be little lost if the compiler pessimized such 
expressions.

Cheers,

-----Original Message----- 
From: Robert Corbett
Sent: Wednesday, December 9, 2015 1:24 PM
To: j3 at mailman.j3-fortran.org
Subject: Re: (j3.2006) parameterized derived types

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

_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3

________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________

-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.