Week12 - SciPy Build & Fixing bugs
SciPy Build & Fixing bugs
Date: Aug 6, 2023.
Hello everyone! Week 12, last week of my GSoC journey. This week I worked on getting SciPy build in my system and also fixed some bugs in LFortran.
Let's start with SciPy build, after discussion with Ondřej Čertík, we decided to open an issue at SciPy stating them the problem that I am facing while building SciPy. The issue can be found at Issue: 19017. In short, the error that I faced was `AssertionError: Bad argument number for Assign: 3, expecting 2`. At first site it looked like a problem with gast version, but later we found that trouble is in installation of mambaforge. I mistakenly installed mambaforge-pypy3 and not mambaforge. Thanks to Ondřej Čertík for pointing out the error, and then on successful installation of mambaforge from miniforge#mambaforge SciPy build was successful.
Moving ahead, I implemented a new flag `--use-loop-variable-after-loop` which is used to decide whether to use loop variable after loop or not. In continuation of work from previous week PR: 2079, we decided to hide the implementation under a flag. The PR can be found at PR: 2081.
Then I worked on Issue: 1977 which is about handling of external functions in LFortran. Let us take the minimal example to understand the problem:
If we look at the code, `f` is an external function with no exisiting implementation and hence we need use the standard template `f` created while handling external functions and hence ASR generates correctly. For LLVM, we have `f` type mentioned as Interface and hence compiler donot generate function code, then it is passed in as a subroutine call argument and here the compiler askes generated code but as there is no code generated it throws an error. The solution to this problem is: When visiting the function dqc25f in the body visitor, check if there are any external symbols in it. If so, resolve them fully, that is, find f in the global symbol table, if available, update the interface stub to be conforming. If it is not available, then don't do anything, since the function f will be linked in a separate compilation, in which case it's fine if the type doesn't match.
Next up, I worked on Issue: 2086, which catches an inefficient implementation of data statement in LFortran. Let us take a look at the example: The problem here is that current implementation of data statement adds Integer 2, 3350 times to the list at compile time. This produces a very hefty around 24,000+ lines of code in LLVM which then takes a lot of time to compile. A solution to This is to create a do loop for assignment to vect.
So with 16.5 hours this week, I was able to get SciPy build and also fixed some bugs in LFortran. All in all for entire 12 weeks, I completed 248.5 hours out of 175 hours and get LFortran compile entire codebase of SciPy to ASR, 77.995% files to LLVM :)). I would like to thank Ondřej Čertík for helping me throughout my GSoC journey. I would also like to thank Thirumalai Shaktivel, Gagandeep Singh, Ubaid Saikh, Smit Lunagaria and all other members of LFortran community for helping me and guiding me whenever I was stuck. I would also like to thank Google for giving me this opportunity to work with LFortran.
Daily logs of work done can be found at