Quantcast
Channel: Intel® Fortran Compiler
Viewing all 3270 articles
Browse latest View live

Can the dummy argument of a PURE subroutine with INTENT(OUT) attribute be unlimited polymorphic?

$
0
0

The following code compiles with no errors or warnings with the latest Intel Fortran compiler 2015, update 2 even with -stand compiler option:

   pure subroutine foo(val)

      class(*), allocatable, intent(out) :: val

      allocate(val, source=0.0)

   end subroutine foo

but gfortran (GCC 5 development truck) throws an error:

    pure subroutine foo(val)
                          1
Error: INTENT(OUT) argument 'val' of pure procedure 'foo' at (1) may not be polymorphic

 

I fail to see anything in the standard about INTENT(OUT) and polymorphic dummy arguments and pure procedures.  Is gfortran misinterpreting the standard or is Intel Fortran incorrect to allow this?

Thanks,

 


What is the effect of indirect recursion on ELEMENTAL procedures, especially finalizers?

$
0
0

The following simple code involving a linked list compiles with no errors or warnings with compiler 2015, update 2.  It seems to execute without any run-time exceptions as well.

However, you will notice the code in module m invokes a finalizer for the derived type for linked list (node_t) that has indirect recursion via clear_node_t; this is to work around the restriction in the standard that both RECURSIVE and ELEMENTAL attributes cannot be applied with subroutines.

What are the risks associated with such a workaround?

Colud the compiler do a static allocation (non-automatic) for allocatable array foo in program p and could the indirect recursion then possibly lead to a failure of some sort under some circumstances?  Note, however, I have not noticed any such issues - no memory leaks are detected nor any other run-time exceptions; I tried /heaparrays0 also.

module m

   implicit none

   private

   type, public :: node_t

      private

      type(node_t), pointer         :: m_child => null()
      character(len=:), allocatable :: m_key

   contains

      private

      procedure, pass(this) :: clear => clear_node_t
      final :: clean_node_t

      procedure, pass(this), public :: put => put_node_t

   end type node_t

contains

   recursive pure subroutine put_node_t(this, key)

      class(node_t), intent(inout) :: this
      character(len=*), intent(in) :: key

      if (allocated(this%m_key)) then
         if (this%m_key /= key) then
            if (.not. associated(this%m_child)) then
               allocate(this%m_Child)
            end if
            call put_node_t(this%m_Child, key)
         end if
      else
         this%m_key = key
      end if

      return

   end subroutine put_node_t

   pure recursive subroutine clear_node_t(this)

      class(node_t), intent(inout) :: this

      if (allocated(this%m_key)) then
         deallocate(this%m_key)
      end if

      if (associated(this%m_child)) then
         deallocate(this%m_child)
         this%m_child => null()
      end if

      return

   end subroutine clear_node_t

   pure elemental subroutine clean_node_t(this)

      type(node_t), intent(inout) :: this

      call clear_node_t(this)

   end subroutine clean_node_t

end module m
program p

   use m, only : node_t

   implicit none

   type(node_t), allocatable :: foo(:)
   integer :: istat

   allocate( node_t :: foo(2), stat=istat)
   if (istat /= 0) then
      print *, " istat = ", istat
      stop
   end if

   call foo(1)%put("red")
   call foo(1)%put("green")

   call foo(2)%put("circle")
   call foo(2)%put("triangle")

   deallocate(foo, stat=istat)
   print *, " deallocate(foo): istat = ", istat

   stop

end program p

 

I understand Fortran 2015 lifts the restriction on RECURSIVE and ELEMENTAL but that is for the long-term.  With the current standard, is such an indirect recursion a concern?  If yes, is there any way to make the coder aware of it?

Thanks,

     

fp-model and other arguments

$
0
0

I'm compiling a large program with the new 15.0.2 compiler, where we previously used 12.0.4.  Since we need to ensure our results are identical with the optimized and non-optimized version, we previously used the following compile arguments:

-extend-source 132 -assume nounderscore -assume nobscc -align dcommons -static-libgcc -zero -fp-port -c -fpe0 -ftz -prec-div -fp-stack-check -ccdefault fortran -traceback -fp-model precise

...when compiling the non-optimized (debug) version, we added the following: -g -debug full -debug-parameters -check bounds -O0

...and added in -O1 or -O2 for the nodebug/optimized version.  All was well in the world, and our results matched perfectly between both executables.  However, now that we're moving on to version 15, this is not so much the case anymore.  We're matching with the majority of our results, however some executions that involve multiple inter-communicating processes are no longer matching.  Our first hiccup was we had to change the "-fp-model precise" argument to "-fp-model source", according to the following warning:

"ifort: command line warning #10212: -fp-model precise evaluates in source precision with Fortran."

Sorry, but I'm having an extremely difficult time digesting that error message.  Upon examination of the manpage, it states that option fp-model precise is converted to fp-model source, however, just a few lines higher up in the manual it outlines that "precise" and "source" appear to do two completely different things.  Is "precise"also setting "source"?  It also seems to suggest you can select multiple options from the three groups listed, but doesn't say how.  "-fp-model precise,source" throws an error, "-fp-model precise -fp-model source" issues the same warning above, implying it is being ignored.

FWIW, here are the flags we're trying to use with 15.0.2:

-extend-source 132 -assume nounderscore -assume nobscc -align dcommons -zero -c -fpe0 -fp-stack-check -ccdefault fortran -traceback -no-global-hoist -fimf-arch-consistency=true -fimf-precision=high -no-fma -fp-model source -prec-div -fp-port -fp-speculation=strict -prec-sqrt -fltconsistency

...and the same debug flags as above.

Thanks in advance to any insight anyone has to offer.

Sourced allocation problems in 15.0.1

$
0
0

Dear all,

the 15.0.1 ifort compiler produces errors on the following snippets. Are these errors still present in 15.0.2 ?

If someone can give advice, this would help me to decide whether I have to check / change all such "sourced allocation assignments" or just wait for our IT to upgrade the compiler.

Snippet 1:

  • Sourced allocation into polymorphic array
  • Source is allocated function result
program p
	implicit none
	type :: t
		logical :: is_not_empty	! seg. fault without
	end type
	class(t), dimension(:), allocatable :: a

	allocate(a, source=make_alloc())
	print *, allocated(a)		! T
	print *, size(a)			! 0 (wrong)

contains
	function make_alloc() result(a)
		type(t), dimension(:), allocatable :: a

		allocate(a(5))
		print *, size(a)		! 5
	end function
end program

 

Snippet 2:

  • Derived type t has polymorphic component
  • Sourced allocation into array of type(t) fails
program p
	implicit none
	type :: s
		logical :: is_not_empty
	end type
	type :: t
		! CLASS is the problem here
	    class(s), allocatable :: polymorphic_component
	end type
	type(t), dimension(:), allocatable :: a

	allocate(a, source=make_alloc())
	print *, allocated(a)		! T
	print *, size(a)			! 0 (wrong)
contains
	function make_alloc() result(a)
		type(t), dimension(:), allocatable :: a

		allocate(a(1))
	end function
end program

 

Snippet 3:

  • Similar to snippet 2 but errorneous code is executed in subroutine
  • Runtime-error (different, though probably related to snippet 2)
module m
	type :: s
		logical :: is_not_empty
	end type
	type :: t
	    class(s), allocatable :: polymorphic_component
	end type

contains
	subroutine main()
		implicit none
		type(t), dimension(:), allocatable :: a

		allocate(a, source=make_alloc())
		print *, allocated(a)		! T
		print *, size(a)			! 0 (wrong)

	end subroutine

	function make_alloc() result(a)
		type(t), dimension(:), allocatable :: a

		allocate(a(1))
	end function
end module

program p
	use m
	implicit none

	call main()

	! forrtl: severe (153): allocatable array or pointer is not allocated
end program

 

An other question to Intel: On the new free-software page, for students / researchers (=me) non-commercial licenses are not offered for Fortran any more. How can I test features and report bugs in the latest compiler? (here, IT departments usually don't have the very latest version, for stability and maintainance reasons)

Thanks,

Ferdinand

Help system in VS2012 screwed up?

$
0
0

I have Intel Fortran Composer 2015.2.179 installed in VS2012 pro.

I an not a regular user and have not used it for a while and on opening it and hoping to do a Help search for help on some Windows API functions,
I find I can only select Intel Compiler and Libraries help and its search is restricted to Fortran stuff. If I type in 'SendMessage' or any other Windows API function name or Windows resource name I get a null return.

I recall in the past having access to a much wider search ability, so I am wondering if my help system has been screwed up since I installed the latest composer version.

I recall in the past being able to choose the help system before, but that option appears to be missing from the Help menu in VS2012 now.

Please can you update me on how I might be able to merge the Intel Fortran help with the wider API help that typically was available in the old Visual Studio Compaq Visual Fortran Help.

AttachmentSize
DownloadVS2012HELP.bmp5.49 MB

Command prompt and Visual Studio 2010

$
0
0

I downloaded Intel Parallel Studio XE 2015 composer edition for Fortran, evaluation 30 days.

My OS is Windows 8.1.

I cannot find the path to the command prompt with intel compiler (both IA-32 and Intel 64) along with Microsoft Visual Studio 2010 Shell.

Any help would be highly appreciated, thanks!

 

Aggregate profiling data collected by -profile-functions in the compiler flag

$
0
0

Hi All,

I intend to profile the Community Earth System Model (CESM) climate application. I am running this MPI code on 8 nodes (each with 16 core processors and hence entirely 128 processors and I run 128 processes -1 on each processor). I want to find out the execution times of the fortran functions along with the number of calls made. 

I am profiling at the compiler stage by adding -profile-functions flag as the compiler flags. This is helping me get the statistics over different files (dump and xml files). I wanted to know if there is anyway I can aggregate the statistics over these files. This will help me identify hotspots, right? 

Thanks,

Aketh. 

XE 2015 Installer has no options

$
0
0

The latest installer no longer gives us options for which version of Visual Studio to install on. In fact it presents no options at all.

VS version was a useful feature because it allowed me to maintain old and incompatible compiler versions on older VS versions, keeping separation without needing multiple workstations.

When will we get better support for older compiler versions, such as being able to set compiler version as a solution property rather than a Visual Studio property ?


How to convert an O file to fortran source file

$
0
0

Hi all,

I have received from somebody else a Fortran object file (created under Linux). Can I convert it back to the source file? (I have Windows 7)

OpenMP: Loops are not parallelized

$
0
0

Hi 

I'm writing a Fortran-Program with Open-MP. 

!$OMP PARALLEL
!$OMP DO PRIVATE(j)
       DO I=1,10
          j = aIndex(I)
          ...
          VALUES(j) = ...
       END DO
!$OMP END DO
!$OMP END PARALLEL

The compiler refuses to parallelize this:

OpenMP Construct at file.for(2255,7)
   remark #16201: OpenMP DEFINED REGION WAS PARALLELIZED
...

LOOP BEGIN at file.for(2258,7)
   remark #17104: loop was not parallelized: existence of parallel dependence
   remark #15300: LOOP WAS VECTORIZED
LOOP END

Actually I *do* know, that aIndex contains only different indexes. Therefore the loop *can* be parallelized.

Is there any way to overrule the compiler? In OpenACC for example I could write

!$acc loop independent private(j)

Thanks

Benedikt

Downgrade Rights?

$
0
0

Dear All,

Firstly, apologies for my naivety - I'm not familar with Fortran products. I've been placed in charge of finding out some information regarding software we need to use on a current project.

We currently have a license for Intel Visual FORTRAN Studio XE (v2013) - we need to use an older version of this software for the project, namely version: Intel Visual FORTRAN Standard Edition (v10.1).

Is this possible with the license we have?

Any help is greatly appreciated.

Thanks in advance,

Jake Bloomfield

Go To Definition and type-bound procedures

$
0
0

Steve,

By the way, you may have noticed "Go To Definition" doesn't fully work with type-bound procedures: for example, if one right-clicks on bar in line 6 in the snippet below, it will be really great if the cursor jumped to the definition of bound procedure (possibly a rename or a generic) of bar in type t in module m!  Right now, it doesn't seem to do anything.

   ..
   use m, only : t
   ..
   type(t) :: foo
   ..
   call foo%bar(..)
   ..

Possibly a difficult feature to implement, but it will be cool if available!

Pointer association and red-black trees

$
0
0

I'm trying to implement a red-black tree in Fortran. Rather than starting from scratch I'm translating some c-code I found on the internet. Both the original code and my Fortran versions are attached together with a Makefile; the c version works as I expect.

The problem I'm having is that line 373

            newn%parent => oldn%parent

seems to corrupt the contents of oldn but not on the first invocation. Tested with 14.0.1.139.

Is this a compiler bug, a typo in my code or something else. I've been thinking about this all afternoon and just can't see what the problem is. Any help greatly appreciated.

Simon

AttachmentSize
Downloadrbtree.tgz7.01 KB

Error# 6634 and 8284 and 7710

$
0
0

I will start with I am new to Fortran and to this forum so if there are any suggestions. Thanks in advance.  

My issue I that I keep coming across is error 6634 and 8284 when trying to use subroutines that operate on element operations.  I have created a simple routine to hopefully illustrate my problem as my code is too large to include. 

I have also included my workaround for Error 7710 related to passing a section of an array and wanted to know if there is a better workaround or best practice?

 

    program Test_Scale_Array

    implicit none

    ! Variables
    REAL(KIND=8), Dimension(:), Allocatable :: var3
    REAL(KIND=8), Dimension(1:10)           :: var2,exponent
    REAL(KIND=8)                            :: var4
    integer,      Dimension(5)              :: x
    integer                                 :: i

    ! Body of Test_Scale_Array
    var2     = 4.0D0
    var4     = 4.0D0
    exponent = 2.0D0
    !have routine that is meant mostly for this
    call simplesquare(var2,exponent)

    !Gives Error 8284 & 6634
    call simplesquare(var4)

    !Gives Error 6634
    call simplesquare(var2(2),exponent(2))


    !Selection and calculation on a portion of array
    x = (/(2*i,i=1,5)/)

    !Gives error #7710
    call simplesquare(var2(x))

    !Is there a faster/better way for the workaround?
    Allocate( var3(1:5) )
    var3 = var2(x)
    call simplesquare(var3)
    var2(x) = var3
    deallocate( var3 )

    contains

    subroutine simplesquare(x,y)
    ! Variables
    REAL(Kind=8), Dimension(:), INTENT(inout) :: x
    REAL(Kind=8), Dimension(:), OPTIONAL      :: y

    ! Body of simplesquare
    if (present(Y)) then
    x = x**y
    else
    x = x**2
    endif

    end subroutine simplesquare

    end program Test_Scale_Array
    

Thanks

Jim

Unhelpful error message array section assignment

$
0
0

I am attempting to assign an array section, e.g.

X(1:N) = Y(1:N)

In the situation that Y has not been declared, the compiler only seems to look at the RHS of the statement, and so assumes that Y is intended to be of CHARACTER type, failing to recognize that the notation also could be an array section.  Since the destination is an array section, then error message 6514 is misleading.

Error 1  error #6404: This name does not have a type, and must have an explicit type.   [UNDECLAREDVAR] C:\Open\kwc54dw\Dev\Winyldmd\trunk\ymd_commands\Show_Stage.f90 107 
Error 2  error #6514: A substring must be of type CHARACTER.   [UNDECLAREDVAR] C:\Open\kwc54dw\Dev\Winyldmd\trunk\ymd_commands\Show_Stage.f90 107 
Error 3  error #6303: The assignment operation or the binary expression operation is invalid for the data types of the two operands.   [UNDECLAREDVAR] C:\Open\kwc54dw\Dev\Winyldmd\trunk\ymd_commands\Show_Stage.f90 107 
 


Cannot find ifort XE 15 in Xcode6.2

$
0
0

Hello, I've installed ifort 15 (and Xcode6.2 with command line tool) and have followed the instructions on https://software.intel.com/en-us/node/524635. to build a fortran file. When I'm suggested to add build rule and to select Intel® Fortran Compiler XE 15.0, I cannot find it under Using. I've tried to reinstall  Intel® Fortran Compiler XE 15.0 and restart Xcode but it still doesn't work.

Pass vector by value?

$
0
0

Dear Intel FORTRAN Support,

I am using Intel Visual FORTRAN Composer XE 2011 on Windows 64-bit.  I would like, if possible, to be able to pass a vector into a subroutine by value as opposed to reference.   I would like to know if there is a way of doing this like in C, i.e., being able to control passing by reference or by value.  From what I have read, it appears that for scalars, I can use the VALUE attribute but this is not valid for arrays.  Is there a way of using the C bindings as a work around to this?

Now, that said, if one can pass by value, is the compiler creating a work array in memory to store a copy of what is being passed?  Would I "save any memory" passing by value as opposed to making a work array copy and passing that as opposed to my actual array?

Thank you very much for your help.

Sincerely,

David

 

 

Memory leak in FORTRAN format with variable string length

$
0
0

Hi,

I am experiencing a memory leak of ~1MB in a subroutine if I am using the following write like statement inside:

    write(*,10)(line(j),j=1,var)
10  format(1x,<var>a1)

where var is variable computed at runtime. Is this a known issue?

I am using ifort 13.1.3.198 Build 20130607 under Windows.

Rak

internal error: derived type containing parameterized derived type

$
0
0

In my case, I have a standard derived type that contains a parameterized derived type. I am not certain that this is legal, but at any rate compiling gives an internal error. I have attached simplified source files which produce the error. The standard derived type is defined as follows:

module type_one
   use type_two   !contains parameterized derived type (two_type)

   implicit none

   type, public :: one_type

      type(two_type(3)) :: two

   contains
      final :: one_destructor
   end type one_type

   private
contains

   subroutine one_destructor(self)
      type(one_type), intent(in)   :: self
   end subroutine

end module type_one

Mac OS X 10.2.2
ifort (IFORT) 15.0.2 20150121

AttachmentSize
Downloadmain.f90100 bytes
Downloadtype_one.f90314 bytes
Downloadtype_two.f90307 bytes

attempt to compare Qparallel vs. Qopenmp compilation (15.0.2)

$
0
0

I thought I remembered that it used to be possible to compile an OpenMP source file with /Qparallel, omitting /Qopenmp.   Now I get an immediate ICE when I try it.  I don't recall seeing any advice about new procedures needed, e.g. to prevent the compiler from seeing OpenMP specific stuff.

I would have kept quiet here and simply submitted it to premier.intel.com if that site were accepting submissions.

Viewing all 3270 articles
Browse latest View live


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