Hi all --

I've just been trying out gfortran with my code library. When compiling my
root-finding module, I get the following error:

<<<
gfortran -I/usr/lib -I/usr/local/include/fortran/gfortran -O2 -std=f2003 -c
b3_root.f90
b3_root.f90:235.45:

module procedure b3rt_find_root_muller_Z
1
Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
make: *** [b3_root.mod] Error 1
<<<

The interfaces in question are as follows:

<<<
function b3rt_find_root_muller_Z (z_1, z_2, z_3, f_func, z_tol_r, z_tol_i, &
& max_iterations, f_1, f_2, f_3,
relative_tol) result (z)

complex(KIND(0.D0)), intent(in) :: z_1
complex(KIND(0.D0)), intent(in) :: z_2
complex(KIND(0.D0)), intent(in) :: z_3
interface
function f_func...

Rich Townsend wrote:

(snip)

(snip)

"Rich Townsend" barVOIDtol.udel.edu> wrote in message
news:fgf7la$e6o$1@scrotar.nss.udel.edu...

I think you're right (and so does Intel), and so you've learned there's a
bug in the compiler.

Regards,

Mike Metcalf

Michael Metcalf wrote:

Thanks for checking, Mike; I think I'll file a bug report.

For any gfortran folk listening (Steve Kargl?), this is version 4.2.2 running on
x86_64 Gentoo Linux.

cheers,

Rich

On Nov 2, 2:11 pm, Rich Townsend barVOIDtol.udel.edu> wrote:

I believe that NAG f95 and gfortran rightly reject this example; I
failed to come up with an example why they are really
indistinguishable and thus I will argue with the standard ;-)

Unless, I overlooked something interfaces are:

z_1, z_2, z_3, f_func, z_tol_r, z_tol_i, [max_iterations,] [f_1,]
[f_2,] [f_3,]
[relative_tol]
complex(8),complex(8),complex(8),complex(8),real(8),real(8),[integer,]
[complex(8),][complex(8),][complex(8),][logical]

"Tobias Burnus" wrote in message
news:1194285308.923816.35560@k79g2000hse.googlegroups.com...

I have spent half an hour trying to prove you wrong, only to come to the
conclusion that you are right. Sorry for misleading folks.

Regards,

On Nov 5, 12:55 pm, Tobias Burnus wrote:

I also agree with your analysis. ifort bug id 81135.

Steve

Tobias Burnus wrote:
| On Nov 2, 2:11 pm, Rich Townsend barVOIDtol.udel.edu> wrote:
|| gfortran -I/usr/lib -I/usr/local/include/fortran/gfortran -O2 -std=f2003 -c
|| module procedure b3rt_find_root_muller_Z
|| 1
|| Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
|| 'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
|
|| Now, based on my understanding of TKR matching, these aren't ambiguous at
|| all. Am I right -- or have I just learned something?
|
| I believe that NAG f95 and gfortran rightly reject this example; I
| failed to come up with an example why they are really
| indistinguishable and thus I will argue with the standard ;-)
|
| "(3) at least one of them shall have both
| (a) A nonoptional non-passed-object dummy argument at an effective
| position
| such that either the other procedure has no dummy argument at that
| effective ...

"Jugoslav Dujic" yahoo.com> wrote in message
news:5palf5Fq7t0aU1@mid.individual.net...

I can't do anything to disprove your supposition. Generic procedures
are not as cool as they could be in Fortran. Fortran does have the
complication that procedure arguments are in the worst case wild
cards. A procedure in a module could have an implicitly typed dummy
that is never used. Is this dummy a variable of the implicit type, a
function of that type, or a subroutine? It's legal, I think, to make
a procedure with an ambiguous dummy like this a specific procedure of
a generic procedure.

Here's a little example of what I'm talking about:

James Van Buskirk wrote:
| I looked at your xeffort stuff and there were a lot of desirable things
| in there but installation with Xeffort_IVF_1221.exe said I didn't have
| IVF 9.0 whereas I had IVF 9.1.

1.2.22 is the last version. The installer is written in InnoSetup, and
its maintenance has been an uphill struggle against Intel and Microsoft
ever-changing registry conventions and abundance of VF/VS versions.

Bug reports are always welcome; the setup should leave a file named
XeffortSetupIVF.log along the installer's exe, for [sort of] debugging
purposes. Checking my CVS history of the installation script, I see
something was changed between 1.2.21 and 1.2.22, but I'm not sure if
it affects the behavior you describe.

Having taken a look at the code, the relevant line is outdated and
somewhat misleading:

nIntegrations := GetIntegrations();

if (nIntegrations=0) then begin
Result := MsgBox('Setup has detected that you do not have IVF 8.1 or 9.0
installed...