This is the mail archive of the gcc@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]

Problem with jump tables


Hi,

This is related to a regression that appeared on SPARC64 with the merging 
of the new WEB pass:

FAIL: gcc.c-torture/execute/20011219-1.c compilation,  -O3 
-fomit-frame-pointer 
UNRESOLVED: gcc.c-torture/execute/20011219-1.c execution,  -O3 
-fomit-frame-pointer 
FAIL: gcc.c-torture/execute/20011219-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/20011219-1.c execution,  -O3 -g 


The sequence of events is as follows:
- CSE is able to assert that a particular 'case' will always be taken inside 
a switch, so it replaces the (set (pc) (reg)) by a (set (pc) (label)),
- purge_all_dead_edges purges the edges to the now useless 'case' statements,
- delete_unreachable_blocks deletes the bbs corresponding to these 'case' 
statements,
- WEB performs pseudo-registers splitting, which makes the insns that set up 
the jump table trivially dead,
- delete_trivially_dead_insns deletes these insns.

So we end up with an orphaned jump table, caught by verify_flow_info.

At which stage should the jump table be deleted? I tend to think it would be 
during CSE, but then the insns that set up the jump table would reference an 
undefined label (that of the jump table itself). Or should cleanup_cfg be 
taught to delete such orphaned jump tables?

-- 
Eric Botcazou


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