search

LKedward / fhash

fpm package implementing a hash table with support for generic keys and values.
https://lkedward.github.io/fhash/
MIT License
38 stars 8 forks source link

clash with ifort 2021.3.20210609 #15

Closed urbanjost closed 2 years ago

urbanjost commented 2 years ago

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

build/dependencies/fhash/src/fhash_tbl.f90(501): error #5286: Ambiguous generic interface GET: previously declared specific procedure FHASH_TBL_GET_INT32 is not distinguishable from this declaration. [FHASH_TBL_GET_RAW]
subroutine fhash_tbl_get_raw(tbl,key,value,stat)
-----------^
build/dependencies/fhash/src/fhash_tbl.f90(597): catastrophic error: Too many errors, exiting
compilation aborted for build/dependencies/fhash/src/fhash_tbl.f90 (code 1)
STOP 1
<ERROR> Compilation failed for object " build_dependencies_fhash_src_fhash_tbl.f90.o "
<ERROR>stopping due to failed compilation
LKedward commented 2 years ago

Thanks for reporting. I don't get this error with later versions of ifort. I've tested:

So 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?

urbanjost commented 2 years ago

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.

LKedward commented 2 years ago

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)?

urbanjost commented 2 years ago

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]
urbanjost commented 2 years ago

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
LKedward commented 2 years ago

Ah yes, try replacing it with get_raw:

call tbl%get_raw(k, data, stat)
LKedward commented 2 years ago

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.

urbanjost commented 2 years ago

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

Execution failed for object " fpm-search " *cmd_run*:stopping due to failed executions So with the change to raw; builds with my versions of gfortran and ifort, and runs with gfortran version; getting another error now ```I but might be unrelated. Have to go, will look later. 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. ```text
urbanjost commented 2 years ago

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!

LKedward commented 2 years ago

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.