From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0AA2B3858D28; Sat, 6 May 2023 23:28:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0AA2B3858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683415718; bh=52b5wEzpc3THV5eW4f3lwGEDaFCPmcUBsazsfifUi+c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fWbqVMSDWkVyq0t0qrj2gyPHNkEZhe/A3C3bVzkyODxlZU97yZOGFphBzVO2A+cRd j6qsvoWF0E7gUTVsXzg4e47YjO3hcwnZKjyFpzhACTiYr7bFOFtHvDNUqI/PFjxebU r4dXcBPQJxasUwmq8IkiHserhYAjqVJwEww917nQ= From: "ldalessandro at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/109751] boost iterator_interface fails concept check starting in gcc-13 Date: Sat, 06 May 2023 23:28:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ldalessandro at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109751 --- Comment #15 from Luke Dalessandro --- Thanks for looking at this. I'd like to report it back to boost as an issue, but I want to make sure I understand what to tell them. 1. The error produce by Andrew's reduction ("error: satisfaction of atomic constraint ... depends on itself") is different than the one produced in the original code ("error: satisfaction value of atomic constraint ... changed) from 'false' to 'true'"). I'm to understand that this isn't important here, it's basically reacting to the same thing? 2. The fundamental problem with the boost code is the use of a constrained `friend` template that depends on the template parameter D, that is not yet complete when it is evaluated? 3. A fix for this issue in boost and the iterator_interface is to use a constrained member function rather than attempting to use a constrained fri= end function? Also, from what I understand, I should report Andrew's reduced case as a bu= g in clang, and msvc (and maybe nvc++ with its different front-end), which I will do. Thanks for looking into this.=