UNDEF not working properly

Yes thank you. This code also runs successfully with the new fix.

The following code produces a strange warning under undef

SUBROUTINE A_CopyBytes (IAD1, IAD2, N)
  INTEGER(KIND=7) ::    IAD1, IAD2
	IF( N.LT.1 ) RETURN
	CALL MOVE@ (CCORE1(IAD1), CCORE1(IAD2), N)
 
END





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

Wanted to add that also adding

  INTRINSIC CCORE1

doesn't solve the issue.

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

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 

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

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

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

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.

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.

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.

A general comment concerning the use of the POINTER attribute when declaring a dummy argument...

In this context, the POINTER attribute is almost identical to the ALLOCATABLE attribute. It amounts to the same thing from the compiler writers' point of view but has different rules in the Fortran Standard.

The POINTER attribute (on a dummy argument) is only needed when an associated ALLOCATE (to the pointer) is anticipated within the current routine (or within a routine that is called from the current routine).

In other situations, the POINTER attribute is allowed but has no effect other than to add an unnecessary overhead to the compiled code. It is tempting to assume that, if the corresponding actual argument has the POINTER attribute, then the dummy argument should also have it, but this is not the case.

When the POINTER attribute is used on a dummy argument, the compiler must provide a mechanism to pass the SHAPE of the ALLOCATEd object back to the calling routine. The SHAPE can be unknown to the calling routine and defined by a call to ALLOCATE within the current routine. This definition could be at compile time or at run time.

FTN95 can be used with /CHECK to provide runtime checks for pointers that have not been allocated.