Quantcast
Viewing all 2746 articles
Browse latest View live

Aliasing problem when passing the private components of a base type to its child

From what I gather, it's best to avoid any kind of aliasing in Fortran. What would be a proper way of implementing the following?

Say, I have two derived types: base_t and child_t, each one defined in its own separate module. child_t extends base_t (I want to model is-a relationship). base_t is an abstract type and has a deferred procedure, which it calls at some point. The child type must provide a definition for this procedure. The problem is that this procedure is supposed to change a private attribute of the base type which is not accessible to the child (add new coordinates to the coordinates array). I was going to pass it as an argument to this deferred procedure, but after reading the thread on aliasing and derived types (https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/597073) it seems like a bad idea. I originally posted this question there, but following FortranFan's comment I moved it to a separate thread. Next paragraph is my response to the comment.

The consumer is not supposed to be able to add new coordinates. Take a look at the simplified example I added below (tried to make it as short as possible). Generally, I'm trying to avoid a setter procedure, because it would be public, and would be accessible to anyone, which contradicts encapsulation principles.

Here's what a consumer is expected to do.

real, dimension(:), allocatable :: f
class(base_t), allocatable :: b

allocate(child_t::b)
! call b%init with some arguments.
! do some other work
call b%compute_differential_operator(f)

And here's a base_t's module.

module base
    implicit none
    private
    public :: base_t

    type, abstract :: base_t
        private
        real, dimension(:,:), allocatable :: x
        integer :: num_bndr = 0
    contains
        private
        procedure, public :: init ! creates initial x array, left it out in this example
        procedure, public :: compute_differential_operator
        procedure(create_boundary_particles_func_t), deferred :: create_boundary_particles
    end type base_t

    interface
        subroutine create_boundary_particles_func_t (this, x)
            import :: base_t
            implicit none
            class(base_t), intent(in) :: this
            real, dimension(:,:), allocatable, intent(in out) :: x ! aliasing would appear when calling this function
        end subroutine create_boundary_particles_func_t
    end interface

contains

    subroutine compute_differential_operator (this, f)
        implicit none
        class(base_t), intent(in out) :: this
        real, dimension(:), intent(out) :: f
        integer :: num_non_bndr

        if (this%num_bndr <= 0) then
            num_non_bndr = size(this%x, 2)
            call this%create_boundary_particles(this%x) ! FIXME: ALIASING
            this%num_bndr = size(this%x, 2) - num_non_bndr
        else
            num_non_bndr = size(this%x, 2) - this%num_bndr
        end if

        ! Here we somehow fill f array based on the positions
        ! of regular and boundary particles.
    end subroutine compute_differential_operator

end module base

P.S. I'm especially interested in the "right" way to do it, not a way. Suggestions on changing the code structure (like how to deal with the whole inheritance of a type with a private component thing) are welcome too. Thanks for any help in advance. I've originally learnt C++, and when it comes to things like OOP it is sometimes difficult to do things Fortran way rather than simply translate C++ principles into Fortran.

Fedor


Optimizer bug

I wrote a driver program to solve the SNLS (Separable Nonlinear Least Squares) problems at http://www.itl.nist.gov/div898/strd/nls/nls_main.shtml using the JPL math77 library (high quality, recently made available free of cost at NetLib, see http://www.netlib.org/math/index.html ). When testing this driver with Intel Fortran, I discovered an optimizer bug.

The optimizer bug occurs with the 15 and 16.0.1 IFort Linux compilers when generating 32-bit targets with -O2. When one of the math77 library files (divset.f) is split into separate files using fsplit, and the split source files are used instead of divset.f, the bug goes away. I have not been able to create a short reproducer that retains the optimizer bug, but to make it simple to reproduce the problem I have collected all the files needed in the attached archive. I have included a copy of  the math77 copyright notice in the archive; you can also see the notice at http://www.netlib.org/math/license.html .

Here are the steps to reproduce the problem (I used an OpenSuse 13.2 system with a T4300 CPU). Extract the archive in a test directory in an IFort 32-bit shell window. Download the test data file http://www.itl.nist.gov/div898/strd/nls/data/LINKS/DATA/BoxBOD.dat . Build and run as follows:

$ ifort -O2 *.f90 *.f
$ echo BoxBod.dat | ./a.out

The output shows a failure:

...
 ***** SINGULAR CONVERGENCE *****
Termination code   7
...

If we compile instead using the split files as follows:

$ ifort -O2 *.f90 dnlsfu.f drn2g.f drnsg.f idsm.f dq7rfh.f DIVS/*.f

the output is correct and as expected:

...
Termination code   4

   Final parameters
...

The output is also correct if -O0 is used or if 64-bit target mode is used.

AttachmentSize
DownloadImage may be NSFW.
Clik here to view.
application/x-gtar
nistjpl.tgz
102.22 KB

ifort linker can't find my user libs

I've searched the forum for this issue but no luck.  

This is my first time trying to link user libs into my source code on linux.
I am NOT using -static or -fast when I compile.  

libA.a and libB.a are both archive files I created.

My link statement is,
-L. -l:libA.a -l:libB.a

When I try to compile my program I get the following.

ifort  -L. -llibA.a -llibB.a -o prog.exe
ld: cannot find -llibA.a

Yes, the lib files are located in the same directory as the makefile and source code.

Any suggestions?  Thanks!

Mixing optimization option O1/O2/O3 in the same code

Hi,

I have got a code which works well in debug ver but gives segmentation fault in the optimized ver. I optimized with:

 -ipo -O3   -r8 -c -fPIC  -save 

After quite a lot of debugging, it seems that it was most likely due to a bug in the compiler. I can't do more debugging since the error part of the code was not written by me. Also, newer ver of Intel compiler works fine with the opt ver. However, the cluster I'm using is stuck with the old ver

I realised that if I use O1 instead of O3, and no ipo for 2 of the problematic source codes (total about 10 - 12), it works well. At least it's partially optimized.

So my qn is if it is ok to mix O1/O3 for different source files and built them together. The main difference is O1 instead of O3, and no ipo. Will it cause any problem? Also in that case, it is still useful to use ipo for the other files?

Can I also use PGO optimization to further optimize the code?

Thanks

 

I

make: ifort: command not found

I intalled fortran on my linux computer, when trying to intall FPLO, after typing command make, it returned ifort: commmand not found, so I used this code: /opt/intel/composer_xe_2015/bin/compilervars.sh ia32         according to the solutions I found online.

Then it returned

/opt/intel/composer_xe_2015/bin/compilervars.sh: 33: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 34: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 36: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 37: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 38: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 39: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 40: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 41: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 42: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 43: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 44: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 45: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 46: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 47: /opt/intel/composer_xe_2015/mkl/bin/mklvars.sh: typeset: not found
/opt/intel/composer_xe_2015/bin/compilervars.sh: 13: /opt/intel/composer_xe_2015/ipp/bin/ippvars.sh: [[: not found

I am not sure how to solve this problem, is it possible anyone could give me some help on this? Thanks a lot in advance.

 

undefined symbol: __libm_feature_flag

Dear colleagues,

I'm compiling WRF model with icc and ifort from parallel_studio_xe_2016.1.056 on a AMD64 with Debian 8 (Jessie). During compilation there is no error. During runtime there appears the same error for almost any executable of the model (example is for real.exe) that is:

./real.exe: symbol lookup error: ./real.exe: undefined symbol: __libm_feature_flag

It is independent of compiling for serial or parallel execution.

Because of this problem my LD_LIBRARY_PATH is probably a bit exaggerated:  

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/lib:/usr/lib:/usr/local/lib:/opt/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64:/opt/compilers_and_libraries_2016.1.150/linux/daal/lib/intel64_lin:/opt/compilers_and_libraries_2016.1.150/linux/ipp/lib/intel64:/opt/compilers_and_libraries_2016.1.150/linux/ipp/lib/mic:/opt/compilers_and_libraries_2016.1.150/linux/mkl/lib/intel64:/opt/compilers_and_libraries_2016.1.150/linux/mkl/lib/mic:/opt/compilers_and_libraries_2016.1.150/linux/mpi/mic/lib:/opt/compilers_and_libraries_2016.1.150/linux/mpi/intel64/lib:/opt/compilers_and_libraries_2016.1.150/linux/tbb/lib/intel64:/opt/compilers_and_libraries_2016.1.150/linux/tbb/lib/mic:/opt/compilers_and_libraries_2016.1.150/linux/mkl/benchmarks/hpcg/bin/lib/intel64:/opt/compilers_and_libraries_2016.1.150/linux/mkl/benchmarks/hpcg/bin/lib/mic:/opt/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin:/opt/compilers_and_libraries_2016.1.150/linux/compiler/lib/intel64_lin_mic/:/opt/advisor_xe_2016.1.10.435553/lib64/pinruntime/:/opt/inspector_xe_2016.1.1.435552/lib64/pinruntime/:/opt/vtune_amplifier_xe_2016.1.1.434111/lib64/pinruntime/

export CPATH=${CPATH}:/opt/compilers_and_libraries_2016.1.150/linux/daal/include/:/opt/compilers_and_libraries_2016.1.150/linux/daal/include/algorithms:/opt/compilers_and_libraries_2016.1.150/linux/daal/include/services:/opt/compilers_and_libraries_2016.1.150/linux/compiler/include:/opt/compilers_and_libraries_2016.1.150/linux/ipp/include:/opt/compilers_and_libraries_2016.1.150/linux/ipp/tools/intel64/staticlib//opt/compilers_and_libraries_2016.1.150/linux/mkl/benchmarks/mp_linpack/include:/opt/compilers_and_libraries_2016.1.150/linux/mkl/include:/opt/compilers_and_libraries_2016.1.150/linux/mkl/include/fftw/:/opt/compilers_and_libraries_2016.1.150/linux/mkl/interfaces/:/opt/compilers_and_libraries_2016.1.150/linux/mpi/mic/include:/opt/compilers_and_libraries_2016.1.150/linux/mpi/intel64/include:/opt/compilers_and_libraries_2016.1.150/linux/tbb/include:/opt/compilers_and_libraries_2016.1.150/linux/tbb/include/tbb:/opt/compilers_and_libraries_2016.1.150/linux/tbb/include/tbb/internal/:/opt/compilers_and_libraries_2016.1.150/linux/tbb/include/tbb/machine/:/opt/compilers_and_libraries_2016.1.150/linux/tbb/include/serial/tbb/

I copied libm.so.6 and  libm-2.3.4.so from the glibc directory to the next higher one, because libc6 en glibc caused problems with some GNU functions. I still don't know in which library contains the libm_feature_flag. Suppose it should be libm.so.6 or libimf.so. I see this error for he first time. It didn't appear in my former compilations of WRF for example with the ifort and icc from composer_xe_2013.

Any suggestion to fix this problem will be welcome.

Many thanks

Thorsten

 

 

 

 

Abstract type/concrete extension interfaces mismatch: different behavior between GNU gfortran and Intel Fortran Compiler

Dear Great Intel Fortran developers Team,

as always, thank you very much for your great work.

I have found a different behavior between the Intel Fortran Compiler (v15.0.3) and GNU gfortran (gcc v5.2) when compiling a "possible" wrong (non standard conforming) code. The most simple (not) working example that I can provide is the following:

 

module adt_foo_class
implicit none
private
type, abstract, public :: adt_foo
  private
  contains
    private
    procedure(sym_operator), pass(lhs), deferred :: foo_multiply_foo
    procedure(assignment),   pass(lhs), deferred :: assign_foo
    generic, public :: operator(*) => foo_multiply_foo
    generic, public :: assignment(=) => assign_foo
endtype adt_foo

abstract interface
  function sym_operator(lhs, rhs) result(operator_result)
  import :: adt_foo
  class(adt_foo), intent(IN)  :: lhs
  class(adt_foo), intent(IN)  :: rhs
  class(adt_foo), allocatable :: operator_result
  endfunction sym_operator

  subroutine assignment(lhs, rhs)
  import :: adt_foo
  class(adt_foo), intent(INOUT) :: lhs
  class(adt_foo), intent(IN)    :: rhs
  endsubroutine assignment
endinterface
endmodule adt_foo_class

module foo_class
use adt_foo_class, only : adt_foo
implicit none
private

type, extends(adt_foo), public :: foo
  private
  integer, public :: a = 0
  contains
    private
    procedure, pass(lhs) :: foo_multiply_foo
    procedure, pass(lhs) :: assign_foo
endtype foo
contains
  pure function foo_multiply_foo(lhs, rhs) result(opr)
  class(foo),     intent(IN)  :: lhs
  class(adt_foo), intent(IN)  :: rhs
  class(adt_foo), allocatable :: opr

  allocate(foo :: opr)
  select type(opr)
  class is(foo)
    opr = lhs
    select type(rhs)
    class is (foo)
      opr%a = lhs%a * rhs%a
    endselect
  endselect
  return
  endfunction foo_multiply_foo

  pure subroutine assign_foo(lhs, rhs)
  class(foo),     intent(INOUT) :: lhs
  class(adt_foo), intent(IN)    :: rhs

  select type(rhs)
  class is (foo)
    lhs%a = rhs%a
  endselect
  return
  endsubroutine assign_foo
endmodule foo_class

program foo_adt_test
use foo_class, only : foo
implicit none

type(foo) :: foo1, foo2, foo3

foo1 = foo(2)
foo2 = foo(3)
foo3 = foo1 * foo2
print "(I2)", foo3%a
stop
contains
endprogram foo_adt_test 

There is an abstract type, namely "adt_foo", that has one deferred operator and one defined assignment defined as "impure". There is a concrete extension of the above abstract type, namely "foo", that has the corresponding operator and assignment defined as "pure". Now, I do not know if this "mismatch" is allowed by the standard (2003/2008), anyway this possible wrong code is compiled differently by Intel Fortran with respect the GNU gfortran. As a matter of facts, Intel Fortran (v15.0.3) compiles this code without warnings and the result obtained by the test is the one expected (6). On the contrary, GNU gfortran (v5.2), does not compile the code and provide the following error message:

→ gfortran foo_adt_test.f90
foo_adt_test.f90:52:13:

     opr = lhs
             1
Error: Subroutine call to ‘assignment’ at (1) is not PURE
foo_adt_test.f90:74:4:

 use foo_class, only : foo
    1
Fatal Error: Can't open module file ‘foo_class.mod’ for reading at (1): No such file or directory
compilation terminated.

 

I am not sure, but I think that GNU gfortran is right, the code is wrong. Can you give me some insights on this (possible) issue? Is the code wrong, i.e. not standard?

Note that if you modify the example declaring pure the abstract assignment procedure, GNU gfrotran behaves like Intel Compiler.

For your convenience I have created a dedicated Gist here https://gist.github.com/szaghi/f4f521b6130ee911348f#gistcomment-1664759

Thank you very much for any suggestions,

My best regards.

 

 

 

License/support issue

 

I need to download the Intel License manager to support an Intel XE Composer license for two floating seats. The problem is that it is says my support period has expired... except it has not. My support expires Feb 25, 2016 and it has been renewed.

Who do I contact about this? I tried Intel Premier support, but it says I am not authorized. I tried calling and they gave me an email address that bounces.

Regards,

       - Henrik


UNSIGNED type?

I had read that Fortran 95 and later support an UNSIGNED data type for unsigned integers.  I successfully compiled a small program with gfortran with this type, but Intel Fortran does not seem to recognize it.  Does Intel Fortran support unsigned integer types?

Jay
 

 

How to get Intel 8.x compiler (needed for legacy Fortran code)

Hello!

I need the old Intel compiler for some old Fortran code that no longer works with the newer compilers. Intel 8.x compiler is explicitly recommended for the code I am trying to compile.

How do I get the Intel 8.x compiler? As a student, I have access to the Intel Parallel Studio XE Cluster Edition for Linux. Under "Additional downloads, latet updates and prior versions", I can also download older versions of this, going back to 2013. But I don't find any option on the website on how to download just an older compiler.

Thank you for your help.

Failure when installing Netcdf 4.3.3.1 with Intel compilers

I am trying to install Netcdf version 4.3.3.1 with the Intel compilers. I enter:

source /opt/intel/bin/compilervars.sh ia32

Then I configure netcdf with the appropriate flags (I followed the guide on your website on how to install netcdf with Intel compilers:

./configure --prefix=/opt/netcdf/4.3.3.1 --disable-netcdf-4 CC=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/icc CXX=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/icpc CFLAGS='-O3 -xHost -ip -no-prec-div -static-intel' CXXFLAGS='-O3 -xHost -ip -no-prec-div -static-intel' F77=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/ifort FC=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/ifort F90=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/ifort FFLAGS='-O3 -xHost -ip -no-prec-div -static-intel' CPP='/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/icc -E' CXXCPP='CXX=/opt/intel/compilers_and_libraries_2016.1.150/linux/bin/ia32/icpc -E'

When I do make check, it goes fine for a while until I get the following error:

icc: warning #10237: -lcilkrts linked in dynamically, static library not available
ld: warning: libimf.so, needed by ../liblib/.libs/libnetcdf.so, not found (try using -rpath or -rpath-link)
ld: warning: libsvml.so, needed by ../liblib/.libs/libnetcdf.so, not found (try using -rpath or -rpath-link)
ld: warning: libirng.so, needed by ../liblib/.libs/libnetcdf.so, not found (try using -rpath or -rpath-link)
make  check-TESTS
make[2]: Entering directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
make[3]: Entering directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
FAIL: run_tests.sh
make[4]: Entering directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
============================================================================
Testsuite summary for netCDF 4.3.3.1
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See ncgen3/test-suite.log
Please report to support-netcdf@unidata.ucar.edu
============================================================================
make[3]: *** [test-suite.log] Error 1
make[3]: Leaving directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
make[2]: *** [check-TESTS] Error 2
make[2]: Leaving directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/csmith/netcdf-c-4.3.3.1/ncgen3'
make: *** [check-recursive] Error 1

I'd be grateful for any help solving this. I am able to install netcdf with the gcc compilers without a problem, but I would prefer to use the Intel compilers.

Thank you.

character for logic

If I have:

Program DW
  implicit none
  character(len=50) :: C
  logical (kind=1) :: L

  C="4 .GT. 3 .And. 5 .EQ. 2"
  L=C      ! I know that this is impossible
  If (L .EQV. .True.) Then  ! <--- How can I do This?
    Write(*,*) "This is True"
  Else
    Write(*,*) "This isn't True"
  EndIf

End Program DW
 

 

 

error #10295 - could be caused by multiple processes launching ifort?

Hi

I get this error:

ifort: error #10295: error generating temporary file name, check disk space and permissions

from a shell script which concurrently launches multiple
instances of ifort 16.0.0 20150815.

It will take some time to debug, but could this be caused
by different instances of ifort trying to write to the same file,
i.e. use the same temp file?

If so, is there a switch to instruct ifort to use different temp
files for each invocation?

I never see this error in serial execution.

Thanks

Anton

Segmentation fault running SPEC CPU2006

I use Intel Parallel Studio XE version 16.0.1 to build and run SPEC CPU2006 on Linux, but get segmentation fault when running 410.bwaves.

410.bwaves: copy 0 non-zero return code (exit code=46, signal=0)

****************************************
Contents of bwaves.err
****************************************
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
bwaves_base.cpu20  000000000048CD45  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000048AB07  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000045E094  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000045DEA6  Unknown               Unknown  Unknown
bwaves_base.cpu20  0000000000443C56  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000040E910  Unknown               Unknown  Unknown
libpthread.so.0    00007FC026018BB0  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000040ACA0  Unknown               Unknown  Unknown
bwaves_base.cpu20  00000000004064D4  Unknown               Unknown  Unknown
bwaves_base.cpu20  000000000040275E  Unknown               Unknown  Unknown
libc.so.6          00007FC025C62DE5  Unknown               Unknown  Unknown
bwaves_base.cpu20  0000000000402669  Unknown               Unknown  Unknown

****************************************

Compiler options:

FC=ifort -m64

OPTIMIZE=-O3

Linux version:

$uname -a

Linux haswell 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

 

Temporary array creation

I'm getting the famous warning of a temporary array created, forrtl: warning (406): fort: (1): In call to XXXX, an array temporary was created for argument #N. However, I create simple code to mimic the larger code, and I don't get the same warning. See code below. Essentially I'm passing in a subset array into subroutine XXXX, and indexing on the last index, which should give me a contiguous memory chunk. What else could cause this temporary array creation? ifort version 16.0.0

Code:

program testArrayPassSubroutine
        integer :: sze,i
        real, dimension(3,3,2) :: arr
        real, dimension(2,3,3) :: arr2

        !do k=1,2
        !       do j=1,3
        !               do i=1,3
        !                       arr(i,j,k) = (k-1)*9 + (j-1)*3 + i
        !               enddo
        !       enddo
        !enddo

        !do k=1,3
        !        do j=1,3
        !                do i=1,2
        !                        arr2(i,j,k) = (k-1)*9 + (j-1)*3 + i
        !                enddo
        !        enddo
        !enddo

        !This is like the original code, which throws the warning(406):...temporary array creation
        write(*,*) "Test1 start"
        call test(arr(:,:,1))
        write(*,*) "Test1 done"

        !This is where I would expect a warning(406), and indeed see it
        write(*,*) "Test2 start"
        call test(arr2(1,:,:))
        write(*,*) "Test2 done"

        contains
        subroutine test(a)
        integer :: i,j
        real, dimension(3,3) :: a

        do i=1,3
                do j=1,3
                        a(j,i) = j*i
                enddo
        enddo

        write(*,*) "Array",(a)
        write(*,*) ""
        end subroutine test
end program testArrayPassSubroutine

Output:

Test1 start

 Array   1.000000       2.000000       3.000000       2.000000
   4.000000       6.000000       3.000000       6.000000       9.000000

 Test1 done
 Test2 start
forrtl: warning (406): fort: (1): In call to TEST, an array temporary was created for argument #1

Image              PC                Routine            Line        Source
a.out              0000000000403876  Unknown               Unknown  Unknown
a.out              0000000000400689  MAIN__                     29  testArrayPassSubroutine.F90
a.out              00000000004004AE  Unknown               Unknown  Unknown
a.out              000000000048D9F1  Unknown               Unknown  Unknown
a.out              0000000000400389  Unknown               Unknown  Unknown
 Array   1.000000       2.000000       3.000000       2.000000
   4.000000       6.000000       3.000000       6.000000       9.000000

 Test2 done


IFORT fails to properly allocate dummy argument with assumed length parameter

Here is a program demonstrating the run-time error mentioned in the title.  I believe this is a bug in IFORT 16.0.0

Program test
   Implicit None

   Type string(slen)
      Integer, Len :: slen
      Character    :: its_value(slen)
   End Type string

   Type(string(5)), Dimension(:), Allocatable :: my_string1
   Type(string(5)), Dimension(:), Allocatable :: my_string2

   Integer :: stat

   Call allocate_string(my_string1)
   If(Allocated(my_string1)) Then
      Print '(a, 1i1)', "my_string1 was allocated with len = ", my_string1%slen
      Deallocate(my_string1, Stat = stat)
   End If

   Print *
   If(stat /= 0) Then
      Print '(a)', "Something is wrong, because"
      Print '(a, i3)', "deallocation of my_string1 failed with status ", stat
   End If
   Print *

   !The problem appears to be the value of the assumed length parameter slen inside the
   !Allocate statement of the subroutine allocate_string.  If we do the allocation outside,
   !then the interface of allocate_string seems to properly transfer the value
   !of the assumed length parameter slen in and out the body of the subroutine

   Allocate(string(5) :: my_string2(3))
   Call allocate_string(my_string2)

Contains

   Subroutine allocate_string(my_string)
      Type(string(*)), Dimension(:), Allocatable, Intent(InOut) :: my_string

      ! If needed, perform typed allocation with the string len parameter being assumed
      If(.Not.Allocated(my_string)) Allocate(string(*) :: my_string(3))

      Print '(a     )', "I am supposed to print 5"
      Print '(a, 1i1)', "I am printing          ",  my_string%slen

   End Subroutine allocate_string

End Program test

 

Issues with Running ifort

HI,

After installation of Parallel Studio XE 2016 Update 1, I am getting some issues while running ifort. Please provide some pointers

This is the error message:

Error: A license for Comp-FL is not available (-76,61026,2).

License file(s) used were (in this order):
    1.  Trusted Storage
**  2.  /home/shm82/intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/../../Licenses
**  3.  /home/shm82/Licenses
**  4.  /opt/intel/licenses
**  5.  /Users/Shared/Library/Application Support/Intel/Licenses
**  6.  /home/shm82/intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/*.lic

Please visit http://software.intel.com/sites/support/ if you require technical assistance.

ifort: error #10052: could not checkout FLEXlm license

 

 

 

forrtl: severe (36) error

I have been using a model compiled with pgi compiler package in intel ifort compiler environment. The original pgi compiler "configure.user" file has the following lines.

SFC       = pgf90
FC        = mpif90
FOPTS     = -byteswapio -fastsse
FOPTS2    = -fastsse
FMCMODEL  = -mcmodel=medium
FFREE     = -Mfree
FFIXED    = -Mfixed

I changed the above lines for intel ifort as below.
 

SFC       = ifort -assume byterecl -mkl=parallel
FC        = mpiifort -assume byterecl -mkl=parallel
FOPTS     =-convert big_endian -O2
FOPTS2    =  -O2
FMCMODEL  = -mcmodel=medium -shared-intel
FFREE     =  -free
FFIXED    = -fixed
 

The error I am getting constantly is

forrtl: severe (36): attempt to access non-existent record, unit 11,
Image              PC                Routine            Line        Source
grd2ss             0000000000607783  Unknown               Unknown  Unknown
grd2ss             00000000006054C6  Unknown               Unknown  Unknown
grd2ss             000000000040E0FD  Unknown               Unknown  Unknown
grd2ss             000000000040428D  Unknown               Unknown  Unknown
grd2ss             0000000000403A56  Unknown               Unknown  Unknown
libc.so.6          00007F24DB18BCDD  Unknown               Unknown  Unknown
grd2ss             0000000000403949  Unknown               Unknown  Unknown
 

I understand that the source of error is from the below quoted lines from a Fortran script used in my model.

  iunit=11
  INQUIRE(IOLENGTH=iolen) iolen
  OPEN(iunit,FILE=filename,FORM='unformatted',ACCESS='direct',RECL=nij0*iolen)

  irec=1
  DO n=1,nv3d
    DO k=1,nlev
      READ(iunit,REC=irec) ((v3d(i,j,k,n),i=1,nlon),j=1,nlat)
      irec = irec + 1
    END DO
  END DO
Kindly suggest me what should I do to solve this issue? Any compiler flag modification can solve this problem?

Bounds checking, zero sized array and sequence association

I work on code that frequently relies on sequence association when passing arrays as arguments. Zero sized arrays are not a problem during program execution but when I turn on bounds checking there doesn't seem to be any way to have a valid index for the actual array argument.

This example shows a simple version where array(0) and array(1) are both out of bounds access. Of course, I could just pass the whole array instead of relying on sequence association, but in many cases the sequence association is a way to pass array sections and it's not possible to find a method that works with bounds checking for both zero sized arrays and non-zero sized arrays. Is there any way to enable bounds checking that "works" in this situation? ("works" = does what I want it to, not what I tell it to)

program zero

  integer,parameter :: array_dim=0
  integer :: array(array_dim)

  array=1

  call print_array(array(0),array_dim)

END PROGRAM zero

subroutine print_array(array,size)
  integer :: array(*),size
  integer :: i

  do i=1,size
    write(*,*)i,array(i)
  end do

end subroutine print_array

 

Which Version of Parallel Studio XE

I want to install ifortan compiler in my Laptop, on the LINUX OS. which version of "Parallel Studio XE "I should download ?? Can I install the cluster edition on my Laptop ?

Viewing all 2746 articles
Browse latest View live


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