[PATCH] D105811: [flang][driver] Delete `f18` (i.e. the old Flang driver)

Andrzej Warzynski via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 30 07:13:57 PDT 2021


awarzynski added inline comments.


================
Comment at: flang/docs/Overview.md:36
 
-**Command:** `f18 -E src.f90` dumps the cooked character stream
+**Command:** `flang-new -fc1 -E src.f90` dumps the cooked character stream
 
----------------
Meinersbur wrote:
> awarzynski wrote:
> > Meinersbur wrote:
> > > Shouldn't the docs refer to `flang` instead of `flang-new`? AFAIU `flang` will eventually be replaced by a proper executable that does not call gfortran anymore and `flang-new` go away.
> > I think that this document should only refer to the frontend driver rather than the compiler driver. In our case, that's either `f18` (compiler driver + frontend driver) or `flang-new -fc1` (new frontend driver).  In fact, some options referred here are only available in `flang-new -fc1` (i..e. these options are frontend-specific).
> > 
> > Currently, `flang` is a yet another tool - it's neither a compiler nor a frontend driver, so I don't want to use it here. IMO, we should first rename it as e.g. `flang-to-gfortran` (or something similar) to clarify what it actually does. Then, we can claim `flang` for the actual driver and update all the docs accordingly.
> Indeed this document is in the "Design Document" section of https://flang.llvm.org/docs/. However, could you still add a note that this is developer, __not__ end-user documentation. Seems that we don't have and-user documentation yet.
> 
> If we follow the analogy of clang, then the eventual goal is that `flang` would be the primary user command __and__ gfortran-compatible wrapper. `flang -fc1` An implementation detail, but still accessible with `-Xflang`. Where does `flang-new` fit in here?
I'll update the documentation shortly.

As for `flang` vs `flang-new` vs `flang -fc1`, the plan is to first rename `flang` as e.g. `flang-to-gfortran`. We still need to decide __when__ to do this. Once `flang` is renamed, `flang-new` can be renamed as `flang` and `flang-new -fc1` becomes `flang -fc1` (we don't really have `flang -fc1` right now).

`flang-new` is a rather confusing and an enigmatic name. One big benefit of renaming `flang` (the bash script) sooner rather than later is that `flang-new` would become `flang` and the weird name would be gone.


================
Comment at: flang/tools/f18/flang:239
 
   local -r ext_fc="${F18_FC:-gfortran}"
   local -r wd=$(cd "$(dirname "$0")/.." && pwd)
----------------
Meinersbur wrote:
> awarzynski wrote:
> > Meinersbur wrote:
> > > Is `F18_FC` still defined?
> > Only here: https://github.com/llvm/llvm-project/blob/main/flang/docs/ReleaseNotes.md#using-flang. I think that we do want to support compilers other than `gfortran` (so we need to keep this variable).
> Maybe `flang-new` should have used `FLANG_FC` instead, but we can keep it as a (temporary?) compatibility option.
Good point, updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105811



More information about the llvm-commits mailing list