https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126604
Bug ID: 126604
Summary: std::inclusive_scan moves from the first element of
the input range
Product: gcc
Version: 16.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: obbardc at gmail dot com
Target Milestone: ---
(I am no compiler expert so please take what I say with a pinch of salt)
Since r16 (commit df1d436, "libstdc++: Fix <numeric> parallel algos for
move-only
values [PR117905]"), the overload
inclusive_scan(first, last, result, binary_op)
initialises its accumulator by moving out of the input range:
auto __init = _GLIBCXX_ITER_MOVE(__first); // was: auto __init = *__first;
For a value type with a destructive move this silently destroys the caller's
input even when result does not alias first.
Test case (fails with -std=c++17 and -std=c++20; both macro expansions move):
#include <numeric>
#include <string>
#include <vector>
#include <cassert>
int main()
{
std::vector<std::string> in{"a", "b"}, out(2);
std::inclusive_scan(in.begin(), in.end(), out.begin(),
std::plus<std::string>{});
assert(out[0] == "a"); // ok
assert(out[1] == "ab"); // ok
assert(in[0] == "a"); // FAILS: in[0] is an empty moved-from string
}
GCC 15.3.0 and clang/libc++ 21.1.8 pass while GCC 16.1.0 fails. Passing
in.cbegin()/in.cend() also passes, so the behaviour silently depends on the
constness of the iterators handed in.
I believe this is non-conforming and is a regression in GCC 16.
This was found via a build failure in Debian's taskflow package
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1133642) whose test suite
compares the input against a golden vector after an out-of-place scan
(unittests/test_scan.cpp); 6 tests fail. Gentoo sees the same failures
(https://bugs.gentoo.org/961562).
Cheers!
Christopher Obbard
