[PATCH] D125788: [flang][driver] Rename `flang-new` as `flang`

Mon May 30 02:39:41 PDT 2022

awarzynski added a comment.

Thank you all for your comments and apologies for going radio silent - I was away for a few days.

I've identified 2 threads emerging from your comments:

**1. flang vs flang-new**
@sscalpone, if I understand correctly, you are suggesting that any tool named `flang` in "LLVM Flang" should satisfy the following condition:

> 2. For all tests with unsupported features, the compiler must issues an error message and the message references the source-location of the unsupported feature

Indeed, `flang-new` does not satisfy this yet, but neither does `flang`, the bash wrapper script. `flang`, the bash script, calls `flang-new` to run parsing and semantic analysis. Basically, it's the same Fortran frontend as far as these initial phases are concerned. So, if "LLVM Flang" is missing diagnostics for e.g. unsupported language features, both `flang` and `flang-new` will fail to report these. I don't see how defaulting to `flang` (the bash script) instead of `flang-new` (the compiler driver) helps here.

Put differently, if the above condition is to be considered a requirement for any tool called `flang`, then the bash wrapper script should be renamed as it does not satisfy it.

**2. NAG test suite**
>From what I recall, we did discuss renaming `flang-new` as `flang` in the past and it was decided that we would wait for `flang-new` to be able to generate executables. I couldn't find this written down, so perhaps I'm misremembering? In any case, I don't follow why a test-suite conformance should determine what name is used for a compiler driver in "LLVM Flang". We should definitely work towards 100% pass rate, but to me that's orthogonal to how our tools are called. The level of Language support in "LLVM Flang"  should be communicated through the documentation (including release notes) instead of misleading tool names.

As for NAG test-suite specifically:

> My preference is to use the NAG test suite.   It is not freely available.

If we take this path, we will effectively be introducing yet another dependency on an external project in "LLVM Flang" (libpgmath <https://github.com/flang-compiler/flang/tree/master/runtime/libpgmath> being the first one). While most (perhaps all?) salaried "LLVM Flang" developers will have access to the NAG test suite, community volunteers will effectively have their ability to contribute severely limited. I'm against this, but also don't have a counter-proposal (I'm not aware of any freely accessible Fortran test suites that we could use here).

@peixin, you raised some really good points, thank you! I agree that even if it is decided that the NAG test suite is used as the benchmark for "LLVM Flang", it's still unclear how to deal with all these tricky corner cases (there will be platform dependencies too). As for the following one:

> 5. Are the rules also applied to Fortran 2003, 2008 and 2018 code, or only restricted to Fortran 95 code?

I think that we should limit ourselves to Fortran 95 for now - there's no code-gen support beyond that.

**NEXT STEPS**
Based on the above, how would you feel about the following:

1. Lets rename `flang` as `flang-to-external-fc` regardless of what's decided for `flang-new`. That would already be a huge step forward (and would reflect accurately what the bash wrapper script actually does).
2. As for the NAG test suite, I hope that we can agree not to use it as the condition for renaming `flang-new`. If it's decided that that's a valid requirement, then I agree with @kiranchandramohan that we should find a way to openly track the progress towards the required pass rate (and how that's defined).

Perhaps we could discuss more in the call today?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125788/new/

https://reviews.llvm.org/D125788