Doomhowl-Interactive/llvm-project
0
0
Fork 0
Code Issues Pull Requests Actions 5 Packages Projects Releases Wiki Activity

[flang] Add Flang Call Notes documents (#180287)

Browse Source 
This PR is the result of discussion in
https://discourse.llvm.org/t/rfc-what-to-do-regarding-the-flang-call-notes-document/89450.
The intent with this PR is to move away from the former Google Doc in
favor of keeping the call notes in the primary repository. This PR has
the boilerplate and the notes from the last few meetings. In future,
notes from previous calls could be added in as well, once recovered from
the corrupted document.

The intended flow going forward would be for the call organizer to draft
the meeting's agenda in the working Google Doc referenced in
MeetingNotes/README.md, post it on Slack the day before the meeting,
take notes in the document during the call, then translate those notes
into a new notes document in the correct folder after the call is
completed and create a PR.
This commit is contained in:
Alexis Perry-Holby
2026-02-18 20:41:41 -07:00
committed by GitHub
parent a0df62be84
commit a0e90614b7
9 changed files with 440 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
flang/docs/GettingInvolved.md
View File

@@ -49,12 +49,20 @@ Contributions to Flang are done using GitHub Pull Requests and follow the
### Flang Biweekly Call
- Technical discussions as well as general updates on the Flang project.
- Join the [Flang Biweekly Call](https://lanl-us.webex.com/lanl-us/j.php?MTID=mdce13c9bd55202e8071d8128fb953614)
- If you prefer to join using a meeting number and password, those can be
found in this [Google Doc](https://docs.google.com/document/d/1Z2U5UAtJ-Dag5wlMaLaW1KRmNgENNAYynJqLW2j2AZQ/). Alternative methods of joining, such as call-in numbers, are also available there.
- Join the [Flang Biweekly Call](https://lanl-us.webex.com/lanl-us/j.php?MTID=m0fcaebfcf6b4b4f506efd792a71a015c). Alternative ways to join the call are provided below.
- Join with meeting number and password
- Meeting number (access code): 177 400 7047
- Meeting password: 6PCdCYKmN43
- Join by phone
- +1-415-655-0002 US Toll
- [Global call-in numbers](https://lanl-us.webex.com/lanl-us/globalcallin.php?MTID=ma8c4fc1f538bce541415427fbe89c85b)
- Join from a video system or application
- Dial [1774007047@lanl-us.webex.com](mailto:1774007047@lanl-us.webex.com)
- You can also dial 173.243.2.68 and enter your meeting number
- Time: Every other Wednesday, 8:30 a.m. Pacific Time. Please check the [LLVM Community Calendar](https://calendar.google.com/calendar/u/0/embed?src=calendar@llvm.org) for the next scheduled call.
- Calendar invite: https://drive.google.com/file/d/1rkfWCtIvQFcxN0Uz8YVwQGoX_BbzT8oc/view?usp=drive_link
- Meeting minutes are available in this [Google Doc](https://docs.google.com/document/d/18DHhXjdzPQP20rmQiDsWbv1tHfqz8TjJiSPwI-wYbY8/edit).
- Working agenda is available in this [Google Doc](https://docs.google.com/document/d/18DHhXjdzPQP20rmQiDsWbv1tHfqz8TjJiSPwI-wYbY8/edit). The drafted agenda will be posted on Slack the day before the meeting. Edits to the agenda should be made directly in the Google Doc, but if this is not possible any replies to the Slack post will also be incorporated.
- Meeting minutes are available in the [MeetingNotes](https://github.com/llvm/llvm-project/blob/main/flang/docs/MeetingNotes) directory.
- Minutes from older meetings were posted on the [Flang forum](https://discourse.llvm.org/c/subprojects/flang). Search for `Flang Biweekly Sync - Notes`.
### LLVM Alias Analysis Technical Call

56
flang/docs/MeetingNotes/2025/2025-12-03.md Normal file
View File

@@ -0,0 +1,56 @@
<!--===- docs/MeetingNotes/2025/2025-12-03.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Call 2025-12-03
## Agenda
* Design docs and/or RFCs
* [\[RFC\] How to inform users why an executable stack is required](https://discourse.llvm.org/t/rfc-how-to-inform-users-why-an-executable-stack-is-required/89007)
* Currently trampolines are implemented on the stack requiring the stack to be executable and the linker emits a message about it, but this may be confusing to users
* There are a few options to explore for how to improve this implementation (see RFC)
* Reorganizing the table of contents for the documentation \- seems a good idea and at least one person volunteered to review PRs related to this
* Should trampolines be implemented on the stack or on the heap?
* Kiran: Implementing on the heap is better, but do people have the bandwidth to re-implement on the heap?
* This RFC is about improving the explanation to users, not necessarily about re-implementing trampolines in an improved fashion
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Themos Tsikas: currently there is a disagreement about parentheses in rounding. We may need an interp request from the J3 committee.
* Jean Perier: we need to account for behavior that apps rely on and provide a fallback mechanism if we make a change
* [\[RFC\] Command-line compatibility with gfortran](https://discourse.llvm.org/t/rfc-command-line-compatibility-with-gfortran/88961)
* Related PR: [https://github.com/llvm/llvm-project/pull/165579](https://github.com/llvm/llvm-project/pull/165579)
* Consensus: we should not try to aim for command-line compatibility with gfortran, and a list exists of specific options that are wanted by users for their specific cases. Support for options will be considered on a case-by-case basis.
* Compatibility with Clang \> with gfortran
* PRs of Note
* [\[Flang\]\[FIR\] Introduce FIRToCoreMLIR pass. \#168703](https://github.com/llvm/llvm-project/pull/168703)
* Issues of Note
* [Invalid code for 'where'](https://urldefense.com/v3/__https://discourse.llvm.org/t/invalid-code-for-where/88881/2__;!!Bt8fGhp8LhKGRg!AzRYeczr2-nZWMBB2mVGUwRR3M58rt_SIF-svPI6IVhIyIiSgTTDssvRaU8H0UI4kGx_9LKg4f2gkD4HaosWtAksKlal0j8r$)
* FYI
* CFP FOSDEM 2026 LLVM dev room
* extended the submission deadline with 1 week until December 7th
* [Discourse post](https://urldefense.com/v3/__https://discourse.llvm.org/t/cfp-fosdem-2026-llvm-dev-room-deadline-extended-until-december-7th/88746/2__;!!Bt8fGhp8LhKGRg!CN-bph7losNBxOURN0VbmhDaHVSVDiQSqbr3oJqWjE6O7tA4Q3yebG-T8B6JQFkQc97cWmtY5XlHyqO9n44zxlCjPvgysnnW$)
* [Flang Liaison Report ot J3](https://j3-fortran.org/doc/year/25/25-184r1.txt)
* [Operational Maturity Round Table Notes](https://urldefense.com/v3/__https://discourse.llvm.org/t/operational-maturity-round-table-notes/88898/4__;!!Bt8fGhp8LhKGRg!DBCD7MXLIlKDQMxYC24V2tf9xKpQF7PD3s92rD_AqokuSQOdNeDC7vxesj3En2jeZJlK5nCu2wRFTbe3WtjJCi-o4hGTHJtt$)
* Possible switch to PR-only mechanism
* Other topics as time allows
* Proposing an Interactive Fortran Workflow with Flang using Jupyter Notebooks
* Anutosh Bhat \- Fortran ecosystem lacks a modern interactive workflow
* Something is available using LFortran, but it’s not perfect: [https://github.com/lfortran/lfortran/blob/main/share/lfortran/nb/Demo1.ipynb](https://github.com/lfortran/lfortran/blob/main/share/lfortran/nb/Demo1.ipynb)
* Flang seems a natural place to bring this into being
* [https://compiler-research.org/xeus-cpp-wasm/lab/index.html](https://compiler-research.org/xeus-cpp-wasm/lab/index.html)
* There is clang-repl for this with C++
* RFC coming
* [OpenMP notebook demo](https://github.com/compiler-research/xeus-cpp/blob/da0cc730b175c2dd880d16845187e68917afc9f5/notebooks/openmp-notebooks/openmp-demo.ipynb)
* [CUDA notebook demo](https://github.com/compiler-research/xeus-clang-repl/blob/main/notebooks/kalman_CUDA_demo/run_kf.ipynb)
* [prototype-debug.mp4](https://drive.google.com/file/d/1KxMpHz7njRTb2d1FSTPumZXfgoNRHhbM/view)
* [FOSDEM 2025 \- O\_o \[ Flang \+ WASM \] o\_O](https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5202-oo-flang-wasm-oo/)
* Given the issues with the Call Notes document, this may be a good time to migrate to a Markdown document located in the repo
*
## Details
* Consists of over **704,000** lines of code, documentation, build files, and test
* To date, over **11,430** commits have been made to Flang

53
flang/docs/MeetingNotes/2025/2025-12-17.md Normal file
View File

@@ -0,0 +1,53 @@
<!--===- docs/MeetingNotes/2025/2025-12-17.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Call 2025-12-17
## Agenda
* No meeting on 12/31
* Update on meeting notes document
* What will protect the data if something should happen to Discourse?
* RFC is a good idea
* Design docs and/or RFCs
* [Changes to builtin modules](https://discourse.llvm.org/t/changes-to-builtin-modules/89072)
* PR was reverted due to buildbot failure involving Windows
* Undergoing another review process, will not try landing again until after the first of the year
* [\[RFC\] Proposing an Interactive Fortran Workflow with Flang using Jupyter Notebooks](https://discourse.llvm.org/t/rfc-proposing-an-interactive-fortran-workflow-with-flang-using-jupyter-notebooks/89116/5)
* Intention is to build a flang-repl in the context of Jupyter Notebooks
* Seems unclear what the authors expect from the greater Flang community
* Looking for assistance with making changes to flang to make the repl work and/or for info about what barriers exist to creating it in the first place (possibly also looking for funding)
* Unsure why they are choosing to use Flang instead of continue the LFortran work
* Possibly to do with level of standards compliance
* [\[RFC\] Support \-fstrict-aliasing and \-fno-strict-aliasing](https://discourse.llvm.org/t/rfc-support-fstrict-aliasing-and-fno-strict-aliasing/89135)
* Related to an issue that came in, these flags are supported in both gcc and clang
* Would affect type-based alias analysis
* Does this have any implications for Fortran code specifically? Does it violate the standard?
* Michael Klemm can ask some gfortran developers directly
* Related issue: [https://github.com/llvm/llvm-project/issues/171912](https://github.com/llvm/llvm-project/issues/171912)
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Still under debate
* PRs of Note
* [\[flang\]\[driver\] Do not allow \-module-dir to be joined to the value \#168748](https://github.com/llvm/llvm-project/pull/168748)
* Currently, although it is a long-form option, the value is joined to it
* Likely, we will not be able to add options that start with \-module-dir given the current implementation
* Changing this will affect CMake usage (CMake PR to use the \-J option has been accepted, but not backported to older versions)
* Potential compatibility problem with gfortran
* [\[Flang\]\[FIR\] Introduce FIRToCoreMLIR pass. \#168703](https://github.com/llvm/llvm-project/pull/168703)
* Issues of Note
* [Building Flang with offload support](https://discourse.llvm.org/t/building-flang-with-offload-support/89100)
* FYI
* LLVM \- [Document the community RFC process](https://github.com/llvm/llvm-project/pull/116386)
* [2026 EuroLLVM Developers' Meeting \- Call for Proposals](https://discourse.llvm.org/t/2026-eurollvm-developers-meeting-call-for-proposals/89059)
* Other topics as time allows
* Flang-tidy update next time
* Fujitsu test suite discussion next time (how to make it easier for people to use)
## Details
* Consists of over **707,000** lines of code, documentation, build files, and test
* To date, over **11,511** commits have been made to Flang

70
flang/docs/MeetingNotes/2026/2026-01-14.md Normal file
View File

@@ -0,0 +1,70 @@
<!--===- docs/MeetingNotes/2026/2026-01-14.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Call 2026-01-14
## Agenda
* Design docs and/or RFCs
* Fujitsu test suite ease of use
* It’s not easily usable as-is right now: very large, includes C++ tests, lacks the expected flang result, etc.
* Issues have been opened in the Fujitsu test repo to make a subset of the suite for Flang-only tests
* [https://github.com/fujitsu/compiler-test-suite/issues/53](https://github.com/fujitsu/compiler-test-suite/issues/53)
* Another Fujitsu issue to request not to build C/C++ when testing Fortran: [https://github.com/fujitsu/compiler-test-suite/issues/52](https://github.com/fujitsu/compiler-test-suite/issues/52)
* Perhaps eventually bring this inside the LLVM test suite directly, after fixes are added
* Does Linaro have a bot that is running this currently?
* [Flang-tidy](https://discourse.llvm.org/t/rfc-flang-flang-tidy-a-new-tool-for-fortran-static-analysis/87579)
* Issue seems to be that many of the checks could be done in Flang itself rather than the tool
* What about in-place correction of the source code (ala clang-tidy)?
* Could we make some of the checks the tool uses available to the Flang driver as well?
* Idea: split the checks up and give the ones that have a repair mechanism to flang-tidy and the rest go to the Flang driver
* Do we bring the tool in as-is, then start a process of refactoring to create a separate library of checks?
* Need to talk to the original contributors to make sure they are still invested, also need to check-in with Peter Klausler and need to find a maintainer for the tool once merged
* [\[RFC\] What to do regarding the Flang Call Notes document](https://discourse.llvm.org/t/rfc-what-to-do-regarding-the-flang-call-notes-document/89450)
*
* [\[RFC\] Support classic flang driver options in flang](https://discourse.llvm.org/t/rfc-support-classic-flang-driver-options-in-flang/89380)
*
* [Cross-compilation of real(kind=16)](https://discourse.llvm.org/t/cross-compilation-of-real-kind-16/89161)
*
* [\[RFC\] Support \-fstrict-aliasing and \-fno-strict-aliasing](https://discourse.llvm.org/t/rfc-support-fstrict-aliasing-and-fno-strict-aliasing/89135)
* Related issue: [https://github.com/llvm/llvm-project/issues/171912](https://github.com/llvm/llvm-project/issues/171912)
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Still under debate
* [Changes to builtin modules](https://discourse.llvm.org/t/changes-to-builtin-modules/89072)
* PR was reverted due to buildbot failure involving Windows
* Undergoing another review process, will not try landing again until after the first of the year
* [\[RFC\] Use pre-compiled headers to speed up LLVM build by \~1.5-2x](https://discourse.llvm.org/t/rfc-use-pre-compiled-headers-to-speed-up-llvm-build-by-1-5-2x/89345/24)
* Related to what has already been done in Flang, attempt to use this approach more generally
* Draft PR: [https://github.com/llvm/llvm-project/pull/173868](https://github.com/llvm/llvm-project/pull/173868)
* PRs of Note
* [\[Flang\]\[FIR\] Introduce FIRToCoreMLIR pass. \#168703](https://github.com/llvm/llvm-project/pull/168703)
* Issues of Note
* [Building Flang with offload support](https://discourse.llvm.org/t/building-flang-with-offload-support/89100)
* FYI
* LLVM 22.x has branched, first RC expected Friday 1/16: [https://discourse.llvm.org/t/llvm-22-x-has-branched/89447](https://discourse.llvm.org/t/llvm-22-x-has-branched/89447)
* [2026 LLVM Community Area Team Elections \- Call for Nominations](https://discourse.llvm.org/t/2026-llvm-community-area-team-elections-call-for-nominations/89439)
* Added LoopInvariantCodeMotion pass for \[HL\]FIR. (PR \#[173438](https://github.com/llvm/llvm-project/pull/173438))
* Other topics as time allows
* One-off additional call next Wednesday at the same start time. Meeting link to be posted on slack and here in the notes.
* [https://lanl-us.webex.com/lanl-us/j.php?MTID=mf9e0b3ff7ba2ba9d5dbdeb510296cf5e](https://lanl-us.webex.com/lanl-us/j.php?MTID=mf9e0b3ff7ba2ba9d5dbdeb510296cf5e)
* Wednesday, January 21, 2026 9:30 AM | 30 minutes | (UTC-07:00) Mountain Time (US & Canada)
* Meeting number: 2488 038 4796
* Password: mY9p2pMx6tm
* Join by video system
* Dial 24880384796@lanl-us.webex.com
* You can also dial 173.243.2.68 and enter your meeting number.
* Join by phone
* \+1-415-655-0002 US Toll
* Access code: 248 803 84796
## Details
* Consists of over **713,000** lines of code, documentation, build files, and test
* To date, over **11,617** commits have been made to Flang

65
flang/docs/MeetingNotes/2026/2026-01-21.md Normal file
View File

@@ -0,0 +1,65 @@
<!--===- docs/MeetingNotes/2026/2026-01-21.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Special Combined Call 2026-01-21
## Agenda
* Design docs and/or RFCs
* Flang failure with thin lto on LLVM 22-RC1
* [https://github.com/llvm/llvm-project/issues/176404](https://github.com/llvm/llvm-project/issues/176404)
* [\[RFC\] What to do regarding the Flang Call Notes document](https://discourse.llvm.org/t/rfc-what-to-do-regarding-the-flang-call-notes-document/89450)
* Tarun- Not keen on keeping it in the Flang repo, mostly due to folks needing commit access to add or update anything. He is not that concerned about relying on Discourse, since LLVM has officially adopted it if they do decide to make a change it is likely that the notes would be migrated
* What about a wiki? Does LLVM have a policy on this, or gist?
* Idea: Working Google Doc, post agenda in Slack day before the meeting and request for comments, final notes copied into MD doc in the repo
* Example of another document/repo structure: [https://github.com/triton-lang/triton/tree/main/docs/meetups](https://github.com/triton-lang/triton/tree/main/docs/meetups)
* [\[RFC\] Support classic flang driver options in flang](https://discourse.llvm.org/t/rfc-support-classic-flang-driver-options-in-flang/89380)
* Do we want to support the spelling of certain options that are available in classic flang?
* Tarun: Not inclined to do this as nearly all of the requested options have equivalent flang/gfortran version
* Poll results: ambiguous, leading choice was to use a case-by-case basis
* Idea: add them in with a deprecation warning to ease users transitions to LLVM Flang
* Tarun will post update to the RFC
* [Cross-compilation of real(kind=16)](https://discourse.llvm.org/t/cross-compilation-of-real-kind-16/89161)
* Issue involves library availability which can cause link-time failures, for example
* There is a proposed solution in the Discourse post
* [\[RFC\] Support \-fstrict-aliasing and \-fno-strict-aliasing](https://discourse.llvm.org/t/rfc-support-fstrict-aliasing-and-fno-strict-aliasing/89135)
* Related issue: [https://github.com/llvm/llvm-project/issues/171912](https://github.com/llvm/llvm-project/issues/171912)
* Gfortran supports \-fno-strict-aliasing, Michael Klemm contacted their communtiy to inquire about it, turns out there is nothing special done for Fortran when that flag is passed
* Would appreciate feedback from someone with more experience with end-users
* Discussion leaned towards not accepting these options
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Reply from the standards committee: [https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html](https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html)
* What happens when FMA does have a different precision than a multiply and add?
* How do you control FMAs, since this is something that users are going to want to employ?
* Cray and nvfortran have a specific control for FMAs, independent of opt level and other things
* [Changes to builtin modules](https://discourse.llvm.org/t/changes-to-builtin-modules/89072)
* PR was reverted due to buildbot failure involving Windows
* Undergoing another review process, will not try landing again until after the first of the year
* [\[RFC\] Use pre-compiled headers to speed up LLVM build by \~1.5-2x](https://discourse.llvm.org/t/rfc-use-pre-compiled-headers-to-speed-up-llvm-build-by-1-5-2x/89345/24)
* Related to what has already been done in Flang, attempt to use this approach more generally
* Draft PR: [https://github.com/llvm/llvm-project/pull/173868](https://github.com/llvm/llvm-project/pull/173868)
* [Improvement of Fujitsu test suite](https://discourse.llvm.org/t/improvement-of-fujitsu-test-suite/89475)
* \[RFC\] Add a New Byte Type to LLVM IR
* Among other things, “Fixes known correctness bugs in memcpy lowering and load merging/widening”. Semantics are different from integer types and may allow other memory optimizations. This is a step towards eventual removal of Undef from LLVM-IR.
* [Related group working towards a formal specification of LLVM-IR](https://discourse.llvm.org/t/rfc-forming-a-working-group-on-formal-specification-for-llvm/89056/4)
* PRs of Note
* [\[Flang\]\[FIR\] Introduce FIRToCoreMLIR pass. \#168703](https://github.com/llvm/llvm-project/pull/168703)
* Issues of Note
* [Building Flang with offload support](https://discourse.llvm.org/t/building-flang-with-offload-support/89100)
* FYI
* [2026 LLVM Community Area Team Elections \- Call for Nominations](https://discourse.llvm.org/t/2026-llvm-community-area-team-elections-call-for-nominations/89439)
* Added LoopInvariantCodeMotion pass for \[HL\]FIR. (PR \#[173438](https://github.com/llvm/llvm-project/pull/173438))
* Call for Mentors \- 2026 EuroLLVM Developers’ Meeting
* [https://discourse.llvm.org/t/call-for-mentors-2026-eurollvm-developers-meeting/89484/](https://discourse.llvm.org/t/call-for-mentors-2026-eurollvm-developers-meeting/89484/)
* Google Form here: [EuroLLVM Mentorship Program Application](https://docs.google.com/forms/d/e/1FAIpQLSfPmzaBfINmdO4ORs8fW5rXTphKaQLfhh45nYFh3IVKS1ZN7w/viewform)
* Other topics as time allows
*
## Details
* Consists of over **713,000** lines of code, documentation, build files, and test
* To date, over **11,617** commits have been made to Flang

75
flang/docs/MeetingNotes/2026/2026-01-28.md Normal file
View File

@@ -0,0 +1,75 @@
<!--===- docs/MeetingNotes/2026/2026-01-28.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Call 2026-01-28
## Agenda
* Design docs and/or RFCs
* Flang failure with thin lto on LLVM 22-RC1 \- Thank you for fixing it\!
* [https://github.com/llvm/llvm-project/issues/176404](https://github.com/llvm/llvm-project/issues/176404)
* [\[RFC\] What to do regarding the Flang Call Notes document](https://discourse.llvm.org/t/rfc-what-to-do-regarding-the-flang-call-notes-document/89450)
* Proposal: in the Flang repo
* This Google doc becomes a working document for drafting the agenda, taking notes during the call
* Post the agenda the day before the meeting, indicate to edit document directly with additional items or other changes, reply to the Slack post if that is not possible
* flang/docs/MeetingNotes/YYYY/
* files of finalized notes go in this directory, in a file like YYYY-MM-DD.md
* flang/docs/MeetingNotes/README.md contains the boilerplate information, point to the GettingStarted.md document for call information to avoid tracking in two different places
* [\[RFC\] Support classic flang driver options in flang](https://discourse.llvm.org/t/rfc-support-classic-flang-driver-options-in-flang/89380)
* Suggestion was to accept the alternate spellings but give a deprecation warning immediately to encourage migrating to the regular spelling
* Time frame for full deprecation/removal?
* Should classic Flang be treated like a totally separate compiler, like Intel vs. Cray?
* [\[RFC\] Automatic static promotion of large local variables in Flang](https://discourse.llvm.org/t/rfc-automatic-static-promotion-of-large-local-variables-in-flang/89539)
* There is a similar issue with OpenMP privatize
* Michael Kruse \- If you do this, you run out of stack space quite quickly. So the default should be on the heap, but with a flag to specifically put arrays (even of unknown size) on the stack
* Ted Johnson \- Cray has flags for both behaviors, but there are a lot of flags to control the exact behavior (default is heap for certain use cases, stack for others)
* Pthreads has a way to change the stack size via a function
* What about executable stacks and how they factor in?
* Flang-tidy
* Meeting with authors has been deferred, will create meeting including Tarun Prabhu
* [Cross-compilation of real(kind=16)](https://discourse.llvm.org/t/cross-compilation-of-real-kind-16/89161)
* PR will come out, remaining issues can be resolved via that discussion
* [\[RFC\] Support \-fstrict-aliasing and \-fno-strict-aliasing](https://discourse.llvm.org/t/rfc-support-fstrict-aliasing-and-fno-strict-aliasing/89135)
* Related issue: [https://github.com/llvm/llvm-project/issues/171912](https://github.com/llvm/llvm-project/issues/171912)
* We can’t do anything reasonable with it without violating the Fortran standard, will leave it open for a little while longer but likely will not support this
* [Changes to builtin modules](https://discourse.llvm.org/t/changes-to-builtin-modules/89072)
* PR was reverted due to buildbot failure involving Windows
* Reviewers asked for big changes, working on a compromise involving putting TODOs in other runtimes
* [\[RFC\] Add a New Byte Type to LLVM IR](https://discourse.llvm.org/t/rfc-add-a-new-byte-type-to-llvm-ir/89522)
* Among other things, “Fixes known correctness bugs in memcpy lowering and load merging/widening”. Semantics are different from integer types and may allow other memory optimizations. This is a step towards eventual removal of Undef from LLVM-IR.
* [Related group working towards a formal specification of LLVM-IR](https://discourse.llvm.org/t/rfc-forming-a-working-group-on-formal-specification-for-llvm/89056/4)
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Reply from the standards committee: [https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html](https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html)
* PRs of Note
* Tests from Cray’s CCE internal test suite in llvm-test-suite \[[PR](https://github.com/llvm/llvm-test-suite/pull/326)\]
* Proposed directory structure with one test in linked PR
* [\[Flang\]\[FIR\] Introduce FIRToCoreMLIR pass. \#168703](https://github.com/llvm/llvm-project/pull/168703)
* Issues of Note
* gcc warning suppression (Michael Kruse)
* [https://github.com/llvm/llvm-project/pull/174918](https://github.com/llvm/llvm-project/pull/174918)
* Also see [message](https://flang-compiler.slack.com/archives/C5C58TT32/p1769446659561029) in Slack \#general
* FYI
* [2026 EuroLLVM Developers' Meeting \- Registration Open\!](https://urldefense.com/v3/__https://discourse.llvm.org/t/2026-eurollvm-developers-meeting-registration-open/89557/1__;!!Bt8fGhp8LhKGRg!A1yd7PA_NA6qkPE3goiI1siQF7mKAnVnpOywFlJBmbQcFXDx25MhAH_tFbBKid5Fgp7F2Plqn6VULBMr0p8X3kyZUxvo58wA$)
* Call for Mentors \- 2026 EuroLLVM Developers’ Meeting
* [https://discourse.llvm.org/t/call-for-mentors-2026-eurollvm-developers-meeting/89484/](https://discourse.llvm.org/t/call-for-mentors-2026-eurollvm-developers-meeting/89484/)
* Google Form here: [EuroLLVM Mentorship Program Application](https://docs.google.com/forms/d/e/1FAIpQLSfPmzaBfINmdO4ORs8fW5rXTphKaQLfhh45nYFh3IVKS1ZN7w/viewform)
* [2026 LLVM Community Area Team Elections \- Voting is open\!](https://discourse.llvm.org/t/2026-llvm-community-area-team-elections-voting-is-open/89586)
* Voting closes Feb 9
* [LLVM 22.1.0-rc2 Released\!](https://urldefense.com/v3/__https://discourse.llvm.org/t/llvm-22-1-0-rc2-released/89590/1__;!!Bt8fGhp8LhKGRg!ABovo_Sh_W26Vzta9YaGsBfoijc8x9IdZeglz6_12Uk63RPwA3uaPmuiBfK_HAKBfAXkVh4l77XHKKfO9aepSUbPipT5YVix$)
* The next release will be 22.1.0-rc3 on Tuesday the 10th of Feb
* Who is writing the [flang release notes](https://github.com/llvm/llvm-project/blob/release/22.x/flang/docs/ReleaseNotes.md)?
* [Improvement of Fujitsu test suite](https://discourse.llvm.org/t/improvement-of-fujitsu-test-suite/89475)
* [\[RFC\] Use pre-compiled headers to speed up LLVM build by \~1.5-2x](https://discourse.llvm.org/t/rfc-use-pre-compiled-headers-to-speed-up-llvm-build-by-1-5-2x/89345/24)
* Related to what has already been done in Flang, attempt to use this approach more generally
* Added LoopInvariantCodeMotion pass for \[HL\]FIR. (PR \#[173438](https://github.com/llvm/llvm-project/pull/173438))
* Other topics as time allows
*
## Details
* Consists of over **721,000** lines of code, documentation, build files, and test
* To date, over **11,703** commits have been made to Flang

74
flang/docs/MeetingNotes/2026/2026-02-11.md Normal file
View File

@@ -0,0 +1,74 @@
<!--===- docs/MeetingNotes/2026/2026-02-11.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Call 2026-02-11
## Agenda
* Design docs and/or RFCs
* [\[RFC\] Warning suppression policy \- Flang \- LLVM Discussion Forums](https://discourse.llvm.org/t/rfc-warning-suppression-policy/89676)
* Related PR: [https://github.com/llvm/llvm-project/pull/174918](https://github.com/llvm/llvm-project/pull/174918)
* [\[RFC\] Support for \-std=f2023](https://discourse.llvm.org/t/rfc-support-for-std-f2023/89608/24)
* SYSTEM\_CLOCK changed with F2023 and the discussion centers on what the default behavior should be and how best to allow users to select the behavior they need. There are compatibility breaking issues between standards regarding this intrinsic.
* MattPD \- re gcc/gfortran: The default value for std is 'gnu', which specifies a superset of the latest Fortran standard that includes all of the extensions supported by GNU Fortran, although warnings are given for obsolete extensions not recommended for use in new code. The 'legacy' value is equivalent but without the warnings for obsolete extensions, and may be useful for old nonstandard programs.
* [https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html](https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html)
* [Cross-compilation of real(kind=16)](https://discourse.llvm.org/t/cross-compilation-of-real-kind-16/89161)
* PR will come out with something concrete to evaluate, remaining issues can be resolved via that discussion
* [Changes to builtin modules](https://discourse.llvm.org/t/changes-to-builtin-modules/89072)
* PR was reverted due to buildbot failure involving Windows
* Reviewers asked for big changes, working on a compromise involving putting TODOs in other runtimes
* [\[RFC\] Support classic flang driver options in flang](https://discourse.llvm.org/t/rfc-support-classic-flang-driver-options-in-flang/89380)
* Suggestion was to accept the alternate spellings but give a deprecation warning immediately to encourage migrating to the regular spelling
* Tarun plans to put out a broader RFC to address the central issue in this and the following RFC in the next few weeks
* [\[RFC\] Support \-fstrict-aliasing and \-fno-strict-aliasing](https://discourse.llvm.org/t/rfc-support-fstrict-aliasing-and-fno-strict-aliasing/89135)
* Related issue: [https://github.com/llvm/llvm-project/issues/171912](https://github.com/llvm/llvm-project/issues/171912)
* We can’t do anything reasonable with it without violating the Fortran standard, will leave it open for a little while longer but likely will not support this
* [\[RFC\] Automatic static promotion of large local variables in Flang](https://discourse.llvm.org/t/rfc-automatic-static-promotion-of-large-local-variables-in-flang/89539)
* No updates on the call today
* Flang-tidy
* Meeting with authors has been deferred, will create meeting including Tarun Prabhu when Michael Klemm is back from travel
* [\`-ffp-contract=fast\` Violates the Fortran Standard](https://discourse.llvm.org/t/ffp-contract-fast-violates-the-fortran-standard/88897)
* Reply from the standards committee: [https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html](https://mailman.j3-fortran.org/pipermail/j3/2026-January/015531.html)
* The J3 opinion is now unanimous that parentheses and FMAs are perfectly compatible with the standard
* See [recently submitted J3 paper](http://26-115r1.txt)
* Remaining question is how to let users control the behavior that they want, implementation still needs to happen
* \-f(no)protect-parens is already an option in Flang
* Is this too heavy-handed for this situation?
* Question about LLVM backend implementation for this control, there are open issues on the LLVM side about it
* Call Notes questions
* These came from review in PR [\#180287](https://github.com/llvm/llvm-project/pull/180287)
* Should they appear in the Flang documentation website (i.e. should they be included in the HTML build)?
* What to do about references to Classic Flang?
* Ted \- in favor of removing them entirely
* Tarun \- include one single reference that states it is an entirely separate compiler and points to one website with further information
* PRs of Note
* Tests from Cray’s CCE internal test suite in llvm-test-suite \[[PR](https://github.com/llvm/llvm-test-suite/pull/326)\]
* Proposed directory structure with one test in linked PR
* This will be merged soon
* Pass for support for OpenMP and NVIDIA offload
* [https://github.com/llvm/llvm-project/pull/180058](https://github.com/llvm/llvm-project/pull/180058)
* [https://github.com/llvm/llvm-project/pull/180060](https://github.com/llvm/llvm-project/pull/180060)
* In need of reviewers on the Flang side, particularly for the second PR. MLIR side for the first PR.
* Issues of Note
* FYI
* [2026 EuroLLVM Developers' Meeting \- Agenda](https://discourse.llvm.org/t/2026-eurollvm-developers-meeting-agenda/89725)
* Michael Kruse is presenting “Creating a runtime using the LLVM\_ENABLE\_RUNTIMES system”
* The LLVM build system has a mechanism designed for building runtime libraries targeting the platform that compiler’s (be it Clang, Flang, Rust, etc. ) output will run on. For instance, since Clang intrinsically is a cross-compiler, such runtime libraries need to be compiled for each targeted platform. The mechanism originates from splitting target-side runtimes from host-side subprojects such as Clang, Polly, BOLT.
* [LLVM 22.1.0-rc3 Released\! \- Announcements](https://discourse.llvm.org/t/llvm-22-1-0-rc3-released/89769)
* Who is writing the [flang release notes](https://github.com/llvm/llvm-project/blob/release/22.x/flang/docs/ReleaseNotes.md)?
* [CFP: MLIR Workshop at the EuroLLVM Developer Meeting (Apr 13, 2026\)](https://discourse.llvm.org/t/cfp-mlir-workshop-at-the-eurollvm-developer-meeting-apr-13-2026/89790)
* Other topics as time allows
* Should these calls be longer and/or more frequent?
* Extending the call to 45 minutes
* Is there a way to add the event to [https://llvm.org/docs/GettingInvolved.html\#llvm-community-calendar](https://llvm.org/docs/GettingInvolved.html#llvm-community-calendar) ?
* Why doesn’t flang appear on the main page for [https://llvm.org/](https://llvm.org/) ?
* Who do we contact about this? General Discourse post?
## Details
* Consists of over **725,000** lines of code, documentation, build files, and test
* To date, over **11,767** commits have been made to Flang

34
flang/docs/MeetingNotes/README.md Normal file
View File

@@ -0,0 +1,34 @@
<!--===- docs/MeetingNotes/README.md
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->
# Combined Flang Community Call Notes
## About these notes
This directory combines the notes from the Flang Technical and Community Calls. This was done to make the call notes more easily available than before. All references to Flang in these documents refer to the Fortran compiler being developed as part of the LLVM project and located in the LLVM monorepo ([github.com/llvm/llvm-project](http://github.com/llvm/llvm-project)). Information about "Classic Flang", a separate and independent Fortran compiler, can be found at [github.com/flang-compiler/flang](http://github.com/flang-compiler/flang).
## Call Information
- Details about the call can be found in the [Getting Involved](https://flang.llvm.org/docs/GettingInvolved.html#flang-biweekly-call) page in flang's documentation.
## Flang Community
* **Websites:**
* **Flang:** [https://flang.llvm.org](https://flang.llvm.org)
* **Issues:**
* Issues for Flang should be reported in GitHub: [https://github.com/llvm/llvm-project/issues](https://github.com/llvm/llvm-project/issues). Please use the "flang" tag for flang-related issues.
* **LLVM mailing lists and Discourse channels:** There are now two communication channels hosted by llvm.org:
* The Flang Discourse channel (used primarily for discussions): [https://discourse.llvm.org/c/subprojects/flang/33](https://discourse.llvm.org/c/subprojects/flang/33)
* The flang-commits mailing list (used primarily for routine notifications): subscribe at [https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-commits](https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-commits)
* **Slack:** The [flang-compiler.slack.com](http://flang-compiler.slack.com)
workspace is used for informal real-time communication in the Flang community.
See the [Getting Involved](https://flang.llvm.org/docs/GettingInvolved.html#flang-slack-workspace) page in flang's documentation for instructions on joining the workspace.
* **Flang Development:**
* On GitHub: The source code for Flang is available on [https://github.com/llvm/llvm-project/tree/main/flang](https://github.com/llvm/llvm-project/tree/main/flang). It is recommended to start in the "docs" directory.

2
flang/docs/conf.py
View File

@@ -90,7 +90,7 @@ copyright = "2017-%d, The Flang Team" % date.today().year
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ["_build", "analyzer", "FIR/*"]
exclude_patterns = ["_build", "analyzer", "FIR/*", "MeetingNotes/*"]
# The reST default role (used for this markup: `text`) to use for all documents.
# default_role = None