Re: taskflow: ftbfs with GCC-16

--=-lEkRE2T8cDt5GdhbcyET
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 02 Aug 2026 17:03:27 +0100 Christopher Obbard <[email protected]> =
wrote:
> Hi Emanuele,

Forwarding this message, as neither Emanuele nor
[email protected] was listed as recipient.

Members of [email protected]: Please read on below.

Best,
Sven=20

>=20
> On Mon, 13 Apr 2026 15:11:35 +0200 Emanuele Rocca <[email protected]> wrote:
> > Package: src:taskflow
> > Version: 3.9.0+ds-1
> > Severity: important
> > Tags: sid forky ftbfs
> > User: [email protected]
> > Usertags: ftbfs-gcc-16
> >=20
> > Hi,
> >=20
> > taskflow fails to build in a test rebuild on at least amd64 and arm64 w=
ith
> > gcc-16/g++-16, but builds properly with gcc-15/g++-15.
>=20
> Thanks for the report; this now appears to cause autoremovals for lots of
> packages and I saw no one has replied so thought I'd take a look.
>=20
> I've tracked this down and it isn't a bug in taskflow; it appears to be a
> regression in libstdc++ 16.
>=20
> Now I am no compiler expert so please take what I say with a pinch of sal=
t.
>=20
> The no-init overload std::inclusive_scan(first, last, result, binary_op)
> initialises its accumulator by moving out of the first element of the
> input range:
>=20
>=C2=A0=C2=A0 auto __init =3D _GLIBCXX_ITER_MOVE(__first);=C2=A0=C2=A0 // w=
as: auto __init =3D *__first;
>=20
> That happens unconditionally, so a plain out-of-place scan silently destr=
oys
> the caller's input. For a value type with a destructive move (e.g. std::s=
tring)
> the first element is left empty.
>=20
> A reduced testcase, which fails with g++ 16 and passes with g++ 15 in bot=
h
> -std=3Dc++17 and -std=3Dc++20:
>=20
>=C2=A0=C2=A0 #include <numeric>
>=C2=A0=C2=A0 #include <string>
>=C2=A0=C2=A0 #include <vector>
>=C2=A0=C2=A0 #include <functional>
>=C2=A0=C2=A0 #include <cassert>
>=20
>=C2=A0=C2=A0 int main()
>=C2=A0=C2=A0 {
>=C2=A0=C2=A0=C2=A0=C2=A0 std::vector<std::string> in{"a", "b"}, out(2);
>=C2=A0=C2=A0=C2=A0=C2=A0 std::inclusive_scan(in.begin(), in.end(), out.beg=
in(),
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 st=
d::plus<std::string>{});
>=C2=A0=C2=A0=C2=A0=C2=A0 assert(out[1] =3D=3D "ab");=C2=A0 // ok
>=C2=A0=C2=A0=C2=A0=C2=A0 assert(in[0] =3D=3D "a");=C2=A0=C2=A0=C2=A0 // fa=
ils: in[0] is an empty moved-from string
>=C2=A0=C2=A0 }
>=20
> Passing in.cbegin()/in.cend() instead leaves the input intact, so the
> behaviour depends on the constness of the iterators handed in which is a
> good sign it wasn't intended.
>=20
> I believe it's non-conforming: [inclusive.scan]/6 specifies the effects
> purely as assignments through result + K, and /9 permits result =3D=3D fi=
rst as
> an aliasing allowance rather than as licence to modify the input when
> result !=3D first.
>=20
> The move came in with gcc commit df1d436 ("libstdc++: Fix <numeric>
> parallel algos for move-only values [PR117905]"), which relaxed the
> requirement on the value type from CopyConstructible to MoveConstructible=
;
> gcc 15 is unaffected. I've reported it upstream as GCC Bug 126604:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D126604
>
> Gentoo hit the same six failures with taskflow 3.10.0
> (https://bugs.gentoo.org/961562) so updating to a newer upstream release =
won't
> help.
>
> This explains the failure set exactly: only the six InclusiveScan.string.=
*
> cases fail, because the overloads taking an init value never touch the
> input and the TransformInclusiveScan tests are int-only (a moved-from int
> keeps its value). The test itself is correct: it computes its golden vect=
or
> with a perfectly ordinary out-of-place std::inclusive_scan and that call =
alone
> is enough to corrupt the input, so no change to the test source can make =
it
> pass legitimately while linked against libstdc++ 16.
>
> So my plan to resolve this bug is to skip those six tests in debian/rules=
, via
> ctest -E 'InclusiveScan\.string\.', with a comment pointing to the GCC bu=
g,
> and to file a separate Debian bug against taskflow to track enabling thos=
e tests
> once libstdc++ 16 is fixed.
>
> I guess I need to open a separate Debian bug on gcc-16 where I can link t=
o
> the upstream GCC bug report.
>
> What do you think?
>
>
> Cheers!
>
> Christopher Obbard

--=20
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585

--=-lEkRE2T8cDt5GdhbcyET
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iQJDBAABCgAtFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAmpw9pkPHHNnZUBkZWJp
YW4ub3JnAAoJEK31Dtr4rdWFbyYQAMRjADpHxfAv6hmTxnS/Cx8Bv8XbLMCTaZe+
K9NhJLs7FbCkhSMl/e2y+EAVrxH6IQGkpq4N9lmkRW4atldvv8qd8pmHAQOahpeE
KlSReLUwxlQqro2ydZSZduOnrrHLgV9gOnCLpGAznUd5584CBekZDCnqYY99Voam
3Pw6ngDKtkdmIYPMgQMbnQCvUVdTmkY7fFanpCfDnwn5O5Reo/wKQ+gqKpKOJp8P
8pvnt9FH5e4LsQGXQxuKDbuM2neeg2IxbFBpWsfZuVymGlOQnIX5aMZmxIXgGcYx
Ee8DYLbBFLKp0nxf0FQXSOCQ0D0Q3mjo6EUFvRxSaOdK3suedrjFo3CArl1NA+Nu
m4gxyFNeMdf0BKAeKotEBK2fFiRSRpb2qDK1vFFvNVei9BET/uLfJOhGrD6R7q9o
E6BCKdqOxCrQ7C9NNW2pqAbplIju4tWdPWzCd724cpkrg+uEwUJVBtwPxdLBgzdy
dP6cuWe8e60SAW5bgS2z8s+0H/lZlpiRUvwN+KRoPcqPIXyxchQagXWBFapw+WQ9
BBSCT433UQhBujE0YQKK41tzz01fuXO8uJPsdM9sxks1enVK1JCXoWVqlgd8lH9l
h8OZB1Ed+f2ZJ9CTXyrpvHVN9WT2uPqUidQPW2DXH86lt14dAzC/wm1Q8A+Ks/n6
PVCP8/6j
=Vm8G
-----END PGP SIGNATURE-----

--=-lEkRE2T8cDt5GdhbcyET--