> 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.
>
