Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
27778 Discussions

Deprecated /extend_source available in VS compiler options

New Contributor I

I am using the compiler option /extend_source:132 in my project. After installing Intel® Fortran Compiler Classic 2021.1.1, I am getting the warning "command line warning #10434: option '/extend_source' use with underscore is deprecated; use '/extend-source' instead". However, options in Fortran -> Language for Fixed Form Line Length only offer /extend_source, with underscore in the name.

There is a workaround to get rid of the warning: to set the Fixed Form Line Length to 72 columns and add the option /extend-source:132 to Fortran -> Command Line -> Additional Options.

0 Kudos
6 Replies
New Contributor I

I have just realized that the workaround has one con - changing the fixed form line length to 72 changes the source code coloring. 

Black Belt

What you see in VS and what you get from the compiler are not necessarily the same. If you install a newer version of the compiler without also updating VS and the Fortran integration in it, the two could be a bit out of step. Similarly, if the Intel compiler developers change the spellings or names of compiler options in a new release, there could be a delay before the Fortran integration of VS is also updated to match. Furthermore, compiler options can be spread over many places (IFORT.CFG, environment variables, VS project/solution files, menu option selections).

As I do most of my compilations using the command line and makefiles, I am not affected by such issues, and I do not rely much on syntax highlighting. What would you have seen and done if, say, you had been using Ifort Compiler Classic 2021.1.1 integrated with VS2017 instead of VS2019?

New Contributor I

I understand. However, I installed the complete package, so I assumed the VS integration will reflect changes in compiler options naming. On the other hand, if I had both PS and oneAPI and wanted to compile my project with PS compiler, not with oneAPI ones, I would run into similar "problems".

Regarding your question about VS 2017, I don't have this version, so I am not able to answer the question.

Finally, I also did compilations using the command line, however, since my project is almost 300 source code files and there are various dependencies between them, I found it easier to use VS which I use also for C++ projects.

Black Belt

I agree that there is a bug in the VS integration regarding /extend_source versus /extend-source, and that the developers should fix this so that either punctuation ('_' or '-') is accepted. 

In the meantime, note that you can specify /extend-source in the Project-Properties:Fortran:Additional Options panel. You can also add the compiler directive


to the top of any source file that needs it, or to an include file that is used by your sources. 

These suggestions, however, will probably not make the syntax highlighting work correctly reflect the source line size limit that you specify.

Honored Contributor II

/warn:truncated_source is also a useful option. I don't see any syntax highlighting for line length I think that is only for fixed form, it is a long time since I used that, it hurts my eyes just to look at it. When in the VS editor the current column number for the cursor point is given at the bottom of the file window anyway so is syntax highlighting that useful in this regard?

Black Belt

I have frequently found that insidious errors were introduced after someone took an old fixed format Fortran 77 (or Fortran IV) program, got it working and established that it passed verification runs. Later, someone else decided to change the names of a few variables or wanted to insert blanks around '=' signs for better appearance, and as a result some lines got stretched beyond column 72.

Being older, I do not wish to burden my weakening eyesight with checking for such errors using syntax highlighting, or any pictorial means, particularly when working with a large body of code.

Instead, one can (i) get rid of pesky tab characters in source files, and (ii) use a short utility that checks for lines that are more than 72 characters long, checks that the spilled part is not part of an inline comment, and prints out the line numbers of the offending lines. Along with IMPLICIT NONE, and utilities such as FTNCHEK/Forcheck, this will catch most of the errors of this nature that we may come across.