Error 6731 in version 11.1.072

Error 6731 in version 11.1.072

The following code gives error 6731 Object is not a pointer object XG.

I understand this was fixed in 2011, but is there a workaround in 11.1?

    program testsize
    real,allocatable,target :: XG__(:,:)
    real,pointer :: XG(:)    
    allocate(XG__(12,12))
    XG(1:size(XG__)) => XG__
    XG(1)=1.0
    write(*,*)XG__(1,1)
    STOP
    END

 

19 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Take a look in this code, it works:

 

    program testsize
    real,allocatable,target :: XG__(:,:)
    real, pointer :: XG(:) 
       
    allocate(XG__(12,12), XG(12))
    
    XG => XG__(1,1:12)
    XG(1)=1.0
    write(*,*)XG__(1,1)
    STOP
    END

 

You need to take care on the array's dimensions.

Ketson Roberto

well it works, but it doesn't do what I intend to do which is span the entire 2d array with a 1d array.  Trying to span the whole array gives an error that the rank of the target is different from the pointer.  So I'm still looking for a functional work around here.

I think that when you are trying to span the entire 2d array with a 1d array is the problem, I am not sure, but I belive that you should to work with the array's dimension before.  

Ketson Roberto

It isn't a problem in any version after 11.1.  There is no problem accessing data from different ranks and that is why it works in the newer versions.  If it doesn't work in 11.1 then I can't support that version with my code, and I try to support all versions.  Thanks for taking a look at this as many eyes looking at a problem often see a different path to a solution.

Do you need to have both XG things active in the same scope?  If not, you could pass the allocatable variant to a procedure taking a rank one explicit shape array, do the pointer assignment in that procedure and the work with the pointer in that procedure.  If you need them in the same scope then I think you are in processor dependent territory, and I'm not sure what ifort's behaviour in the face of that processor dependent behaviour is.

PROGRAM testsize
  IMPLICIT NONE
  real,allocatable,target :: XG__(:,:)
  real,pointer :: XG(:)
  allocate(XG__(12,12))
  CALL point_me_in_the_right_direction(XG__, SIZE(XG__))
  write(*,*)XG__(1,1)
CONTAINS
  SUBROUTINE point_me_in_the_right_direction(array, sz)
    INTEGER, INTENT(IN) :: sz
    REAL, INTENT(INOUT), TARGET :: array(sz)
    XG => array
    XG(1)=1.0
  END SUBROUTINE point_me_in_the_right_direction
END PROGRAM testsize

(The XG pointer may or may not be undefined after the procedure finishes - that's the processor dependent bit.)

Edit because I did something silly.

The real usage is actually more complicated because I intend to actually do this twice with XG declared in two modules.  Once as a 2d pointer and once as a 1d pointer, both pointing to actual memory allocated by XG__.  The two versions of XG (via the two modules) will never both be referred to in the same unit.  Both modules will refer to the module containing the definition of XG__.  The problem I've had is the compiler seems to recognize the difference in ranks when trying to get the 1d array assigned.  Not sure why in your version the compiler doesn't complain about passing a 2d array to a function expecting a 1d array.  That's what I didn't seem to get to work. THe CONTAINS must do something that disables the 3761 error here.  I'll try and factor a contains into my code somewhere and see if it will work.  Thanks!
 

It's nothing to with the CONTAINS per se - that's just there for the sake of the example.  Since the olden days, you have been able to do that sort of rank remapping with procedure arguments - it is a variety of sequence association.

Pointer rank remapping is a F2003 feature, if I remember correctly.  It didn't exist in earlier Fortran standards, hence earlier Fortran compilers don't know about it.

Because of the CONTAINS the definition for XG is outside of the subroutine.  Try including a definition inside the routine and it fails on one compiler error or another.  I'm still trying to see how I can include it in my code

 

 

Can you explain why this may be processor dependent.  Random failures would not be good.

Moved

Thanks!

Citation :

dajum a écrit :

Can you explain why this may be processor dependent.  Random failures would not be good.

That's what the standard says - see 12.5.2.4 in F2008 for the usage relevant to the example above.

Citation :

If the dummy argument has the TARGET attribute and is an explicit-shape array, an assumed-shape array with the CONTIGUOUS attribute, or an assumed-size array, and the effective argument has the TARGET attribute but is not simply contiguous and is not an array section with a vector subscript then

• on invocation of the procedure, whether any pointers associated with the effective argument become associated with the corresponding dummy argument is processor dependent, and
• when execution of the procedure completes, the pointer association status of any pointer that is pointer associated with the dummy argument is processor dependent.

It is the last bit that is significant.

Doesn't the qualifier "but is not simply contiguous and is not an array section with a vector subscript" have to apply for it to become processor dependent?

 

 

Just FYI, in standards-speak, for "processor" read "compiler". It doesn't mean CPU. When the standard says something is processor-dependent, it means that the specific implementation may choose a behavior. Contrast with "undefined", which means anything goes.

Steve - Intel Developer Support

True - but the "simply contiguous" thing is a F2008 change.  Standards before F2008 didn't have the concept of "contiguous", and we all know that nothing is ever simple.

Dr Fortran - so what is ifort's chosen behaviour in this area?

(There was a discussion on c.l.f related to this a few weeks back, during which I think I concluded that the chosen behaviour was "pointer association status becomes undefined".  But that had other aspects to it too.)

Well my testing of this workaround hasn't shown any problems.  Seems to work for the cases I've tested.  The pointer assignment happens and seems to persist throughout the run, as passed to other routines via the module.

Many thanks Ian!

Ian, I'll have to study this question and get back to you. I don't want to answer offhand as my experience is that I'm often mistaken!

Steve - Intel Developer Support

First of all, I need to mention that F2008 Corrigendum 2 relaxed the restrictions regarding the CONTIGUOUS attribute. Previously, if you had CONTIGUOUS on an assumed-shape dummy argument, you were not allowed to pass anything other than a "contiguous effective argument" to it. Corrigendum 2 now says that the dummy argument is received as contiguous, which means that if you pass a non-contiguous actual argument that the compiler needs to do whatever is needed (such as passing a contiguous temp copy) to make it contiguous on receipt (and to store any changes on return). Intel Fortran doesn't yet do that, though we have started to work on it. This is our issue DPD200241665.

While this doesn't exactly tie in to the question at hand, it does suggest a further complication if what gets received in a subroutine is a copy rather than the original. This is sort of what 12.5.2.4 paragraph 10 is trying to get at - you don't know how this affects the status of OTHER pointers that are associated with the "effective argument", nor what happens to pointers pointing to the dummy argument on return.

I'm not aware that we want to promise any particular behavior here. If we don't do copy-in/copy-out, then pointers should remain defined. If we do copies, then all bets are off. Doctor Fortran prescribes avoiding routines that save pointers to dummy arguments, unless you can be certain that you're not violating the rules in 12.5.2.4p10. Moreover, the compiler won't be able to stop you from getting into trouble here.

Steve - Intel Developer Support

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui