(j3.2006) STAT arguments to intrinsics inconsistent

Bill Long longb
Fri Aug 25 00:13:47 EDT 2017


> On Aug 24, 2017, at 9:19 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 
> Hi Bill,
>  
> I will write a paper for MOVE_ALLOC.  The STAT and ERRMSG arguments are new in F2015 so there is no difficulty about fixing it.

Thanks. 

>  
> For ALLOCATE and DEALLOCATE, changing these now would be an incompatibility with Fortran 95, 2003 and 2008 (also I think F90, but don?t have a copy to hand to check).  This does not seem like a big enough problem to add yet another incompatibility.  We could add a recommendation without any compatibility issues, or just a NOTE that if the error code is large, it would need a bigger-than-8bit variable.

Realistically, there are more that 127 messages in the catalog, so a byte-size variable was never going to work.  A recommendation / Note would be a good idea for a separate paper. 

Cheers,
Bill
 

>  
> Cheers,
> -- 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>  
> From: J3 [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Bill Long
> Sent: Thursday, August 24, 2017 10:20 PM
> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
> Subject: Re: (j3.2006) STAT arguments to intrinsics inconsistent
>  
> 
> > On Aug 24, 2017, at 3:09 AM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> > 
> > Hi folks,
> > 
> > For the atomics, STAT is required to have a decimal range of at least 4.
> > 
> > The same is true of the collectives and EVENT_QUERY.
> > 
> > EXITSTAT has to have a decimal range of at least 9, but CMDSTAT is 4. I don?t object to that.
> > 
> > STATUS is also range 4.
> > 
> > In MOVE_ALLOC, STAT is required to be default integer. I *do* object to that.
> > 
> > I think we should change MOVE_ALLOC to be the same as all the other STAT arguments, i.e. decimal range of at least four.
> 
> 
> That is reasonable. 
> 
> However, there is a related problem. The likely error conditions for MOVE_ALLOC are the same as the errors for ALLOCATE and DEALLOCATE. The STAT= specifier for those statements (R929) is only required to be an integer, which is a real mistake. We need a constraint on R929 to require at least 4 digits there as well. 
> 
> We need to be consistent in requiring status variables to have a decimal range of at least 4, whether it is a STAT argument or a STAT= specifier. Allowing a single-byte integer in those cases is just not workable. 
> 
> Cheers,
> Bill
> 
> > 
> > Cheers,
> > -- 
> > ..............Malcolm Cohen, NAG Oxford/Tokyo.
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long longb at cray.com
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax: 651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> 
> Disclaimer
> The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> 
> This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425





More information about the J3 mailing list