View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Jul 04, 2019 2:50 pm Post subject: |
|
|
I was not suggesting that the POINTER attribute be removed everywhere and not when defining the TYPE for PR_ROOT.
When you define the routines A_DFLT and A_INIT the PR is of TYPE(STRUCTTYPE) but this PR has now been allocated memory so the POINTER attribute is not needed at these points in the code.
When you define a routine, its arguments do not normally require the POINTER or ALLOCATABLE attribute unless you are about to do the allocation of memory in the current routine.
Perhaps you should consider using ALLOCATABLE rather than POINTER then the fact that the attribute is not used when passing arguments might make more sense.
I have checked earlier versions of FTN95 and I am fairly confident that this is not a regression. If it worked before then I guess that you must have been using /INHIBIT_CHECK 6 (or maybe 10). These switch off pointer checking parts of /CHECK mode.
edited 15.14 |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jul 04, 2019 5:13 pm Post subject: |
|
|
Thanks for that. With /INHIBIT_CHECK 6 (which for some reason must not be just before the filename but a bit before that...) the program above works.
However in our program we now are getting a different error
Error 14: Attempt to alter an actual argument that is a constant, an expression, an INTENT(IN) argument, or a DO variable.
All files with subroutines leading to that call have been put under /undef (a necessary condition).
This is difficult to show to you because the project is fairly large. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Jul 04, 2019 5:34 pm Post subject: |
|
|
Can you show the context? In might even be a programming error in your code. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sat Jul 06, 2019 11:14 am Post subject: |
|
|
The bug described above relating to false error reports has now been fixed for the next release of FTN95. This occurs when /CHECK is applied to a program that contains dummy arguments that have the POINTER attribute.
As I mentioned above, the POINTER attribute is not appropriate in the context of these dummy arguments but is presumably acceptable Fortran. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Jul 08, 2019 1:36 pm Post subject: |
|
|
Where to allocate and release pointer variables is at the discretion of the programmer, and there may be good reasons why that should be done in one place rather than another -- reasons that may not be visible in a cut down example.
The following is a rearrangement of StamK's original code, in which the allocation of the pointer variable is done just-in-time. In this version, the pointer attribute is required for the dummy arguments, and FTN95 8.51 still displays the same errors as before. The error ("attempt to access undefined argument to routine") is clearly wrong, since the statement is assigning a value to CVAL, which is a component of the previously allocated variable PR.
Code: | MODULE TESTMOD
TYPE STRUCTTYPE
SEQUENCE
CHARACTER*60 :: COUNTRY
END TYPE STRUCTTYPE
TYPE (STRUCTTYPE), POINTER :: PR_ROOT
CONTAINS
SUBROUTINE RU_GetC (PAR, K, CVAL)
CHARACTER*(*) PAR, CVAL
CVAL = "England" ! Line-14, where error occurs with /undef
END SUBROUTINE
SUBROUTINE A_DFLT (PR)
TYPE (STRUCTTYPE), POINTER :: PR
ALLOCATE(PR)
PR%COUNTRY = ' '
CALL RU_GetC ('country', 1, PR%COUNTRY)
END SUBROUTINE
SUBROUTINE A_INIT (PR)
TYPE (STRUCTTYPE), POINTER :: PR
CALL A_DFLT (PR)
END SUBROUTINE
SUBROUTINE START()
CALL A_INIT (PR_ROOT)
print*,"PR_ROOT%country=",PR_ROOT%country
NULLIFY(PR_ROOT)
END SUBROUTINE
END MODULE TESTMOD
PROGRAM MAIN
USE TESTMOD
CALL START()
END PROGRAM |
I hope that the updated compiler works correctly on this modified version, too. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Jul 08, 2019 2:16 pm Post subject: |
|
|
Yes thank you. This code also runs successfully with the new fix. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jul 11, 2019 11:25 am Post subject: |
|
|
The following code produces a strange warning under undef
Code: |
SUBROUTINE A_CopyBytes (IAD1, IAD2, N)
INTEGER(KIND=7) :: IAD1, IAD2
IF( N.LT.1 ) RETURN
CALL MOVE@ (CCORE1(IAD1), CCORE1(IAD2), N)
END
|
Code: |
0006) CALL MOVE@ (CCORE1(IAD1), CCORE1(IAD2), N)
WARNING - 362: Assigning a value of type CHARACTER(LEN=1) to a variable of type INTEGER(KIND=3) is a non-standard
extension, use the TRANSFER intrinsic
WARNING - 362: Assigning a value of type CHARACTER(LEN=1) to a variable of type INTEGER(KIND=3) is a non-standard
extension, use the TRANSFER intrinsic
|
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jul 11, 2019 11:27 am Post subject: |
|
|
Wanted to add that also adding
doesn't solve the issue. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Jul 11, 2019 12:59 pm Post subject: |
|
|
The warning is benign and relates to a more general case rather than this unusual and strangely convoluted construction. On the face of it a direct call to MOVE@ would be simpler (or indeed TRANSFER to be standard conforming).
Code: | SUBROUTINE A_CopyBytes (IAD1, IAD2, N)
INTEGER(KIND=7) :: IAD1, IAD2
IF( N.LT.1 ) RETURN
CALL MOVE@(CCORE1(IAD1), CCORE1(IAD2), N)
END
program main
integer iad1,iad2
iad1 = 42
call A_CopyBytes(LOC(iad1), LOC(iad2), 4)
print*, iad2
iad2 = 0
CALL MOVE@(iad1, iad2, 4)
print*, iad2
end |
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jul 11, 2019 1:16 pm Post subject: |
|
|
Thanks Paul. I presume that with UNDEF it thinks CCORE1 is a character? So that this is a bug, albeit a benign one.
Regarding the previous (pointer related) bug that you fixed, it still is not fully fixed and it still crashes - but more deep inside a large program and not in the simple program. We are packaging a program to send over and you/Robert hopefully soon can have a look at it.
Thanks |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Thu Jul 11, 2019 2:20 pm Post subject: |
|
|
CCORE1 is intrinsic and of type character, as you can see in the FTN95.CHM file or on the online help pages. If you do not specify /check, /undef or another option that implies /check, no warnings are issued if actual arguments are of different types than expected.
Since MOVE@ is agnostic to argument types, why do you need to apply CCORE1 to the actual arguments? That is, as Paul already indicated, why not simply write CALL MOVE@(IAD1,IAD2,N)? |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Jul 11, 2019 3:38 pm Post subject: |
|
|
This particular warning is normally very useful but in this unusual construction it is false. I have not added this to the list of things to fix because the context is so unusual and is unlikely to reoccur.
Just to clarify, most of the issues that StamK has raised relate the checking options within /CHECK. It just happens that /UNDEF and similar options imply /CHECK. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Fri Dec 04, 2020 12:27 am Post subject: |
|
|
When running the debugger on Testmod example above by mecej4, I am still getting the same error
Attempt to access undefined argument to routine
Compiled with 8.70. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Fri Dec 04, 2020 8:21 am Post subject: |
|
|
StamK
The "fix" mentioned above caused a regression that was identified just before v8.70 was released. Rather than delay the release, the decision was made to remove this particular fix pending further work.
This work has now been completed so the issue will be resolved in the next release of FTN95. |
|
Back to top |
|
|
|