------- Comment #6 from dir at lanl dot gov 2007-06-18 18:13 -------
> Now I don't know how the compiler is supposed to behave when there is a
> mismatch between the arguments in the subroutines and their call.
I do - since the beginning of FORTRAN, well, at least since FORTRAN 2, it
simply passes the starting address down for simple data types. I have worked
several commercial finite element codes over the years and at least half of
them call routines with wrong data type for various reasons - to do extremely
efficient low cost dynamic memory management, to create objects, to overload
modules, to do multiple inheritance, etc... Fortran 90 has not always been
around to do these things legally.
That is all not relevant anyway, if you would look at the output, you would
realize that the only this wrong is that the loop -
do 242 i=1,nvg
j2=jj+iprec*(i-1)
c+---------------------------------------------------------------------+
c| multiply main diagonals by 2 |
c+---------------------------------------------------------------------+
jt=t(j2)
tt=tt+tt
t(j2)=jt
242 jj=jj+iprec*i
does not compile correctly - The program prints the data before and after the
loop. If you look at the assembly language output for that loop, it is
incorrect for O2. I make a quick try at pulling it out of the routine, but that
fail - so I just submitted the whole routine as I had already spent several
hours eliminated the other 100,000 lines of code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32393
