forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

UNDEF not working properly
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Wed Jun 26, 2019 5:19 pm    Post subject: UNDEF not working properly Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Jun 26, 2019 6:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu Jun 27, 2019 12:35 am    Post subject: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu Jun 27, 2019 3:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu Jun 27, 2019 8:21 pm    Post subject: Reply with quote

Please do let me know if you are able to reproduce it. Thanks
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Jun 28, 2019 9:16 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Fri Jun 28, 2019 10:25 am    Post subject: Reply with quote

Hi Paul,
yes please I would love the test the fix!
Back to top
View user's profile Send private message
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jul 01, 2019 9:34 am    Post subject: related issue? Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jul 01, 2019 12:21 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jul 01, 2019 12:25 pm    Post subject: Reply with quote

ok, let me know if you want my object files and link script...

K
Back to top
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Jul 01, 2019 1:46 pm    Post subject: Reply with quote

Yes. I think we might be able to fix it with this information.
Back to top
View user's profile Send private message AIM Address
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Mon Jul 01, 2019 1:50 pm    Post subject: Reply with quote

ok, i'll rebuild the complete set and "hightail" them over to you shortly.

K
Back to top
View user's profile Send private message Visit poster's website
KennyT



Joined: 02 Aug 2005
Posts: 317

PostPosted: Tue Jul 02, 2019 12:18 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Jul 04, 2019 7:31 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
StamK



Joined: 12 Oct 2016
Posts: 159

PostPosted: Thu Jul 04, 2019 11:51 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group