From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0765E3858439; Mon, 21 Nov 2022 23:21:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0765E3858439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669072902; bh=4v93D6UlgkQRZoRPULZN6ZhaCTBUZwZO/ErcE/UFjNc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FX2HqQx6sWms8DOciMhZ1qOFzts+iMmLY/bFqeVlX53Qz1Y0AjWPlWSGIaI/pylZq 32RyVpmjLGEwD820vmpT6GKa0x+kJfgteWO7Jw+iwJOex/wdSHq4qdForL3vzt44QV VF3dVxlH8dRZJkq+P3Dmdwysn42kf251SPs06Xpc= From: "ldionne.2 at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/107795] recursion through breaks non-GNU implementations of the C++ stdlib Date: Mon, 21 Nov 2022 23:21:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 12.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ldionne.2 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=3D107795 --- Comment #13 from Louis Dionne --- Let me rephrase my whole request here. I understand that what GCC does work for GCC and GCC-adjacent projects. This report is about making the behavior of more friendly to implementations that are not GCC-adjacent and that need to build on top of = the GCC machinery. Those implementations expect that they can include_next GCC headers and that no crazy magic is required to make that work, an expectati= on that is not met at the moment. Is GCC interested in doing that? If not, you can close this bug as "not to = be fixed". Frankly, I do hope there's such a desire, since on our side we (Clang and libc++) do try to be "friendly" to GCC/libstdc++. For example, Clang is car= eful to implement attributes and match GCC behavior, and libc++ similarly tries = to match libstdc++ behavior and ensures that it works on GCC. This results in a better ecosystem for everyone, but it can't be a one-way street. If you don't want to even consider fixing this "because it's not a problem within the GCC stack", there's nothing I can do about it, but I think that would be a poor decision. If there's a technical reason why this can't or shouldn't be done, I'm all ears.=