Program producing output only when built with -heap-arrays

[Arjen_Markus]

I was experimenting with different implementations of a simple algorithm and stumbled on this problem: if the parameter max_ij in the program is set to 100, then at run-time it produces a stack overflow. So, I reduced the value to 13 (the smallest value that ought to give an output), but then there is none. If I compile the program with gfortran, I do get the expected answer, 1729.

If I compile with option -heap-arrays to solve the stack overflow, then I do get that same answer (and with a value of 100 the full set of solutions).

It is a silly program, only meant for a demonstration, but still the fact that no output results is odd. I am using Intel Fortran oneAPI 2023.1.0 here. I have not tried yet with a newer version.

[mecej4]

The following shortened version of Arjen's program triggers a serious problem in the current Ifort (Build 20240222) and Ifx compilers (Build 20240308) on Windows 11.

program ramanujan_single
    implicit none
    integer, parameter   :: max_ij  = 13, max_sum = 2 * max_ij ** 3
    integer              :: i, j, k

    write(*,*) pack( [ (k, k = 1,max_sum)], &
                     [ ( count( [((i**3+j**3, i = 1,j), &
                        j = 1,max_ij)] == k ) > 1, &
                        k = 1,max_sum )] )

end program ramanujan_single

With the compilation command

ifx /Od ramsingl.f90

the compilation did not produce an EXE even after one minute! Ditto for Ifort.

I also tried an old version (14.0.4.237 Build 20140805) of the Ifort compiler on this program. The compilation went through in less than a second, but the resulting EXE, when run, produced no output and took 1.5 seconds to do so. Raising the stack size of the EXE to 4 megabytes, however, caused the EXE to run and output the correct result.

[Ron_Green]

I haven't tried this on Windows.  But I do see what is probably the same issue on Linux.  Very slow compilation on linux, but it does finish and the executable does work as expected.

$ module load oneapi/2024.1.0
$ time gfortran -g -O0 ramsingl.f90 

real	0m1.746s
user	0m1.528s
sys	0m0.060s
$ time ifx -g -O0 -what -V ramsingl.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.1.0 Build 20240308
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 24.0-1472.3
GNU ld version 2.39-9.fc38

real	0m45.896s
user	0m43.901s
sys	0m0.755s
rwgreen@orcsle153:~/quad/tuesday$ ./a.out
        1729

[Ron_Green · Accepted solution]

After a deeper analysis I found this is a bug in the compiler.  It appears to get into a long loop manually unrolling the implied DO's, hence creating a massive AST (very time consuming, as you can imagine.).  I'm writing up a bug report on this.  

[mecej4]

Thanks. It is rather odd that IFort and IFX are able to compile the following compile-time-compute version of the same program in about one second.

program ramanujan_single
    implicit none
    integer, parameter   :: max_ij  = 13, max_sum = 2 * max_ij ** 3
    integer              :: i, j, k

    integer, parameter :: s2cube(*) = &
	   pack( [ (k, k = 1,max_sum)], &
                [ ( count( [((i**3+j**3, i = 1,j), &
                  j = 1,max_ij)] == k ) > 1, &
                  k = 1,max_sum )] )
    print *, s2cube
end program ramanujan_single

[Ron_Green]

yes, it's an interplay of the parser and what we call "the middle end" - it's the middle-end of our front end, not the middle end of the overall compiler.  "Our middle-Front-end".  

[Ron_Green]

bug id is CMPLRLLVM-57641

[Arjen_Markus]

Thanks for taking care of this. gfortran has similar issues with my original program (very long compile times), but turning the parameter max_sum into a variable makes it all go as fast as you would expect.

[Devorah_H_Intel]

The fix for this issue will be available in the upcoming 2025.1 ifx