[Bug other/11375] New: rtl_dump_file problems in rest_of_compilation

[Bug other/11375] New: rtl_dump_file problems in rest_of_compilation

[wilson at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375

           Summary: rtl_dump_file problems in rest_of_compilation
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilson at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org

The code for managing rtl_dump_file in rest_of_compilation has gotten rather
confused.  There are many places where we have code that is supposed to write to
rtl_dump_file when -da, but it doesn't because the dump file was accidentally
closed.

Consider the relatively new bt-load optimization.  It runs in the middle of the
flow2 pass.  It opens and closes its own dump file, DFI_branch_target_load. 
This is all well and good, but there is a problem here.  Dump files don't stack.
 So when we calll open_dump_file for DFI_branch_target_load, we end up closing
the DFI_flow2 file accidentally.  Then when we close DFI_branch_target_load, we
have no dump file at all.  35 lines later, we attempt to close DFI_flow2, but
this does nothing at all.  Meanwhile, lots of info that should have gone into
the flow2 dump file disappears.

Consider the code near the rest_of_handle_ssa call.  We close the DFI_jump dump
file before the goto to exit_rest_of_compilation.  This makes sense in itself. 
We don't want to leave a file accidentally open here.  However, we continue as
if the DFI_jump dump file is still open, and 28 lines later there is another
call to close DFI_jump which does nothing.  Meanwhile info that should have gone
into dump files is lost.  Moving the first close inside the if statement before
the goto partially solves this.  It isn't a complete solution because we have
the same problem as above.  rest_of_handle_ssa and rest_of_handle_null both
create their own dump files, which implicitly close the DFI_jump dump file.

There may be other problems.

Someone should revise the rtl_dump_file handling in rest_of_compilation, and
rewrite it so tha we always have open dump files when we are supposd to.  Making
 open_dump_file create a stack of dump files would help.  Then we would not
accidentally close higher order dump files when we open lower order ones.  We
need to move the DFI_jump close into the if statements before the goto to
exit_rest_of_compilation as mentioned above.  This might be sufficient to solve
the problem.  This should be checked.  There might be other possible solutions.

This might be a good project for a beginner.

[Bug other/11375] rtl_dump_file problems in rest_of_compilation

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-07-20 02:41:43
               date|                            |


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-20 02:41 -------
rtl_dump_file could be made into a stack and this would make these problems go away.

[Bug other/11375] rtl_dump_file problems in rest_of_compilation

[dhazeghi at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375


dhazeghi at yahoo dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4                         |---

[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-12 17:15 -------
Some update on this bug.
rest_of_handle_ssa is removed and has been since 3.4.0.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375

[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-12 21:28 -------
(In reply to comment #0)
> Consider the relatively new bt-load optimization.  It runs in the middle of the
> flow2 pass.  It opens and closes its own dump file, DFI_branch_target_load. 
> This is all well and good, but there is a problem here.  Dump files don't stack.
>  So when we calll open_dump_file for DFI_branch_target_load, we end up closing
> the DFI_flow2 file accidentally.  Then when we close DFI_branch_target_load, we
> have no dump file at all.  35 lines later, we attempt to close DFI_flow2, but
> this does nothing at all.  Meanwhile, lots of info that should have gone into
> the flow2 dump file disappears.

In September 2004, open_dump_file was changed so that it aborts when a dump
file is already open.  That made the sh64-elf compiler abort when running
with -da.  I've fixed this with this patch:

http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01467.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375

[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-03-13 01:32 -------
This open_dump_file change looks like a sufficient solution to me.  That
prevents us from accidentally trying to open two dump files at the same time. 
The equivalent problem with close_dump_file is not serious, and unlikely to
happen without triggering the open_dump_file abort, so I don't think it needs a
solution.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |4.0.0
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375

[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375