[flang-dev] RFC: new Flang driver options
Andrzej Warzynski via flang-dev
flang-dev at lists.llvm.org
Mon Nov 30 08:00:03 PST 2020
My comments inline. Spreadsheet updated accordingly.
On 25/11/2020 20:09, Timothy Keith wrote:
> 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
> Tim
>
> On 11/21/20, 11:42 AM, "flang-dev on behalf of Andrzej Warzynski via flang-dev" <flang-dev-bounces at lists.llvm.org on behalf of flang-dev at lists.llvm.org> wrote:
>
> 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
>
> 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
> _______________________________________________
> flang-dev mailing list
> flang-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/flang-dev
>
More information about the flang-dev
mailing list