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

Michael Kruse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 4 14:11:49 PDT 2021


Meinersbur 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
 
----------------
awarzynski wrote:
> Meinersbur wrote:
> > awarzynski wrote:
> > > 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.
> > > I'll update the documentation shortly.
> > 
> > Still working on this?
> Are you referring to `flang-new -fc1` here? I would like to keep it for now. This document is intended for developers, so I'm hoping that that's fine.
> 
> `flang` (the bash script) would need some extra logic for `flang -fc1` to work as expected. We could add it, but would it be worth it? I'd rather limit the script to the required minimum.
It just looked like you were planning to add more documentation (that you want me to review). I think that state as it is is fine.


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