https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92356
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-10-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please provide source, not jus a link to another site, as stated at
https://gcc.gnu.org/bugs/
The testcase is:
#include <algorithm>
#include <iterator>
constexpr static int validValues[] = { 0, 1, 2 };
bool isValidValueWithRawLoop(int value) {
for (int i = 0; i < std::size(validValues); ++i) {
if (validValues[i] == value) {
return true;
}
}
return false;
}
bool isValidValueWithRangeForLoop(int value)
{
for (int item : validValues) {
if (item == value) {
return true;
}
}
return false;
}
bool isValidValueWithFind(int value)
{
return std::find(std::begin(validValues), std::end(validValues), value) !=
std::end(validValues);
}
Clang with libc++ compiles to the same code for all three functions:
cmp edi, 3
setb al
ret
GCC compiles the first one similarly:
cmp edi, 2
setbe al
ret
but generates much worse code for the range-based for loop and std::find.
Clang with libstdc++ also generates poor code, suggesting it's not just a
compiler issue. Presumably the manual unrolling we do in std::__find_if hurts
the optimizer.
The range-based for case is definitely a separate bug and should be filed
separately against component=c++ or component=tree-optimization.
