[Bug libstdc++/126604] [16/17 Regression] std::inclusive_scan moves from the first element of the input range

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2026-08-03
     Ever confirmed|0                           |1
   Target Milestone|---                         |16.3
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |ASSIGNED
            Summary|std::inclusive_scan moves   |[16/17 Regression]
                   |from the first element of   |std::inclusive_scan moves
                   |the input range             |from the first element of
                   |                            |the input range
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu=
.org

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Christopher Obbard from comment #0)
> GCC 15.3.0 and clang/libc++ 21.1.8 pass while GCC 16.1.0 fails.

Libc++ fails with move-only types, that's why.

> I believe this is non-conforming and is a regression in GCC 16.

As explained in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0571r2.html it's =
not
really possible to conform to these numeric algorithms, they're very badly
specified.

My interpretation was that it has to be possible to use move-only types,
because the preconditions of std::inclusive_scan say so. But p0571r2 adds a
requirement that an accumulator can be initialized from 'init' or '*first',
which in most cases adds a copy constructible requirement.

As written, libc++ fails to conform to the standard. GCC 16 conforms to the
standard.

But the standard is broken, and we should not move from *first here.=