Fortran support with FLANG

[htg200]

Hi,

There has been a recent effort to compile Fortran with LLVM target (https://github.com/flang-compiler/flang). Can we expect Emscripten also support Fortran in the future? Thank you.

Best Regards H.

[juj]

I don't know of anyone currently working on this, but if someone contributes support for it, it would be very welcome. Perhaps you might have interested in picking up developing it?

I must admit my experience of Fortran is restricted to one university level course 10 years ago, which I initially dropped out from, and later was given a special exempt to redo in C, so there might not be much help from us on this one 😅 (unless @kripken is a secret Fortran wiz?)

[htg20]

You must have really loved Fortran by then ;-). I am very experienced in Fortran and I would be happy to contribute; however, it depends how much work it needs. This year I am involved in too many projects. But I will start to play with it. I will ask question when something comes up.

[htg20]

Hi again, I have compiled the Flang compiler (64 bit) and it can create bitcode. Flang uses a bit different Clang version than the original. So, what will be the next step? I am not sure how to start. What are the simplest commands to convert bitcode to JS using emcc?

[kripken]

A different clang might cause issues. But if the bitcode is compatible, just run emcc bitcode.bc - it works fine with bitcode as its input (can even be multiple bitcode files, or a mix of bitcode and source files, etc.).

[htg20]

Let's solve the first problem:

The Flang behaviour is very similar to Clang. So, to test, I simply make a C++ Helloworld.cpp and compile it to bitcode. When I try to do "emcc Helloworld.bc", it gives the below errors. My Clang version is also below. If the error is only because of 64 or 32 bit libraries, what commands should I use to compile so it works with Emscripten? As far as I have read, Emscripten uses a slightly modified Clang.

######### clang version 4.0.1 (https://github.com/flang-compiler/clang.git e735df1a7287cca476b0b313f7d01a096023c8bd) (https://github.com/llvm-mirror/llvm.git c8fccc53ed66d505898f8850bcc690c977a7c9a7) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /data/opt/flang/clang_40/bin Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 ############

warning: Linking two modules of different data layouts: '/home/user/.emscripten_cache/asmjs/dlmalloc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'hello.bc' is 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

warning: Linking two modules of different target triples: /home/user/.emscripten_cache/asmjs/dlmalloc.bc' is 'asmjs-unknown-emscripten' whereas 'hello.bc' is 'x86_64-unknown-linux-gnu'

warning: Linking two modules of different data layouts: '/home/user/.emscripten_cache/asmjs/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'hello.bc' is 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

warning: Linking two modules of different target triples: /home/talebi/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas 'hello.bc' is 'x86_64-unknown-linux-gnu'

warning: incorrect target triple 'x86_64-unknown-linux-gnu' (did you use emcc/em++ on all source files and not clang directly?) warning: unresolved symbol: _ZNSt8ios_base4InitD1Ev warning: unresolved symbol: _ZNSt8ios_base4InitC1Ev warning: unresolved symbol: _ZNSolsEPFRSoS_E warning: unresolved symbol: ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6 warning: unresolved symbol: _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc warning: unresolved symbol: _ZSt4cout

[dschuff]

The CPU target needs to match; In your case you compiled one module targeting x86_64-unkown-linux-gnu whereas Emscripten by default uses asmjs-unknown-emscripten. Support for that target is one of the modifications of Emscripten's clang. If you do want to use a frontend based on an unmodified upstream LLVM, you can use the wasm32-unknown-unknown-elf target, which is supported in emscripten as well (in emscripten codebase this is known as the "vanilla" or "upstream" backend; see https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend). It only supports wasm and not asm.js, but it's the one that will be supported going forward. In clang you use the --target flag to set it, e.g. --target=wasm32 or --target=wasm32-unknown-unknown-elf (the difference doesn't matter if you are just generating bitcode).

On Thu, Sep 14, 2017 at 6:52 AM htg20 [email protected] wrote:

Let's solve the first problem:

The Flang behaviour is very similar to Clang. So, to test, I simply make a C++ Helloworld.cpp and compile it to bitcode. When I try to do "emcc Helloworld.bc", it gives the below errors. My Clang version is also below. If the error is only because of 64 or 32 bit libraries, what commands should I use to compile so it works with Emscripten? As far as I have read, Emscripten uses a slightly modified Clang.

clang version 4.0.1 (https://github.com/flang-compiler/clang.git e735df1a7287cca476b0b313f7d01a096023c8bd) ( https://github.com/llvm-mirror/llvm.git c8fccc53ed66d505898f8850bcc690c977a7c9a7) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /data/opt/flang/clang_40/bin Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 https://github.com/m64 Candidate multilib: 32;@m32 https://github.com/m32 Candidate multilib: x32;@MX32 https://github.com/mx32 Selected multilib: .;@m64 https://github.com/m64

warning: Linking two modules of different data layouts: '/home/user/.emscripten_cache/asmjs/dlmalloc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'hello.bc' is 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

warning: Linking two modules of different target triples: /home/user/.emscripten_cache/asmjs/dlmalloc.bc' is 'asmjs-unknown-emscripten' whereas 'hello.bc' is 'x86_64-unknown-linux-gnu'

warning: Linking two modules of different data layouts: '/home/user/.emscripten_cache/asmjs/libc.bc' is 'e-p:32:32-i64:64-v128:32:128-n32-S128' whereas 'hello.bc' is 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'

warning: Linking two modules of different target triples: /home/talebi/.emscripten_cache/asmjs/libc.bc' is 'asmjs-unknown-emscripten' whereas 'hello.bc' is 'x86_64-unknown-linux-gnu'

warning: incorrect target triple 'x86_64-unknown-linux-gnu' (did you use emcc/em++ on all source files and not clang directly?) warning: unresolved symbol: _ZNSt8ios_base4InitD1Ev warning: unresolved symbol: _ZNSt8ios_base4InitC1Ev warning: unresolved symbol: _ZNSolsEPFRSoS_E warning: unresolved symbol: ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6 warning: unresolved symbol: _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc warning: unresolved symbol: _ZSt4cout

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kripken/emscripten/issues/5553#issuecomment-329488348, or mute the thread https://github.com/notifications/unsubscribe-auth/ABEiKM9rikxhluOwk8UTuX_M6xr5DUrKks5siS-FgaJpZM4PLoj0 .

[htg20]

Well, I could not basically compile Flang with Webassembly target. I think I should follow up with Flang developer.

[jakirkham]

There was some work done to build it here. So that might be worth giving a try.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

[jakirkham]

I guess it’s stale, but should it actually be closed? This is still valuable to people.

[sbc100]

Lets leave this one open then.

[jakirkham]

Thanks 🙏

[StarGate01]

I managed to build a toolchain based on gfortran, dragonegg and emscripten. Then I compiled libgfortran to webassembly in order to provide a runtime. This enabled me to actually compile and run most of LAPACK and BLAS. It works: https://github.com/StarGate01/Full-Stack-Fortran

[jakirkham]

FWIW Flang entered LLVM mainline ( https://github.com/llvm/llvm-project/tree/master/flang/ ). Guessing it will be available in LLVM 11.0.

[JoyMonteiro]

Hello, I saw some discussions on the pyodide project and was wondering if new versions of emscripten can work with fortran90 code (thanks to the flang frontend).

If yes, I would appreciate any pointers as to how to go about this. If no, when would this be possible?

TIA, Joy

[StarGate01]

As of the release notes of LLVM 11.0, The flang frontend is at this point in time only able to parse and unparse Fortran code into a canonical form. Actual code generation or IR generation does not seem to be supported yet, instead an external compiler can be invoked.

[JoyMonteiro]

Thanks! looks like we will have to wait, or use your solution until that happens.

[StarGate01]

I am confident LLVM will eventually properly support Fortran. I tried to integrate my solution into emscripten, but was not able to make much progress due to time limitations and the complexity of the emscripten codebase.

[stale[bot]]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

[jakirkham]

Would it be alright to keep this open? This still seems desirable

[carlkl]

I just noticed this novelty:

The msys2 team now provides flang (based on llvm-16 with some patches) for it's clang64 based environments. With that also scipy is provided there: clang64 and clangarm64 environments. See here: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-flang.

In the msys2 32-bit envrironment flang isn't supported; to my knowlegde because of the memory consumption of Flang. I have no idea if this restriction also applies to emscripten.

Phoronix recently published an article about the status of Flang: LLVM's Fortran Compiler "Flang" Makes Significant Progress But Not Yet Production Ready. However, regardless of this statement flang seams to be good enough to compile and run the scipy. scipy itself is a scientific python extension and an important part of podide and pyscript and therefore of great interest in these communities.

[stuartjamesmcnicholas]

I very recently (last night) got what I think is a fully working Fortran toolchain sorted.

1. I built llvm including flang-new from llvm git repo (5ddd561cb5e2d2c55f4d42912a96d1e0982697b1).

2. Wrote a small driver python script based on instructions in https://niconiconi.neocities.org/tech-notes/fortran-in-webassembly-and-field-solver/ I added a step to change instances of i64 to i32 in the .ll file.

3. Compiled the "runtime" and "decimal" libraries parts of flang-new with emscripten, simply by running emcmake, make on those directories. I had to do some very minor patching to get it to compile.

And that's it. I use my python flang/llc wrapper as FC when using emcmake and JS/wasm fortran executables or libraries can be produce.

I do not know if this would be generally useful though. Happy to share details if anyone interested.

[jakirkham]

Thanks for sharing! 🙏

Looks like there is an LLVM 17.0.0 release coming up

[anutosh491]

here are some updates (if you haven't seen them already)

1. https://gws.phd/posts/fortran_wasm/ (blog on patched flang being able to output wasm objects)
2. Improvements on "1" (https://github.com/llvm/llvm-project/blob/b15d2b2b1ded09290e2f429c3bba0d4ca0a5e94a/README.wasm.md)
3. This was packaged on conda-forge too (https://github.com/conda-forge/flang-feedstock/pull/69)

So technically we can use emscripten with a version of patched flang to hopefully resolve issues pointed out in this issue

[stuartjamesmcnicholas]

Wow, thanks! I was aware of the work of point 1, but 2 and 3 are very exciting.

[hoodmane]

It would still be great if Emscripten bundled flag with it. An update from this week: https://blog.llvm.org/posts/2025-03-11-flang-new/

[dschuff]

It might be straightforward to e.g. "just" include flang with emscripten's build of LLVM, but would that be enough to be useful? What about runtime libraries? What else would be needed to actually build a toolchain?