-
-
Notifications
You must be signed in to change notification settings - Fork 155
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
Failure to compile with intel compiler on linux #83
Comments
Ah. ICC strikes again. Try forcing |
I can sympathize - icpc has caused me a lot of problems in the past, but the performance jump on this code is too big too ignore :( #ifdef __INTEL_COMPILER
#define TOML_ICC __INTEL_COMPILER
#define TOML_ALWAYS_INLINE inline
#ifdef __ICL
#define TOML_ICC_CL TOML_ICC
#else
#define TOML_ICC_CL 0
#endif
#else
|
Hmmmm, well, I'm out of ideas. I'll try to give this a look at some point over the weekend. |
@blackwer OK so I just started looking into this and it turns out I need to jump through all of Intel's hoops to get their compiler on Linux too. Their website and documentation is a bunch of convoluted nonsense - is there a single download link or package repo you can point me to? |
I'm using a version supplied by my employer, so I haven't had to deal with their nonsense for a few years. I think this should be the thing you're looking for: https://software.intel.com/content/dam/develop/external/us/en/documents/iss-icc-download-install-cmdline-780679.pdf Thanks so much for trying to deal with this. The intel compiler is a such a thorn |
Is this even an option? |
Perhaps this is useful: https://github.com/oneapi-src/oneapi-ci . |
It's maybe not ideal, but you can use godbolt. I've reproduced the (well, an) issue there as well. |
Thanks all. Things I've learned about ICC:
I've pushed some minor fixes in 3db1e4e. Not promising it will fix the linker error you were seeing @blackwer since I haven't got an ICC test setup locally yet, but iterating on compiler explorer was a good start. |
@marzer Thanks! New version does resolve all of the compilation issues up to the linking step, but still gets the same undefined symbol errors. I haven't investigated too much yet, but it appears that icc is expecting some external linkage to
|
@blackwer Yeah I'm really not sure what to make of that. |
@marzer yeah I was poking through the code and noticed that just now too. This is completely bizarre. I can maybe look into getting someone from Intel in on this if we can't make progress -- though, if even possible, that's going to take a while in my experience. Any luck getting the compiler? My understanding is that there is a free one month trial, though I understand if you don't want to deal with all that nonsense (or already have for the windows version, etc). If that's a problem, let me know and I'll see if I can find you some resources. |
@blackwer Nope, I haven't revisited it yet. Had hoped to find time over the weekend but things got away from me. Might be able to squeeze it in some night this week, but who knows, if not it'll be a weekend effort again. Worth noting that I do have the windows version already and have tested it with toml++ in the past and it seemed to work OK. For some definition of OK, that is; it compiled, linked and ran, only after I disabled a bunch of unicode-related code paths, but it at least built an executable. It was targeting the MSVC linker so the codegen and object format would have likely been quite different... |
Well, I've got a hilarious hack that seems to work, so there's that. #include "include/toml.hpp"
toml::v2::node_type toml::node::type() const noexcept { return type(); }; |
What. The actual fuck. |
A colleague of mine (apataki) suspects that this is arising from how vtables are constructed in various C++ implementations.
He discovered that simply replacing commands like const auto type = v.type(); with auto *pv = &v;
const auto type = pv->type(); resolves the issue (symbol for This is certainly a strange compiler bug. We're looking at generating a more minimal example that doesn't involve a 12k line header file. Glorious though the header file is, it is difficult to isolate what's going on exactly :). |
Yah it's quite a tome. You can find the individual 'component' headers in |
I misspoke about vtables - that was just his initial hunch. It's something a bit weirder it seems. We'll update once that's 100% clarified. Thanks for the tips on how the includes work. I'm not sure the best way to patch this, since it's a weird compiler bug work-around and requires patching many different calls to My autoformatter and your tabs are also not getting along, though I could definitely figure that one out. |
One of us! One of us! One of us! |
Small update. We got the latest intel compiler packaged with 'parallel studio', and it doesn't resolve the issue. This is version 19.1.3.304. To get the 21.1 version used in godbolt, you have to install oneapi, and then the HPC toolkit addon. There are then two c++ variants installed ( This oddly seems to work without any licensing, because... reasons? I don't think they'd be too happy if we installed it on our cluster though... we probably still need to come up with a reasonable workaround. For now I might just inline the 'implement something that should by definition not be implemented' hack until a more elegant fix is figured out, if such thing exists. |
@blackwer I wonder if a good solution for that compiler would be to just be to make that method non-pure-virtual, and provide a a base implementation something like: toml::v2::node_type toml::node::type() const noexcept
{
assert(false); // or maybe some sort of unreachable() intrinsic if icc has one
return {};
}; Mercifully this is something I can test on godbolt now that it has execution output. |
Ok, no, it just blasts past the assert, returns the default-initialized node_type, and causes other weird issues. Fortunately your workaround is ok: #if TOML_ICC && !TOML_ICC_CL
[[nodiscard]] virtual node_type type() const noexcept
{
return type();
}
#else
[[nodiscard]] virtual node_type type() const noexcept = 0;
#endif (https://godbolt.org/z/vGoaTG) Though I do wonder if it's not just moving the problem to the next pure-virtual method in the class... |
@blackwer I've added your hilarious workaround in b11f28a. It might come back to bite me, but we'll see. :D |
Thanks! It does compile on a considerably more complex example now, though it's certainly not happy! Thousands of lines of complaints about missing return statements in non-void functions. I'll suppress the warnings for now and open another issue when I'm actually on the clock and can isolate what its freakin' problem is. |
Oh, yeah, There's a few places where I use |
Setting |
@blackwer OH, yah, that's something else I recall it not handling well - function templates allowing for a 'null path' by virtue of |
It's HPC software that relies on a bunch of libraries that have to be installed with some extremely special care, so I will definitely have to isolate the code a bit unfortunately. I'll see what I can drum up and open an issue with it hopefully today. |
Ah sure. You needn't worry about opening a seperate issue, this one can serve as a repository for any/all ICC issues you encounter (I reopened it with that in mind) |
@blackwer How did you go with this? |
Environment
toml++ version and/or commit hash:
toml.hpp v2.3.0 [9be51e4]
Compiler:
icpc (ICC) 19.1.0.166 20191121
icpc (ICC) 19.0.0.117 20180804
gcc backend: 7.4.0 (also tried 9.3.0)
C++ standard mode (e.g. 17, 20, 'latest'):
17
Target arch (e.g. x64):
x64 (linux)
Library configuration overrides:
None
Relevant compilation flags:
-std=c++17
Describe the bug
Compiling a simple test program with icpc fails, complaining about issues with TOML_ALWAYS_INLINE.
The same example works fine when compiling with gcc (the same version used as the backend for icpc).
Other versions of gcc on the backend similarly fail.
Steps to reproduce (or a small repro code sample)
Additional information
Forcing
#define TOML_ALWAYS_INLINE __forceinline
will compile with no errors, but fail to link.The text was updated successfully, but these errors were encountered: