In the following calls to the solvers, the third and fifth actual arguments are identical

dlsoda.inc  1815 call dstoda 
dlsodar.inc 2002 call dstoda 
dlsode.inc  1824 call dstode 
dlsodes.inc 2068 call dstode 
dlsodi.inc  1957 call dstodi 
dlsodis.inc 2345 call dstodi 
dlsodkr.inc 2020 call dstoka 
dlsodpk.inc 1858 call dstodpk
dlsoibt.inc 1991 call dstodi 

In all these calls, the third and fifth actual arguments are the same section of the work array, namely, Rwork(dls1%lyh) . The corresponding dummy arguments are YH(NYH,*) and YH1(*). Within the code you can see comments such as "YH1: a one-dimensional array occupying the same space as YH."

With modern optimizing compilers, this violation of the Fortran antialiasing rules can lead to problems -- wrong results, wrong selection of code paths, access violations, etc. This could happen even if the 3rd argument were always used as INTENT(IN) and the 5th argument with INTENT(OUT).

These cases of aliasing are obvious when you look at the lines where they occur. There are many more instances where the subscripts into the one and only one work array are different for different actual arguments, and one needs to investigate to see if any overlap occurs. Such overlap may occur for only certain combinations of input data to the program.

I have seen several instances where the LSODPK example failed, announcing "Poor iterative algorithm performance" when built with some compilers, but ran without such messages with other compilers (or with different compiler options).