This final week was a deep dive into the heart of the bugs that had haunted us throughout the summer — the ones that didn’t yet have reproducible MREs, or worse, had partial workarounds in the FPM build. These were workarounds where commenting a single statements make code compiling else it crashes. So I understood fortran codeflow properly for that particular line like which variables are used, what struct is used, its intent, its location etc. and with focus I tried to replicate same scenario in a small fortran code which can reproduce same error and I was successful doing that.

So primary goal was to get all MREs for workarounds that were just a commented line without know reason why it was failing. There were 5-6 MREs which were not having MREs and were tricky to create one.

Work done this week:

• Create MREs for 5-6 workarounds on lf-6 branch which were tricky ones. So we have MREs for all workarounds on fpm local branch.
• Reduced workarounds number to ~10 from ~20 (Tested at LFortran CI)
• Fixed 8-10 MREs which helped me to remove workarounds from fpm codebase
• Fixed all Regressions from StructType Refactor

Some of tricky MREs created:

• Issue #8240: Class vtab pointer got out of scope in if else condition when another type is passed as argument in type bound procedure. Basically vtab for struct was getting declared in if block and LFortran was using same variable in else block which is not syntactical correct.
• Issue #8252: Nested subroutine variable of structType (which is stored as a global Var in LLVM IR) has incorrect order of its member. Consider original order of members was [b,a,c] but global var was storing it alphabetically as [a,b,c]. This was just a small fix but creating this MREs was very tricky.
• Issue #8257: Handle type bound generic procedure call properly in serialization while creating .mod files

Some important Fixes pushed:

• Issue #8265: Handle nested struct members of ArrayItem. Here I handled a small bug in ASR for complex expressions like a%b%c%d(i)
• Issue #8261: handle parent type struct member in backend. Here I handled examples like below:
• Issue #8273: Store data member of Struct_t in same order as declared in original code while initializing global variable. It is fix corresponding 2nd issue listed above

Final Status

• FPM now compiles 100% with LFortran-LLVM backend
• Only 10 minimal workarounds remain (down from ~25)
• MREs written for all known workarounds
• LFortran CI for testing fpm lf-6 branch is active and green

What I Learned This Summer

More than just fixing bugs, I learned to see through the layers of a compiler — from the user's Fortran code to the final LLVM IR. I now understand in detail:

• How ASR (Abstract Semantic Representation) enables both flexibility and strict correctness
• How Object Oriented Stuff is working in LFortran codebase and improvements needs.
• How to optimize at different locations in ASR and LLVM. For eg. something that is not used in original fortran code or any extra operations we are doing which are not needed at all.
• The value of simplifying problems until the compiler has no escape hatch

I also grew significantly in engineering discipline — writing clean test cases, maintaining PR hygiene, and collaborating asynchronously with global contributors.

I created around 100+ MREs and pushed 100+ Fixes for getting FPM compiled with LFortran with just 10 workarounds. So during this summer struct/class/OOP related stuff was robustly tested at integration tests using these MRE.

Acknowledgements

Deep thanks to my mentors Ondřej and Pranav — for not only helping me unblock technical hurdles, but also encouraging me to push for deeper understanding. Thanks also to LFortran Community to have such a great collaborative environment and help.

Thanks to GSoC and Fortran-lang to give me this opportunity and it helped me a lot for upgrading skills and collaborating with different people.

What’s Next

• Remove remaining 10 workarounds with upstream fixes
• Test FPM by running fpm tests on CI
• Looking forward to contribute to LFortran in future

✨ Final Words

GSoC 2025 was much more than 12 weeks of coding — it was a chance to become a real part of a compiler’s growth story, contribute meaningfully to the Fortran ecosystem, and connect with a fantastic community.

I plan to continue maintaining and improving LFortran — not just as a contributor, but as someone who now understands how powerful this project can be for compiling modern Fortran codes.

Thank you to everyone at Fortran-lang. Onward!