Thank you for reporting this issue. I have escalated it to the developers. The issue number is DPD200237122. I will post any updates I receive to this thread.
Regards,
Annalee
Intel Developer Support
13.0 compiler bug: associating entity in select type missing target attribute
如需更全面地了解编译器优化，请参阅优化注意事项.
- 登录以发表评论
星期日, 07/10/2012 - 08:58
- 登录以发表评论
星期一, 15/10/2012 - 08:18
This program is not standard conformant.
I forgot about C715 (R733) which states:
"If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymorphic, or of a type with the BIND attribute or the SEQUENCE attribute."
The developers are working to improve the error message.
Note: I tested the sample program with bind(c), and it still gives an error. I have escalated it to the developers as DPD200237400. I will post any updates I receive on that issue as well.
- 登录以发表评论
星期一, 15/10/2012 - 09:59
Annalee-
Actually you're right that my example isn't standard conforming, but not for the reason you cite. In my zeal to strip the example down to the bare minimum I wound up with a CLASS IS (INTEGER) which is illegal (intrinsic types not allowed in a class is --- an error that the compiler should have detected). I've attached a fixed example, and my original assertion that the compiler has a bug remains.
I'd agree with your analysis if this were a pointer assignment statement, but it's not. This is a SELECT TYPE statement and there are a whole set of rules that apply to the associate-name (which is not a data-pointer-object):
16.4.7: "The associate name of a SELECT TYPE construct has a separate scope for each block of the construct. Within
each block, it has the declared type, dynamic type, type parameters, rank, and bounds specified in 8.1.9.2."
For the type(integer) block 8.1.9.2.5 says: "Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter values of the selector.
And for the type(foo) block 8.1.9.2.6 says: "Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and has the declared type named in the type guard statement. The type parameter values of the associating entity are the corresponding type parameter values of the selector."
So in this case the associate name is either polymorphic of class foo or of type integer depending on what block gets executed.
But the important bit is 8.1.9.2.8 which says: "The other attributes of the associating entity are described in 8.1.3.3" which leads back to my original assertion that the associate name has the TARGET attribute, for 8.1.3.3 says: "The associating entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute."
-Neil
附件:
| 附件 | 尺寸 |
|---|---|
下载  intel-bug-20121007-fixed.txt | 1.7 KB |
- 登录以发表评论
星期三, 17/10/2012 - 15:22
In terms of "C715 (R733) If data-target is unlimited polymorphic, data-pointer-object shall be unlimited polymorphic, or of a type with the BIND attribute or the SEQUENCE attribute."
The issue is with.:
type :: foo
integer :: n
end type
It should be:
type :: foo
sequence
integer :: n
end type
That still gives an error though, which is part of DPD200237400.
- 登录以发表评论
星期三, 17/10/2012 - 16:10
Annalee-
To which statement do you think C715 (R733) applies? I think you're looking at
select type (uptr => return_uptr())
and thinking that "uptr =>return_uptr()" is a pointer assignment statement; it's not and C715 (R733) does not apply. It uses the same kind of syntax but it is something else entirely. It is called a construct association: see 16.5.1.1 and 16.5.1.6. My (fixed) example is standard conforming, and I reiterate that there is a bug, but it's not what you're going after.
- 登录以发表评论
星期三, 17/10/2012 - 19:30
I am looking at :
function return_uptr () result (uptr)
class(*), pointer :: uptr
uptr => obj
end function
in the module.
To be clear, I agree with you that there is a bug in how our compiler is handling objects passed through a class(*) pointer. Changing the code as I have suggested does not cause the error mesage to go away.
- 登录以发表评论
星期三, 17/10/2012 - 19:57
Ah, I see what the confusion is. You've got things backwards. In the statement
uptr => obj
uptr is the data-pointer-object and obj is the data-target (see R733 in 7.2.2.2). The data-target here is not unlimited polymorphic, it's a non-polymorphic variable with the target attribute, and so C715, "If data-target is unlimited polymorphic, ..." doesn't apply to this case at all.
- 登录以发表评论
星期二, 23/10/2012 - 20:40
Ah, I did indeed.
In other news, the issue does not appear to be caused by class(*). It still occurs if class(*) is changed to class(foo). This bug occurs any time the return value of function is used as the selector.
13.0 compiler bug: associating entity in select type missing target attribute
When the selector in a SELECT TYPE construct is the result of a pointer-valued function it should be considered a variable with the POINTER attribute accordiing to R602/C602. It follows then from 8.1.3.3 that the associating entity should have the TARGET attribute, but the 13.0 compiler fails to do this. I've attached a small example the illustrates this bug and gives a bit more detail.
-Neil