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

EthanLuisMcDonough · February 7, 2023, 8:48pm

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.

sscalpone · February 7, 2023, 8:58pm

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.

github.com

llvm/llvm-project/blob/a2569a76e034d98b067805d3c577d46eb6766506/flang/docs/OptionComparison.md

<!--===- docs/OptionComparison.md 
  
   Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
   See https://llvm.org/LICENSE.txt for license information.
   SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
  
-->

# Compiler options comparison

This document catalogs the options processed by F18's peers/competitors.  Much of the document is taken up by a set of tables that list the options categorized into different topics.  Some of the table headings link to more information about the contents of the tables.  For example, the table on **Standards conformance** options links to [notes on Standards conformance](#standards).

**There's also important information in the ___[Appendix section](#appendix)___ near the end of the document on how this data was gathered and what ___is___ and ___is not___ included in this document.**  

Note that compilers may support language features without having an option for them.  Such cases are frequently, but not always noted in this document.

## Categorization of Options

<table>
  <tr>

This file has been truncated. show original

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.

banach-space · February 8, 2023, 8:12am

Hi @EthanLuisMcDonough ,

Thanks for raising this important issue!

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

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?
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.
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?

Thanks!

-Andrzej

banach-space · February 10, 2023, 8:05am

@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.

-Andrzej