Quantcast
Channel: Fortran
Viewing all 3108 articles
Browse latest View live

Possible bug on abstract type

$
0
0

Dear great Intel Fortran Developers team,

I would like to report a possible bug in ifort 15.0.3.

I am trying to develop an OOP library that takes advantage of Abstract Calculus Pattern by means of an abstract type definition. In a very few words, the library defines an abstract type with some operators overloading deferred and it provides a procedure that operates on the abstract type. The concrete extensions of the abstract type implement only the type bound procedures deferred whereas the overloaded operators are defined by the abstract type. The real code is here https://github.com/Fortran-FOSS-Programmers/FOODiE/blob/master/src/lib/type_integrand.f90

A minimal example raising the possible bug is reported below. There are 3 modules and 1 main program: 1) type_abstract_buggy provides the abstract type, 2) lib_abstract_buggy provides a procedure working on the abstract type that raises the possible bug, 3) type_buggy implements a concrete extension of the abstract type defining only the procedures for the operators overloading and 4) is the main program using the last 2 modules. 

The expected results are:

Array: 

  1.00000000
  2.00000000
  3.00000000
Scalar:     3
Array:
  2.00000000
  4.00000000
  6.00000000
Scalar:     3
Array:
  4.00000000
  8.00000000
  12.0000000
Scalar:     3
 

but when compiling with ifort 15.0.3 complains with following errors. 

ifort-bug.f90(58): error #6633: The type of the actual argument differs from the type of the dum

my argument.   [BUG]
 bug = scalar * bug
-----------------^
ifort-bug.f90(146): error #7013: This module file was not generated by any release of this compi
ler.   [LIB_ABSTRACT_BUGGY]
use lib_abstract_buggy, only : raise_bug
----^
ifort-bug.f90(149): error #6457: This derived type name has not been declared.   [BUGGY]
type(buggy) :: bug
-----^
ifort-bug.f90(151): error #6404: This name does not have a type, and must have an explicit type.
  [BUG]
bug = buggy(array=[1., 2., 3.], scalar=3)
^
ifort-bug.f90(151): error #6632: Keyword arguments are invalid without an explicit interface.   
[ARRAY]
bug = buggy(array=[1., 2., 3.], scalar=3)
------------^
ifort-bug.f90(151): error #6632: Keyword arguments are invalid without an explicit interface.   
[SCALAR]
bug = buggy(array=[1., 2., 3.], scalar=3)
--------------------------------^
ifort-bug.f90(152): error #6406: Conflicting attributes or multiple declaration of name.   [RAIS
E_BUG]
call raise_bug(bug=bug, scalar=2)
-----^
ifort-bug.f90(146): error #6580: Name in only-list does not exist.   [RAISE_BUG]
use lib_abstract_buggy, only : raise_bug
-------------------------------^
ifort-bug.f90(147): error #6580: Name in only-list does not exist.   [BUGGY]
use type_buggy, only : buggy
-----------------------^
compilation aborted for ifort-bug.f90 (code 1)
 

The compilation is done by: ifort -O0 -debug all -check all -warn all -traceback -assume realloc_lhs -std08 ifort-bug.f90

Note that the correct result is obtained by GNU gfortran 5.2.

Minimal example raising the possible compiler bug

 

module type_abstract_buggy
implicit none
private
public :: abstract_buggy

type, abstract :: abstract_buggy
  contains
    ! public methods
    procedure(abstract_printf), public, deferred :: printf
    generic,                    public           :: operator(*) => buggy_multiply_scalar, scalar_multiply_buggy
    generic,                    public           :: assignment(=) => buggy_assign_buggy
    ! private methods
    procedure(abstract_buggy_multiply_scalar),       pass(lhs), private, deferred :: buggy_multiply_scalar
    procedure(scalar_multiply_abstract_buggy),       pass(rhs), private, deferred :: scalar_multiply_buggy
    procedure(abstract_buggy_assign_abstract_buggy), pass(lhs), private, deferred :: buggy_assign_buggy
endtype abstract_buggy
abstract interface
  subroutine abstract_printf(self)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN) :: self
  endsubroutine abstract_printf

  function abstract_buggy_multiply_scalar(lhs, rhs) result(multy)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN)  :: lhs
  integer,               intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction abstract_buggy_multiply_scalar

  function scalar_multiply_abstract_buggy(lhs, rhs) result(multy)
  import :: abstract_buggy
  integer,               intent(IN)  :: lhs
  class(abstract_buggy), intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction scalar_multiply_abstract_buggy

  pure subroutine abstract_buggy_assign_abstract_buggy(lhs, rhs)
  import :: abstract_buggy
  class(abstract_buggy), intent(INOUT) :: lhs
  class(abstract_buggy), intent(IN)    :: rhs
  endsubroutine abstract_buggy_assign_abstract_buggy
endinterface
endmodule type_abstract_buggy

module lib_abstract_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: raise_bug
contains
  subroutine raise_bug(bug, scalar)
  class(abstract_buggy), intent(INOUT) :: bug
  integer,               intent(IN)    :: scalar

  call bug%printf()
  bug = bug * scalar
  call bug%printf()
  bug = scalar * bug
  call bug%printf()
  endsubroutine raise_bug
endmodule lib_abstract_buggy

module type_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: buggy

type, extends(abstract_buggy) :: buggy
  private
  real, dimension(:), allocatable :: array
  integer                         :: scalar=0
  contains
    ! public methods
    procedure, pass(self), public :: printf
    ! private methods
    procedure, pass(lhs), private :: buggy_multiply_scalar
    procedure, pass(rhs), private :: scalar_multiply_buggy
    procedure, pass(lhs), private :: buggy_assign_buggy
endtype buggy
interface buggy
  procedure create_buggy
endinterface
contains
  pure function create_buggy(array, scalar) result(bug)
  real, dimension(:), intent(IN) :: array
  integer,            intent(IN) :: scalar
  type(buggy)                    :: bug

  bug%array = array
  bug%scalar = scalar
  return
  endfunction create_buggy

  subroutine printf(self)
  class(buggy), intent(IN) :: self
  integer      :: i

  print "(A)", "Array:"
  do i=1, size(self%array)
    print*, self%array(i)
  enddo
  print "(A,I5)", "Scalar: ", self%scalar
  endsubroutine printf

  function buggy_multiply_scalar(lhs, rhs) result(multy)
  class(buggy), intent(IN)           :: lhs
  integer,      intent(IN)           :: rhs
  class(abstract_buggy), allocatable :: multy
  type(buggy),           allocatable :: multy_tmp

  allocate(buggy :: multy_tmp)
  multy_tmp%array = lhs%array * rhs
  multy_tmp%scalar = lhs%scalar
  call move_alloc(multy_tmp, multy)
  return
  endfunction buggy_multiply_scalar

  pure function scalar_multiply_buggy(lhs, rhs) result(multy)
  integer,      intent(IN)           :: lhs
  class(buggy), intent(IN)           :: rhs
  class(abstract_buggy), allocatable :: multy
  type(buggy),           allocatable :: multy_tmp

  allocate(buggy :: multy_tmp)
  multy_tmp%array = rhs%array * lhs
  multy_tmp%scalar = rhs%scalar
  call move_alloc(multy_tmp, multy)
  return
  endfunction scalar_multiply_buggy

  pure subroutine buggy_assign_buggy(lhs, rhs)
  class(buggy),          intent(INOUT) :: lhs
  class(abstract_buggy), intent(IN)    :: rhs

  select type(rhs)
  class is(buggy)
    if (allocated(rhs%array)) lhs%array = rhs%array
    lhs%scalar = rhs%scalar
  endselect
  return
  endsubroutine buggy_assign_buggy
endmodule type_buggy

program ifort_bug
use lib_abstract_buggy, only : raise_bug
use type_buggy, only : buggy
implicit none
type(buggy) :: bug

bug = buggy(array=[1., 2., 3.], scalar=3)
call raise_bug(bug=bug, scalar=2)
stop
endprogram ifort_bug

 


Visual Studio 2010 imported CVF project is not a fortran project

$
0
0

I have imported many CVF projects, but yesterday I imported a project that is showing up in Visual Studio as a C project instead of a fortran project.  The import did produce a .vcxproj and .vfproj files along with the .sln file.  The project property pages are for C instead of fortran.  What did I do wrong?  Should I start over?

Thread Local Storage

$
0
0

I have a requirement for a large .dll to be re-initialized.  (So, basically, all the SAVE variables, all the DATA variables, all the COMMON variables, need to be reset to their starting values).  I've been using the FreeLibrary() LoadLibrary() WinAPI functions for this purpose, but I've come across Thread Local Storage as an interesting alternative that would possibly work a little bit faster.  (We're not using OpenMP, just a single threaded .dll and its caller).  Is it possible to compile a Fortran .dll to default to Thread Local Storage?

ICE with valid code

$
0
0

The following code produces an ICE with ifort 15.0 Build 20150407 (on Linux Intel(R) 64)

$ ifort -c testice.f90
testice.f90(50): warning #6178: The return value of this FUNCTION has not been defined.   [RES]
 elemental function met1(f) result(res)
-----------------------------------^
testice.f90(44): warning #6178: The return value of this FUNCTION has not been defined.   [RES]
 elemental function cnt_met1(f) result(res)
---------------------------------------^
testice.f90(38): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value.   [Y]
 elemental subroutine to_ta(y,x)
----------------------------^
testice.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** 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 testice.f90 (code 1)

module m1
 implicit none

 type, abstract :: c_base
 contains
  private
  generic, public :: method => met1
  procedure(i_met1), pass(f), deferred :: met1
 end type c_base

 type, extends(c_base) :: t_cnt
 contains
  private
  procedure, pass(f) :: met1 => cnt_met1
 end type t_cnt

 type, extends(c_base) :: t_a
 contains
  private
  procedure, pass(f) :: met1
 end type t_a

 abstract interface
  elemental function i_met1(f) result(res)
   import :: c_base, t_cnt
   implicit none
   class(c_base), intent(in) :: f
   type(t_cnt) :: res
  end function i_met1
 end interface

 interface assignment(=)
   module procedure to_ta
 end interface

contains

 elemental subroutine to_ta(y,x)
  type(t_cnt), intent(in)  :: x
  type(t_a),  intent(out) :: y

 end subroutine to_ta

 elemental function cnt_met1(f) result(res)
  class(t_cnt), intent(in) :: f
  type(t_cnt) :: res

 end function cnt_met1

 elemental function met1(f) result(res)
  class(t_a), intent(in) :: f
  type(t_cnt) :: res

 end function met1

end module m1

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

module m2
 use m1
 implicit none

 type :: t_g
  type(t_a), allocatable :: aa(:,:), bb(:)
 end type t_g

contains

 subroutine s()

  integer :: i
  type(t_g) :: a

  allocate( a%aa(1,3), a%bb(3) )

  a%aa(1,:) = a%bb%method() ! ICE

  do i=1,3
    a%aa(1,i) = a%bb(i)%method() ! works
  enddo

 end subroutine s

end module m2

 

Polyhedron Fortran compilers benchmark

$
0
0

I'm sorry - I sent erroneously my message to Fortran/Windows forum, and repeat now. The Polyhedron Fortran benchmark is absent know,

and in particular is absent well known html:

http://www.polyhedron.com/compare0html

Do somebody have relative new (not too old) corresponding data ? I myself is sure that Intel Fortran benchmark results are the best, but I need this

data to prepare short information in our grant proposal.

 

Mikhail Kuzminsky

Pass Array of Pointers from a C++ function into a Fortran subroutine

$
0
0

I am attempting to pass a C++ array of pointers into a Fortran subroutine.

The C++ array is of a structure, which exactly conforms to a Fortran derived type.

So in C++ I have pArray* c_arr[DIM1][DIM2];

Then I call a Fortran sub, passing in the C++ array of pointers like fortsub(c_arr[0][0])

In Fortran I have Subroutine fortsub (fort_arr) where I need fort_arr to be a container for the array of pointers.

I currently do not know how to make this work, I have something like:

Type (type1), Dimension(2,*), Target :: fort_arr where type1 is the same type as pArray.

Basically, my problem is I don't know how to pass a double dimensioned array of C++ structure pointers into a Fortran subroutine.

I know that he concept of "array of pointers" does not exist in Fortran and the way you have to do it is have an array of derived type with a pointer component, but I cannot seem to get the data passing on the argument list correct.

Anyone have some advice, perhaps with a specific example? I would appreciate it greatly. Thanks.

Compiling with DEC/VAC and IBM/VS Extensions?

$
0
0

I have some old legacy code I'm trying to compile, which was originally compiled on the Lahey LF90 compiler. When I tried compiling using gfortran and then ifort, the program compiled but when running the program I got vastly different results. When I talked to the original author, he said he had to specify -vax while compiling in order to compile code which uses the DEC/VAX and IBM/VS extensions. Rewriting the code is not at all a good option, as the code is ridiculously long and I haven't found any good resources saying how to convert back to regular fortran 77. 

I've been trying to find what the equivalent option with ifort is, but all I've found is -Vaxlib (which doesn't appear to exist anymore?) or -vax which didn't work at all, or things saying that it should be done automatically, which obviously wasn't the case. So what do I need to do to compile this code? 

Any help would be greatly appreciated, thanks!

OpenMP slower than serial codes

$
0
0

Hi,

I am trying to do the parallelization of a serial preconditioned conjugate gradient solver codes for 3D fire simulation using OpenMP (Intel compiler). But the performance seems not to be improved.

The grid dimension is 79x81x79 and the solver can converge after 565 iterations. The serial codes cost 3.39 seconds and the OpenMP version needs 3.86 seconds on Intel i7 2600.

Please help me to check  the codes. Thanks a lot.

//   preconditioned conjugate gradient solver  ...
void PCGSSolver::solveNew(const Array3D<double>& sn, const Array3D<double>& ae,  const Array3D<double>&aw,
                          const Array3D<double>& as,  const Array3D<double>& an,  const Array3D<double>&at,  const Array3D<double>&ab,
                          const Array3D<double>& ap, Array3D<double>& ptmp){
    std::size_t dimX=sn.getDimI();
    std::size_t dimY=sn.getDimJ();
    std::size_t dimZ=sn.getDimK();


    Array3D<double> p1(dimX,dimY,dimZ,0.0);
    Array3D<double> res(dimX,dimY,dimZ,0.0);
    Array3D<double> d(dimX,dimY,dimZ,0.0);
    Array3D<double> ain(dimX,dimY,dimZ,0.0);


    double tiny=1.0e-30;
#pragma omp parallel
{
        //Jacobi preconditioner
#pragma omp for nowait
    for(std::size_t k=1;k<dimZ-1; k++){
        for(std::size_t j=1; j<dimY-1; j++){
            for(std::size_t i=1; i<dimX-1; i++){
                d(i,j,k)=1./ap(i,j,k);
            }
        }
    }
#pragma omp for nowait
    for(std::size_t k=1;k<dimZ-1; k++){
        for(std::size_t j=1; j<dimY-1; j++){
            for(std::size_t i=1; i<dimX-1; i++){
                res(i,j,k)=ae(i,j,k)*ptmp(i+1,j,k) + aw(i,j,k)*ptmp(i-1,j,k)+an(i,j,k)*ptmp(i,j+1,k)+as(i,j,k)*ptmp(i,j-1,k)+
                                at(i,j,k)*ptmp(i,j,k+1)+ab(i,j,k)*ptmp(i,j,k-1)+sn(i,j,k)-ap(i,j,k)*ptmp(i,j,k);
            }
        }
    }

}


    double big =1.0e+30;
    double s1old=big;
    //start iteration
    for(std::size_t intswp=0; intswp<this->nswpvr; intswp++){

        double alpha=0.0;
        double bbeta=0.0;
        double s1=0.0;
        double s2=0.0;
        double testir=0.0;
#pragma omp parallel
{
#pragma omp for reduction(+:s1)
        for(std::size_t k=1;k<dimZ-1; k++){
            for(std::size_t j=1; j<dimY-1; j++){
                for(std::size_t i=1; i<dimX-1; i++){
                    ain(i,j,k)=res(i,j,k)*d(i,j,k);
                    s1+=(res(i,j,k)*ain(i,j,k));
                }
            }
        }

#pragma omp single
{
        bbeta=s1/(s1old+tiny);
}
#pragma omp for
        for(std::size_t k=1;k<dimZ-1; k++){
            for(std::size_t j=1; j<dimY-1; j++){
                for(std::size_t i=1; i<dimX-1; i++){
                    p1(i,j,k)=ain(i,j,k)+bbeta*p1(i,j,k);
                }
            }
        }

#pragma omp for reduction(+:s2)
        for(std::size_t k=1;k<dimZ-1; k++){
            for(std::size_t j=1; j<dimY-1; j++){
                for(std::size_t i=1; i<dimX-1; i++){
                    ain(i,j,k)=ap(i,j,k)*p1(i,j,k)-ae(i,j,k)*p1(i+1,j,k)-aw(i,j,k)*p1(i-1,j,k)-
                                    an(i,j,k)*p1(i,j+1,k)-as(i,j,k)*p1(i,j-1,k)-
                                    at(i,j,k)*p1(i,j,k+1)-ab(i,j,k)*p1(i,j,k-1);
                    s2+=(p1(i,j,k)*ain(i,j,k));
                }
            }
        }

#pragma omp single
{
        alpha=s1/(s2+tiny);
}
#pragma omp for reduction(+:testir)
        for(std::size_t k=1;k<dimZ-1; k++){
            for(std::size_t j=1; j<dimY-1; j++){
                for(std::size_t i=1; i<dimX-1; i++){
                    ptmp(i,j,k)=ptmp(i,j,k)+alpha*p1(i,j,k);
                    res(i,j,k)=res(i,j,k)-alpha*ain(i,j,k);
                    testir+=fabs(res(i,j,k));
                }
            }
        }

}//==openmp region end
        s1old=s1;
        //test stop criteria
        if(testir < ccvar){
            std::cout<<"PCGS solver coverage at "<<(intswp+1)<<" iterations!"<<std::scientific<<testir<<std::endl;
            return;
        }

    }
    std::cout<<"PCGS solver can not coverage "<<std::endl;
}

The Array3D is a my 3 dimension array class.

#ifndef ARRAY3D_H
#define ARRAY3D_H

#include <vector>
#include <algorithm>

template<typename T> class Array3D
{
public:
    typedef T value_type;
    Array3D(){
        dim_i=dim_j=dim_k=0;
        dim_ij=0;
    }

    Array3D(std::size_t size_i, std::size_t size_j, std::size_t size_k){
        this->resize(size_i,size_j,size_k);
    }

    Array3D(std::size_t size_i, std::size_t size_j, std::size_t size_k,const value_type& defaultValue){
        this->resize(size_i,size_j,size_k,defaultValue);
    }

    virtual ~Array3D(){}

    std::size_t getDimI()const{
        return this->dim_i;
    }

    std::size_t getDimJ()const{
        return this->dim_j;
    }

    std::size_t getDimK()const{
        return this->dim_k;
    }

    //check if valid indices
    bool checkIndices(std::size_t i, std::size_t j, std::size_t k){
        return (i<this->dim_i ) && (j<this->dim_j) && (k<this->dim_k);
    }
    void resize(std::size_t size_i, std::size_t size_j, std::size_t size_k,const value_type& defaultValue){
        this->resize(size_i,size_j,size_k);
        this->fillValue(defaultValue);
    }
    //resize the array. The data will be ereased.
    void resize(std::size_t size_i, std::size_t size_j, std::size_t size_k){
        this->dim_i=size_i;
        this->dim_j=size_j;
        this->dim_k=size_k;
        this->dim_ij=this->dim_i*this->dim_j;

        std::size_t totalSize=this->dim_i*this->dim_j*this->dim_k;
        this->data.resize(totalSize);
    }
    std::size_t size()const{
        return this->data.size();
    }

    void fillValue(const value_type& defaultValue){
        std::fill(this->data.begin(),this->data.end(),defaultValue);
    }
    value_type minValue()const{
        return *(std::min_element(data.begin(),data.end()));
    }
    value_type maxValue()const{
        return *(std::max_element(data.begin(),data.end()));
    }

    //Fill the array value using the sum of two array
    void setValueSum(const Array3D& array1, const Array3D& array2){
        size_t minSize=std::min(std::min(array1.data.size(),array2.data.size()),this->data.size());
        for(size_t i=0; i<minSize; i++)
            this->data[i]=array1.data[i]+array2.data[i];
    }

    void clear(){
        dim_i=dim_j=dim_k=0;
        dim_ij=0;
        this->data.clear();
    }

    //get value reference at (i,j,k) or (x,y,z) or (u,v,w)...
    const value_type& operator () (std::size_t i, std::size_t j, std::size_t k )const{
        return this->data.at(this->calIndex(i,j,k));
    }

    value_type& operator ()(std::size_t i, std::size_t j, std::size_t k ){
        return this->data.at(this->calIndex(i,j,k));
    }
    //access the raw data by 1D index
    const value_type& operator [] (std::size_t i )const{
        return this->data.at(i);
    }
    value_type& operator [](std::size_t i ){
        return this->data.at(i);
    }
    std::vector<value_type>* rawData(){
        return &(data);
    }
private:
    inline std::size_t calIndex(std::size_t i, std::size_t j, std::size_t k )const{
        return k*this->dim_ij+j*this->dim_i+i;
    }

private:
    //dimension of array (i,j,k)(x,y,z)(u,v,w)...
    std::size_t dim_i, dim_j, dim_k;
    //raw data, order is I-J-K
    std::vector<value_type> data;

    //dim_i*dim_j
    std::size_t dim_ij;
};

#endif // ARRAY3D_H

 


Optimization creates infinite loop

$
0
0

Users of numerical analysis packages such as those at www.netlib.org, especially the codes in the ACM TOMS group, often find themselves contending with Fortran 77 subroutines and functions that are now obsolete because those were replaced with intrinsics such as RADIX, EPSILON, HUGE, TINY, etc., in Fortran 90 and later. Although the proper fix is to rework the old code, replacing the add hoc pieces of code with RADIX, etc., that is not a chore that one wishes to undertake in every case -- often, we just want to build and run the old code with minimum effort.

Here is an example, where the user's purpose is defeated by the high quality of the IFort optimizer. I extracted a reproducer from www.netlib.org/toms, file 768.gz (TENSOLVE, a solver for simultaneous nonlinear equations). The test code is intended to output the floating point base (radix) of 2. With other compilers, and with /Od with IFort, it does. However, with /Ot or the default /fast, the program goes into an infinite loop, as did one of the test problem runs from TOMS-768 compiled with IFort.

      PROGRAM PBETA
      IMPLICIT NONE
      WRITE(*,*)'IBETA = ',IBETA()

      CONTAINS
      INTEGER FUNCTION IBETA()
C
C     returns radix(0d0)
C
      IMPLICIT NONE
      INTEGER ITEMP
      DOUBLE PRECISION A, B, TEMP, TEMP1
      DOUBLE PRECISION ZERO, ONE
      DATA ZERO, ONE/0.0D0, 1.0D0/

      A = ONE
      B = ONE
   10 CONTINUE
      A = A + A
      TEMP = A + ONE
      TEMP1 = TEMP - A
      IF (TEMP1-ONE .EQ. ZERO) GO TO 10
   20 CONTINUE
      B = B + B
      TEMP = A + B
      ITEMP = INT(TEMP-A)
      IF (ITEMP .EQ. 0) GO TO 20
      IBETA = ITEMP
      RETURN
      END FUNCTION
      END PROGRAM

The portion of the disassembly that corresponds to the lines from statement-10 to the IF statement four lines later is as follows. In effect, the optimizer replaces the IF statement before statement-20 with IF (0d0 .EQ. 0d0) GO TO 10. It similarly replaces lines 25 and 26 with, in effect, ITEMP = INT(B).

  00000076: 0F 28 CA           movaps      xmm1,xmm2     ; A=ONE
  00000079: 66 0F EF C0        pxor        xmm0,xmm0     ; should have been TEMP1 - ONE
  0000007D: 66 0F 2E C0        ucomisd     xmm0,xmm0     ; comparing 0D0 with 0D0
  00000081: F2 0F 58 C9        addsd       xmm1,xmm1     ; A=A+A
  00000085: 7A 02              jp          00000089      ; never happens
  00000087: 74 F4              je          0000007D      ; always true
  00000089: F2 0F 58 D2        addsd       xmm2,xmm2     ; B=B+B
  0000008D: F2 0F 2C C2        cvttsd2si   eax,xmm2

Lines 3 to 6 of the disassembly constitute the infinite loop. The loop is entered with xmm0 = 0 (from the PXOR), and xmm0 is never changed in the loop.

The compiler is allowed to make transformations and cannot be faulted based on standards-conformance. In fact, it could have continued its aggressive work and replaced the jp/je with an unconditional jmp.  Perhaps, it could have removed the ucomisd instruction, which is not needed any more. However, the compiler can, after optimizing the code, see that it has created an infinite loop, at which point it is probably worth issuing a warning to the unsuspecting user.

After all, when a program built from about 9000 lines of code "works" with competing compilers, hangs with IFort/default-options but works with IFort /Od, one may suspect a compiler bug. Nor is it trivial to locate the problem in the source code. What I did was to use the fsplit utility on the source files, and I then compiled all pieces with /Od for the base run. I then compiled each split file with /Ot, until I found the one that caused the infinite loop to occur.

Compiles Successful but unable to debugg

$
0
0

Hi, I'm using intel fortran visual studio xe 2013 with visual studio 2012. I'm able to successfully compile my program, however I cannot start the debugging. It automatically exits with message: The program '[11156] ID.exe: Native' has exited with code 0 (0x0). How to solve this?

Result file from Intel Inspector 2015 does not have call stack frames

$
0
0

Hi,

 

I have recently migrated from the Intel Inspector 2011 to Intel Inspector 2015 and I started to have problems with the result file that I generate using following cmd line command:

C:\Program Files (x86)\Intel\Inspector XE 2015\bin32\inspxe-cl.exe" -report=problems -suppression-file="C:/MySuppresion.sup" -format=xml -result-dir="C:/temp/result" -report-output="C:/temp/result\final_report"

The output file is generated and looks ALMOST the same like with one generated, by Intel Inspector 2011 with an exception, that it does not have frames from the call stack to the memory issue included. Previously I had .xml structure like:

<psets>

<pset>

<obs>

<stack>

<frame>

....

<frame>

</stack>

</obs>

</pset>

</psets>

Now I don't have <stack> and <frame> elements.

Does anyone know, whyt it is like that? And how can one get it back?

Keep well,

Andrzej

Release mode executable problem

$
0
0

I wrote a simple and short program which ran well in debug mode. However, it went wrong in release mode. Values were assigned in an array, but they changed to some funny number when they were used. 

Books - Message Passing Interface (MPI)

$
0
0

Beginning MPI (An introduction in C)

This book covers essential concepts of the Message Passing Interface (MPI). From this book, the reader will gain insights into utilizing MPI to write portable parallel code. The book covers the following essential elements of MPI: Sending and receiving with MPI_Send and MPI_Recv; Dynamic receiving with MPI_Probe and MPI_Status; A collective communication introduction with MPI_Bcast; Common collectives – MPI_Scatter, MPI_Gather, and MPI_Allgather; and Using MPI_Reduce and MPI_Allreduce for parallel number reduction.

Along the way, the book provides a couple application examples of using the various MPI methods. The first application example is performing a random walk among processes. The second application example shows how to build a new MPI function, MPI_Rank, to compute the rank of a number across MPI processes.

This book was written by a previous grad student, Wesley Kendall, that heavily used MPI in his doctoral research. Since it was very hard to find high quality information about MPI on the internet (and cheap books about MPI), Wesley compiled various tutorials on mpitutorial.com.

This book is a compilation of all of the beginner tutorials on this site. It goes over everything from installing MPI on an Amazon EC2 cluster to the basics of sending and receiving with MPI to performing collective operations and reductions. click here for more info.

Beginning MPI - An Introduction in C

 

Parallel Programming with MPI

A hands-on introduction to parallel programming based on the Message-Passing Interface (MPI) standard, the de-facto industry standard adopted by major vendors of commercial parallel systems. This textbook/tutorial, based on the C language, contains many fully-developed examples and exercises. The complete source code for the examples is available in both C and Fortran 77. Students and professionals will find that the portability of MPI, combined with a thorough grounding in parallel programming principles, will allow them to program any parallel system, from a network of workstations to a parallel supercomputer.

* Proceeds from basic blocking sends and receives to the most esoteric aspects of MPI.
* Includes extensive coverage of performance and debugging.
* Discusses a variety of approaches to the problem of basic I/O on parallel machines.
* Provides exercises and programming assignments..

Click here for more info.

Parallel Programming with MPI

 

Using MPI - 2nd Edition

The Message Passing Interface (MPI) specification is widely used for solving significant scientific and engineering problems on parallel computers. There exist more than a dozen implementations on computer platforms ranging from IBM SP-2 supercomputers to clusters of PCs running Windows NT or Linux ("Beowulf" machines). The initial MPI Standard document, MPI-1, was recently updated by the MPI Forum. The new version, MPI-2, contains both significant enhancements to the existing MPI core and new features.Using MPI is a completely up-to-date version of the authors' 1994 introduction to the core functions of MPI. It adds material on the new C++ and Fortran 90 bindings for MPI throughout the book. It contains greater discussion of datatype extents, the most frequently misunderstood feature of MPI-1, as well as material on the new extensions to basic MPI functionality added by the MPI-2 Forum in the area of MPI datatypes and collective operations.Using MPI-2 covers the new extensions to basic MPI. These include parallel I/O, remote memory access operations, and dynamic process management. The volume also includes material on tuning MPI applications for high performance on modern MPI implementations.This is a more up-to-date book than the previous, but it mostly focuses on the newer and more advanced MPI routines in the second MPI standard. These include parallel I/O, remote memory access, and dynamic process management. The book also discusses using MPI with threads. This is a must have for advanced MPI development. Click here for more info.

Using MPI - 2nd Edition

 

Parallel Programming in C with MPI and OpenMP

The era of practical parallel programming has arrived, marked by the popularity of the MPI and OpenMP software standards and the emergence of commodity clusters as the hardware platform of choice for an increasing number of organizations. This exciting new book, Parallel Programming in C with MPI and OpenMP addresses the needs of students and professionals who want to learn how to design, analyze, implement, and benchmark parallel programs in C using MPI and/or OpenMP. It introduces a rock-solid design methodology with coverage of the most important MPI functions and OpenMP directives. It also demonstrates, through a wide range of examples, how to develop parallel programs that will execute efficiently on today's parallel platforms. . .

Click here for more info.

Parallel Programming in C with MPI and OpenMP

 

MPI: The Complete Reference

Since its release in summer 1994, the Message Passing Interface (MPI) specification has become a standard for message-passing libraries for parallel computations. There exist more than a dozen implementations on a variety of computing platforms. The MPI Forum, which has continued to work on MPI, has recently released MPI-2, a new definition that includes significant extensions, improvements, and clarifications. This volume presents a complete specification of the MPI-2 Standard. It is annotated with comments that clarify complicated issues, including why certain design choices were made, how users are intended to use the interface, and how they should construct their version of MPI. The volume also provides many detailed, illustrative programming examples. A complete reference guide to MPI one and two. The book does not necessarily teach MPI, but it provides a great reference and complete descriptions of every single function. One advantage of this book is that it includes Fortran routines as well as C routines. Click here for more info.

 The Complete Reference

  • Développeurs
  • Professeurs
  • Étudiants
  • Linux*
  • C/C++
  • Fortran
  • Débutant
  • Intermédiaire
  • Interface de transmission de messages
  • Enseignement
  • Informatique en cluster
  • Modernisation du code
  • URL
  • LTIME

    $
    0
    0

    Portability Subroutine: Returns the components of the local time zone time in a nine-element array.

    Module

    USE IFPORT

    CALL LTIME(time,array)

    time

    (Input) INTEGER(4). An elapsed time in seconds since 00:00:00 Greenwich mean time, January 1, 1970.

    array

    (Output) INTEGER(4). One-dimensional array with 9 elements to contain local date and time data derived from time.

    The elements of array are returned as follows:

    Element

    Value

    array(1)

    Seconds (0 - 59)

    array(2)

    Minutes (0 - 59)

    array(3)

    Hours (0 - 23)

    array(4)

    Day of month (1 - 31)

    array(5)

    Month (0 - 11)

    array(6)

    Years since 1900

    array(7)

    Day of week (0 - 6, where 0 is Sunday)

    array(8)

    Day of year (1 - 365)

    array(9)

    1 if daylight saving time is in effect; otherwise, 0.

    Caution

    This subroutine is not year-2000 compliant, use DATE_AND_TIME instead.

    Example

    USE IFPORT
    INTEGER(4) input_time, time_array(9)
    !   find number of seconds since 1/1/70
    input_time=TIME()
    !   convert number of seconds to time array
    CALL LTIME (input_time, time_array)
    PRINT *, time_array

    LSTAT

    $
    0
    0

    Portability Function: Returns detailed information about a file.

    Module

    USE IFPORT

    result=LSTAT(name,statb)

    name

    (Input) Character*(*). Name of the file to examine.

    statb

    (Output) INTEGER(4) or INTEGER(8). One-dimensional array of size 12; where the system information is stored. See STATfor the possible values returned in statb.

    Results

    The result type is INTEGER(4). The result is zero if successful; otherwise, an error code (see IERRNO).

    LSTAT returns detailed information about the file named in name.

    On Linux* and OS X* systems, if the file denoted by name is a link, LSTAT provides information on the link, while STAT provides information on the file at the destination of the link.

    On Windows* systems, LSTAT returns exactly the same information as STAT (because there are no symbolic links on these systems). STAT is the preferred function.

    INQUIRE also provides information about file properties.

    Example

    USE IFPORT
    INTEGER(4) info_array(12), istatus
    character*20 file_name
    print *, "Enter name of file to examime: "
    read *, file_name
    ISTATUS = LSTAT (file_name, info_array)
    if (.NOT. ISTATUS) then
       print *, info_array
    else
       print *, 'Error ',istatus
    end if

    Migrate from Linux to Windows

    $
    0
    0

    I have inherited a large Fortran project, and I need to migrate it to Windows. We use Visual Studio 2008. It was developed in Linux, and the previous owners said to use Visual Fortran. So I got the proper version installed nicely. Now can I open the Linux project directly? Can I reuse the makefiles? I tried clicking around but couldn't find how.

    Is there an approved method for doing this?

    I am probably not the first person to have this problem, though everybody else here seems to be porting in the other direction.

    Run-Time Check Failure #2

    $
    0
    0

    I am getting the following message when I leave a particular subroutine, at the end statement:

    Run-Time Check Failure #2 - Stack around the variable '.T209_' was corrupted.

    By trial and error I have traced it to the calling of another subroutine, "A", 4 levels below. If I comment out the call to this subroutine "A" the error goes away.  However if I still call "A" but remove all the code inside it, I get the error. So it looks like a argument list issue.  However all the arguments match fine.  Most of the arguments are structures from USE'd modules which both the caller and callee USE.

    How do I debug this further?

    Any problem for Fortran under Windows to read files produced by Fortran under Linux

    $
    0
    0

    Hi,

    I will run the Cluster Studio and Fortran both under Windows and Linux. I want run code under Linux to produce result files. I then want to read the result files using Fortran code under Windows with nice Quickwin graphics to inspect the results. Later on I will add a Xeon Phi card and has found out that there a lot of hands on documentation of running the Phi under Linux but virtually zero information on running the Phi card under Windows.

    Best regards

    Anders S

    -heap_arrays option, thread safety and performance

    $
    0
    0

    I'm updating old .f90 code to f2003 and in order to make thread-safe libraries.  I've come across this old topic:

    https://software.intel.com/en-us/forums/topic/270572

    in listing a few guidelines for writing thread-safe code.  One of the libraries I've updated uses very large arrays, which I've been able to get working when using the -heap_arrays compiler option. Otherwise I get a stack overflow error in the MAXVAL intrinsic function.  But the above topic states to not use the -heap_arrays option for thread-safe code. 

    Is this true?  I'm using Intel® Parallel Studio XE 2015 Update 4 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2013, Version 15.0.0122.12

    I know previous versions of IVF had memory leak problems with this option but have since been fixed. 

    Also, this particular library is being executed across multiple threads (2-8) 1000s of times and I do see a noticeable slow down when I get to the 1000+ run/thread.  Is this due to the -heap arrays option for creating the library? or would this be attributable to a memory leak problem? 

    Will purchasing IVF 15 now allow for upgrade to IVF 16 in a few weeks?

    $
    0
    0

    If I remember well, free upgrades are possible within a year of purchase of a compiler - it this correct?

    Thanks,
    Olivier

    Viewing all 3108 articles
    Browse latest View live


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