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

Segfault when passing non-allocated class variable to optional dummy arg

Bálint_A_
Beginner
800 Views

The binary produced with the ifort 17.0.4 @ x86_64/Linux crashes, if a non-allocated class variable is passed to an optional dummy argument. The code below demonstrates the issue.

Best regards,

Bálint

module mymod
  implicit none

  type :: BaseType
    integer :: ii = 0
  end type BaseType

contains

  subroutine optional(bt)
    class(BaseType), optional :: bt

    print *, 'PRESENT:', present(bt)
    if (present(bt)) then
      bt%ii = 42
    end if

  end subroutine optional

end module mymod


program myprog
  use mymod
  implicit none

  class(BaseType), allocatable :: btClass
  type(BaseType), allocatable ::  btType

  allocate(btType)
  call move_alloc(btType, btClass)
  call optional(btClass)
  deallocate(btClass)
  ! Crashes here
  call optional(btClass)
  
end program myprog

 

0 Kudos
1 Solution
FortranFan
Honored Contributor II
800 Views

Bálint A. wrote:

Yes, indeed. However, I thought it is supported, as it works with all kind of dummy arguments apart of class (even type works.)

It might be an oversight or a bug in the Intel Fortran implementation of this feature introduced starting with Fortran 2008.

You may know Intel now would like you to submit a support request incident at their Online Service Centter (OSC), that's their approach now to ensure the matter is brought to the attention of their compiler development team:

https://supporttickets.intel.com/?lang=en-US ;

View solution in original post

0 Kudos
10 Replies
jimdempseyatthecove
Honored Contributor III
800 Views

The unallocated array descriptor is present, but not allocated.

Consider if it is acceptable to declare the argument as allocatable in additional to optional
(iow require callers to pass only allocatable objects (or none))

Jim Dempsey

 

0 Kudos
Bálint_A_
Beginner
800 Views

Thanks a lot for the suggestion!

Sure, that would be a workaround around this compiler bug (all other compilers I've tried get it right). Actually, I could even leave away the optional attribute in that case and make the dummy argument allocatable only. However, I find neither of the two workarounds nice. The subroutine is part of a library, and I want to signalize to the caller, that (1) the argument may or may not be passed, (2) even if the argument is passed, the routine would change only its content, but not its allocation status. If the alloctable attribute is added, point (2) won't be enforced by the compiler any more.

Bálint

0 Kudos
IanH
Honored Contributor II
800 Views

Note this is a Fortran 2008 language feature.  I'm not sure if it is formally supported by ifort yet.

0 Kudos
Bálint_A_
Beginner
800 Views

Yes, indeed. However, I thought it is supported, as it works with all kind of dummy arguments apart of class (even type works.)

0 Kudos
FortranFan
Honored Contributor II
801 Views

Bálint A. wrote:

Yes, indeed. However, I thought it is supported, as it works with all kind of dummy arguments apart of class (even type works.)

It might be an oversight or a bug in the Intel Fortran implementation of this feature introduced starting with Fortran 2008.

You may know Intel now would like you to submit a support request incident at their Online Service Centter (OSC), that's their approach now to ensure the matter is brought to the attention of their compiler development team:

https://supporttickets.intel.com/?lang=en-US ;

0 Kudos
jimdempseyatthecove
Honored Contributor III
800 Views

Balint,

FWIW - you posted a similar thread on 11/13/2015

Jim Dempsey

0 Kudos
Bálint_A_
Beginner
800 Views

Dear Jim Dempsey,

yes, but that affected all variable types if extra checking options were turned on. This one affects only that special case, however, it crashes independently, whether checks are turned on or not. So, while the previous bug seems to have been fixed, this special case still remained.

0 Kudos
Bálint_A_
Beginner
800 Views

Dear FortranFan,

thank you for pointing me to the support. However, I always found reporting bug reports via the official support channel for Intel products too complicated, especially because I every time had to ask the person in my department, who was the registered for this support, to submit my queries. I use also another commercial compiler, where bug reports can be sent informally by mail, and usually you get fast answer, and a fixed compiler within a week. The barrier for reporting bugs for Intel is just too high for me, if I can't use this channel. If Intel developers are not reading it, well, than I can't help...

0 Kudos
FortranFan
Honored Contributor II
800 Views

Bálint A. wrote:

Dear FortranFan,

t.. I always found reporting bug reports via the official support channel for Intel products too complicated ..  The barrier for reporting bugs for Intel is just too high for me, if I can't use this channel. If Intel developers are not reading it, well, than I can't help...

@Bálint A.,

Sorry to read of your experience and position but I can empathize for sure.

I have provided similar feedback to Intel staff re: barriers to submitting incidents at their OSC, it was several months ago but there have been no changes in terms of the OSC layout - it looks like it was designed for those with severe visual handicaps with its ugly large icons and layout and with no coding experience, not C++ and Fortran programmers - and having to answer the same irrelevant and umpteen questions every time.

But the Intel staff at OSC now follows up on my submitted incidents within a few days and communicates with the Fortran development team as needed.  So the issues are getting looked at which is very positive.

By the way, why can't you use the particulars you use to log onto this forum to submit incidents by yourself at OSC also?  Why do you need to ask the person in your department?

0 Kudos
Steve_Lionel
Honored Contributor III
800 Views

True enough - anyone can file a report now.

0 Kudos
Reply