-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
Thanks for reporting. I don't get this error with later versions of
So it could be a bug in I may be wrong but my understanding is that a generic interface should be able to distinguish between an unlimited polymorphic argument |
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 Can you try again with the latest version (d7029b5)? |
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.
|
hmmm, now does not build with the same version of gfortran. That was a surprise.
|
Ah yes, try replacing it with call tbl%get_raw(k, data, stat) |
Interesting, I sure this should definitely be unambiguous according to the standard.
Yes, my earlier response was in reference to the latest version of |
urbanjs@venus:~/github/fpm-search$ fpm run --compiler ifort 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 |
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!
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
The text was updated successfully, but these errors were encountered: