Hi,

I have updated the Intel Fortran from 2013 SP1 to 2016 recently and found the I/O speed of 2016 is very slower than 2013. To read a bigger txt file( 3.67G), the program compiled with Intel Fortran 2013 costs about 2 minutes and the one compiled with Intel Fortran 2016 costs about 4 minutes. I have used the same codes and same compiler options. The following are the compiler options:

/nologo /MP /O2 /Ob0 /assume:buffered_io /heap-arrays0 /I"./header/com" /assume:nocc_omp /f77rtl /fpscomp:nolibs /warn:none /Qsave /names:uppercase /iface:cvf /module:"x64\Release64\\" /object:"x64\Release64\\" /Fd"x64\Release64\vc120.pdb" /check:none /libs:dll /threads /c

The option "/assume:buffered_io" has been turned on. Have you any suggestion to fix such problem?

By the way, Intel Fortran 2016 has a memory leak when doing file I/O. It is fixed in 2016 Update 1.It cost me a lot of time to find it. I hope you can provide us the stable version of Intel Fortran compiler.

WARNING: If the code below does not compile immediately, please Ctrl-C fast; otherwise, huge cores are being produced, and you may have to restart your workstation. 

! Code from Figure 19.3 on page 324 of "Fortran 95/2003 explained"

! IFORT 15.0.1 compiles the code, and the program runs fine.

! IFORT 16.0.0 never returns from compilation; Ctrl-C causes
! huge core files to be created

Module list_module
   Implicit None

   Type node
      Integer              :: value = 0
      Class(node), Pointer :: next_node => Null()
   Contains
      Procedure :: pwf
      Generic   :: Write(Formatted) => pwf
   End Type node

Contains

   Recursive Subroutine pwf(dtv, unit, iotype, vlist, iostat, iomsg)
      Class(node), Intent(In)     :: dtv
      Integer, Intent(In)         :: unit
      Character(*), Intent(In)    :: iotype
      Integer, Intent(In)         :: vlist(:)
      Integer, Intent(Out)        :: iostat
      Character(*), Intent(InOut) :: iomsg

      Character(10)                :: pfmt

      Write(unit, fmt = '(i9,/)', iostat = iostat) dtv%value
      If(iostat /= 0) return
      If(Associated(dtv%next_node)) Write(unit, fmt='(dt)', iostat=iostat) dtv%next_node
   End Subroutine pwf

End Module list_module

Program test
   Use list_module
   Implicit None

   Type(node), Target :: first_link = node(42, Null())
   Type(node), Target :: second_link = node(43, Null())
   Type(node), Target :: third_link = node(44, Null())

   first_link%next_node  => second_link
   second_link%next_node => third_link

   Print '(dt)', first_link

End Program test

All,

Trying to bone-up on calling C routines from Fortran in IVF Parallel Studio XE 2015 Composer. I thought the code was fairly simple & straight forward but a persistent error is stumping me...

error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.   [IX] [IY] 

The error is at the call to C_routine - "call C_croutine (ix, iy, icountsin, icountsout)"

I thought everything pertaining to arrays ix & iy was in agreement but...IVF doesn't agree. I'm sure it is something simple.

Here is the code - Thanks in advance, Jeff

***********************************************************************************************

    program Fortran2C

    use, intrinsic :: ISO_C_BINDING
   
     interface
     SUBROUTINE C_croutine(ix, iy, icountsin, icountsout) BIND(C)
        IMPORT ! Use declarations from host

        implicit none
        integer (C_INT), value :: ix
        integer (C_INT), value :: iy
        integer (C_INT), value :: icountsin
        integer (C_INT), value :: icountsout

     end SUBROUTINE C_croutine
   end interface
!    implicit none

    ! Variables
    integer  :: ix(10)
    integer  :: iy(10)
    integer  :: icountsin
    integer  :: icountsout

    ! Body of Fortran2C
    OPEN(25,FILE='Fortran2C.txt',STATUS='UNKNOWN')

    icountsout = 0
    icountsin = 0
    do i=1,10
      ix(i) = i
      iy(i) = i
      icountsin = icountsin + 1
      write(25,*)'itestx/y in = ',i,ix(i),iy(i)
    enddo

    call C_croutine (ix, iy, icountsin, icountsout)

    do i=1,icountsout
      write(25,*)'itestx/y out = ',i,ix(i),iy(i)
    enddo

    end program Fortran2C

void C_croutine (int ix[], int iy[], int icountsin, int icountsout)

{
int    ii;

    icountsout = 0;
    for ( ii = 1; ii < icountsin; ii++ )  {
    ix[ii] = ix[ii]+1;
    iy[ii] = iy[ii]+1;
    icountsout = icountsout+1;
    }

    return;
}

I have some code that calls a passed-in function called YDDZIC inside a loop. For 22 iterations this works fine but on the 23rd it crashes out of the whole program when it hits the END statement of the YDDZIC Function. The table below shows a side-by-side comparison of the local variables on the 22nd (left) and 23rd(right) iterations. The obvious difference here is that BRTS and X_1 are undefined in the 23rd iteration, it is also notable that I5, IBODY0 and IX0 are negative, these are used as array indices.

However when I step through the code (also below) the debugger steps all the way to the END statement before it falls over and I was wondering why it doesn't fail sooner, is it that it actually performs the evaluation when the end statement is reached? That seems unlikely because the debugger needs to determine the intermediate variables values. Any other ideas why it doesn't fall over before reaching the END statement?

      ENTRY YDDZID ( XI )

C     Find the envelope spline bay containing XI.
      I = ISEG2

C     Use the spline coefficients to find area slope at XI.
      I5 = IBODY0 + (I-1)*5
      DX = XI - BODY(I5+1)
      DS =            BODY(I5+3) +
     +     DX*( 2.0 * BODY(I5+4) +
     +     DX*  3.0 * BODY(I5+5))

C     Ward function of X-XI
      DX = X(IX0+1) - XI
      Z  = DX*BR
      W  = (A0 + Z*(A1 + Z*A2)) /
     +     (B0 + Z*(B1 + Z*(B2 + Z*(B3 + Z*B4))))

C     Integrand in W&F linear phi' equation
      YDDZID = W*DS

      RETURN
*     ======>

      END

<Edit> I put the variables in as a table but they just came out as a list so I have attached an image of the variables</edit>

Hello,

The following code raises an internal error with ifort 15.0.2 and 16.0.1:

catastrophic error: **Internal compiler error: segmentation violation signal raised** 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.

program main
!$ use omp_lib
  integer :: a
  a = 42
  !$omp parallel
  !$omp master
  call foo(a)
  !$omp end master
  !$omp end parallel

  contains
subroutine foo(a)
!$ use omp_lib
   integer :: a
  !$omp task depend(in:a)
  write(*,*) '--->',a
  !$omp end task
end subroutine foo

end program

The code compiles if the depend clause is removed. It also compiles if the code in the foo subroutine is inserted directly in the main program body, or, inversely, if the parallel region is created in the foo subroutine.

Thanks,

Theo

ETA: Another compiler error (which may or may not be related to the first one)

I believe I have found another problem with the following code:

program main
!$ use omp_lib
  integer  :: a
  a = 42
  !$omp parallel
  !$omp master
  call foo(a)
  !$omp end master
  !$omp end parallel

  contains
subroutine foo(a)
!$ use omp_lib
   integer, target :: a
   integer, pointer :: p
   p => a
  !$omp task firstprivate(p) depend(in:p)
  write(*,*) '--->',p
  !$omp end task
end subroutine foo

end program

The compiler raises the following error: /tmp/ifort0sm6zA.o:(.data+0xf0): undefined reference to `foo$P$_4.0.2'

Interestingly, the code compiles without problem when the flag -O0 is used, so it looks the error might be due to a too aggressive optimization.

Theo

I have an old quick win program which I am revisiting and found the pressing F1 for Help does not work.

I had the call:

call DlgSetHelp(ChildDlg,MyHelpRoutine) - it did work several years ago

If I include it in my program I get the error:

error LNK2019: unresolved external symbol _DLGSETHELP reference in function _WinMain@16

Is there a workaround so I can get the help working?

Steve:

This comes from VS 2013 -- Latest Intel Fortran - I must be doing something stupid - but I cannot see what it is - debug is turned on

Hi all,

I just discover than the sum intrinsic function use the type of the array ( I guess) to do the sum and therefor if the array is longer than the max value of type. I don't know if that is defined in the standard, is there a solution to this other than custom sum function ?

program sum1
integer(1),dimension(200) :: int1
integer(2),dimension(200000) :: int2

int1=1
int2=1
print *,sum(int1)
print *,sum(int2)
end program

Gives the results  -56   3392.

Thanks for your thoughts on this.

P.

Hi Guys,

I'm new to these forums and I'm looking for some help/advice on fortran subroutines in combination with Abaqus. I noticed there were several posts related to fortran and Abaqus in the past.

In one of the posts it was mentioned to setup a main program to interface with an abaqus subroutine for easy debugging/testing. 

(https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-fo...)

I was wondering if there are people having experience in setting up such a program and if there are any examples. 

My plan would be to create a single element model and run it with abaqus to write the information that abaqus is passing to the subroutine to a file. I would then feed this input to the stand-alone program to "simulate" abaqus calling it after which I can test/debug the subroutine.

I'm interested in VUMAT examples but any other subroutine would probably be similar.

Thanks,

Bas

Hi,

I am trying to create several bitmaps, draw graphs, output text, etc in them and then bitblt them onto the screen. My code follows but it does no work. Any help will be much appreciated.  Brooks V.

In WinMainProc...

   case (WM_CREATE)

   hDC = BeginPaint(hWndMain,lppaint)
   hDCMem1 = CreateCompatibleDC(hDC)
   hBM1 = CreateCompatibleBitMap(hDCMem1,maxx, maxy)
   hTemp = SelectObject(hDCMem1, hBM1)
   hOldPen = SelectObject (hDCMem1,hPen)

   hDCMem2 = CreateCompatibleDC(hDC)
   hBM2 = CreateCompatibleBitMap(hDCMem2,maxx, maxy)
   hTemp = SelectObject(hDCMem2, hBM2)
   hOldPen = SelectObject (hDCMem2,hPen)

   bret = EndPaint(hWndMain,lppaint)

Later in the sequence of things...

   case (WM_PAINT)

   hDC = BeginPaint(hWndMain,lppaint)
   nx =  Rectxy%right - Rectxy%left
   ny = Rectxy%bottom - Rectxy%top
   Select Case (myOption)
     case (1)
        bret = BitBlt (hdc, 0, 0, nx, ny, hBM1, 0, 0, SRCCOPY)
     case (2)
        bret = BitBlt (hdc, 0, 0, nx, ny, hBM2, 0, 0, SRCCOPY)
   End Select
   bret = EndPaint(hWndMain,lppaint)

Then in a button callback

   if (myOpt == 1) Then
      hBM = hBM1
   else
      hBM = hBM2
   end if

   bret = MoveToEx(hBM, x, y, NULL)
   do i = 1, 50
      x = ptx(i)
      y = PtY(i)
      bret = LineTo(hBM, x, y)
   end do

I am trying to compile a fortran code (WRF 3.6.1) with intel 15.0.3

I am calling the compiler, in bashrc, with the following lines:

export LD_LIBRARY_PATH=/share/apps/intel2015/lib/intel64:${LD_LIBRARY_PATH}

source /share/apps/intel2015/impi/5.0.3.048/bin64/mpivars.sh

source /share/apps/intel2015/bin/ifortvars.sh intel64

source /share/apps/intel2015/bin/iccvars.sh intel64

I am getting some errors during compilation with openmpi_v185, the first ones are the following ones:

ifort: command line error: no files specified; for help type "ifort -help"

make[3]: [module_state_description.o] Error 1 (ignored)

ifort: command line error: no files specified; for help type "ifort -help"

make[3]: [module_domain_type.o] Error 1 (ignored)

ifort: command line error: no files specified; for help type "ifort -help"

make[3]: [module_configure.o] Error 1 (ignored)

module_quilt_outbuf_ops.f90(112): error #7002: Error in opening the compiled module file.  Check INCLUDE paths.   [MODULE_STATE_DESCRIPTION]

    USE module_state_description

--------^

Any help will be appreciated.

Thanks in advance

just wonder if there is a way to pick-up integer miss-match (see simple example below) as it might frequnetly appear when porting from Win32 to x64. Any suggestions how I can find such flaws? Useful compiler options, etc..

program test

    integer(4)  i4

    integer(8)  i8

    i8 = 2

    do i = 1,19

        i4= i8   ! here is the miss-match that leads to problems for i>10

        write (*,*) 'i4= ', i4, ';   i8=', i8

        i8 = 10*i8

    enddo

    read(*,*)

end program test

I made a minor refactoring change to a large code project and suddenly, BOOM, tons of link errors. After spending a lot of time trying to debug, I've concluded this is a linker/module problem. I think I've seen the problem discussed online years ago, but I couldn't find any good references.

With a simple, data-only module with no default initializers, linking on Mac OS X fails if the object file for the module is in a static library. Consider two separate source files:

module.f90:

module mod
implicit none

	real(8) :: array(1000)

contains

subroutine Init()
	array(:) = 0
end subroutine

end module

main.f90:

program main
use mod
	array(2) = 1
	print *, array(1:2)
end program

Compiling together works fine:

$ ifort module.f90 main.f90
$ ./a.out
  0.000000000000000E+000   1.00000000000000

Compiling and linking separately also works fine:

$ ifort -c module.f90 main.f90
$ ifort main.o module.o
$ ./a.out
  0.000000000000000E+000   1.00000000000000

But if the module is in a library, BOOM:

$ libtool -static -o libmod.a module.o
$ ifort main.o libmod.a
Undefined symbols for architecture x86_64:
  "_mod_mp_array_", referenced from:
      _MAIN__ in main.o
ld: symbol(s) not found for architecture x86_64

If the module is changed to have a default initializer, (i.e. real(8) :: array(1000) = 0) then linking through a static library works. Similarly, if the main routine is changed to call the module procedure Init(), then linking also works.

It appears that the system linker on Mac OS X ignores any static library objects that won't invoke executable code.

Is there a good way to guard against this problem in the future (other than remembering)?

I have some LAPACK routines (F95 or F77?) in a DLL and write some stubs to cal the LAPACK routines that I call  from C#
I put those stubs in another DLL.
At least, that's the general idea to solve the problem of having to recompile ALL the Fortran many times, when I put everything in one DLL.
I want to build the LAPACK dll only once and develop the stubs separately.
How would I do this calling of the LAPACK routines?

I was pointed to "modules" and to "loadlibrary" which seem to be quite different approaches.

I use VS2015 on win10 and call from c#, which goes well.

I have the following code snippet in many dialogs - and most work and call Help.
When stop the code I find WM_HELP is decimal 83 (HEX 53)
In just a few cases WM_HELP is not working and Help is not being called.
I have added some code to see what key is being pressed and is says decimal 260/261,
HEX 104/105 - key up/key down (not HEX 53).
I'm not sure why in most cases it is working, but in a few it is not. Is there any other setting that is not causing it to work?

Another case where it is not working is from a sub menu - I'm not sure if I should be testing another constant. 

integer*4 function ChamfcProc(hwnd, message, wParam, lParam)
 !**********************************************************
 !MS$ATTRIBUTES STDCALL, ALIAS : '_ChamfcProc@16' :: ChamfcProc

 write (c8,'(i7,A)') message,char(0)
 call display_prompt(c8)

    select case (message)
 case (WM_HELP)
  call help ! help not accessed??
  
    case (WM_INITDIALOG)
  ChamfcProc=1
  return

    case (WM_SHOWWINDOW)
  if (wParam) then
  endif
        ChamfcProc = 1
        return

 case (WM_MOVE)
  lret=GetWindowRect(hWnd,rectW)

 case (WM_MOUSEMOVE)
  call MouseMove (lparam,rectW)

I recently upgraded my development environment  from MSVS 2010 with the Intel Fortran 2013 compiler to MSVS 2015 with the Intel 2016 Fortran compiler and was trying to use some functionality to debug my code that doesn't seem to be working with my new setup. Under the old MSVS 2010 environment, if I wanted to view a watch variable with a different format I could use the format specifiers that were built into Visual Studio. For example, if I wanted to view a real variable as a hex number in the watch window I would type "my_var,x" and the value displayed for my_var would properly display as a hex value. In MSVS 2015, when I type the equivalent string I get a syntax error. The functionality still appears to be present when I search the MSDN forums (Relevant Link: https://msdn.microsoft.com/en-us/library/75w45ekt(v=vs.140).aspx) but I can't seem to get to work in my project. Am I missing something or has this feature been abandoned?

Thanks in advance for any help anyone can provide.

I am very sorry to open this topic again, which has been discussed in this forum many times before. Like here:

https://software.intel.com/de-de/forums/intel-visual-fortran-compiler-for-windows/topic/534732

I am using Visual Studio 2010 Shell with Intel Fortran XE 14.0.2...

This are the Release-Settings:

Runtime Library: Multithreaded

Use Intel Math Kernel Library: Sequential (/Qmkl:sequential)

This are the Debug-Settings:

Runtime Library: Debug Multithreaded (/libs:static /threads /dbglibs)

Use Intel Math Kernel Library: Sequential (/Qmkl:sequential)

Unfortunately the Release-Version is still using dynamic link libraries. I guess it is the fortran runtime library? This can also be seen in my attached figure (1) from the Dependency walker. The Debug-Version (figure 2) is fully static and run on every other maschine without any runtime library installed. What I am doing wrong? Any help is much appreciated. If I do still need the runtime library dynamic linked for the Release-Version, where do I can get a redistributable installer from and how do I find out which version I need for my configuration?

BR,

Matthias

Is there an easy way to use my vfproj file to produce an equivalent command line build? Do I need to make a Make file? A batch file?

There must be a way to get from the IDE to the command line, surely?

I work on mac OS X 10.11 El Capitan and right now, I use intel fortran composer_xe_2015 without problem. I wanted to download the initial release of composer_xe_2016, which I am allowed to use without renewing my Licence. Unfortunately, I face an installation problem and following the advice of Jill from Intel(R) Developer Zone support, I submit this problem here with the hope to get some hints to solve it...

1) I downloaded successfully the m_fcompxe_2016.0.033.dmg archive, expanded it, then it shows a m_fcompxe_2016.0.033 installer.

When I launch the installer, it asks whether I want to open this application coming from internet (to which I answer yes).

Then, unexpectidly the installer immediately shuts off and nothing happens….

2) I tried another alternative. I went in the /Volumes directory where the archive resides and tried to start manually the installer :

sudo ./install.sh

the command fails with the following error message :

./install.sh: line 616:  4329 Segmentation fault: 11  "$pset_engine_binary" --TEMP_FOLDER="$temp_folder" $params $root_nonroot 2> /dev/null

It seems there happens some temporary folder problem that the archive is not able to access...

I disabled Apple System Integrity Protection (stupid locks Apple put in their system...) but this didn't help...

Is this a known problem ? Any hint to solve it ?

Thank's in advance,

Daniel.

I have two cases of calling from C# program A a Fortran subroutine (in a DLL) FBn that itself calls a Fortran subroutine (in that same DLL) FCn.
So: A -> FB1 -> FC1

and the other case:

A -> FB2 -> FC2

FB1 and FB2 each need two DECLs to adjust to the C# calling convention

!DEC$ ATTRIBUTES DLLEXPORT ,STDCALL :: FBn
!DEC$ ATTRIBUTES ALIAS: 'FBn' :: FBn

No problem here. That call works fine. FBn is written by me in F95,
But FB1 calls subroutine FC1 (DSBGVX straight from LAPACK), and FB2 calls FC2 (DPBSVX also LAPACK)

Now I find, that in the case of FB1, FC1 also needs the two !DECL$, but FC2 does not.
I'd say that a call from Fortran to Fortran, you would never need to adjust the calling protocol.
But in one case you do.
Why would that be?
Is there an issue with Fortran versions? or...