This is the mail archive of the
mailing list for the GCC project.
Re: Fix PR 56077
- From: Andrey Belevantsev <abel at ispras dot ru>
- To: Olivier Hainque <hainque at adacore dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc-patches at gcc dot gnu dot org Patches" <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, Leonid Lisovskiy <lly dot dev at gmail dot com>, maxim at kugelworks dot com
- Date: Fri, 05 Apr 2013 15:22:04 +0400
- Subject: Re: Fix PR 56077
- References: <512772F5 dot 3040007 at ispras dot ru> <51594783 dot 2050600 at ispras dot ru> <515E7538 dot 4070408 at ispras dot ru> <2872353 dot 8z9xlFt23k at polaris> <2BF9B339-B6EF-49C4-87ED-FB4195254C89 at adacore dot com>
On 05.04.2013 14:10, Olivier Hainque wrote:
On Apr 5, 2013, at 10:13 , Eric Botcazou <email@example.com> wrote:
We do have regressions on the 4.7 branch in the scheduler (CCed Olivier who
has more information).
Right: we do see a SEGV while compiling the attached monitor.i (preprocessed
output from a qemu tree) with -O2 -g.
./cc1 -m32 -O2 -g -quiet monitor.i
.../monitor.c: In function âmemory_dumpâ:
.../monitor.c:1109:1: internal compiler error: Segmentation fault
As already mentioned upthread, this is triggered by a call to
flush_pending_lists with a DEBUG_INSN. We get into:
add_dependence_list_and_free (deps, insn, &deps->pending_read_insns,
deps->pending_read_list_length = 0;
add_dependence_list_and_free doesn't free *LISTP when
operating on DEBUG_INSNs, so we end up with pending_read_mems freed together
with pending_read_insns not freed.
This was cured on mainline by:
Date: Mon Aug 27 22:11:48 2012 +0000
* sched-deps.c (add_dependence_list_and_free): Simplify.
(flush_pending_list_and_free): Fix a hack that was fixing a hack. Free
lists when add_dependence_list_and_free doesn't free them.
I don't know whether backporting this would be better than reverting
the offending change as just done on 4.7.
I'd say for 4.6 the best way is to revert. PR 56077 is not that important,
and this 4.6 release will be the last one. For 4.7, we can additionally
backport Maxim's patch or revert this one. I'm fine with both options, but
I'll test 4.7 backport too just to be ready for that.