Hello,
> (based on gcc 4.1.1).
now that is a problem; things have changed a lot since then, so I am not
sure how much I will be able to help.
> 1. The problem was unveiled by compiling a testcase with dump turned
> on. The compilation failed while calling function get_loop_body from
> flow_loop_dump on the following assert :
>
> else if (loop->latch != loop->header)
> {
> tv = dfs_enumerate_from (loop->latch, 1, glb_enum_p,
> tovisit + 1, loop->num_nodes - 1,
> loop->header) + 1;
>
>
> gcc_assert (tv == loop->num_nodes);
>
> The compilation exits successfully if compiled without enabling the dump.
this means that there is some problem in some loop transformation,
forgetting to record membership of some blocks to their loops or something
like that.
> 2. SMS pass contained a single call to loop_version on the loop to be
> SMSed. This happened before any SMS related stuff was done. Trying to
> call verify_loop_structure(loops) just after the call to loop_version
> failed on the same assert in get_loop_body as in (1). The loop on
> which we fail is neither the versioned loop nor the new loop.
Probably it is their superloop?
> Below
> there are dumps to verify_loop_structure called from different places
> in loop_version:
These dumps are not very useful, loop structures do not have to be
consistent in the middle of the transformation.
> 3. At the very beginning of the SMS pass we build the loop structure
> using build_loops_structure defined in modulo-sched.c. Just after the
>
> call I tried to print in gdb the loop on which we failed in
> get_loop_body. This failed as well
>
> (gdb) p print_loop(dumpfile, 0xbabe20, 0)
Do not use print_loop, that only works on gimple. Use flow_loops_dump
to find which blocks belong to which loops, and possibly debug_bb_n
if you need to see the contents of the blocks.
Zdenek
