Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clash with ifort 2021.3.20210609 #15

Closed
urbanjost opened this issue Feb 10, 2022 · 10 comments
Closed

clash with ifort 2021.3.20210609 #15

urbanjost opened this issue Feb 10, 2022 · 10 comments

Comments

@urbanjost
Copy link

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
Copy link
Owner

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

  • 2021.4.0 20210910 in the CI workflow
  • 2021.5.0 Build 20211109_000000 on my Windows machine

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
Copy link
Author

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
Copy link
Owner

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 (125ac80) prior to #10.

Can you try again with the latest version (d7029b5)?

@urbanjost
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

Ah yes, try replacing it with get_raw:

call tbl%get_raw(k, data, stat)

@LKedward
Copy link
Owner

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
Copy link
Author

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

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
Copy link
Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants