View previous topic :: View next topic |
Author |
Message |
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Wed Jun 26, 2019 5:19 pm Post subject: UNDEF not working properly |
|
|
I don't normally use UNDEF, however my colleague has just told me that he hasn't been able to use it for about a year now (when there was a new release back then), because of a recurrent issue.
The program below works fine when compiled normally (tested in 32bit). When compiled with undef, it complains:
Run-Time error
Error 15: Attempt to access undefined argument to routine.
So most of the code cannot be checked with /undef because of this issue.
Code: |
!ftn95$free
SUBROUTINE TEST1(IVAL1)
CALL TEST2(IVAL1)
END SUBROUTINE
SUBROUTINE TEST2(IVAL1)
IVAL2 = 99
IVAL1 = IVAL2
END SUBROUTINE
PROGRAM MAIN
ITEST1=0; CALL TEST1(ITEST1)
PRINT*,"ITEST1=",ITEST1
END PROGRAM
|
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Wed Jun 26, 2019 6:56 pm Post subject: |
|
|
Please state the compiler version used. I tried versions 8.3, 8.4 and 8.5, with and without /64, with and without /undef. In every case, the program ran and output "Itest1 = 99". |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jun 27, 2019 12:35 am Post subject: |
|
|
It appears that this is caused by
/inhibit_check 10
Removing this seems to fix the problem. I am going to try with the whole project. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jun 27, 2019 3:50 pm Post subject: |
|
|
Unfortunately there is still an issue, and it is with derived types. Our program is full of these, so we cannot use UNDEF at all unfortunately.
Code: |
!ftn95$free
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"
END SUBROUTINE
SUBROUTINE A_DFLT (PR)
TYPE (STRUCTTYPE), POINTER :: 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()
ALLOCATE (PR_ROOT)
CALL A_INIT (PR_ROOT)
print*,"PR_ROOT%country=",PR_ROOT%country
END SUBROUTINE
END MODULE TESTMOD
PROGRAM MAIN
USE TESTMOD
CALL START()
END PROGRAM
|
|
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jun 27, 2019 8:21 pm Post subject: |
|
|
Please do let me know if you are able to reproduce it. Thanks |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Fri Jun 28, 2019 9:16 am Post subject: |
|
|
Yes this fails for me. The failure has now been fixed for the next release of FTN95.
If you are using v8.50 or v8.51 then I can send you an FTN95 to test. |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Fri Jun 28, 2019 10:25 am Post subject: |
|
|
Hi Paul,
yes please I would love the test the fix! |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Mon Jul 01, 2019 9:34 am Post subject: related issue? |
|
|
hi, i'm trying to compile my entire application under /undef using the "test" v8.51, but when i try to link it, i get an "internal error 42".
without wishing to offend "Deep Thought", what's the answer?
is it that the total size of the object files is just too large?
K |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Jul 01, 2019 12:21 pm Post subject: |
|
|
Kenny
I can see a message like this in SLINK and at first sight it looks like a memory overflow of some kind. We will probably need to be able to reproduce the fault in order to make progress. |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Mon Jul 01, 2019 12:25 pm Post subject: |
|
|
ok, let me know if you want my object files and link script...
K |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Jul 01, 2019 1:46 pm Post subject: |
|
|
Yes. I think we might be able to fix it with this information. |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Mon Jul 01, 2019 1:50 pm Post subject: |
|
|
ok, i'll rebuild the complete set and "hightail" them over to you shortly.
K |
|
Back to top |
|
|
KennyT
Joined: 02 Aug 2005 Posts: 317
|
Posted: Tue Jul 02, 2019 12:18 pm Post subject: |
|
|
you should have received the files now. there may be some path entries in the link scripts that need editing, depending on where you unzipped them to but if you think you're still missing anything, let me know.
K |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Jul 04, 2019 7:31 am Post subject: |
|
|
Contrary to my reply above the FTN95 bug revealed in the code posted by StamK remains unfixed (see code headed with MODULE TESTMOD). The fix was incomplete and remains illusive. It occurs when compiling with /CHECK (or for example /UNDEF which implies /CHECK).
A work-around can be employed to avoid the failure by removing the POINTER attribute as follows...
Code: | SUBROUTINE A_DFLT (PR)
TYPE (STRUCTTYPE) :: PR
PR%COUNTRY = ' '
CALL RU_GetC ('country', 1, PR%COUNTRY)
END SUBROUTINE
SUBROUTINE A_INIT (PR)
TYPE (STRUCTTYPE) :: PR
CALL A_DFLT (PR)
END SUBROUTINE |
This is correct Fortran and could be considered a more logical way of expressing it.
In this code the POINTER attribute is used like ALLOCATABLE to denote delayed allocation whilst in calls to these routines the allocation has already be made. In this sense the POINTER attribute is not relevant. (I am assuming that POINTER is allowed in this context but I am not entirely sure about this.) |
|
Back to top |
|
|
StamK
Joined: 12 Oct 2016 Posts: 159
|
Posted: Thu Jul 04, 2019 11:51 am Post subject: |
|
|
Thanks Paul for the investigation. Unfortunately this is not a solution for us. That was a simple example, but in our cases we cannot get rid of pointers, see below
Code: |
TYPE ZPLT
SEQUENCE
CHARACTER*80 :: TITLE
TYPE (ZPLT), POINTER :: NEXT=>null(), MUM, KID, CKID
|
Because types like the one above are used all over our program, we are not able to use /undef unfortunately. We believe this stopped working with 8.40 (it was around November 2018, we think). |
|
Back to top |
|
|
|