Intel® Fortran Compiler for Linux* and Mac OS X*

Compiler bug - stream formatted nonadvancing read


I'd like to report a possible bug in Fortran Intel Compiler - it seems it doesn't read correctly data in nonadvancing way on a file opened as a formatted stream.

Please consider the attached program. It generates file with lines "This_is_line_no_XXXX" where XXXX is the number of the line. It then reads it back as stream formatted nonadvancing. With the default blocksize, the first problem exhibits at line 780 which is around 16384 bytes which could be the default blocksize, the output is as follows:

Feature request: Compiler Version Notes

ifort currently generates comment sections in compiler-generated assembler files (built with "-s") that contain a lot of useful information, such as the compiler version and flags used when compiling; however, since these are comments, they do not find their way into the compiled object files.  Would it be possible to have the compiler mimic gcc's behavior and put this information instead in a ".note" section?  GCC uses ".note.GNU-stack" and places just the compiler version, which alone would be nice, but if there are no restrictions on data length, the compile flags would be nice too.  Or

Cycling block-do-construct with inner block-construct

Hi, I'm wondering if there exists a way (other than branching) for exiting or cycling within a inner block in a do block:

do i=1,10
        integer :: k
        if (...) then
            cycle !not possible
        end if
    end block
end do

More general, the question is, if its possible to terminate the execution of a block-construct without using IF/GOTO? I've looked into the standard but I've found no other possibilities...

Use of unlimited polymorphic object and performance question

I'm still learning how to do OO programing and have several doubts.  Although this could be a question better suited for a FORTRAN forum, I want to ask you about the performance of an executable created with polymorphic entities.

The attached code (tes_polymorphism.f90)  works.  It defines a upoly entity called "electron", which can be described (actually, the velocity distribution function) either by Maxwell-Boltzmann or by kappa (non-additive) statistics.

Possible bug in ifort version 14.0.1


I have encountered some strange behaviour in the ifort version 14.0.1 by deliberately forcing an overflow of a 32 bit integer on my computer. Here is how to reproduce it

% ifort -v
ifort version 14.0.1

% cat main.f90
program main
  implicit none
  integer i

  do while(.true.)
     if (i.le.0) then
     end if
  end do
  print *,'i',i
end program main

% ifort -O0 -std03 -o main main.f90
% ./main
 i -2147483648

Feature (or change?) request: "j1" and "j11"

It appears as though with some of the newer compilers (I recently jumped from 12.0.4 to 15.0.2), "j1" and "j11" are now reserved symbols.  I'm getting very obscure errors from the linker about dwarf version 3, though the true error is just above this in that "j1" is defined in real/j1.c (which is also a function name in my program).  If this is an internal Fortran function that is not designed to be called externally, maybe it would be best to do some name mangling on it or put one of the usual "for__" prefixes on it?  I can also see people using such short names as global variables when li

old 32-bit compiler vs 64-bit compiler trouble - array values

Hello, A program is seg faulting due to Common array values not being constant through subroutines.  This did not occur on our old 32-bit machine, but it has appeared in our new 64-bit machine.  

Old machine is running Intel(R) Fortran Compiler for 32-bit applications, Version 8.1.  New machine is running Intel(R) Fortran 64 Compiler XE for applications running on Intel(R) 64, Version

The same include files which initialize the array are found in both .f but the values are not constant though the program in the new machine like the old one.

订阅 Intel® Fortran Compiler for Linux* and Mac OS X*