Can you please add fortran to the gcc targets ?

[janftacnik]

Hi Martin, great job on this. I just tried to compile everything on Ubuntu20 in WSL2 on Windows - works like charm. It is great Windows on Arm can be supporte din this way. I just have one request - could you please include gfortran as additional target for the compilation ? Windows on arm does not have native fortran yet - llvm has flang but is not supported for Windows. But gfortran is readily compiled for Windows mingw releases, so very probably would compile without problems. I am no so good to discover proper modification of your scripts in source distribution to add fortran to the terget compilers to build, but it should be possible 9may be even easy). Could you please suggest hot to add fortran to the whole thing ? I need that because i intent to make plottinh to work for Python on arm, fo rthat i need to compile Numpy but for that I need Blaas and Lapack but for that I need fortran on Windows on Arm. I tried to overcome it with ancient f2c convertor, but it cannot do everything.
Many thanks in advance for any help with this - or at least comment. My email is jan.ftacnik@oki.cz if you want to write to me directly.

[mstorsjo]

Windows on arm does not have native fortran yet - llvm has flang but is not supported for Windows.

FWIW, the main issue regarding the new upcoming flang in LLVM isn't that it doesn't support Windows, but that it's not yet functional. It's so far just various bits of a compiler.

But gfortran is readily compiled for Windows mingw releases, so very probably would compile without problems. I am no so good to discover proper modification of your scripts in source distribution to add fortran to the terget compilers to build, but it should be possible 9may be even easy).

No, it's not easy - in fact I believe it's not possible at all right now.

GCC, which gfortran is a part of, does not currently support generating code for windows/ARM. That's the whole root cause for using LLVM in the first place.

Now it would maybe be possible to compile a gfortran that runs ON arm/windows, that generates for code x86/windows. But there's no gfortran that generates code FOR arm/windows.

Note that there are other fortran compilers running on top of LLVM (some of them also named flang), which supposedly are functional. I don't know what state they are in and how possible it is to make them build to run on windows, and whether they even work with modern versions of LLVM. That's probably the most realistic alternative right now, for building fortran code for arm/windows - but I won't be able to spend time on looking into those at the moment.

[janftacnik]

Hi Martin, Thank you very much for answering. I was under impression someone was able to reconfigure gcc to use LLVM way of generating code (and it is not only redirection to clang). If that was possible, gfortran in my understanding uses very similar mechanism of generating code so for it that new generating of code using LLVM technology should be possible as well. Bu now I just checked with gcc –version that it is in fact clang in the background so You are right – It is probably not going to fly. Thanks anyway, I will look into f2c more closely. Do not really need fortran, just to compile fortran library to obj code on WOA. Best regards Jan From: Martin Storsjö <notifications@github.com> Sent: Sunday, November 1, 2020 9:00 PM To: mstorsjo/llvm-mingw <llvm-mingw@noreply.github.com> Cc: janftacnik <jan.ftacnik@oki.cz>; Author <author@noreply.github.com> Subject: Re: [mstorsjo/llvm-mingw] Can you please add fortran to the gcc targets ? (#163) Windows on arm does not have native fortran yet - llvm has flang but is not supported for Windows. FWIW, the main issue regarding the new upcoming flang in LLVM isn't that it doesn't support Windows, but that it's not yet functional. It's so far just various bits of a compiler. But gfortran is readily compiled for Windows mingw releases, so very probably would compile without problems. I am no so good to discover proper modification of your scripts in source distribution to add fortran to the terget compilers to build, but it should be possible 9may be even easy). No, it's not easy - in fact I believe it's not possible at all right now. GCC, which gfortran is a part of, does not currently support generating code for windows/ARM. That's the whole root cause for using LLVM in the first place. Now it would maybe be possible to compile a gfortran that runs ON arm/windows, that generates for code x86/windows. But there's no gfortran that generates code FOR arm/windows. Note that there are other fortran compilers running on top of LLVM (some of them also named flang), which supposedly are functional. I don't know what state they are in and how possible it is to make them build to run on windows, and whether they even work with modern versions of LLVM. That's probably the most realistic alternative right now, for building fortran code for arm/windows - but I won't be able to spend time on looking into those at the moment. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#163 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHP4I7RSDYGUIMFTE3XC4HLSNW44FANCNFSM4TGTRVRA> . <https://github.com/notifications/beacon/AHP4I7RIIGTT35GGPIGCNODSNW44FA5CNFSM4TGTRVRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFLWID3A.gif>

[mstorsjo]

I was under impression someone was able to reconfigure gcc to use LLVM way of generating code (and it is not only redirection to clang). If that was possible, gfortran in my understanding uses very similar mechanism of generating code so for it that new generating of code using LLVM technology should be possible as well.

It's not just to "reconfigure" it, but it's switching out the whole GCC backend to use LLVM instead; this is called gcc-llvm, or the project is called DragonEgg. It's essentially dead at this point (https://dragonegg.llvm.org shows the last version around LLVM 3.3, which is from 2013), although someone had updated it to newer versions (GCC 8 and LLVM 6) a few years ago, too.

Feel free to dig in if you feel like it, but it's not something that I'm going to spend time on trying to make work right now.

[mstorsjo]

Closing.

[Molier]

Hi! Just checking to see if there is any update on including Flang in this distribution? Having a real hard time finding fortran compiler for windows arm64 on the new surface pro11

Maybe a seperate issue, but not quite sure on what the difference is between this distr and the one marked WoA of the official llvm? https://github.com/llvm/llvm-project/releases/tag/llvmorg-18.1.8

[mstorsjo]

Hi! Just checking to see if there is any update on including Flang in this distribution? Having a real hard time finding fortran compiler for windows arm64 on the new surface pro11

I'm following the flang development at a distance... Including it in llvm-mingw would bring a whole lot of slowdown to most of our builds though, so I'm not very keen to include it until it really adds value.

I did look into including it a couple years ago, and while it does work in some settings, there were a few problems around how it works with cross compilation and Windows dylib builds.

llvm-mingw is primarily built as a cross compiler, with native compilation as an extra bonus, not the other way around. At the time, it wasn't quite possible to cross compile the flang runtimes, but I did hack in some preliminary support for it. There's work ongoing upstream quite recently to make this better set up as well; see https://discourse.llvm.org/t/rfc-use-llvm-enable-runtimes-for-flangs-runtime/80826.

For the dylibs; that's how llvm-mingw is built, where most of the shared code is in separate libLLVM-<version>.dll, libclang-cpp.dll etc, so most of the large code is in there, while the various executables (clang-<version>.exe, ld.lld.exe etc) are kept smaller. This only works for mingw targets at the moment, not for MSVC style builds (although there is work progressing on that as well). But enabling that, in a Windows build that includes MLIR+Flang, caused a bunch of problems - I didn't get to upstreaming the fixes I tried to do 2 years ago on that. Maybe that's better these days though.

Anyway, so unless those issues are fixed, a build that includes Flang can't use the shared libLLVM-<version>.dll, which quite significantly inflates the size of the toolchain.

In practice - I think the msys2 clang environments do include flang these days. It does seem like they do have it included in the clangarm64 environments in msys2 - see e.g. https://packages.msys2.org/packages/mingw-w64-clang-aarch64-flang. So installing msys2 should get you that compiler.

Maybe a seperate issue, but not quite sure on what the difference is between this distr and the one marked WoA of the official llvm? https://github.com/llvm/llvm-project/releases/tag/llvmorg-18.1.8

This distribution is built and set up for use with mingw headers/libraries - essentially a third party reimplemented Windows SDK. With the pros that it's freely redistributable (as opposed to MSVC and WinSDK), but with the cons that it does lag behind the official SDKs somewhat. The official releases upstream are built with and for use with MSVC and WinSDK.

[Molier]

Thank you for the quick and very thorough response!

I understand the issues. Thanks for explaining. I will look at the msys2 option and trying to compile with flang-new.exe from the llvm project.