Intel® Fortran Compilers

Performance without compromise on Windows*, Linux* and OS X*

  • Broad support for current and previous Fortran standards, plus popular extensions
  • Intel® Math Kernel Library included in suites
  • Optional Rogue Wave* IMSL* Fortran Numerical Library on Windows

Try & Buy Intel® Fortran Compiler in:

Intel® Parallel Studio XE

A complete Fortran development environment for Windows*

  • Works with Microsoft* Visual Studio* 2010, 2012 and 2013
  • Don't have Visual Studio? No problem - a Fortran development environment based on Microsoft Visual Studio 2010 Shell is included - nothing else to buy!
  • Develop, build, debug and run from the familiar Visual Studio IDE, or build and run from the command line - your choice!
  • 32-bit and 64-bit development included - no extra charge!
  • Create traditional console applications or advanced graphical interfaces with QuickWin, OpenGL* and Windows API support
  • COM (Component Object Model) and .NET interoperability provided
  • Build mixed-language applications with C++, Visual Basic*, Microsoft C# and more! (requires Microsoft Visual Studio)
  • Tens of thousands of declarations of routines, types and constants for Windows API, OpenGL, POSIX, dialogs, multi-byte character support and more!

Intel Fortran integration into Microsoft Visual Studio

  1. Fortran project and source files in Visual Studio
  2. Fortran-aware text editor with context-sensitive help, Go To Definition, templates, coloring and more
  3. Debug Fortran code with full access to Fortran types and arrays
  4. Build and debug mixed-language programs in a single Visual Studio solution
  5. Set breakpoints at Fortran source lines, with optional conditions


Broad support for current and previous Fortran standards, plus popular extensions

  • Full language Fortran 95, full Fortran 2003, plus significant Fortran 2008 features
    • Coarrays
    • DO CONCURRENT
    • 31 array dimensions (standard specifies 15)
    • NEWUNIT in OPEN
    • Much more - see release notes for details
  • Also supports FORTRAN IV (FORTRAN-66), FORTRAN 77 and Fortran 90
  • Extensive OpenMP 4.0* support
  • Source compatible with Compaq Visual Fortran* - most projects just need a rebuild

Performance without compromise

  • Industry leading performance on Intel and AMD* processors.  Take a look at the benchmarks below that were run by Polyhedron* for independent confirmation.


Geomean time in seconds - lower is better
As published 3/10/2014 at http://www.polyhedron.com

  • Extensive optimizations for the latest Intel processors, including Intel® Xeon Phi™ coprocessor
  • Take advantage of multicore, manycore and multiprocessor systems with OpenMP, automatic parallelism, DO CONCURRENT, coarrays and Intel Xeon Phi coprocessor support
  • Patented automatic CPU dispatch feature gets you code optimized for the current running processor

Intel® Math Kernel Library

  • Included in Fortran suites that adds advanced math processing
  • Vectorized and threaded for highest performance on all Intel and compatible processors
  • De facto standard APIs for simple code integration
  • Compatible with all C, C++ and Fortran compilers
  • Royalty-free, per developer licensing for low cost deployment
  • Click here for more information.

Rogue Wave* IMSL* 7 Fortran Numerical Library

  • Optional add-on to the suites that include Intel Visual Fortran compiler
  • Superior accuracy and reliability through 40 years of refinement
  • A comprehensive set of 1000+ algorithms
  • Supporting parallel processing architectures since 1990
  • Evolves easily with software and hardware upgrades
  • Click here for more information and pricing

Outstanding support

  • One year of support included with purchase – gives you access to all product updates and new versions released in the support period plus access to Intel® Premier Support
  • Active user forums for help from experienced users and Intel engineers

Works with your familiar development environment

  • Uses gcc tools, including gdb debugger
  • Link compatible with C and C++ from gcc
  • 32-bit and 64-bit compilers included – no extra charge!

Broad support for current and previous Fortran standards, plus popular extensions

  • Full language Fortran 95, Full Fortran 2003, plus significant Fortran 2008 features
    • Coarrays
    • DO CONCURRENT
    • 31 array dimensions (standard specifies 15)
    • NEWUNIT in OPEN
    • BLOCK
    • Much more - see release notes for details
  • Also supports FORTRAN IV (FORTRAN-66), FORTRAN 77 and Fortran 90
  • Extensive OpenMP 4.0* support

Performance without compromise

  • Industry leading performance on Intel and AMD processors. Take a look at the benchmarks below that were run by Polyhedron for independent confirmation.


Geomean time in seconds - lower is better
As published 3/10/2014 at http://www.polyhedron.com

  • Extensive optimizations for the latest Intel processors including Intel® Xeon Phi™ coprocessor
  • Take advantage of multicore, manycore and multiprocessor systems with OpenMP, automatic parallelism, DO CONCURRENT, coarrays and Intel Xeon Phi coprocessor support
  • Patented automatic CPU dispatch feature gets you code optimized for the current running processor

Intel® Math Kernel Library

  • Included in Fortran suites that adds advanced math processing
  • Vectorized and threaded for highest performance on all Intel and compatible processors
  • De facto standard APIs for simple code integration
  • Compatible with all C, C++ and Fortran compilers
  • Royalty-free, per developer licensing for low cost deployment
  • Click here for more information

Outstanding support

  • One year of support included with purchase – gives you access to all product updates and new versions released in the support period plus access to Intel® Premier Support
  • Active user forums for help from experienced users and Intel engineers

Works with your familiar development environment

  • Build from command line or use Xcode integration (limited feature)
  • Link compatible with C and C++ from gcc
  • 32-bit and 64-bit compilers included – no extra charge!

Broad support for current and previous Fortran standards, plus popular extensions

  • Full language Fortran 95, full Fortran 2003, plus significant Fortran 2008 features
    • DO CONCURRENT
    • 31 array dimensions (standard specifies 15)
    • NEWUNIT in OPEN
    • BLOCK
    • Much more - see release notes for details
  • Also supports FORTRAN IV (FORTRAN-66), FORTRAN 77 and Fortran 90
  • Extensive OpenMP 4.0* support

Performance without compromise

  • Industry leading performance
  • Extensive optimizations for the latest Intel processors
  • Take advantage of multicore, manycore and multiprocessor systems with OpenMP, automatic parallelism, DO CONCURRENT
  • Patented automatic CPU dispatch feature gets you code optimized for the current running processor

Intel® Math Kernel Library

  • Vectorized and threaded for highest performance on all Intel and compatible processors
  • De facto standard APIs for simple code integration
  • Compatible with all C, C++ and Fortran compilers
  • Royalty-free, per developer licensing for low cost deployment
  • Included in Intel® Fortran Composer XE
  • Click here for more information

Outstanding support

  • One year of support included with purchase – gives you access to all product updates and new versions released in the support period plus access to Intel® Premier Support
  • Active user forums for help from experienced users and Intel engineers

Videos to help you get started.

  • Introduction to Intel® Visual Fortran in the Microsoft* Visual Studio* Development Environment
  • Optimizing your application with Intel® C++ and Fortran Compilers for Windows* and Linux*

Register for future Webinars


Previously recorded Webinars:

  • Update Now: What’s New in Intel® Compilers and Libraries
  • An Introduction to Intel® Visual Fortran Development on Intel® Xeon Phi™ coprocessor
  • OpenMP 4.0 for SIMD and Affinity Features with Intel® Xeon® Processors and Intel® Xeon Phi™ Coprocessor
  • Learn to be an Intel® Visual Fortran Power User
  • Optimizing and Compilation for Intel® Xeon Phi™ Coprocessor

Featured Articles

Контент не найден

More Tech Articles

Scheduling for 1-4 Threads Per Core Using Compiler Option -qopt-threads-per-core
- Ronald W Green (Intel)Опубликовано: 10/16/20130
Compiler Methodology for Intel® MIC Architecture Scheduling for 1-4 Threads Per Core Using Compiler Option -qopt-threads-per-core This option is a hint or suggestion to the compiler about the number of hardware threads per core that MAY be used for an application. This hint enables the compiler...
Application Analysis for Intel® MIC Architecture Suitability
- AmandaS (Intel)Опубликовано: 10/16/20130
Compiler Methodology for Intel® MIC Architecture Application Analysis for Intel® MIC Architecture Suitability The Intel® Many Integrated Core Architecture (Intel® MIC Architecture) provides a product family optimized to deliver performance for highly parallel applications or highly parallel ker...
Preparing for the Intel® Many Integrated Core Architecture
- AmandaS (Intel)Опубликовано: 10/16/20133
Compiler Methodology for Intel® MIC Architecture Preparing for the Intel® Many Integrated Core Architecture The Intel® Many Integrated Core Architecture (Intel® MIC Architecture) provides a product family optimized to deliver performance for highly parallel applications or highly parallel kerne...
Programming and Compiling for Intel® Many Integrated Core Architecture
- AmandaS (Intel)Опубликовано: 10/16/20131
Compiler Methodology for Intel® MIC Architecture This methodology enables you to determine your application's suitability for performance gains using Intel® Many Integrated Core Architecture (Intel® MIC Architecture).
Подписаться на Статьи Intel Developer Zone

Supplemental Documentation

Контент не найден
Подписаться на Статьи Intel Developer Zone

You can reply to any of the forum topics below by clicking on the title. Please do not include private information such as your email address or product serial number in your posts. If you need to share private information with an Intel employee, they can start a private thread for you.

New topic    Search within this forum     Subscribe to this forum


Passing Parts of Derived Data Type to Subroutine
- Scott B.3
I am building a subroutine that I can either use a derived data type (my preference) or individual arrays. The arrays will be passed to a various subroutines, including the MKL CG Solver.  My question is will this form temporary arrays or will the compiler efficiently use the arrays in the routines (particularly in MKL)   Bellow are is an example (forgive any minor bugs as I am just typing this from the window to illustrate what I mean) TYPE MAT DOUBLE PRECISION, DIMENSION(:), ALLOCATABLE:: X DOUBLE PRECISION, DIMENSION(:,:), ALLOCATABLE:: A END TYPE TYPE(MAT), DIMENSION(:), ALLOCATABLE:: M ALLOCATE(M(5)) DO I=1, 5 ALLOCATE( M(I)%X(10) ) ALLOCATE( M(I)%A(10,10) ) END DO !X and A are then populated with numbers DO I=1, 5 CALL MYSUB( M(I)%A, M(I)%X ) END DOThe alternative would be to use standard arrays as follows: DOUBLE PRECISION, DIMENSION(:,:), ALLOCATABLE:: X DOUBLE PRECISION, DIMENSION(:,:,:), ALLOCATABLE:: A ALLOCATE( X(10,5) ) ALLOCATE( A(10,10, 5) ) ...
Unformatted file I/O difference between Debug and Release
- NotThatItMatters5
I have code which has the option of dumping memory to a file and then later reading this file to repopulate memory for a later run.  I am noting that I can run the code in Release mode without error, and yet in Debug mode the READ statements crash with the claim, input beyond end of record. The READ statements contain within the program two REWIND statements for the file.  I have put some tracking statements to a file to see where the problem lies, but there is no apparent reading out of sequence.
#6375: Because of COMMON, the alignment of object is inconsistent with its type
- PRADEEP KUMAR P.11
I have one of a very common issue. But I am not sure why it happens this time.  Warning #6375: Because of COMMON, the alignment of object is inconsistent with its type[P]   THE DECLARATION IS DONE WITH CARE. BUT STILL THE PROBLEM PERSISTS. I KINDLY SEEK EXPERTS AND FRIENDS ADVICE ON THIS REGARD.  -PRADEEP
Using . instead of % as a component selector tool for a derived type
- avinashs4
  I accidently used the period operator (.) instead of % as a component selector tool in my Fortran code. This seemed to work perfectly fine with the Intel Parallel XE 2015 compiler. However, I could not find it documented anywhere as being a safe alternative for the % character. Is this a known feature or change to the standard? I personally find it easier to read code with the period operator and would like to adopt this as a standard code-writing practice. Any suggestions or warnings will be welcomed.
PDT question
- Walt Brainerd2
<p>I am trying some new things with Beta 2016 (W8.1, cygwin) and have several things working, including submodules, PDTs, and DTIO ! <p>I have encountered a couple of bugs and ICEs, which I have submitted, but this is a question. <p>I am trying to extend operator (+) and assignment (=) with a PDT. Each seems to work (sort of) but not together. How do I declare the result of the operator extension so that it is compatible with the arguments (other than literal array sizes)? Here is what I have so far (sorry, I have no clue how to format this thing). I am going to try the whole thing again with allocatables, but I think the simpler case should work ??? <pre> $ ifort addmatrix.f90 Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0 Beta Build 20150326 Copyright (C) 1985-2015 Intel Corporation.  All rights reserved. addmatrix.f90(67): error #6197: An assignment of different structure types is invalid.    c = a + b...
Comments in Namelist Read From Character String Broken
- Jeff L.2
Hi, I am not a Fortran expert by any means but have been searching for a solution to a particular problem that I'm having and have not had any success in finding a solution. Any help or feedback would be much appreciated. I have a Fortran program that receives a character string from an external source (3rd party lib) that contains Namelist inputs. I have been using the READ statement to read the string directly into my namelist variables and all has been working well it seemed. However, recently I came along a use case where comments were embedded in the input string. All namelist inputs before the comment were read in correctly but all namelist inputs after the comment was ignored and the read statement returned a -1. I set up a small program to emulate the behavior and am including an example below. The namelist input string looks like the following: $NLA  a = 1,  ! This is a comment  b = 1, $ ---- Example Program to Emulate Problem --- CHARACTER*255 temp INTEGER(KIND=4) :: a, b,...
BBC Radio - Codes that Changed the World - Fortran
- Steve Lionel (Intel)4
A delightful program from BBC Radio on Fortran. Downloadable for the next three weeks: http://downloads.bbc.co.uk/podcasts/radio4/codes/r4codes_20150406-1400b.mp3
intel fortran DLL is klobbering my SIGINT handler!
- Geoff G.3
Hey guys, I'm doing an integration piece between a Java front-end and a very mathy chunk of fortran we've written. We've got it being loaded and executed properly. The one annoying thing is that I'm using the JVM to subscribe to SIGINT, so I can do some persistence-ee things if the user hits Ctrl + C on one of our command line tools. This works well, except for that if I load the fortran dll after the signal handler was registered with the JVM, the fortran DLL appears to over-write the signal handler I put in with its own. Fortran's default SIGINT handler prints out this: error (200): program aborting due to control-C event Image PC Routine Line Source SOGOV1.dll 6B0B69C8 Unknown Unknown Unknown KERNELBASE.dll 772123C4 Unknown Unknown Unknown KERNEL32.DLL 74E07C04 Unknown Unknown Unknown ntdll.dll 775DB54F Unknown Unknown Unknown ntdll.dll 775DB51...
Подписаться на Форумы

You can reply to any of the forum topics below by clicking on the title. Please do not include private information such as your email address or product serial number in your posts. If you need to share private information with an Intel employee, they can start a private thread for you.

New topic    Search within this forum     Subscribe to this forum


Overriding type-bound procedures
- Ewan T.8
Hi there, I am trying to make best use of Fortran's OOP features and I have a question regarding the overriding of type-bound procedures. Is there a way in which I can define a type-bound procedure that can be overridden in child objects (objects which extend the base class) and have different dummy arguments? At the moment I can override type-bound procedures but I have to have exactly the same number and type of dummy arguments. I had been thinking about generic procedures, but I couldn't figure out to tackle the problem. Thanks, Ewan
ifort real*4 count bug
- 志强 赵.9
Recently, I wrote a piece of codes, like that below. The value of num is larger than the range of integer 32. The result of the tmp should be 2. But in that code, the program gave 0. No matter if use ifort 13.0.0 or 15.0.0. If I change the tmp from real*4 to real*8, the result is correct. Ang idea? integer*8,parameter :: num = 2500000000 integer*8 :: i real*4,dimension(:),allocatable :: a real*4 :: tmp allocate(a(num)) a = 0.0e0 do i = 1, num if(i.eq.1) then a(1) = 1.0e0 else if(mod(i, 2).eq.0) then a(i) = 1.0e0 else a(i) = -1.0e0 end if end do tmp = 0.0e0 do i = 1, num tmp = tmp + a(i) end do print*, tmp end  
compile ifort source code in different folder
- diedro4
Dear all, I would like to compile a fortran code with ifort. The source code files *.f90 are in different sub-folders. how can I do? Thanks    
Calling Java from Fortran using JNI
- Chaitra R.2
Hello, I have a program to call Fortran from Java. The codes for func.f95, addC.c, and addJava.java are as follows: FUNCTION add(c, iflag) RESULT(f) INTEGER, INTENT(IN):: c INTEGER, INTENT(OUT):: iflag INTEGER:: f INTEGER:: i i=10 f=c+i PRINT *, f PRINT *, iflag END FUNCTION #include <stdio.h> #include "addJava.h" extern int add(int *, int *); JNIEXPORT jint JNICALL Java_addJava_add(JNIEnv *env, jobject obj, jint c, jint iflag) { int result; printf("-- We are now in the C program CCode --\n"); printf("c=%d, iflag=%d\n",c,iflag); printf("Call the FORTRAN code\n"); result = add(&c,&iflag); printf("-- We have now returned back to the C program --\n"); printf("c=%d, iflag=%d\n",c,iflag); printf("Result = %d\n",result); return result; } import java.io.*; import java.lang.*; import com.sun.jna.Library; import com.sun.jna.Native; import com.sun.jna.Platform; import com.sun.jna.ptr.IntByReference; clas...
What hath &quot;TS 29113/TS 18508&quot; wrought!?
- FortranFan20
The following simple code compiles fine with the latest Intel Fortran compiler 2015, update 2 but it gives an error with gfortran, a GCC 5.0 development trunk version. The error, as shown below, has to do with "TS 29113/TS 18508", presumably related to further interoperability features with C in the next standard.   Now I am not sure if Intel has started implementing any of these features yet, so Intel Fortran compiler behavior may not be relevant yet. However, looking at TS 29113, I don't see anything that states this code is in error; the code is so basic, if this is not allowed, then I wonder what is!  My take on this is gfortran has a bug; I would appreciate any comments and feedback on this. module m use, intrinsic :: iso_c_binding, only : c_funptr, c_f_procpointer implicit none private abstract interface subroutine ifoo() end subroutine ifoo end interface type(c_funptr) :: c_f_ptr procedure(ifoo), pointer :: f_f_ptr contains ...
Automatic pointer targeting
- YG14
Hello, As common in OO programming, an object "y" of derived type "t" should have access to some other data "x", and we grant them access by storing a local pointer "ptr" to such data.  Such pointer needs only exist inside the object "y", while in the main program we declare "x" as "target". Often enough, we want to handle the pointer association "y%ptr => x" through a dedicated subroutine that performs additional operations and consistency checks.  With F2003, our only option is to have a "target" dummy argument that corresponds to the actual argument "x", but this way the compiler does not perform any check to verify that "x" was indeed a "target".  I think that this may lead to undefined behaviour in certain situations where "x" was not declared as target and gets copied-in instead of being passed by reference.  Please correct me if I am wrong. The F2008 standard helps us here, as we could now use the "automatic pointer targeting" feature, and declare a "pointer" dummy argumen...
I want Non Commercial Intel Fortran Compiler
- Ali G.3
hi all I am master student  I want Non Commercial Intel Fortran Compiler  for Linux any help please  Thanks
Using -openmp and the effect of -auto in preparing a serial code to use OPenMP
- Jack S.7
Hi all, I have a large serial code (>15k line of code) with COMMONs blocks. I wanted to start transffering some time consuming loops to work under OpneMP parallelism. After reading some different posts in Intel's forums (i.e.:https://software.intel.com/en-us/forums/topic/279757), I decided to prepare first my code for OpenMP by adding the -auto compiler option to my set of flgas. I'm getting different results. I'm aware to the dafult -openmp which sets also -auto. My question is - how to intial local variables / arrays in a robust way, including the COMMON blocks (at the begining of the code) to get the very same results only by adding the -auto. The following step would be using -openmp flag / without any caluases for now - only to verify that the defualt behavior is not messing my calculations. Thanks for any detailed insight that you can provide. Jack.   
Подписаться на Форумы