[Flang][driver] Behavior of unsupported gfortran flags when fed into flang

Hi everyone,

I’m starting this thead to discuss how flang should treat unsupported gfortran flags that get passed into its compiler driver. Right now, most unsupported flags will throw an error, which can be a problem if someone wants to run a build script written with gfortran in mind. Many gfortran flags, especially -W warning flags, would be better off emitting warnings instead of errors. Here are some proposals that have been brought up in discussions about this topic:

  • “Add another flag in Options.td to clearly document such options (something akin FlangOnlyOption), e.g. GFortranFlag. This way, adding a new “unsupported” option would boil down to decorating it with this new flag in Options.td.” - @banach-space
  • “Create something similar to e.g. LangOptions.def to define such unsupported options.” - @banach-space
  • “Do what clang does. If that is not properly defined we can do categories of ignored options for other compilers and emit warnings under a common flag (-Wgfortran-only, -Wifx-only, …)” - @jdoerfert

Please feel free to reply with any thoughts you have on this subject.

1 Like

There’s a document that lists a number of options that apply to Fortran semantics and describes what various compilers do with those flags. It might be a good place to record the outcome of this thread.

For what it’s worth, nvfortran recognizes a lot of gfortran options. Of those that aren’t implemented, there are broadly two actions. 1) Ignore if the option doesn’t affect the execution of the program being compiled or 2) complain. Many of those that would solicit a complaint are implemented.

Hi @EthanLuisMcDonough ,

Thanks for raising this important issue!

Out of the proposals that you are listing, each has its pros and cons:

  1. Updating Options.td might be the easiest approach, but means polluting that file with yet another flag (it’s already quite complex). Perhaps that’s not a problem at all?
  2. Adding something akin LangOptions.def in LLVM Flang would mean keeping all the required info within the Flang sub-project. I think that this would be neater than #1.
  3. Ideally, we should align with Clang, but for that we need to understand what Clang does (I raised https://discourse.llvm.org/t/what-does-clang-do-with-unsupported-gcc-flags to figure this out).

I don’t have a strong preference. For consistency with Clang, I would begin with #3. But it’s possible that Clang doesn’t have this problem because it was designed to be a drop-in replacement for GCC.

All in all, I would like for us to work towards three goals:

  • a consistent behavior for all unsupported flags (to make it easy for the user),
  • semi-automated implementation (e.g. through TableGen), instead of special cases in CompilerInvocaiton.cpp (to make this easy for developers),
  • clear documentation (this would include diagnostics and e.g. the doc linked by @sscalpone ).

@sscalpone , what do you mean by “complain” in nvfortran? A warning or an error? And what should LLVM Flang do?



@EthanLuisMcDonough , Clang has various flags in Options.td to decorate options like this, e.g. clang_ignored_f_Group. That’s probably the route that we should be taking here. We’d need to introduce a similar flag for Flang, but that should be fairly straightforward.