[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added Component|analyzer|testsuite Assignee|efric at gcc dot gnu.org |hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson --- I'm taking it as I'm about to commit the approved patch. Also, changing component to testsuite.
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 --- Comment #6 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:d3dd69706af4c086cb3385ff1f321887b91f49fb commit r14-3631-gd3dd69706af4c086cb3385ff1f321887b91f49fb Author: Hans-Peter Nilsson Date: Fri Sep 1 04:36:03 2023 +0200 testsuite: Fix analyzer_cpython_plugin.c declarations, PR testsuite/111264 Also, add missing newline at end of file. PR testsuite/111264 * gcc.dg/plugin/analyzer_cpython_plugin.c: Make declarations C++11-compatible.
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 --- Comment #7 from Hans-Peter Nilsson --- I don't think it's worthwhile to keep this open, as I'm pretty sure I fixed it for all targets, as the cause wasn't target-related. Otherwise, reopen; if adding a sarcastic comment, then preferably also with a humorous twist.
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 Hans-Peter Nilsson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Hans-Peter Nilsson --- .
[Bug testsuite/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111264 --- Comment #9 from Eric Feng --- (In reply to Hans-Peter Nilsson from comment #4) > > 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. There > 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 original syntax in the body of this e-mail: https://gcc.gnu.org/pipermail/gcc/2023-September/242404.html. In short: I think the issue was due to the compiler having trouble disambiguating between which hash_map constructor to use in the original syntax in C++11. Please feel free to chime in and correct my hypothesis. Cheers!
