Problem with the CHARACTER([KIND=] n) statement

[Amalia_B_]

I'm using MS Visual Studio 2010 with Intel Visual Fortran Composer XE 2011 Update 6 Integration for Microsoft Visual Studio* 2010, 12.1.3514.2010, on a 32-bit XP machine. This simple program:

_______________
program mtest

character dumst(len=80)

write(*,*) 'Hello World'

call short_routine

end program mtest

!******************************

subroutine short_routine

character dumst2(len=80)

write(*,*) 'Hello World II'

end subroutine short_routine
__________________________

gives methe following error:

catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for .......

Yet when I comment out the character declaration for DUMST2 in the subroutine, it compiles fine. I've used "character dumst2(kind=80)" also and it does the same thing - that is, produces the catastrophic error. The only thing that works is "character dumst2*80". Funny that the compiler acceptsthe "character dumst(len=80)" in the main program.

Is this a known bug?

AEB

[Steven_L_Intel1]

I can't reproduce the problem. Can you show me the full command line used? If you're building in Visual Studio, please go to the Fortran > Command Line property page, copy the command line options shown there and paste them here.

Your post seems to confuse KIND= and LEN=. You seem to be using LEN=, but you talk about KIND=80. Intel Fortran supports only KIND=1 for CHARACTER.

[Amalia_B_]

Yes, I guess I was just following the example of "character(len=xx)" in the samples provided in the Fortran reference help.

Anyway, here's the command line used:

/nologo /debug:full /Od /warn:interfaces /module:"Debug\" /object:"Debug\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:qwin /dbglibs /c

Amalia

[Steven_L_Intel1]

Thanks - I can now reproduce this. /debug:full seems to be the culprit - if you remove this, it compiles. It also compiles if you use character(80) instead of character(len=80), though why this should make a difference is beyond me. I will report this to the developers - thanks. Issue ID is DPD200176148.

[Steven_L_Intel1]

Evidently I had not had enough coffee when I first looked at this.

The syntax you cite in the thread title, CHARACTER(KIND=) or CHARACTER(LEN=) is legal. However,

CHARACTER dunst(LEN=80)

is not legal syntax. The only way you are allowed to specify the length after the variable name is with the *n syntax, such as dunst*80.

Nevertheless, there is a compiler bug here - it should not have allowed (LEN=80) or (KIND=80) following the variable name. If you correct the syntax, the program will compile.

[Steven_L_Intel1]

We've fixed the compiler to give a reasonable error message for this incorrect syntax. The fix will be in a future release.