I have some code which is supposed to set up a structure foo of type t_stuff.  This type contains two allocatable arrays, boxes and stres.  One of these types has a pointer to the other:

!-----------------------------------------------------------------
      module data_n

      type :: t_box
        integer                  :: num
      end type t_box

      type :: t_str
        integer                  :: num
        type(t_box), pointer     :: begin
        type(t_box), pointer     :: end
      end type t_str

      type :: t_stuff
        type(t_box), allocatable :: boxes(:)
        type(t_str), allocatable :: stres(:)
      end type t_stuff

      end module data_n
!-----------------------------------------------------------------

      program test
      use data_n
      implicit none

      type(t_stuff) :: foo

      allocate(foo%boxes(2))
      allocate(foo%stres(1))

      foo%stres(1)%begin => foo%boxes(1)
      foo%stres(1)%end   => foo%boxes(2)

      end

When I compile this I get:

bb.f90(31): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [FOO]
      foo%stres(1)%begin => foo%boxes(1)
----------------------------^
bb.f90(32): error #6796: The variable must have the TARGET attribute or be a subobject of an object with the TARGET attribute, or it must have the POINTER attribute.   [FOO]
      foo%stres(1)%end   => foo%boxes(2)
----------------------------^

If I put the TARGET specifier in the t_stuff definition it complains too:

bb.f90(15): error #6516: This attribute specification is not valid for a component definition statement.   [TARGET]
        type(t_box), allocatable, target :: boxes(:)
----------------------------------^

How do I do this properly?

If I have a structure called fred which contains many variables, eg. x and y, is there a way to avoid keeping having to preface the variables everywhere I use them with "fred%".  This used to be available in Pascal as:

with fred
  begin
  x = 555
  y = 666
  end

Long shot...

In the manual I found:

EXTERNAL FACET
CALL BAR(FACET)
SUBROUTINE BAR(F)
EXTERNAL F
CALL F(2)

I would like something as:

SUBROUTINE BAR(F,t,y)
EXTERNAL, DIMENSION(1:2) :: F
EXTERNAL fun
fun = F(1)
CALL fun(t,y)
fun = F(2)
CALL fun(t,y)

and

f(1) = myode
f(2) = myresult

SUBROUTINE myode(t,y)
! do something
END

SUBROUTINE myresult(t,y)
! do something
END

Do you think it is possibile?

I found these two TYPE declarations are not welcome:

1. EXTERNAL in type is not accept

TYPE myvar
EXTERNAL :: fun
END TYPE

2. this trick is not allowed

TYPE myvec
INTEGER :: n
REAL*8, DIMENSION(1:n) :: x
END TYPE

Some workarounds is possible?

I had installed Parallel Studio XE 2015 Update 4 on a Windows 8.1 machine.  Integration into Microsoft Visual Studio 2013 worked with Inspector, Amplifier, and Advisor showing up in the VS menu bar.  Integration into Microsoft Visual Studio 2015 worked only for Amplifier.  I noticed in the "Program Files (x86)\Intel\VTune Amplifier XE 2015" folder the *.msi files for VS 2010, 2012, 2013, and 2015.  However, in the Inspector and Advisor folders I saw only the *.msi files for VS 2010, 2012, and 2013.  In the Inspector's bin32 folder I see inspxe-gui.exe but the same-named executable does not ocur in the Inspector's bin64 folder.  Is this a problem with installation?  Or is the integration with VS 2015 and the 64-bit inspxe-gui.exe planned for the next update?

I also wanted to run Inspector on a Windows 10 machine (with the Technical Preview).  Running from a command window (and the 32-bit version of inspxe-gui.exe which is all I appear to have), Inspector fails when trying to run on a project with "unknown operating system." Yet Amplifier runs on a Windows 10 machine, so I imagine it recognizes the operating system version.  Same question:  Is this a problem with installation?  Or will this support occur once Windows 10 and Visual Studio 2015 (RTM) ship?

Thanks.

Hi everybody,
This is my first attempt at library assembly, so please have mercy! Let me also start by saying to Steve Lionel: Wow, you answer a lot, I hope they are paying you well there at Intel!

I am trying to link an external library (written in .f90 and compiled with IVF on VS2012) to my Qt application (32bit based on Qt 5.5.0- MinGW 4.9.2).

I have a few questions:

1) Is this futile? Some of the research I have found suggests that IVF and MinGW are ABI incompatible. I really want to stay with the MinGW compiler in Qt because basically everything else we are doing with the software uses this.

2) It would be of advantage to be able to load the library only when called upon (which would only represent a fraction of cases). For this reason I have been attempting to use QLibrary but keep getting Segmentation faults when I try to call SUBROUTINES defined in my DLL (with resolve("my_function")):

I have defined my external call routines with:

 @ !DEC$ ATTRIBUTES C, REFERENCE, MIXED_STR_LEN_ARG, DLLEXPORT,   ALIAS:"sub_name" :: sub_name @
and import them using:

   @typedef int (*MyPrototype)(int i);
    MyPrototype Square = (MyPrototype) DLLname.resolve("sub_name"); @

3) Is there any way to check if the library has, in fact, loaded? Of course calling a subroutine would accomplish this, but that isn't working, and when I import the library DLLname.load() returns a positive result. and resolve.("sub_name") has a memoryaddress allocated to it. Does this suggest a type fault? Ie. passing the wrong identifier in to the fortran code.

Once again, thanks for reading and please feel free to take apart any flaws in logic I have, I'm not (yet) a programmer!

I wrote this Fortran module and I need its subroutines to run as fast as possible. My hope is to get some advice to optimize this code, and after having the serial version running as fast as it can run I will use MPI to make it parallel.

Module smearingmodule
IMPLICIT NONE
contains
subroutine smearing(i, nMCd, nPeriodT, nPeriods, DF, theta, wm) bind(C, name="smearing_")
    use, intrinsic                         :: iso_c_binding, only : c_double, c_int
    integer(c_int), intent(in)                                 :: i, nMCd, nPeriods
    integer(c_int), intent(in), dimension(nPeriods)            :: nPeriodT
    real(c_double), intent(in), dimension(i,5)        :: DF
    real(c_double), intent(in), dimension(i,nMCd)     :: theta
    real(c_double), dimension(nMCd, nPeriods), intent(out)  :: wm
    integer                                             :: d

    do d=1,nMCd
        CALL subsmearing(d, i, nMCd, nPeriodT, nPeriods, DF, theta, wm(d,:))
    end do

end subroutine smearing


subroutine subsmearing(d, i, nMCd, nPeriodT, nPeriods, DF, theta, wm)
    integer, intent(in)                                 :: d, i, nMCd, nPeriods
    integer, intent(in), dimension(nPeriods)            :: nPeriodT
    double precision, intent(in), dimension(i,5)        :: DF
    double precision, intent(in), dimension(i,nMCd)     :: theta
    double precision, dimension(nPeriods), intent(out)  :: wm
    double precision, allocatable, dimension(:,:)       :: out
    double precision, dimension(i,8)                    :: bigDF
    double precision, dimension(i)                      :: epredC, epredT, diff, A1, A2
    double precision, dimension(i,i)                    :: B1, B2
    integer                                             :: j, Period, jj
    double precision                                    :: sumWeights

    diff = 0.0d0
    wm = 0.0d0
    epredC = exp(DF(:,4) + (theta(:,d) * DF(:,1)))
    epredT = exp(DF(:,4) - (theta(:,d) * (1-DF(:,1))))

    do j=1,i
        B1(:,j)=epredT(j)
        B2(:,j)=epredC(j)
    end do

    A1 = matmul(DF(:,5), B1)
    A2 = matmul(DF(:,5), B2)

    diff = (A1-A2)/DBLE(i)

    bigDF(:,1:5) = DF
    bigDF(:,6) = epredC
    bigDF(:,7) = epredT
    bigDF(:,8) = diff

    do jj =1, nPeriods
        ALLOCATE(out(nPeriodT(jj),7))
        CALL subsetPeriod(bigDF, i, 8, nPeriodT(jj), jj, out) !Filters data
        sumWeights = sum(out(:,2))
        do j=1, nPeriodT(jj)
            wm(jj) = wm(jj) + (out(j,7)*out(j,2)/sumWeights)
        end do
        DEALLOCATE(out)
    end do

end subroutine subsmearing

subroutine subsetPeriod(A, rowA, colA, rowB, Period, B)
    double precision, dimension(rowA, colA), intent(in)    :: A
    integer, intent(in)                                    :: rowA, colA, rowB, Period
    double precision, dimension(rowB,colA-1), intent(out)  :: B
    integer                                                :: i, pos

    pos = 1
    do i = 1, size(A,1)
        if(A(i,2)==Period)then
            B(pos,1) = A(i,1)
            B(pos,2:) = A(i,3:)
            pos = pos+1
        end if
    end do
end subroutine subsetPeriod

end module smearingmodule

Is there anything in my code that could be done in a more efficient way?

Thanks a lot!

Hi, I see and ICE with the attached code, both versions (A) and (B).

$ ifort -c ice.f90
ice.f90(33): warning #6178: The return value of this FUNCTION has not been defined.   [Y]
 pure recursive function unpck(x) result(y)
-----------------------------------------^
ice.f90(45): catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for ice.f90 (code 1)

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0 Build 20150407

module m

 implicit none

 public :: t_base, unpck

 private

 type, abstract :: t_base
 contains
  private
  generic, public :: operator(+) => add
  procedure(i_add), pass(x), deferred :: add
 end type t_base

 type, extends(t_base) :: t_cont
  class(t_base), allocatable :: f
 contains
  procedure, pass(x) :: add => cont_add
 end type t_cont

 abstract interface
  elemental function i_add(x,y) result(z)
   import :: t_base, t_cont
   implicit none
   class(t_base), intent(in) :: x, y
   type(t_cont) :: z
  end function i_add
 end interface

contains

 pure recursive function unpck(x) result(y)
  class(t_base), intent(in) :: x
  class(t_base), allocatable :: y

 end function unpck

 elemental function cont_add(x,y) result(z)
  class(t_cont), intent(in) :: x
  class(t_base),  intent(in) :: y
  type(t_cont) :: z

   ! Both these lines produce an ICE
   z = unpck(x) + unpck(y) ! (A)
   !allocate( z%f , source=unpck(x)+unpck(y) ) ! (B)

 end function cont_add

end module m

I am still involved with a legacy program that has many very old components (30 - 40 years old).  We have recently migrated from g77 to Intel Fortran, and things are going well.  Recently, the original author summarized a test that he ran, and mentioned that g77 and ifort behave differently when "array overruns" occur, i.e., an out-of-bounds array index is referenced.  So I suggested we try catching array overruns when they occur, i.e., not wait for memory corruption, and use '-check bounds' when we run tests.

I am very impressed by how this compiler option works.  In half a day, I have found about a dozen array overruns (even caught one at compile time!), and have not even begun to execute realistic scenarios.  In an application this old, we will find many more, I am sure, and it will further contribute to the robustness of the program.

Just one issue:  When I execute under gdb and an index out-of-bounds is discovered, the program does not break immediately into gdb.  Rather, the error is reported, and gdb is entered after the program terminates.

We are using version 15, update 2, on Red Hat Enterprise Linux 6.

Here is a tiny example.  I have purposely created a test case with ancient style that matches the old code.

      PROGRAM TEST
      INTEGER I,ARR(100)
      I=0
1     I=I+1
      ARR(I)=I
      PRINT *,I
      GOTO 1
      END

The idea is that we have an array of 100 elements, and march right through the end until we are "caught".  Each index is printed as we go.

First, I compile with: ifort -c -debug test.for

If I run without gdb, the program simply dies when I get to I=568.  So I run with gdb, and it breaks into gdb when it detects something is wrong (too late, of course):

         567
         568
Program received signal SIGSEGV, Segmentation fault.
0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64 libgcc-4.4.7-11.el6.x86_64
(gdb) bt
#0  0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000040f931 in for__aio_acquire_lun ()
#2  0x0000000000428613 in for__acquire_lun ()
#3  0x0000000000408ad9 in for_write_seq_lis ()
#4  0x0000000000402d20 in test () at test.for:6
#5  0x0000000000402c7e in main ()
(gdb) bt
#0  0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000040f931 in for__aio_acquire_lun ()
#2  0x0000000000428613 in for__acquire_lun ()
#3  0x0000000000408ad9 in for_write_seq_lis ()
#4  0x0000000000402d20 in test () at test.for:6
#5  0x0000000000402c7e in main ()

As usual, I can get a complete backtrace.

Next, I compile with: ifort -c -debug -check bounds test.for

Running without gdb, the program now correctly crashes when I get to 101:

          99
          100
forrtl: severe (408): fort: (2): Subscript #1 of the array ARR has value 101 which is greater than the upper bound of 100
Image              PC                Routine            Line        Source            
test               0000000000404860  Unknown               Unknown  Unknown
test               0000000000402DAA  Unknown               Unknown  Unknown
test               0000000000402C7E  Unknown               Unknown  Unknown
libc.so.6          0000003B6DA1ED5D  Unknown               Unknown  Unknown
test               0000000000402B89  Unknown               Unknown  Unknown

 
In a program this small, the location of the bug is obvious.  But in a large program, just knowing the name of the array is not always enough information to find the place in the code where the overrun occurs.  So I run with gdb ,and the following occurs:

          99
         100
forrtl: severe (408): fort: (2): Subscript #1 of the array ARR has value 101 which is greater than the upper bound of 100
Image              PC                Routine            Line        Source            
test               0000000000404860  Unknown               Unknown  Unknown
test               0000000000402DAA  Unknown               Unknown  Unknown
test               0000000000402C7E  Unknown               Unknown  Unknown
libc.so.6          0000003B6DA1ED5D  Unknown               Unknown  Unknown
test               0000000000402B89  Unknown               Unknown  Unknown
Program exited with code 0230.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64 libgcc-4.4.7-11.el6.x86_64
(gdb) bt
No stack.

In other words, the crash is detected as before, but break in the program is too late, so the backtrace does not guide me to the line of code where the error is detected.

Jay 

This topic must have been beaten to death, but the issue I've encountered seems very odd.

Here is the C code:

void test_array(int *, int *, double **); // To test accessing a Fortran 2D array.

void test_get_array()

{

    int i;

    int narr1, narr2;

    double *farr;

    test_array(&narr1, &narr2, &farr);

    for (i=0;i<narr1*narr2; i++)

        printf("%d %f\n",i,farr[i]);

}

and the Fortran:

subroutine test_array(narr1, narr2, cptr) bind(C)
!DEC$ ATTRIBUTES DLLEXPORT :: test_array
use, intrinsic :: iso_c_binding
integer(c_int) :: narr1, narr2
TYPE (C_PTR)    :: cptr
real(c_double), allocatable, target :: a(:,:)
integer :: i1, i2
integer :: n1=4, n2=3

allocate(a(n1,n2))
do i1 = 1,n1
    do i2 = 1,n2
        a(i1,i2) = i1 + 10*i2
    enddo
enddo

narr1 = n1
narr2 = n2
cptr = c_loc(a)
write(*,'(4f6.0)') a

end subroutine

This is the output:

11. 12. 13. 14.

21. 22. 23. 24.

31. 32. 33. 34.

0 0.000000

1 12.000000

2 13.000000

3 14.000000

4 21.000000

5 22.000000

6 23.000000

7 24.000000

8 31.000000

9 32.000000

10 33.000000

11 34.000000

What has happened to the first array entry?

Hang on!  I just remembered seeing something about SAVE.  When I add that to the declaration of a(:) I get the first entry correctly.  I'm guessing that not SAVEing immediately clobbers the start of the array somehow on subroutine return.  I decided to leave the post here because the phenomenon is interesting and I'd like to see comments on it.

Thanks

Gib

This will not be an easy question to handle for anyone as it involves a lot of variables. We shifted on to Windows 8.1 and started observing this issue.

OS: Windows 8.1 Enterprise

VS: Visual Studio 2008 SP1

VF: Intel(R) Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3469.2008

When you have variables added to the watch window and are stepping through the code (F10), Visual Studio can take up to 3 seconds going through each line when going through Fortran projects. The mouse cursor would change to waiting (small circle) when the program is waiting to move to the next line. This depends on the number of variables that are being added to the Watch window i.e. a couple of variable then wait time may be less than 0.1 second, up to say 50 variables wait time > 3 seconds each line. If you get rid of all the variables in the watch window, debugging would run smoothly without any delays.

We started observing this issue with Windows 8.1. Windows 7 did not have this issue keeping all the other installations the same. I tried to reproduce the same issue on a VM, but could not and the debugging ran smoothly for the same project regardless of the number of variable added to the watch window. May be it is because of some Hotfix.

This is really frustating to us, and any help from your guys would be hugely appreciated.

Thank you.

Another issue while experimenting with type bound operators: ifort (version 15.0) rejects the attached code, which I think is correct (some comments in the code itself, close to the line producing the error).

$ ifort -c test.f90

test.f90(34): warning #6178: The return value of this FUNCTION has not been defined.   [Y]
 pure recursive function unpck(x) result(y)
-----------------------------------------^
test.f90(40): warning #6178: The return value of this FUNCTION has not been defined.   [Z]
 elemental function cont_add(x,y) result(z)
-----------------------------------------^
test.f90(70): warning #6178: The return value of this FUNCTION has not been defined.   [Z]
 elemental function add(x,y) result(z)
------------------------------------^
test.f90(126): error #6355: This binary operation is invalid for this data type.   [DAT]
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
---------------------------------------^
test.f90(126): error #6355: This binary operation is invalid for this data type.   [YUNP]
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
---------------------------------------------^
test.f90(126): error #6549: An arithmetic or LOGICAL type is required in this context.
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
-------------------------------------------^
test.f90(100): warning #6178: The return value of this FUNCTION has not been defined.   [NEWB]
 pure function new_t_b(dat) result(newb)
-----------------------------------^
compilation aborted for test.f90 (code 1)

module m1

 implicit none

 public :: &
   t_abstr, t_cont, unpck

 private

 type, abstract :: t_abstr
 contains
  private
  generic, public :: operator(+) => add
  procedure(i_add), pass(x), deferred :: add
 end type t_abstr

 type, extends(t_abstr) :: t_cont
  class(t_abstr), allocatable :: f
 contains
  procedure, private, pass(x) :: add => cont_add
 end type t_cont

 abstract interface
  elemental function i_add(x,y) result(z)
   import :: t_abstr, t_cont
   implicit none
   class(t_abstr), intent(in) :: x, y
   type(t_cont) :: z
  end function i_add
 end interface

contains

 pure recursive function unpck(x) result(y)
  class(t_abstr), intent(in) :: x
  class(t_abstr), allocatable :: y

 end function unpck

 elemental function cont_add(x,y) result(z)
  class(t_cont), intent(in) :: x
  class(t_abstr),  intent(in) :: y
  type(t_cont) :: z

 end function cont_add

end module m1

!-----------------------------------------------------------------------

module m2

 use m1, only: &
   t_abstr, t_cont, unpck

 implicit none

 public :: &
   t_a

 private

 type, extends(t_abstr) :: t_a
 contains
  procedure, private, pass(x) :: add
 end type t_a

contains

 elemental function add(x,y) result(z)
  class(t_a), intent(in) :: x
  class(t_abstr), intent(in) :: y
  type(t_cont) :: z

 end function add
end module m2

!-----------------------------------------------------------------------

module m3

 use m1, only: &
   t_abstr, t_cont, unpck

 use m2, only: &
   t_a

 implicit none

 private

 type, extends(t_abstr) :: t_b
  type(t_cont), allocatable :: dat(:)
 contains
  procedure, pass(x) :: add
 end type t_b

contains

 pure function new_t_b(dat) result(newb)
  type(t_cont), intent(in) :: dat(:)
  type(t_b) :: newb

 end function new_t_b

 elemental function add(x,y) result(z)
  class(t_b), intent(in) :: x
  class(t_abstr), intent(in) :: y
  type(t_cont) :: z

  class(t_abstr), allocatable :: yunp

   allocate( yunp , source=unpck(y) )
   select type(yunp)
    type is(t_a)

     ! Note:
     !
     ! x%dat has type  type(t_cont), allocatable, dimension(:)
     ! yunp has type  type(t_a)
     !
     ! Since both  t_cont  and  t_a  extend  t_abstr, the elemental
     ! type bound function "add" should be called. In particular,
     ! given that the first argument is the passed one, x%dat%cont_add
     ! should be called.
     allocate( z%f , source=new_t_b( x%dat + yunp ) )

   end select

 end function add

end module m3

Dear all,

I would like to create a program with #ifdef and #endif compilation options  but I do not know how could i compile even tis simple hello program:

PROGRAM HELLO
IMPLICIT NONE

#ifdef PARALLEL
  WRITE(*,*) 'OPTION A'
#endif

 WRITE(*,*) 'OPTION A+B'

END PROGRAM

When I compile, I get this error:

hello.f90(4): warning #5117: Bad # preprocessor line
#ifdef PARALLEL
-^
hello.f90(6): warning #5117: Bad # preprocessor line
#endif

Can someone explain me how to compile and activate or not activate options A and B.

Really Really thanks

Greetings,

I'm writing an ABAQUS FILM user subroutine.  The subroutine uses many supporting modules to get the job done, and works well with a dummy driver.  I'm most experienced writing stand-alone code, i..e., main + subs.  How do I compile in Visual Studio to create a single *.obj with only the sub and supporting modules to present to ABAQUS?  Excluding the main dummy program from the build generates an error regarding the missing external routine.  Failing that can I manually concatenate the many obj files VS makes into a single file, or must I concatenate the modules' source code to generate a single obj file?

Also: How can I get Visual Studio to create a makefile (NMAKE?) from the IDE so other users can recompile from the command line?  The HELP leaves me confused.  Creating a Makefile from scratch is always a painful exercise for me, and presenting the many supporting modules to the linker begs for a script.

Thanks,

John W

Hi there,

I have been using the Inspector XE Beta fairly successfully but on my recent run Inspector reported an internal error and ended the analysis. It also states that I should contact the Intel Support team.

The Inspector reports several data race conditions with 'for__acquire_lun' which I haven't seen before.

I should say that I am working with Fortran on a linux system. I have also created an Intel Premier support issue where I have uploaded the results dir.

Also, I have been trying to make use of the Intel Collection Control API with Inspector but it doesn't seem to work at all. I am using the commands:

    CALL itt_suppress_push(itt_suppress_all_errors)     ! Stop Inspector collection
    CALL itt_suppress_push(itt_suppress_threading_errors)     ! Stop Inspector collection
    CALL itt_suppress_push(itt_suppress_memory_errors)     ! Stop Inspector collection

to push, and the following to pop:

CALL itt_suppress_pop()
CALL itt_suppress_pop()
CALL itt_suppress_pop()

I am calling these within serial sections of the code, but prior to the OpenMP parallel sections I want to analyse. Any clues as to why it doesn't seem to work?

Thanks,

Ewan

Hi, Guys,

Does anyone see this warning message before?

How to fix it?

Incorrect setting of the registers of the graphics chip:

Jul 6 18:54:51 i7IvyBridge kernel: [drm] Wrong MCH_SSKPD value: 0x20100406

Jul 6 18:54:51 i7IvyBridge kernel: [drm] This can cause pipe underruns and display issues.

Jul 6 18:54:51 i7IvyBridge kernel: [drm] Please upgrade your BIOS to fix this.

Dear All,

There appears to be an obscure bug in version 15 of the Fortran compiler involving MPI, OpenMP and string passing all together.

We're running on Intel hardware under Linux. First the compiler:

mpif90 --version

ifort (IFORT) 15.0.3 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

... now the smallest code I could devise which still has the bug:

program test
implicit none
integer i
!$OMP PARALLEL DEFAULT(SHARED)
!$OMP DO
do i=1,10
  call foo
end do
!$OMP END DO
!$OMP END PARALLEL
end program

subroutine foo
implicit none
character(256) str
call bar(str)
return
end subroutine

subroutine bar(str)
implicit none
character(*), intent(out) :: str
write(str,'(I1)') 1
return
end subroutine

... compiling with:

mpif90 -openmp test.f90

... results in code which crashes randomly with OMP_NUM_THREADS greater than one. This does not occur with version 14 of the compiler.

Regards,

John.

Dear folks,

I am using

>ifort -O3 -xHost -ipo

to compile a huge program package including a NAG Library file and get the following error message:

NAG_TProp.f(8887): remark #7922: The value was too small when converting to REAL(KIND=8); the result is in the denormalized range.   [1.11253692925361D-308]
      DATA X02CON /1.11253692925361D-308 /
-------------------^

The corresponding function in the file in which the error occurs looks like this

      DOUBLE PRECISION FUNCTION X02AMF()
C     MARK 12 RELEASE. NAG COPYRIGHT 1986.
C
C     RETURNS THE 'SAFE RANGE' PARAMETER
C     I.E. THE SMALLEST POSITIVE MODEL NUMBER Z SUCH THAT
C     FOR ANY X WHICH SATISFIES X.GE.Z AND X.LE.1/Z
C     THE FOLLOWING CAN BE COMPUTED WITHOUT OVERFLOW, UNDERFLOW OR OTHER
C     ERROR
C
C        -X
C        1.0/X
C        SQRT(X)
C        LOG(X)
C        EXP(LOG(X))
C        Y**(LOG(X)/LOG(Y)) FOR ANY Y
C
      DOUBLE PRECISION X02CON
      DATA X02CON /1.11253692925361D-308 /
C     .. Executable Statements ..
      X02AMF = X02CON
      RETURN
      END

My ifort version is

>ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Is this a compiler problem? Are there any option I could try? I also couldn't find a 'newer' version of the NAG Routine online, so I can't tell if this occurs only with this quite old version.

Thank you in advance,

Maja

Hi,

while importing the open-source project CP2K, I came across a problem with parsing the input files. Opening the attached file d3_poly.F in Visual Studio 2015 with Intel Parallel Studio XE 2015 U4 immediately crashes the Visual Studio UI for me. Can anybody confirm this issue?

Kind regards,

Guido

I am new to using Intel's Parallel Studio XE Cluster Edition.  I am used to using Gdb and Valgrind for debugging.  I have just begun using Intel Inspector XE.  I was wondering if there is any capability in the Parallel Studio XE Cluster package to step through parallel programs and investigate/change individual variable values similar to Gdb, as well as, step different processors independently?  I have not been able to find that functionality as of yet.  Thanks!