Allocating an allocatable array in an assignment sentence produces unexpeted results or segfaults

[Ket_T_]

Dear forum and Intel developers,

Consider the following code:

program hello
    implicit none
    real(kind=8), allocatable, dimension(:) :: x,y
    x=reshape((/1,2,3,4,5,6/),(/6/))
    print *,x
end program

It will produce blank output. The rememdy is to explicitly allocate x before the reshape statement.

Now the following:

program hello
    implicit none
    integer :: istat
    real(kind=8), allocatable, dimension(:) :: x,y
    allocate(x(60),stat=istat)
    call random_number(x)
    y=sin(x)
    print *,y
end program

It sometimes produces blank output, and sometimes it produces segfaults.

As long as I know, in Fortran 2003 allocatable arrays can be allocated dynamically in a statement.

[TimP]

There's far too much implied material to repeat here.  Besides reading a textbook about F2003 allocatable, or the material in the ifort documentation, you should remember that ifort requires the option -assume:realloc_lhs (which you should look up) to implement F2003 automatic reallocation.  Note that there is no automatic allocation in random_number().

If you think that ifort is the only compiler with such issues, you could read the gfortran docs (which do collect the information in more compact form).

[Ket_T_]

Thank you for your reply.

If ifort needs a flag to be specified for implementing 2003 features, "at least", it can alert the user with an apporpriate message. Producing a blank output here is meaningless, while allocating on-the-fly is completely standard in fortran 2003. Furthermore, the users expect a fully working 2003 environment from ifort. If ifort is not going to implement latest features out of the box, it would definitely be more convenient to explicitly state so during the installation or while encountering non-standard features (in ifort point of view). That would prevent users from falling into endless loops to see where they are wrong and from wasting their time.

In addition, gfortran already compiles and runs the code without any problems. Actually, that was just an example. I had written a large code which was going to be compiled with ifort. While gfortran produced correct results, ifort even didn't produce anything or sometimes sefault-ed. And it took half a day to find where the problem is. "I" had to specify an option to be able to use the already defined standards.

Is there a list of features that need an option like this in ifort to be used? This is going to be scary if ifort does not agree with new features to be enabled by default.

Thanks

[TimP]

Ifort option -assume standard-semantics includes several options needed for compatibility with f2003 or gfortran.  No compiler, including gfortran, is entirely useful without studying its options.

ifort -assume standard-semantics -xHost -heap-arrays

could be roughly equivalent to

gfortran -O3 -march=native -funroll-loops --param max-unroll-times=4 -ffast-math -fno-cx-limited-range

As you can see, commercial compiler defaults are more aggressive than gfortran's.