I traced back a problem in an application release build to std::find returning the wrong result on the first call to it with an object not present in the collection but then the correct result on a second call. The attached demo code gives me this output from a release build:
1 THIS SHOULD BE 0
A debug build or changing /O3 to /O2 or /Qstd=c++17 to c++14 and some other optimization option changes gives the correct results. Pulling the function body into main also gives correct results.
The problem is seen with Intel C++ 19.1.3 and 2020.1.
Environment and build details are in the demo file.
This seems like a serious optimizer bug.
Thank you for posting in Intel C++ Compiler forum and providing us with the information about the issue, reproducer code and steps to reproduce the issue. We’re trying to reproduce it from our end. We'll get back to you. Thank you for your patience.
We executed the reproducer code and we were not able to reproduce the issue. We tried with c++17, c++20 and c++14. We were getting the correct output. The ouput remains correct even if the options /O3 and /O2 are used. The details of our compiler are
>icl --version Intel(R) C++ Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.1 Build 20201112_000000 Copyright (C) 1985-2020 Intel Corporation. All rights reserved.
We’d also set the compiler version to 19.1.3. We were not able to reproduce the issue.
As you tried in both Intel C++ 19.1.3 and 2020.1, we suggest you to install the latest version of intel C++ Compiler( i.e. 2021) and try running the code again. Please reach out to us if you’re still facing the issue after upgrading.
Thanks for the update. I think we have a real bug here so let's get the details right so the Intel team can reproduce this.
I just reproduced this on a different machine. Did you use the exact combination of flags shown in the demo file? I found that almost any change to those flags eliminates the bug.
icl /nologo /Qstd=c++17 /Qcxx-features /Qvc14.2 /QxHOST /Qansi-alias /DNDEBUG /O3 find_bug.cpp
If you used this then maybe it is hardware (/QxHOST) specific. The 2 systems I reproduced this on are Haswell CPU systems:
- Intel Core i7-4702HQ 2.20GHz running Windows 10 1909
- Intel Core i7-4790K 4.00GHz running Windows 10 20H2
The problem is present with /QxHOST replaced by /QxHASWELL and /QxSSE4.2 and /QxAVX and /QxCORE-AVX2 on these Haswell CPUs.
I reproduce the issue running Intel C++ 19.1.3 and the OneAPI 2021.1 Build 20201112_000000. There is no later Intel C++ to upgrade to (the 2021.2 update does not appear to include any compiler fixes).
I can confirm that adding /Qhlo0 eliminates the error for the demo case with icl Version 2021.2.0 Build 20210228_000000.
Since this is an undocumented option can you provide information about what it does and whether it is likely to be better wrt performance than dropping back to /O2 or an earlier CPU /Qx?
Unfortunately, the bug is still present in 2021.3.0 Build 20210609_000000 using the command line specified in the sample code. The same work-arounds still work including /Qhlo0 suggested by Viet_H above.
Not sure why the developers would tell you it is fixed when it clearly isn't.
Thanks for accepting our solution. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.