- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The attached code produces incorrect answers with the latest compiler - 11.1.064.
-----------------------------------------------------------------------------------------------------
module circleClass
implicit none
type circleObj
real :: radius
end type circleObj
contains
subroutine edit( circle )
class(circleObj) :: circle
write(6,*) circle%radius
end subroutine edit
end module circleClass
!
!------------------------------------------------------
!
program test
use circleClass
implicit none
class(CircleObj), allocatable :: circles(:)
allocate(circles(2))
circles(1)%radius = 1.
circles(2)%radius = 2.
call edit(circles(2))
end
-----------------------------------------------------------------------------------------------------
The correct answer should be 2.0, not 1.0 as the program produces??? Has anyone seen a similar problem?
-----------------------------------------------------------------------------------------------------
module circleClass
implicit none
type circleObj
real :: radius
end type circleObj
contains
subroutine edit( circle )
class(circleObj) :: circle
write(6,*) circle%radius
end subroutine edit
end module circleClass
!
!------------------------------------------------------
!
program test
use circleClass
implicit none
class(CircleObj), allocatable :: circles(:)
allocate(circles(2))
circles(1)%radius = 1.
circles(2)%radius = 2.
call edit(circles(2))
end
-----------------------------------------------------------------------------------------------------
The correct answer should be 2.0, not 1.0 as the program produces??? Has anyone seen a similar problem?
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is reproducible (at all opt-levels) when using CLASS(in test).Using TYPE (in test) and CLASS (in edit) produces 2.0. I may have a mis-understanding the Fortran standard for CLASS, but the usage in test appears acceptable. I'll inquire w/Development.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel concurred that this appears to be a bug and noted a related post (here). I submitted this bug to Development and will keep this thread updated as I learn more. If convenient, perhaps TYPE can be used as a work around.
(Internal tracking id: DPD200148969 DPD200148818)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
Steve Lionel concurred that this appears to be a bug and noted a related post (here). I submitted this bug to Development and will keep this thread updated as I learn more. If convenient, perhaps TYPE can be used as a work around.
(Internal tracking id: DPD200148969)
As an aside, I ran this code on a competing f2003 compiler (NAG). It compiled with no errors and produced the CORRECT result - 2.0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, our compiler got this wrong. I also noted in my earlier post the previous internal tracking id for the report you filed via Premier. We'll track the resolution under the earlier id. Thanks again for the convenience reproducer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirmed this defect will be fixed in the upcoming 11.1 update 5 inlate January/early February.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11.1 Update 5 (11.1.069 - Linux) is now available.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page