(j3.2006) Generic resolution of assumed-size dummy
Daniel C Chen
cdchen
Sun Jun 5 17:26:15 EDT 2016
Case1:
Interface
Subroutine sub(arg)
Integer :: arg(*)
End
End interface
Integer :: iarr(10, 10)
Call sub(iarr)
End
Case 2,
Interface sub
Subroutine sub1(arg)
Integer :: arg(*)
End
End interface
Integer :: iarr(10, 10)
Call sub(iarr)
End
Call sub in Case 1 resolves to specific subroutine sub, but call sub in
Case 2 cannot resolves to specific subroutine sub1 even though it has
exactly the same interface.
I would think there is some kind of inconsistency here.
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran
From: "Lionel, Steve" <steve.lionel at intel.com>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Date: 06/03/2016 14:37
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Sent by: j3-bounces at mailman.j3-fortran.org
I don?t see an inconsistency. The carve-out for assumed-size rank mismatch
applies to the actual procedure reference. That generic selection doesn?t
have the same carve-out isn?t inconsistent ? in fact I?d say it?s required
or else the rules of generic selection get more complicated (and less
useful) than they already are.
Steve
From: j3-bounces at mailman.j3-fortran.org [
mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Daniel C Chen
Sent: Friday, June 3, 2016 2:04 PM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Checki1 is fine since it has different KIND parameter.
I would think that checki2, checki3 and checki4 are supposed to be
ambiguous because they are either assume-size or explicit-shape array based
on the sequence association rule that both calls to the generic name check
can resolve to any of these specifics.
However, the current wording in the standard (as Steve also said) seems
disallow the ambiguity (by saying TKR must be differ), but at the same
time, introduce the inconsistency of how a generic name or specific
procedure is referenced.
So the question is: is this inconsistency desired?
Thanks,
Daniel
XL Fortran Development - IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran
Inactive hide details for Tom Clune ---06/03/2016 13:55:04---Bill, OK -
maybe I was reading too quickly, but I thought your resTom Clune
---06/03/2016 13:55:04---Bill, OK - maybe I was reading too quickly, but I
thought your response was implying that checki3()
From: Tom Clune <Thomas.L.Clune at nasa.gov>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Date: 06/03/2016 13:55
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
Sent by: j3-bounces at mailman.j3-fortran.org
Bill,
OK - maybe I was reading too quickly, but I thought your response was
implying that checki3() and checki1() could be overloaded. And both would
match any assumed size array regardless of rank.
- Tom
On Jun 3, 2016, at 1:34 PM, Bill Long <longb at cray.com> wrote:
On Jun 3, 2016, at 11:56 AM, Tom Clune <Thomas.L.Clune at nasa.gov
> wrote:
We then have the rather odd situation that the mere
act of adding an additional interface can change
which procedure is called in an already working
code.
That should never happen, since it would imply that the CALL
matched two of the specifics (the old one and the newly added
one). The rules for generic disambiguation are designed to make
sure that never happens.
Cheers,
Bill
Not necessarily a bad thing, but it does seem that
it could be rather surprising to the developer that
thought he was ?guaranteed? not to be changing
results as he was only implementing a new interface
and had not added client code to use it ?
On Jun 3, 2016, at 10:55 AM, Lionel, Steve <
steve.lionel at intel.com> wrote:
True, but Daniel's question really is about whether
a rank-1 assumed-size
dummy is distinguishable from a rank-N assumed-size
dummy, since as he says,
we allow a rank mismatch for an assumed-size dummy
(16-007r1 5.5.8.5p1).
Given that there's no wording in 12.4.3.5.5 (again,
16-007r1) carving out an
exemption for assumed-size dummies, I would say
that they are
distinguishable and that generic selection would
require that the specific
that matches the rank be called.
Steve
-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org
[mailto:j3-bounces at mailman.j3-fortran.org] On
Behalf Of Bill Long
Sent: Friday, June 03, 2016 10:41 AM
To: fortran standards email list for J3 <
j3 at mailman.j3-fortran.org>
Subject: Re: (j3.2006) Generic resolution of
assumed-size dummy
assumed-rank is dimension(..). That is different
from assumed-size.
Cheers,
Bill
On Jun 3, 2016, at 9:35 AM, Daniel C Chen <
cdchen at ca.ibm.com> wrote:
Hello,
Consider the following code:
module checktest
interface check
module procedure checki1, checki2
end interface
contains
subroutine checki1(ia1)
integer*1, dimension(*) :: ia1
end subroutine checki1
subroutine checki2(ia1)
integer*2, dimension(*) :: ia1
end subroutine checki2
subroutine checki3(ia1)
integer*2, dimension(4,*) :: ia1
end subroutine checki3
subroutine checki4(ia1)
integer*2, dimension(4,4,4) :: ia1
end subroutine checki4
end module checktest
program main
use checktest
integer*2, dimension(10,5) :: ia1
integer*2, dimension(4,4,4) :: ia2
call check(ia1)
Call check(ia2)
end program main
While we allow assumed-size dummy
argument of a specific procedure
correspond to an array actual argument of any rank,
it seems we don't allow
it for generic procedure.
In the standard, we have:
12.4.3.5.5
"A dummy argument is type, kind, and
rank compatible, or TKR compatible,
with another dummy argument if the first is type
compatible with the second,
the kind type parameters of the first have the same
values as the
corresponding kind type parameters of the second,
and both have the same
rank or either is assumed-rank.
...
Two dummy arguments are distinguishable
if ...
they are both data objects or known to
be functions, and neither is
TKR compatible with the other, ..
"
1. It seems ia1 of checki2, checki3 and
checki4 are distinguishable
according to the standard I quoted at the above
because they have different
ranks, Is this expected?
2. If 1 is expected, should call check
(ia1) resolves to checki3 and call
check(ia2) resolves to checki4? If so, it seems
contradict to the sequence
association rule.
Thanks,
Daniel
XL Fortran Development - IBM Toronto
Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com
http://www.ibm.com/software/awdtools/fortran/xlfortran
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long
longb at cray.com
Fortran Technical Support & voice:
651-605-9024
Bioinformatics Software Development fax:
651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./
St. Paul, MN 55101
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN
55101
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160605/027bae18/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20160605/027bae18/attachment-0001.gif
More information about the J3
mailing list