https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116219
--- Comment #17 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:165e3e7c3ba884345647c0f1c9a3a57a03383651 commit r15-2800-g165e3e7c3ba884345647c0f1c9a3a57a03383651 Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Aug 7 20:14:31 2024 +0200 Don't call clean_symbol_name in create_tmp_var_name [PR116219] SRA adds fancy names like offset$D94316$_M_impl$D93629$_M_start where the numbers in there are DECL_UIDs if there are unnamed FIELD_DECLs etc. Because -g0 vs. -g can cause differences between the exact DECL_UID values (add bigger gaps in between them, corresponding decls should still be ordered the same based on DECL_UID) we make sure such decls have DECL_NAMELESS set and depending on exact options either don't dump such names at all or dump_fancy_name sanitizes the D123456$ parts in there to Dxxxx$. Unfortunately in tons of places we then use get_name to grab either user names or these SRA created names and use that as argument to create_tmp_var{,_name,_raw} to base other artificial temporary names based on that. Those are DECL_NAMELESS too, but unfortunately create_tmp_var_name starting with https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=725494f6e4121eace43b7db1202f8ecbf52a8276 calls clean_symbol_name which replaces the $s in there with _s and thus dump_fancy_name doesn't sanitize it anymore. I don't see any discussion of that commit (originally to TM branch, later merged) on the mailing list, but from DECL_NAME (new_decl) = create_tmp_var_name (IDENTIFIER_POINTER (DECL_NAME (old_decl))); - SET_DECL_ASSEMBLER_NAME (new_decl, NULL_TREE); + SET_DECL_ASSEMBLER_NAME (new_decl, DECL_NAME (new_decl)); snippet elsewhere in that commit it seems create_tmp_var_name was used at that point also to determine function names of clones, so presumably the clean_symbol_name at that point was to ensure the symbol could be emitted into assembly, maybe in case DECL_NAME is something like C++ operators or whatever could have there undesirable characters. Anyway, we don't do that for years anymore, already GCC 4.5 uses for such purposes clone_function_name which starts of DECL_ASSEMBLER_NAME of the old function and appends based on supportable symbol suffix separators the separator and some suffix and/or number, so that part doesn't go through create_tmp_var_name. I don't see problems with having the $ and . etc. characters in the names intended just to make dumps more readable, after all, we already are using those in the SRA created names. Those names shouldn't make it into the assembly in any way, neither debug info nor assembly labels. There is one theoretical case, where the gimplifier promotes automatic vars into TREE_STATIC ones and therefore those can then appear in assembly, just in case it would be on e.g. SRA created names and regimplified later. Because no cases of promotion of DECL_NAMELESS vars to static was observed in {x86_64,i686,powerpc64le}-linux bootstraps/regtests, the code simply uses C.NNN names for DECL_NAMELESS vars like it does for !DECL_NAME vars. Richi mentioned on IRC that the non-cleaned up names might make things harder to feed stuff back to the GIMPLE FE, but if so, I think it should be the dumping for GIMPLE FE purposes that cleans those up (but at that point it should also verify if some such cleaned up names don't collide with others and somehow deal with those). 2024-08-07 Jakub Jelinek <ja...@redhat.com> PR c++/116219 * gimple-expr.cc (remove_suffix): Formatting fixes. (create_tmp_var_name): Don't call clean_symbol_name. * gimplify.cc (gimplify_init_constructor): When promoting automatic DECL_NAMELESS vars to static, don't preserve their DECL_NAME.
