TheRock/compiler/amd-llvm/flang/docs/MeetingNotes/2026/2026-05-20.md

Community Call 2026-05-20

Agenda

• Design docs and/or RFCs

  • [RFC] Support for -std=f2023
    • There is a new proposal for how to proceed: https://discourse.llvm.org/t/rfc-support-for-std-f2023/89608/24
    • Related PR: #196410 Generalize -pedantic to take an optional argument
      • Reviewers needed, as there are several different ways forward and detailed feedback is very much needed
    • Related Issue: https://github.com/llvm/llvm-project/issues/196409
    • Suggestion of getting -std= working, with f2018 as the minimum standard (so no need to enforce standards prior to 2018)
    • Steve - the way the compiler is written is not for 2018 semantics, it accepts everything from before that too. Concern that if we say -std=2018 that f03 and f08 will be expected too, and this could lead to mismatches in expectations from users. If we’re going to do the -std method, we should do it right so that the user experience meets user expectation. He prefers the -pedantic version.
    • Idea, have -std work as -pedantic (after implementing the latter) and give an extra warning to say we are not strictly enforcing the standard
    • Idea, have a separate flag that is specifically about the feature (i.e. SYSTEM_CLOCK)
      • Error out if using “bad” behavior of SYSTEM_CLOCK, flag would be to allow those errors
    • How to handle standards that don’t have SYSTEM_CLOCK (ex. f77)?
    • Potential for large increase in testing burden if we go the -std route, due to the need to test for all differences between each new standard and all the ones we use before it (even if we cut it off at f2018 as the earliest standard)
      • Current philosophy: If the old and new standards coexist happily, accept both, but if they clash then test for that specific feature behavior
    • Steve - this is only the second time we’ve run into this problem of conflicting standards for a given feature, if we start having a large number of situations like this, then it may make more sense to tackle this issue of enforcing strict standards compliance in a unified way
    • Do we know if the -std= flag is widely used by applications in the wild?
      • Useful for teams developing and expecting portability across different compilers
  • [RFC][flang] Add Floating-point trap handling support
    • Initial PR coming soon
    • Github issue: https://github.com/llvm/llvm-project/issues/198657
    • Agreement on RFC discussion about how to proceed, is it alright to create a PR for this or does NVIDIA want to upstream their previous work?
      • Go ahead with the new PR
  • [RFC] Aggressive inlinging for OpenMP SIMD loops
    • Needs more feedback from the community
    • How well is the inliner working for this?
      • Haven’t hit any regressions yet, using MLIR inline pass and LLVM inline cost model
  • [RFC][Flang-rt]Allow multiple units to open the same file path
    • Appears a decision against the proposal has been reached. Can we close this?
      • Yes, we should close it
  • [RFC] Flang lowering for OpenMP metadirective
    • PR https://github.com/llvm/llvm-project/pull/193664
    • PR https://github.com/llvm/llvm-project/pull/194424
    • First PR is basic lowering, the second is for dynamic user resolution, the loop and construct is still a work in progress
    • Reviewers needed
  • [RFC] Fortran 2023 ENUMERATION TYPEs
    • Related to Issue #183789
    • PR stack beginning here: https://github.com/llvm/llvm-project/pull/192651
    • All PRs in stack are still open for review/feedback
    • Reviewers needed
  • Changes to builtin modules
    • Main PR (from which the other two were extracted): https://github.com/llvm/llvm-project/pull/171515
    • Related Issue on Discourse: OpenMP Module Installation Paths in Flang
    • Reviewers asked to extract some more functionality out of the main PR
    • Now there are two paths added to the module search path, there is a chance of conflicting modules
    • Flang-rt change: there was one implementation file written in Fortran, has been rewritten in C++, changes requirements for what exactly is required to build and affects the order of the build
    • Michael Kruse will post on Discourse to let people know when the changes are about to land
    • When thinking about adding things to the runtime, does this mean we should avoid implementing things in Fortran?

• PRs of Note

  • Reviewers needed: Conditional args support - semantics, https://github.com/llvm/llvm-project/pull/195345
    • Parser support has been merged, this is the next step of the process and needs reviewers
    • There is one approval so far, but as this is a significant feature this really needs review from more experienced developers too

• Issues of Note

  • Unanswered Slack question about pow vs. powr: https://app.slack.com/client/T5CSCA08L/C5C58TT32
    • In the "IEEE floating point" standard (also ISO/IEC 60559:2020-05), we read that there are two recommended exponentiation operations, identified as pow(x,y) and powr(x,y). Lore has it that pow was modelled after C's pow function and powr was modelled after Fortran's **. This compiler seems to implement ** (for real operands) with pow semantics. Other popular compilers also do so. My question is, was there any discussion of this choice and is there a record of it somewhere? Either way, I think it would be helpful to document this choice in the appropriate place.
    • It may be too late to change the default semantics of R ** R to powr, but there is a decent chance that powr can be implemented to be faster than pow and some, at least, Fortran codes assume powr semantics and would rather not pay the price of pow.

• FYI

  • LLVM 22.1.6 Released!

  • [CFP] LLVM-HPC Workshop at SC’26

• Other topics as time allows

  • Recommended practice for reviewers being absent for a period of time (i.e. vacations)?
    • Post something on Slack to let the community know, especially if you are a frequent reviewer
    • HPE is working on designating people to handle some of this workload, looking to shadow current people serving in this capacity
    • The Maintainers list should be updated

Details

• Consists of over 764,000 lines of code, documentation, build files, and test
• To date, over 12,354 commits have been made to Flang