[Bug libstdc++/92356] New: Missed optimization of std::find looking for item in array of items [0..n]

[gsfreema at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92356

            Bug ID: 92356
           Summary: Missed optimization of std::find looking for item in
                    array of items [0..n]
           Product: gcc
           Version: 9.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gsfreema at gmail dot com
  Target Milestone: ---

Performing a std::find on an array with elements [0, 1, 2,..., n] does not
produce similar optimizations as implementing the find using a raw for loop. 
This is true when using clang 9.0 or gcc 9.2 with flags `-O2 -std=c++17`. 
Using libc++ with clang produces the same result with std::find as the raw loop
version.

Here is a link to compiler explore demonstrating the difference in generated
assembly.
https://godbolt.org/z/pM1FQQ

One item I just discovered that I did not expect is that a range-for loop in
gcc also has inefficiencies.  That might be a separate issue, and I can file
one if needed.

I understand this looks like a contrived example, but I feel like this scenario
does come up sometimes with enums.  People will have a large enum list where
they want to check if a value is in a small subset of the enum and that subset
just happens to be the first few items in the enum.