* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
@ 2014-12-01 17:24 ` kargl at gcc dot gnu.org
2014-12-01 20:11 ` wong.david-c at epa dot gov
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: kargl at gcc dot gnu.org @ 2014-12-01 17:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to david from comment #0)
> Hi,
>
> I have created a complex number module:
>
> module complex_number_module
> implicit none
>
> integer, parameter :: loc_real_precision = 8
>
> type complex_number
> real(kind=loc_real_precision) :: real_part, imag_part
> end type complex_number
>
> interface c_sub
> module procedure c_sub_cc, & ! z1 - z2
> c_sub_cr, & ! z1 - num, where num is a
> real number
> c_sub_rc ! num - z1, where num is a
> real number
> end interface
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_cc (z1, z2)
>
> type (complex_number), intent(in) :: z1, z2
>
> c_sub_cc%real_part = z1%real_part - z2%real_part
> c_sub_cc%imag_part = z1%imag_part - z2%imag_part
>
> end function c_sub_ccj
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_cr (z1, num)
>
> type (complex_number), intent(in) :: z1
> real(kind=loc_real_precision), intent(in) :: num
>
> c_sub_cr%real_part = z1%real_part - num
> c_sub_cr%imag_part = z1%imag_part
>
> end function c_sub_cr
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_rc (num, z1)
>
> type (complex_number), intent(in) :: z1
> real(kind=loc_real_precision), intent(in) :: num
>
> c_sub_rc%real_part = num - z1%real_part
> c_sub_rc%imag_part = - z1%imag_part
>
> end function c_sub_rc
>
> end module complex_number_module
>
> When I compile with gfortran (version 4.6.4), I got the following error:
>
> module_twoway_rrtmg_aero_optical_util.F:14.85:
>
> c_sub_rc ! num - z1, where num is a real number
> 1
>
> Error: Ambiguous interfaces 'c_sub_rc' and 'c_sub_cr' in generic interface
> 'c_sub' at (1)
>
> I don't see any ambiguity and I don't encounter any problem with other
> compilers such pgi and ifort. Please advise.
>
> Cheers,
> David
Please attach the exact code you tried to compile. The above is nonsense.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
2014-12-01 17:24 ` [Bug fortran/64138] " kargl at gcc dot gnu.org
@ 2014-12-01 20:11 ` wong.david-c at epa dot gov
2014-12-01 20:13 ` wong.david-c at epa dot gov
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: wong.david-c at epa dot gov @ 2014-12-01 20:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #2 from david <wong.david-c at epa dot gov> ---
Created attachment 34158
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34158&action=edit
a small code
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
2014-12-01 17:24 ` [Bug fortran/64138] " kargl at gcc dot gnu.org
2014-12-01 20:11 ` wong.david-c at epa dot gov
@ 2014-12-01 20:13 ` wong.david-c at epa dot gov
2014-12-01 20:17 ` kargl at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: wong.david-c at epa dot gov @ 2014-12-01 20:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #3 from david <wong.david-c at epa dot gov> ---
(In reply to david from comment #0)
> Hi,
>
> I have created a complex number module:
>
> module complex_number_module
> implicit none
>
> integer, parameter :: loc_real_precision = 8
>
> type complex_number
> real(kind=loc_real_precision) :: real_part, imag_part
> end type complex_number
>
> interface c_sub
> module procedure c_sub_cc, & ! z1 - z2
> c_sub_cr, & ! z1 - num, where num is a
> real number
> c_sub_rc ! num - z1, where num is a
> real number
> end interface
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_cc (z1, z2)
>
> type (complex_number), intent(in) :: z1, z2
>
> c_sub_cc%real_part = z1%real_part - z2%real_part
> c_sub_cc%imag_part = z1%imag_part - z2%imag_part
>
> end function c_sub_ccj
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_cr (z1, num)
>
> type (complex_number), intent(in) :: z1
> real(kind=loc_real_precision), intent(in) :: num
>
> c_sub_cr%real_part = z1%real_part - num
> c_sub_cr%imag_part = z1%imag_part
>
> end function c_sub_cr
>
> ! --------------------------------------------------------------------------
> type (complex_number) function c_sub_rc (num, z1)
>
> type (complex_number), intent(in) :: z1
> real(kind=loc_real_precision), intent(in) :: num
>
> c_sub_rc%real_part = num - z1%real_part
> c_sub_rc%imag_part = - z1%imag_part
>
> end function c_sub_rc
>
> end module complex_number_module
>
> When I compile with gfortran (version 4.6.4), I got the following error:
>
> module_twoway_rrtmg_aero_optical_util.F:14.85:
>
> c_sub_rc ! num - z1, where num is a real number
> 1
>
> Error: Ambiguous interfaces 'c_sub_rc' and 'c_sub_cr' in generic interface
> 'c_sub' at (1)
>
> I don't see any ambiguity and I don't encounter any problem with other
> compilers such pgi and ifort. Please advise.
>
> Cheers,
> David
Hi,
I have attached a smaller version of the code and the way I compiled the
code is:
gfortran -c -ffree-form d.F
Thanks,
David
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (2 preceding siblings ...)
2014-12-01 20:13 ` wong.david-c at epa dot gov
@ 2014-12-01 20:17 ` kargl at gcc dot gnu.org
2014-12-02 15:37 ` wong.david-c at epa dot gov
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: kargl at gcc dot gnu.org @ 2014-12-01 20:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2014-12-01
Ever confirmed|0 |1
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> (In reply to david from comment #0)
> > Hi,
> >
> > I have created a complex number module:
> >
> > module complex_number_module
> > implicit none
> >
> > integer, parameter :: loc_real_precision = 8
> >
> > type complex_number
> > real(kind=loc_real_precision) :: real_part, imag_part
> > end type complex_number
> >
> > interface c_sub
> > module procedure c_sub_cc, & ! z1 - z2
> > c_sub_cr, & ! z1 - num, where num is a
> > real number
> > c_sub_rc ! num - z1, where num is a
> > real number
> > end interface
> >
> > ! --------------------------------------------------------------------------
> > type (complex_number) function c_sub_cc (z1, z2)
> >
> > type (complex_number), intent(in) :: z1, z2
> >
> > c_sub_cc%real_part = z1%real_part - z2%real_part
> > c_sub_cc%imag_part = z1%imag_part - z2%imag_part
> >
> > end function c_sub_ccj
> >
> > ! --------------------------------------------------------------------------
> > type (complex_number) function c_sub_cr (z1, num)
> >
> > type (complex_number), intent(in) :: z1
> > real(kind=loc_real_precision), intent(in) :: num
> >
> > c_sub_cr%real_part = z1%real_part - num
> > c_sub_cr%imag_part = z1%imag_part
> >
> > end function c_sub_cr
> >
> > ! --------------------------------------------------------------------------
> > type (complex_number) function c_sub_rc (num, z1)
> >
> > type (complex_number), intent(in) :: z1
> > real(kind=loc_real_precision), intent(in) :: num
> >
> > c_sub_rc%real_part = num - z1%real_part
> > c_sub_rc%imag_part = - z1%imag_part
> >
> > end function c_sub_rc
> >
> > end module complex_number_module
> >
> > When I compile with gfortran (version 4.6.4), I got the following error:
> >
> > module_twoway_rrtmg_aero_optical_util.F:14.85:
> >
> > c_sub_rc ! num - z1, where num is a real number
> > 1
> >
> > Error: Ambiguous interfaces 'c_sub_rc' and 'c_sub_cr' in generic interface
> > 'c_sub' at (1)
> >
> > I don't see any ambiguity and I don't encounter any problem with other
> > compilers such pgi and ifort. Please advise.
> >
> > Cheers,
> > David
>
> Please attach the exact code you tried to compile. The above is nonsense.
I fixed the above code. I believe gfortran is correct to complain
about an ambiguous interface. In the last two line below, which
of c_sub_rc and c_sub_cr should be called.
program foo
use complex_number_module
type(complex_number) a, b
real(dp) x
a%re = 1
a%im = 2
x = 1
b = c_sub(a, x); print '(A,2F5.1)', 'a-x = ', b%re, b%im
b = c_sub(x, a); print '(A,2F5.1)', 'x-a = ', b%re, b%im
b = c_sub(z1=a, num=x); print '(A,2F5.1)', 'a-x = ', b%re, b%im
b = c_sub(num=x,a); print '(A,2F5.1)', 'a-x = ', b%re, b%im
end program foo
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (3 preceding siblings ...)
2014-12-01 20:17 ` kargl at gcc dot gnu.org
@ 2014-12-02 15:37 ` wong.david-c at epa dot gov
2014-12-02 16:05 ` sgk at troutmask dot apl.washington.edu
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: wong.david-c at epa dot gov @ 2014-12-02 15:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #5 from david <wong.david-c at epa dot gov> ---
Hi,
What is your fix?
In the original code, c_sub_cr and c_sub_rc are distinct because the
sequence of argument type are different. Other compilers have no problem to
distinguish them. Please advise.
Cheers,
David
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (4 preceding siblings ...)
2014-12-02 15:37 ` wong.david-c at epa dot gov
@ 2014-12-02 16:05 ` sgk at troutmask dot apl.washington.edu
2014-12-02 17:13 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2014-12-02 16:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Dec 02, 2014 at 03:37:19PM +0000, wong.david-c at epa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
>
> What is your fix?
>
I meant I fixed the code you posted. It was missing a CONTAINS
statement before c_sub_cc, and there is an extra 'j' on the
end of one of the 'end function c_sub_??' lines.
> In the original code, c_sub_cr and c_sub_rc are distinct because the
> sequence of argument type are different. Other compilers have no problem to
> distinguish them. Please advise.
You can get the code to compile if you change the dummy
argument names in c_sub_cr and c_sub_rc to unique entities.
For example, (and yes I changed the function and variable
names while debugging)
type(complex_number) function f2(z1, num)
type (complex_number), intent(in) :: z1
real(kind=dp), intent(in) :: num
f2%re = z1%re - num
f2%im = z1%im
end function f2
type(complex_number) function f3(num, z2)
type (complex_number), intent(in) :: z2
real(kind=dp), intent(in) :: num
f3%re = num - z2%re
f3%im = - z2%im
end function f3
The only problem with this workaround is that you cannot
use keyword argument association. For example,
type(complex_number) :: z=complex_number(1.,2.)
real x = 3.
z = c_sub(num=x, z)
The above is ambiguous because the reduced argument list for
f2 and f3 are identical, so the generic c_sub can be mapped
to either. Fortunately, gfortran tries to help in this
situation
% gfortran -o z -fmax-errors=1 a.f90
a.f90:53.18:
b = c_sub(num=x, a); print '(A,2F5.1)', '(x-a)? = ', b%re, b%im
1
Error: Missing keyword name in actual argument list at (1)
Fatal Error: Error count reached limit of 1.
Note, however, AFAIK, a keyword is not necessary and is not required.
IHMO, issuing this error message could in fact be considered a bug.
In fact, if you change the order of arguments to
b = c_sub(a, num=x); print '(A,2F5.1)', '(x-a)? = ', b%re, b%im
This will compile without error. If the former line producing an
error about a missing keyword shouldn't the latter?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (5 preceding siblings ...)
2014-12-02 16:05 ` sgk at troutmask dot apl.washington.edu
@ 2014-12-02 17:13 ` dominiq at lps dot ens.fr
2014-12-02 17:29 ` sgk at troutmask dot apl.washington.edu
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-12-02 17:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I was sure to have seen discussions about such issues: pr33997 and
https://groups.google.com/forum/#!msg/comp.lang.fortran/GIcxE7GM1ek/aP7eJpQ-T7QJ
AFAIU the discussions, the relevant point for this PR is
> (b) A nonoptional non-passed-object dummy argument whose name
> is such that either the other procedure has no dummy argument
> with that name or the dummy argument with that name is distinguishable
> with it.
Along this line I have renamed num to num1 and z1 to z2 in c_sub_rc
module complex_number_module
implicit none
integer, parameter :: loc_real_precision = 8
type complex_number
real(kind=loc_real_precision) :: real_part, imag_part
end type complex_number
interface c_sub
module procedure c_sub_cc, & ! z1 - z2
c_sub_cr, & ! z1 - num, where num is a real
number
c_sub_rc ! num - z1, where num is a real
number
end interface
contains
! --------------------------------------------------------------------------
type (complex_number) function c_sub_cc (z1, z2)
type (complex_number), intent(in) :: z1, z2
c_sub_cc%real_part = z1%real_part - z2%real_part
c_sub_cc%imag_part = z1%imag_part - z2%imag_part
end function c_sub_cc
! --------------------------------------------------------------------------
type (complex_number) function c_sub_cr (z1, num)
type (complex_number), intent(in) :: z1
real(kind=loc_real_precision), intent(in) :: num
c_sub_cr%real_part = z1%real_part - num
c_sub_cr%imag_part = z1%imag_part
end function c_sub_cr
! --------------------------------------------------------------------------
type (complex_number) function c_sub_rc (num1, z2)
type (complex_number), intent(in) :: z2
real(kind=loc_real_precision), intent(in) :: num1
c_sub_rc%real_part = num1 - z2%real_part
c_sub_rc%imag_part = - z2%imag_part
end function c_sub_rc
end module complex_number_module
program foo
use complex_number_module
type(complex_number) a, b
real(loc_real_precision) x
a%real_part = 1
a%imag_part = 2
x = 3
b = c_sub(a, x); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part
b = c_sub(x, a); print '(A,2F5.1)', 'x-a = ', b%real_part, b%imag_part
b = c_sub(z1=a, num=x); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part
b = c_sub(num=x,z1=a); print '(A,2F5.1)', 'a-x = ', b%real_part, b%imag_part
b = c_sub(num1=x,z2=a); print '(A,2F5.1)', 'x-a = ', b%real_part, b%imag_part
end program foo
This made the code to compile and if I am not mistaken to produce the correct
result
a-x = -2.0 2.0
x-a = 2.0 -2.0
a-x = -2.0 2.0
a-x = -2.0 2.0
x-a = 2.0 -2.0
Out of curiosity why do want to handle complex numbers through types while they
are perfectly handled in Fortran by kinds?
To conclude I think this PR should be closed as INVALID.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (6 preceding siblings ...)
2014-12-02 17:13 ` dominiq at lps dot ens.fr
@ 2014-12-02 17:29 ` sgk at troutmask dot apl.washington.edu
2014-12-02 17:36 ` dominiq at lps dot ens.fr
2014-12-06 15:03 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2014-12-02 17:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Dec 02, 2014 at 05:13:09PM +0000, dominiq at lps dot ens.fr wrote:
>
> To conclude I think this PR should be closed as INVALID.
>
That's the conclusion that I'm leaning towards. Reading
section 16 of the standard always makes my head hurt, so
I'm being caution while looking for some subtle point
that I may have missed.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (7 preceding siblings ...)
2014-12-02 17:29 ` sgk at troutmask dot apl.washington.edu
@ 2014-12-02 17:36 ` dominiq at lps dot ens.fr
2014-12-06 15:03 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-12-02 17:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> That's the conclusion that I'm leaning towards. Reading
> section 16 of the standard always makes my head hurt, so
> I'm being caution while looking for some subtle point
> that I may have missed.
And the threads I have pointed to are also convoluted. Now I find quite clear
that using the same names for the dummy arguments in c_sub_cr and c_sub_rc does
not permit to distinguish between c_sub_cr(num=x,z1=a) and
c_sub_rc(num=x,z1=a), while using different names does.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug fortran/64138] gfortran interface issue
2014-12-01 15:03 [Bug fortran/64138] New: gfortran interface issue wong.david-c at epa dot gov
` (8 preceding siblings ...)
2014-12-02 17:36 ` dominiq at lps dot ens.fr
@ 2014-12-06 15:03 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-12-06 15:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The argument in comment 9 not being challenged, closing as INVALID.
^ permalink raw reply [flat|nested] 11+ messages in thread