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
| Anhang | Größe |
|---|---|
Herunterladen  intel-bug-20121007.f90 | 1.32 KB |
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
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.
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
| Anhang | Größe |
|---|---|
| Herunterladen intel-bug-20121007-fixed.txt | 1.7 KB |
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.
Annalee-
To which statement do you think C715 (R733) applies? I think you're looking at
select type (uptr => return_uptr())
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.
Ah, I see what the confusion is. You've got things backwards. In the statement
uptr => obj
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.