[J3] Should all intrinsic functions be simple?

[Shafran, Aury]

I think the same issue exists for some of the procedures from the IEEE intrinsic module. F2023 says about 17.11 for the IEEE modules, "All the functions are simple ... unless otherwise stated." However, all the IEEE_GET/SET_* procedures are not conceptually simple because they access/modify state outside themselves. It is true that the floating-point status resets on exit of a user's procedure, so if A calls B, and B calls IEEE_SET_*, the changed status won't apply to A. But still it seems strange to call these IEEE procedures simple. Although, it would be equally as strange to not permit invoking these functions within a simple procedure!

There are also the IEEE_SUPPORT_* query procedures, COMPILER_VERSION, and COMPILER_OPTIONS, which are all simple but read global state. However I think these aren’t much of an issue because the global state they access should be constant, so they should always return the same value. (Though I don't think the standard requires them to always return the same value.)

Thanks,
Aury

-----Original Message-----
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Brad Richardson via J3
Sent: Tuesday, December 19, 2023 11:04 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: [J3] Should all intrinsic functions be simple?

Hi all,

For F2023 we changed our blanket statement from:

All standard intrinsic functions are pure.

to

All standard intrinsic functions are simple.

At first glance this seemed reasonable, but on closer inspection it seems several intrinsic functions are not conceptually simple. The constraints for simple procedures:

Any procedure referenced in a simple subprogram shall be simple.

A simple subprogram shall not contain a designator of a variable that is accessed by use or host association, unless the designator is part of a specification inquiry (10.1.11) that is a constant expression.

A simple subprogram shall not contain a reference to a variable in a common block.

Would seem to indicate that references to simple procedures with identical arguments would be suitable candidates for common subexpression elimination optimizations. However, that would not necessarily be true for all of the intrinsic functions. Take the following example:

cur_team = get_team()
...
change team (new_team)
  cur_team = get_team()
  ...
end team

Clearly, it is intended that the two calls to get_team return different results, so common subexpression elimination would not be valid here.
Also, conceptually, it would not be possible to implement this call in a way that does "not contain a designator of a variable that is accessed by use or host association" or "not contain a reference to a variable in a common block" as it clearly must be accessing some global state of the program.

Intrinsic functions which may be affected include:

* failed_images
* get_team
* image_index
* num_images
* stopped_images
* team_number
* this_image

I may have missed some. I think this is worth correcting. What do you all think?

Regards,
Brad