13.0 compiler bug: associating entity in select type missing target attribute

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

AllegatoDimensione
Download intel-bug-20121007.f901.32 KB
10 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

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

Allegati: 

AllegatoDimensione
Download intel-bug-20121007-fixed.txt1.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())


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.

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


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.

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.

This issue was resolved in the recently released v15.0 IFORT compiler, aka Composer XE 2015.

Ron

Accedere per lasciare un commento.