Unable to compile TOMS Algorithm 609 with ifort and ifx 2024.2

[Miguel_Hermanns]

I'm trying to compile Algorithm 609 from ACM Transactions on Mathematical Software using the 2024.2 version of ifort and ifx. I'm compiling the file just as downloaded, without any modifications from my side apart from adding the extension .f to the file, from the following link to the article:

https://dl.acm.org/doi/10.1145/356056.356064

Both compilers issue en error at compilation time at lines 1364-1365 and 2849-2850 that is not correct and that gfortran 8.3.0 (Debian Buster) does not issue. An older version of ifort, run on Ubuntu and on a different PC, issues the same error.

The problem is with the legacy extension of Hollerith constants. It is correctly handled in all appearances in the source file of the algorithm except at the specified source code lines. Shortening the Hollerith constant so that the whole command fits into one line eliminates the error.

Best regards,

Miguel

[andrew_4619]

  310 CALL XERROR(66HIN EXINT,  THE EXPONENTIAL INTEGRAL IS NOT DEFINED
     *FOR X=0 AND N=1, 66, 2, 1)

There is no space char after "DEFINED" and the compiler is not padding to column 72.  If you add a space the the end then that compiles.

Is that not the correct behaviour?

[Miguel_Hermanns]

Good point. Honestly, no idea. However, it makes sense to me what you mention. Thanks for figuring it out.

[andrew_4619]

Given Hollerith's were made redundant in F77 the current standard says nothing, I wouldn't worry too much and just fix it and move on IMO.

[Steve_Lionel · Accepted solution]

This was an interesting issue back when I was on VAX FORTRAN at DEC. The Fortran standard, as I explain in Doctor Fortran in "Source Form Just Wants to be Free" - Doctor Fortran (stevelionel.com), says that fixed-form source lines are exactly 72 columns, no more, no less. This was not an issue in the era of punch cards, but with interactive editors and varying-length source lines, how should a compiler treat a fixed-form source line shorter than 72 columns?

At the time I was investigating this, different compilers had different interpretations. Some padded to 72 columns, some didn't. Technically, such a source file was non-conforming, so a compiler could do anything it wanted. DEC's approach at the time was to not pad, but because some user programs cared (you could see this effect with either Hollerith constants or character literals), we added a pad-source option that would pad short lines to 72 columns. Intel Fortran still has that option today.

[Miguel_Hermanns]

Thanks, Steve, for sharing this interesting piece of history. With the option pad-source passed to the compiler it works. Thanks a lot!

[Arjen_Markus]

I never realised that, but the IBM computer I used at the start of my career had special file types, one being fixed-length files that we used for the FORTRAN code, always 80 characters. Sequential unformatted files had variable-length spanned records. And moving these files from that system to the early PCs made for some non-trivial reading and writing actions :).

[mecej4]

Apart from the pad-to-column-72 issue that has been covered so far, make sure to edit the R1MACH, D1MACH and I1MACH routines in the TOMS 609 source files. You will obtain strange, incorrect program behavior and output if you fail to do this.

The program source is in Fortran-66, i.e., not even Fortran-77; integers are used to represent and process characters. Fortunately, most of the routines where this type of obsolete usage occurs are taken from SLATEC. You may substitute more recent Fortran 77 versions of those routines from www.netlib.org/slatec .

[Miguel_Hermanns]

Too late, already hit the issue of not editing *1MACH before your comment . One learns the hard way, as always ...

Thanks for pointing out SLATEC. Although I knew its existence, I was not fully aware of its relationship with pre-existing codes.