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.

!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

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'.

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.

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.

!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

Please do let me know if you are able to reproduce it. Thanks

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.

Hi Paul, yes please I would love the test the fix!

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

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.

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

K

Yes. I think we might be able to fix it with this information.

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

K

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

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...

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.)

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

 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).

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

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.

Can you show the context? In might even be a programming error in your code.

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.

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.

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.