FortranCon2021/Fortran-lang: GSoC LFortran Presentations
Channel: FortranCon
Date: 15/11/2021

Fortran-lang Minisymposium, Presentation of the Google Summer of Code projects around LFortran & discussion.

===
Finish AST generation in LFortran
Speaker: Thirumalai Shaktivel
Material: https://tcevents.chem.uzh.ch/event/14/contributions/83/

LFortran has a Bison based parser implemented in the parser.yy file that can parse most of Fortran source code. The main objective of my GSoC project was to make sure that all the grammar rules defined are exposed to AST (Abstract Syntax Tree) leveli.e., one has to systematically go over the parser file and make sure AST is always generated for all the grammar rules defined, resulting in Completion of the AST generation. AST.asdl contains a list of AST nodes that have already been implemented,this project aims at adding the missing node into the AST.asdl.
The steps for implementation are:
Add missing AST nodes.
Define macros, use them in the parser file to expose these nodes to the AST level.
Add tests to make sure things work as expected.
 The `fmt` sub-command(format) is used to convert AST back to Fortran source code. There were certain issues related to `fmt` and `parser`, this project solved those issues. As a result, LFortran would be able to convert every grammar rule defined into AST for further manipulation and if required back to Fortran source code.

===
Supporting Arrays and Allocatables in LFortran
Speaker: Gagandeep Singh
Material: https://tcevents.chem.uzh.ch/event/14/contributions/63/

In my Google Summer of Code, 2021 with LFortran under the umbrella of NumFOCUS, I worked on adding semantic and LLVM backend support for arrays and allocatables as per Fortran standards. Specifically, the project resulted in addition of support for **array declaration**, **operations on arrays** (**slicing**, **unary and binary operations**), **allocatable arrays**, **automatic deallocation**, **passing arrays to subroutines and functions**. At the LLVM level, structures have been used as descriptors to store the necessary information related to an array such as the pointer to the data, offset and dimensions’ lower and upper bounds. Operations on arrays are converted to `do` loops while storing the intermediate results in compiler generated variables. Memory for allocatable arrays is reserved in heap using `malloc` and freed using `free` in C runtime library. Automatic deallocation is achieved by freeing memory of those allocatable arrays in a particular scope which haven’t been manually deallocated by the user. We pass pointers to array descriptors (for arrays on heap) and pointers to data (for arrays on stack) in functions and subroutines. In this talk, I would be covering each of these topics in detail with some examples of internal representations (ASR, LLVM) generated by LFortran.

===
Implementing Fortran Standardese within LFortran
Speaker: Rohit Goswami
Material: https://tcevents.chem.uzh.ch/event/14/contributions/69/

The Fortran standard is a rather imposing document; though with F2018 at around 600 pages it is significantly lighter than its C++ counterpart. The standard itself is rarely cited as a beginner resource, with a cottage industry of books designed to shed light on the dry prose and foreboding technical rigor. However, with LFortran, particularly viewed through the lens of the Abstract Semantic Representation (ASR) of any Fortran code, the standard suddenly gains clarity and rigor.  Being as it isa Fortran-first representation, unlike GCC's internal representations (parse trees and lowered GIMPLE) or opaque (proprietary) middle-layers of NAG/Intel; the ASR is meant to concretely represent the syntax in a way to make the Standard seem eminently rational. Implementing the intrinsic functions and standard computing models become pleasant C++ puzzles instead of pidgin nightmares of progressively lower representations. In this presentation, I will discuss the process of implementing Standardintrinsic functions, the lifeline of any applied physical science researcher. LFortran allows for further flexibility at runtime, which will come up briefly, but most of the focus for this short talk will be on the compile time evaluation of intrinsic functions and future directions.

===
Discussion