Every respectable Fortran compiler must be able to compile LAPACK, probably the most famous and influential Fortran library.
Christopher Albert spent most of December 2025 to get it working, it took about 70 PRs (pull requests). For context, LFortran is composed of about 4,500 merged PRs at GitHub plus another 1,800 merged PRs at GitLab (before we switched to GitHub), total of 6,300 PRs. So 70 PRs is about 1% of all the PRs, very impressive effort!
We have been mainly focusing on modern Fortran with LFortran, so the features
that Christopher had to implement mostly concern various older features like
equivalence, common block, etc., as well as many bugs, including some
numerical bugs that compiling any production code exposes.
LAPACK now works in single/double precision, real/complex, as well as with both default 32-bit and 64-bit integers, all tests pass. You can see how we test it for every commit at our CI.
There is an old blog post when the original Flang (before LLVM Flang and before legacy Flang…) could compile LAPACK in 2013. You can tell the author was very excited. Many of the numerical issues he faced we also faced. Unfortunately it looks like that version of Flang stopped development soon after. I (Ondřej) remember reading this blog post and intentionally did not focus on LAPACK with LFortran. It must come as a side effect of the compiler maturing.
We did not focus on LAPACK at all, our goal is to compile all Fortran codes, so we have been compiling codes with increasing complexity. LAPACK is now a nice bonus. But also we can now call ourselves respectable. It does exercise the numerics implementation in LFortran really well. It means LFortran can now be used to implement most numerical algorithms and trust the results.
We are still in alpha stage, meaning LFortran is expected to break when compiling your code. However our experience when compiling new 3rd-party codes is that the bugs we need to fix are all relatively small. We plan to spend most of 2026 just compiling as many codes as we can, until we start expecting LFortran to just work on most new 3rd-party codes; then we can declare beta quality.
Join Us
We welcome new contributors to join our journey. If you’re interested, please reach out on Zulip. Working on LFortran is both challenging and rewarding, offering great opportunities for learning and growth.
Acknowledgements
We want to thank:
- Sovereign Tech Fund (STF)
- NumFOCUS
- QuantStack
- Google Summer of Code
- FLOSS/fund
- John D. Cook
- LANL
- GSI Technology
- Our GitHub, OpenCollective and NumFOCUS sponsors
- All our contributors (131 so far!)