RFC: Fortran optoins in Clang

Hello,

What should Clang do when using options that are reserved for Flang (i.e. that only make sense for Fortran input)? Should this be a warning or an error?

Currently Clang will issue an error. This is problematic to some users and was brought up in a post-commit review for ⚙ D95460 [flang][driver] Add forced form flags and -ffixed-line-length. GCC is more forgiving in such scenarios:

gcc -c  -ffree-form  file.c
cc1: warning: command line option ‘-ffree-form’ is valid for Fortran but not for C

I propose that we introduce similar logic in Clang. A patch implementing this is available here: ⚙ D99353 [driver] Make `clang` warn rather then error on `flang` options.

This is a user-facing change and I want to make sure that this works for everyone. Your feedback is much appreciated!

-Andrzej

I think warning and codegen options should be claimed only if the
corresponding language frontend is actually active. I think we have some
existing cases for that with Objective-C and C++ interaction. So just
extend that?

Joerg

Hi Joerg,

I think warning and codegen options should be claimed only if the
corresponding language frontend is actually active. I think we have some
existing cases for that with Objective-C and C++ interaction. So just
extend that?

What do you mean by "active"?

Unlike Objective-C and C++, Flang's frontend is implemented in a different sub-project. Also, AFAIK, there's no concept of active/inactive frontend in the compiler driver.

Perhaps you meant "Clang, the frontend and the frontend driver"? I'm referring to "Clang, the compiler driver" :slight_smile: I should've made that clearer first time round.

-Andrzej

Hi Joerg,

>
> I think warning and codegen options should be claimed only if the
> corresponding language frontend is actually active. I think we have some
> existing cases for that with Objective-C and C++ interaction. So just
> extend that?

What do you mean by "active"?

If there is a source file using that frontend, it is active. Either due
to implicit derivation from the extension or explicit -x option.

Unlike Objective-C and C++, Flang's frontend is implemented in a different
sub-project. Also, AFAIK, there's no concept of active/inactive frontend in
the compiler driver.

Not that relevant, since the former two are using a different (internal)
progress too. My memory is a bit fuzzy, but I'm moderately sure we have
such options already.

Perhaps you meant "Clang, the frontend and the frontend driver"? I'm
referring to "Clang, the compiler driver" :slight_smile: I should've made that clearer
first time round.

I'm talking about clang the driver, not the -cc1 or -cc1as backend
process.

Joerg

The Clang driver claims arguments in the various things in the ToolChain files. If I remember correctly, most of this is done automatically by marking options in the .td files as being automatically forwarded to certain tools (e.g. clang -cc1 or ld), but you will get an error for anything that is not claimed.

I have not looked at the Flang code, but I presume the clang driver has a FlangTool class for collecting and forwarding arguments from the driver to the flang front end. I'd expect this to be the place to claim all flang-only arguments, anywhere else they should just show up as unclaimed.

David

David, Joerg,

Thank you for your replies and clarifications! In general there are few separate scenarios that a driver based on clangDriver should to cater for. It might be helpful to list them here:

*SCENARIO-ONE*
C/C++/Obj-C/Obj-C++ files is passed to clang:

clang file.c

This should not affect Flang at all.

*SCENARIO-TWO*
Fortran file is passed to clang:

clang file.f

David, as you pointed out, in this case all Fortran flags should be forwarded to Flang via a dedicated specialisation of clang::Driver::tool. This is already available [1].

*SCENARIO-THREE*
Fortran file is passed to Flang [2]:

flang-new file.f

This should not affect Clang at all [2]. Again, everything is claimed by Flang's specialisation of clang::Driver::tool [1].

*SCENARIO-FOUR*
C/C++/Obj-C/Obj-C++ file is passed to Flang [2]:

flang-new file.c

Currently the new Flang driver rejects non-Fortran files (contributions in this area are very welcome!).

To summarise, for C/C++/Obj-C/Obj-C++ files, all options should be claimed by Clang's frontend driver. For Fortran input files, all options should be claimed by Flang's frontend driver. This covers all scenarios listed above. I would like to skip mixed source projects for now (e.g. C + Fortran).

In this RFC I'm only discussing *SCENARIO-ONE*. More specifically, what should happen when a Fortran flag [4] is used here:

clang -ffree-form file.c

IMO, it makes no sense for `clang` to claim it. The Flang "tool" is not required here, so it can't claim it either. Should `clang`:
* issue an error (current behaviour, inconsistent with GCC, brought up in [3] as problematic to some users), or
* issue a warning (implemented in [3], consistent with GCC)

What are you thoughts?

-Andrzej

[1] llvm-project/Flang.h at 985a42fdf8ae3117442ea129b684569fa6942a71 · llvm/llvm-project · GitHub
[2] `flang-new` is the new Flang driver, to be renamed as `flang`
[3] ⚙ D95460 [flang][driver] Add forced form flags and -ffixed-line-length
[4] Fortran Dialect Options (The GNU Fortran Compiler)