FTN95 computes wrong size of array

The following is a modified version of a very compact code to print out prime integers, by Arjen Markus, author of the book Modern Fortran in Practice, Cambridge, 2012 ( https://www.cambridge.org/core/books/modern-fortran-in-practice/BC5BD23B2E478B4D457C5D6265BA9363 ). The special feature of the program is the use of the PACK intrinsic to do most of the work of sifting through candidate prime numbers. The program works correctly with NAG, Intel and Gfortran, and uses the 'allocate on assignment' feature of Fortran 200X.

FTN95 calculates the wrong size (2490 instead of 563) for the array multiples. As a consequence, the (over)allocated array has nearly 2000 elements undefined, which leads to program errors and aborts in the subsequent portions of the program.

program prime_sieve

    implicit none

    integer, parameter :: N = 1000, rtN = 31
    integer, parameter :: candidates(N/2) = [2,(i, i=3,N-1,2)]
    integer, allocatable :: multiples(:)
    integer, allocatable :: primes(:)
    integer            :: i, j

    multiples = [(( i*j, i=j,N/j,2), j=3,rtN,2)]  ! FTN95 signals Ref. to Undef. Var.
    print *,'size(multiples array) = ',size(multiples) ! expected: 563

    primes = pack( candidates, [(all(candidates(i) /= multiples), &
       i = 1,size(candidates))] )
    print '(A,I5,A,I5)','Found',size(primes),' primes <= ',N

end program prime_sieve

mecej4

Thank you for the bug report which I have logged for investigation.

FTN95 has now been fixed so that it will compile and successfully run this program. Thank you mecej4. Your feedback is greatly appreciated.

I have not looked at the book so I don't know what point the author is making.

I find the algorithm difficult to understand. Its compactness is impressive but maybe not practical with regard to maintenance.

There can be a false assumption that compactness leads to minimal object code. However, in situations like this, the compiler may be forced to introduce and compute temporary arrays that would not be needed in a more direct approach.

Thanks for the fix, Paul.

I agree with you that using intrinsics such as PACK, which yield a result whose size/shape may not be known at compile time, can make the code confusing, albeit compact. John Campbell, you and I discussed its properties and usage in another thread in this forum ( https://forums.silverfrost.com/Forum/Topic/3814 ).

It was the code example on Quicksort in the book by Arjen Markus that impressed me at first sight and invited me to try out PACK. Such usages of PACK are somewhat disruptive since many Fortran programmers' natural approach is to program an algorithm, instead of merely writing a specification for selecting a subset of an array with certain properties, and having PACK deliver just the selected items, all without bothering to consider how these tasks get done.

As you observed, there is a trade-off between convenience and efficiency. For small data sets, the convenience may dominate since even an inefficient execution takes a negligible amount of CPU time. After a candidate program has been built using PACK, and tested with small data sets, one could replace the lines using PACK with calls to a more efficient utility such as a Quicksort subroutine, and then apply the program to larger data sets.