Hi. I have started working on my GSoC, 2021 project, Supporting Arrays and Allocatables in LFortran. Here is the link to its first week’s blog post, Week 1 - Declaring, Initialising and Passing Fortran Arrays | czgdp1807
Would appreciate your feedback on this. Thank you.
10 Likes
Thanks for your work and for your blog post, which gives me an inkling of what it is like to write a Fortran compiler. Supporting arrays will be a big step for LFortran.
3 Likes
Thanks for your comment. I am writing a compiler for the first time and I have realized that there are several cases that one has to keep in mind while brainstorming. Community support plays an important role here as different people bring different perspectives, ideas on the table.
1 Like
Proper array handling is at the core of Fortran. Congrations! Your work will be close to the heart of the language.
I have a doubt regarding converting implied into explicit do loop. Implied do works for parameter array initialization (something I frequently use to target compile time evaluations). Would not your solution restrict that?
3 Likes
@mfurquan you are right that such a rewrite might not work for parameter initialization — I guess maybe one could create a pure function that uses a do loop internally. Otherwise this would then have to be handled in the LLVM backend if there is no Fortran equivalent.
I don’t think it is allowed (I checked latest edition of Metcalf). Only intrinsic functions can be used to form constant expressions. Aside, I do think there should be a ‘constexpr’ equivalent in Fortran.
Another case where do and implied do are not equivalent is the write statement. Unless advance is set to ‘NO’, do puts a linefeed after every iteration. Implied do is the most frequently used way of writing without line breaks.
Bottomline is implied do is not a syntactic sugar for do. Both have to be handled differently at the backend.
I think that’s right. What we could do is to simply “create a temporary intrinsic function” inside the compiler and the backend would treat it as such. Alternatively, in a declaration, I believe all the bounds must be known at compile time, so one can simply execute the implied do loop at compile time and return an array, e.g. this:
integer, parameter :: x(10) = [(i**2, i = 1, 10)]
could be transformed into:
integer, parameter :: x(10) = [1**2, 2**2, 3**2, ..., 10**2]
As in here?
print '("Matrix A"/(10F8.2))', ((A(i,j), i = 1, 10), j = 1, 10)
Isn’t this equivalent to:
do j = 1, 10
do i = 1, 10
k = 10*(j-1) + i
B(k) = A(i,j)
end do
end do
print '("Matrix A"/(10F8.2))', B
Either way it is, we plan to implement things properly according to the standard, so that things work as expected.
You are right. Format string is the precise way of writing. What I had in mind was:
do j = 1,10
write(*,*) (A(i,j), i = 1,10)
end do
1 Like
Hi, The blog post for second week is uploaded. Please find at, Week 2 - Operations, Slicing and Intrinsic Functions Support For Arrays | czgdp1807
Thanks.
2 Likes
@czgdp1807 posted his third blog post: Week 3 - Slicing Arrays and Passing them to User Defined Functions | czgdp1807
@milancurcic, @lkedward it seems @czgdp1807 is moderated (automatically) and I can’t figure out how to unmoderate him so that he can keep posting.
Hi. Blog post for week 4 is available at, Week 4 - Variable Sized Arrays for Storing Slicing Results | czgdp1807
3 Likes
Thank you, great progress!
Blog Post for Week 6 - Allocatable Arrays and Extending Support for Array Operations | czgdp1807
Thanks.
1 Like
Hi, Blog Post for Week 7 - Array Operations & Segmentation Faults | czgdp1807
This was really a Segfault week. 
1 Like
Blog post for Week 8 - Implicit Deallocate & Abstracting Descriptor Access | czgdp1807
Thanks. Happy Weekend.
1 Like
Thank you! Great job.