LFortran can now compile fpm, the Fortran Package Manager. We opened up an issue for it in April 2025, when we started focusing on it as a priority. We closed it on February 7, 2026. fpm is the most complex project that we now successfully built and run. It is an interesting project: it is not computational, but rather a system project which exercises running other programs, reading environment variables, command-line argument parsing, reading and writing files, directories, parsing enough Fortran to understand dependencies, etc. It uses almost all modern Fortran features: classes, inheritance, allocatable components, constructors, arrays of classes, select type, associate, automatic LHS (left-hand side) reallocation, strings, arrays of strings and it exposed dozens and dozens of bugs and missing features in LFortran. And we have now implemented them all. As a result, LFortran is really close to beta, and we are advancing our progress bar to 9/10.

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 are thrilled to announce that LFortran can now successfully compile and run predsci/POT3D, marking a significant milestone in our journey to beta. POT3D is the ninth production-grade, third-party code that LFortran can compile, bringing us closer to our goal of compiling 10 such codes—a critical step toward a beta-quality compiler.

About POT3D

POT3D: High Performance Potential Field Solver is a package developed by Predictive Science Inc., written in Fortran that computes potential field solutions to approximate the solar coronal magnetic field using observed photospheric magnetic fields as a boundary condition. It can be used to generate potential field source surface (PFSS), potential field current sheet (PFCS), and open field (OF) models. It has been (and continues to be) used for numerous studies of coronal structure and dynamics. The code is highly parallelized using MPI and is GPU-accelerated using Fortran standard parallelism (do concurrent) and OpenMP Target for data movement and device selection, along with an option to use the NVIDIA cuSparse library. The HDF5 file format is used for input/output.

We’re thrilled to share that LFortran can now successfully compile and execute libprima/PRIMA. PRIMA marks the eighth production-grade, third-party code that LFortran has compiled with bit-for-bit alignment to GFortran’s output. This milestone brings us closer to our goal of compiling 10 such codes—an essential step toward achieving a beta-quality compiler.

About PRIMA

PRIMA is a package developed by Zaikun Zhang for solving general nonlinear optimization problems without using derivatives. It provides the reference implementation for Powell’s derivative-free optimization methods, i.e., COBYLA, UOBYQA, NEWUOA, BOBYQA, and LINCOA. PRIMA means Reference Implementation for Powell’s methods with Modernization and Amelioration, P for Powell. The package is written in Fortran and is widely used in the scientific community for solving optimization problems.

We are thrilled to announce that LFortran supports all intrinsic functions listed in F2018 Interpretation Document (Table 16.1 Pg: 332) (also shown by this nice list online at GFortran’s documentation). This comprehensive list of almost 200 intrinsics encompasses a broad array of functions and subroutines essential to Fortran’s functionality, including elemental, inquiry, transformational, array operations, and more. For each function we support both compile-time and runtime evaluation.

The functions are implemented in an ASR (Abstract Semantic Representation) pass, which means they get “instantiated” and specialized for the argument types and then the compiler can optimize it, so using any intrinsic function is at least as fast as implementing the same operation yourself, there is no runtime overhead.

We are thrilled to announce that LFortran can now successfully compile and run lanl/SNAP, marking a significant milestone in our journey to beta. SNAP is the seventh production-grade, third-party code that LFortran can compile, bringing us closer to our goal of compiling 10 such codes—a critical step toward a beta-quality compiler.

About SNAP

SNAP (SN Discrete Ordinates Application Proxy) is a proxy application designed to emulate the performance of modern discrete ordinates neutral particle transport codes. It replicates the computational workload, memory requirements, and communication patterns of the Los Alamos National Laboratory code PARTISN, without including actual physics. By using domain decomposition and parallelization across spatial, angular, and energy domains, SNAP is ideal for performance testing on cutting-edge high-performance computing systems.

In early June, we announced a significant achievement with LFortran: the Fastest Open-Source Compiler in Compile-Time Evaluation of an Array Benchmark. Continuing our commitment to performance enhancement, we are pleased to announce that LFortran now includes support for OpenMP pragmas and parallelizing do concurrent. Particularly for parallel do OpenMP construct, our implementation is fully operational and achieves performance comparable to GFortran.

Note that LFortran is still a alpha software, meaning that users must continue expecting that LFortran will fail compiling or running their codes. Please report all bugs that you find.

After successful compilation of stdlib and Fortran On Web Using LFortran, we focused on improving the support for compile time computation and we are excited to announce that LFortran can now compile the example from the Computing at compile time Fortran Discourse topic.

This example can be used to benchmark the speed of compilation and compile-time array evaluation by increasing the size of the arrays. On this particular example LFortran outperforms other open-source Fortran compilers by an order of magnitude for large array sizes. For small array sizes each compiler has a different constant overhead, which becomes negligible for large arrays and this benchmark measures how quickly the compiler can internally apply the symbolic function on a large array numerically.

Fortran On Web Using LFortran

Recently, there was a blog post titled Fortran on WebAssembly released by Dr George W Stagg. This article inspired us to compile the same example using our LFortran compiler. We are happy to share that we have the fortran mnist classifier example used in the blog post, compiled to WebAssembly using LFortran (with no hacks to the compiler) and working perfectly in the browser.

MNIST

We cloned the original authors code and just swapped-in two of our generated files mnist.js and mnist.wasm with the original files. We also fixed few minor bugs in the code that we came across (details in the commit history).

LFortran compiles 85% Fortran stdlib

We are happy to announce that LFortran can compile all numerical modules in stdlib. The stdlib library has 32 modules, here are the details of the current status:

• all 32 modules compile to ASR
• 27 modules (85%) compile to LLVM; there are 4 hash modules (hash_32bit, hash_64bit, hashmaps, hashmap_wrappers, stringlist_type) and one stringlist_type module that does not compile to LLVM yet
• 24 modules pass all their tests; 3 modules (sorting, bitsets, stats) do not pass all tests yet, but simple examples that use the modules work

This is sixth third-party production-grade code that LFortran can compile after SciPy. The progress bar towards beta has thus reached 6/10.