http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-05 10:02:41 UTC --- (In reply to comment #15) > (In reply to comment #13) > > A guess is that you end up creating SSA names during code transform in > > different > > order - which can result from walking a hashtable to do things (which might > > be in different order when it doesn't have the same number of entries). > > I have verified in the debugger that SRA does not create any new SSA > names on its own, all of them are created by renaming after the pass > finishes (i.e. by TODO_update_ssa). > > > Note that if you process debug stmts _at all_ (thus end up creating new SSA > > names because of them) then this will break as well. > > I'm not sure what you mean. SRA does not process debug stmts but it > now creates them. The re-namer is apparently clever enough not to > create a PHI node and thus a new SSA name because of debug statements, > yet it manages to create them in a different order, probably because > it sees uses were there are none without debug statements. Can that > be the case? Is creating such uses really a bug? Awww. ISTR SRA creates new decls that are renamed by the SSA renamer. SSA rewriting creates those SSA names when visiting definition sites (this is why it doesn't create PHI nodes for debug uses ... hopefully). Renaming is performed in DOM order, but DOM order has DOM children "unordered" - can you check if rewrite_update_enter_block visits basic-blocks in different order -g vs. -g0?
