Warning # 6009, possible bug?

Warning # 6009, possible bug?

I don't really understand why the compiler is issuing warning #6009 to me.

program inibug

	  implicit none

	  integer ,parameter :: WP = kind(1.0D0)

	  real(WP) ,parameter :: offsets(3) = real([0.0D0 ,10.0D8 ,10.0D9],WP)

	  print*, offsets

	end program

$ ifort --version

	ifort (IFORT) 13.0.2 20130314

	Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.
$ ifort -warn -syntax-only -stand f08 reproducer-ini.f90 

	reproducer-ini.f90(4): warning #6009: Fortran 2008 specifies that an elemental intrinsic function here be of type integer or character and each argument must be an initialization expr of type integer or character .   [REAL]

	  real(WP) ,parameter :: offsets(3) = real([0.0D0 ,10.0D8 ,10.0D9],WP)


To be honest, I'm not that familiar with the changes that were made in f03/f08 to initialization expressions, but I don't understand why it says it needs to be an integer or character. Is this a bug?

The goal of initializing this array this way is to be able to set the working floating point precision globally throughout the code using a constant (WP) while still being able to initialize this constant array, offsets to values reasonably close to the floating point values I am after, then perform any type conversion to increase or decrease the precision. I actually realized that the best way to do this was via E notation and literal real constants ([0.0_WP ,10.0E8_WP ,10.0E9_WP]) and then I don't need to call real(), but either way, I don't understand why I am getting this warning.

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

The warning is a bug.  The restriction was there for f95, lifted for f2003.  My recollection is that this usage was allowed as an extension in initialization in f95 versions of ifort, possibly leading to wrong code (for f95) being generated by the compiler unfortunately a virus wiped out my old ifort installation last year and I have no idea how to restore it so I can't test this for you.

Yes, it's a bug - I will report it.

Retired 12/31/2016

Intel Fortran compiler accepts a similar syntax in the executable section of code:

   REAL(WP) :: offsets(3)
   offsets = REAL (  [ 0.0, 10.0, 10.0 ], KIND=WP )

I guess the bug is in the initialization section that saw changes in Fortran 2003/2008.

Yes - it has to do with the rules for initialization expressions (now called "constant expressions") that relaxed considerably in F2003. Apparently we did not catch all the places where we needed to test for the requested standards level.  Issue ID is DPD200253798.

Retired 12/31/2016

Thanks Steve.



One place I always struggle is in making sense out of the wordings used in compiler error/warning messages.  I assume this is completely in Intel's domain i.e., the Fortran standards don't dictate anything here and the compiler team has freedom to make this aspect as user-friendly as they desire?

Consider the text of warning #6009:

Fortran 2008 specifies that an elemental intrinsic function here be of type integer or character
and each argument must be an initialization expr of type integer or character . [REAL]

I don't have the slightest clue what this message is trying to convey.  Believe me, I'm trying to read a lot about Fortran and various other programming languages, principles, patterns, and paradigms, much more so than many around me.  So I feel if I struggle so much, I can only imagine the hardship faced by other fellow Fortran coders, especially those who don't have to do business regularly in English but who do use it as the locale setting in Windows.  Is there any effort to review, simplify, and improve as needed the error and warning messages from the compiler?  I think it'll be very useful for customers and offer a competetive advantage for Intel.  Is this something you would consider feeding back to Intel Fortran compiler team?

My 2 cents,


In many cases, including this one, the wording is "adapted" from the standard. I agree with you that this one is somewhat more obscure than others. The developers dislike changing wording of error messages because it tends to mean lots of work updating the test system, but it is done when it is worthwhile.

In the case of this message, I don't think it's worthwhile since it won't be issued by default once the bug is fixed - you'd see it only if you asked for F95 or F90 checking.

You are right, though - the text of the messages is entirely up to us. 

Retired 12/31/2016

I think in general the ifort warning messages are pretty good, however I really like how gfortran cites the chapter/section etc. of the standard. Hunting down the portion of the standard corresponding to this error would be much easier if that information was included.


That variation in terminology for "different sorts of expressions" from standard to standard doesn't help with this specific case either.  (That said I think the current terminology is appropriate.)

I think the only real issue with this diagnostic is the use of the word "here".  If (for F95) that said "...an elemental intrinsic function in an initialization expression be..." that gives a pretty strong clue as to why the compiler has got itself all hot and bothered.

For an internal "lint" like tool I used paragraph/syntax rule or constraint type references back to F2008 in messages.  But this becomes a maintenance headache as soon as you start talking multiple standards.

Regarding chapter citation - we used to do that, but as the standard shifts those go out of date. Our standards warnings have a fixed text and we just plug in the level you asked for.

Retired 12/31/2016

This bug has been fixed for a future release.

Retired 12/31/2016

Leave a Comment

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