This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/83396] [8 Regression] Bootstrap failures with Statement Frontiers


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83396

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Alex, please have a look at this.
The problem is again the debug stmts (insns in this case) in unexpected spots.
Both the
;; Insn is not within a basic block
(debug_insn 4582 4581 4583 (var_location:DI flags (reg/v:DI 559 [ flags ]))
"/nasfarm/edelsohn/src/sandbox/gcc/gimple-pretty-print.c":2567 -1
     (nil))
and
;; Insn is not within a basic block
(debug_insn 5064 5063 5065 (var_location:SI spc (reg/v:SI 558 [ spc ]))
"/nasfarm/edelsohn/src/sandbox/gcc/gimple-pretty-print.c":2583 -1
     (nil))
insns are emitted in between a barrier and later code_label and appear there in
the *.expand/*.vregs dump, but then we go into the cfglayout mode and the
instructions are moved into the BB_FOOTER of some basic block (or BB_HEADER?)
and remain there until outof_cfglayout pass.  Most RTL passes assume there is
no interesting IL in there though, it isn't even dumped in dumps, and most of
the bb walks just ignore it, typically just notes or barriers should be there.
So, if we end up with debug insns in there, we just risk they will not be
properly maintained.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]