Memory Corruption, Peculiar Assembly

[emr150]

Excuse the length of this post, but I want to be clear in the issue I'm seeing. I've been at this for 3 weeks now and have a flat spot on my head from beating it against the wall.

STRUCTURE /AN_ARRAY/
INTEGER*4 A
...
REAL*4 D
REAL*4 E(6)
...
END STRUCTURE

After assigning values to E, I get AN_ARRAY to be the following:
E(1) = 23.8
E(2) = 224.4
E(3) = 11.1
E(4) = 128.2
E(5) = 4.1
E(6) = 0

However, my program consistently (no matter what is in E) gets a SIGFPE at a line of code that is calling a subroutine:

REAL*4 X, DUMMY
X (DUMMY) = 20.0 * ALOG10 ( MAX ( 1.0E-10, ABS ( DUMMY ) ) )

CALL SOME_SUBROUTINE ( BLAH, BLAH, BLAH, BLAH, X(AN_ARRAY.E(1)), X(AN_ARRAY.E(2)), X(AN_ARRAY.E(3)), X(AN_ARRAY.E(4)), X(AN_ARRAY.E(5)), X(AN_ARRAY.E(6)) )
If I split the subroutine variables so they are on different lines, it says the FPE occurs on the AN_ARRAY.E(5) line. This math should be valid, so I'm not sure why it's always faulting out on me. Any suggestions would be much appreciated.

Thanks.

ifort 8.1 Build 20050702Z

P.S. -- I should clarify the subject......when I started writing this post, I was seeing some chunks of assembly that appeared as though they were overwriting memory regions they shouldn't be (fstps 0x931f4e8(%eax, 8) ), thinking it was writing 8 bytes of data when it was only working on a 4-byte variable, but I need to first brush up on my assembly to better understand what it's trying to do before I can make this assumption.

[Steven_L_Intel1]

Specifically which exception are you seeing? Have you tried a current compiler? (The one you have is three years old.) What compiler options are you using? Have you tried -check bounds?

My experience over the past 30 years is that when users describe what they think is happening rather than the actual results, and show only the lines of source they think are relevant, 99% of the time they are mistaken. Therefore I would suggest trying to reduce the test case to something manageable that you can show us in its entirety. It's quite possible that, along the way, you'll find the problem yourself.