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

Code compiled with IFORT causes ICE (#5623) with IFX

jirina
New Contributor I
1,243 Views

I am trying to switch from IFORT to IFX. While IFORT compiles well, IFX issues an internal compiler error #5623. I was able to narrow the problem down to a short and simple piece of code; I am attaching the solution to this post.

I am using oneAPI Base+HPC 2024.0.1 with Visual Studio 2022 Pro (17.9.4) on Windows 10 Pro.

The main unit is following code:

	program LBM
  
	use Configuration_mod
	use wlog
  implicit none
	type(configuration) :: config
	call WriteIntro()
  
  contains

	subroutine WriteIntro()
	implicit none
  write(*,'(a)') toString(config%idStateFile)
  end subroutine WriteIntro
  
	end program LBM

Type configuration is defined in the module Configuration_mod like this:

	module Configuration_mod

	public :: configuration

	type configuration
		integer, public :: idStateFile
	end type configuration

	end module Configuration_mod

What is causing ICE is the line in the main unit with the call to toString (commenting the line out gets rid of ICE), defined in the module wlog:

	module wlog

	interface toString
  module procedure intToStr, real4ToStr
	end interface toString

  contains
	
	function intToStr(num) result(res)
	character(:),allocatable :: res
	integer,intent(in) :: num
	character(range(num)+2) :: tmp
	write(tmp,'(i0)') num
	res = trim(adjustl(tmp))
  return
  end function intToStr
  
  function real4ToStr(num) result(res)
	character(:),allocatable :: res
	real*4,intent(in) :: num
	character(range(num)+2) :: tmp
	integer(4) :: digitsBefore, digitsAfter, digitsTotal
	digitsBefore = getRealNumberDigitsBeforeDecimalPoint ( num )
	digitsAfter = getRealNumberDigitsAfterDecimalPoint ( num )
	digitsTotal = digitsBefore + 1 + digitsAfter
	write(tmp,'(f<digitsTotal>.<digitsAfter>)') num
	res = trim(adjustl(tmp))
	return
  end function real4ToStr
	
	integer(4) function getRealNumberDigitsBeforeDecimalPoint ( realNumberIn )
	real*4, intent(in) :: realNumberIn
  getRealNumberDigitsBeforeDecimalPoint = 0
  return
  end function getRealNumberDigitsBeforeDecimalPoint
  
	integer(4) function getRealNumberDigitsAfterDecimalPoint ( realNumberIn )
	real*4, intent(in) :: realNumberIn
  getRealNumberDigitsAfterDecimalPoint = 1
	return
  end function getRealNumberDigitsAfterDecimalPoint
  
	end module wlog

If I comment out the function real4ToStr and two functions getRealNumberDigitsBeforeDecimalPoint, getRealNumberDigitsAfterDecimalPoint (their implementation is simplified for the sake of size of this example) called by it, everything is OK. I thus assume there is something wrong with these 3 functions.

If I do not use function getRealNumberDigitsBeforeDecimalPoint, getRealNumberDigitsAfterDecimalPoint in the function real4ToStr, everything is OK too.

This leads to a suspicion that having real4ToStr in the interface block and calling getRealNumberDigitsBeforeDecimalPoint, getRealNumberDigitsAfterDecimalPoint which are just in the module, is something what triggers ICE...

 

(Virus scan in progress ...)
1 Solution
Barbara_P_Intel
Employee
1,223 Views

@jirina, thank you for taking the time to create a small reproducer! I am able to duplicate the ICE on Linux using "-g -O0 -qopenmp". If I remove "-qopenmp" from the compile for LBM.f90, no ICE.

I get the same thing on Windows compiling with "ifx /debug:full /Od /c LBM.f90".

I see the same ICE using a preview of the compiler that will be released in a few weeks.

I'll get a bug report filed.



View solution in original post

0 Kudos
5 Replies
Barbara_P_Intel
Employee
1,224 Views

@jirina, thank you for taking the time to create a small reproducer! I am able to duplicate the ICE on Linux using "-g -O0 -qopenmp". If I remove "-qopenmp" from the compile for LBM.f90, no ICE.

I get the same thing on Windows compiling with "ifx /debug:full /Od /c LBM.f90".

I see the same ICE using a preview of the compiler that will be released in a few weeks.

I'll get a bug report filed.



0 Kudos
jirina
New Contributor I
1,221 Views

Thank you for your suggestion how to get rid of ICE. Unfortunately, disabling OpenMP is not possible for my application, parallel calculation is one of its main features. Since IFORT works, I can stay with IFORT until the issue is resolved.

Regarding the bug report, it is already done as Support Request 06170149. I posted my original question here to make sure that I am not doing something from the Fortran language point of view.

0 Kudos
Barbara_P_Intel
Employee
1,221 Views

Can you remove /Qopenmp for just LBM.f90? I hate to see you run into another issue with ifx after this ICE is fixed.

Do you know you can mix .obj and .mod files between ifort and ifx as long as you don't compile with /Qipo? That is another workaround.



jirina
New Contributor I
1,195 Views

This simple change is actually possible and working, thank you! Fortunately, there are no OpenMP directives in the file causing ICE, so it is no problem to disable processing OpenMP directives. That is a very convenient workaround, allowing me to keep the whole solution/project to be compiled with IFX which is my goal before IFORT is discontinued.

Thank you very much!

0 Kudos
Barbara_P_Intel
Employee
1,186 Views

That's GREAT news!

 

0 Kudos
Reply