|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Sun Feb 13, 2022 5:41 pm Post subject: Incorrect type for MOD intrinsic in XREF listing |
|
|
The cross-reference listing for the source file
Code: | 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:
Code: | 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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Mon Feb 14, 2022 11:17 am Post subject: |
|
|
mecej4
Thanks for the feedback, I will take a look at this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Mon Feb 14, 2022 5:59 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1895
|
Posted: Mon Feb 14, 2022 6:49 pm Post subject: |
|
|
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
Code: | 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.
Code: | 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 |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7942 Location: Salford, UK
|
Posted: Mon Feb 14, 2022 7:12 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
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
|