http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101
--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > passes with this change and the testcase from this PR finishes in under a > second. Manuel, can you please try to explain what you were trying to > achieve in the SAVE_EXPR case and whether the reversal of copy behavior in > merge_tlist was on purpose? I don't remember I implemented this part (the revision that you mention is not adding the handling of SAVE_EXPR or the reversal of copy behavior). My patch simply extended the definition of what is considered candidates for warning (by looking at the operands of operators). I took a look at my patch, and I don't fully understand how it triggers the bug that you mention. Perhaps there is some duplication between the code path that I added (since it is meant to recurse on operands) and some special-handling that was there for SAVE_EXPR and COND_EXPR.
