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

Tue May 24 18:36:03 PDT 2022

peixin added a comment.

In D125788#3535199 <https://reviews.llvm.org/D125788#3535199>, @sscalpone wrote:

> My proposal is:
>
> If the compiler compiles it, it ought to run.
> If the compiler can't compile it, it ought to clearly say why.
>
> 1. All tests of legal Fortran that compile & link must also execute correctly (which excludes tests that expect to catch a problem at runtime)
> 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
>
> My preference is to use the NAG test suite.   It is not freely available.

I tested a lot of test cases (mostly Fortran 95 code) and have several detailed questions about the reasonable quality bar.

1. Should some incorrect execution results be changed into one TODO if there is no plan to support it soon? One example is derived type array in forall (https://github.com/flang-compiler/f18-llvm-project/issues/1598).

2. What if the case fails in lowering with a "fatal internal error", but the real reason is the incorrect semantic analysis? Should it either be supported, or be turned from the "fatal internal error" into TODO?

3. What about the edge cases? For those with incorrect execution results, turn them into TODO? One example is D125632 <https://reviews.llvm.org/D125632>.

4. What about some dangerous usage? Usually, gfortran can report a lot of warnings for the dangerous scenarios such as string length mismatch, external procedure type kind mismatch, the test case in D125891 <https://reviews.llvm.org/D125891>, etc. Maybe this is not in priority.

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

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125788