Quantcast
Viewing all 3270 articles
Browse latest View live

ICE: ifort-16.0 with -assume realloc-lhs

I recently upgraded to ifort 16.0 from ifort 15.0.3 for OS X and have encountered an ICE and also an unexpected segmentation fault. 

I experience the ICE when I have two derived types. The first is a component of the second. The first has an empty finalization procedure, which seems to cause the ICE. Both types have overloaded operators. 

module subtype
      implicit none

      type, public :: subtype_t

          real :: val

      contains
          final :: destructor
      end type subtype_t


      public operator (*)
      interface operator (*)
        module procedure op
      end interface


contains

      elemental function op(left,right) result(res)
          real,               intent(in)  :: left
          type(subtype_t),    intent(in)  :: right
          type(subtype_t) :: res

          res%val = left * right%val

      end function

      subroutine destructor(self)
          type(subtype_t),    intent(inout)   :: self

      end subroutine

end module

The above subtype_t is a component of a second derived type of similar structure as

module type
      use subtype
      implicit none

      type, public :: type_t

          type(subtype_t),    allocatable :: lvecs(:)

      end type type_t

      public operator (*)
      interface operator (*)
          module procedure op_two
      end interface


contains


     function op_two(left,right) result(res)
         real,               intent(in)  :: left
         type(type_t),       intent(in)  :: right
         type(type_t)    :: res

         res%lvecs = left * right%lvecs

     end function

end module

Trying to compile the above modules with ifort-16.0 -c -assume realloc-lhs produces an ICE. If the finalization procedure is commented out in subtype_t the code compiles without error. ifort-15.0.3 compiles in either case without error.

Assuming the finalization procedure has been commented out and the modules compile, I experience a run-time segmentation fault when testing the multiplication operator with ifort-16.0 using -assume realloc-lhs. 

program main
    use type
    implicit none

    type(type_t)    :: testing, res


    ! Allocate derived type component
    allocate(testing%lvecs(1))

    ! Assign values
    testing%lvecs(1)%val = 1.


    ! Test multiplication operation
    ! Seg-fault with ifort 16.0 using -assume realloc-lhs
    ! Executes without error using ifort 15.0.3
    res = 1. * testing


end program main

Source files are attached.

AttachmentSize
DownloadImage may be NSFW.
Clik here to view.
subtype.f90
1.04 KB
DownloadImage may be NSFW.
Clik here to view.
type.f90
638 bytes
DownloadImage may be NSFW.
Clik here to view.
main.f90
419 bytes

Referencing conditional logic

I have a .f90 file with dozens of subroutines, each of which require:

#ifdef _WINDOWS

#ifdef BITS64
  use apm_mod_Win_x64
#else
  use apm_mod_Win_x86
#endif

#else

#ifdef BITS64
  use apm_mod_Linux_x64
#else
  use apm_mod_Linux_x86
#endif

#endif

 

Is there a way to define this logic once and then just refer to it in each subroutine?

 

 

Using !$omp declare simd in an elemental subroutine

Quite recently (in May), I decided to update some of my codebase to use OpenMP 4.0 and, in particular, try out the "!$omp declare simd" directive. After a few teething troubles documented in a question I asked here, I got it working well and it has been running smoothly ever since. As it's such a short subroutine, I'll reproduce it here for convenience:

elemental subroutine Calculate_Sines(normal_x, normal_y, normal_z, &
                                     rzero_x, rzero_y, rzero_z,    &
                                     es_x, es_y, es_z, sin_theta)

!$omp declare simd(Calculate_Sines) uniform(normal_x, normal_y, normal_z)
    real(kind(1d0)), intent(in) :: normal_x, normal_y, normal_z
    real(kind(1d0)), intent(in) :: rzero_x, rzero_y, rzero_z
    real(kind(1d0)), intent(out) :: es_x, es_y, es_z, sin_theta

    es_x = normal_z * rzero_y - normal_y * rzero_z
    es_y = normal_x * rzero_z - normal_z * rzero_x
    es_z = normal_y * rzero_x - normal_x * rzero_y

    sin_theta = sqrt( es_x**2 + es_y**2 + es_z**2 )

end subroutine Calculate_Sines

However, I've just installed Parallel Studio XE 16.0 and everything has come to a juddering halt. The same piece of code now fails to compile, with the error message:

error #8807: An OpenMP* directive may not appear in a PURE procedure.

I assume that an elemental subroutine is pure by implication. My basic syntax isn't at all original, as it very closely follows an example given in the Intel documentation here, so I can't really figure out what I should do. Is the example in the documentation, which dates from May 2014 no longer valid? Or am I just doing something really dumb?

Is there any option in the intel fortran compiler (ifort) to compile and run the executable automatically after compiling?

I know that it is possible to compile in IVF from CMD by using the ifort command. However, that command only compiles and does not run the executable upon finishing compiling. The .exe needs to be run sequentially by hand.

Is there any automatic option in the ifort driver to compile and run the .exe automatically?

Thanks in advance.

Finalizer: only executed on scallar allocatable object.

In just want to confirm if this is the expected behavior of a finalizer.

In the code below,

module tes_final_mod
implicit none
type :: my_final
   integer :: n
   contains
      final :: destroy
end type my_final
contains
   subroutine destroy(self)
   type(my_final) :: self
   write(*,*), 'Destroy executed!'
   end subroutine destroy
end module tes_final_mod
!=============================
program tes_finalizer
use tes_final_mod
implicit none
type(my_final), allocatable :: a(:), b(:)
type(my_final), allocatable :: c
!
allocate(a(10))
a%n= 1
deallocate(a)
print*, 'a deallocated'
allocate(a(10))
a%n= 3
allocate(b(20))
b(1:10)= a
call move_alloc(b, a)
print*, 'b deallocated'
allocate(c)
c%n= 2
deallocate(c)
print*, 'c deallocated'
call call_final
contains
   subroutine call_final
   type(my_final) :: aa
   print*, 'SUB: Will finalize when returned.'
   return
   end subroutine call_final
end program tes_finalizer

I have the following result, when compiled with ifort Version 15.0.3.187 Build 20150407:

 a deallocated
 b deallocated
 Destroy executed!
 c deallocated
 SUB: Will finalize when returned.
 Destroy executed!

That is, the finalizer only runs when SCALAR allocatable objects are deallocated (object c in the main and aa in the subroutine).  Allocatable arrays are not finalized either by directly killing then with a deallocate (array a, first time) or by the move_alloc (array b).

Is this the expected behavior?

Even stranger, when the very same program is compiled with gfortran, the results are almost the same, with the exception of the last call on the finalizer, when the subroutine is exited.  With gfortran the return statement did not cause the finalizer to run.

Error:#11025 and #10014 in linux

My system is fedora 19 , the version is :

Linux version 3.14.27-100.fc19.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Wed Dec 17 19:36:34 UTC 2014

The ifort is parallel_studio_xe2016 for students, when inpit ''ifort --version'' in the terminal,there is :

ifort (IFORT) 16.0.0 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

 

When compile a file with 'ifort 't.f95'(could be compiled with g95),there is :

ipo: error #11025: Linker command line is badly formed
ifort: error #10014: problem during multi-file optimization compilation (code 1)

If input 'ifot',there is :

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

Then I try to use 't.f90',input 'ifort t.f90 -o a.e',there is :

fortcom: Severe: No such file or directory

... file is 'daalvars.csh*'
compilation aborted for t.f90 (code 1).

That's all information I get.

Thank you for your help!

 

system crash when running dss on MKL_dss_indefinite

Hey there,

my dss implementation freezes the whole system, probably due running out of memory, when switching from positive_definite to indefinite.

The matrix provided to dss is 4x4, so not a big problem, but it is negative definite.

The module implementing the solver is:

include "mkl_dss.f90"
Module ModMKLSolver
  use Data_Kind
  use ModEquation
  use ModLogfile
  Implicit none
  Type MKLSolver
    Type(Equation) :: TSEq
  contains
    Procedure, Pass, Public :: Solve => SubSetPEVDSS
  End type MKLSolver
  Private :: SubSetPEVDSS
contains
  Subroutine SubSetPEVDSS(this,ISSubStat)
    use MKL_DSS
    Implicit None
    Class(MKLSolver), Target, Intent(InOut) :: this
    Integer(Iks), Intent(InOut) :: ISSubStat
    Integer(Ikxl) :: c1, c2
    TYPE(MKL_DSS_HANDLE) :: handle
    Integer(Ikxl) :: ISError
    Integer(Ikl) :: opt, a, ISSize
    Integer(Ikl), Allocatable, Dimension(:) :: IVPermu
    ISSize=this%TSEq%TSLHS%ISDim
    Allocate(&&IVPermu(ISSize),&&stat=ISSubStat)
    If(ISSubStat==0) Then
      IVPermu=0
      this%TSEq%RVsol=0._rkdbl
      ISSubStat=dss_create(handle, MKL_DSS_MSG_LVL_WARNING&&+MKL_DSS_TERM_LVL_ERROR)
      If(ISSubStat==0) Then
        ISSubStat=dss_define_structure(handle=handle,&&opt=MKL_DSS_SYMMETRIC,&&rowIndex=this%TSEq%TSLhs%IVRowPos,&&nRows=ISSize,&&RCols=ISSize,&&columns=this%TSEq%TSLhs%IVColPos,&&nNonZeros=size(this%TSEq%TSLhs%RVCoeff))
      End If
      If(ISSubStat==0) Then
        ISSubStat=dss_reorder(handle=handle, opt=MKL_DSS_GET_ORDER, perm&&=IVPermu)
      end If
      If(ISSubStat==0) Then
        ISSubStat=dss_factor(handle=handle,&
          !&opt=MKL_DSS_POSITIVE_DEFINITE,&&opt=MKL_DSS_INDEFINITE,&&RValues=this%TSEq%TSLhs%RVCoeff)
      End If
      If(ISSubStat==0) Then
        ISSubStat=dss_solve(handle=handle,&&opt=0,&&RRhsValues=this%TSEq%RVRHS,&&nRhs=1,&&RSolValues=this%TSEq%RVSol)
      End If
    End If
  end Subroutine SubSetPEVDSS
end Module ModMKLSolver

The implementation works with setting "positive_definite" and matrices which abide by that rule.

Compiler: ifort 15, System: ubuntu 14.04

Any suggestions??

Thanks

Karl

Bindings of types local to procedures can't find module procedures

If you have a module procedure that is explicitly marked PUBLIC, and you try and use that procedure for a binding for a type definition that is local to another procedure, then current ifort complains that the name of the module procedure doesn't have an explicit interface.

Delete the PUBLIC statement for the procedure in the specification part of the module, and all is well...

MODULE m
  IMPLICIT NONE
  PUBLIC :: True
  PUBLIC :: False      !<<<< Delete this and things work.

  TYPE, PUBLIC :: TraitsType
  CONTAINS
    PROCEDURE, NOPASS :: XYZ => True
  END TYPE TraitsType

  TYPE, PUBLIC :: Thing
    CLASS(TraitsType), ALLOCATABLE :: traits
  END TYPE Thing
CONTAINS
  SUBROUTINE proc(arg)
    TYPE(Thing), INTENT(OUT) :: arg

    TYPE, EXTENDS(TraitsType) :: local_traits
    CONTAINS
      PROCEDURE, NOPASS :: XYZ => False
    END TYPE local_traits

    ALLOCATE(arg%traits, SOURCE=local_traits())
  END SUBROUTINE proc

  FUNCTION True() RESULT(b)
    LOGICAL :: b
    b = .TRUE.
  END FUNCTION True

  FUNCTION False() RESULT(b)
    LOGICAL :: b
    b = .FALSE.
  END FUNCTION False
END MODULE m

 

>ifort /check:all /warn:all /standard-semantics "2015-09-07 true.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

2015-09-07 true.f90(20): error #8182: The name is neither an abstract interface nor a procedure with an explicit interface.   [FALSE]
      PROCEDURE, NOPASS :: XYZ => False
----------------------------------^
compilation aborted for 2015-09-07 true.f90 (code 1)

The mention of abstract interface in the error message is odd, as the syntax does not permit the name of an abstract interface to be used as the procedure name in a type bound procedure statement.

 


Using structure constructor for empty type as actual argument

If a structure constructor for an empty extension type is used as an actual argument to an polymorphic INTENT(IN) dummy of the parent type, then strange things happen.

MODULE m
  IMPLICIT NONE

  TYPE, PUBLIC :: EmptyType
!    INTEGER :: dummy = 0   ! <<<<
  CONTAINS
    PROCEDURE, NOPASS :: XYZ => True
  END TYPE EmptyType
CONTAINS
  FUNCTION True() RESULT(b)
    LOGICAL :: b
    b = .TRUE.
  END FUNCTION True

  FUNCTION False() RESULT(b)
    LOGICAL :: b
    b = .FALSE.
  END FUNCTION False

  SUBROUTINE Proc(arg)
    CLASS(EmptyType), INTENT(IN) :: arg

    PRINT *, arg%XYZ()
  END SUBROUTINE Proc
END MODULE m

PROGRAM p
  USE m
  IMPLICIT NONE

  TYPE, EXTENDS(EmptyType) :: extension
  CONTAINS
    PROCEDURE, NOPASS :: XYZ => False
  END TYPE extension

  CALL Proc(extension())
END PROGRAM p

 

>ifort /check:all /warn:all /standard-semantics /traceback "2015-09-07 Empty.f90"&& "2015-09-07 Empty.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Build 20150815
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2015-09-07 Empty.exe"
-subsystem:console
-incremental:no"2015-09-07 Empty.obj"
forrtl: severe (408): fort: (7): Attempt to use pointer ARG when it is not associated with a target

Image              PC                Routine            Line        Source
2015-09-07 Empty.  000000013FAD3BCE  Unknown               Unknown  Unknown
2015-09-07 Empty.  000000013FAD1173  M_mp_PROC                  23  2015-09-07 Empty.f90
2015-09-07 Empty.  000000013FAD12FE  MAIN__                     36  2015-09-07 Empty.f90
2015-09-07 Empty.  000000013FB2362E  Unknown               Unknown  Unknown
2015-09-07 Empty.  000000013FB104C3  Unknown               Unknown  Unknown
kernel32.dll       00000000771559CD  Unknown               Unknown  Unknown
ntdll.dll          000000007738B981  Unknown               Unknown  Unknown

 

Generating SUBMODULE interfaces automatically

To reduce compile cascades I want to convert  some MODULES to SUBMODULES. I have hundreds of subroutines and functions and this will not be a quick task without some automation of the process.  I did consider the generate interfaces compiler option but this does not do what you need because the routines are in a MODULE so it quite rightly ignores them. As most of the current modules have some module data and some internal interdependencies is is not so simple as to comment out the MODULE/END MODULE to get generated interfaces.

Does anyone have a method/ program for doing this? I would imaging he data needed is all in the .MOD files if you knew the format of the MOD file. Has Intel considered some tool for this? 

How to execute an external batch file from Fortran with SYSTEM / SYSTEMQQ and wait until completion to continue

Hello,

I know there is available in the Intel Fortran Compiler a SYSTEM call or SYSTEMQQ logical function to be used for executing batch processes from CMD. However, the problem is that in either case Fortran does not wait until completion of the batch process.

Below is a sample case:

==============================================

      PROGRAM MAIN
C
C       IMPLICIT NONE
C
      CHARACTER(LEN=8)   :: JOBID
      CHARACTER(LEN=9)   :: DRIVER1
      CHARACTER(LEN=3)   :: DRIVER2
      INTEGER            :: RET
C
      JOBID='''JOB100'''
      DRIVER1='BATCH991('
      DRIVER2=',1)'
      CALL SYSTEM(DRIVER1//JOBID//DRIVER2)
C     
C
      PRINT*,'>>> RUNNING BATCH... >>>'
      PRINT*, CHAR(7)
C
C     continue FORTRAN statements...
C
C
      END PROGRAM MAIN

==============================================

The BATCH991 process takes around of 40 seconds to complete, and the beep sounds instantaneously after printing the RUNNING... message, a clear indication that Fortran is not waiting until completion to continue with the statements. I both tried with CALL SYSTEM, RES=SYSTEM(..) and RES=SYSTEMQQ(), in any case Fortran does not wait until the batch termination.

I really appreciate your help on this issue.

Thanks once again. 

coarrays in common blocks

Hello,

please, can somebody comment on the statement I found at several
places that coarray cannot be a part of a common block?

I would like to understand if there is a good reason for this...

It complicates easy parallelization of existing code a lot, because
instead of just changing things inside a common one has to create
modules, and then (since I can't change all commons into modules at
once) copy information between commons and modules (and have it
explicitly twice, in effect).

I believe that Cray complilers explicitly state that there *can* be
coarrays in commons... On the other and, gfortran seems to reject
that.

Thanks for any comments and explanations!
Best regards

Rudolf Sykora

SUBMODULE error #6645: The name of the module procedure conflicts....

Loaded PSXE2016 start night and today had a first play with the much awaited SUBMODULES. consider the following code:

MODULE BILL
    implicit none
    public
    integer, parameter          :: axs6_irk = kind(1.D0)            ! real kind for dp
    integer, parameter, private :: irk = axs6_irk
    INTERFACE
        MODULE FUNCTION IS_LEAP_YEAR(IYEAR)
            INTEGER(KIND=2), INTENT(IN) :: IYEAR
            LOGICAL(KIND=4) :: IS_LEAP_YEAR
        END FUNCTION IS_LEAP_YEAR
        MODULE SUBROUTINE DVECRS(V1XV2,V1,V2)
            REAL(KIND=IRK) :: V1XV2(3)
            REAL(KIND=IRK), INTENT(IN) :: V1(3)
            REAL(KIND=IRK), INTENT(IN) :: V2(3)
        END SUBROUTINE DVECRS
    END INTERFACE
END MODULE BILL

This compiles OK with no errors or warnings. Then we have.

submodule (BILL) BILL_SUBS1
    contains
    function is_leap_year(iyear)
       ! returns true if iyear is a leap year and false otherwise
       implicit none
       logical(4)              :: is_leap_year
       integer(2), intent (in) :: iyear
       if     (mod(iyear,400_2) == 0) then ! special case for every 4th century
           is_leap_year=.true.
       elseif (mod(iyear,100_2) == 0) then ! centuries are not leap years
           is_leap_year=.false.
       elseif (mod(iyear,4_2) /= 0 ) then  ! not divisible by 4 and not special case so not a leap year
           is_leap_year=.false.
       else
           is_leap_year=.true.             ! divisible by 4 and not a special case to leap year
       endif
    end function is_leap_year
    subroutine dvecrs(V1XV2,V1,V2 )
        !     THIS FORMS THE CROSS PRODUCT OF V1 AND V2 AS V1XV2
        implicit none
        REAL(irk)             :: V1XV2(3)
        REAL(irk), intent(in) :: V1(3) , V2(3)
        V1XV2 = [V1(2)*V2(3) - V1(3)*V2(2), -V1(1)*V2(3) + V1(3)*V2(1), V1(1)*V2(2) - V1(2)*V2(1)]
    end subroutine dvecrs
end submodule BILL_SUBS1

This was a simple example using one function and one subroutine. I get the errors>>>>

sample2.f90(3): error #6645: The name of the module procedure conflicts with a name in the encompassing scoping unit.   [IS_LEAP_YEAR]

sample2.f90(18): error #6645: The name of the module procedure conflicts with a name in the encompassing scoping unit.   [DVECRS]

what have a done wrong? I have read various example etc and I can't see it though I may be suffering that brand of selective blindness that sometime filters out the glaring errors...

VS2013 strange behaviour/submodules/PSXE16.0

I am making some tests with PSXE16.0 using SUBMODULES. My test job exhibits some strange behaviour:

1] On doing a successful build or clean then build if I do F5 to debug it says the exe is out of date and does a full build again. It will then debug.

2] On changing anything, e.g. the main program (there are only 3 source files ) is does a complete rebuild every time.

This type of behaviour I have experienced before when the project has circular dependencies. This project has three files, a module file with interfaces, a sub module file with only contained sub-routines and a simple main program. I did all the usual close VS and restarting, deleting the project and making a new one etc.

On opening the project in VS the first time and doing a build I get (one time only!):

C:\Users\...\fred_subs.f90 : warning: Module 'Debug\subroutine.mod' is created by both 'C:\Users\...\fred_subs.f90' and 'C:\Users\...\fred.f90'.
1>------ Build started: Project: SUBM_TEST2, Configuration: Debug Win32 ------
1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
1>fred.f90
1>fred_subs.f90
1>SUBM_TEST.f90
1>Linking...
1>Embedding manifest...
1>
1>Build log written to  "file://C:\Users\.....\Debug\BuildLog.htm"
1>SUBM_TEST2 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Note the first line! I think this is the route cause but it makes no sense are the VS integration picking up “module subroutine” which is part of the interfaces for each subroutine and also the definition and believing there is a MODULE called SUBROUTINE? “Subroutine.mod” is not created by the way.

Does anyone know of any issues like this? 

Array of structure of arrays in fortran

I have something like this - 

type output
real(kind=8) :: array1(10,20,30)
real(kind=8) :: array2(10,20,4)
end type output

type (output),save, dimension(54) :: array_o

Also, I have something like this - 

type output_pointer
real(kind=8),pointer :: array1(:,:,:)
real(kind=8),pointer :: array2(:,:,:)
end type output_pointer

type (output),save, dimension(54) :: array_pointer

Are these permissible in fortran? I am getting no build error but I am getting runtime error.


Troubles migrating from Visual Studio 6.0 (Visual Fortran 6.6.0) to Visual Studio 2013 (Parallel Studio XE 2015)

Hello everyone,

I’m developing an upgrade from Visual Fortran 6.0 to Visual Studio 2013. It is a dynamic library based on Fortran and C++  . The migration of the project is automatically made by VS2013, so, I only change the code to adapt it to new C++  standard and add "$(IFORT_COMPILER15)\compiler\lib\ia32" to Library WinRT Directories of Microsoft.Cpp.Win32.user.

First I build the C++  project obtaining a static library, after that, I compile the Fortran project with the static library to obtain the dynamic library. This step works and I obtain the dynamic library.

Then, I’m trying to run the dll file from another project but the code breaks when it is trying to get the addresses of the library functions. The code runs properly (this part of code) when it loads the Visual Fortran 6 library. So it should be the new dll.

 

  // Attempt to load the specified dll
   m_hInstance = ::LoadLibrary(filename);
   HMODULE hm = (HMODULE) m_hInstance;
   if (0 == m_hInstance) goto cleanup;

   // Get addresses of all DLL functions
   m_pSI = (INITIALIZE*) ::GetProcAddress(hm, "Initialize");
   if (!m_pSI) goto cleanup;

   m_pGC = (GETCOUNT*) ::GetProcAddress(hm, "GetCount");
   if (!m_pGC) goto cleanup;

   m_pGP = (GETPERIOD*) ::GetProcAddress(hm, "GetPeriod");
   if (!m_pGP) goto cleanup;

I am able to load the dll, but when I call to GetProcAddress function, I get NULL address. And we don’t know why it cannot get addresses.

Any suggestion of what can I do?

Information of fortran and visual studio:

  • Visual Studio: Professional 2013, Version 12.0.21005.1
  • Fortran compiler: Intel® Parallel Studio XE 2015 Composer Edition for Fortran, Version 15.0.0115.12

Thank you in advance,

Ibon

Warning about misaligned elements in structure

The 16.0 compiler issues the following warning message about a structure:

..\include\dmumps_struc.h(14): warning #6379: The structure contains one or more misaligned fields.   [DMUMPS_STRUC]
      TYPE DMUMPS_STRUC

Although I wish to make this message go away, by inserting padding or rearranging the sequence, in this case the declaration of the structure (i.e., user-defined type) spans 265 lines, causing the number of suspects to be large.

It would help if the compiler flagged (or flagged when requested) the particular structure members that caused the misalignment.

 

Open Source Downloads

This article makes available third-party libraries, executables and sources that were used in the creation of Intel® Software Development Products or are required for operation of those. Intel provides this software pursuant to their applicable licenses.

 

Required for Operation of Intel® Software Development Products

The following products require additional third-party software for operation.

Intel® Parallel Studio XE 2015 Composer Edition for C++ Windows* and
Intel® System Studio 2015 Composer Edition for Windows*:

The following binutils package is required for operation with Intel® Graphics Technology:


Please see Release Notes of the product for detailed instructions on using the binutils package.

The above binutils package is subject to various licenses. Please see the corresponding sources for more information:


 

Required for use of offload with Open Source Media Kernel Runtime for Intel® HD Graphics

The following products require additional third-party software for the mentioned operation.

Intel® Parallel Studio XE 2016 Composer Edition for C++ Linux* and
Intel® System Studio 2016 Composer Edition for Linux*:

The following installation guide together with the build and installation script are required:


This file contains the otc_cmrt_build_and_install.sh script. Please unpack it.
 

Used within Intel® Software Development Products

The following products contain Intel® Application Debugger, Intel® Debugger for Heterogeneous Compute, Intel® Many Integrated Core Debugger (Intel® MIC Debugger), Intel® JTAG Debugger, and/or Intel® System Debugger tools which are using third party libraries as listed below.

Products and Versions:

Intel® System Studio 2016*

  • Intel® System Studio 2016 Composer Edition
    (Initial Release and higher)

Intel® Parallel Studio XE 2016 for Linux*

  • Intel® Parallel Studio XE 2016 Composer Edition for C++ Linux*/Intel® Parallel Studio XE 2016 Composer Edition for Fortran Linux*
    (Initial Release and higher)

Intel® Parallel Studio XE 2015 for Linux*

  • Intel® Parallel Studio XE 2015 Composer Edition for C++ Linux*/Intel® Parallel Studio XE 2015 Composer Edition for Fortran Linux*
    (Initial Release and higher)

Intel® Composer XE 2013 SP1 for Linux*

  • Intel® C++ Composer XE 2013 SP1 for Linux*/Intel® Fortran Composer XE 2013 SP1 for Linux*
    (Initial Release and higher; 13.0 Intel® Application Debugger)

Intel® Composer XE 2013 for Linux*

  • Intel® C++ Composer XE 2013 for Linux*/Intel® Fortran Composer XE 2013 for Linux*
    (Initial Release and higher; 13.0 Intel® Application Debugger)

Intel® Composer XE 2011 for Linux*

  • Intel® C++ Composer XE 2011 for Linux*/Intel® Fortran Composer XE 2011 for Linux*
    (Update 6 and higher; 12.1 Intel® Application Debugger)
  • Intel® C++ Composer XE 2011 for Linux*/Intel® Fortran Composer XE 2011 for Linux*
    (Initial Release and up to Update 5; 12.0 Intel® Application Debugger)

Intel® Compiler Suite Professional Edition for Linux*

  • Intel® C++ Compiler for Linux* 11.1/Intel® Fortran Compiler for Linux* 11.1
  • Intel® C++ Compiler for Linux* 11.0/Intel® Fortran Compiler for Linux* 11.0
  • Intel® C++ Compiler for Linux* 10.1/Intel® Fortran Compiler for Linux* 10.1

Intel® Embedded Software Development Tool Suite for Intel® Atom™ Processor:

  • Version 2.3 (Initial Release and up to Update 2)
  • Version 2.2 (Initial Release and up to Update 2)
  • Version 2.1
  • Version 2.0

Intel® Application Software Development Tool Suite for Intel® Atom™ Processor:

  • Version 2.2 (Initial Release and up to Update 2)
  • Version 2.1
  • Version 2.0

Intel® C++ Software Development Tool Suite for Linux* OS supporting Mobile Internet Devices (Intel® MID Tools):

  • Version 1.1
  • Version 1.0

Intel AppUp™ SDK Suite for MeeGo*

  • Initial Release (Version 1.0)

Used third-party libraries:
Please see the attachments for a complete list of third-party libraries.

Note: The packages posted here are unmodified copies from the respective distributor/owner and are made available for ease of access. Download or installation of those is not required to operate any of the Intel® Software Development Products. The packages are provided as is, without warranty or support.

  • Eclipse
  • EPL
  • third-party
  • Intel(R) Software Development Products
  • Intel® Graphics Technology
  • Intel® Composer XE
  • Intel® C++ Composer XE
  • Intel® Application Debugger
  • Intel® Many Integrated Core Architecture Debugger & Intel® JTAG Debugger
  • Intel AppUp® Developers
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Microsoft Windows* 8.x
  • C/C++
  • Fortran
  • Intel® C++ Compiler
  • Intel® Fortran Compiler
  • Intel® Debugger
  • Intel® JTAG Debugger
  • Graphics
  • Intel® Atom™ Processors
  • Open Source
  • Wrong result with defined assignment operator and/or parenthesized expressions and allocatable components

    As discussed also in this thread:

    https://groups.google.com/d/msg/comp.lang.fortran/8q2nYfHnZfU/M9FmGgx7AQAJ

    ifort produces wrong results with the attached code: the expected output is

     Case A: v1%x =   1.5000000E+00
     Case B: v1%x =   1.5000000E+00
     Case C: v1%x =   1.5000000E+00

    while it gives

     Case A: v1%x =   0.0000000E+00
     Case B: v1%x =   0.0000000E+00
     Case C: v1%x =   0.0000000E+00

    ifort -V
    Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.0.109 Build 20150815

    module m
     implicit none
    
     type :: t_a
      real, allocatable :: x
     end type t_a
    
     interface assignment(=)
      module procedure copy_t_a
     end interface
    
    contains
    
     subroutine copy_t_a(y,x)
      type(t_a), intent(in)  :: x
      type(t_a), intent(out) :: y
       allocate( y%x , source=x%x)
     end subroutine copy_t_a
    
    end module m
    
    
    program p
     use m
     implicit none
    
     type(t_a) :: v1
    
     ! Define v1
     allocate( v1%x )
     v1%x = 1.5
    
    
     ! This produces segfault
     v1 = v1
     write(*,*) "Case A: v1%x = ",v1%x ! should print 1.5
    
     ! This produces segfault
     v1 = (v1)
     write(*,*) "Case B: v1%x = ",v1%x ! should print 1.5
    
     ! This prints 0
     call copy_t_a( v1 , (v1) )
     write(*,*) "Case C: v1%x = ",v1%x ! should print 1.5
    
    end program p
    

     

    Visual Studio trying to re-link app when running it in debug mode

    Hi there,

    I don't know why this is happening. I can successfully build a (VS) project consisting of two static libraries and one executable. I can run the (command line) app and everything seems OK. Now, when I try to launch it from Visual Studio for debugging (with F5 or pressing the "play" button), VS will always try to build the exe again and the link will fail with basically everything being "unresolved external symbol". This never happened to me before and I think it is related with the fact that I've been altering the PATH. Could this be the case?

    What I have in the path and which seems to be related with IVF is (I purposefully removed the mpirt entries.)

    C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64\compiler;

    C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler;

    Is there anything obvious missing? I have VS 2012 and IVF 2013 Update 3 (Windows 10).

    I already created a new VS solution with its projects from scratch and the problem persists.

    Thanks.

     

    Viewing all 3270 articles
    Browse latest View live


    <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>