On Mon, Jan 26, 2015 at 10:11 AM, Jakub Jelinek wrote: > On Mon, Jan 26, 2015 at 10:06:05AM +0100, Eric Botcazou wrote: >> > While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs, >> > some targets like i?86/x86_64 choose to populate it again during machine >> > reorg and some target don't free it at the end of machine reorg. >> > This patch updates cleanup_barrier pass, so that it adjusts basic block >> > boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during >> > final pass. >> >> This isn't a recent regression so what about fixing it more "properly"? For >> example, by calling free_bb_for_insn at the end of the machinre reorg passes >> which called compute_bb_for_insn at the beginning? Or do the affected ports >> need the BB info all the way down to final? > > Yes, they do, that is why it crashed during final.
And they should not do so. It cannot be relied upon, in general. Even now, recomputing BLOCK_FOR_INSN only works because machine reorg is the first pass after free_cfg (so nothing has changed yet to the insns stream). Some ports (including x86_64/i386, ia64, and most non-sched_dbr ports) could simply do away with free_cfg and cleanup_barriers. But some ports put things into the insns stream after free_cfg that verify_flow_info chokes on, e.g. the fake insns for const pools for ARM (that causes bugs elsewhere also, see e.g. https://gcc.gnu.org/ml/gcc-patches/2011-07/msg02101.html). The current situation is confusing and bound to give bugs sooner or later... I had patches to have an "early" and "late" free_cfg pass -- I think I even posted them and I still believe that's the right short-term solution -- to make sure nobody can put something between free_cfg and a target with a machine_reorg that needs the CFG, or at least BLOCK_FOR_INSN. Oh well... Ciao! Steven
