Entry poiint problem?

[dajum]

I have the following structure in my code (... where there is more that doesn't really matter):

    Program Main
    COMMON /ARAYS/ A(1000)
    REAL A
...
    call DEG


...

    SUBROUTINE DEG
    COMMON /ARAYS/ A(1)
    REAL A
...
    CALL AERROR('NAME',A(950))



    SUBROUTINE A1
    COMMON /ARAYS/ A(1)
    REAL A
    REAL B1(1)
    INTEGER IDIF
...
    ENTRY AERROR( NAME,B1)
...    
    IDIF = MYFUNC(B1(1),A(1))




A c routine that finds the offset in the array

crint myfunc(p1, p2)
crfloat *p1, *p2;
{
    crint diff;
    diff = p1 - p2;
    return diff;
}

The problem is that this code no longer works.  In this example I expect IDIF = 949

In the debugger it says both NAME and B1 are undefined variables when I try to watch them, but name does get used
correctly in the code.  B1 seems to be a temporary variable rather than actually pointing to the
correct location in the A array.  Inside MYFUNC, p1 has an address that is much less than p2 when I
expect it should be greater such that diff=949.  

We do use /integer_size:64 /real_size:64, and myfunc uses the correct sized variables as the function does work fine in
many other calls where we haven't used ENTRY points like we did with AERROR.  

Is there something I'm missing here as to why this isn't working anymore?

[bmchenry]

am guessing this is older Fortran you are porting to IVF? some of what is in your code appears to maybe similar to the ole tricks used in Fortran IV or before to pass by location v values, etc...but not sure what's going on in your code. I see you declare in common a(1)? then pass A(950) in the argument to AERROR as the second argument then have the common is included in the DEG program that includes the Entry AERROR in subroutine A your NAME is undefined (in the snippets you sent) so perhaps double check the example you sent so some of the erros i mention are fixed and then lets have another look at it. B

[dajum]

CHARACTER *(*) NAME.  But this doesn't affect how it treats A and B1.  It is old code and has worked for many years.  common block ARAYS is dimensioned in the main program.  This is used for all other instances.  DEG is actually in a library and the is compiled telling it to use as an array.  The true size comes from the main definition.  The entry to AERROR is in subroutine A1, not DEG.  AERROR is called from DEG.  I don't think there are any errors in my sample.  Why the debugger thinks variables are undefined within the scope I don't understand. 

[andrew_4619]

Won't you get 949*4 or 949*8 as an answer dependent on if real is 4 or 8 bytes?

[dajum]

No the type in the routine makes it get the right index value.  The problem is the address for the array passed appears to be a temporary rather than an address for the element in the actual array.

[mecej4]

dajum wrote:
 (... where there is more that doesn't really matter)

Such pre-judgements make it less likely that the information presented will suffice to find the source of the problem.

When there are errors in type declaratiions, especially when C pointer size does not equal C/Fortran integer size, a source level debugger is probably not of much help in finding and fixing the problem.

Please present a complete test example.