search

conda-forge / conda-forge.github.io

The conda-forge website.
https://conda-forge.org
BSD 3-Clause "New" or "Revised" License
123 stars 272 forks source link

updates to gfortran again? #961

Closed beckermr closed 4 years ago

beckermr commented 4 years ago

It appears the scipy folks are discussing Fortran2003. I think we would have to migrate our fortran compilers to support this.

xref: https://github.com/scipy/scipy/issues/11421

isuruf commented 4 years ago

You mean gfortran 8 or above? We use gfortran 7.3.0 on linux and mac.

beckermr commented 4 years ago

Right. Fortran2003 is the language def and we would need at least 4.8. Some features are 4.9

isuruf commented 4 years ago

? 7.3 > 4.9

beckermr commented 4 years ago

Ach sorry yes. šŸ¤¦ā€ā™‚ 8 or above, maybe 9 on both linux and osx

beckermr commented 4 years ago

Here is the page. Looks like 8 would do the trick modulo bugs: https://gcc.gnu.org/wiki/Fortran2003Status

beckermr commented 4 years ago

scipy issue was closed. closing

h-vetinari commented 4 years ago

Actually, for full support of Fortran2003 (which will surely be necessary eventually), it seems that gcc >= 9.0 is required, see "Asynchronous input/output" in the status page.

Although, one can hope that with LLVM 11 later this year, we might have a x-platform fortran-compiler, depending how things develop with https://github.com/flang-compiler/f18/issues/876 (they were reasonably close to inclusion for LLVM 10 already; let's hope 11's the charm)

beckermr commented 4 years ago

Iā€™d be nervous about moving conda-forge to flang. Gfortran seems like a decent standard for now.

scopatz commented 4 years ago

flang on windows seems like a reasonable thing to do, though

h-vetinari commented 4 years ago

Sure, start with windows (finally scipy on CF!), and if the standards question comes up again, it can then still be weighed what's the better course of action.

jakirkham commented 4 years ago

FWIW people have tried this before ( https://github.com/conda-forge/scipy-feedstock/pull/78 ), but maybe the tooling has improved in the intervening time?

Thoughts @isuruf? šŸ™‚

h-vetinari commented 4 years ago

@jakirkham, @isuruf is more than just a little involved already. šŸ˜‰ Conda-forge's flang is tracking his personal flang-compiler/flang fork (predecessor to flang-compiler/f18), and he's not just actively involved, but actually going to lead the windows support effort for f18 in the context of them merging into LLVM.

jakirkham commented 4 years ago

I'm very aware of all of this @h-vetinari šŸ˜„

h-vetinari commented 4 years ago

Pardon me if that was all very obvious ('m sure the following will be too šŸ˜…).

I just misunderstood the question about the scipy-status, as it seems to me from his comments that scipy is clearly a target once that capability lands (originally it was hoped to be windows support in flang itself), but now everyone is putting their efforts into f18, and I would guess that not much will happen before that sees a release in LLVM. Although, to be fair, @mariusvniekerk did prepare a conda-forge scipy build with VS2017 + 2019 and Intel IFort.

PS. Maybe I should just let the man answer for himself... I'll stop now, sorry šŸ™ˆ

isuruf commented 4 years ago

flang development has stopped now and everyone is putting their efforts on f18. code generation in f18 landed 4 days ago and it still experimental and the runtime libraries are being written. It's a long way from being usable, but it'll get there. f18 is more receptive in getting windows patches merged, so when f18 is ready for other platforms, it'll probably be for windows too.