From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id A32C03848013; Fri,  2 Jul 2021 16:47:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A32C03848013
From: "rodgertq at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/101274] [11/12 Regression] std::execution::seq has
 incorrect behaviour under GCC 11.1.0
Date: Fri, 02 Jul 2021 16:47:06 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 11.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rodgertq at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-101274-4-7p3CdThcLS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101274-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101274-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Jul 2021 16:47:06 -0000

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

--- Comment #6 from Thomas Rodgers <rodgertq at gcc dot gnu.org> ---
It does raise an issue which I'm going to follow up on separately on the SG1
(concurrency and parallelism study group) mailing list.

While it is indeed the case that standard says you can't count on determini=
stic
sequencing for std::reduce(), I can't find any wording that directly suppor=
ts
the wording on cppreference.com std::execution::sequenced_policy, though th=
at
wording is consistent with my recollection of SG1's discussions regarding
execution policies.

There is wording that says 'Unless otherwise specified, the semantics of
ExecutionPolicy algorithm overloads are identical to their overloads withou=
t."

The wording for std::for_each() for the non-execution policy overload the
standard says -

Effects: Applies f to the result of dereferencing every iterator in the ran=
ge
[first, last), starting from first and proceeding to last - 1.

And for one that takes an execution policy -

Effects: Applies f to the result of dereferencing every iterator in the ran=
ge
[first, last).

So it omits the ordering constraint, which makes sense, but I wonder if we
shouldn't be more explicit in the documentation of the policies themselves.=