(j3.2006) (SC22WG5.5232) [ukfortran] Ballot on draft DTS

Bill Long longb
Fri Apr 18 15:07:01 EDT 2014

On Apr 18, 2014, at 1:42 PM, Damian Rouson <sourcery at rouson.net> wrote:

> On Apr 15, 2014, at 12:35 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
>> In particular,
>> (1) the collectives CO MAX, CO MIN, CO REDUCE, CO SUM, should be split into two 
>> forms, one with RESULT, one without.  The one with RESULT should have SOURCE as 
>> INTENT(IN), the one without should have SOURCE as INTENT(INOUT).  RESULT must 
>> not be optional.  The SOURCE INTENT(IN) form should have no coarray restrictions 
>> on SOURCE.

Currently there are no coarray restrictions on SOURCE (with or without a RESULT). 

> Is the reasoning here that there is a potential performance advantage that can be preserved in the ?INTENT(IN)? case?  If so, I agree that performance is paramount.  If not, please explain the reasoning for wanting two forms rather than having RESULT optional. 

The current requirement is that ?If RESULT is present, SOURCE is not modified?.  For the compiler optimizer, that is as good as saying INTENT(IN). 

The argument against OPTIONAL arguments in intrinsics is that in F2003 (or was it 2008?) we introduced a new concept that an actual argument that is an unallocated allocatable or disassociated pointer that corresponds to an OPTIONAL nonallocatable nonpointer dummy causes the dummy to treat the call as if the actual is not present.  Thus there are situations where the compiler cannot tell at compile time whether the RESULT argument is PRESENT or not PRESENT.  (A recurring thorn in the side with this feature.)   For the collective routines above, I?d argue that this is not that big a deal.  It is possible to put the PRESENT check inside the library routine without material performance consequences.  Is some other cases, you really do want the compiler to call different actual library routines for cases where an argument is PRESENT or not, and in those cases we do specify different forms of the call and make the argument not OPTIONAL in the alternate version. 


> Damian
> _______________________________________________
> 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 Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

More information about the J3 mailing list