Apple OS X*

Override default component initialization

Hi,

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?

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  
010101_13220
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)

Building on Mac OS X 10.9

I'm trying to build the openmprtl on Mac OS X 10.9, to be used with OpenMP/Clang project. Is this supposed to be possible? A new thing with 10.9 is that gcc is just a macro for clang, which maybe is confusing the build scripts.

I try to build with:

make compiler=clang

And I get a build error in check-tools.pl "Cannot parse GNU compiler version" as it has run gcc and get clang output (as gcc is just a macro for clang on 10.9). I was thinking that when you compile with "compiler=clang" the check-tools.pl would not look for gcc at all.

Recursive function and pass by VALUE optimizations

Hi all,

I have some questions about the recursive functions performance in the compiler.

The code is below, the performance table obtains with the compiler 14.  First column is normal, second column is pass by value.

Ifort is slower than gfortran(4.8.2), and is passing by reference creating more copies in the recursive case ?

I don't know if performance is better with old compiler version.

Thanks.

ifort         3.51  1.151

gfortran  2.027  0.452

Optimization causes array index out of bounds

I'm still testing the ffte benchmark. Running it on the host with -O3 -xAVX -openmp works flawlessly and the performance looks great. Now I wanted to use that code on the Intel Xeon Phi. So I replaced the -xAVX option with -mmic in order to create a native binary. With ulimit and KMP_STACKSIZE I increased the stack to avoid a stack overflow.

Suscribirse a Apple OS X*