I do not know whether the problem I encountered belongs here (compiler error) or to MKL forum (call to MKL solvers), so I apologize if it does not belong here.

I am compiling the same code in VS 2010 with IPS XE 2017 Update 2 and in VS 2015 with IPS XE 2016 Update 4. I am using Debug-x64 configuration with following compiler options:

/nologo /debug:full /MP /Od /I"%MKLROOT%" /I"\include" /fixed /extend_source:132 /Qopenmp /fpscomp:general /debug-parameters:all /warn:declarations /warn:truncated_source /warn:noalignments /warn:interfaces /assume:byterecl /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc140.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /check:arg_temp_created /check:stack /libs:dll /threads /dbglibs /Qmkl:parallel /c

While everything is OK in IPS 2016 U4, I am getting internal compiler error in IPS 2017 U2, no matter if I use x64 or Win32 platform. The error message is:

fortcom: Fatal: There has been an internal compiler error (C0000005).
ifort: error #10298: problem during post processing of parallel object compilation

By commenting out lines of the corresponding source code file, I found out that calls to dgetrs and dgerfs, see lines 272 and 281 of the source file solver_matrix_general.for in the solution I am going to attach later, are both causing the same ICE. This is how the corresponding code snippet looks like:

      subroutine solveLinearSystemGeneral ( )

      integer(4) :: info


      ! Backup matrix A and B
      call backupLinearSystemMatrixAndRHS ( )

      ! LU factorization - matrix A is overwritten by LU factorization
      call dgetrf( nDimension, nDimension, Amat, nDimension, iPivot, info )

      ! Solution - matrix B of right hand sides is overwritten by solution to Amat*Xmat = Bmat
      call dgetrs( 'N', nDimension, numberOfRHS, Amat, nDimension, iPivot, Bmat, nDimension, info )

      ! Solution evaluation (copy to its own variable)
      call evaluateLinearSystemSolution ( )

      ! Solution refinement
      call dgerfs( 'N', nDimension, numberOfRHS, AmatOrig, nDimension, Amat, nDimension,
     +             iPivot, BmatOrig, nDimension, Xmat, nDimension,
     +             ferr, berr, work, iWork, info )

      return
      end subroutine solveLinearSystemGeneral

What am I doing wrong?

My old project goes wrong with Intel® Parallel Studio XE 2017 Update 4 again.

In sample code, subroutine foo crash on debug mode. (Stack overflow)

If change integer :: a(N) to a(1000000), the code goes well.

Similar things was happened with character parameter argument also.

    program Console2

        call foo(1000000)

    end program Console2

    subroutine foo(N)

    implicit none

    integer :: N

        integer:: a(N)

    end subroutine

When stack overflow occuring, increasing stack reserve size is helpful while commit size isn't.

Would experts explain the difference bewteen reserve and commit size, and when to increase reserve size and when to increase commit size?

Thanks!

I am converting a QW program from CVF to IVF with VS2013.  When I try to build, I receive several error messages I do not understand. Please see blow. Can someone give me a tip?

       Build Log

         Build started: Project: CaFeMS1_, Configuration: Debug|Win32

       Output

       
Compiling with Intel(R) Visual Fortran Compiler XE 14.0.4.237 [IA-32]...
ifort /nologo /debug:full /Od /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc120.pdb" /traceback /check:bounds /libs:qwin /dbglibs /winapp /c /Qvc12 /Qlocation,link,"C:\Program Files (x86)\VC\\bin""C:\CALC\CaFeMS\Moduldata.f90"
ifort /nologo /debug:full /Od /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc120.pdb" /traceback /check:bounds /libs:qwin /dbglibs /winapp /c /Qvc12 /Qlocation,link,"C:\Program Files (x86)\VC\\bin""C:\CALC\CaFeMS\Fortran_WinPrint_Direct.f90"
ifort /nologo /debug:full /Od /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc120.pdb" /traceback /check:bounds /libs:qwin /dbglibs /winapp /c /Qvc12 /Qlocation,link,"C:\Program Files (x86)\VC\\bin""C:\CALC\CaFeMS\TVRR46_E.for"
C:\CALC\CaFeMS\TVRR46_E.for(34): remark #6375: Because of COMMON, the alignment of object is inconsistent with its type - potential performance impact   [TXTFONT]
 INTEGER TXTFONT,LMAX

.

ifort /nologo /debug:full /Od /Qsave /iface:cvf /module:"Debug/" /object:"Debug/" /Fd"Debug\vc120.pdb" /traceback /check:bounds /libs:qwin /dbglibs /winapp /c /Qvc12 /Qlocation,link,"C:\Program Files (x86)\VC\\bin""C:\CALC\CaFeMS\Main_elast6b.f90"
Linking...
Link /OUT:"Debug/CaFeMS1-IVF.exe" /INCREMENTAL:NO /NOLOGO /NODEFAULTLIB:"dfconsol.lib" /MANIFEST /MANIFESTFILE:"C:\CALC\CaFeMS\Debug\CaFeMS1-IVF.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"Debug/CaFeMS1.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"WinMainCRTStartup" /IMPLIB:"C:\CALC\CaFeMS\Debug\CaFeMS1-IVF.lib" kernel32.lib /MACHINE:I386 "Debug/Moduldata.obj""Debug/Fortran_WinPrint_Direct.obj""Debug/TVRR46_E.obj""Debug/Plotgraph.obj""Debug/Getopenfilename.obj""Debug/PcgrafCVF_old.obj""Debug/FreqSweep.obj""Debug/EDITASSEMBLY.obj""Debug/MOVEMENTS.obj""Debug/Dialogs_E6.obj""Debug/Mich.obj""Debug/Elasub6.obj""Debug/CalcNatFreq.obj""Debug/DBASE_Operations.obj""Debug/messageboxes.obj""Debug/SectionData.obj""Debug/Editdata.obj""Debug/ASCIIDBASE.obj""Debug/Main_elast6b.obj""Debug/Resource1.res""Debug/ELAST6.res""C:\DVFORTRAN\PCLIBDF\Release\PCLIBDF_.lib"
Link: executing 'link'
LIBCMT.lib(invarg.obj) : error LNK2005: "void __cdecl _invalid_parameter(unsigned short const *,unsigned short const *,unsigned short const *,unsigned int,unsigned int)" (?_invalid_parameter@@YAXPBG00II@Z) already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: "void __cdecl _invoke_watson(unsigned short const *,unsigned short const *,unsigned short const *,unsigned int,unsigned int)" (?_invoke_watson@@YAXPBG00II@Z) already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __call_reportfault already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __get_invalid_parameter_handler already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __initp_misc_invarg already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __invalid_parameter already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __invoke_watson already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: __set_invalid_parameter_handler already defined in LIBCMTD.lib(invarg.obj)
LIBCMT.lib(invarg.obj) : error LNK2005: ___pInvalidArgHandler already defined in LIBCMTD.lib(invarg.obj)
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
FreqSweep.obj : error LNK2019: unresolved external symbol _DLSACG@24 referenced in function _FREQSWEEP
Debug/CaFeMS1-IVF.exe : fatal error LNK1120: 1 unresolved externals

CaFeMS1_ - 11 error(s), 21 warning(s)

Ladies and gentlemen, 

I am an absolute beginner at coding. I have to use user subroutines on ABAQUS 6.14-5, and it requires Visual Studio and Intel Fortran Compiler (IFORT). I have found that the only free option to get this is to install Intel System Studio 2017 (free for students), which has to include Fortran compiler as well. I installed Visual Studio 2013, then I installed System Studio 2017, and everything has integrated fine, except there is no Fortran compiler whatsoever. Therefore, I cannot create Fortran projects in VS2013, command line does not recognize the IFORT command, and system variables have no traces of the IFORT as well. Of course, I could download some third-party Fortran compilers, such as FORCE 2.0, Silverfrost F95, etc, but I have no idea how to make them compatible with ABAQUS. 

So, what do I do? Any pieces of advice will be greatly appreciated.   

Ladies and gentlemen, 

I am an absolute beginner at coding. I have to use user subroutines on ABAQUS 6.14-5, and it requires Visual Studio and Intel Fortran Compiler (IFORT). I have found that the only free option to get this is to install Intel System Studio 2017 (free for students), which has to include Fortran compiler as well. I installed Visual Studio 2013, then I installed System Studio 2017, and everything has integrated fine, except there is no Fortran compiler whatsoever. Therefore, I cannot create Fortran projects in VS2013, command line does not recognize the IFORT command, and system variables have no traces of the IFORT as well. Of course, I could download some third-party Fortran compilers, such as FORCE 2.0, Silverfrost F95, etc, but I have no idea how to make them compatible with ABAQUS. 

So, what do I do? Any pieces of advice will be greatly appreciated.   

Hi. Since I am doing some fundamental calculation, this problem came up, as:

! This is good.
integer(8), parameter :: max_int64 = int(16#8000000000000000, kind = 8)
write(*,*) max_int64

! This is bad.
write(*,*) int(16#8000000000000000, kind = 8)

The upper case gives an correct output of ‭9151314442816847872‬ but the lower one prints only 0. why is that? Thanks for any help.

Colleagues,

I installed PS 2018, interfacing with VS 2015. What happened to the Fortran documentation?  It is no longer available via the F1 key -- a window appears saying I have to download it. I followed the link to the program download page in the registration center but can't find the documentation.

I've spent most of this afternoon trying to install the latest Parallel Studio 2018 product on a Windows 7 PC with VS 2015 & PS2017 Update 4 already installed.

Before the installation attempt the VS 2015 & Parallel Studio 2017 Update 4 were working fine.

My first attempt at the installation failed at some point and after lots of rollback messages informed me of an error. The message wasn't very helpful so I gave up on that version. Unfortunately this attempted installation caused VS to lose it's fortran integration so I could no longer use the previous 2017.

I tried repairing the PS 2017 but this didn't work so I then uninstalled it and then installed PS2018. This time there was no error and the integration at first appeared to be OK but my euphoria was short lived when I tried to set the syntax highlighting in the text editors. All the Fortran options are missing from the list in the Fonts and Colors (sic)->Text Editor dialog box so I only have what appears to be a 1960's monochrome text editor.

Does anyone know a quick fix for this, other than uninstalling PS2018 and reinstalling PS2017 (which may or may not work anyway)?

The install instructions don't mention windows 10.  They do say the Windows SDK8.1 is required.  Is the SDK 10.0 required on Windows 10? 

Hello,

I have a Fortran Code and I built a solution and an executable file with visual studio. The code works fine on my personal computer. I have to run the .exe file on another computer. I transferred the entire folder but when I run the program it can not find the input file.

I think that there is a problem with path because the error is:   forrtl : severe (29) file not found unit 10

Could anyone help me?

Hello!

I'm running into a issue within a code that works fine in 2017 but crashes in 2018.

Used Versions:

• Microsoft Visual Studio Professional 2015 Version 14.0.25431.01 Update 3
• Intel(R) Visual Fortran Compiler 17.0.4.210 [Intel(R) 64] and
• Intel(R) Visual Fortran Compiler 18.0.0.124 [Intel(R) 64]

sample-code:

  program Console1
  implicit none

  type tO
    integer :: aNumber
    real, allocatable, dimension(:) :: arr
  end type
  type (tO), allocatable, dimension(:) :: arTOs
  type (tO) :: oTo
  integer i,j,m

  m=3
  allocate(arTOs(m))
  do i=1,size(arTOs)
    write(*,'(a,i1)') 'allocating, loop:',i
    oTo=arTOs(i)
    oTo%aNumber=i+m
    if (allocated(oTo%arr)) then
      write(*,'(a)') 'oTo%arr IS already allocated'
    endif
    allocate(oTo%arr(oTo%aNumber))
    do j=1,size(oTo%arr)
      oTo%arr(j)=real(i+j)
    enddo
    arTOs(i)=oTo
  enddo
  CONTINUE
  end program Console1

When I run this code with the 18.0.0.124 Compiler, the first loop works as expected, but in the second loop Exception:

forrtl: severe (151): allocatable array is already allocated was thrown.

And the interesting past is that the line above 'allocated(oTo%arr)' is still false.

And, as mentioned above, this code works fine with 17.0.4.210.

Any Hints what I am doing wrong here?

Best Regards

mirko

Plaxis 2D allows user-definition of material models using fortran. Their documentation recommends that the fortran project be compiled into a dll with a specific name (usrmod.dll) and also provides access to subroutines that can do additional work (Appendix C of their material model manual). I'm guessing the user has no access to the source code of these subroutines and that the user must access them using a dll.

One compile line they recommend is as follows:

• ifort /winapp USRMOD.FOR DFUsrLib.lib /dll

I'm guessing that DFUsrLib.lib is they library where the common functions are contained. However I can't find it anywhere in the root directory of the program and thus have no idea what or where it is. 

Has anyone else used this part of Plaxis2D before? For more general fortran users out there, does the above compile line look like it expects USRMOD.FOR to call some common subroutines in DFUsrLib.lib??

Thanks for your help and look forward to your answers!

I'm trying to compile a dynamic library in VS2010. I've already tried compiling it with ifort using multiple compile lines for lowest level source files to highest level. Everything compiled fine but I did get one warning at the end:

LINK: warning LNK4098: defaultlib 'LIBCMT' conflicts with the use of other libs; use /NODEFAULTLIB:library

Nevertheless I think that the dll has compiled OK.

Next I tried to move all the source files to visual studio. I enabled preprocessing because my source files do contain some directives. Unfortunately when I try to build the solution I get an error for one of the subroutines at an intermediate-level source files:

Error 1 error #6633: The type of the actual argument differs from the type of the dummy argument.   [1.]

After which it aborts the compilation. Please note that I simply imported all my source files under the Source Files directory in my VS2010 project, enabled /fpp and pressed "Build". Does the user also need to specify the compile order in Visual Studio or is this handled automatically? Why am I getting a type error in VS when the exact same source files compile just fine in ifort? Thanks for your help.

Dear all,

I installed PSXE 2018 and rebuilt one of my major projects in release (i.e. with optimizations, compiler options see below). I'm not happy to get an ICE in one 2000 lines routine, which builds and runs fine with all PSXE 2017 compilers and produces reasonable results. Debug compilation runs fine with PSXE 2018.

My goal is to derive a (simple) reproducer. I hate to be so unspecific here, sorry. Is there a chance to get an information in which part/line of code the ICE is triggered exactly. Any fortcom logs available?

I know, I could commit the whole code to OSC, but I don't like to do that by different reasons.

Any hints on tracking down the ICE are welcome.

PSXE 2018 initial release

    Compiling with Intel(R) Visual Fortran Compiler 18.0.0.124 [Intel(R) 64]...
ifort /nologo /MP /O3 /Qparallel /assume:buffered_io /Qopt-matmul /fpp /Qopenmp /warn:all /real_size:64 /Qinit:snan /Qinit:arrays /fp:source /Qfp-speculation=safe /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc140.pdb" /check:bounds /libs:static /threads /c /Qimf-precision:high /QaxCORE-AVX512 /nostandard-realloc-lhs /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\amd64" /Qm64 "D:\...\mod_calc_section_2D_BECAS.f90"

In the release notes, it says

"Offline core documentation is removed from the Intel® Parallel Studio XE installed image. The core documentation for the components of Intel® Parallel Studio XE are available at the Intel® Software Documentation Library for viewing online. You can also download an offline version of the documentation from the Intel® Software Development Products Registration Center: Product List > Intel® Parallel Studio XE Documentation."

But I don't see such a product in my product list. I am asking, because the F1 sensitive help in VS2013 does nothing in my installation, and I am hoping to fix it by downloading the documentation.

Thank you for any pointers,

UM

-------------

Edit: Didn't see that this was posted already... No need to reply.

I suspect this is perhaps a VS bug and originally asked this on StackOverflow, but the only response I have had suggests it might be Fortran related.  On the off-chance it is (or the better chance that someone here has encountered something similar) here it is:

I'm currently moving a series of VS2005 32 bit solutions into VS2015 (update 3) for 64 bit implementation. The solution in question consists of 3 VB projects, 14 Fortran projects and one Assembler project.

When I build this solution, all projects are processed as expected. However, if I attempt to individually build any of the first three projects listed in the Solution Explorer pane, a different project is built.

This only happens for the first three projects in the list (all Fortran projects). The project that is actually built is always the same one. It is further down the Solution Explorer list and also a Fortran project. When I individually build any of the other projects in the solution, they are all built as expected.

I have been unable to find any link between the affected projects and the project which is actually being built and am at a loss understanding how to correct this.

The immediate work-around was to rebuild the entire solution whenever I need to rebuild one of the affected projects, however this requires somewhat more processing (and delay) than ideal.   I have subsequently found that this happens only if using the VS main menu (Build+[Re]Build ...project...).  The projects build correctly if using the Solution Explorer context menu "Project Only+Build Only ..."

Has anyone else encountered such a problem, and is there a simple fix?

Thanks, Randy

I have noticed a change in behaviour in my application when I recompiled used the latest version (PS 2018).

I have lots of user defined data types that have within them allocatable components and I often create a "NULL" entity that is used to initialise the other instances used throughout the program by the following statement :

a = a_NULL 

where a is the instance being initialised and a_NULL is an instance of the data structure with all components uninitialized.

The follow test example shows the change between compilers.

program test
 
implicit none
 
! Simple data structure with allocatble component
type dtyp
  integer             :: id = 0   ! This does not seem to work
  integer,allocatable :: array(:)
endtype

! Create instances
type(DTYP)   :: a0,a1
character(1) :: wt
integer      :: istat
 
! Initialise (doesn't use the initialisation in type definition
a1%id = 1
a0%id = 0

! Allocate array in a1
allocate(a1%array(10),stat=istat)
if(istat.eq.0) then
 
  ! Initialise array
  a1%array = 0
 
! This should deallocate a%array
  a1 = a0

! Shows as deallocated in debugger
 
  ! Try reallocation 
  allocate(a1%array(10),stat=istat)
  if(istat.eq.0) then
    a1%array = 0
  else
  ! Fails with status 151 (Already allocated)
    write(*,'(a)') 'Reallocation failed!'
  endif

else
 
  write(*,'(a)') 'Allocation failed!'
 
endif

write(*,'(a)') 'Press any key to exit'
read(*,'(a)') wt

end  

In PS 2017 the test runs to the end without any errors, however in PS 2018 the test fails to allocate the a%array component the second time around as it still thinks it is already allocated. Interestingly the debugger shows a%array to not be allocated.

Is this something I am doing wrong that I have got away with in the past or is it a potential bug in the compiler?

If it is the later I will have to revert back to PS2017 until it is fixed.

On a more general note, why doesn't the initialisation of id = 0 in the definition work? The debugger shows garbage values until I explicitly assign 0. This is not dependent upon which compiler I use.

I am interested in wielding the differential code coverage functionality in ifort. The documentation appears to address this thoroughly but I have failed to apply it to my reduced example. Heres what I have:

program test
	integer :: userinput
	print *, 'enter 1 or 0'
	read *, userinput

	if (userinput.eq.1) then
		print *, 'You have entered ONE'
	else
		print *, 'You have not entered ONE'
	end if
end program test

A simple program that can take one of two paths. If the user enters 1 then it goes into the if ... then statement, if the user enters 0 then it goes into the else... statement.

The goal of differential code coverage (as stated by intel docs) is as follows:

compare the profiles from two runs of an application: a reference run and a new run identifying the code that is covered by the new run but not covered by the reference run

So if we take a reference run where the user enters 0 and a new run where the user enters 1, the differential code coverage should be able to identify that the new run covers the if statement whereas the reference run does not (reference run goes into the else statement). I followed the docs as closely as possible. The source file is called test.f90. Here are the compile lines i'm using:

ifort test.f90 /Qcov-gen

Which generates PGOPTI.SPI, PGOPTI, test.exe and test.obj. I then run the executable and enter 0, I get the correct message "You have not entered ONE". This causes a .dyn file to be created (due to the Qcov-gen option). I then do the following:

profmerge

Which generates additional files pgopti.dpi, pgopti.dpi.lock. At this point I think I have enough material to generate my reference data. This I attempt using the following:

codecov -prj Project_Name -dpi pgopti.dpi -ref pgopti.dpi

Which generates html files similar to the ones displayed when code coverage is run in Visual Studio for Intel Fortran. I also get 100% code coverage which seems incorrect. The docs then show this command:

codecov -prj Project_Name -spi pgopti.spi -dpi pgopti.dpi

Which does not appear to provide an opportunity for a new run. 

Could someone please explain how to do a simple differential code coverage on this particular example? I'm eventually trying to extrapolate this to a larger project but I'm trying to take baby steps to get there.

Thanks 

Is there any possibility to determine whether the redistributables are already installed before running the .msi installer file?   I am using INNO setup to install a console application.

This question went unanswered in an earlier thread.  So I am asking it again in hopes someone can provide some help.