Bizarre run-time error in the compiler itself

Okay, I was trying to compile a program, and I got the following:

Compiling file: SmallRad.f95 C:\Fortran\SmallRad.F95(10) : comment 981 - Specifying the kind of the type REAL with the constant '2' is non-portable - 'SELECTED_REAL_KIND(15,307)' would be better C:\Fortran\SmallRad.F95(72) : comment 1005 - This declaration of RR has caused the intrinsic of the same name to be inaccessible Access violation: The instruction at address 004357b7 attempted to read from location 00000008 0043577c is_type_eq(<ptr>structÄtype_definition,<ptr>structÄtype_definition) [+003b]

00459192 read_module_entity(enumÄlogical)#1D [+0d96]

0045a95a process_binary_module(int,enumÄlogical)#1D [+034b]

0045b146 process_use_stmt(<ptr>char,<ref>int) [+0264]

0040a953 parse_declaration_statement(<ptr>char,int,int,<ref>int) [+25e2]

0041200b handle_token(<ptr>char,int,int,int,int,<ref>int) [+0df5]

0040514d ProcessEntireLine(void) [+0695]

0040619b compile(<ptr>char) [+00ce]

eax=00000000 ebx=0000000b ecx=04433d94 edx=00000000 esi=0440edc8 edi=0442c54c ebp=0383f220 esp=0383f1fc IOPL=0 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00210206 [NC EP NZ SN DN NV] 0360/4820 TSTK=1 [ ] 004357b7 mov edi,[eax+0x8]

004357ba mov [ebp-0x10],edi

How do I figure out what statement was involved and what do I do to fix it? The dump appears to be of instructions and the contents of registers for the compiler, not the program being compiled.

-BPL

Barton

Just comment out blocks of your program until the access violation goes away.

Alternatively, start from nothing and add a few lines at a time.

When you find the offending line, post a short demonstartion program here so that we can fix the bug.

[small]Paul Laidler wrote:[/small] *Just comment out blocks of your program until the access violation goes away.

Alternatively, start from nothing and add a few lines at a time.

When you find the offending line, post a short demonstartion program here so that we can fix the bug.*

I tried the latter method, and I found the bug. In my data module, I had:

[pre] real(kind=2) :: P ! Surface pressure in mb.[/pre]

But further down, in a subroutine, I had:

[pre] Subroutine Scale(row, p) use SmallRadStuff

    integer :: row              ! Row number.
    real(kind=2) :: p           ! Scale factor.[/pre]

P and p, of course, are the same variable to a case-insensitive compiler. Now, in theory, this just should have blocked P off from use in that subroutine, but apparently it causes a conflict. All I have to do now is rename p in the subroutine.

Once again, thanks very much for your help.

-BPL

Barton

Can you post a small program that demonstrates the access violation so we can fix it?

[small]Paul Laidler wrote:[/small] Can you post a small program that demonstrates the access violation so we can fix it?

Yes, I'll try to do that today. Nag me if it isn't up by the end of the week.

-BPL

[small]Barton Levenson wrote:[/small] *Paul Laidler wrote: Can you post a small program that demonstrates the access violation so we can fix it?

Yes, I'll try to do that today. Nag me if it isn't up by the end of the week.*

Okay, here's the code for a short program that causes the explosion. It's 26 lines including lots and lots of comment lines:

[pre]!===== ! Access demonstrates how a mistake in coding can blow up the compiler. !===== Module DataStuff real(kind=2) :: P ! Pressure at Earth's surface, in mb. End Module DataStuff

!===== ! Main routine starts here. !===== Program Access Write(*, *) 'Here goes...' Call Flub(17.2_2) End Program Access

!===== ! Flub uses a name identical to the one in the data module as a ! subroutine argument, thus wreaking havoc with the computer. !===== Subroutine Flub(p) use DataStuff ! This is crucial to killing the compiler.

real(kind=2) :: p   ! Some other quantity.

p = 4.4

End Subroutine Flub[/pre]

By the way, can anybody tell me why 'pre' eliminates all the blank lines?

-BPL

[small]Bruce Bowler wrote:[/small] Just a casual observer here, who hasn't downloaded and tried your example, but I'm VERY surprised that changing P to p (or vise versa) would make a difference. The REAL problem with the example is that you're trying to change the value of a constant. Does the real program also attempt to change a constant?

All changing P to p did was obscure the fact that I was using the same name for two variables. I don't believe I declared either one as a constant.

-BPL

Barton

Looks like the bug has already been fixed.