Intel® Fortran Studio XE

Intel Software Tools Technical Webinar Series

These free technical webinars cover tips and techniques that will help sharpen your development skills to create faster, more reliable applications. Technical experts will cover topics ranging from vectorization, code migration, code optimization, using advanced threading techniques (e.g., OpenMP 4.0, Intel® Cilk™ Plus, Intel® TBB), and error checking. Bring programming questions to the live session for our technical experts to answer. A replay of each webinar will be available shortly after the live session so you can share with those unable to attend the live session.

VOLATILE on POINTER

The documentation is a little unclear on this, or perhaps I'm mis-reading it.  If I were to declare a variable as a POINTER, and then mark it as VOLATILE, is this marking the pointer as VOLATILE, or the memory region that it points to?  I need to mark the latter.  In this example, I have a structure, BAR, which I want to be able to grow in size as the program progresses, and I have already mapped the HMM common area to global shared memory between multiple processes, as well as the contents of BAR.  When I expand the array, I call a routine that remaps the new addresses of BAR to global, bu

About ~/intel/ism/rm

Hi,

I apologize in advance if this is the wrong forum for the question.

Why is the ~/intel/ism/rm directory created whenever I run the ifort command, even if, during installation, I did choose not to participate in the improvement program?

--

John.



 

problem with openmp directives in gedit/emacs

Hello everyone,

I am facing an awkward situation. I am trying to run a f90 program in Linux with ifort and since it has openmp directives I compile it with the -openmp-report1 option to see that whether the blocks have been successfully parallelized.

The problem  is that gedit doesn't recognize the openmp directive:

!$omp parallel do etc.

it treats it as a comment. Anyone has an idea about it? I also tried

write(*,*) in function called by another write(*,*)

Hello,

I used to put some "write(*,*)" in my code when I want quick and easy checks of what is happening.

Today I encountered an error while doing this with ifort :

Here the sample program :

program test
implicit none

write(*,*) func(),func()

contains

function func()
real(8) :: func
func=0.d0
write(*,*) "Inside func"
end function func

And the output:

 forrtl: severe (40): recursive I/O operation, unit -1, file unknown

Debug/release versions of .mod files

If I have separate debug and release versions of a Fortran module, the difference being solely one of compiler flags, will the .mod file differ between them? In other words, is it necessary/advisable to change my include path depending on which version of the module I link to? I know the .mod file is a compiler-generated binary, but as a Fortran newbie coming from a C background I'm not sure whether I should be thinking of it as akin to a precompiled header or more like an object file in its own right.

Thanks,

Simon

Different results with -O0 -openmp or -O3 -openmp

Hi all, 

I developed a FORTRAN (F90) code (its a large model) with the following compilation flags :

ifort -g -O0 -openmp -openmp_report -threads -ipo

When running this code with the above flags, I keep the results within 15 digits after the dot when running serial or parallel (OpenMP). I have also checked with Intel Inspector 2013 - and I do not have any data race condition in either if the subroutines.

inconsistent treatment of TYPE vs. REAL in 'stream' write with Intel big-endian I/O conversion

I'm seeing different bit patterns when I write a REAL variable to file as component of a TYPE as opposed to when it's just a REAL in stream output while using the -convert big_endian option.

Given the following small program, which opens a file in 'stream' access mode and the proceeds to write two REAL's:

$ cat stream-write.f90
PROGRAM foo
  IMPLICIT NONE
  TYPE bar
    real :: x
  END TYPE bar
  INTEGER, PARAMETER :: file_id = 20
  INTEGER :: ierror
  REAL :: y
  TYPE(bar) :: z

Deferred length string component: segmentation fault

In a project I am working on, I changed a fixed length string in a structure within a module to a deferred length string and the result was an internal compiler error (the code compiled and ran without issue before the change).  I cannot reproduce the internal compiler error with a simple case, but I do get a segmentation fault in the below program when it hits the WRITE() statement.  It is unclear to me what the issue is or if this is even related to the internal compiler error I was trying to reproduce.  When compiling with '-std03', I get "warning #5436: Overlapping storage initializatio

Intel® Fortran Studio XE abonnieren