In my program, it has used my other libraries.

I want to use some blas rountines with integer in 64bit. But I don't want to change the other parts of the program.

So, I have to use blas in 64version and 32 version.

Is it possible? How can I do.

The code below produces an internal compiler error, if the /debug:full option is enabled.

program main
  implicit none

    real :: foo(2,2)
    foo = 1.0

    call testSub(foo)

  contains

  subroutine testSub(matrix)
    class(*), intent(inout) :: matrix(:,:)  ! << This works
!    class(*), intent(inout) :: matrix(2,2)  ! << This fails
    select type(local => matrix)
      type is (real)
    end select
  end subroutine testSub

end program

Compiler: Intel(R) Visual Fortran Compiler XE 15.0 Update 2 for Windows

Hi,

I'm writing some fortran subroutines and linking them to a commercial code. The code is in the form of a library, and it was compiled with intel fortran  parallel studio XE 2013, with MS Visual Studio 2010.

I set up MS Visual Studio 2013 (with the added SDK) and I got an evaluation version of Intel Parallel Studio XE 2015 Composer Edition for Fortran Windows.  I got that to install and compiled the fortran files, and when I try to link everything up into an executable (using a makefile and MS incremental linker version 12.00.21005.1) ) I get the following:

LINK : Fatal error LNK1104: cannot open file 'LIBCMT.lib'

NMAKE :  Fatal error U1077:  'ifort' : return code '0x450'

I've tried tracking down the directories for the libraries and adding them to the LIB environment variable, but wound up with conflicts. The vendor of the commercial code is not inclined to re-compile with the newer versions, so I've re-installed MS Visual Studio 2010 and I want to install the 2013 version of the intel fortran compiler.

Questions:
a) is there a fix I can apply to my current set-up to resolve the library references in the older (2013) version of intel fortran (which is how the vendor-supplied code was compiled) ?

b) I'm planning to install the older version of fortran - MS visual studio 2010 and intel fortran 2013. Will the versions coexist on the same windows box?  That is, can I have the intel fortran compiler 2013 and the Microsoft visual studio 2010 linked up, and also have the intel fortran 2015 compiler and the Microsoft visual studio 2013 linked up, on the same machine?  or do I need to uninstall the newer versions before I install the older versions?

Thanks for any wisdom you can supply,

Tim

In November 2014, I led a session at SC14 (the event formerly known as “Supercomputing”) titled “The Future of Fortran”. I invited representatives from other vendors and members of the Fortran standards committee to participate, and had some accept, but when it came time for the session, I was up there alone. Oh well…

I had prepared a short, vendor-neutral presentation on the current state of the Fortran standard and what was coming in the next standard, currently called Fortran 2015. (I expect this name to stick.) After that I opened it up for questions from the audience, which was more substantial than I expected (about 70-80 people, despite an awful time slot.) At the end invited attendees to participate in an online survey of Fortran usage, and the results were interesting (see the end of this post).

First, I spoke about the current standard, Fortran 2008 (2010) and the previous one, Fortran 2003 (2004). There is one vendor supporting all of Fortran 2008 (Cray) and three supporting Fortran 2003 (IBM, Intel, PGI/NVidia).

Fortran 2015 was envisioned as a minor revision with only two major feature sets plus corrections of inconsistencies (referred to as “wart removal”). As is usually the case, a bunch of small features have crept in, but the result is still manageable. If you want the complete list, the Introduction to the new standard lists all the changes. The current draft is here, but it doesn't yet reflect all the changes.

The current schedule calls for the “technical work” to be done in 2015, hence the name. The expectation is that the new standard would be published sometime in 2017, but it may get pushed out further, as I discuss later.

In the following sections I will highlight the major changes, but won’t go into full detail. You can look at the draft (see above) for that.

The "Interop TS"

The first big feature set was defined in a separate Technical Specification TS29113 “Further Interoperability with C”.  This was approved in 2012 with the intent that vendors could implement the features now with reasonable assurance that the final standard would not be incompatible. A big driver of the “Interop TS”, as it is often called, was the needs of MPI 3.0. As is hinted by the title, Fortran 2015 extends the C interoperability features that first appeared in Fortran 2003 as follows:

• Assumed-type and assumed-rank make it easier to interoperate with C’s “void *”
• ALLOCATABLE, POINTER, assumed-shape and CHARACTER(*) arguments can be passed to and from C, communicated with a new data structure called a “C descriptor”
• New ISO_Fortran_binding.h C header file declares C descriptors and routines for manipulating them
• OPTIONAL arguments are now interoperable
• ASYNCHRONOUS was extended to more than I/O
• Relaxed restrictions on dummy arguments

Assumed-type variables are declared with the new syntax TYPE(*) and are allowed only as dummy arguments. Assumed-type variables have no type (are effectively unlimited polymorphic, so you can pass any type to one of these), but unlike ordinary polymorphic variables you can’t do a SELECT TYPE on them. In Fortran code if you want to use these at all you have to “cast” them to a Fortran pointer type using C_LOC and C_F_POINTER. Assumed-type variables may not have the ALLOCATABLE, CODIMENSION, INTENT(OUT), POINTER or VALUE attributes.

Assumed-rank variables are declared with the new syntax DIMENSION(..); DIMENSION(*) already had a meaning, so you’re supposed to think of this as a colon on its side. Again, only dummy variables may have assumed-rank. You can pass an item of any rank, including scalar, to an assumed-rank dummy argument. (If the item is assumed-type, it must also be assumed-shape or assumed-rank to pass to an assumed-rank dummy.) The rank of an assumed-rank dummy is assumed from the actual argument, which may be 0 if the actual was a scalar. These are passed by descriptor (C descriptor if the procedure is BIND(C) - see below). An assumed-rank dummy may not have the CODIMENSION or VALUE attributes. A new RANK intrinsic returns the rank of its argument.

At the February 2015 standards meeting, we accepted a proposal for a new SELECT RANK construct which is similar in concept to SELECT TYPE. It can be used on assumed-rank variables only and within each select block, the “associate variable” has the rank specified. This hasn't yet been accepted by the ISO committee, but I expect that to happen at our meeting in August 2015. Without SELECT RANK, it is difficult to do much with an assumed-rank variable in Fortran code.

C descriptors are an invention of the Fortran standard – they define a standard-conforming way to communicate extended information about procedure arguments such as shape, type, ALLOCATABLE/POINTER attributes and more. The standard specifies that the Fortran implementation provide a C header file named ISO_Fortran_binding.h that declares the typedefs for C descriptors, macros for values of various members, and definitions of functions for accessing and manipulating C descriptors. Any changes to the descriptor must be made through one of these functions. All the typedefs, macros and functions have names beginning with “CFI_”. An important point is that while the standard defines some restrictions on the layout of C descriptors, there is room for implementation-dependent members and member order, so C descriptors are not necessarily interchangeable among different Fortran implementations. Nonetheless, they allow mixed Fortran-C applications to do away with dependencies on vendor extensions.

Here’s a short example of a Fortran-C program that uses C descriptors.

use, intrinsic :: iso_c_binding
interface
  function c_alloc (array) bind(C)
  import
  integer(C_INT) :: c_alloc
  real(C_FLOAT), intent(out), allocatable, dimension(:) :: array
  end function c_alloc
end interface
real(C_FLOAT), allocatable, dimension(:) :: my_array
if (c_alloc(my_array) == 0) then
  print *, lbound(my_array), ubound(my_array); print *, my_array
  end if
end

#include "ISO_Fortran_binding.h“
extern int c_alloc (CFI_cdesc_t * descr) {
    int ret, i; float * array;
    CFI_index_t lower = 0, upper = 10;
    ret = CFI_allocate (descr, &lower, &upper, 0); // No elem_len
    if (ret == CFI_SUCCESS) {
        array = descr->base_addr;
        for (i=lower;i<=upper;i++) {array[i] = (float) i;}
    }
    return ret;
}

The “Coarray TS”

The other major feature set is contained in TS18508, “Additional Parallel Features in Fortran”, generally referred to as the “Coarray TS”. Unlike the “Interop TS”, the Coarray TS is still in flux. When I spoke about this last November, I was not optimistic that things would settle down enough to meet the already ambitious schedule. However, at the February 2015 meeting we made major changes to the most contentious aspect and I am feeling a lot better about its chances now.

There are generally four parts to the Coarray TS: teams, events, atomics and collectives. A “team” is a collection of images in a coarray application that are working together on a particular task. The application may have several (or many) teams working independently and then communicating their results to their parent. The nice thing about teams is that image numbering is relative to the team making it much easier to construct libraries that use coarrays without having to worry about the “coshape” of the entire application. Syntax has been added to allow you to specify a team variable as part of a coindex reference.

Teams can themselves form subteams, and teams can be dissolved and reformed dynamically. One reason to do this is if one of the images fails – as the number of images grows this can become more and more likely. But this was where the arguments raged – how do you know if an image has failed, or perhaps is just taking longer than it should to respond?

Initially, the TS had the notion of “stalling” where an image failed to make progress but was still somehow alive. We spent many, many meetings debating this topic and failed to come up with a solution for expressing in the language how to detect and recover from stalled images. In February we chose to toss the whole idea of stalling. Instead, an image could be deemed to have failed and status arguments were added to synchronization constructs to detect that an image had failed. (The actual mechanism for such detection is implementation dependent, of course.) A caveat is that some of the more vocal participants in the debate weren't at the February meeting, so it remains to be seen how the revised TS is accepted at the August meeting.

Another significant part to the TS is “events”, a way for one image notifying another image that a task has been completed and that it can proceed. This part has been settled for some time now and I don’t expect further changes.

Fortran 2008 added the concept of ATOMIC objects for which operations are done indivisibly, but there was limited support for them. The Coarray TS adds procedures for more atomic operations such as ADD, AND, CAS (Compare and Set), OR and XOR.

Lastly, collectives are intrinsic procedures for performing some operation across all the images of the current team. New subroutines defined are CO_MAX, CO_MIN, CO_SUM, CO_BROADCAST and CO_REDUCE.

What Else?

In addition to the two Technical Specifications above, Fortran 2015 will have a number of smaller changes intended to improve consistency across the language. Some of these are:

• Being able to specify the type and kind of the implied DO variable in an array constructor and in DATA (this was prompted by a suggestion in our user forum!)
• SIZE= can be used with advancing input (like our Q format extension)
• G0.d can be used with integer, logical and character list items
• New intrinsics RANDOM_INIT, COSHAPE, REDUCE, OUT_OF_RANGE
• IMPORT is now allowed in a contained procedure and in BLOCK
• IMPLICIT NONE(EXTERNAL) requires explicit interfaces for all procedures
• All procedures are recursive by default – NON_RECURSIVE may be specified if desired

Finally, what the standards committee giveth, the standards committee can also taketh away. Newly declared “obsolescent” are labeled DO loops (DO 10 I…), EQUIVALENCE, COMMON and BLOCK DATA. Arithmetic IF and the non-block DO construct, where the DO range doesn't end in a CONTINUE or END DO, are finally deleted from the language, having been declared obsolescent for several revisions. Note that none of these will actually be removed from any compiler you are likely to use, but their use will be flagged if you ask for standards checking.

The Survey Says….

As I noted earlier, I invited those attending the SC14 session to respond to a survey about Fortran usage. I didn't get a lot of responses (eleven), but what I did get was interesting:

• 45% said they were using coarrays now, 64% thought they would be using coarrays in three years
• 73% were using C interoperability features now and 36% thought they would use DO CONCURRENT within three years
• C was the overwhelming (90%) “other language” used in mixed-language applications, but Python came in a surprising second (27%)
• 90% of the responders use three or more different Fortran compilers in their work
• Responders had been programming in Fortran an average of 14 years (range was 4 to 28)
• 100% thought they would still be using Fortran in five years

Want to take the survey yourself? It’s still open at http://goo.gl/forms/j55wX7EyPs

Feel free to put in your comments here on Fortran 2015 (or the survey). As always, if you need help with the compiler or with the Fortran language, please ask in our user forums. We have one for Windows users and one for Linux/Mac users.

Hi,

I have some data (z,h) which reprents sinusoidal curve. Now, I would like to calculate first derivative dh/dz at each point (z,h).

I am using Intel Fortran Compiler with IMSL.

Can you please help me in this regard?

Cheers

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

   subroutine set_fptr()

      call c_f_procpointer(c_f_ptr, f_f_ptr)

   end subroutine set_fptr

end module m

Compilation error with options -Wall -std=f2008 in gfortran :

m.f90:23.36:
      call c_f_procpointer(c_f_ptr, f_f_ptr)
                                    1
Error: TS 29113/TS 18508: Noninteroperable procedure pointer at (1) to C_F_PROCPOINTER

When I switched to IVF/F90/F95 many years ago I used the plusFORT tool from Polyhedron to modernize the hundreds of source files in my Fortran projects saving me a lot of time and effort.Today I tried to use plusFORT again, but the program told me that my license is no longer valid. I wonder if there is free pretty printer/refactoring tool for Fortran available which might include support for the more recent standards. Any suggestions?

Hello,

I have an application that was built with Intel Fortran 14.0 and I'm trying to run it on client workstation where Intel Fortran is not installed. So I've installed Intel Fortran 14.0 redistributable package there but application doesn't work. After research with Dependency Walker I found that this workstation also have Intel Fortran 11.1 redistributables installed, and my application is trying to use the wrong library from old version.

Of course the simple solution is to uninstall 11.1 redistributables, but what if the user needs them for some other apps? Is it possible to make my application use correct libraries from new paths?

The library in question is LIBIFCOREMD.DLL

11.1 libs are here: C:\Program Files (x86)\Common Files\Intel\shared files\fortran\Bin\ia32

14.0 libs are here:  C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32\compiler

I also have 2 environment variables:

INTEL_DEV_REDIST = C:\Program Files (x86)\Common Files\Intel\Shared Libraries\
F_IA32_REDIST11 = C:\Program Files (x86)\Common Files\Intel\Shared Files\fortran\

Thank you.

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;


class addJava {

    private native int add(int element, int iflag);

    public static void main(String args[]) {
	Native.setProtected(true);

	System.out.println(System.getProperty("jna.library.path"));
	System.out.println(System.getProperty("java.library.path"));
	System.load("/home/chaitra/Research/JAVA/examples/JNI/add/add.so");

        System.out.println("-- We are in the Java program JavaCode --");
        addJava result = new addJava();

        System.out.println("Call the C code");
        int sum = result.add(10, 0);

        System.out.println("-- We are back in Java --");
        System.out.println("Result = " + sum);
        System.out.println("Exit Java");
    }
}

I want to know how to call Java from Fortran i.e., Fortran -> C -> Java. I want to pass the value of variable c to a Java program that computes result=c+10 and returns the value to Fortran. How can this be done? Please help!

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

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

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

program p

   implicit none

   integer :: i(1)

   asc_1: associate ( j => i )

      asc_2: associate ( k => j )

      end associate asc_2

   end associate asc_1

   stop

end program p

------ Build started: Project: p, Configuration: Debug|x64 ------

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]...
p.f90
fortcom: Fatal: There has been an internal compiler error (C0000005).
compilation aborted for C:\..\p.f90 (code 1)

My new workstation runs RH Release 6.6 with Linux kernel 2.6.32-504.el6.x86_64, with a Xeon CPU & 64 GB RAM, etc.  Nothing else is different, however, now my Fortran routines with openMP calls to the BLAS lib (from Intel Libs) aren't maximizing core/thread usage (it looks like core/thread-swapping has gone "nutz") unless I set the number of threads to 1 in my execution script.  Have you seen this behavior with upgrades to the multicore/multithread CPUs?

Intel Visual Fortran falis to compile implicit class statements such as:

implicit class(foo) (a-b)
implicit class(*) (c)

gfortran had the same bug which was fixed in gfortran 4.9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56500

Trying to compile the code from the gfortran bug report gives:

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [IA-32]...
ifort /nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc120.pdb" /traceback /check:bounds /check:stack /libs:dll /threads /dbglibs /c /Qvc12 /Qlocation,link,"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\\bin""C:\Users\Nicholas\Documents\imp_bug\implicitclass\Source1.f90"
C:\Users\Nicholas\Documents\imp_bug\implicitclass\Source1.f90(8): error #5082: Syntax error, found '(' when expecting one of: (
  implicit class(foo) (a-b)
----------------------^
C:\Users\Nicholas\Documents\imp_bug\implicitclass\Source1.f90(9): error #5082: Syntax error, found '(' when expecting one of: (
  implicit class(*) (c)
--------------------^
(trimmed)

Is this a known bug?

This usage is relevant for people trying to simulate generic programming (templates) using a combination of implict, include and renaming in use statements.

Nick

The full error i'm getting is Unhandled exception at 0x0162EF4C in MAIN.exe: 0xC0000005: Access violation reading location 0x00000000

I think this is just a symptom of an underlying problem.  I've been struggling with these types of issues off and on for many years and have never figured out for sure why they happen.

I get this error only with a release build with the following settings:

/nologo /debug:full /O3 /Qipo /fpp /I"C:\Program Files (x86)\Intel\Composer XE\mkl\include\ia32" /I"C:\Program Files (x86)\MATLAB\R2010b\extern\include" /warn:all /debug-parameters:all /fp:fast=2 /Qfp-stack-check /module:"Release\INTERMEDIATE\\" /object:"Release\INTERMEDIATE\\" /Fd"Release\INTERMEDIATE\vc110.pdb" /check:uninit /libs:static /threads /Qmkl:sequential /c

When i run the debug build the program seems to run correctly.

If i throw a simple write statement:

write(*,*) 'hello'

before the line that this error occurred on, the program will run without throwing the error.  If i change the build settings to /O2 I can get it to run but produce incorrect results.

I ran the program in inspector, and i get a critical item "Unhandled application exception" and a "Invalid memory access" on the same line, but i don't see anything obvious that points to a cause for this error.

In my experience with these issues, i've seen lots of strange behavior for example a simple assignment statement where after execution the left hand side doesn't equal the right hand side, but then if the same statement is repeated the value will "stick".

I have no c functions being called (i had thought these were the problem previously).

Has anyone else run into this before?

rob

If I build and run the attached program I get

Method 1:
   {Monday   }
   {Tuesday  }
   {Wednesday}
   {Thursday }
   {Friday   }
   {Saturday }
   {Sunday   }

but I don't understand why. I'd have thought that it should be

Method 1:
   {Monday}
   {Tuesday}
   {Wednesday}
   {Thursday}
   {Friday}
   {Saturday}
   {Sunday}

which I can get by using trim(n) on line 22. Could someone please explain to me why I get the first result. Thanks.

Hello,

I bought three years ago a software FORTRAN from Intel. Recently I had a problem with my software. Then, I reinstalled it.
The program works well but I have a message when I try to connect me to internet with my 3G key.
The message that appears on my screen is: Run Time Error! Microsoft Visual C++ Runtime library
and I cannot connect me to internet.
If you have a solution to resolve this problem?
Best regards
Mr AURIA

I am trying to install the Fortran compiler (and associated libraries and linkers) on my MacBook Pro laptop -- a brand new (Yosemite) system.  I downloaded the "Academic Research Performance Libraries from Intel (OS X*)” to my Mac — a 1.1 Gbyte file named: m_ipp_8.2.1.108.mpkg. I then clicked on this file and went through the install procedure.  What do I do next? I found the webpage:

https://software.intel.com/en-us/articles/intel-compilers-for-linux-and-...

but there is no file "install.sh" in the distribution package as mentioned on the above page.  There is a file "link_install.sh" in /opt/intel/composer_xe_2015.1.108.  Is this the file I am to "launch".  How do I "launch" this, by the way -- by typing "sh link_install.sh"?

Along this line, is it really necessary, as a prerequisite (according to the above Intel webpage), to install the full Apple Xcode package?  Isn't it enough to just install the Command Line Tools (as I have done)?  Any general tips would be appreciated. 

Dear Service Team,

I have installed the parallel studio xe 2015 cluster version (30 days free). The installation was complete and sucessfull.

But I dont find any .exe file in installation folder for launching neither the fortran compiler nor the parallel studio in general.

When i do via the Start menu and the list of all programs, i can find a button for the "fortran compiler XE 15.0", but it just opens a bowser tab with the following link: file:///C:/Program%20Files%20(x86)/Intel/Composer%20XE%202015/Documentation/en_US/startup_common_w.htm

Do you know, how I can launch the fortran compiler or the parallel studio XE 2015?

For any help I would be very thankful,

Wilko