Adjust README for upstreaming to llvm. #909

DavidTruby · 2020-01-07T11:15:40Z

No description provided.

kiranchandramohan

Three references are remaining.

F18 is written in C++17.
F18 uses components from LLVM.
Build F18

Also, have you checked that it works when invoked as flang?
I guess other references in documentation and source code can be removed later, right?

DavidTruby · 2020-01-07T11:37:40Z

Also, have you checked that it works when invoked as flang?

I don't think there's actually any instructions in the README about invoking the compiler. The binary will still be called f18 unless/until we change that in the CMake files.

kiranchandramohan · 2020-01-07T11:43:08Z

What is the executable that we want users to invoke flang? Ideally, it should be flang and not f18. Do you see any practical difficulties in changing the name of the exe?

Also note that @sscalpone created a wrapper script (tools/f18/flang.sh) which seems to be installed in build/tools/f18/bin/flang. So it is possible to invoke as flang.

kiranchandramohan · 2020-01-07T12:07:31Z

Note: The invocation is there in Overview.md in the documentation directory.
Overview.md:Command: f18 -E src.f90 dumps the cooked character stream
Overview.md: - f18 -fdebug-dump-parse-tree -fparse-only src.f90 dumps the parse tree
Overview.md: - f18 -funparse src.f90 converts the parse tree to normalized Fortran
Overview.md:Command: f18 -fdebug-dump-symbols -fparse-only src.f90 dumps the

I guess the invocation as f18/flang can be a separate PR if needed.

klausler

If you're going to abet the ambiguous use of the name flang, please add some adjectives or explanatory text so that newcomers aren't confused by the use of the same name for two completely distinct projects.

kiranchandramohan · 2020-01-13T22:54:43Z

@klausler @DavidTruby : Would something like the following be OK?
Flang is a ground-up implementation of a Fortran front end written in modern C++. It started off as the f18 project (https://github.com/flang-compiler/f18) at Nvidia with an aim to replace the old flang project (https://github.com/flang-compiler/flang) and address its various deficiencies. F18 was subsequently accepted as the Fortran frontend of LLVM and rechristened as Flang.

DavidTruby · 2020-01-22T16:21:29Z

@kiranchandramohan that text sounds fine to me, if @klausler is ok with it I can change the PR to include that.

The build instructions are for out of tree builds only, and the headings for those instructions should reflect that.

RichBarton-Arm · 2020-04-06T11:59:55Z

README.md

@@ -34,9 +34,7 @@ read the [style guide](documentation/C++style.md)
 and
 also review [how flang uses modern C++ features](documentation/C++17.md).

-## Building Flang


I think you still want a section on building flang here so would not remove it completely. The supported C++ compilers bit can stay in the "Building Flang" section (and Carol's patch will beef it up to add more info).

As Flang is not going to be built by default I think we should at least also include instructions on how to add Flang to a build and perhaps link to the LLVM build instructions or mention where to find those.

RichBarton-Arm · 2020-04-06T12:00:29Z

README.md

@@ -47,6 +45,8 @@ The code has been compiled and tested with
 clang version 7.0 and 8.0
 using either GNU's libstdc++ or LLVM's libc++.

+
+## Building Flang out of tree


I think I would put a little intro here saying what these instructions are for and why you might need to follow them. Probably also recommend building in-tree as far easier.

RichBarton-Arm · 2020-04-06T12:48:37Z

README.md

-for more information about Flang.
+Flang is a ground-up implementation of a Fortran front end written in modern
+C++. It started off as the f18 project (https://github.com/flang-compiler/f18)
+at Nvidia with an aim to replace the old flang project


I would say "previous flang project" :-)

No need to call out NVIDIA, but if you do, please also include the NNSA.

I've changed it to not call out anyone in particular, let me know if the new wording is ok!

RichBarton-Arm · 2020-04-06T12:49:17Z

README.md

-F18 uses components from LLVM.
+## Building Flang out of tree
+These instructions are for building Flang separately from LLVM; if you are
+building Flang alongside LLVM then follow the standard LLVM build instructions


I think you need this statement in the section above about Building Flang in-tree too.

I think in general if you're building in-tree you're not going to read this README and will just follow the normal build instructions? I can change this though, where would you put it?

README.md

RichBarton-Arm · 2020-04-06T15:59:28Z

Just had a thought while looking over the merging checklist. We should put a few words in here about where to submit issues. During previous emails about this I proposed we keep F18 repository github 'issues' open for this purpose. Can we add a line or two near the top of this README to that effect, including the URL, etc?

klausler · 2020-04-06T16:12:57Z

Just had a thought while looking over the merging checklist. We should put a few words in here about where to submit issues. During previous emails about this I proposed we keep F18 repository github 'issues' open for this purpose. Can we add a line or two near the top of this README to that effect, including the URL, etc?

The file should link to a bug tracker, but I don't think that the f18 github repository is the right place unless the fixes to the "issues" are pull requests to the same repository. Why can't the normal llvm bug tracking site be used for bugs being reported and fixed by the community?

RichBarton-Arm · 2020-04-06T17:02:06Z

I don’t think there is any reason why it can’t be used. My reasoning behind proposing F18 issues is * llvm are discussing a move from bugzilla to github issues<https://mail.google.com/mail/u/0/?zx=wwm6yj2noi7o#search/label%3Adevlist+github+issues%22/FMfcgxwDrtxxqzZcnsgKvSCfGpKfhsvf> so we would be aligning with the direction of travel in that regard (no ETA on that move though.) * It would also be 0 cost to set up. * I think the LLVM Bugzilla is not as nice to use as github issues, but that is personal preference. All weak reasons though – I don’t think there is a compelling reason to chose either approach. Do you have one?

klausler · 2020-04-06T17:30:55Z

I don’t think there is any reason why it can’t be used. My reasoning behind proposing F18 issues is * llvm are discussing a move from bugzilla to github issueshttps://mail.google.com/mail/u/0/?zx=wwm6yj2noi7o#search/label%3Adevlist+github+issues%22/FMfcgxwDrtxxqzZcnsgKvSCfGpKfhsvf so we would be aligning with the direction of travel in that regard (no ETA on that move though.) * It would also be 0 cost to set up. * I think the LLVM Bugzilla is not as nice to use as github issues, but that is personal preference. All weak reasons though – I don’t think there is a compelling reason to chose either approach. Do you have one?

Yes, and it's in my original comment. It would be weird and confusing to have bug reporting and tracking activity proceeding on a github repository while fixes and reviews are taking place elsewhere. LLVM has bug tracking and code review systems for LLVM. Use them.

DavidTruby · 2020-04-06T17:35:38Z

I think there's some merit in being ahead of the curve here; LLVM is planning on moving to github issues imminently, and it seems to me odd that we would set up and use bugzilla for 2 weeks and then switch back to github issues.
However, I wouldn't suggest using this repository for issues, but rather the llvm-project one. That is already open for github issues and is what MLIR uses I believe (MLIR never made the move to bugzilla for the same reason as I'm suggesting).
Since LLVM currently has two ways to submit issues and is planning on closing one down in the imminent future, I don't see the harm in suggesting that people submit issues on the other one (i.e. that they should submit issues against github.com/llvm/llvm-project).

kiranchandramohan · 2020-04-06T17:38:15Z

@DavidTruby Github issues in llvm-project is temporarily disabled until the switch from Bugzilla to github (soon?).
http://lists.llvm.org/pipermail/llvm-dev/2020-March/140129.html

DavidTruby · 2020-04-06T17:39:27Z

Oh ok, my mistake! In that case I agree that we should do what the rest of the project does and use Bugzilla until the rest of the project moves. I have no idea how to set that up on the bugzilla side though.

DavidTruby · 2020-04-06T17:50:43Z

I've sent an email to the bugzilla admins asking if we can be added on there and what the plan is for the github issues transition; I'll report back on that and update the readme as appropriate.

klausler · 2020-04-06T17:58:25Z

I've sent an email to the bugzilla admins asking if we can be added on there and what the plan is for the github issues transition; I'll report back on that and update the readme as appropriate.

Thank you.

RichBarton-Arm · 2020-04-06T18:06:26Z

I've sent an email to the bugzilla admins asking if we can be added on there and what the plan is for the github issues transition; I'll report back on that and update the readme as appropriate.

SGTM

DavidTruby · 2020-04-07T13:49:14Z

I've posted about the bugzilla to flang-dev as I think it is relevant to more people than will see this PR, you can read the mail here: http://lists.llvm.org/pipermail/flang-dev/2020-April/000269.html

This changes the references and build instructions for Flang so that they are correct now that F18 has been rechristened Flang and merged with LLVM. Reviewed at: flang-compiler/f18#909

DavidTruby · 2020-04-24T14:29:35Z

Resolved during upstream merge.

This changes the references and build instructions for Flang so that they are correct now that F18 has been rechristened Flang and merged with LLVM. Reviewed at: flang-compiler/f18#909

DavidTruby requested review from kiranchandramohan and sscalpone January 7, 2020 11:15

kiranchandramohan requested changes Jan 7, 2020

View reviewed changes

kiranchandramohan approved these changes Jan 7, 2020

View reviewed changes

klausler reviewed Jan 7, 2020

View reviewed changes

DavidTruby added this to In progress in LLVMify F18 - before merging Feb 4, 2020

DavidTruby force-pushed the readme branch from e565671 to 1064d10 Compare March 9, 2020 13:43

DavidTruby requested a review from sscalpone March 9, 2020 13:45

klausler approved these changes Mar 11, 2020

View reviewed changes

RichBarton-Arm moved this from In progress to Ready to merge in LLVMify F18 - before merging Mar 12, 2020

h-vetinari mentioned this pull request Mar 20, 2020

Submission into the llvm-project #876

Open

23 tasks

RichBarton-Arm moved this from Ready to merge to In progress in LLVMify F18 - before merging Apr 1, 2020

DavidTruby added 2 commits April 2, 2020 13:19

Adjust README for upstreaming to llvm.

64f097c

Changed further F18 references to Flang.

0372b99

DavidTruby force-pushed the readme branch from 6e6d505 to a1c552e Compare April 2, 2020 12:20

Added wording explaining relationship to old flang.

5d6d22d

DavidTruby force-pushed the readme branch from a1c552e to 5d6d22d Compare April 2, 2020 13:58

Clarify build instructions in README

1c6aec6

The build instructions are for out of tree builds only, and the headings for those instructions should reflect that.

RichBarton-Arm reviewed Apr 6, 2020

View reviewed changes

Clarify out-of-tree instructions further.

61ebcca

RichBarton-Arm reviewed Apr 6, 2020

View reviewed changes

sscalpone reviewed Apr 6, 2020

View reviewed changes

README.md Outdated Show resolved Hide resolved

sscalpone reviewed Apr 6, 2020

View reviewed changes

README.md Outdated Show resolved Hide resolved

Reworded text about the previous flang project.

fbe371d

RichBarton-Arm moved this from In progress to In review in LLVMify F18 - before merging Apr 6, 2020

RichBarton-Arm moved this from In review to Ready to merge in LLVMify F18 - before merging Apr 9, 2020

RichBarton-Arm moved this from Ready to merge to Done in LLVMify F18 - before merging Apr 9, 2020

DavidTruby closed this Apr 24, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adjust README for upstreaming to llvm. #909

Adjust README for upstreaming to llvm. #909

DavidTruby commented Jan 7, 2020

kiranchandramohan left a comment

DavidTruby commented Jan 7, 2020

kiranchandramohan commented Jan 7, 2020 •

edited

kiranchandramohan commented Jan 7, 2020

klausler left a comment

kiranchandramohan commented Jan 13, 2020

DavidTruby commented Jan 22, 2020

RichBarton-Arm Apr 6, 2020

RichBarton-Arm Apr 6, 2020

RichBarton-Arm Apr 6, 2020

sscalpone Apr 6, 2020

DavidTruby Apr 6, 2020

RichBarton-Arm Apr 6, 2020

DavidTruby Apr 6, 2020

RichBarton-Arm commented Apr 6, 2020

klausler commented Apr 6, 2020

RichBarton-Arm commented Apr 6, 2020 via email •

edited

klausler commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

kiranchandramohan commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

klausler commented Apr 6, 2020

RichBarton-Arm commented Apr 6, 2020

DavidTruby commented Apr 7, 2020

DavidTruby commented Apr 24, 2020

Adjust README for upstreaming to llvm. #909

Adjust README for upstreaming to llvm. #909

Conversation

DavidTruby commented Jan 7, 2020

kiranchandramohan left a comment

Choose a reason for hiding this comment

Build F18

DavidTruby commented Jan 7, 2020

kiranchandramohan commented Jan 7, 2020 • edited

kiranchandramohan commented Jan 7, 2020

klausler left a comment

Choose a reason for hiding this comment

kiranchandramohan commented Jan 13, 2020

DavidTruby commented Jan 22, 2020

RichBarton-Arm Apr 6, 2020

Choose a reason for hiding this comment

RichBarton-Arm Apr 6, 2020

Choose a reason for hiding this comment

RichBarton-Arm Apr 6, 2020

Choose a reason for hiding this comment

sscalpone Apr 6, 2020

Choose a reason for hiding this comment

DavidTruby Apr 6, 2020

Choose a reason for hiding this comment

RichBarton-Arm Apr 6, 2020

Choose a reason for hiding this comment

DavidTruby Apr 6, 2020

Choose a reason for hiding this comment

RichBarton-Arm commented Apr 6, 2020

klausler commented Apr 6, 2020

RichBarton-Arm commented Apr 6, 2020 via email • edited

klausler commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

kiranchandramohan commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

DavidTruby commented Apr 6, 2020

klausler commented Apr 6, 2020

RichBarton-Arm commented Apr 6, 2020

DavidTruby commented Apr 7, 2020

DavidTruby commented Apr 24, 2020

kiranchandramohan commented Jan 7, 2020 •

edited

RichBarton-Arm commented Apr 6, 2020 via email •

edited