From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E8C7A3858408; Fri, 1 Sep 2023 21:32:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8C7A3858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1693603959; bh=vjOi9dQLXlCP4n6o7Ar44hLyekuXtMnVNMTLVAc3+Mw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DbGwcJq03ivPYo50pNTBj68aAJGh92hlFSUmX52JrGMCd1Kvgj0e3vLh7UunPJZ53 ApDDgAnOTdyC+rDnzDXYpddxyzANIk+Qe7DGCAZGl3pLMY0Os3fpma9qV0wL8ArGxc Irg9r5ChQzzYSdvJr8FJ+MaKLXe01Xj6IxzsK3+0= From: "efric at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a Date: Fri, 01 Sep 2023 21:32:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: efric at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hp at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 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=3D111264 --- Comment #9 from Eric Feng --- (In reply to Hans-Peter Nilsson from comment #4) >=20 > If we move past the difference in semantics of the idioms in the patch, I > still don't see why there actually was error for the original syntax. Th= ere > must be something in the difference between the hash_map and hash_set > declarations. Eagerly awaiting comments on the patch. (Probably not the > best way to learn recent C++ standards, but believe it or not, I'm exposed > to a worse way, on another track... :) Thanks again for the patch, Hans-Peter. For those interested, I try to dive into why hash_map caused an error here whilst hash_set was fine in the orig= inal syntax in the body of this e-mail: https://gcc.gnu.org/pipermail/gcc/2023-September/242404.html. In short: I t= hink the issue was due to the compiler having trouble disambiguating between whi= ch hash_map constructor to use in the original syntax in C++11. Please feel fr= ee to chime in and correct my hypothesis. Cheers!=