[cfe-dev] RFC: Fortran optoins in Clang

Andrzej Warzynski via cfe-dev cfe-dev at lists.llvm.org
Fri Apr 9 09:44:52 PDT 2021


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] 
https://github.com/llvm/llvm-project/blob/985a42fdf8ae3117442ea129b684569fa6942a71/clang/lib/Driver/ToolChains/Flang.h
[2] `flang-new` is the new Flang driver, to be renamed as `flang`
[3] https://reviews.llvm.org/D95460
[4] https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html

On 09/04/2021 09:56, David Chisnall via cfe-dev wrote:
> On 08/04/2021 19:28, Andrzej Warzynski via cfe-dev wrote:
>> Hi Joerg,
>>
>> On 08/04/2021 17:44, Joerg Sonnenberger via cfe-dev wrote:
>>>
>>> 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" :) I should've made that 
>> clearer first time round.
> 
> 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
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


More information about the cfe-dev mailing list