intel builds fail with internal compiler errors #1302
Comments
cz4rs
changed the title
|
I'll try to reproduce and reduce. I'll also check Intel 21, which we're having a hard time getting set up for CI |
|
Confirmed that the builds work fine without the last PR in checkpoint - all checks passed at #1303 🤔 --- a/src/checkpoint/container/map_serialize.h
+++ b/src/checkpoint/container/map_serialize.h
@@ -96,7 +96,9 @@ inline void serializeUnorderedAssociativeContainer(
auto bucket_count = cont.bucket_count();
s | bucket_count;
- cont.rehash(bucket_count);
+ if (s.isUnpacking() and bucket_count > cont.bucket_count()) {
+ cont.rehash(bucket_count);
+ }
}
serializeMapLikeContainer(s, cont);It doesn't seem like we are hitting any resource limit here, but the change itself also looks pretty innocent. |
|
A somewhat reduced example triggering the bug: #include <checkpoint/checkpoint.h>
struct PhaseManager {
std::unordered_map<int, std::map<int, int>> map_;
template <typename SerializerT>
void serialize(SerializerT& s) {
s | map_;
}
};
void printMemoryFootprint() {
PhaseManager* comp;
checkpoint::getMemoryFootprint(*comp, 0);
}Compilation line: |
|
Oh, wow, well done. I'll toss that at creduce and see what comes out |
|
Also: removing |
|
Compilation succeeds even with |
|
OK, I'm all set up for a creduce run. You can put manual efforts on hold. |
|
This is a surprising bug. |
|
So, I don't know if this is the crash, but ... namespace std {
int& max(int, int);
}
void foo() {
int a = std::max(0, 1);
}The |
|
I'll pass the report along |
|
It also crashes for 21.1.9 |
|
Per request, I tested Intel's next-generation C++ compiler |
|
It might be worth noting that there is template <typename T>
std::size_t getMemoryFootprint(T& target, std::size_t size_offset) {
return size_offset + std::max(
dispatch::Standard::footprint<T, Footprinter>(target),
sizeof(target)
);
}so it's even more surprising that the additional I assume that we should keep this issue open, I will update the top description once |
|
I think the compiler crash has something to do with a flaw in how it's implementing return value optimization (RVO), but I can't pin down what distinguishes a case that crashes from one that doesn't. |
|
@PhilMiller Do you have any update on this issue from the Intel compiler devs? |
|
I just checked the repro in #1302 (comment) and found it still crashes 2021.5.0 |
|
Also, that's the compiler version incorporated in Intel oneAPI 2022: |
|
@cz4rs @PhilMiller Is this still a concern? We're no longer seeing the internal compiler error since I lowered the build parallelism, but I'm not sure if that's just masking the problem. |
I think we can close / archive this issue, as there's nothing that we can do about it (until Intel fixes this). |
Describe the bug
Intel builds have begun to fail with internal errors recently.
icc-18
icc-19
To Reproduce
Currently all up-to-date PRs are affected.Running build in local environment (without unity) results in the same error in different stage of the build (while compiling
runtime.cc).Builds are passing again after merging DARMA-tasking/magistrate#183 - reverting that PR allows to reproduce the crashes.
For reduced examples see #1302 (comment) and #1302 (comment) .
Additional context
It seems that recent changes in
checkpointhave triggered this behavior (DARMA-tasking/magistrate#181).When running builds with
checkpointat DARMA-tasking/magistrate@60d6542 builds run fine in local environment (PR created to verify this in CI).The text was updated successfully, but these errors were encountered: