[flang-dev] RFC: new Flang driver options

[Andrzej Warzynski via flang-dev]

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

On 17/11/2020 15:33, Andrzej Warzynski via flang-dev wrote:
> 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:
> 
> https://docs.google.com/spreadsheets/d/1JRe39lP_KhtkYxFEIvwrCFlE5v1Ofa_krOHI-XXXWPY/edit?usp=sharing 
> 
> 
> 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
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev