> From: Segher Boessenkool
>
> Ah. Is there a PR for it yet? Please open one, if not.
>
Yes, PR79150. I got carried away with the mailing and forgot about the PR,
sorry.
I have updated the PR thread with all of the things we've discussed in this
thread (and some more).
Let's continue this di
On Thu, Feb 23, 2017 at 10:43:36PM +, Matthew Fortune wrote:
> This is an ICE that will be reproducible on a primary target so is still
> appropriate to pursue in stage4 as far as I understand. I'm hoping to
> find time to work with Toma on this issue.
Ah. Is there a PR for it yet? Please o
Segher Boessenkool writes:
> On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > > This happens when you have inserted code ending in a jump on an
> edge.
> > > This then will need updating of the CFG, and this code does not know
> > > how to do that.
> >
> > Would the following be an
Hi Toma,
On Thu, Feb 23, 2017 at 04:27:26PM +, Toma Tabacu wrote:
> > This happens when you have inserted code ending in a jump on an edge.
> > This then will need updating of the CFG, and this code does not know
> > how to do that.
>
> Would the following be an appropriate solution ?
[ snip
Hi Segher,
Thank you for replying.
> From: Segher Boessenkool
>
> This happens when you have inserted code ending in a jump on an edge.
> This then will need updating of the CFG, and this code does not know
> how to do that.
>
Would the following be an appropriate solution ?
diff --git a/gcc/
Hello Toma,
On Thu, Feb 16, 2017 at 02:39:12PM +, Toma Tabacu wrote:
> It is caused by "gcc_assert (!JUMP_P (last))" in
> commit_one_edge_insertion (gcc/cfgrtl.c:2059-2077):
>
> if (returnjump_p (last))
> {
> /* ??? Remove all outgoing edges from BB and add one for EXIT.
>
Hello,
I have been looking into an ICE triggered by the gcc.dg/pr77834.c test for
MIPS targets (filed as PR 79150).
It turns out that it is unrelated to the fix for PR 77834, as the code from the
test case triggers the same ICE even without those changes.
It is caused by "gcc_assert (!JUMP_P (la
