From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 586CA385840A; Tue, 30 May 2023 10:20:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 586CA385840A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685442046; bh=T/uRVW61mJAfd1NlbChi0zMGZe3ya+Q0YVsIGBHr3H0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=uorwjHnKWGJwPbZHxgHlsQEXjDYGYrX9tN7YOZBQY4TtJI/mR/vh6lN5FUFj4wOv9 jE9uH07M0iDQslHkF3Ceckh56LsM1ty9Am2FSyJ5a10sXsCX91msGcoRvitdRIcWjS 1L748VHYfGMRURYLil3RIK0EzNXCfpbqrdK8IWTA= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/110028] slow compilation on incorrect namespace after gcc-12.1 Date: Tue, 30 May 2023 10:20:45 +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: 12.1.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: NEW 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: everconfirmed cf_reconfirmed_on bug_status 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=3D110028 Jonathan Wakely changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Last reconfirmed| |2023-05-30 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- (In reply to Steven Xia from comment #0) > The following program is very slow to compile (>10 seconds) and return > error. Compared to clang (<1 second). N.B. -std=3Dc++20 or similar is needed to reproduce this. It's fast with the default options. It's fast with -fmax-errors=3D2000 so I think the error handling machinery = gets stuck in a loop, or the time is spent generating the actual error output. Maybe we should instantly fail if any libstdc++ header is included inside a namespace, since that's explicitly disallowed by the standard: "A translation unit shall include a header only outside of any declaration = or definition and, in the case of a module unit, only in its global-module-fragment, and shall include the header or import the corresponding header unit lexically before the first reference in that translation unit to any of the entities declared in that header. No diagnos= tic is required." That would need some new attribute or pragma though.=