Incorrect type for MOD intrinsic in XREF listing

The cross-reference listing for the source file

subroutine sub(job)
   implicit none
   integer, intent(in) :: job
   logical :: cb, cr, cqy, cqty, cxb
!
   cqy = job/10000 /= 0
   cqty = MOD(job,10000) /= 0
   cb = MOD(job,1000)/100 /= 0
   cr = MOD(job,100)/10 /= 0
   cxb = MOD(job,10) /= 0
   print *,cqy,cqty,cb,cr,cxb
   return
end subroutine

incorrectly lists the type of the intrinsic function MOD as 'double precision', even though both the arguments to MOD are of type integer:

DOUBLE PRECISION, PURE, ELEMENTAL :: FUNCTION MOD
     7,       8,       9,      10

I think that the error as to the type is only in the listing and not in the compiled code.

mecej4

Thanks for the feedback, I will take a look at this.

mecej4

I haved 'fixed' this particular case by removing 'DOUBLE PRECISION' for MOD (also ABS and MODULO).

The type is determined by the type of the first argument and this information is not currently provided at the point where the xref output is generated.

A similar discrepancy will occur for intrinsics that can return REAL or DOUBLE PRECISION. Similarly for REAL or COMPLEX etc. and probably others.

I don't think it is worth working through all of the intrinsics but I could remove this description of the type for all standard intrinsics if this is preferable.

Considering that intrinsics such as MOD can have more than one type, as the following modification of the test code above displays, it may be best to list it in the cross-reference as

INTRINSIC, PURE, ELEMENTAL :: FUNCTION MOD 

The following modified code causes the return value of MOD to be type REAL in Line 11, and of type INTEGER in the other lines where MOD occurs.

subroutine sub(job)
   implicit none
   integer, intent(in) :: job
   logical :: cb, cr, cqy, cqty, cxb
   real :: x = 3.5, y = 8.1
!
   cqy  = job/10000 /= 0
   cqty = MOD(job,10000) /= 0
   cb   = MOD(job,1000)/100 /= 0
   cr   = MOD(job,100)/10 /= 0
   cxb  = MOD(y,x) > 0.5
   print *,cqy,cqty,cb,cr,cxb
   return
end subroutine

OK. For now I will apply this to all standard intrinsics then there will be no discrepancies of this kind. Users will be able to deduce the return type from the context.