Closed urbanjost closed 2 years ago
Thanks for reporting. I don't get this error with later versions of ifort
. I've tested:
2021.4.0 20210910
in the CI workflow2021.5.0 Build 20211109_000000
on my Windows machineSo it could be a bug in ifort 2021.3.0
that got fixed or a subsequent regression that slipped past in later versions.
I may be wrong but my understanding is that a generic interface should be able to distinguish between an unlimited polymorphic argument class(*)
and an intrinsic type such as integer
. What do you think?
If it works in newer iforts and already works in gfortran that is a good empirical case for it being allowed; I was looking through the standard and so far not positive. There are two routines that can take the same arguments when the type is integer that are in the same generic definition; but one is specifically for integers and at least some compilers do not even warn about it; and so on. Since I was not sure yet i wanted to mention it; but it is looking like a compiler bug.
It came up in the middle of trying to make the most recent version of fpm-search I could; as Carlos Une's github site disappeared, and the cairo interface and fpm-search appear gone, and have not heard back what is going on. fpm-search uses fhash.
I can close this under the assumption it is a compiler bug; if you have no objection.
Apologies, it seems I have a bad memory! I think this bug may have already been fixed in #10.
I noticed in urbanjost/fpm-search/fpm.toml that fhash
is pinned to an older version (125ac80a3e736c08ba46184150923baca09a6bfd) prior to #10.
Can you try again with the latest version (d7029b55e01438fcd7c164c1366aaab87792ee25)?
well, the message got better. It builds with newer ifort though, correct? The question gets particularly interesting if I make a polymorphic procedure that I want to handle all integer types and one that handles all real types and then want to make a generic interface to those; but then I am combining two polymorphics and I think that is not allowed. Interesting that newer ifort has no problem. I will leave the newer fhash version in though.
app/main.f90: error #5286: Ambiguous generic interface GET: previously declared specific procedure FHASH_TBL::FHASH_TBL_GET_INT32 is not distinguishable from this declaration. [FHASH_TBL::FHASH_TBL_GET_INT64]
hmmm, now does not build with the same version of gfortran. That was a surprise.
ce -fcoarray=single -J build/gfortran_2A42023B310FA28D -Ibuild/gfortran_2A42023B310FA28D -o build/gfortran_2A42023B310FA28D/fpm-search/app_main.f90.o
app/main.f90:319:12:
319 | call tbl%get(k, data, stat)
| 1
Error: Found no matching specific binding for the call to the GENERIC ‘get’ at (1)
<ERROR> Compilation failed for object " app_main.f90.o "
<ERROR>stopping due to failed compilation
Ah yes, try replacing it with get_raw
:
call tbl%get_raw(k, data, stat)
app/main.f90: error #5286: Ambiguous generic interface GET: previously declared specific procedure FHASH_TBL::FHASH_TBL_GET_INT32 is not distinguishable from this declaration. [FHASH_TBL::FHASH_TBL_GET_INT64]
Interesting, I sure this should definitely be unambiguous according to the standard.
It builds with newer ifort though, correct?
Yes, my earlier response was in reference to the latest version of fhash
- so yes it is currently working with the new ifort
.
urbanjs@venus:~/github/fpm-search$ fpm run --compiler ifort
forrtl: severe (194): Run-Time Check Failure. The variable 'table_search$R1$_157' is being used in 'app/main.f90(353,24)' without being defined
Image PC Routine Line Source
fpm-search 00000000004105FB main_IP_table_sea 353 main.f90
fpm-search 00000000004060D9 MAIN 108 main.f90
fpm-search 0000000000403822 Unknown Unknown Unknown
libc-2.31.so 00007F409072E0B3 libc_start_main Unknown Unknown
fpm-search 000000000040372E Unknown Unknown Unknown
deleted the build/ directory and did a clean rebuild, and with the change in and using the latest version of fhash everything is working with ifort and gfortran versions I have, and fpm-search up to date with @brocolis version from Dec 25th, so pretty recent. I do not know if anyone has a newer version (if there were changes after that) but until (if) I hear from C. Une I have a relatively recent version that works with those two compilers. Closing. Thanks!
Glad to hear that you got it working!
On unrelated issue I home Une is OK; got no response and github site is gone. If he does not want to author it anymore perhaps it could go straight into the fpm repository; but I will bring that up on fpm site if I cannot figure out what is going on.
Yes I'm unsure what is going on too, it is unexpected. I agree that it may be worth discussing whether we want to bring your latest version of fpm-search under fortran-lang.
no problem with the gfortran versions I have, but withifort (IFORT) 2021.3.0 20210609 Copyright (C) 1985-2021 Intel Corporation. All rights reserved.
I get the following clash