Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Generic Name signature problem

jimdempseyatthecove
Honored Contributor III
771 Views

I am seeking a solution to a problem and I am attempting to use ageneric named interface block to resolve the calling issue.

What I want to do is pass integer by value, everything else by reference. This means I want the address of the array descriptor passed and not the location of the first cell of the descriptor. Using !DEC$ ATTRIBUTES C does not do this for me. As I get the address of the 1st cell and REALs are passed by value (which I don't want).

The arguments being passed are unknown in number and sequence. And if known for an application, the permutaions would be too many to warrant writing every possible combination.

Side bar

Consider

select case(expr)
case(value1)
statements1
case(value2)
statements2
case default
statementsDefault
end select

Where you have a set of matching filter values, and something to do when none of the filter values produce a match.

End side bar

What I wish to do is have the equivilent of the "case default" for the interface. My attempt at doing this is something like:

interface Generic
subroutine GenericInt(i)
!DEC$ ATTRIBUTES VALUE :: i
integer :: i
end subroutine GenericInt
subroutine GenericOther1(X1)
type T_Opaque
integer :: dummy
end type T_Opaque
!DEC$ ATTRIBUTES NO_ARG_CHECK :: X1
type(T_Opaque), pointer :: X1
end subroutine GenericOther1
subroutine GenericOther2(X1,X2)
type T_Opaque
integer :: dummy
end type T_Opaque
!DEC$ ATTRIBUTES NO_ARG_CHECK :: X1
type(T_Opaque), pointer :: X1
!DEC$ ATTRIBUTES NO_ARG_CHECK :: X2
type(T_Opaque), pointer :: X2
end subroutine GenericOther2
end interface Generic
The problem is GenericInt produces a signature
error with GenericOther1.
If I omit GenericInt then I get the array descriptor that I want
and reference for everything else (and value for external),
excepting that integer passes by reference.
A potential fix for this problem is a suggestion for a new
compiler intrinsic value(ivar). Example:
call foo(value(ivar))
call foo(OtherThingByReference)

Jim Dempsey

					
				
			
			
				
			
			
			
			
			
			
			
		
0 Kudos
4 Replies
Steven_L_Intel1
Employee
771 Views
Look up %VAL in "built-in functions".
0 Kudos
jimdempseyatthecove
Honored Contributor III
771 Views

Steve,

Thanks, that's just what I want. (RTFM)

Why doesn't the documentation, in the sections regarding calling conventions, include

See also %VAL (with a hyperlink)?

It would have saved me about two days of mucking around. (Same thing for %REF).

I almost have my app running again :).

When you talk with the developers next time, you might ask that they consider permitting a generic name with an explicit argument type to disambiguate with an argument of NO_ARG_CHECK. Even though the number of arguments are the same.

I've found it handy to use

!DEC$ ATTRIBUTES NO_ARG_CHECK :: arg
integer, pointer, optional :: arg

As a means to pass variable number of args by reference (and pass array bydescriptor). The by value gave me a problem but the %VAL should fix that now. Think about adding %DES to pass array by descriptor too.

Thanks again,

Jim Dempsey

0 Kudos
Steven_L_Intel1
Employee
771 Views
On VMS we had %DESCR, but that's not supported on non-VMS platforms. I seem to recall we had a discussion of allowing NO_ARG_CHECK to bypass type-kind-rank checking for generics, I'm not sure where that went.
0 Kudos
jimdempseyatthecove
Honored Contributor III
771 Views

I do not want NO_ARG_CHECK to bypass type-kind-rank checking for generics. I want it to behave differently.

If an explicit interface without NO_ARG_CHECK matches and if an interface with NO_ARG_CHECK matches I want it to choose the interface without NO_ARG_CHECK thatmatches without complaining about multiple interfaces matching. As the interfaces are not matching at the same degree of strength.

A similar situation will arise if you have an interface with an object reference and you call with an object pointer. The compiler will dereference the pointer. The programmer may want two different interfaces one with an object pointer, the other with an object reference. Only upon the lack of the other interface should the compiler perform a friendly conversion for you.

The %DESCR would be nice to have. It explicitly states the intention.

!DEC$ ATTRIBUTES DESCRIPTOR :: array
real :: array(:)

would be the counter part to the intrinsic.

Jim Dempsey

0 Kudos
Reply