addressing problems with g77 on alpha/linux

Red Hat Linux User adler@ssadler.phy.bnl.gov
Sun Jan 4 18:58:00 GMT 1998


egcs people,

I've spent a week or so trying to build a large fortran based software
package in use by the nuclear and high energy phyiscs community
called CERNLIB. I've been able to fully build and test this
software package using egcs 1.0 on the intel/linux platform.
I have failed to do so on the alpha/linux platform. Both
platforms are running redhat 5.0. The first main problem I'm
having on the alpha/linux platform is some kind of addressing
problem. Some of the CERNLIB test routines bomb with a
segment violation. It looks something like this.

	program bomb

	integer i(10),i

	do j = 1, 10
	  i(j) = 0
	end do

	call zero(i,10)
	
	end

	subroutine zero(a,n)

	integer a(*),n,i

	do i = 1, n
	  a(i) = 0
	end do

	return
	end


In the above code, the array i is cleared fine, but when passed
to subroutine zero, the program bombs on the first a(i)=0 line. The
wierd thing is that if I do a print *,%loc(a(1)) inside
zero, I get the same address as if I do a print *,%loc(i(1))
in the main program, so it's like the address of the array
i is being passed properly into zero. If you take the above
code and compile it, it will work. This segmentation
violation that I'm getting, is reproducible, but only
in these test programs which are rather involved and
complicated. but the jist of the problem is as I
have described above. Another wierd thing. In /var/log/message
I get an entry for the segment violation from the
test program and the address is complaining about is
the same as %loc(i(1)) and %loc(a(1)). The thing thats
bizzar is that I can clear the array in the calling routine
but not in the zero routine. Something wierd is going on
in the call statement.

I've built the snapshot version of egcs 971225 but the
problem has not gone away. I don't know what to do and need
help in diagnosing this further. I'm afraid, one needs to
dig into the assembly output to figure this one out. Are
there any suggestions? If someone want's to tackle this
error, I'll be glad to bundle the cernlib test program
into a tar ball so that you can fiddle with it. Otherwise,
any kind of suggestions as to how to proceed would be
appreciated.

stephen.adler@bnl.gov



More information about the Gcc-bugs mailing list