- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think the simple code below that makes use of a parameterized derived type extension with type-bound procedures is ok, but Intel(R) Visual Fortran Compiler XE 15.0.1.148 seems to hang up for me and the process never exits. I wonder if this problem is reproducible.
MODULE m USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : I4 => INT32, SP => REAL32, DP => REAL64 IMPLICIT NONE !.. PRIVATE !.. PUBLIC :: I4, SP, DP TYPE :: b_t(k,n) PRIVATE INTEGER(I4), KIND :: k = SP INTEGER(I4), LEN :: n = 1 END TYPE b_t TYPE, EXTENDS(b_t), PUBLIC :: e_t PRIVATE REAL(k) :: m_X(n) CONTAINS PRIVATE PROCEDURE, PASS(This) :: SetX_SP PROCEDURE, PASS(This) :: SetX_DP GENERIC, PUBLIC :: SetX => SetX_SP, SetX_DP END TYPE e_t CONTAINS PURE SUBROUTINE SetX_SP(This, Arr) CLASS(e_t(SP,*)), INTENT(INOUT) :: This REAL(SP), INTENT(IN) :: Arr(:) IF (SIZE(Arr) == This%n) THEN This%m_X = Arr END IF RETURN END SUBROUTINE SetX_SP PURE SUBROUTINE SetX_DP(This, Arr) CLASS(e_t(DP,*)), INTENT(INOUT) :: This REAL(DP), INTENT(IN) :: Arr(:) IF (SIZE(Arr) == This%n) THEN This%m_X = Arr END IF RETURN END SUBROUTINE SetX_DP END MODULE m
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To elaborate a little further on the above example, if the derived type is not an extended one, the code compiles without errors or warnings.
MODULE m USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY : I4 => INT32, SP => REAL32, DP => REAL64 IMPLICIT NONE !.. PRIVATE !.. PUBLIC :: I4, SP, DP TYPE, PUBLIC :: t(k,n) PRIVATE INTEGER(I4), KIND :: k = SP INTEGER(I4), LEN :: n = 1 REAL(k) :: m_X(n) CONTAINS PRIVATE PROCEDURE, PASS(This) :: SetX_SP PROCEDURE, PASS(This) :: SetX_DP GENERIC, PUBLIC :: SetX => SetX_SP, SetX_DP END TYPE t CONTAINS PURE SUBROUTINE SetX_SP(This, Arr) CLASS(t(SP,*)), INTENT(INOUT) :: This REAL(SP), INTENT(IN) :: Arr(:) IF (SIZE(Arr) == This%n) THEN This%m_X = Arr END IF RETURN END SUBROUTINE SetX_SP PURE SUBROUTINE SetX_DP(This, Arr) CLASS(t(DP,*)), INTENT(INOUT) :: This REAL(DP), INTENT(IN) :: Arr(:) IF (SIZE(Arr) == This%n) THEN This%m_X = Arr END IF RETURN END SUBROUTINE SetX_DP END MODULE m
------ Build started: Project: TestFor, Configuration: Debug|Win32 ------ Compiling with Intel(R) Visual Fortran Compiler XE 15.0.1.148 [IA-32]... TestMod.f90 Build log written to "file://..\Debug\Win32\TestForBuildLog.htm" TestFor - 0 error(s), 0 warning(s) ---------------------- Done ----------------------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've seen another report of this. Will check it out in detail on Monday.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is very similar, though not identical, to an issue we're already working, ID DPD200363712. I added your example to that case. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve. So does it mean you/Intel can reproduce the apparent "hanging up" of Ifort.exe process with the code snippet in the original topic above? I was worried if the process getting frozen was unique to my setup.
By the way, any idea why a forum search for issue ids doesn't work? I've noticed this before too, but I just did a search on DPD200363712 and no results are obtained.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I can reproduce it. The other report wasn't through the forum, which is why you can't find it. The compiler is going into an infinite loop.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
Yes, I can reproduce it. The other report wasn't through the forum, which is why you can't find it. The compiler is going into an infinite loop.
Steve,
Re: forum search, I did it after you posted your comment. So shouldn't the search have come up with a hit for your comment?
I also just did a search for the issue Id DPD200363307 you referenced in the other topic on PDTs; sorry, but the forum search comes up with no hits for this either.
Is the forum search feature only querying the topic titles and not the comments section?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The index is probably not updated immediately. Then again, I've generally found searching Google with "site:software.intel.com" added to be more effective than the forum search. Google already finds my initial post.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
The index is probably not updated immediately. Then again, I've generally found searching Google with "site:software.intel.com" added to be more effective than the forum search. Google already finds my initial post.
Thanks for the tip about Google! I should have thought about it since I already do that for a couple of other sites.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I expect this problem to be fixed in Update 2, planned for February.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
I expect this problem to be fixed in Update 2, planned for February.
Steve,
The code in the original post gets past the hang up stage with the latest compiler update, but it encounters an internal compiler error with Intel 64 configuration (x64, 64-bit). It compiles fine with IA-32 target (Win32, 32-bit)
------ Build started: Project: TestFor, Configuration: Debug|x64 ------ Compiling with Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]... TestMod.f90 C:\..\TestMod.f90(37): 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 C:\..\TestMod.f90 (code 1)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So it does. Unfortunate. I have reopened the issue with development.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MODULE test IMPLICIT NONE ! TYPE, PUBLIC :: mtype(n) INTEGER, LEN :: n INTEGER :: x(0:n+1) ! does not compile, but compiles with x(0:n) CONTAINS PROCEDURE :: fun END TYPE mtype ! CONTAINS ! SUBROUTINE fun(this) CLASS(mtype(*)) :: this this%x = 0 END SUBROUTINE fun ! END MODULE testPawel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Pawel Matuszyk wrote:
Hi,
I think this is not a problem with a derived type, but rather with definition of the derived type itself. Here, there is a code which does not compile, however, it compiles with x(0:n).....
Your code compiles and executes fine with the latest compiler version, 2015, Update 2 (Intel(R) Visual Fortran Compiler XE 15.0.2.179)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
So it does. Unfortunate. I have reopened the issue with development.
Steve,
Fyi, the code snippets in both Message #1 and #2 now cause an ICE with compiler 16.0, update 1 with x64 target configuration (x86/Win32 compiles with no errors or warnings):
Compiling with Intel(R) Visual Fortran Compiler 16.0.1.146 [Intel(R) 64]... m.f90 m.f90(37): 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 m.f90 (code 1)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I get an ICE for #1 but not #2. Are you using any compile options?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Intel) wrote:
I get an ICE for #1 but not #2. Are you using any compile options?
You're right, it's just for the code in Message #1. I think I made a mistake during the cut-and-paste from this thread and perhaps didn't update the buffer while doing my test. Thanks for catching it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The ICE should be fixed in compiler 16.0.2, planned for February.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page