RFC: new Flang driver options

Subprojects Flang
#1

Hi All,

We would like to start adding the remaining features in the new Flang driver and would appreciate your feedback on the list of proposed compiler options.

Flang - llvm-project/flang
"flang" - current Flang compiler and frontend driver
"flang-new" - new Flang compiler driver
"flang-new -fc1" - new Flang frontend driver

The list of proposed options is available in Google Docs:

If you are unable to read Google Docs, please suggest a different format and I will port it for you. The "unsupported options" sheet lists options from "flang" that won't be supported in "flang-new".

Below you will find our rationale.

# *SPELLINGS*
The current driver implements both "gfortran " and "Classic Flang" spellings for options. For the sake of simplicity (it's easier to focus on 1 set) and consistency with libclangDriver (which the new driver is implemented in terms of), we propose that for now we focus on "gfortran" style spellings.

# *COMPILER VS FRONTED DRIVER OPTIONS*
Options available in the frontend driver ("flang-new -fc1") won't be automatically available in the compile driver ("flang-new"). We propose the following rule of thumb:
   * if an option is available in "gfortran" then it should also be available in "flang-new"
For all other options one either has to use the frontend driver or the `-Xflang` compiler driver flag (equivalent to `-Xclang`).

# *EXTERNAL TOOL*
"flang" calls a tool defined with the "F18_FC" environment variable to perform the actual compilation. In the new driver we want to focus on typical compiler driver tasks, the interface and the user experience. Also, with the ongoing efforts to bring the code-generation capabilities to llvm-project/flang, we assume that this functionality won't be needed in "flang-new". In other words, we suggest that this is not supported.

# *FUTURE CHANGES*
The proposed set of options is _not_ set in stone and can be refined in future. In particular, "Classic Flang" spellings can be added in a similar manner as MSVC spelling were added to Clang (e.g. "flang-new-cf" could represent the new driver in "Classic Flang" compatibility mode).

# *FINER DETAILS*
* In some cases we suggest a completely new spelling (e.g. "-fdebug-unparse" instead of "-unparse") - please see the "Notes" column
* "flang-new" already supports a few options that are not supported by "flang" (e.g. "-###") - these are also listed
* "-fget-definition" seems like a rather complex and obscure proof-of-concept option and we suggest that it's skipped for now

# *QUESTIONS*
* Are the descriptions accurate? We might have missed or misinterpreted something.
* What are `-ed` and `-fdebug-module-writer` for? We couldn't find any documentation.

Is this sufficient for you to adopt the new Flang driver once these options are available? Is there anything that we missed? Does this sound sensible to you?

Thank you for reading,
-Andrzej

#2

I've just updated the spreadsheet based on the feedback on Slack (flang-compiler.slack.com):

* Removed `-cpp`/`-nocpp` (as per http://flang.llvm.org/docs/Parsing.html, the preprocessor is always run)
* Added `-futf-8` and `-flatin`
* Replaced `std=<standard>` with `-std=f2018` ("flang' spelling: "-Mstandard")
* Added `-I` (it should be there from the start)

Please comment either here or on Slack.

-Andrzej

#3

I have a few more comments:

I think -module or -module-directory is a better name than -J for that option. Of course -J can also be supported as an alternative for compatibility.

Also, gfortran's -J also adds the directory to those to search for .mod files while flang's -module only set the output directory. I think gfortran's behavior makes more sense.

I don't think -module-suffix is useful in the new driver. Once flang can generate code the testing approach of using another compiler to generate code will be obsolete. Until then, the f18.cpp driver can be used for those tests.

-std=f2018 doesn't mean the same thing to me as -Mstandard. The former implies you can choose which Fortran standard to enforce while the latter is about how strictly it is enforced. I don't think -std should be used until there are at least two versions of the standard that can be enforced.

Tim

    External email: Use caution opening links or attachments

    I've just updated the spreadsheet based on the feedback on Slack
    (flang-compiler.slack.com):

    * Removed `-cpp`/`-nocpp` (as per
    http://flang.llvm.org/docs/Parsing.html, the preprocessor is always run)
    * Added `-futf-8` and `-flatin`
    * Replaced `std=<standard>` with `-std=f2018` ("flang' spelling:
    "-Mstandard")
    * Added `-I` (it should be there from the start)

    Please comment either here or on Slack.

    -Andrzej

#4

My comments inline. Spreadsheet updated accordingly.

I think -module or -module-directory is a better name than -J for that option. Of course -J can also be supported as an alternative for compatibility.

Also, gfortran's -J also adds the directory to those to search for .mod files while flang's -module only set the output directory. I think gfortran's behavior makes more sense.

Sounds like we want two spellings:
* -J
* -module-dir (just shorter version of what you suggested)

The behaviour will match gfortran.

I don't think -module-suffix is useful in the new driver. Once flang can generate code the testing approach of using another compiler to generate code will be obsolete. Until then, the f18.cpp driver can be used for those tests.

I agree. Removed.

-std=f2018 doesn't mean the same thing to me as -Mstandard. The former implies you can choose which Fortran standard to enforce while the latter is about how strictly it is enforced. I don't think -std should be used until there are at least two versions of the standard that can be enforced.

We could have `-std=f2018` and reject e.g. `-std=f90` (to make sure that users get sane behaviour). So there's no need for other versions to be fully supported. Also, we could have `-std=flang` (similar to `-std=gnu`). That's already two versions.

To me `-Mstandard` is a bit confusing - which standard does it refer to? Perhaps `-disable-extensions` would be more appropriate here?

-Andrzej