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 Previous  1, 2
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 04, 2019 2:50 pm    Post subject: Reply with quote

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



Joined: 12 Oct 2016
Posts: 110

PostPosted: Thu Jul 04, 2019 5:13 pm    Post subject: Reply with quote

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


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

PostPosted: Thu Jul 04, 2019 5:34 pm    Post subject: Reply with quote

Can you show the context? In might even be a programming error in your code.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Jul 06, 2019 11:14 am    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1181

PostPosted: Mon Jul 08, 2019 1:36 pm    Post subject: Reply with quote

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


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

PostPosted: Mon Jul 08, 2019 2:16 pm    Post subject: Reply with quote

Yes thank you. This code also runs successfully with the new fix.
Back to top
View user's profile Send private message
StamK



Joined: 12 Oct 2016
Posts: 110

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

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



Joined: 12 Oct 2016
Posts: 110

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

Wanted to add that also adding

Code:

  INTRINSIC CCORE1


doesn't solve the issue.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 11, 2019 12:59 pm    Post subject: Reply with quote

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



Joined: 12 Oct 2016
Posts: 110

PostPosted: Thu Jul 11, 2019 1:16 pm    Post subject: Reply with quote

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



Joined: 31 Oct 2006
Posts: 1181

PostPosted: Thu Jul 11, 2019 2:20 pm    Post subject: Reply with quote

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



Joined: 12 Oct 2016
Posts: 110

PostPosted: Thu Jul 11, 2019 2:34 pm    Post subject: Reply with quote

I meant it thinks the second CCORE1 is an integer(kind=3) - of course CCORE1 is a character. As an example, if you do /undef to the example from the Ftn95 documentation below, it will give you the warning above!

https://www.silverfrost.com/ftn95-help/clearwinp/library/copy_from_clipboard_.aspx
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Thu Jul 11, 2019 3:38 pm    Post subject: Reply with quote

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
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 Previous  1, 2
Page 2 of 2

 
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