Reviving rename flang-new to flang

That’s not how I read this thread.

In general, I find it puzzling that folks were fine with a bash script called flang (that would call another, unrelated compiler), but reject a proper, well-tested driver to be called flang. Instead, the driver in LLVM Flang is stuck with some enigmatic name which was only introduced temporarily to avoid a name clash.

If there is no consensus for a big change just yet, then we should work towards a compromise. Together.

That was suggested last year as an acceptable alternative, see this comment. Since we disagree what the compiler driver in Flang should be called, this change would at least allow everyone to decide for themselves.

-Andrzej

1 Like

Best I can tell,

is true, but I don’t see much evidence for

I’ve only seen 2, maybe 3 people express opposition to doing this now. I’ve heard from lots of potential users, including multiple super computing centers, that they would like to see this happen so that their applications of interest can finally get some insight into the progress of the compiler that DOE ECP has been promising them for years. The demand for this is there. Any attempt to claim “consensus” otherwise is a disingenuous attempt to mislead and subvert consensus for your own incentives.

2 Likes

Perhaps I phrased it backwards. There is no consensus to make the change.

https://llvm.org/docs/DeveloperPolicy.html#making-a-major-change

Note the call out of the development community & remember that consensus building is not a majority vote but a process.

@everythingfunctional I believe we’ve explained that everything needed to build and distribute flang to your community is available to you in llvm-project. I’m not sure why that’s not an acceptable solution for you to share with your community & gather the feedback that they are eager to provide. I’d appreciate a better understanding of why this path doesn’t meet your needs.

@banach-space The old flang script was very useful during the bring up of the front end. Now that lowering is upstream, I don’t find it useful. We did have consensus on your plan to update the project to allow developers to select their own driver name. I didn’t know that wasn’t committed. Maybe that old script could be changed to offer some advice about flang-new and some of its options?

Thank you for confirming.

We need a reviewer willing to OK that change. IMHO, all comments for ⚙ D125788 [flang][driver] Rename `flang-new` as `flang` have been addressed. IIUC, the outstanding request for changes from @clementval refers to this specific change in ToolChain.cpp:

      // Flang's driver name is configured with CMake's FLANG_USE_LEGACY_NAME.
      // Both `flang` and `flang-new` are currently supported, so there are 2
      // suffixes for Flang in this list. `flang-new` will be removed in the
      // future.
      {"flang", "--driver-mode=flang"},
      {"flang-new", "--driver-mode=flang"},

But I feel that I’ve provided sufficient justification that this is the cleanest and most frictionless approach.

-Andrzej

1 Like

It’s a strange day when intentionally obscuring the use of a software package with the expressed intent of discouraging its use qualifies as open-source development. @everythingfunctional gave a great example of what truly open development looks like in LFortran and described the resulting benefits. I’ll go further and say that one goal of the LFortran developers is to provide an early testbed for new features even before those features are in the standard. This provides a great service to the community.

I’ll also add the examples of gfortran and OpenCoarrays. Since around 2010, I’ve been involved in funding or otherwise facilitating the addition of a broad swath of modern Fortran features to gfortran and OpenCoarrays, including type finalization, submodules, user-defined derived-type input/output, parameterized derived types, coarrays, collective subroutines, events, teams, failed images, synchronization, and more. Throughout that time, features were available within 1-2 annual releases of the start of development even when the features were known to be incomplete. Providing early and easy access to the user community gave us helpful feedback. Sometimes even the lack of feedback speaks volumes: you don’t know whether most developers will use a feature until you’ve given them the option to do so without jumping through hoops. For example, I recently searched OpenCoarrays issues for sync memory and found only one mention of it in the 9 years since we opened the source.

Bottom line: if you’re going to develop open-source, do so in the open. Obscuring the software’s use in what is widely viewed as the central repository for the project is not playing well in the sandbox. It damages Flang and damages the Fortran community. @everythingfunctional and I have given three relevant examples to the contrary. It’s sad to see opposition to LLVM Flang doing the same.

3 Likes

yet, but that’s why we’re having the discussion, and what I’m trying to achieve. There is at least some support.

That’s true, but it also doesn’t require unanimous consent. E.g.

  1. A process of decision-making that seeks widespread agreement among group members.
  2. General agreement among the members of a given group or community, each of which exercises some discretion in decision-making and follow-up action

Most policies/procedures based on consensus I have seen require that opposing points have been addressed, but not that a unanimous agreement be reached. This prevents minority opposing voices from deadlocking progress. I believe I have addressed any concerns expressed, even if some still have a differing opinion. Specifically from the document you referenced:

  1. keep the community informed about future changes to LLVM,

I’ve been as open and public as I can about letting everyone know about this.

  1. avoid duplication of effort by preventing multiple parties working on the same thing and not knowing about it, and

I don’t think anybody is trying to do anything directly conflicting or duplicating this effort

  1. ensure that any technical issues around the proposed work are discussed and resolved before any significant work is done.

Any issues I’ve seen raised have not been technical, just social.

Yes, and if this effort fails, I will do so. But I’m still going to try and push this because it’s the right thing to do.

Because it’s still intentionally exclusionary, preventing the community from easily growing.

The initial feedback they’re providing is that they’d prefer to see this change upstream.

2 Likes

I haven’t seen any plan put forth describing how these new users will be supported, so I assume that the support plan is to have current developer community deal with newly reported problems. This isn’t really happening too well today, as one can see from the growing backlog of bugs on github. (Bugs are getting fixed, as I know from reviewing patches that I appreciate seeing, but incoming rate is higher.)

So, if we make this change now, I worry that Flang developers will be on the hook to ensure that new users will enjoy responsive support for their problems. I myself work far more efficiently when I’m resolving issues identified by small test cases, so I’d like to continue working in that mode for a few more weeks before switching to a mode of isolating and fixing problems in larger codes like the ones that these new users will present. But that’s just how I see things.

So here’s how you can get my support, if you want it, for the timing of this change. Either put forth a credible support strategy for the new users that doesn’t depend on the current active developers, or show support for doing this now from even a few of the potentially affected active developers (representing say just 10% or more of the lines of code in the flang/ subdirectory as reported by “git blame”).

1 Like

Do we need to use the LLVM Decision Making Process for this proposal?

You just made my day. @rouson and I have funding to do just that. We will promise to monitor bug reports related to flang, reach out to those submitting them and to collaborate on generating simple reproducers as necessary. We absolutely do not wish inundate current active developers with distractions or busy work, just to start building a larger user community. If you want a more formal plan, we can put it together. Does that satisfy your concerns?

1 Like

That sounds like a support strategy that still depends on the current active developer community to fix your bugs, and I told you how to convince me that they’re ready (edit: and willing) to take that on now.

Ok, I’ll modify my plan slightly.

and provide them with reasonable expectations that current active development may not have solving their issue as their current priority.

Also, @rouson, @ktras , myself, and some others working on our team at LBL, relatively new contributors (i.e. not current active developers), will work to provide fixes for the reported bugs.

I will also start reaching out to current developers reported by git blame to ask if they are willing to accept feedback from new users and a growing community.

As I said

so we commit to avoiding that.

1 Like

I’m leaning towards yes. I’d love to hear what other LLVM developers and community leaders think on the topic. It’s not exactly clear (to me), how to initiate it from here.

Let me take a stab at this…

I think what is really being discussed here is the determination of when Flang will have its first release candidate and what the feature set will be. IMHO, the name of the executable and command line arguments are symptomatic of this but alone won’t address them; a lot of the frustration appears to be issues with communication and a lack of information. Apologies, but I think these are the critical topics for us to discuss.

Regarding the first release: To test Flang’s latest status you need to use the main branch of llvm-project. This has the caveat of bringing along the active state of the entire project. Unless you are experience with the infrastructure, using the main branch for general/end-user testing is asking for trouble. If someone is enthusiastic and understands what they are testing from end-to-end, I’m not against such efforts but I think this testing would be most effective in the release candidate and point-release phases. YMMV but I would consider this much more concerning in the grand scheme of things than the name of the executable.

Understanding this means we need to agree on what it explicitly means for Flang to reach its first release. @sscalpone has suggested some criteria. Are there others? I would suggest we focus on this as I think it is more constructive for the community in both the short and long term. To kick this idea off, I’d like to propose we start a “status notes” document at the top-level of the Flang repo that highlights a target feature set and any other criteria for the first release candidate. We can then track these details aligned with the LLVM release cycle. If we can keep this on target for each release in the LLVM cycle it will help communicate to both developers and potential users a more concrete view of our efforts. Hopefully, this could also addresses a portion of @banach-space’s concerns re: documentation.

The second challenge is testing. The lack of an open, robust test suite for Flang is problematic. I would say more in the impact it has on project-wide communications than testing itself at this point in time. The closed testing infrastructure was done to expedite the testing that was desperately needed to harden and stand Flang up. Unfortunately, the nature of the situation means the test features are not visible to the broad community. The only obvious way I see to address this is to provide one or more alternative paths. E.g., the gfortran piece mentioned by @kiranchandramohan, the NIST test suite – although it has older Fortran, and perhaps Fortran-centric OpenMP tests would all be good starting places). This suite could also capture key features that the applications @everythingfunctional and @rouson mention so key features are more visible to the entire community and can be more easily discussed in a community setting (vs. entire applications that compiler folks are unlikely to focus on). Without an alternative set of tests I think we will continue to struggle with visibility, constructively grow the community, and setting project-wide priorities for the foreseeable future.

Maybe I’ve simply stared at this discussion for too many days in a row but this was where I ended up. Hopefully we can find a constructive set of next steps…

–Pat

2 Likes

@pat thanks for the guidance and suggestions. To make sure I understand, when you mention placing " a ‘status notes’ document at the top-level of the Flang repo," I’m imagining a STATUS.md file with checkboxes in the flang/ subdirectory of llvm-project repository on GitHub. That would be helpful as long as it’s maintained and referenced prominently in flang/README.md and if the items on the checklist are grouped under release milestones. What I think would be more maintainable and provide a much richer experience would be a GitHub project board similar to Semantic Tests for Parallel Features project board. In keeping with the theme of your message, the name of the new project could be “First Release Candidate.” The project board could group GitHub issues into columns with headings such as “To Do,” “Under Development,” “In Code Review,” and “On LLVM main.” This provides a lot more functionality than just a status list. For example, a GitHub project can be set up such that

  1. Every issue tagged with the project name automatically appears in the “To Do” column on the project board,
  2. Every issue assigned to a developer automatically moves to the “Under Development” column on the project board,
  3. Commit messages that contain text like “fixes #42” can automatically trigger the closing of the corresponding issue when the commit is pushed to the main branch, and
  4. Every issue closed moves to the “On LLVM main” column on the project board.

Moreover, developer discussions can be tracked as comments on the issues. Seeing such discussions in the open is really important. The lack of visibility into what’s happening has caused some in the Fortran community to express pessimism publicly about seeing anything useful from LLVM Flang anytime soon. See this recent comment in the Fortran-lang Discourse. Most Fortran programmers don’t fully appreciate the monumental amount of work that has happened and continues to happen in developing LLVM Flang.

The approach that I’m suggesting invites a broader group of people into the discussion. Users might offer comments on the relative importance of certain optimizations or features that can help prioritize development. Some users might even roll up their sleeves and contribute code. On the OpenCoarrays project, we’ve seen this happen several times over the years when we received unsolicited bug fixes and new features from people we didn’t know prior to their contributions.

Lastly, the project board gives a rough sense of the percent completion based on the number of issues in each of the various columns. It’s not perfect because the list is likely to grow as new work items are discovered and not every issue requires the same amount of development time, but it’s still useful information for the potential user community in an open-source project. I hope these ideas are helpful.

As @kiranchandramohan mentioned earlier, there is such a board but it was started recently and it is very incomplete. https://github.com/orgs/llvm/projects/12/views/1

The LLVM release 16.0.0 is just around the corner. The next release, 17.0.0 will be in 6 month.

Do you want to ship flang or flang-new with LLVM 17?

IMO this is completely orthogonal to what the name and usability of the executable is during development.

My point is that at present, there’s more to it than that. If you are interested in joining development of Flang, you’d think that (and in my experience with other projects) it would be straightforward to try out the latest version; i.e. you clone the official repo, follow the build instructions, and get something potentially usable by a non-developer (i.e. you don’t need to know special names and hidden options). I don’t mean it won’t have missing features or bugs, but it shouldn’t present itself differently just because it’s not “done”.

Yes, and some manual testing from potential new contributors and users can assist in that endeavor. If you’re intentionally excluding them from early testing and feedback, you’re completely missing the bugs and features they might care about (or at least you can’t be sure).

Even with an alternative set of tests, if you have barriers to entry for potential new contributors or users (i.e. if you are not in “the club” and know “the secret handshake”), you will continue to struggle with these things.

Is there any plans to have a flang executable at all included with the 16 release? What are the chances of having one for the 17 release?

My main point has always been that these artificial barriers to early use are exclusionary, are preventing you from getting useful early feedback, and are turning potential contributors away. The sooner the official/upstream repository can stop this the better (IMO).

1 Like

You can download flang packages for the current rc:

It is unlikely that 16 ships with flang instead of flang-new. It is up to you which name flang will have in 17.

As the FreeBSD port maintainer for LLVM I’m giving serious consideration to applying ⚙ D143592 [flang][driver] Rename `flang-new -flang-experimental-exec` to `flang` to our release. The other realistic option is to disable flang in the default config which means no packages.

3 Likes

@rouson: My goal was to try and find a simple way to reach the community so there is a quick way to understand what is happening and where things stand in terms of a release candidate. Nothing less, nothing more. I’m hesitant to take on anything more complex until we can find a simple way to communicate these aspects so we can come to agreement on what the feature set for the first RC will be and do the work to bring it to reality.

1 Like