[J3] Question about the maximum event count of EVENT_TYPE variables

Malcolm Cohen malcolm at nag-j.co.jp
Mon Jun 7 08:03:40 UTC 2021



Integer overflow makes the program non-conforming. The standard should not say more about event count in particular, unless we want to *require* that overflow raise an error condition. That would be a new feature for F202y.




..............Malcolm Cohen, NAG Oxford/Tokyo.


From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Milan Curcic via J3
Sent: Monday, June 7, 2021 3:49 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Milan Curcic <caomaco at gmail.com>
Subject: [J3] Question about the maximum event count of EVENT_TYPE variables


Section, paragraph 2, line 16 of 18-007r1 states:


> The event count is of type integer with kind ATOMIC_INT_KIND from the intrinsic module ISO_FORTRAN_ENV


and the ATOMIC_INT_KIND is defined as (


> The value of the default integer scalar constant ATOMIC_INT_KIND is the kind type parameter value of type integer variables for which the processor supports atomic operations specified by atomic subroutines.


My interpretation of this is that EVENT_TYPE variables have a maximum event count that is processor-dependent. With GFortran and ifort, that's 2147483647.


However, I can't find any text that describes what happens to the event count when it exceeds its maximum value. With GFortran+OpenCoarrays, it overflows (i.e. -2147483648 follows 2147483647).


Is this behavior:


* Processor-dependent?

* Undefined?

* Non-conforming?


I think that the Standard should at least say if the behavior is one of the above, if not also what should happen to the event count value. Do you agree? If yes, does this call for an interp?








The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: 30 St. Giles, Oxford, OX1 3LE, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210607/b4d67a04/attachment.htm>

More information about the J3 mailing list