[Bug libstdc++/108236] New: std::exclusive_scan with execution policy does not work in-place

j.l.k at gmx dot com gcc-bugzilla@gcc.gnu.org
Tue Dec 27 21:33:13 GMT 2022


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

            Bug ID: 108236
           Summary: std::exclusive_scan with execution policy does not
                    work in-place
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: j.l.k at gmx dot com
  Target Milestone: ---

The [exclusive.scan#8] section of the standard explicitly says:
https://eel.is/c++draft/exclusive.scan#8

Remarks: result may be equal to first.

So there should be no problem with using std::exclusive_scan in "in-place" mode
overwriting the storage. However, with the libstdc++ implementation that comes
with GCC 12.2.0, it does not work with the overloads that use an execution
policy, even if it is std::execution::seq. Consider this example:

#include <algorithm>
#include <numeric>
#include <execution>
#include <vector>
#include <cassert>

int main()
{
    const int size = 10;
    std::vector<int> vec(size);

    // without execution policy
    std::fill(vec.begin(), vec.end(), 1);
    std::exclusive_scan(vec.begin(), vec.end(), vec.begin(), 0);
    assert(vec[0] == 0); // the first element should be 0
    assert(vec[size-1] == size-1); // the last element should be the sum

    // sequential execution policy
    std::fill(vec.begin(), vec.end(), 1);
    std::exclusive_scan(std::execution::seq, vec.begin(), vec.end(),
vec.begin(), 0);
    assert(vec[0] == 0); // the first element should be 0
    assert(vec[size-1] == size-1); // the last element should be the sum
}

Note that the code fails on the last of the asserts. The std::exclusive_scan
overload without a policy works and there is also no problem with using
std::inclusive_scan in-place with any policy.

See also https://stackoverflow.com/q/74932677/4180822 where I asked about this
behavior.


More information about the Gcc-bugs mailing list