Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

bugs make my playing ping pong between 17 and 16.0.4

may_ka
Beginner
284 Views

With regard to this

https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/675652

I went back to 16.0.4 which gave me my dynamic library .................. but the code below failed with a segfault, while 17 is giving the correct results:

Module mod_t1
  Implicit None
  Type t1
    Private
    Integer :: a=8
  contains
    Procedure, Pass, Public :: getA => FunGetA
  End type t1
  Private FunGetA
contains
  Function FunGetA(this)
    Class(t1), Intent(In) :: this
    Real, Allocatable :: FunGetA
    FunGetA=this%a
  End Function FunGetA
End Module mod_t1
Program Test
  use mod_t1
  Type(t1) :: b
  write(*,*) b%getA()
End Program Test

Thus, I either rewrite heaps of allocatable functions ................ or I forget about getting a dynamically linked library.

0 Kudos
2 Replies
IanH
Honored Contributor II
284 Views

I would expect a segfault with 16.0.4 if the program in #1 was compiled without -standard-semantics.
 

0 Kudos
Steven_L_Intel1
Employee
284 Views

To elaborate on Ian's answer, the assignment at line 13 assumes the Fortran 2003 feature of automatic (re)allocation on assignment to allocatable arrays. Up through version 16, this feature was disabled by default - you could enable it using /assume:realloc_lhs or by /standard-semantics (the latter enables all options whose defaults are not standard-conforming.) In version 17, this feature is ON by default, which is why the program works in 17. This is all explained in great detail in the 17.0 release notes.

There are no bugs evident here.

0 Kudos
Reply