Modern Fortran is not working in VS Code

Hi every body,
I am new here, and I was trying to run a simple Fortran code in VS Code after installing Modern Fortran , but I could not see the triangular button to run it, so I believe that some configurations are missing. Could you please help me in that?


Below are some information that could help:

>python --version
Python 3.11.1
>fortls --version
2.13.0

In settings.json I have only

{
"C:\\Users\\a\\AppData\\Local\\Programs\\Python\\Python311\\Scripts\\fortls.exe",
}

Following the post:

Following the post:

By syntax, the source code is valid.* Can you

  • save the source code as a file accessible to you, in a folder where you have full read/write access
  • check if you have a working installation of a compiler on board. In case for gfortran, for example run gfortran -v from the command line/the shell provided by cmd.exe. The command should display the version of the compiler. Something similar like
$ gfortran --version
GNU Fortran (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now check if manual compilation/execution is possible. For this

  • enter the folder with your source code; it may require a few cd commands to change into the corresponding directory from the shell. Then issue gfortran testhello.f90 -o executable as new command to the shell. If successful, this creates a new binary file, executable. If successful, this executable
  • will run by the command to the CLI/shell ./executable.

* Note, print *, 'hello World' is a bit old, write (*,*) 'hello world´ is more contemporary.

1 Like

I think both date back to f77 when character variables were introduced. For some reason, which I have long forgotten, I have always tended to avoid print in my code, but I have perhaps overused the write(*,*) version when I should have been using an explicit unit and/or an explicit format. If it weren’t for that stupid space that it adds to the output, I would probably have overused it even more.

[Edit] Now that I’ve had a day to think about it, the reason I used to avoid print in favor of write is that print and punch were not part of the standard fortran language prior to f77 when I started programming. They were common extensions that were widely supported by various vendors, but I think they had some minor differences such as when commas were required. I found that I could avoid most of those problems by simply using write, which was standard. The print statement would either send output directly to a printer, or it would spool it to a tape with other print jobs that would be printed at some later time. Similarly, punch would punch holes in a card deck, either in real time as the job ran or it would spool them for some later time. These were the days of central computer centers, before remote terminals and remote printers were available, and before office or personal computers of any kind. With f77, the print statement became standard, but punch did not (I think that is right). Of course one could still punch cards with write statements to the correct (usually preconnected) output unit with most computers, so one only had to replace those statements. I think when I did this with old legacy codes, I replaced both print and punch with write statements because of the extra flexibility it provided. I remember also punching paper tape with fortran write statements. Of course, the character variable aspect was only possible with f77 and later, before that one would punch hollerith encoded characters stored in integer variables.

2 Likes

No such thing.

PRINT statement is a supported feature in the language.

The standard states, “The PRINT statement specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE statement and is the same as the unit identified by the value of the named constant OUTPUT_UNIT of the intrinsic module ISO_FORTRAN_ENV (16.10.2.24).”

Additionally with FORMAT in a case like so

   use, intrinsic :: iso_fortran_env, only : output_unit
   character(len=*), parameter :: fmtg = "(*(g0:,1x))"
   integer, allocatable :: x(:)
   x = [ 1, 2, 3 ]
   print fmtg, x
   write(*,fmtg) x
   write(output_unit,fmtg) x
end

is for all practical purposes equivalent.

C:\temp>gfortran p.f90 -o p.exe

C:\temp>p.exe
1 2 3
1 2 3
1 2 3
PS C:\MinGW> gfortran -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\bin\gfortran.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/9.2.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-9.2.0/configure --build=x86_64-pc-linux-gnu --host=mingw32 --target=mingw32 --disable-win32-registry --with-arch=i586 --with-tune=generic --enable-static --enable-shared --enable-threads --enable-languages=c,c++,objc,obj-c++,fortran,ada --with-dwarf2 --disable-sjlj-exceptions --enable-version-specific-runtime-libs --enable-libgomp --disable-libvtv --with-libiconv-prefix=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --disable-build-format-warnings --prefix=/mingw --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/mingw --with-isl=/mingw --enable-nls --with-pkgversion='MinGW.org GCC Build-2'
Thread model: win32
gcc version 9.2.0 (MinGW.org GCC Build-2)

Yes, it works manually and generate the executable
Do you have any suggestions to solve the problem in VS Code?

For now this is only available in the pre-release version of the extension (amongst other bug fixes and features)

1 Like

Thanks for your comment and I followed!
However, I could not see the generated executable but rather an o extension file? Do you know where I can see the executable?

Of course print isn’t dead, out-of standard. More contemporary only in the sense of the syntax of write opens the more frequently seen approach to direct the output to to the screen (unit) for now, or into an unit of a permanent record for later (as in «now the program now works well enough (here) on its own»).

1 Like

The answer to this question is no, simply because I do not use VS Code.

1 Like

Thanks for your comment. What is the alternative that you would like to work with?