[flang][driver] Rename `flang-new` as `flang`

[awarzynski]

Summary

This patch _conditionally_ renames flang-new as flang. This is controlled with the FLANG_USE_LEGACY_NAME Cmake option, which by default is set to ON. This means that by default, the driver executable will still be called flang-new. If you want to use the updated name, flang, set FLANG_USE_LEGACY_NAME to OFF when configuring LLVM Flang. No other set-up is required.

Similarly to Clang, Flang's driver executable will be called flang{-new}-<MAJOR_VERSION> and flang{-new} will be a symlink to flang{-new}-<MAJOR_VERSION>.

[DavidSpickett]

Do you know how this will work with the llvm-testsuite runs that currrently use gfortran for codegen? Here is one we have: https://lab.llvm.org/buildbot/#/builders/179/builds/3694

Currently:

2022-05-17 13:06:53 INFO: Execute: /usr/bin/cmake -DCMAKE_C_COMPILER:FILEPATH=/home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/clang -DCMAKE_CXX_COMPILER:FILEPATH=/home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/clang++ /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/test/test-suite -DCMAKE_C_FLAGS=-mcpu=cortex-a57 -DCMAKE_C_FLAGS_DEBUG= -DCMAKE_C_FLAGS_MINSIZEREL= -DCMAKE_C_FLAGS_RELEASE= -DCMAKE_C_FLAGS_RELWITHDEBINFO= -DCMAKE_CXX_FLAGS=-mcpu=cortex-a57 -DCMAKE_CXX_FLAGS_DEBUG= -DCMAKE_CXX_FLAGS_MINSIZEREL= -DCMAKE_CXX_FLAGS_RELEASE= -DCMAKE_CXX_FLAGS_RELWITHDEBINFO= -DTEST_SUITE_FORTRAN:STRING=ON -DCMAKE_Fortran_COMPILER=/home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang
<...>
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang
-- Check for working Fortran compiler: /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Checking whether /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang supports Fortran 90
-- Checking whether /home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang supports Fortran 90 -- yes

Can we expect the current flang-new, soon to be flang to also cope with these tests (I have no expectations myself here, fine if not) or should we move the bots to use flang-to-gfortran?

[awarzynski]

In D125788#3519297, @DavidSpickett wrote:

Can we expect the current flang-new, soon to be flang to also cope with these tests (I have no expectations myself here, fine if not) or should we move the bots to use flang-to-gfortran?

Great point, thank for highlighting it! Moving the bots to flang-to-gfortran would make most sense. I can split this change into two patches so that there's no disruption from the buildbot perspective:

• patch 1: rename flang as flang-to-gfortran, but keep flang as an alias for flang-to-gfortran,
• patch 2: all the remaining changes from this patch.

Once "patch 1" is merged, we can update the buildbot config to use flang-to-gfortran. After that, we could land "patch 2".

[DavidSpickett]

Sounds good to me. https://reviews.llvm.org/D125796 for the bot side, let me know if/when the first half of the change goes in.

I'll leave it to others to approve the change overall. I do think being able to do ./bin/flang and get the right flang will save a lot of confusion but I'm not a user of either of them myself.

[h-vetinari]

Very happy to see this finally happening! :)

[kiranchandramohan]

LGTM. In the call on Monday, it was mentioned that the original users of the flang script have moved on to using a custom driver.

It will be a good idea to,
-> wait for the author of the original script and the throwaway driver, @sscalpone.
-> clarify that execution is still restricted to developers via a flag. We hope to open it to users later in the year.

My personal preference for the renaming is flang-to-external-fc since it is not specific to gfortran.

flang/tools/flang-driver/CMakeLists.txt

55

Nit: backwords -> backwards

[awarzynski]

In D125788#3519403, @DavidSpickett wrote:

Sounds good to me. https://reviews.llvm.org/D125796 for the bot side, let me know if/when the first half of the change goes in.

https://reviews.llvm.org/D125832 for "patch 1".

In D125788#3521487, @kiranchandramohan wrote:

It will be a good idea to,
-> wait for the author of the original script and the throwaway driver, @sscalpone.

👍🏻

-> clarify that execution is still restricted to developers via a flag.

👍🏻 Nothing changes with regard to the compiler flags (there are no functional changes here, just the renaming).

My personal preference for the renaming is flang-to-external-fc since it is not specific to gfortran.

Makes sense, I can rename it.

[awarzynski]

Rename flang-to-gfortran as flang-to-external-fc

I will also make this change depend on https://reviews.llvm.org/D125832

[shraiysh]

clarify that execution is still restricted to developers via a flag.

Just confirming what this means: After this patch, would flang sample.f90 generate an executable? If not, how to generate an executable using flang-new? If yes, does this mean that if I just replace classic-flang with new llvm flang (along with library and include paths), I should be able to find and report bugs (expected) or run the application (best case)?

[kiranchandramohan]

In D125788#3523259, @shraiysh wrote:

clarify that execution is still restricted to developers via a flag.

Just confirming what this means: After this patch, would flang sample.f90 generate an executable? If not, how to generate an executable using flang-new? If yes, does this mean that if I just replace classic-flang with new llvm flang (along with library and include paths), I should be able to find and report bugs (expected) or run the application (best case)?

Sorry, the point I was trying to say here is that till now the flang script will parse, unparse and call an external compiler to do the codegen/generate executable. With this change the flang driver will not generate an executable unless it is built with an option. This default behaviour might be seen as a regression from the point of view of a flang script user.

[shraiysh]

With this change the flang driver will not generate an executable unless it is built with an option.

Okay, thank you for the clarification. Is this a cmake option and? Are we documenting this somewhere except this patch summary, like on the flang documentation or something? Apologies if this a repetition to what you meant by clarifying that it is available via a flag.

[rouson]

I think this is an exciting step. I hope it gets approved. Although it's technically true that this could appear to be a regression for current flang script users, the ultimate compilation currently happens by invoking an external compiler so most current flang script users can eliminate the regression by simply calling the external compiler. The exception would be if the current flang script user specifically wants flang's parsing capabilities for checking code correctness (do we know if anyone is using the flang script that way?) or for testing the parser (which I presume can still happen by other means). It might be nice to simply rename the current script so those who want it can simply change the name they use to invoke it.

[kiranchandramohan]

In D125788#3523408, @shraiysh wrote:

With this change the flang driver will not generate an executable unless it is built with an option.

Okay, thank you for the clarification. Is this a cmake option and? Are we documenting this somewhere except this patch summary, like on the flang documentation or something? Apologies if this a repetition to what you meant by clarifying that it is available via a flag.

I think it is a driver flag -flang-experimental-exec. I was only requesting the add this information to the patch summary. If you feel it should be present somewhere else then please add a separate comment.

Some users might have been blindly running flang before without being aware that the script was calling an external compiler to generated code/executable. This change introduces the lowering flow and the users might see different results,
-> TODO messages for 2003 and above features.
-> Unexpected ICEs or miscomparisons.
-> Not producing an executable.

In D125788#3523443, @rouson wrote:

I think this is an exciting step. I hope it gets approved. Although it's technically true that this could appear to be a regression for current flang script users, the ultimate compilation currently happens by invoking an external compiler so most current flang script users can eliminate the regression by simply calling the external compiler. The exception would be if the current flang script user specifically wants flang's parsing capabilities for checking code correctness (do we know if anyone is using the flang script that way?) or for testing the parser (which I presume can still happen by other means). It might be nice to simply rename the current script so those who want it can simply change the name they use to invoke it.

Yes, the user can use flang-to-external-fc if they want the old flow. But this change might be a surprise for the user hence the request to add the relevant information to the summary.

[awarzynski]

Update documentation

[awarzynski]

Summary updated :)

In D125788#3524338, @kiranchandramohan wrote:

I think it is a driver flag -flang-experimental-exec. I was only requesting the add this information to the patch summary. If you feel it should be present somewhere else then please add a separate comment.

The flag is deliberately not being "advertised" - that was the compromise that we agreed on in https://reviews.llvm.org/D122008. Personally, I would really like to document it and make it more visible, but I don't want anyone to feel that their reservations are being ignored.

In D125788#3524338, @kiranchandramohan wrote:

Some users might have been blindly running flang before without being aware that the script was calling an external compiler to generated code/executable.

A while back we added documentation to clarify this. The bash script (which is the most confusing part) is documented here (that's being updated here). I'm not sure whether there's anything else that we could improve 🤔.

In D125788#3523443, @rouson wrote:

I think this is an exciting step.

Thank you!

Although it's technically true that this could appear to be a regression for current flang script users, the ultimate compilation currently happens by invoking an external compiler so most current flang script users can eliminate the regression by simply calling the external compiler.

I agree :)

[sscalpone]

My belief is that we should wait until f18 hits a reasonable quality bar for executables before making flang-new the default. My reasoning seems not to have carried the day.

[rouson]

In D125788#3534482, @sscalpone wrote:

My belief is that we should wait until f18 hits a reasonable quality bar for executables before making flang-new the default. My reasoning seems not to have carried the day.

It would hep to have a well-defined quality bar, e.g., a standards-based test suite or a collection of application test suites or the progress bar on the relevant GitHub project pages. We could then discuss and vote on which point on the quality bar suffices.

[sscalpone]

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

My preference is to use the NAG test suite. It is not freely available.

[peixin]

In D125788#3535199, @sscalpone wrote:

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

My preference is to use the NAG test suite. It is not freely available.

I tested a lot of test cases (mostly Fortran 95 code) and have several detailed questions about the reasonable quality bar.

1. Should some incorrect execution results be changed into one TODO if there is no plan to support it soon? One example is derived type array in forall (https://github.com/flang-compiler/f18-llvm-project/issues/1598).

2. What if the case fails in lowering with a "fatal internal error", but the real reason is the incorrect semantic analysis? Should it either be supported, or be turned from the "fatal internal error" into TODO?

3. What about the edge cases? For those with incorrect execution results, turn them into TODO? One example is D125632.

4. What about some dangerous usage? Usually, gfortran can report a lot of warnings for the dangerous scenarios such as string length mismatch, external procedure type kind mismatch, the test case in D125891, etc. Maybe this is not in priority.

5. Are the rules also applied to Fortran 2003, 2008 and 2018 code, or only restricted to Fortran 95 code?

[kiranchandramohan]

In D125788#3535199, @sscalpone wrote:

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

My preference is to use the NAG test suite. It is not freely available.

I strongly suspect that you might be able to win over some of the folks by sharing the status/list of failures/list of issues to be fixed for getting the NAG test suite to pass. As I have mentioned before, at least the companies involved have access to the NAG testsuite. The community can probably help you achieve the outlined goals faster. It can also help focus our efforts. Some of our engineers have now worked with f18/flang for some time. While some issues might require a fix by the experts, many can be fixed by others.

A separate issue we have is that it is not clear which branch is it that is being used for testing with NAG. Since many fixes have landed in llvm-project/flang, I assume that fir-dev is now out of date. While most of upstreaming is complete there is still a bit of things left to upstream, should not take much time though.

[rouson]

+1 @kiranchandramohan

I have access to the NAG Fortran compiler and find it very helpful for checking standard conformance. I was unaware of the NAG test suite and don't see any mention of it online. Is it an official product that can be purchased?

[sscalpone]

Recommend that you contact NAG for more info on the test suite. Here's the only reference that I could find: https://fortran-lang.discourse.group/t/fortran-compiler-testing-framework/1573/10

[awarzynski]

Thank you all for your comments and apologies for going radio silent - I was away for a few days.

I've identified 2 threads emerging from your comments:

1. flang vs flang-new
@sscalpone, if I understand correctly, you are suggesting that any tool named flang in "LLVM Flang" should satisfy the following condition:

2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

Indeed, flang-new does not satisfy this yet, but neither does flang, the bash wrapper script. flang, the bash script, calls flang-new to run parsing and semantic analysis. Basically, it's the same Fortran frontend as far as these initial phases are concerned. So, if "LLVM Flang" is missing diagnostics for e.g. unsupported language features, both flang and flang-new will fail to report these. I don't see how defaulting to flang (the bash script) instead of flang-new (the compiler driver) helps here.

Put differently, if the above condition is to be considered a requirement for any tool called flang, then the bash wrapper script should be renamed as it does not satisfy it.

2. NAG test suite
From what I recall, we did discuss renaming flang-new as flang in the past and it was decided that we would wait for flang-new to be able to generate executables. I couldn't find this written down, so perhaps I'm misremembering? In any case, I don't follow why a test-suite conformance should determine what name is used for a compiler driver in "LLVM Flang". We should definitely work towards 100% pass rate, but to me that's orthogonal to how our tools are called. The level of Language support in "LLVM Flang" should be communicated through the documentation (including release notes) instead of misleading tool names.

As for NAG test-suite specifically:

My preference is to use the NAG test suite. It is not freely available.

If we take this path, we will effectively be introducing yet another dependency on an external project in "LLVM Flang" (libpgmath being the first one). While most (perhaps all?) salaried "LLVM Flang" developers will have access to the NAG test suite, community volunteers will effectively have their ability to contribute severely limited. I'm against this, but also don't have a counter-proposal (I'm not aware of any freely accessible Fortran test suites that we could use here).

@peixin, you raised some really good points, thank you! I agree that even if it is decided that the NAG test suite is used as the benchmark for "LLVM Flang", it's still unclear how to deal with all these tricky corner cases (there will be platform dependencies too). As for the following one:

5. Are the rules also applied to Fortran 2003, 2008 and 2018 code, or only restricted to Fortran 95 code?

I think that we should limit ourselves to Fortran 95 for now - there's no code-gen support beyond that.

NEXT STEPS
Based on the above, how would you feel about the following:

1. Lets rename flang as flang-to-external-fc regardless of what's decided for flang-new. That would already be a huge step forward (and would reflect accurately what the bash wrapper script actually does).
2. As for the NAG test suite, I hope that we can agree not to use it as the condition for renaming flang-new. If it's decided that that's a valid requirement, then I agree with @kiranchandramohan that we should find a way to openly track the progress towards the required pass rate (and how that's defined).

Perhaps we could discuss more in the call today?

[sscalpone]

I'm fine with removing or renaming the existing flang shell script.

My proposal is not to wait for a 100% pass rate. My proposal is to wait until the messages for unimplemented features are converted to TODOs that reference the program's source line and that legal programs which compile and link will execute without error. In short, what flang compiles should work, and what flang doesn't compile should offer a reasonable message to the user to understand the limitation.

This proposal is not restricted to F95 but to any source that someone might attempt to compile.

[rouson]

On Mon, May 30, 2022 at 2:39 AM Andrzej Warzynski via Phabricator <[e-mail]> wrote:

1. Lets rename flang as flang-to-external-fc regardless of what's decided for flang-new. That would already be a huge step forward (and > would reflect accurately what the bash wrapper script actually does).

I support this. I think the proposed new name is better reflects what the current flang script currently does and thereby reduces the likelihood of surprise when a user sees an error message from an external compiler.

2. As for the NAG test suite, I hope that we can agree not to use it as the condition for renaming flang-new. If it's decided that that's a valid > equirement, then I agree with @kiranchandramohan that we should find a way to openly track the progress towards the required pass rate

(and how that's defined).

I agree.

Perhaps we could discuss more in the call today?

Any news from the call?

Damian

[awarzynski]

In D125788#3547494, @sscalpone wrote:

I'm fine with removing or renaming the existing flang shell script.

In D125788#3547656, @rouson wrote:

On Mon, May 30, 2022 at 2:39 AM Andrzej Warzynski via Phabricator <[e-mail]> wrote:
I support this.

Great, thank you both! "Step 1" merged: https://reviews.llvm.org/D125832. This leaves us with flang as a symlink pointing to flang-to-external-fc, which I will be removing once buildbots are reconfigured: https://reviews.llvm.org/D125796. I'd like this to happen soon.

In D125788#3547494, @sscalpone wrote:

This proposal is not restricted to F95 but to any source that someone might attempt to compile.

I would really appreciate if we could agree on more specific criteria. IMHO, "any source" leaves too much room for interpretation.

In D125788#3547656, @rouson wrote:

Any news from the call?

Not much - it was a very quiet call (Memorial Day for some folks, ISC 2022 for others, unexpected hiccup with Teams for the rest ). We decided to re-visit in the next call.

Next steps
Just to avoid any confusion:

• flang, the bash script, will be renamed as flang-to-external-fc (see D125832)
• flang-new won't be renamed just yet - perhaps we could discuss more in the forthcoming call(s)?

[awarzynski]

In the call yesterday it was proposed that we add a CMake option that will control the name of the driver. I suggest adding FLANG_USE_LEGACY_NAME:

• when set to ON, the driver binary will be called flang-new,
• when set to OFF, the driver binary will be called flang.

With this approach, everyone will be able to select the preferred driver name. Note that:

• this will affect both the build and installation targets,
• LLVM's testing infrastructure will automatically choose between flang and flang-new (based on FLANG_USE_LEGACY_NAME),
• you won't be required to perform any extra steps (in fact, you will be able to continue with your current workflows).

It was requested that the default value is set to ON (i.e. the default name for the driver executable in LLVM Flang will remain flang-new).

Later today I will upload a new version of this patch that implements the above. As for changing the default to flang (i.e. setting the default for FLANG_USE_LEGACY_NAME to OFF), the following remains a blocker:

In D125788#3535199, @sscalpone wrote:

My proposal is:

If the compiler compiles it, it ought to run.
If the compiler can't compile it, it ought to clearly say why.

1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

My preference is to use the NAG test suite. It is not freely available.

We did discuss replacing NAG with e.g. SNAP + SPEC, but we run out of time and haven't concluded that part.

As always, please comment if I missed or misread anything!

Next steps
I will update this patch by introducing FLANG_USE_LEGACY_NAME CMake option - it will control the name of the generated driver executable.

[awarzynski]

Add the FLANG_USE_LEGACY_NAME cmake option that will control the name of the driver executable.

[peixin]

In summary:

If you want to use the updated name, flang, set FLANG_USE_LEGACY_NAME to ON when configuring LLVM Flang.

OFF?

[awarzynski]

In D125788#3612533, @peixin wrote:

In summary:

If you want to use the updated name, flang, set FLANG_USE_LEGACY_NAME to ON when configuring LLVM Flang.

OFF?

Updated, thanks!

[clementval]

clang/lib/Driver/ToolChain.cpp

189

Why do we need two lines here? Shouldn't we have a single line with the name chosen by the cmake option?

clang/lib/Driver/ToolChains/Flang.cpp

161–165

flang/CMakeLists.txt

411

Maybe add a comment that says what is the legacy name.

flang/test/lit.cfg.py

87

Is this the correct indentation?

[awarzynski]

clang/lib/Driver/ToolChain.cpp

189

That would require making this file "configurable" by CMake. That would be quite an intrusive design change, which IMO we should avoid.

Unless there's some easy way that I'm missing here?

[awarzynski]

Incorporate @clementval 's suggestions

[clementval]

Overall the patch looks ok from a technical point. Shouldn't we just wait until we can make the permanent renaming so we do not add unnecessary cmake option?

[awarzynski]

Thank your for reviewing @clementval !

In D125788#3621585, @clementval wrote:

Shouldn't we just wait until we can make the permanent renaming so we do not add unnecessary cmake option?

This was discussed in one of our calls. As we weren't able to agree on any specific time-frames, the CMake route was proposed instead. This was suggested by @sscalpone as an acceptable compromise. From what I recall, there were no objections to this.

flang-new has always been intended as a temporary name for the compiler driver. That's because flang was reserved for the bash script. The bash script has recently been renamed as flang-to-external-fc ( D125832) so we are free to repurpose that name. As I tried to explain earlier, these names (flang-new vs flang) have always been very confusing to people and we are trying to improve and to clarify that, step by step. While this approach is not ideal, it gives us the flexibility to choose our preferred name sooner rather than later. If you feel that we should keep flang-new, you can continue using/building LLVM Flang as you have been so far. If you are ready to update the driver name, the CMake option enables that for you.

We discussed this in our call on Monday and agreed to go ahead provided that this change is technically sound. IIUC, this has now been confirmed:

Overall the patch looks ok from a technical point.

As always, please correct me if I missed or misinterpreted something!

[clementval]

clang/lib/Driver/ToolChain.cpp

189

This is counter intuitive. We rename flang-new but we add flang-new here. It should be configurable.

[richard.barton.arm]

clang/lib/Driver/ToolChain.cpp

189

This is a list of all the valid prefixes of binaries that the driver supports. With this change, an additional one will be supported so I don't think it's an issue to have both flang and flang-new here.

The thing that confuses me is how flang-new works today without this change, given that "flang" is not a suffix of "flang-new"? @awarzynski , do you know why that is? Perhaps the line here is not needed at all? Or is this a bug fix for flang-new that is actually unrelated to this change?

[awarzynski]

clang/lib/Driver/ToolChain.cpp

189

This is counter intuitive.

I can add a comment to clarify this.

It should be configurable.

It is, in Flang's driver.cpp. Originally, the suffix was hard-coded as:

clang::driver::ParsedClangName targetandMode("flang", "--driver-mode=flang");

(i.e. the clangDriver library used flang internally despite the actual name being flang-new). This is now being replaced with (see in "driver.cpp"):

clang::driver::ParsedClangName targetandMode =
     clang::driver::ToolChain::getTargetAndModeFromProgramName(argv[0]);

But the change in "driver.cpp" means that we can no longer make assumptions about the suffix and hence the update here.

Like I mentioned earlier, we should not make this file build-time configurable. One possible option would be to try to update Clang's config.h.cmake, but that's would lead to more Flang-specific changes in Clang's core set-up. Also, I'm not convinced it would work here.

@awarzynski , do you know why that is?

Yeah, check Flang's "driver.cpp". We should've captured this earlier. The original set-up from ToolChain.cpp predates flang-new. And then in "driver.cpp" we just matched what was here. There was a lot of confusion around naming back then and this has slipped in.

[clementval]

clang/lib/Driver/ToolChain.cpp

189

This is counter intuitive.

I can add a comment to clarify this.

There should be at least a comment here.

Like I mentioned earlier, we should not make this file build-time configurable. One possible option would be to try to update Clang's config.h.cmake, but that's would lead to more Flang-specific changes in Clang's core set-up. Also, I'm not convinced it would work here.

If it cannot be configurable I think this is a good reason to wait a bit and make a direct renaming without all the options and duplicate.

[clementval]

In D125788#3621744, @awarzynski wrote:

We discussed this in our call on Monday and agreed to go ahead provided that this change is technically sound. IIUC, this has now been confirmed:

Overall the patch looks ok from a technical point.

As always, please correct me if I missed or misinterpreted something!

I still have reserved on this patch so please do not take my "Overall the patch looks ok from a technical point." as an approval. There are open discussion so wait for other to confirm or not.

[awarzynski]

Add a comment

[awarzynski]

In D125788#3622274, @clementval wrote:

There are open discussion so wait for other to confirm or not.

I was under the impression that we did discuss this extensively in our community calls and agreed to proceed with it. At least that's how I recall it.

I am abandoning this change as I'm distracted with other tasks at the moment, but I am still strongly in favor of this. Please, feel free to commandeer this patch and continue the discussion. I will try my best to help with reviews.

[MaskRay]

If you continue this work, consider landing this rename in multiple phases, e.g.

• Use lit substitutions instead of flang-new and other preparatory stuff so that the next step has very little change
• (lightweight) change flang-new to flang and add flang-new as a symlink for compatibility
• perform other post-migration cleanup
• (lightweight) remove the symlink flang-new, when it is no longer used both in-tree and for significant downstream users that need time for migration

Many build bots can fail in weird ways and ensuring that we will not revert a large change prevents causing churn to the tests.

[awarzynski]

In D125788#4556324, @MaskRay wrote:

If you continue this work, consider landing this rename in multiple phases, e.g.

• Use lit substitutions instead of flang-new and other preparatory stuff so that the next step has very little change
• change flang-new to flang and add flang-new as a symlink for compatibility
• remove the symlink flang-new, when it is no longer used.

Many build bots can fail in weird ways and ensuring that we will not revert a large change prevents causing churn to the tests.

Thank you, these are great pointers! CC @everythingfunctional

clang/lib/Driver/Driver.cpp

void Driver::PrintHelp(bool ShowHidden) const {
   std::string Usage = llvm::formatv("{0} [options] file...", Name).str();
   getOpts().printHelp(llvm::outs(), Usage.c_str(), DriverTitle.c_str(),
                       IncludedFlagsBitmask, ExcludedFlagsBitmask,
                       /*ShowAllAliases=*/false);
 }
 
 void Driver::PrintVersion(const Compilation &C, raw_ostream &OS) const {
   if (IsFlangMode()) {
-    OS << getClangToolFullVersion("flang-new") << '\n';
+    OS << getClangToolFullVersion("flang") << '\n';
   } else {
     // FIXME: The following handlers should use a callback mechanism, we don't
     // know what the client would like to do.
     OS << getClangFullVersion() << '\n';
   }
   const ToolChain &TC = C.getDefaultToolChain();
   OS << "Target: " << TC.getTripleString() << '\n';
 

clang/lib/Driver/ToolChain.cpp

static const DriverSuffix DriverSuffixes[] = {
       {"clang-cpp", "--driver-mode=cpp"},
       {"clang-g++", "--driver-mode=g++"},
       {"clang-gcc", nullptr},
       {"clang-cl", "--driver-mode=cl"},
       {"cc", nullptr},
       {"cpp", "--driver-mode=cpp"},
       {"cl", "--driver-mode=cl"},
       {"++", "--driver-mode=g++"},
+      // 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"},
       {"clang-dxc", "--driver-mode=dxc"},
   };
 
   for (size_t i = 0; i < llvm::array_lengthof(DriverSuffixes); ++i) {
     StringRef Suffix(DriverSuffixes[i].Suffix);
     if (ProgName.endswith(Suffix)) {
       Pos = ProgName.size() - Suffix.size();
       return &DriverSuffixes[i];

clang/lib/Driver/ToolChains/Flang.cpp

void Flang::ConstructJob(Compilation &C, const JobAction &JA,
   }
 
   assert(Input.isFilename() && "Invalid input.");
 
   addDashXForInput(Args, Input, CmdArgs);
 
   CmdArgs.push_back(Input.getFilename());
 
-  // TODO: Replace flang-new with flang once the new driver replaces the
-  // throwaway driver
-  const char *Exec = Args.MakeArgString(D.GetProgramPath("flang-new", TC));
+  // Get the name of this executable. The `getClangProgramPath` hook predates
+  // Flang, hence the name assumes that it's a Clang program. In practice, it
+  // can be any program (e.g. a Flang program) implemented in terms of
+  // `clangDriver`.
+  const char *Exec = D.getClangProgramPath();
   C.addCommand(std::make_unique<Command>(JA, *this,
                                          ResponseFileSupport::AtFileUTF8(),
                                          Exec, CmdArgs, Inputs, Output));
 }
 
-Flang::Flang(const ToolChain &TC) : Tool("flang-new", "flang frontend", TC) {}
+Flang::Flang(const ToolChain &TC) : Tool("flang", "flang frontend", TC) {}
 
 Flang::~Flang() {}

clang/test/Driver/flang/flang.f90

 ! Check that flang -fc1 is invoked when in --driver-mode=flang.
 
 ! This is a copy of flang_ucase.F90 because the driver has logic in it which
 ! differentiates between F90 and f90 files. Flang will not treat these files
 ! differently.
 
 ! Test various output types:
 ! * -E
 ! * -fsyntax-only
 ! * -emit-llvm -S
 ! * -emit-llvm
 ! * -S
 ! * (no type specified, resulting in an object file)
 
 ! All invocations should begin with flang -fc1, consume up to here.
-! ALL-LABEL: "{{[^"]*}}flang-new" "-fc1"
+! ALL-LABEL: "{{[^"]*}}flang" "-fc1"
 
 ! Check that f90 files are not treated as "previously preprocessed"
 ! ... in --driver-mode=flang.
 ! RUN: %clang --driver-mode=flang -### -E                  %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-E %s
 ! CHECK-E-NOT: previously preprocessed input
 ! CHECK-E-DAG: "-E"
 ! CHECK-E-DAG: "-o" "-"
 

clang/test/Driver/flang/flang_ucase.F90

 ! Check that flang -fc1 is invoked when in --driver-mode=flang.
 
 ! This is a copy of flang.f90 because the driver has logic in it which
 ! differentiates between F90 and f90 files. Flang will not treat these files
 ! differently.
 
 ! Test various output types:
 ! * -E
 ! * -fsyntax-only
 ! * -emit-llvm -S
 ! * -emit-llvm
 ! * -S
 ! * (no type specified, resulting in an object file)
 
 ! All invocations should begin with flang -fc1, consume up to here.
-! ALL-LABEL: "{{[^"]*}}flang-new" "-fc1"
+! ALL-LABEL: "{{[^"]*}}flang" "-fc1"
 
 ! Check that f90 files are not treated as "previously preprocessed"
 ! ... in --driver-mode=flang.
 ! RUN: %clang --driver-mode=flang -### -E                  %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-E %s
 ! CHECK-E-NOT: previously preprocessed input
 ! CHECK-E-DAG: "-E"
 ! CHECK-E-DAG: "-o" "-"
 

clang/test/Driver/flang/multiple-inputs-mixed.f90

 ! Check that flang can handle mixed C and fortran inputs.
 
 ! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/other.c 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new{{[^"/]*}}" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang{{[^"/]*}}" "-fc1"
 ! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
 ! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}clang{{[^"/]*}}" "-cc1"
 ! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/other.c"

clang/test/Driver/flang/multiple-inputs.f90

 ! Check that flang driver can handle multiple inputs at once.
 
 ! RUN: %clang --driver-mode=flang -### -fsyntax-only %S/Inputs/one.f90 %S/Inputs/two.f90 2>&1 | FileCheck --check-prefixes=CHECK-SYNTAX-ONLY %s
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
 ! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
-! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang-new" "-fc1"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
 ! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"

flang/CMakeLists.txt

 include(CMakeParseArguments)
 include(AddFlang)
 
 
 add_subdirectory(include)
 add_subdirectory(lib)
 add_subdirectory(cmake/modules)
 
+option(FLANG_USE_LEGACY_NAME "Use the legacy name, flang-new, for the Flang driver." ON)
+
 option(FLANG_BUILD_TOOLS
   "Build the Flang tools. If OFF, just generate build targets." ON)
 if (FLANG_BUILD_TOOLS)
   add_subdirectory(tools)
 endif()
 add_subdirectory(runtime)
 
 option(FLANG_BUILD_EXAMPLES "Build Flang example programs by default." OFF)

flang/docs/FlangDriver.md

 <!--===- docs/FlangDriver.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
 
 -->
 
 # Flang drivers
 
 ```eval_rst
 .. contents::
    :local:
 ```
 
 There are two main drivers in Flang:
-* the compiler driver, `flang-new`
-* the frontend driver, `flang-new -fc1`
-
-> **_NOTE:_** The diagrams in this document refer to `flang` as opposed to
-> `flang-new`. Eventually, `flang-new` will be renamed as `flang` and the
-> diagrams reflect the final design that we are still working towards.
+* the compiler driver, `flang`
+* the frontend driver, `flang -fc1`
 
 The **compiler driver** will allow you to control all compilation phases (e.g.
 preprocessing, semantic checks, code-generation, code-optimisation, lowering
 and linking). For frontend specific tasks, the compiler driver creates a
-Fortran compilation job and delegates it to `flang-new -fc1`, the frontend
+Fortran compilation job and delegates it to `flang -fc1`, the frontend
 driver. For linking, it creates a linker job and calls an external linker (e.g.
 LLVM's [`lld`](https://lld.llvm.org/)). It can also call other tools such as
 external assemblers (e.g. [`as`](https://www.gnu.org/software/binutils/)). In
 Clang, the compiler driver can also link the generated binaries with LLVM's
 static analysis/sanitizer libraries (e.g.
 [MemorySanitizer](https://clang.llvm.org/docs/MemorySanitizer.html)). This is
 not yet available in Flang, but will be relatively easy to support once such
 libraries become available. Flang's compiler driver is intended for Flang's
 end-users - its interface needs to remain stable. Otherwise, Flang's users will
 have to adjust their build scripts every time a compiler flag is changed.
 
 | ![Compiler Driver](compiler_driver.png) |
 |:--:|
 | *Flang’s compiler driver and the **tools** that it runs* |
 
 The **frontend driver** glues together and drives all of the Flang's frontend
 libraries. As such, it provides an easy-to-use and intuitive interface to the
 frontend. It uses MLIR and LLVM for code-generation and can be viewed as a
 driver for Flang, LLVM and MLIR libraries. Contrary to the compiler driver, it
 is not capable of calling any external tools (including linkers).  It is aware
 of all the frontend internals that are "hidden" from the compiler driver. It
-accepts many frontend-specific options not available in `flang-new` and as such
+accepts many frontend-specific options not available in `flang` and as such
 it provides a finer control over the frontend. Note that this tool is mostly
 intended for Flang developers. In particular, there are no guarantees about the
 stability of its interface and compiler developers can use it to experiment
 with new flags.
 
 | ![Frontend Driver](frontend_driver.png) |
 |:-:|
 | *Flang's frontend driver and the **libraries** that it drives* |
 
 Note that similarly to `-Xclang` in `clang`, you can use `-Xflang` to forward a
 frontend specific flag from the _compiler_ directly to the _frontend_ driver,
 e.g.:
 
 ```lang=bash
-flang-new -Xflang -fdebug-dump-parse-tree input.f95
+flang -Xflang -fdebug-dump-parse-tree input.f95
 ```
 
-In the invocation above, `-fdebug-dump-parse-tree` is forwarded to `flang-new
+In the invocation above, `-fdebug-dump-parse-tree` is forwarded to `flang
 -fc1`. Without the forwarding flag, `-Xflang`, you would see the following
 warning:
 
 ```lang=bash
-flang-new: warning: argument unused during compilation:
+flang: warning: argument unused during compilation:
 ```
 
-As `-fdebug-dump-parse-tree` is only supported by `flang-new -fc1`, `flang-new`
+As `-fdebug-dump-parse-tree` is only supported by `flang -fc1`, `flang`
 will ignore it when used without `Xflang`.
 
 ## Why Do We Need Two Drivers?
-As hinted above, `flang-new` and `flang-new -fc1` are two separate tools. The
-fact that these tools are accessed through one binary, `flang-new`, is just an
+As hinted above, `flang` and `flang -fc1` are two separate tools. The
+fact that these tools are accessed through one binary, `flang`, is just an
 implementation detail. Each tool has a separate list of options, albeit defined
 in the same file: `clang/include/clang/Driver/Options.td`.
 
 The separation helps us split various tasks and allows us to implement more
-specialised tools. In particular, `flang-new` is not aware of various
+specialised tools. In particular, `flang` is not aware of various
 compilation phases within the frontend (e.g. scanning, parsing or semantic
-checks). It does not have to be. Conversely, the frontend driver, `flang-new
+checks). It does not have to be. Conversely, the frontend driver, `flang
 -fc1`, needs not to be concerned with linkers or other external tools like
 assemblers. Nor does it need to know where to look for various systems
 libraries, which is usually OS and platform specific.
 
 One helpful way of differentiating these tools is to keep in mind that:
 
 * the compiler driver is an end-user tool
 * frontend driver is a compiler developer tool with many additional options,
 
 Also, Since the compiler driver can call external tools, e.g. linkers, it can
 be used to generate **executables**. The frontend driver cannot call external
 tools and hence can only generate **object files**. A similar model is
 implemented in Clang (`clang` vs `clang -cc1` vs `clang -cc1as`), which is
 based on the [architecture of
 GCC](https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Architecture).
 In fact, Flang needs to adhere to this model in order to be able to re-use
 Clang's driver library. If you are more familiar with the [architecture of
 GFortran](https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gfortran/About-GNU-Fortran.html)
-than Clang, then `flang-new` corresponds to `gfortran` and `flang-new -fc1` to
+than Clang, then `flang` corresponds to `gfortran` and `flang -fc1` to
 `f951`.
 
 ## Compiler Driver
 The main entry point for Flang's compiler driver is implemented in
 `flang/tools/flang-driver/driver.cpp`.  Flang's compiler driver is implemented
 in terms of Clang's driver library, `clangDriver`. This approach allows us to:
 * benefit from Clang's support for various targets, platforms and operating systems
 * leverage Clang's ability to drive various backends available in LLVM, as well

 * `-E` for `PreprocessJobClass`,
 * `-c` for `CompileJobClass`.
 
 In most cases, the driver creates a chain of actions/jobs/phases where the
 output from one action is the input for the subsequent one. You can use the
 `-ccc-print-phases` flag to see the sequence of actions that the driver will
 create for your compiler invocation:
 ```bash
-flang-new -ccc-print-phases -E file.f
+flang -ccc-print-phases -E file.f
 +- 0: input, "file.f", f95-cpp-input
 1: preprocessor, {0}, f95
 ```
 As you can see, for `-E` the driver creates only two jobs and stops immediately
 after preprocessing. The first job simply prepares the input. For `-c`, the
 pipeline of the created jobs is more complex:
 ```bash
-flang-new -ccc-print-phases -c file.f
+flang -ccc-print-phases -c file.f
          +- 0: input, "file.f", f95-cpp-input
       +- 1: preprocessor, {0}, f95
    +- 2: compiler, {1}, ir
 +- 3: backend, {2}, assembler
 4: assembler, {3}, object
 ```
-Note that currently Flang does not support code-generation and `flang-new` will
+Note that currently Flang does not support code-generation and `flang` will
 fail during the second step above with the following error:
 ```bash
 error: code-generation is not available yet
 ```
 The other phases are printed nonetheless when using `-ccc-print-phases`, as
 that reflects what `clangDriver`, the library, will try to create and run.
 
 For actions specific to the frontend (e.g. preprocessing or code generation), a
 command to call the frontend driver is generated (more specifically, an
 instance of `clang::driver::Command`). Every command is bound to an instance of
 `clang::driver::Tool`. For Flang we introduced a specialisation of this class:
 `clang::driver::Flang`. This class implements the logic to either translate or
-forward compiler options to the frontend driver, `flang-new -fc1`.
+forward compiler options to the frontend driver, `flang -fc1`.
 
 You can read more on the design of `clangDriver` in Clang's [Driver Design &
 Internals](https://clang.llvm.org/docs/DriverInternals.html).
 
 ## Frontend Driver
 Flang's frontend driver is the main interface between compiler developers and
 the Flang frontend. The high-level design is similar to Clang's frontend
 driver, `clang -cc1` and consists of the following classes:
* `FrontendAction` and `FrontendActions` (the former being the base class for
   there is one specialisation of `FrontendActions` for every compiler action flag
   (e.g. `-E`, `-fdebug-unparse`). These classes also contain various hooks that
   allow you to e.g. fine-tune the configuration of the frontend based on the
   input.
 
 This list is not exhaustive and only covers the main classes that implement the
 driver. The main entry point for the frontend driver, `fc1_main`, is
 implemented in `flang/tools/flang-driver/driver.cpp`. It can be accessed by
-invoking the compiler driver, `flang-new`, with the `-fc1` flag.
+invoking the compiler driver, `flang`, with the `-fc1` flag.
 
 The frontend driver will only run one action at a time. If you specify multiple
 action flags, only the last one will be taken into account. The default action
 is `ParseSyntaxOnlyAction`, which corresponds to `-fsyntax-only`. In other
-words, `flang-new -fc1 <input-file>` is equivalent to `flang-new -fc1 -fsyntax-only
+words, `flang -fc1 <input-file>` is equivalent to `flang -fc1 -fsyntax-only
 <input-file>`.
 
 ## The `flang-to-external-fc` script
-The `flang-to-external-fc` wrapper script for `flang-new` was introduced as a
-development tool and to facilitate testing. The `flang-to-external-fc` wrapper
-script will:
-* use `flang-new` to unparse the input source file (i.e. it will run `flang-new
-  -fc1 -fdebug-unparse <input-file>`), and then
+The `flang-to-external-fc` wrapper script for `flang` was introduced as a
+development tool and to facilitate testing. While code-generation is not
+available in Flang, you can use it as a drop-in replacement for other Fortran
+compilers in your build scripts.
+
+The `flang-to-external-fc` wrapper script will:
+* use `flang` to unparse the input source file (i.e. it will run `flang -fc1
+  -fdebug-unparse <input-file>`), and then
 * call a host Fortran compiler, e.g. `gfortran`, to compile the unparsed file.
 
 Here's a basic breakdown of what happens inside `flang-to-external-fc` when you
 run `flang-to-external-fc file.f90`:
 ```bash
-flang-new -fc1 -fdebug-unparse file.f90 -o file-unparsed.f90
+flang -fc1 -fdebug-unparse file.f90 -o file-unparsed.f90
 gfortran file-unparsed.f90
 ```
 This is a simplified version for illustration purposes only. In practice,
 `flang-to-external-fc` adds a few more frontend options and it also supports
 various other use cases (e.g. compiling C files, linking existing object
 files). `gfortran` is the default host compiler used by `flang-to-external-fc`.
 You can change it by setting the `FLANG_FC` environment variable.
 

 There are many predefined TableGen classes and records that you can use to fine
 tune your new option. The list of available configurations can be overwhelming
 at times. Sometimes the easiest approach is to find an existing option that has
 similar semantics to your new option and start by copying that.
 
 For every new option, you will also have to define the visibility of the new
 option. This is controlled through the `Flags` field. You can use the following
 Flang specific option flags to control this:
-  * `FlangOption` - this option will be available in the `flang-new` compiler driver,
-  * `FC1Option` - this option will be available in the `flang-new -fc1` frontend driver,
+  * `FlangOption` - this option will be available in the `flang` compiler driver,
+  * `FC1Option` - this option will be available in the `flang -fc1` frontend driver,
   * `FlangOnlyOption` - this option will not be visible in Clang drivers.
 
 Please make sure that options that you add are only visible in drivers that can
 support it. For example, options that only make sense for Fortran input files
 (e.g. `-ffree-form`) should not be visible in Clang and be marked as
 `FlangOnlyOption`.
 
 When deciding what `OptionGroup` to use when defining a new option in the

 
 * frontend driver: `flang/lib/Frontend/CompilerInvocation.cpp`,
 * compiler driver: `clang/lib/Driver/ToolChains/Flang.cpp`.
 
 The parsing will depend on the semantics encoded in the TableGen definition.
 
 When adding a compiler driver option (i.e. an option that contains
 `FlangOption` among its `Flags`) that you also intend to be understood by the
-frontend, make sure that it is either forwarded to `flang-new -fc1` or translated
+frontend, make sure that it is either forwarded to `flang -fc1` or translated
 into some other option that is accepted by the frontend driver. In the case of
 options that contain both `FlangOption` and `FC1Option` among its flags, we
-usually just forward from `flang-new` to `flang-new -fc1`. This is then tested in
+usually just forward from `flang` to `flang -fc1`. This is then tested in
 `flang/test/Driver/frontend-forward.F90`.
 
 What follows is usually very dependant on the meaning of the corresponding
 option. In general, regular compiler flags (e.g. `-ffree-form`) are mapped to
 some state within the driver. A lot of this state is stored within an instance
 of `FrontendOptions`, but there are other more specialised classes too. Action
 flags (e.g. `-fsyntax-only`) are usually more complex overall, but also more
 structured in terms of the implementation.

 ```
 where `<version>` corresponds to the LLVM Flang version. Note that while
 generating executables remains experimental, you will need to inform CMake to
 use the `-flang-experimental-exec` flag when invoking `flang-new` as in the
 example above.
 
 # Testing
 In LIT, we define two variables that you can use to invoke Flang's drivers:
-* `%flang` is expanded as `flang-new` (i.e. the compiler driver)
-* `%flang_fc1` is expanded as `flang-new -fc1` (i.e. the frontend driver)
+* `%flang` is expanded as `flang` (i.e. the compiler driver)
+* `%flang_fc1` is expanded as `flang -fc1` (i.e. the frontend driver)
 
 For most regression tests for the frontend, you will want to use `%flang_fc1`.
 In some cases, the observable behaviour will be identical regardless of whether
 `%flang` or `%flang_fc1` is used. However, when you are using `%flang` instead
 of `%flang_fc1`, the compiler driver will add extra flags to the frontend
-driver invocation (i.e. `flang-new -fc1 -<extra-flags>`). In some cases that might
+driver invocation (i.e. `flang -fc1 -<extra-flags>`). In some cases that might
 be exactly what you want to test.  In fact, you can check these additional
 flags by using the `-###` compiler driver command line option.
 
 Lastly, you can use `! REQUIRES: <feature>` for tests that will only work when
 `<feature>` is available. For example, you can use`! REQUIRES: shell` to mark a
 test as only available on Unix-like systems (i.e. systems that contain a Unix
 shell). In practice this means that the corresponding test is skipped on
 Windows.
 
 # Frontend Driver Plugins
 Plugins are an extension to the frontend driver that make it possible to run
 extra user defined frontend actions, in the form of a specialization of a
 `PluginParseTreeAction`. These actions are run during compilation, after
 semantic checks. Similarly to Clang, Flang leverages `LoadLibraryPermanently`
 from LLVM's `llvm::sys::DynamicLibrary` to load dynamic objects that implement
 plugins. The process for using plugins includes:
 * [Creating a plugin](#creating-a-plugin)
 * [Loading and running a plugin](#loading-and-running-a-plugin)
 
-Flang plugins are limited to `flang-new -fc1` and are currently only available /
+Flang plugins are limited to `flang -fc1` and are currently only available /
 been tested on Linux.
 
 ## Creating a Plugin
 There are three parts required for plugins to work:
 1. [`PluginParseTreeAction` subclass](#a-pluginparsetreeaction-subclass)
 1. [Implementation of `ExecuteAction`](#implementation-of-executeaction)
 1. [Plugin registration](#plugin-registration)
 

 being the description:
 ```cpp
 static FrontendPluginRegistry::Add<PrintFunctionNamesAction> X(
     "print-fns", "Print Function names");
 ```
 
 ## Loading and Running a Plugin
 In order to use plugins, there are 2 command line options made available to the
-frontend driver, `flang-new -fc1`:
+frontend driver, `flang -fc1`:
 * [`-load <dsopath>`](#the--load-dsopath-option) for loading the dynamic shared
   object of the plugin
 * [`-plugin <name>`](#the--plugin-name-option) for calling the registered plugin
 
 Invocation of the example plugin is done through:
 ```bash
-flang-new -fc1 -load flangPrintFunctionNames.so -plugin print-fns file.f90
+flang -fc1 -load flangPrintFunctionNames.so -plugin print-fns file.f90
 ```
 
 Both these options are parsed in `flang/lib/Frontend/CompilerInvocation.cpp` and
 fulfil their actions in
 `flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp`
 
 ### The `-load <dsopath>` option
 This loads the plugin shared object library, with the path given at `<dsopath>`,
 using `LoadLibraryPermantly` from LLVM's `llvm::sys::DynamicLibrary`, which
 itself uses `dlopen`. During this stage, the plugin is registered with the
 registration line from the plugin, storing the name and description.
 
 ### The `-plugin <name>` option
 This sets `frontend::ActionKind programAction` in `FrontendOptions` to
 `PluginAction`, through which it searches the plugin registry for the plugin
 name from `<name>`. If found, it returns the instantiated plugin, otherwise it
 reports an error diagnostic and returns `nullptr`.
 
 ## Enabling In-Tree Plugins
 For in-tree plugins, there is the CMake flag `FLANG_PLUGIN_SUPPORT`, enabled by
-default, that controls the exporting of executable symbols from `flang-new`,
+default, that controls the exporting of executable symbols from `flang`,
 which plugins need access to. Additionally, there is the CMake flag
 `FLANG_BUILD_EXAMPLES`, turned off by default, that is used to control if the
 example programs are built. This includes plugins that are in the
 `flang/example` directory and added as a `sub_directory` to the
 `flang/examples/CMakeLists.txt`, for example, the `PrintFlangFunctionNames`
 plugin. It is also possible to develop plugins out-of-tree.
 
 ## Limitations

flang/docs/ImplementingASemanticCheck.md

 
 ```fortran
       jvar = intentOutFunc(ivar) ! Error since ivar is a DO variable
 ```
 
 
 I also used this program to produce a parse tree for the program using the command:
 ```bash
-  flang-new -fc1 -fdebug-dump-parse-tree testfun.f90
+  flang -fc1 -fdebug-dump-parse-tree testfun.f90
 ```
 
 Here's the relevant fragment of the parse tree produced by the compiler:
 
 ```
 | | ExecutionPartConstruct -> ExecutableConstruct -> DoConstruct
 | | | NonLabelDoStmt
 | | | | LoopControl -> LoopBounds
```C++
   void DoChecker::Leave(const parser::Expr &) {
     std::cout << "In Leave for parser::Expr\n";
   }
 ```
 
 I then built the compiler with these changes and ran it on my test program.
 This time, I made sure to invoke semantic checking.  Here's the command I used:
 ```bash
-  flang-new -fc1 -fdebug-unparse-with-symbols testfun.f90
+  flang -fc1 -fdebug-unparse-with-symbols testfun.f90
 ```
 
 This produced the output:
 
 ```
   In Leave for parser::Expr
   In Leave for parser::Expr
   In Leave for parser::Expr

flang/docs/Overview.md

- A "cooked" character stream: the entire program as a contiguous stream of
   normalized Fortran source.
   Extraneous whitespace and comments are removed (except comments that are
   compiler directives that are not disabled) and case is normalized.
 - Provenance information mapping each character back to the source it came from.
   This is used in subsequent phases to issue errors messages that refer to source locations.
 
 **Entry point:** `parser::Parsing::Prescan`
 
-**Command:** `flang-new -fc1 -E src.f90` dumps the cooked character stream
+**Command:** `flang -fc1 -E src.f90` dumps the cooked character stream
 
 ## Parse
 
 **Input:** Cooked character stream.
 
 **Output:** A parse tree representing a syntactically correct program,
   rooted at a `parser::Program`.
   See: [Parsing.md](Parsing.md) and [ParserCombinators.md](ParserCombinators.md).
 
 **Entry point:** `parser::Parsing::Parse`
 
 **Command:**
-  - `flang-new -fc1 -fdebug-dump-parse-tree src.f90` dumps the parse tree
-  - `flang-new -fc1 -fdebug-unparse src.f90` converts the parse tree to normalized Fortran
+  - `flang -fc1 -fdebug-dump-parse-tree src.f90` dumps the parse tree
+  - `flang -fc1 -fdebug-unparse src.f90` converts the parse tree to normalized Fortran
 
 ## Validate Labels and Canonicalize Do Statements
 
 **Input:** Parse tree.
 
 **Output:** The parse tree with label constraints and construct names checked,
   and each `LabelDoStmt` converted to a `NonLabelDoStmt`.
   See: [LabelResolution.md](LabelResolution.md).

 - Parse tree with some refinements:
   - each `parser::Name::symbol` field points to one of the symbols
   - each `parser::TypeSpec::declTypeSpec` field points to one of the types
   - array element references that were parsed as function references or
     statement functions are corrected
 
 **Entry points:** `semantics::ResolveNames`, `semantics::RewriteParseTree`
 
-**Command:** `flang-new -fc1 -fdebug-dump-symbols src.f90` dumps the
+**Command:** `flang -fc1 -fdebug-dump-symbols src.f90` dumps the
   tree of scopes and symbols in each scope
 
 ## Check DO CONCURRENT Constraints
 
 **Input:** Parse tree with names resolved.
 
 **Output:** Parse tree with semantically correct DO CONCURRENT loops.
 

flang/examples/FlangOmpReport/FlangOmpReport.cpp

 //===-- examples/flang-omp-report-plugin/flang-omp-report.cpp -------------===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 // This plugin parses a Fortran source file and generates a YAML report with
 // all the OpenMP constructs and clauses and which line they're located on.
 //
 // The plugin may be invoked as:
-// ./bin/flang-new -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report
+// ./bin/flang -fc1 -load lib/flangOmpReport.so -plugin flang-omp-report
 // -fopenmp
 //
 //===----------------------------------------------------------------------===//
 
 #include "FlangOmpReportVisitor.h"
 
 #include "flang/Frontend/FrontendActions.h"
 #include "flang/Frontend/FrontendPluginRegistry.h"

flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp

createFrontendAction(CompilerInstance &ci) {
   }
 
   llvm_unreachable("Invalid program action!");
 }
 
 bool executeCompilerInvocation(CompilerInstance *flang) {
   // Honor -help.
   if (flang->getFrontendOpts().showHelp) {
-    clang::driver::getDriverOptTable().printHelp(llvm::outs(),
-        "flang-new -fc1 [options] file...", "LLVM 'Flang' Compiler",
+    clang::driver::getDriverOptTable().printHelp(
+        llvm::outs(), "flang -fc1 [options] file...", "LLVM 'Flang' Compiler",
         /*Include=*/clang::driver::options::FC1Option,
         /*Exclude=*/llvm::opt::DriverFlag::HelpHidden,
         /*ShowAllAliases=*/false);
     return true;
   }
 
   // Honor -version.
   if (flang->getFrontendOpts().showVersion) {

flang/test/CMakeLists.txt

 # Test runner infrastructure for Flang. This configures the Flang test trees
 # for use by Lit, and delegates to LLVM's lit test handlers.
 
 llvm_canonicalize_cmake_booleans(
   FLANG_BUILD_EXAMPLES
   FLANG_STANDALONE_BUILD
   LLVM_ENABLE_PLUGINS
+  FLANG_USE_LEGACY_NAME
 )
 
 set(FLANG_TOOLS_DIR ${FLANG_BINARY_DIR}/bin)
 
 # FIXME In out-of-tree builds, "SHLIBDIR" is undefined and passing it to
 # `configure_lit_site_cfg` leads to a configuration error. This is currently
 # only required by plugins/examples, which are not supported in out-of-tree
 # builds.
configure_lit_site_cfg(
   MAIN_CONFIG
   ${CMAKE_CURRENT_SOURCE_DIR}/NonGtestUnit/lit.cfg.py
 )
 
 set(FLANG_TEST_PARAMS
   flang_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg.py)
 
 set(FLANG_TEST_DEPENDS
-  flang-new
+  flang
   llvm-config
   FileCheck
   count
   not
   module_files
   fir-opt
   tco
   bbc

flang/test/Driver/disable-ext-name-interop.f90

-! Test that we can disable the ExternalNameConversion pass in flang-new.
+! Test that we can disable the ExternalNameConversion pass in flang.
 
 ! RUN: %flang_fc1 -S %s -o - 2>&1 | FileCheck %s --check-prefix=EXTNAMES
 ! RUN: %flang_fc1 -S -mmlir -disable-external-name-interop %s -o - 2>&1 | FileCheck %s --check-prefix=INTNAMES
 
 ! EXTNAMES: test_ext_names_
 ! INTNAMES: _QPtest_ext_names
 subroutine test_ext_names
 end subroutine

flang/test/Driver/driver-help-hidden.f90

 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: %flang --help-hidden 2>&1 | FileCheck %s
 ! RUN: not %flang  -help-hidden 2>&1 | FileCheck %s --check-prefix=ERROR-FLANG
 
 !----------------------------------------
-! FLANG FRONTEND DRIVER (flang-new -fc1)
+! FLANG FRONTEND DRIVER (flang -fc1)
 !----------------------------------------
 ! RUN: not %flang_fc1 --help-hidden 2>&1 | FileCheck %s --check-prefix=ERROR-FLANG-FC1
 ! RUN: not %flang_fc1  -help-hidden 2>&1 | FileCheck %s --check-prefix=ERROR-FLANG-FC1
 
 !----------------------------------------------------
-! EXPECTED OUTPUT FOR FLANG DRIVER (flang-new)
+! EXPECTED OUTPUT FOR FLANG DRIVER (flang)
 !----------------------------------------------------
-! CHECK:USAGE: flang-new
+! CHECK:USAGE: flang
 ! CHECK-EMPTY:
 ! CHECK-NEXT:OPTIONS:
 ! CHECK-NEXT: -###      Print (but do not run) the commands to run for this compilation
 ! CHECK-NEXT: -cpp      Enable predefined and command line preprocessor macros
 ! CHECK-NEXT: -c        Only run preprocess, compile, and assemble steps
 ! CHECK-NEXT: -D <macro>=<value>     Define <macro> to <value> (or 1 if <value> omitted)
 ! CHECK-NEXT: -emit-llvm             Use the LLVM representation for assembler and object files
 ! CHECK-NEXT: -E        Only run the preprocessor

 ! CHECK-NEXT: -S                     Only run preprocess and compilation steps
 ! CHECK-NEXT: --target=<value>        Generate code for the given target
 ! CHECK-NEXT: -U <macro>             Undefine macro <macro>
 ! CHECK-NEXT: --version Print version information
 ! CHECK-NEXT: -W<warning>            Enable the specified warning
 ! CHECK-NEXT: -Xflang <arg>          Pass <arg> to the flang compiler
 
 !-------------------------------------------------------------
-! EXPECTED OUTPUT FOR FLANG DRIVER (flang-new)
+! EXPECTED OUTPUT FOR FLANG DRIVER (flang)
 !-------------------------------------------------------------
 ! ERROR-FLANG: error: unknown argument '-help-hidden'; did you mean '--help-hidden'?
 
 !-------------------------------------------------------------
-! EXPECTED OUTPUT FOR FLANG FRONTEND DRIVER (flang-new -fc1)
+! EXPECTED OUTPUT FOR FLANG FRONTEND DRIVER (flang -fc1)
 !-------------------------------------------------------------
 ! Frontend driver -help-hidden is not supported
 ! ERROR-FLANG-FC1: error: unknown argument: '{{.*}}'
 

flang/test/Driver/driver-version.f90

 
 !-----------
 ! RUN LINES
 !-----------
 ! RUN: %flang --version 2>&1 | FileCheck %s --check-prefix=VERSION
 ! RUN: not %flang --versions 2>&1 | FileCheck %s --check-prefix=ERROR
 ! RUN: %flang_fc1 -version 2>&1 | FileCheck %s --check-prefix=VERSION-FC1
 ! RUN: not %flang_fc1 --version 2>&1 | FileCheck %s --check-prefix=ERROR-FC1
 
 !-----------------------
 ! EXPECTED OUTPUT
 !-----------------------
-! VERSION: flang-new version
+! VERSION: flang version
 ! VERSION-NEXT: Target:
 ! VERSION-NEXT: Thread model:
 ! VERSION-NEXT: InstalledDir:
 
-! ERROR: flang-new: error: unsupported option '--versions'; did you mean '--version'?
+! ERROR: error: unsupported option '--versions'; did you mean '--version'?
 
 ! VERSION-FC1: LLVM version
 
 ! ERROR-FC1: error: unknown argument '--version'; did you mean '-version'?

flang/test/Driver/escaped-backslash.f90

 ! Ensure argument -fbackslash works as expected.
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: %flang -E %s  2>&1 | FileCheck %s --check-prefix=ESCAPED
 ! RUN: %flang -E -fbackslash -fno-backslash %s  2>&1 | FileCheck %s --check-prefix=ESCAPED
 ! RUN: %flang -E -fbackslash %s  2>&1 | FileCheck %s --check-prefix=UNESCAPED
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -E %s  2>&1 | FileCheck %s --check-prefix=ESCAPED
 ! RUN: %flang_fc1 -E -fbackslash -fno-backslash %s  2>&1 | FileCheck %s --check-prefix=ESCAPED
 ! RUN: %flang_fc1 -E -fbackslash %s  2>&1 | FileCheck %s --check-prefix=UNESCAPED
 
 !-----------------------------------------
 ! EXPECTED OUTPUT FOR ESCAPED BACKSLASHES
 !-----------------------------------------

flang/test/Driver/fdefault.f90

 ! Ensure argument -fdefault* work as expected.
 ! TODO: Add checks when actual codegen is possible for this family
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang -fsyntax-only -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=NOOPTION
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang -fsyntax-only -fdefault-real-8 -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=REAL8
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang -fsyntax-only -fdefault-real-8 -fdefault-double-8 -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=DOUBLE8
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang -fsyntax-only -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=NOOPTION
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang -fsyntax-only -fdefault-real-8 -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=REAL8
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang -fsyntax-only -fdefault-real-8 -fdefault-double-8 -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=DOUBLE8
 ! RUN: not %flang -fsyntax-only -fdefault-double-8 %s  2>&1 | FileCheck %s --check-prefix=ERROR
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang_fc1 -fsyntax-only -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=NOOPTION
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang_fc1 -fsyntax-only -fdefault-real-8 -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=REAL8
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang_fc1 -fsyntax-only -fdefault-real-8 -fdefault-double-8 -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=DOUBLE8
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang_fc1 -fsyntax-only -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=NOOPTION
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang_fc1 -fsyntax-only -fdefault-real-8 -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=REAL8
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang_fc1 -fsyntax-only -fdefault-real-8 -fdefault-double-8 -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=DOUBLE8
 ! RUN: not %flang_fc1 -fsyntax-only -fdefault-double-8 %s  2>&1 | FileCheck %s --check-prefix=ERROR
 
 !-----------------------------------------
 ! EXPECTED OUTPUT FOR NO SPECIFICATION
 !-----------------------------------------
 ! NOOPTION: integer(4),parameter::real_kind=4_4
 ! NOOPTION-NEXT: intrinsic::kind
 ! NOOPTION-NEXT: integer(4),parameter::double_kind=8_4

flang/test/Driver/flarge-sizes.f90

 ! Ensure argument -flarge-sizes works as expected.
 ! TODO: Add checks when actual codegen is possible.
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang -fsyntax-only -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=NOLARGE
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang -fsyntax-only -flarge-sizes -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=LARGE
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang -fsyntax-only -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=NOLARGE
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang -fsyntax-only -flarge-sizes -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=LARGE
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang_fc1 -fsyntax-only -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=NOLARGE
-! RUN: rm -rf %t/dir-flang-new  && mkdir -p %t/dir-flang-new && %flang_fc1 -fsyntax-only -flarge-sizes -module-dir %t/dir-flang-new %s  2>&1
-! RUN: cat %t/dir-flang-new/m.mod | FileCheck %s --check-prefix=LARGE
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang_fc1 -fsyntax-only -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=NOLARGE
+! RUN: rm -rf %t/dir-flang  && mkdir -p %t/dir-flang && %flang_fc1 -fsyntax-only -flarge-sizes -module-dir %t/dir-flang %s  2>&1
+! RUN: cat %t/dir-flang/m.mod | FileCheck %s --check-prefix=LARGE
 
 !-----------------------------------------
 ! EXPECTED OUTPUT WITHOUT -flarge-sizes
 !-----------------------------------------
 ! NOLARGE: real(4)::z(1_8:10_8)
 ! NOLARGE-NEXT: integer(4),parameter::size_kind=4_4
 
 !-----------------------------------------

flang/test/Driver/frontend-forwarding.f90

-! Test that flang-new forwards Flang frontend
-! options to flang-new -fc1 as expected.
+! Test that flang forwards Flang frontend
+! options to flang -fc1 as expected.
 
 ! RUN: %flang -fsyntax-only -### %s -o %t 2>&1 \
 ! RUN:     -finput-charset=utf-8 \
 ! RUN:     -fdefault-double-8 \
 ! RUN:     -fdefault-integer-8 \
 ! RUN:     -fdefault-real-8 \
 ! RUN:     -flarge-sizes \
 ! RUN:     -mllvm -print-before-all\

flang/test/Driver/intrinsic-module-path.f90

 ! Ensure argument -fintrinsic-modules-path works as expected.
 ! WITHOUT the option, the default location for the module is checked and no error generated.
 ! With the option GIVEN, the module with the same name is PREPENDED, and considered over the
 ! default one, causing a CHECKSUM error.
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -fsyntax-only %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
 ! RUN: not %flang_fc1 -fsyntax-only -fintrinsic-modules-path %S/Inputs/ %s  2>&1 | FileCheck %s --check-prefix=GIVEN
 
 !-----------------------------------------
 ! EXPECTED OUTPUT WITHOUT
 !-----------------------------------------
 ! WITHOUT-NOT: 'ieee_arithmetic.mod' was not found

flang/test/Driver/macro-def-undef.F90

 ! Ensure arguments -D and -U work as expected.
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: %flang -E -P %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
 ! RUN: %flang -E -P -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
 ! RUN: %flang -E -P -DX=A -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -E -P %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
 ! RUN: %flang_fc1 -E -P -DX=A %s  2>&1 | FileCheck %s --check-prefix=DEFINED
 ! RUN: %flang_fc1 -E -P -DX -UX %s  2>&1 | FileCheck %s --check-prefix=UNDEFINED
 
 !--------------------------------------------
 ! EXPECTED OUTPUT FOR AN UNDEFINED MACRO
 !--------------------------------------------

flang/test/Driver/missing-input.f90

 ! Test the behaviour of the driver when input is missing or is invalid. Note
-! that with the compiler driver (flang-new), the input _has_ to be specified.
+! that with the compiler driver (flang), the input _has_ to be specified.
 ! Indeed, the driver decides what "job/command" to create based on the input
 ! file's extension. No input file means that it doesn't know what to do
-! (compile?  preprocess? link?). The frontend driver (flang-new -fc1) simply
+! (compile?  preprocess? link?). The frontend driver (flang -fc1) simply
 ! assumes that "no explicit input == read from stdin"
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: not %flang  2>&1 | FileCheck %s --check-prefix=FLANG-NO-FILE
 ! RUN: not %flang %t.f90 2>&1 | FileCheck %s --check-prefix=FLANG-NONEXISTENT-FILE
 
 !-----------------------------------------
-! FLANG FRONTEND DRIVER (flang-new -fc1)
+! FLANG FRONTEND DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: not %flang_fc1 %t.f90 2>&1  | FileCheck %s --check-prefix=FLANG-FC1-NONEXISTENT-FILE
 ! RUN: not %flang_fc1 %S 2>&1  | FileCheck %s --check-prefix=FLANG-FC1-DIR
 
 !-----------------------
 ! EXPECTED OUTPUT
 !-----------------------
-! FLANG-NO-FILE: flang-new: error: no input files
+! FLANG-NO-FILE: error: no input files
 
-! FLANG-NONEXISTENT-FILE: flang-new: error: no such file or directory: {{.*}}
-! FLANG-NONEXISTENT-FILE: flang-new: error: no input files
+! FLANG-NONEXISTENT-FILE: error: no such file or directory: {{.*}}
+! FLANG-NONEXISTENT-FILE: error: no input files
 
 ! FLANG-FC1-NONEXISTENT-FILE: error: {{.*}} does not exist
 ! FLANG-FC1-DIR: error: {{.*}} is not a regular file

flang/test/Driver/predefined-macros-compiler-version.F90

 ! Check that the driver correctly defines macros with the compiler version
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: %flang_fc1 -E %s  2>&1 | FileCheck %s --ignore-case
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -E %s  2>&1 | FileCheck %s --ignore-case
 
 !-----------------
 ! EXPECTED OUTPUT
 !-----------------
 ! CHECK: flang = 1
 ! CHECK: flang_major = {{[1-9][0-9]*$}}
 ! CHECK: flang_minor = {{[0-9]+$}}
 ! CHECK: flang_patchlevel = {{[0-9]+$}}
 
 integer, parameter :: flang = __flang__
 integer, parameter :: flang_major = __flang_major__
 integer, parameter :: flang_minor = __flang_minor__
 integer, parameter :: flang_patchlevel = __flang_patchlevel__

flang/test/Driver/std2018-wrong.f90

 ! Ensure argument -std=f2018 works as expected.
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: not %flang_fc1 -std=90 %s  2>&1 | FileCheck %s --check-prefix=WRONG
 
 !-----------------------------------------
 ! EXPECTED OUTPUT WITH WRONG
 !-----------------------------------------
 ! WRONG: Only -std=f2018 is allowed currently.

flang/test/Driver/std2018.f90

 ! Ensure argument -std=f2018 works as expected.
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -fsyntax-only %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
 ! RUN: %flang_fc1 -fsyntax-only -std=f2018 %s  2>&1 | FileCheck %s --check-prefix=GIVEN
 ! RUN: %flang_fc1 -fsyntax-only -pedantic %s  2>&1 | FileCheck %s --check-prefix=GIVEN
 
 !-----------------------------------------
 ! EXPECTED OUTPUT WITHOUT
 !-----------------------------------------

flang/test/Driver/use-module-error.f90

 ! Ensure that multiple module directories are not allowed
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: not %flang -fsyntax-only -J %S/Inputs/module-dir -J %S/Inputs/ %s  2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 ! RUN: not %flang -fsyntax-only -J %S/Inputs/module-dir -module-dir %S/Inputs/ %s 2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 ! RUN: not %flang -fsyntax-only -module-dir %S/Inputs/module-dir -J%S/Inputs/ %s 2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: not %flang_fc1 -fsyntax-only -J %S/Inputs/module-dir -J %S/Inputs/ %s 2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 ! RUN: not %flang_fc1 -fsyntax-only -J %S/Inputs/module-dir -module-dir %S/Inputs/ %s 2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 ! RUN: not %flang_fc1 -fsyntax-only -module-dir %S/Inputs/module-dir -J%S/Inputs/ %s 2>&1 | FileCheck %s --check-prefix=DOUBLEINCLUDE
 
 !-----------------------------------------
 ! EXPECTED OUTPUT FOR MISSING MODULE FILE
 !-----------------------------------------
 ! DOUBLEINCLUDE:error: Only one '-module-dir/-J' option allowed
 
 program too_many_module_dirs
 end

flang/test/Driver/use-module.f90

 ! Checks that module search directories specified with `-J/-module-dir` and `-I` are handled correctly
 
 !--------------------------
-! FLANG DRIVER (flang-new)
+! FLANG DRIVER (flang)
 !--------------------------
 ! RUN: %flang -fsyntax-only -I %S/Inputs -I %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 ! RUN: %flang -fsyntax-only -I %S/Inputs -J %S/Inputs/module-dir %s 2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 ! RUN: %flang -fsyntax-only -I %S/Inputs -module-dir %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 
 ! RUN: not %flang -fsyntax-only -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2
 ! RUN: not %flang -fsyntax-only -J %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2
 ! RUN: not %flang -fsyntax-only -module-dir %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2
 
 ! RUN: not %flang -fsyntax-only -I %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=SINGLEINCLUDE
 ! RUN: not %flang -fsyntax-only -J %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=SINGLEINCLUDE
 ! RUN: not %flang -fsyntax-only -module-dir %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=SINGLEINCLUDE
 
 !-----------------------------------------
-! FRONTEND FLANG DRIVER (flang-new -fc1)
+! FRONTEND FLANG DRIVER (flang -fc1)
 !-----------------------------------------
 ! RUN: %flang_fc1 -fsyntax-only -I %S/Inputs -I %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 ! RUN: %flang_fc1 -fsyntax-only -I %S/Inputs -J %S/Inputs/module-dir %s 2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 ! RUN: %flang_fc1 -fsyntax-only -I %S/Inputs -module-dir %S/Inputs/module-dir %s  2>&1 | FileCheck %s --check-prefix=INCLUDED --allow-empty
 
 ! RUN: not %flang_fc1 -fsyntax-only -I %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2
 ! RUN: not %flang_fc1 -fsyntax-only -J %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2
 ! RUN: not %flang_fc1 -fsyntax-only -module-dir %S/Inputs %s  2>&1 | FileCheck %s --check-prefix=MISSING_MOD2

flang/test/Frontend/multiple-input-files.f90

 
 !--------------------------
 ! FLANG DRIVER (flang)
 !--------------------------
 ! NOTE: Use `-E` so that the compiler driver stops after the 1st compilation phase, preprocessing. That's all we need.
 
 ! TEST 1: Both input files are processed (output is printed to stdout)
 ! RUN: %flang -E %s %S/Inputs/hello-world.f90 | FileCheck %s --match-full-lines -check-prefix=FLANG
 
 ! TEST 2: None of the files is processed (not possible to specify the output file when multiple input files are present)
-! RUN: not %flang -E -o - %S/Inputs/hello-world.f90 %s  2>&1 | FileCheck %s --match-full-lines -check-prefix=ERROR
-! RUN: not %flang -E -o %t %S/Inputs/hello-world.f90 %s 2>&1 | FileCheck %s --match-full-lines -check-prefix=ERROR
+! RUN: not %flang -E -o - %S/Inputs/hello-world.f90 %s  2>&1 | FileCheck %s -check-prefix=ERROR
+! RUN: not %flang -E -o %t %S/Inputs/hello-world.f90 %s 2>&1 | FileCheck %s -check-prefix=ERROR
 
 !----------------------------------------
 ! FLANG FRONTEND DRIVER (flang -fc1)
 !----------------------------------------
 ! TEST 3: Both input files are processed
 ! This particular test case generates output files in the same directory as the input files. We need to copy the input files into a
 ! temporary directory to avoid polluting the source directory.
 ! RUN: rm -rf %t-dir && mkdir -p %t-dir && cd %t-dir

 ! FLANG-NEXT:  End Program arithmetic
 
 ! FLANG-LABEL: program hello
 ! FLANG-NEXT:  implicit none
 ! FLANG-NEXT:  write(*,*) 'Hello world!'
 ! FLANG-NEXT:end program hello
 
 ! TEST 2: `-o` does not when multiple input files are present
-! ERROR: flang-new: error: cannot specify -o when generating multiple output files
+! ERROR: error: cannot specify -o when generating multiple output files
 
 ! TEST 3: The output file _was not_ specified - `flang_fc1` will process all
 ! input files and generate one output file for every input file.
 ! FC1-OUTPUT1-LABEL: Program arithmetic
 ! FC1-OUTPUT1-NEXT:    Integer :: i, j
 ! FC1-OUTPUT1-NEXT:    i = 2; j = 3; i= i * j;
 ! FC1-OUTPUT1-NEXT:  End Program arithmetic
 

flang/test/Lower/Intrinsics/command_argument_count.f90

 ! RUN: bbc -emit-fir %s -o - | FileCheck %s
-! bbc doesn't have a way to set the default kinds so we use flang-new driver
-! RUN: flang-new -fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64  %s
+! bbc doesn't have a way to set the default kinds so we use flang driver
+! RUN: %flang_fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64  %s
 
 ! CHECK-LABEL: argument_count_test
 subroutine argument_count_test()
 integer :: arg_count_test
 arg_count_test = command_argument_count()
 ! CHECK: %[[argumentCount:.*]] = fir.call @_FortranAArgumentCount() : () -> i32
 ! CHECK-64: %{{[0-9]+}} = fir.convert %[[argumentCount]] : (i32) -> i64
 end subroutine argument_count_test

flang/test/Lower/Intrinsics/exit.f90

 ! RUN: bbc -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-32 -DDEFAULT_INTEGER_SIZE=32 %s
-! bbc doesn't have a way to set the default kinds so we use flang-new driver
-! RUN: flang-new -fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
+! bbc doesn't have a way to set the default kinds so we use flang driver
+! RUN: %flang_fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
 
 ! CHECK-LABEL: func @_QPexit_test1() {
 subroutine exit_test1
     call exit()
   ! CHECK: %[[status:.*]] = arith.constant 0 : i[[DEFAULT_INTEGER_SIZE]]
   ! CHECK-64: %[[statusConvert:.*]] = fir.convert %[[status]] : (i64) -> i32
   ! CHECK-32: %{{[0-9]+}} = fir.call @_FortranAExit(%[[status]]) : (i32) -> none
   ! CHECK-64: %{{[0-9]+}} = fir.call @_FortranAExit(%[[statusConvert]]) : (i32) -> none

flang/test/Lower/Intrinsics/get_command_argument.f90

 ! RUN: bbc -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-32 -DDEFAULT_INTEGER_SIZE=32 %s
-! RUN: flang-new -fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
+! RUN: %flang_fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
 
 ! CHECK-LABEL: func @_QPnumber_only(
 ! CHECK-SAME: %[[num:.*]]: !fir.ref<i[[DEFAULT_INTEGER_SIZE]]>{{.*}}) {
 subroutine number_only(num)
     integer :: num
     call get_command_argument(num)
 ! CHECK-NOT: fir.call @_FortranAArgumentValue
 ! CHECK-NOT: fir.call @_FortranAArgumentLength

flang/test/Lower/Intrinsics/get_environment_variable.f90

 ! RUN: bbc -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-32 -DDEFAULT_INTEGER_SIZE=32 %s
-! RUN: flang-new -fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
+! RUN: %flang_fc1 -fdefault-integer-8 -emit-fir %s -o - | FileCheck --check-prefixes=CHECK,CHECK-64 -DDEFAULT_INTEGER_SIZE=64 %s
 
 ! CHECK-LABEL: func @_QPnumber_only(
 ! CHECK-SAME: %[[nameArg:.*]]: !fir.boxchar<1> {fir.bindc_name = "name"}) {
 subroutine number_only(name)
     character(len=32) :: name
     call get_environment_variable(name)
 ! CHECK-NOT: fir.call @_FortranAEnvVariableValue
 ! CHECK-NOT: fir.call @_FortranAEnvVariableLength

flang/test/Lower/OpenACC/Todo/acc-declare.f90

 ! This test checks lowering of OpenACC declare Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenacc %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenacc %s 2>&1 | FileCheck %s
 
 program main
   real, dimension(10) :: aa, bb
 
   // CHECK: not yet implemented: OpenACC Standalone Declarative construct
   !$acc declare present(aa, bb)
 end

flang/test/Lower/OpenACC/Todo/acc-routine.f90

 ! This test checks lowering of OpenACC routine Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenacc %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenacc %s 2>&1 | FileCheck %s
 
 program main
   // CHECK: not yet implemented: OpenACC Routine construct not lowered yet!
   !$acc routine(sub) seq
 contains
   subroutine sub(a)
     real :: a(:)
   end
 end

flang/test/Lower/OpenMP/Todo/omp-declarative-allocate.f90

 ! This test checks lowering of OpenMP allocate Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
 
 program main
   integer :: x, y
 
   // CHECK: not yet implemented: OpenMPDeclarativeAllocate
   !$omp allocate(x, y)
 end

flang/test/Lower/OpenMP/Todo/omp-declare-reduction.f90

 ! This test checks lowering of OpenMP declare reduction Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
 
 subroutine declare_red()
   integer :: my_var
   // CHECK: not yet implemented: OpenMPDeclareReductionConstruct
   !$omp declare reduction (my_red : integer : omp_out = omp_in) initializer (omp_priv = 0)
   my_var = 0
 end subroutine declare_red

flang/test/Lower/OpenMP/Todo/omp-declare-simd.f90

 ! This test checks lowering of OpenMP declare simd Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
 
 subroutine sub(x, y)
   real, intent(inout) :: x, y
 
   // CHECK: not yet implemented: OpenMPDeclareSimdConstruct
   !$omp declare simd(sub) aligned(x)
   x = 3.14 + y
 end

flang/test/Lower/OpenMP/Todo/omp-declare-target.f90

 ! This test checks lowering of OpenMP declare target Directive.
 
-// RUN: not flang-new -fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
+// RUN: not %flang_fc1 -emit-fir -fopenmp %s 2>&1 | FileCheck %s
 
 module mod1
 contains
   subroutine sub()
     integer :: x, y
     // CHECK: not yet implemented: OpenMPDeclareTargetConstruct
     !$omp declare target
   end
 end module

flang/test/lit.cfg.py

 
 if config.flang_standalone_build:
     # For builds with FIR, set path for tco and enable related tests
     if config.flang_llvm_tools_dir != "":
         config.available_features.add('fir')
         if config.llvm_tools_dir != config.flang_llvm_tools_dir:
             llvm_config.with_environment('PATH', config.flang_llvm_tools_dir, append_path=True)
 
+# Select the driver name for this configuration
+if config.use_driver_legacy_name:
+    driver_name = "flang-new"
+else:
+    driver_name = "flang"
+
 # For each occurrence of a flang tool name, replace it with the full path to
 # the build directory holding that tool.
 tools = [
-        ToolSubst('%flang', command=FindTool('flang-new'), unresolved='fatal'),
-    ToolSubst('%flang_fc1', command=FindTool('flang-new'), extra_args=['-fc1'],
+        ToolSubst('%flang', command=FindTool(driver_name), unresolved='fatal'),
+        ToolSubst('%flang_fc1', command=FindTool(driver_name), extra_args=['-fc1'],
             unresolved='fatal')]
 
 # Flang has several unimplemented features. TODO messages are used to mark and fail if these
 # features are exercised. TODOs exit with an error in non-assert builds but in assert builds
 # it aborts. To catch aborts, the `--crash` option for the `not` command has to be used.
 if 'asserts' in config.available_features:
     tools.append(ToolSubst('%not_todo_cmd', command=FindTool('not'), extra_args=['--crash'],
         unresolved='fatal'))
 else:

flang/test/lit.site.cfg.py.in

 config.flang_llvm_tools_dir = "@CMAKE_BINARY_DIR@/bin"
 config.flang_lib_dir = "@CMAKE_BINARY_DIR@/lib"
 config.flang_examples = @FLANG_BUILD_EXAMPLES@
 config.python_executable = "@PYTHON_EXECUTABLE@"
 config.flang_standalone_build = @FLANG_STANDALONE_BUILD@
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.cc = "@CMAKE_C_COMPILER@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
+config.use_driver_legacy_name = @FLANG_USE_LEGACY_NAME@
 
 import lit.llvm
 lit.llvm.initialize(lit_config, config)
 
 # Let the main config do the real work.
 lit_config.load_config(config, "@FLANG_SOURCE_DIR@/test/lit.cfg.py")

flang/tools/f18/CMakeLists.txt

else()
     endif()
     if(${filename} STREQUAL "ieee_arithmetic" OR
        ${filename} STREQUAL "ieee_exceptions")
       set(depends ${FLANG_INTRINSIC_MODULES_DIR}/__fortran_ieee_exceptions.mod)
     endif()
   endif()
   add_custom_command(OUTPUT ${base}.mod
     COMMAND ${CMAKE_COMMAND} -E make_directory ${FLANG_INTRINSIC_MODULES_DIR}
-    COMMAND flang-new -fc1 -fsyntax-only -module-dir ${FLANG_INTRINSIC_MODULES_DIR}
+    COMMAND flang -fc1 -fsyntax-only -module-dir ${FLANG_INTRINSIC_MODULES_DIR}
       ${FLANG_SOURCE_DIR}/module/${filename}.f90
-    DEPENDS flang-new ${FLANG_SOURCE_DIR}/module/${filename}.f90 ${depends}
+    DEPENDS flang ${FLANG_SOURCE_DIR}/module/${filename}.f90 ${depends}
   )
   add_custom_command(OUTPUT ${base}.f18.mod
     DEPENDS ${base}.mod
     COMMAND ${CMAKE_COMMAND} -E copy ${base}.mod ${base}.f18.mod)
   list(APPEND MODULE_FILES ${base}.mod ${base}.f18.mod)
   install(FILES ${base}.mod ${base}.f18.mod DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}/flang")
 endforeach()
 
 add_custom_target(module_files ALL DEPENDS ${MODULE_FILES})
 
-# This flang shell script will only work in a POSIX shell.
+# The flang-to-gfortan shell script will only work in a POSIX shell.
 if (NOT WIN32)
   add_custom_command(
     OUTPUT ${CMAKE_BINARY_DIR}/bin/flang-to-external-fc
     DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/flang-to-external-fc
     COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/flang-to-external-fc ${CMAKE_BINARY_DIR}/bin)
   add_custom_target(flang-to-external-fc ALL DEPENDS ${CMAKE_BINARY_DIR}/bin/flang-to-external-fc)
   install(PROGRAMS ${CMAKE_BINARY_DIR}/bin/flang-to-external-fc DESTINATION "${CMAKE_INSTALL_BINDIR}")
 endif()
 
 # TODO Move this to a more suitable location
 file(COPY ${FLANG_SOURCE_DIR}/module/omp_lib.h DESTINATION "${CMAKE_BINARY_DIR}/include/flang/OpenMP/" FILE_PERMISSIONS OWNER_READ OWNER_WRITE)

flang/tools/flang-driver/CMakeLists.txt

 # Infrastructure to build flang driver entry point. Flang driver depends on
 # LLVM libraries.
 
 # Set your project compile flags.
 link_directories(${LLVM_LIBRARY_DIR})
 
 set( LLVM_LINK_COMPONENTS
   ${LLVM_TARGETS_TO_BUILD}
   Option
   Support
 )
 
-add_flang_tool(flang-new
+add_flang_tool(flang
   driver.cpp
   fc1_main.cpp
 
   DEPENDS
   # These libraries are used in the linker invocation generated by the driver
   # (i.e. when constructing the linker job). Without them the driver would be
   # unable to generate executables.
   FortranRuntime
   FortranDecimal
   Fortran_main
 )
 
-target_link_libraries(flang-new
+target_link_libraries(flang
   PRIVATE
   flangFrontend
   flangFrontendTool
 )
 
-clang_target_link_libraries(flang-new
+clang_target_link_libraries(flang
   PRIVATE
   clangDriver
   clangBasic
 )
 
+if(WIN32 AND NOT CYGWIN)
+  # Prevent versioning if the buildhost is targeting for Win32.
+else()
+  set_target_properties(flang PROPERTIES VERSION ${FLANG_EXECUTABLE_VERSION})
+endif()
+
+if (FLANG_USE_LEGACY_NAME)
+  set_target_properties(flang PROPERTIES OUTPUT_NAME flang-new)
+endif()
+
 option(FLANG_PLUGIN_SUPPORT "Build Flang with plugin support." ON)
 
-# Enable support for plugins, which need access to symbols from flang-new
+# Enable support for plugins, which need access to symbols from flang
 if(FLANG_PLUGIN_SUPPORT)
-  export_executable_symbols_for_plugins(flang-new)
+  export_executable_symbols_for_plugins(flang)
 endif()
 
-install(TARGETS flang-new DESTINATION "${CMAKE_INSTALL_BINDIR}")
+install(TARGETS flang DESTINATION "${CMAKE_INSTALL_BINDIR}")

flang/tools/flang-driver/driver.cpp

 }
 
 int main(int argc, const char **argv) {
 
   // Initialize variables to call the driver
   llvm::InitLLVM x(argc, argv);
   llvm::SmallVector<const char *, 256> args(argv, argv + argc);
 
-  clang::driver::ParsedClangName targetandMode("flang", "--driver-mode=flang");
+  clang::driver::ParsedClangName targetandMode =
+      clang::driver::ToolChain::getTargetAndModeFromProgramName(argv[0]);
   std::string driverPath = getExecutablePath(args[0]);
 
   llvm::BumpPtrAllocator a;
   llvm::StringSaver saver(a);
   ExpandResponseFiles(saver, args);
 
-  // Check if flang-new is in the frontend mode
+  // Check if flang is in the frontend mode
   auto firstArg = std::find_if(
       args.begin() + 1, args.end(), [](const char *a) { return a != nullptr; });
   if (firstArg != args.end()) {
     if (llvm::StringRef(args[1]).startswith("-cc1")) {
       llvm::errs() << "error: unknown integrated tool '" << args[1] << "'. "
                    << "Valid tools include '-fc1'.\n";
       return 1;
     }
-    // Call flang-new frontend
+    // Call flang frontend
     if (llvm::StringRef(args[1]).startswith("-fc1")) {
       return executeFC1Tool(args);
     }
   }
 
   // Not in the frontend mode - continue in the compiler driver mode.
 
   // Create DiagnosticsEngine for the compiler driver