[clang][driver] Add basic --driver-mode=flang support for fortran

[peterwaller-arm]

Summary

As per the RFC in http://lists.llvm.org/pipermail/cfe-dev/2019-June/062669.html.

This patch adds a new Flang mode. When in Flang mode, the driver will
invoke flang for fortran inputs instead of falling back to the GCC
toolchain as it would otherwise do.

The behaviour of other driver modes are left unmodified to preserve
backwards compatibility.

It is intended that a soon to be implemented binary in the flang project
will import libclangDriver and run the clang driver in the new flang
mode.

Please note that since the binary invoked by the driver is under
development, there will no doubt be further tweaks necessary in future
commits.

• Initial support is added for basic driver phases
  • -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified)
  • -### tests are added for all of the above
  • This is more than is supported by f18 so far, which will emit errors for those options which are unimplemented.

• A test is added that ensures that clang gives a reasonable error message if flang is not available in the path (without -###).

• Test that the driver accepts multiple inputs in --driver-mode=flang.

• Test that a combination of C and Fortran inputs run both clang and flang in --driver-mode=flang.

• clang/test/Driver/fortran.f95 is fixed to use the correct fortran comment character.

[peterwaller-arm]

Note: In case you see this early, the email isn't yet sent to the list. I'll link it here when it is, likely tomorrow.

[Hahnfeld]

Even though I know you didn't send the email yet, can you please upload the diff with full context? Thanks :-)

[peterwaller-arm]

Include full context.

[peterwaller-arm]

I updated this "prototype" revision into the real thing I would like to submit. Please let me know if that was the wrong thing to do and I will resubmit it.

This is an initial implementation which naturally doesn't implement very much. More will come in future patches.

[hfinkel]

clang/lib/Driver/ToolChains/Flang.cpp

74

Should this say "Invalid output"?

[peterwaller-arm]

Fixed assertion message "Input output." => "Invalid output". The erroneous text came was copied from: https://github.com/llvm/llvm-project/blob/6b9df910d04fae62dacc22c1c84f66c0f126cde0/clang/lib/Driver/ToolChains/Clang.cpp#L3849

[richard.barton.arm]

Hi Peter

The overall approach seems good to me and matches how the driver is integrated in the original flang project so not too many surprises. I left a few comments mostly about the scope of the original patch. I wonder how much sense it makes to add support for routing options on to (f18) flang that it does not support yet? Would it not be better to add these options to the clang driver at the same time as they arrive in flang -fc1?

Ta
Rich

clang/lib/Driver/Driver.cpp

4877

This first clause surprised me. Is this a temporary measure or do we never intend to support compiling more than one fortran file at once?

clang/lib/Driver/ToolChains/Flang.cpp

38

F18 does not currently support these options that control the output like -emit-llvm and -emit-obj so this code doesn't do anything sensible at present. Would it not make more sense to add this later on once F18 or llvm/flang grows support for such options?

45

Looks like the F18 option spelling for this is -fparse-only? Or maybe -fdebug-semantics? I know the intention is to throw away the 'throwaway driver' in F18, so perhaps you are preparing to replace this option spelling in the throwaway driver with -fsyntax-only so this would highlight that perhaps adding the code here before the F18 driver is ready to accept it is not the right approach?

68

Similarly to previous comment, do we want to be passing all gfortran options through to F18 in the immediate term or even the long term? I don't think there has been any agreement yet on what the options that F18 will support are (although I agree that gfortran-like options would be most sensible and in keeping with clang's philosophy)

clang/test/Driver/fortran.f95

1–2

... when not in --driver-mode=fortran

[peterwaller-arm]

Updated for review comments and spotted a couple of things myself.

Changes since last time:

• Removed various options which aren't yet implemented on the f18 side.
• --driver-mode=fortran is now --driver-mode=flang, which is more consistent with other modes.
• Added tests which show that multiple inputs (and mixed C+Fortran inputs) are supported by the driver.
• Updated comments.
• Removed a branch in getTool which didn't make sense.
• Updated commit message.

clang/lib/Driver/Driver.cpp

4877

This function answers the question at the scope of a single JobAction. My understanding is that the compiler (as with clang -cc1) will be invoked once per input file.

This does not prevent multiple fortran files from being compiled with a single driver invocation.

clang/lib/Driver/ToolChains/Flang.cpp

38

I've removed them.

45

In the RFC, the intent expressed was to mimick gfortran and clang options. I am making a spelling choice here that I think it should be called -fsyntax-only, which matches those. I intend to make the flang -fc1 side match in the near future.

-fdebug-* could be supported through an -Xflang ... option to pass debug flags through.

68

I have deleted these options pass-throughs. I think you're right in general that we should only add options along with support for those things. The plan is now to add an OPT_flang_Group (or alike) later.

clang/test/Driver/fortran.f95

1–2

Fixed.

[peterwaller-arm]

Updated comment for IsFlangMode.

[kiranchandramohan]

Some minor comments about Filetypes and file extensions. Can be ignored or considered for a separate commit.

clang/include/clang/Driver/Driver.h

69

Is the comma by choice?

clang/lib/Driver/ToolChains/Flang.cpp

38

Can it be removed from the Summary of this PR?

clang/lib/Driver/Types.cpp

220

Now that there is a 2018 standard, I am assuming that f18 and F18 are also valid fortran extensions. Can these be added to the File types?

Also, should the TypeInfo file be extended to handle all Fortran file types? ./include/clang/Driver/Types.def

Also, should we capture some information about the standards from the filename extension?

clang/test/Driver/lit.local.cfg

1

For completion .F95 also?
Should we add f03,F03,f08,F08,f18,F18. May be not now.

[peterwaller-arm]

• Fixed spurious comma
• Fixed incorrect comment and changed comment wrapping.

[richard.barton.arm]

Thanks for the updates. I think this is now looking good and matches the RFC already posted.

One thought that occurs to me when reviewing this. I think we will assume that F18/flang when it lands in the LLVM project will be an optional thing to build and will be an opt-in project at the start that is off by default. What happens when clang --driver-mode=flang is called and flang has not been built? And where would we put a test for that behaviour? If flang were not to be built, should --driver-mode=flang be unsupported/unrecognised and emit an error message?

Might not be something we need to address with this patch, but have you considered this?

clang/include/clang/Driver/Driver.h

186

Need to update the cover letter for the patch then as it still talks about 'fortran mode' rather than 'flang mode'.

clang/lib/Driver/Driver.cpp

4877

Righto - thanks for the explanation.

clang/lib/Driver/ToolChains/Flang.cpp

45

OK - happy with this approach. So -fsyntax-only and -emit-ast will be the new names for f18's -fdebug-semantics and -fdebug-dump-parse-tree I guess.

clang/lib/Driver/Types.cpp

220

Agree with those first two, but that last one is surely a new feature that needs adding when such a feature is enabled in the rest of F18.

We'd need to think that through carefully too. Classic flang never supported such an option and GCC's -std option from C/C++ does not work for Fortran. Also, would that go in the driver or in flang -fc1?

I suggest holding fire on this until we are ready to do it properly.

clang/test/Driver/fortran.f95

2

Need to change "see also --drver-mode=fortran" to "--driver-mode=flang" here.

[hfinkel]

One thought that occurs to me when reviewing this. I think we will assume that F18/flang when it lands in the LLVM project will be an optional thing to build and will be an opt-in project at the start that is off by default. What happens when clang --driver-mode=flang is called and flang has not been built? And where would we put a test for that behaviour? If flang were not to be built, should --driver-mode=flang be unsupported/unrecognised and emit an error message?

The Clang tests should not actually run flang regardless - they should just test the command line that should be run. An error might be emitted if "flang" isn't found in the relevant search paths, however, that makes sense to me (although we might override this for the purpose of the tests?).

[peterwaller-arm]

Thanks everyone for your comments.

Changes since last patch:

• Reintroduce handling of (no phase arg specified), -S, -emit-llvm, etc.
  
  The code implementing it was reordered for clarity.
  
  After internal discussion we concluded it was preferable to land these now even though they are unimplemented on the frontend side, in order to avoid giving assertion errors for unimplemented behaviour.
  
  It is planned that the frontend will emit sensible errors for unimplemented behaviour.

• Fixes to the cover letter for --driver-mode=fortran => --driver-mode=flang

• Add a test (flang-not-installed.f90) which demonstrates the error message if clang is invoked with no flang available, by unsetting PATH. This is a non-"-###" test which also does not depend on the presence of flang.
  • Since it uses shell syntax, it is marked unsupported on windows.

• In response to a private comment, Flang mode now coerces TY_PP_Fortran to TY_Fortran. This:
  • Leaves the legacy behaviour unchanged
  • Ensures that we do not emit a warning when passing TY_PP_Fortran inputs to -E
  • Should ensure that TY_PP_Fortran is treated exactly as a fortran file
  • Is consistent with f18's intent to not have any notion of preprocessed sources
  • Now the flang.f90 and flang.F90 tests are identical except for the filename

• Various minor whitespace changes and documentation fixes.

clang/include/clang/Driver/Driver.h

69

It was not. Fixed.

clang/lib/Driver/ToolChains/Flang.cpp

38

They have now been reintroduced after we found that it had an unpleasant failure mode. Better to implement them now, after all, and fail gracefully in the frontend.

45

Agreed. They can still be changed later if necessary.

clang/lib/Driver/Types.cpp

220

My reading of the code is that both [fF]90 and [fF]95 both get turned into TY_Fortran/TY_PP_Fortran.

Both of these in the Types.def end up coerced to "f95", currently. I don't think the driver wants an entry in the Types.def for each fortran standard - it doesn't have them for other languages, for example, and I'm unsure what the benefit of that would be. The main purpose of that table as far as I see is to determine what phases need to run.

My feeling is that the name in the types table should be "fortran". I don't want to make that change in the scope of this PR, since it might be a breaking change. It looks to me like the name works its way out towards human eyeballs but is otherwise unused.

I would like to implement -std inference from the file extension and additional fortran filename extensions (f18 etc) in another change request.

220

Agreed, thanks for clarifying.

I didn't intend to suggest that it was something to be implemented in the near future. Just the future.

clang/test/Driver/fortran.f95

2

Fixed.

clang/test/Driver/lit.local.cfg

1

Since the file I added was .F90, that is what got added.

I have added strictly what was used by the tests under the assumption that others could be introduced when those are used. I would prefer not to add the others until they exist and are exercised (perhaps could happen as part of -std inference).

[richard.barton.arm]

I think the behaviour for missing flang is fine for now, and I think we can improve on it later on.
We ought to codify (if it is not done already) where flang looks for tools to exec, because I think PATH is probably not the only place it could look to (directory of clang binary, other relative paths, other environment variables and commandline options, etc.) The new test will need revising once we get there.

I think this patch is looking good to be committed - what do you think @hfinkel ?

[peterwaller-arm]

Hi All, I'm going on leave for two weeks, returning October 14th. I can plausibly respond to comments until 14:00 UTC tomorrow (Thu 25th Sept).

As a quick note, another piece of the puzzle has been submitted for review at https://github.com/flang-compiler/f18/pull/759, which is the flang-side binary which will link to this code and default to running the driver in flang mode.

[peterwaller-arm]

Friendly ping to everybody watching. I'd like to get this in soon if possible.

Hal - do you think this is close to being accepted? Note that I consider this "the beginning" rather than "the end", since there will be more functionality to add piecewise before this is fully functional. In the meantime, since it is new functionality, it should not break anything.

[hfinkel]

In D63607#1709258, @peterwaller-arm wrote:

Friendly ping to everybody watching. I'd like to get this in soon if possible.

Hal - do you think this is close to being accepted? Note that I consider this "the beginning" rather than "the end", since there will be more functionality to add piecewise before this is fully functional. In the meantime, since it is new functionality, it should not break anything.

One comment on the test, but otherwise LGTM.

clang/test/Driver/flang/flang-not-installed.f90

11 ↗

(On Diff #220856)

I believe that you can write:

REQUIRES: shell

for this.

[peterwaller-arm]

I have rebased the patch for conflicts to master and all the tests are passing.

While doing so, I discovered that the test for flang-not-installed was not fit for purpose, because clang actually doesn't first check the PATH, it can find a flang binary which lives in the same directory as itself. I conclude that having such a test is more trouble than it is worth. Adding such a test would involve adding some questionable test-specific machinery. Therefore I've removed that test for now.

I'll leave the patch over the weekend in case anyone objects, otherwise I intend to submit early next week.

[peterwaller-arm]

clang/test/Driver/flang/flang-not-installed.f90

11 ↗

(On Diff #220856)

I've removed this test for now because I discovered that setting PATH="" is not enough to make clang lose the flang binary, if the flang binary is in the same directory as clang (which will be likely once flang is in-tree).

[peterwaller-arm]

I'm still awaiting commit access, please can someone submit this on my behalf?

[peterwaller-arm]

Revoking my previous request: I now have commit access and I intend to submit this shortly.

[peterwaller-arm]

Submitted in 6bf55804924d5a1d902925ad080b1a2b57c5c75c.

[teemperor]

Could we have the clang/test/Driver/flang/flang.F90 and clang/test/Driver/flang/flang.f90 files in different directories please? As macOS's FS is case-insensitive, those two files have the same path from macOS perspective which is causing a whole bunch of issues (including breaking git even with 'core.ignorecase').

[thakis]

Sorry, I had missed the RfC, but it looks like there wasn't a lot of discussion on it anyways.

Adding fortran support to clang's driver has been suggested and decided against before, see "[cfe-commits] [RFC and PATCH] Fortran"

In D63607#1726895, @teemperor wrote:

Could we have the clang/test/Driver/flang/flang.F90 and clang/test/Driver/flang/flang.f90 files in different directories please? As macOS's FS is case-insensitive, those two files have the same path from macOS perspective which is causing a whole bunch of issues (including breaking git even with 'core.ignorecase').

One issue is that the test flakily fails about half the time

http://45.33.8.238/mac/2498/summary.html fail
http://45.33.8.238/mac/2499/summary.html pass
http://45.33.8.238/mac/2500/summary.html fail
http://45.33.8.238/mac/2501/summary.html pass
http://45.33.8.238/mac/2502/summary.html fail
http://45.33.8.238/mac/2503/summary.html pass
http://45.33.8.238/mac/2504/summary.html fail

[peterwaller-arm]

In D63607#1726895, @teemperor wrote:

Could we have the clang/test/Driver/flang/flang.F90 and clang/test/Driver/flang/flang.f90 files in different directories please? As macOS's FS is case-insensitive, those two files have the same path from macOS perspective which is causing a whole bunch of issues (including breaking git even with 'core.ignorecase').

This was fixed by Jeremy Morse in 6c0a160c2d33e54aecf1538bf7c85d8da92051be - thanks.

I'm investigating the non-deterministic failure but don't have access to a mac to test.

@thakis is the flaky test resolved by 6c0a160c or is it still outstanding?

[teemperor]

6c0a160c2d33e54aecf1538bf7c85d8da92051be renamed the file (thanks Jeremy).

In D63607#1726978, @peterwaller-arm wrote:

In D63607#1726895, @teemperor wrote:

Could we have the clang/test/Driver/flang/flang.F90 and clang/test/Driver/flang/flang.f90 files in different directories please? As macOS's FS is case-insensitive, those two files have the same path from macOS perspective which is causing a whole bunch of issues (including breaking git even with 'core.ignorecase').

This was fixed by Jeremy Morse in 6c0a160c2d33e54aecf1538bf7c85d8da92051be - thanks.

I'm investigating the non-deterministic failure but don't have access to a mac to test.

@thakis is the flaky test resolved by 6c0a160c or is it still outstanding?

Green dragon survived the change (because it doesn't run git pull I assume) and is running the tests soon-ish: http://green.lab.llvm.org/green/view/Clang/job/clang-stage1-cmake-RA-incremental/4685/console

[peterwaller-arm]

Thanks for chiming in.

Sorry, I had missed the RfC, but it looks like there wasn't a lot of discussion on it anyways.

Apologies @thakis - did I jump the gun? And if so, what could I have done differently?

Adding fortran support to clang's driver has been suggested and decided against before, see "[cfe-commits] [RFC and PATCH] Fortran"

Interesting, I had missed that conversation! Google and DDG fail to find it for me even quoting sentences out of it. Found it by wgetting the gzip mailing list archives and grepping them - is there a better way? :)

That conversation was in 2012, and since then flang has been accepted as a subproject to LLVM in "[llvm-dev] f18 is accepted as part of LLVM project!". Since the acceptance, the project has renamed to flang, and is in the process of actively being integrated into the llvm project.

As discussed in the RFC, I understand that libclangDriver was always intended to be a flexible driver used by other frontends, so in light of that, does the change still seem unreasonable? My expectation is that the footprint of fortran on libclangDriver should only be quite modest.

[thakis]

In D63607#1727037, @peterwaller-arm wrote:

Thanks for chiming in.

Sorry, I had missed the RfC, but it looks like there wasn't a lot of discussion on it anyways.

Apologies @thakis - did I jump the gun? And if so, what could I have done differently?

Whoops, sorry! I had meant to delete that bit. I started writing that, then went back to the old discussion thread, and saw that there was actually agreement on giving clang's driver knowledge about fortran (but not the preprocessor etc). So this is all good as far as I can tell. Please ignore that part.

The test is still failing fairly consistently on my bot, even after 6c0a160c . (And that change required me to change my bots from git merge --ff-only origin/master to git reset --hard origin/master after fetching, but that's a good change to do anyways ;) ). Does http://45.33.8.238/mac/2528/step_6.txt make any sense to you, or should I ssh in and debug?

[thakis]

Interesting, I had missed that conversation! Google and DDG fail to find it for me even quoting sentences out of it. Found it by wgetting the gzip mailing list archives and grepping them - is there a better way? :)

(If you want, I can forward you the thread. But as I said, I just failed to delete my toplevel comment; all good.)

[peterwaller-arm]

@thakis: I found the thread at https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120430/057199.html

@thakis: I can't make quick sense of the failure from those logs alone. I would appreciate it very much to see the output of the clang -### run lines to see what's missing. It should be showing that it would invoke flang.

[thakis]

@thakis: I can't make quick sense of the failure from those logs alone. I would appreciate it very much to see the output of the clang -### run lines to see what's missing. It should be showing that it would invoke flang.

It's the very first run line that's failing. The output looks like so:

$ out/gn/bin/clang --driver-mode=flang -### -E /Users/thakis/src/llvm-project/clang/test/Driver/flang/flang.f90
clang version 10.0.0 
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Users/thakis/src/llvm-project/out/gn/bin
clang: warning: /Users/thakis/src/llvm-project/clang/test/Driver/flang/flang.f90: previously preprocessed input [-Wunused-command-line-argument]

[peterwaller-arm]

I've thought about it for a moment and I'm currently at a loss to quickly explain why this would only fail on darwin. In my patch, the change to LookupTypeForExtension should prevent clang from reaching this state where it complains about a preprocessed input.

I don't have access to a darwin machine right now to dive in, understand and fix it.

I propose to mark the test UNSUPPORTED: darwin until more is understood about the breakage. I assume there is no issue with that?

[peterwaller-arm]

@thakis: I've marked the test unsupported in c75cd3c7f0f. Hopefully that makes your builder happy! I'll figure out what is going on and fix it.

[thakis]

Thanks!

Looks like it's just the -E test that's causing problems; the test passes with that disabled:

$ git diff
diff --git a/clang/test/Driver/flang/flang.f90 b/clang/test/Driver/flang/flang.f90
index 97e4847f843..4cbc2cd8754 100644
--- a/clang/test/Driver/flang/flang.f90
+++ b/clang/test/Driver/flang/flang.f90
@@ -1,6 +1,5 @@
 ! D63607 made mac builders unhappy by failing this test, and it isn't
 ! yet obvious why. Mark as unsupported as a temporary measure.
-! UNSUPPORTED: darwin
 
 ! Check that flang -fc1 is invoked when in --driver-mode=flang.
 
@@ -21,10 +20,9 @@
 
 ! 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
+! RUN: %clang --driver-mode=flang -###                   %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-E %s
 ! CHECK-E-NOT: previously preprocessed input
-! CHECK-E-DAG: "-E"
-! CHECK-E-DAG: "-o" "-"
+! CHECK-E-DAG: "-o"
 
 ! RUN: %clang --driver-mode=flang -### -emit-ast           %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-AST %s
 ! CHECK-EMIT-AST-DAG: "-triple"

I'll debug a bit more.

clang/lib/Driver/Driver.cpp

4883

(please run clang-format on your new code -- it might also answer why some enums have a comma after the last entry ;) )

[thakis]

I had some time to take a look. D69636 makes things work on mac.

[echristo]

Sadly I'm just noticing this:

I don't really agree with the rationale for adding fortran support to the clang driver. My proposed design here would be to move the aspects you need out of clang and into a separate library in llvm that you can use instead.

I don't necessarily want to remove this immediately, but I think work should be done to move forward in this other direction and eventually migrate this out.

Thanks!

clang/include/clang/Driver/Driver.h

class Driver {
   DiagnosticsEngine &Diags;
 
   IntrusiveRefCntPtr<llvm::vfs::FileSystem> VFS;
 
   enum DriverMode {
     GCCMode,
     GXXMode,
     CPPMode,
-    CLMode
+    CLMode,
+    FlangMode
   } Mode;
 
   enum SaveTempsMode {
     SaveTempsNone,
     SaveTempsCwd,
     SaveTempsObj
   } SaveTemps;
 
public:
   bool CCCIsCPP() const { return Mode == CPPMode; }
 
   /// Whether the driver should follow gcc like behavior.
   bool CCCIsCC() const { return Mode == GCCMode; }
 
   /// Whether the driver should follow cl.exe like behavior.
   bool IsCLMode() const { return Mode == CLMode; }
 
+  /// Whether the driver should invoke flang for fortran inputs.
+  /// Other modes fall back to calling gcc which in turn calls gfortran.
+  bool IsFlangMode() const { return Mode == FlangMode; }
+
   /// Only print tool bindings, don't build any jobs.
   unsigned CCCPrintBindings : 1;
 
   /// Set CC_PRINT_OPTIONS mode, which is like -v but logs the commands to
   /// CCPrintOptionsFilename or to stderr.
   unsigned CCPrintOptions : 1;
 
   /// Set CC_PRINT_HEADERS mode, which causes the frontend to log header include
public:
 
   /// Return the pathname of the pch file in clang-cl mode.
   std::string GetClPchPath(Compilation &C, StringRef BaseName) const;
 
   /// ShouldUseClangCompiler - Should the clang compiler be used to
   /// handle this action.
   bool ShouldUseClangCompiler(const JobAction &JA) const;
 
+  /// ShouldUseFlangCompiler - Should the flang compiler be used to
+  /// handle this action.
+  bool ShouldUseFlangCompiler(const JobAction &JA) const;
+
   /// Returns true if we are performing any kind of LTO.
   bool isUsingLTO() const { return LTOMode != LTOK_None; }
 
   /// Get the specific kind of LTO being performed.
   LTOKind getLTOMode() const { return LTOMode; }
 
 private:
 

clang/include/clang/Driver/ToolChain.h

private:
 
   /// The list of toolchain specific path prefixes to search for files.
   path_list FilePaths;
 
   /// The list of toolchain specific path prefixes to search for programs.
   path_list ProgramPaths;
 
   mutable std::unique_ptr<Tool> Clang;
+  mutable std::unique_ptr<Tool> Flang;
   mutable std::unique_ptr<Tool> Assemble;
   mutable std::unique_ptr<Tool> Link;
   mutable std::unique_ptr<Tool> IfsMerge;
   mutable std::unique_ptr<Tool> OffloadBundler;
   mutable std::unique_ptr<Tool> OffloadWrapper;
 
   Tool *getClang() const;
+  Tool *getFlang() const;
   Tool *getAssemble() const;
   Tool *getLink() const;
   Tool *getIfsMerge() const;
   Tool *getClangAs() const;
   Tool *getOffloadBundler() const;
   Tool *getOffloadWrapper() const;
 
   mutable std::unique_ptr<SanitizerArgs> SanitizerArguments;

clang/include/clang/Driver/Types.h

#undef TYPE
   bool isCuda(ID Id);
 
   /// isHIP - Is this a HIP input.
   bool isHIP(ID Id);
 
   /// isObjC - Is this an "ObjC" input (Obj-C and Obj-C++ sources and headers).
   bool isObjC(ID Id);
 
+  /// isFortran - Is this a Fortran input.
+  bool isFortran(ID Id);
+
   /// isSrcFile - Is this a source file, i.e. something that still has to be
   /// preprocessed. The logic behind this is the same that decides if the first
   /// compilation phase is a preprocessing one.
   bool isSrcFile(ID Id);
 
   /// lookupTypeForExtension - Lookup the type to use for the file
   /// extension \p Ext.
   ID lookupTypeForExtension(llvm::StringRef Ext);

clang/lib/Driver/CMakeLists.txt

add_clang_library(clangDriver
   ToolChains/Clang.cpp
   ToolChains/CloudABI.cpp
   ToolChains/CommonArgs.cpp
   ToolChains/Contiki.cpp
   ToolChains/CrossWindows.cpp
   ToolChains/Cuda.cpp
   ToolChains/Darwin.cpp
   ToolChains/DragonFly.cpp
+  ToolChains/Flang.cpp
   ToolChains/FreeBSD.cpp
   ToolChains/Fuchsia.cpp
   ToolChains/Gnu.cpp
   ToolChains/Haiku.cpp
   ToolChains/HIP.cpp
   ToolChains/Hexagon.cpp
   ToolChains/Hurd.cpp
   ToolChains/Linux.cpp

clang/lib/Driver/Driver.cpp

if (!Opt.startswith(OptName))
     return;
   StringRef Value = Opt.drop_front(OptName.size());
 
   if (auto M = llvm::StringSwitch<llvm::Optional<DriverMode>>(Value)
                    .Case("gcc", GCCMode)
                    .Case("g++", GXXMode)
                    .Case("cpp", CPPMode)
                    .Case("cl", CLMode)
+                   .Case("flang", FlangMode)
                    .Default(None))
     Mode = *M;
   else
     Diag(diag::err_drv_unsupported_option_argument) << OptName << Value;
 }
 
 InputArgList Driver::ParseArgStrings(ArrayRef<const char *> ArgStrings,
                                      bool IsClCompatMode,
bool Driver::ShouldUseClangCompiler(const JobAction &JA) const {
   // And say "no" if this is not a kind of action clang understands.
   if (!isa<PreprocessJobAction>(JA) && !isa<PrecompileJobAction>(JA) &&
       !isa<CompileJobAction>(JA) && !isa<BackendJobAction>(JA))
     return false;
 
   return true;
 }
 
+bool Driver::ShouldUseFlangCompiler(const JobAction &JA) const {
+  // Say "no" if there is not exactly one input of a type flang understands.
+  if (JA.size() != 1 ||
+      !types::isFortran((*JA.input_begin())->getType()))
+    return false;
+
+  // And say "no" if this is not a kind of action flang understands.
+  if (!isa<PreprocessJobAction>(JA) && !isa<CompileJobAction>(JA) && !isa<BackendJobAction>(JA))
+    return false;
+
+  return true;
+}
+
 /// GetReleaseVersion - Parse (([0-9]+)(.([0-9]+)(.([0-9]+)?))?)? and return the
 /// grouped values as integers. Numbers which are not provided are set to 0.
 ///
 /// \return True if the entire string was parsed (9.2), or all groups were
 /// parsed (10.3.5extrastuff).
 bool Driver::GetReleaseVersion(StringRef Str, unsigned &Major, unsigned &Minor,
                                unsigned &Micro, bool &HadExtra) {
   HadExtra = false;

clang/lib/Driver/ToolChain.cpp

 //===- ToolChain.cpp - Collections of tools for one platform --------------===//
 //
 // 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
 //
 //===----------------------------------------------------------------------===//
 
 #include "clang/Driver/ToolChain.h"
 #include "InputInfo.h"
 #include "ToolChains/Arch/ARM.h"
 #include "ToolChains/Clang.h"
 #include "ToolChains/InterfaceStubs.h"
+#include "ToolChains/Flang.h"
 #include "clang/Basic/ObjCRuntime.h"
 #include "clang/Basic/Sanitizers.h"
 #include "clang/Config/config.h"
 #include "clang/Driver/Action.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Job.h"
 #include "clang/Driver/Options.h"
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", "--driver-mode=flang"},
   };
 
   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];
     }

 }
 
 Tool *ToolChain::getClang() const {
   if (!Clang)
     Clang.reset(new tools::Clang(*this));
   return Clang.get();
 }
 
+Tool *ToolChain::getFlang() const {
+  if (!Flang)
+    Flang.reset(new tools::Flang(*this));
+  return Flang.get();
+}
+
 Tool *ToolChain::buildAssembler() const {
   return new tools::ClangAs(*this);
 }
 
 Tool *ToolChain::buildLinker() const {
   llvm_unreachable("Linking is not supported by this toolchain");
 }
 

 
 bool ToolChain::needsGCovInstrumentation(const llvm::opt::ArgList &Args) {
   return Args.hasFlag(options::OPT_fprofile_arcs, options::OPT_fno_profile_arcs,
                       false) ||
          Args.hasArg(options::OPT_coverage);
 }
 
 Tool *ToolChain::SelectTool(const JobAction &JA) const {
+  if (D.IsFlangMode() && getDriver().ShouldUseFlangCompiler(JA)) return getFlang();
   if (getDriver().ShouldUseClangCompiler(JA)) return getClang();
   Action::ActionClass AC = JA.getKind();
   if (AC == Action::AssembleJobClass && useIntegratedAs())
     return getClangAs();
   return getTool(AC);
 }
 
 std::string ToolChain::GetFilePath(const char *Name) const {
std::string ToolChain::GetLinkerPath() const {
 
   if (A)
     getDriver().Diag(diag::err_drv_invalid_linker_name) << A->getAsString(Args);
 
   return GetProgramPath(getDefaultLinker());
 }
 
 types::ID ToolChain::LookupTypeForExtension(StringRef Ext) const {
-  return types::lookupTypeForExtension(Ext);
+  types::ID id = types::lookupTypeForExtension(Ext);
+
+  // Flang always runs the preprocessor and has no notion of "preprocessed
+  // fortran". Here, TY_PP_Fortran is coerced to TY_Fortran to avoid treating
+  // them differently.
+  if (D.IsFlangMode() && id == types::TY_PP_Fortran)
+    id = types::TY_Fortran;
+
+  return id;
 }
 
 bool ToolChain::HasNativeLLVMSupport() const {
   return false;
 }
 
 bool ToolChain::isCrossCompiling() const {
   llvm::Triple HostTriple(LLVM_HOST_TRIPLE);

clang/lib/Driver/ToolChains/Flang.h

+//===--- Flang.h - Flang Tool and ToolChain Implementations ====-*- C++ -*-===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_FLANG_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_FLANG_H
+
+#include "clang/Driver/Tool.h"
+#include "clang/Driver/Action.h"
+#include "clang/Driver/Compilation.h"
+#include "clang/Driver/ToolChain.h"
+#include "llvm/Option/ArgList.h"
+#include "llvm/Support/Compiler.h"
+
+namespace clang {
+namespace driver {
+
+namespace tools {
+
+/// Flang compiler tool.
+class LLVM_LIBRARY_VISIBILITY Flang : public Tool {
+public:
+  Flang(const ToolChain &TC);
+  ~Flang() override;
+
+  bool hasGoodDiagnostics() const override { return true; }
+  bool hasIntegratedAssembler() const override { return true; }
+  bool hasIntegratedCPP() const override { return true; }
+  bool canEmitIR() const override { return true; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+                    const InputInfo &Output, const InputInfoList &Inputs,
+                    const llvm::opt::ArgList &TCArgs,
+                    const char *LinkingOutput) const override;
+};
+
+} // end namespace tools
+
+} // end namespace driver
+} // end namespace clang
+
+#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_FLANG_H

clang/lib/Driver/ToolChains/Flang.cpp

+//===-- Flang.cpp - Flang+LLVM ToolChain Implementations --------*- C++ -*-===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+
+#include "Flang.h"
+#include "CommonArgs.h"
+
+#include "clang/Driver/Options.h"
+
+#include <cassert>
+
+using namespace clang::driver;
+using namespace clang::driver::tools;
+using namespace clang;
+using namespace llvm::opt;
+
+void Flang::ConstructJob(Compilation &C, const JobAction &JA,
+                         const InputInfo &Output, const InputInfoList &Inputs,
+                         const ArgList &Args, const char *LinkingOutput) const {
+  const auto &TC = getToolChain();
+  const llvm::Triple &Triple = TC.getEffectiveTriple();
+  const std::string &TripleStr = Triple.getTriple();
+
+  ArgStringList CmdArgs;
+
+  CmdArgs.push_back("-fc1");
+
+  CmdArgs.push_back("-triple");
+  CmdArgs.push_back(Args.MakeArgString(TripleStr));
+
+  if (isa<PreprocessJobAction>(JA)) {
+    CmdArgs.push_back("-E");
+  } else if (isa<CompileJobAction>(JA) || isa<BackendJobAction>(JA)) {
+    if (JA.getType() == types::TY_Nothing) {
+      CmdArgs.push_back("-fsyntax-only");
+    } else if (JA.getType() == types::TY_AST) {
+      CmdArgs.push_back("-emit-ast");
+    } else if (JA.getType() == types::TY_LLVM_IR ||
+               JA.getType() == types::TY_LTO_IR) {
+      CmdArgs.push_back("-emit-llvm");
+    } else if (JA.getType() == types::TY_LLVM_BC ||
+               JA.getType() == types::TY_LTO_BC) {
+      CmdArgs.push_back("-emit-llvm-bc");
+    } else if (JA.getType() == types::TY_PP_Asm) {
+      CmdArgs.push_back("-S");
+    } else {
+      assert(false && "Unexpected output type!");
+    }
+  } else if (isa<AssembleJobAction>(JA)) {
+    CmdArgs.push_back("-emit-obj");
+  } else {
+    assert(false && "Unexpected action class for Flang tool.");
+  }
+
+  if (Output.isFilename()) {
+    CmdArgs.push_back("-o");
+    CmdArgs.push_back(Output.getFilename());
+  } else {
+    assert(Output.isNothing() && "Invalid output.");
+  }
+
+  const InputInfo &Input = Inputs[0];
+  assert(Input.isFilename() && "Invalid input.");
+  CmdArgs.push_back(Input.getFilename());
+
+  const auto& D = C.getDriver();
+  const char* Exec = Args.MakeArgString(D.GetProgramPath("flang", TC));
+  C.addCommand(std::make_unique<Command>(JA, *this, Exec, CmdArgs, Inputs));
+}
+
+Flang::Flang(const ToolChain &TC)
+    : Tool("flang", "flang frontend", TC, RF_Full) {}
+
+Flang::~Flang() {}

clang/lib/Driver/Types.cpp

bool types::isHIP(ID Id) {
 
   case TY_HIP:
   case TY_PP_HIP:
   case TY_HIP_DEVICE:
     return true;
   }
 }
 
+bool types::isFortran(ID Id) {
+  switch (Id) {
+  default:
+    return false;
+
+  case TY_Fortran: case TY_PP_Fortran:
+    return true;
+  }
+}
+
 bool types::isSrcFile(ID Id) {
   return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
 }
 
 types::ID types::lookupTypeForExtension(llvm::StringRef Ext) {
   return llvm::StringSwitch<types::ID>(Ext)
            .Case("c", TY_C)
            .Case("C", TY_CXX)

clang/test/Driver/flang/Inputs/one.f90

+! This file only exists to facilitate a driver -### test.

clang/test/Driver/flang/Inputs/other.c

+/* This file only exists to facilitate a driver -### test. */

clang/test/Driver/flang/Inputs/two.f90

+! This file only exists to facilitate a driver -### test.

clang/test/Driver/flang/flang.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" "-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" "-"
+
+! RUN: %clang --driver-mode=flang -### -emit-ast           %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-AST %s
+! CHECK-EMIT-AST-DAG: "-triple"
+! CHECK-EMIT-AST-DAG: "-emit-ast"
+! CHECK-EMIT-AST-DAG: "-o" "{{[^"]*}}.ast"
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only       %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-NOT: "-o"
+! CHECK-SYNTAX-ONLY-DAG: "-fsyntax-only"
+
+! RUN: %clang --driver-mode=flang -### -emit-llvm -S       %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-LLVM-IR %s
+! CHECK-EMIT-LLVM-IR-DAG: "-emit-llvm"
+! CHECK-EMIT-LLVM-IR-DAG: "-o" "{{[^"]*}}.ll"
+
+! RUN: %clang --driver-mode=flang -### -emit-llvm          %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-LLVM-BC %s
+! CHECK-EMIT-LLVM-BC-DAG: "-emit-llvm-bc"
+! CHECK-EMIT-LLVM-BC-DAG: "-o" "{{[^"]*}}.bc"
+
+! RUN: %clang --driver-mode=flang -### -S                  %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-S %s
+! CHECK-S-DAG: "-S"
+! CHECK-S-DAG: "-o" "{{[^"]*}}.s"
+
+! RUN: %clang --driver-mode=flang -###                     %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-OBJ %s
+! CHECK-EMIT-OBJ-DAG: "-emit-obj"
+! CHECK-EMIT-OBJ-DAG: "-o" "{{[^"]*}}.o"
+
+! Should end in the input file.
+! ALL: "{{.*}}flang.F90"{{$}}

clang/test/Driver/flang/flang.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" "-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" "-"
+
+! RUN: %clang --driver-mode=flang -### -emit-ast           %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-AST %s
+! CHECK-EMIT-AST-DAG: "-triple"
+! CHECK-EMIT-AST-DAG: "-emit-ast"
+! CHECK-EMIT-AST-DAG: "-o" "{{[^"]*}}.ast"
+
+! RUN: %clang --driver-mode=flang -### -fsyntax-only       %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-NOT: "-o"
+! CHECK-SYNTAX-ONLY-DAG: "-fsyntax-only"
+
+! RUN: %clang --driver-mode=flang -### -emit-llvm -S       %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-LLVM-IR %s
+! CHECK-EMIT-LLVM-IR-DAG: "-emit-llvm"
+! CHECK-EMIT-LLVM-IR-DAG: "-o" "{{[^"]*}}.ll"
+
+! RUN: %clang --driver-mode=flang -### -emit-llvm          %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-LLVM-BC %s
+! CHECK-EMIT-LLVM-BC-DAG: "-emit-llvm-bc"
+! CHECK-EMIT-LLVM-BC-DAG: "-o" "{{[^"]*}}.bc"
+
+! RUN: %clang --driver-mode=flang -### -S                  %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-S %s
+! CHECK-S-DAG: "-S"
+! CHECK-S-DAG: "-o" "{{[^"]*}}.s"
+
+! RUN: %clang --driver-mode=flang -###                     %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-OBJ %s
+! CHECK-EMIT-OBJ-DAG: "-emit-obj"
+! CHECK-EMIT-OBJ-DAG: "-o" "{{[^"]*}}.o"
+
+! Should end in the input file.
+! ALL: "{{.*}}flang.f90"{{$}}

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{{[^"/]*}}" "-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" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/one.f90"
+! CHECK-SYNTAX-ONLY-LABEL: "{{[^"]*}}flang" "-fc1"
+! CHECK-SYNTAX-ONLY: "{{[^"]*}}/Inputs/two.f90"

clang/test/Driver/fortran.f95

-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran when in
+! --driver-mode=clang. This is legacy behaviour - see also --driver-mode=flang.
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
-// CHECK-OBJECT: gcc
-// CHECK-OBJECT: "-c"
-// CHECK-OBJECT: "-x" "f95"
-// CHECK-OBJECT-NOT: cc1as
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
+! CHECK-OBJECT: gcc
+! CHECK-OBJECT: "-c"
+! CHECK-OBJECT: "-x" "f95"
+! CHECK-OBJECT-NOT: cc1as
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-ASM %s
-// CHECK-ASM: gcc
-// CHECK-ASM: "-S"
-// CHECK-ASM: "-x" "f95"
-// CHECK-ASM-NOT: cc1
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-ASM %s
+! CHECK-ASM: gcc
+! CHECK-ASM: "-S"
+! CHECK-ASM: "-x" "f95"
+! CHECK-ASM-NOT: cc1
 
-// RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
-// CHECK-WARN: gcc
-// CHECK-WARN-NOT: "-Wall"
-// CHECK-WARN: ld
-// CHECK-WARN-NOT: "-Wall"
+! RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
+! CHECK-WARN: gcc
+! CHECK-WARN-NOT: "-Wall"
+! CHECK-WARN: ld
+! CHECK-WARN-NOT: "-Wall"

clang/test/Driver/lit.local.cfg

-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.F90', '.f95',
                    '.cu', '.rs', '.cl', '.hip']
 config.substitutions = list(config.substitutions)
 config.substitutions.insert(0,
     ('%clang_cc1',
      """*** Do not use 'clang -cc1' in Driver tests. ***""") )
 
 # Remove harmful environmental variables for clang Driver tests.
 # Some might be useful for other tests so they are only removed here.