http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- The issue is that after folding strcat_chk -> strcat -> strcpy (dst + strlen, ...) we do gimplify_and_update_call_from_tree which as part of gimplification folds the builtins again, which enters update_call_from_tree which tries to preserve virtual operands (which are not yet there) and finally calls gsi_replace which does update_stmt (). That causes virtual operands to be marked for renaming even if the outer folding routines happily update virtual operands correctly. So the issue is that we re-enter the builtin folding machinery via gimplification and that is able to fold things further than builtins.c folding which recurses to the tree foldings. I'm inclined to disable that if ctx->into_ssa, or add a new flag, ->fold_calls. [in the end we want to remove all stmt folding from the gimplifier and maybe have one strategical place where we fold all stmts once] Or, less intrusive, remove that strcat folding from GENERIC folding (builtins.c) as we have tree-ssa-strlen.c now which optimizes it for the interesting case of an already available string length - generally folding strcat to strcpy (dst + strlen (dst), src) isn't profitable. That also gets rid of that odd optimize_insn_for_speed_p call in builtins.c [I've skimmed through other calls we generate in builtins.c and decided the above is the only case where we can recurse into gimple call folding]
