Intel® Fortran Compiler for Linux* and Mac OS X*

change run time just for a line

Dear all,

I wrote a very complex code. I mean a code with many subroutines and functions. I used to worked fine. Last few days I noticed that the code became very very slow. After that I noticed that this depends by a single line. If I comment this line the code became very fast again.

To be more clear, this is a peace of may code:

internal error: derived type containing parameterized derived type

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:

Cannot find ifort XE 15 in Xcode6.2

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.

Sourced allocation problems in 15.0.1

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:

fp-model and other arguments

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

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

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

 

incompatibilty between libifcore.a between ifort 15.0.0 and 15.0.2

The following affects one of our Library builds, built using ifort 15.0.0 when compiling and linking a main program against

the shared library using ifort.15.0.2 .......

Using ifort 15.0.0 compile up the following in file nag_test_io.f90  and turn into archive 

  Subroutine nag_test_io(string)
      Character (*) string
      Write(6,*) string
    End Subroutine nag_test_io

ifort -O3 -w -auto -fPIC -axAVX,SSE2 -threads -fexceptions -fp-model precise -c  nag_test_io.f90 -o nag_test_io.o

ar rvf libnag_test.a nag_test_io.o

S’abonner à Intel® Fortran Compiler for Linux* and Mac OS X*