[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
Thu Aug 5 02:25:36 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:
> > > 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.
I got distracted and then forgot about it, sorry. So, I would like to merge this change as is. For extra documentation, please see https://reviews.llvm.org/D107543. We can continue the discussion there.


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