8000 MAINT,DOC: Classic Flang is not LLVM Flang · Issue #20240 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

MAINT,DOC: Classic Flang is not LLVM Flang #20240

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
HaoZeke opened this issue Oct 30, 2021 · 6 comments · Fixed by #24532
Closed

MAINT,DOC: Classic Flang is not LLVM Flang #20240

HaoZeke opened this issue Oct 30, 2021 · 6 comments · Fixed by #24532
Labels
03 - Maintenance component: numpy.distutils

Comments

@HaoZeke
Copy link
Member
HaoZeke commented Oct 30, 2021

Issue with current documentation:

3ff9227 introduced classic flang based on pgifortran into np.distutils.

Idea or request for content:

This is both unmaintained and confusing for users or to-be users of LLVM Flang. Removal would be for the best.
@HaoZeke
Copy link
Member Author
HaoZeke commented Oct 30, 2021 •
edited
Loading

Also while we're at it we might as well kill off (in separate commits) the other unmaintained Fortran compilers. However I'm less concerned about them, since there is no confusion about the other compilers.

@rgommers
Copy link
Member

I don't think this is a good first issue. We cannot just remove this. Right now Classic Flang still has more functionality I believe, in particular on Windows.

We may add LLVM-FLang as a new compiler and improve the docs.

@rgommers
Copy link
Member

Also, Classic Flang is not unmaintained. As of right now it's my best hope at a sane Fortran story for SciPy within the next year.

@HaoZeke
Copy link
Member Author
HaoZeke commented Oct 30, 2021

Ah, I think I made a bit of a knee jerk assumption based off their wiki which states that it should be considered to be superseded by F18 from early 2020.

However, the impetus was that at-least in the context of clang and flang optimizations as discussed in #19930, classic flang is incorrect.

Naming the fortran compilers is a bit of a nightmare, perhaps classic_flang and flang for LLVM would make more sense for the issue?

@rgommers
Copy link
Member

Naming the fortran compilers is a bit of a nightmare, perhaps classic_flang and flang for LLVM would make more sense for the issue?

I think I'd prefer a non-breaking change. Can we just add some code comments for now that flang means classic, and name the new one flang_llvm? Or maybe rename the other classic_flang but keep flang as an alias to that one (I think that is possible)? Once the new one actually is the better compiler, we can then switch flang. My impression is that that's a couple of years away still.

@HaoZeke
Copy link
Member Author
HaoZeke commented Oct 30, 2021 •
edited
Loading

Or maybe rename the other classic_flang but keep flang as an alias to that one (I think that is possible)?

This sounds like a plan. Will do. Thanks!

My impression is that that's a couple of years away still.

Yup, sounds about right. MLIR itself is still in a lot of flux too.

@HaoZeke HaoZeke mentioned this issue Aug 27, 2023
Merged
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
03 - Maintenance component: numpy.distutils
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

ENH: meson backend for f2py HaoZeke/numpy
2 participants
@rgommers @HaoZeke
0