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

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

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?


6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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.

Retired 12/31/2016

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


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.

Retired 12/31/2016

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,


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.

Retired 12/31/2016

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

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today