Intel's compiler 2019 (Version 19.0.4.243 Build 20190416) seems to be allergic to setting the value of skip (forder.c:905) by calculation for its side-effect use in forder.c:922. It's probably optimized out because the second loop contains the same body without the skip condition.
Clearly a compiler bug and I reported this issue to the Intel guys.
However, to be more explicit I propose to calculate the value of skip afterwards and separate from the key counting.
Thanks for the report and fix! Will merge. Do you have a link the issue you reported to Intel? This workaround will only apply to the next version of data.table so it will be useful to monitor its status so we know if Intel confirm it and which version is it fixed, so we can advise data.table users who might not be able to upgrade data.table.
Does test.data.table() fail under that Intel compiler? I hope it does fail; i.e., is test coverage ok so users know if they have this problem, or do we need to add a new test?
Yes, it does fail. That's how I noticed in the first place.
Re the report, I opened a support ticket which is not a public process. They used to have a public support forum which has been discontinued unfortunately. I'll see what I can do to make it a public issue.
Intel's compiler 2019 (Version 19.0.4.243 Build 20190416) seems to be allergic to setting the value of skip (forder.c:905) by calculation for its side-effect use in forder.c:922. It's probably optimized out because the second loop contains the same body without the
skip
condition.Clearly a compiler bug and I reported this issue to the Intel guys.
However, to be more explicit I propose to calculate the value of skip afterwards and separate from the key counting.
#
Minimal reproducible example
Any dataset with group size >256 should do.
#
Output of sessionInfo()
> sessionInfo()
R version 3.6.0 (2019-04-26)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: openSUSE Leap 42.3
The text was updated successfully, but these errors were encountered: