On Fri, Sep 25, 2015 at 10:09:23AM -0600, Jeff Law wrote: > >>So what that means is the presence or absence of debug information is > >>causing a difference in > > > the code you generate. That is (of course) bad and indicates a bug > >of some kind in your code. > > > >>I haven't put your code under a debugger or anything like that, but > >>this does jump out: > > > >>+ rtx_insn* temp_src_insn = BB_HEAD (then_bb); > >>+ if (temp_src_insn && NOTE_INSN_BASIC_BLOCK_P (temp_src_insn)) > >>+ temp_src_insn = NEXT_INSN (temp_src_insn); /* skip over a > >>start-of-BB note */ > > > >>What if BB_HEAD (then_bb) is a DEBUG_INSN with -g enabled, but is a > >>NOTE_INSN_BASIC_BLOCK when -g is not enabled. That could cause > >>this kind of failure.
I haven't looked at the full code, but NEXT_INSN is even more suspicious (you also need to skip the debug insns). > Otherwise, you're just going to have to slog through and find out why > the codegen is different. These kind of bugs are usually painful to > track down, but it's usually worth the time spent in the end. Compile with -dap (directly with cc1 or with -S), find some difference in the generated asm, see what the RTL insn number for that was (that's what -dp is for), find where the difference came from (from the dumpfiles, that's -da; you probably already know what pass is the culprit ;-) ) Segher