[Bug other/57970] New: segfault in sched-deps.c

["colanderman at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

            Bug ID: 57970
           Summary: segfault in sched-deps.c
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: colanderman at gmail dot com

Created attachment 30546
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30546&action=edit
Patch

Symptom: Segfault in sched-deps.c when compiling a large auto-generated C file:

==3363== Invalid read of size 8
==3363==    at 0x95A41D: sched_analyze_1 (sched-deps.c:2479)
==3363==    by 0x95D182: sched_analyze_insn (sched-deps.c:2859)
==3363==    by 0x95E636: deps_analyze_insn (sched-deps.c:3505)
==3363==    by 0x95E7F1: sched_analyze (sched-deps.c:3653)
==3363==    by 0x6EC4F8: sched_rgn_compute_dependencies (sched-rgn.c:2702)
==3363==    by 0x6EF582: schedule_insns (sched-rgn.c:2915)
==3363==    by 0x89E237: tilegx_reorg (tilegx.c:4710)
==3363==    by 0x6E0699: rest_of_handle_machine_reorg (reorg.c:4183)
==3363==    by 0x69F5BF: execute_one_pass (passes.c:2084)
==3363==    by 0x69FA30: execute_pass_list (passes.c:2139)
==3363==    by 0x69FA44: execute_pass_list (passes.c:2140)
==3363==    by 0x69FA44: execute_pass_list (passes.c:2140)
==3363==  Address 0x8 is not stack'd, malloc'd or (recently) free'd

Cause: deps->pending_read_insns and deps->pending_read_mems are getting out of
sync.  (Hence the NULL pointer access at sched-deps.c:2479.)

Fix: The conditions "!deps->readonly" under which deps->pending_read_mems is
freed in flush_pending_lists() should be changed to "!deps->readonly &&
!DEBUG_INSN_P (insn)" to match the condition "deps->readonly || DEBUG_INSN_P
(insn)" under which deps->pending_read_insns is not freed in
add_dependence_list_and_free().

Patch attached.  Unfortunately I cannot provide a test case, as I have only
been able to reproduce the crash with a very large (auto-generated) proprietary
C file.

The bug seems to exist in the source code of at least 4.6.3 as well, though I
have not been able to trigger it therein.