[flang-commits] [PATCH] D153916: [flang][NFC] Add F2023X documentation

[Peter Klausler via Phabricator via flang-commits]

klausler added a comment.

In D153916#4454929 <https://reviews.llvm.org/D153916#4454929>, @kiranchandramohan wrote:

> Thanks for putting up this document. Very informative and likely good feedback for standards committee members. I see that Brad has already commented, may be Mark and Gary also might be interested.
>
> A comment on the source line changes, relaxation for BOZ constants, using rank-one arrays to specify the rank and bounds of arrays might be useful.

F18 <https://reviews.llvm.org/F18> has always had no limit on free from source line length; are there other source line changes that I missed?

The BOZ literal changes originated in other implementations and they should already work in f18.  Some compilers allow BOZ as output statement I/O data items, and that is intentionally not supported.

I did miss the thing about using vectors for bounds in array declarations; will read up on that and add it.  Thanks for the tip!



================
Comment at: flang/docs/F202X.md:140
+
+#### `SIMPLE` procedures
+
----------------
kiranchandramohan wrote:
> There might be some performance benefits if lowering can use llvm attributes like `argmem`/`argmemonly` for simple functions.
> https://github.com/llvm/llvm-project/blob/main/llvm/docs/Frontend/PerformanceTips.rst#modeling-memory-effects
My understanding is that calls to `PURE` procedures could use `memory(read, argmem:readwrite, inaccessiblemem:readwrite)` and `SIMPLE` could drop the `read`.  Is that also what you have in mind?

Calls to `SIMPLE` procedures from `DO CONCURRENT` are also safe from the bug that feature has with `PURE` procedures.


================
Comment at: flang/docs/F202X.md:198
+type checking on assignment and argument association, generic
+resolution, formatted I/O, NAMELIST, debugging symbols, &c.
+It will indirectly affect every switch statement in the compiler
----------------
kiranchandramohan wrote:
> Is `Select case` support for enumeration types new?
It must be, since `ENUMERATION TYPE` is new in F202X.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153916/new/

https://reviews.llvm.org/D153916