Why won't this compile?

[WSinc]

I wrote a short little subroutine, and it generates only one diagnostic: "fatal build error" when I add it into my project. When looking at the BUILD log, I see "Fatal internal compiler error" but no clues as to what caused the abort.

Interestingly enough, when I change the name of the subroutine (top line) by changing one letter, or shortening slighly, it compiles fine, and the build goes to completion. So I surmise that somehow the compiler does notlike the subroutine name.

I am using Fortan 9.1, don't have 10.x yet so I don't know if this was a bug that was addressed in a later build or a later topic. Or is it a bug?

See attached F90 file - -

[Steven_L_Intel1]

No file was attached. But any "internal compiler error" is a bug and should be reported to Intel Support. However, since you are using 9.1, post the code and I'll try it with 10.1. This symptom sounds vaguely familiar.

[bradmull]

Hmm - it displayed the attached F90 source code yesterday. Is there a time limit?

I wonder why itgot dropped? Anyway, I will cut/paste the source right here in this message.

------------------------------------------------------------------------------------

subroutine convolve()

implicit none

real*8 pi/3.14159265358979324D0/

real*8 func(0:10000)

real*8 conv(0:10000)

real*8 mono(0:20001)

integer i,j,nosamp

! execution

do i=0,10000

conv(i)=sqrt(dble(i)/1.D4)

enddo

do i=0,10000

func(i)=sin(2*pi*dble(i)/1000.)

end do

! do the convolution

do i=0,10000

do j=0,10000

mono(i+j+1)=mono(i+j+1)+func(i)*conv(j)

end do

end do

nosamp=10000

end subroutine

[bradmull]

Curiously enough, even when I remove the entire contents of the subroutine, except for the 1st and last lines, the compiler still "hiccups and dies."

So apparently the NAME of the subroutine is what's triggering the problem. As I said before, minor changes to it make the problem go away.

How do I report this (if needed)?

[Steven_L_Intel1]

I can't reproduce the problem in 9.1.039 or 10.1.019. What compile options are you using and which specific compiler version?

If you need to report it, use https://premier.intel.com/

[bradmull]

Here are my COMPILE options:

/nologo /Zi /Od /gen-interfaces /debug-parameters:all /warn:declarations /warn:unused /warn:interfaces

/module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /check:bounds /RTCu /libs:qwin /dbglibs /c

As for the compiler version, how do I find that out? The only thing I can get right now is "IA-32"

I wonder if the GENand WARN interface options could be triggering this.

[bradmull]

I turned off some of the DIAGNOSTIC options, and the problem went away.

Still seems weird that the subroutine NAME would trigger this problem, though - -

[Steven_L_Intel1]

If it involved generated interface checking, that would very much involve the name. If there was an existing generated .mod file for the name, it might create a conflict.

The easiest way to see the compiler version in 9.1 is to do Start > Programs > Intel Software Development Tools > Intel Fortran Compiler 9.1 > Build Environment and look at the first line of the console window.

[bradmull]

I have the START PAGE on Visual Studio up, but there is no choice "PROGRAMS", and under "tools" I have "Options," but I don't see "Intel Fortran Compiler 9.1"

I see"environment" but I don't see "build environment." My menu choices don't correspond to what you're saying.

I don't understand why there was a previously existing.MOD filewhen it was a brand new subroutine I was adding. No previous file by that name, nor any suchentry point.

Even if it were there before, why wouldn't it just overwrite it?

I restored the options I had before, and now it aborts like before, but in a completely different place. No error messages, just a bunch of warnings.

I then tried a CLEAN, followed by a REBUILD, that worked without any errors. So I guess I have to resort to that from now on, though it's time-consuming.

[Steven_L_Intel1]

I meant Start on your Windows desktop.

Cleaning the solution should only be needed the once, unless something creates a bad or corrupted generated module. As I said earlier, this sounds vaguely familiar and it's very likely that we've fixed the bug already.