Apple OS X*

Coarray type with an allocatable component of length zero

I get a SIGSEGV when running the following code

 type t

	  real, allocatable :: a(:)

	 end type t

	 type(t) :: data[*]


	 print*, size(data[1]%a)

	end program

If, instead of the last line I put

print*, size(data%a)

it runs successfully by printing 0 for each image. In principle I could work out the problem by using 'allocated' statements, but



Intel(R) C++ Compiler and Intel(R) Fortran Compiler Do not Work with XCode 5.1*

Reference Number : DPD200254375

  • Intel(R) C++ Composer XE 2013 for OS X* (including update 2)
  • Intel(R) Fortran Composer XE 2013 for OS X* (including update 2)

Problem Description:

If you have recently upgraded to the latest XCode 5.1*, the Intel C++ compiler or the Intel Fortran compiler is not integrated into XCode any more. So the existing projects that are built with Intel C++ compiler or Intel Fortran compiler will fail when building.

Solution Status:

  • Entwickler
  • Apple OS X*
  • C/C++
  • Fortran
  • Intel® C++-Compiler
  • Intel® Fortran Compiler
  • XCode
  • Compiler not detecting missing OMP4 declare target variable

    Most of the time, the compiler will complain if a global variable used in an OMP4 target region is not declared for the target (!$omp declare targt(foo))

    But now I had a (very big) program that compiled without errors (finally after fixing all the missing declares) but failed at runtime with the message:

    Functions returning arrays, derived types and the creation of temporaries.

    Dear all,

    Consider the following situation followed up by a working test case.

    Let there be a derived type wrapping a multidimensional array. Let there further be a function "sum" which adds array components of the objects of a derived type and returns the resulting array. Furthermore, there is a "from_array" assignment subroutine which takes an object and an array, then fills the array component of the object with its array argument.

    Override default component initialization


    I understand the following is not legal:

    module foo
    type :: bar
        integer :: a=53
    end type
    type, extends(bar) :: rab
        integer :: a=-33333 !!! Redefine default initialization
    end type
    end module

    I think this would be quite practical. The only workaround is implementing clumsy constructor wrappers...

    Any thoughts?

    how to call functions in the MKL_lapack95 library

    Hi, I need your help about using the MKL_lapack95 library: I need to call a subroutine ("polyfit.f")  which calls two functions in the MKL_lapack95 library. I am using intel fortran (composer_xe_2013_sp1.2.144) with Fedora 20. The environment should be already set up:

    Superfluous GENERIC OPERATOR specification in extended derived type generated no errors or warnings

    Dear Steve et al. at Intel,

    Can you please review the code shown below and check whether it is ok to have a superfluous GENERIC OPERATOR specification in an extended derived type that is simply a copy of one in the abstract parent?  See lines 17 and 47 in the code snippet, a heavily simplified version of my actual type.

    This code compiles without any errors or warnings in Intel Fortran XE 2013, Update 1 even if standards checking is turned on.

    However, gfortran 4.9 flags an error saying the two procedures for the + operator are ambiguous.

    ICE with -standard-semantics

    Hi all,
       I see and ICE when compiling the following code with -standard-semantics :

    $  ifort -standard-semantics -c ice.f90  
    catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
    compilation aborted for ice.f90 (code 1)

    Apple OS X* abonnieren