This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Lto-team] Fwd: [tuples] reduced testcase of the libjava build failure
That's another way to fix it. I don't know the CFG infra-structure
well enough to tell if this is better than allowing exception edges
from a block ending in a conditional branch. I can certainly try
that tomorrow.
Thanks for your comments.
-Doug
2008/5/2 Richard Guenther <richard.guenther@gmail.com>:
>
> On Fri, May 2, 2008 at 3:57 AM, Doug Kwan (關振德) <dougkwan@google.com> wrote:
> > ---------- Forwarded message ----------
> > From: Doug Kwan (關振德) <dougkwan@google.com>
> > Date: 2008/5/1
> > Subject: Re: [Lto-team] Fwd: [tuples] reduced testcase of the libjava
> > build failure
> > To: Rafael Espindola <espindola@google.com>
> > 副本： lto-team <lto-team@google.com>
> >
> >
> > The test case fails because we find a basic block with 3 out-going
> > edges in gimple_verify_flow_info:
> >
> > if (!true_edge
> > || !false_edge
> > || !(true_edge->flags & EDGE_TRUE_VALUE)
> > || !(false_edge->flags & EDGE_FALSE_VALUE)
> > || (true_edge->flags & (EDGE_FALLTHRU | EDGE_ABNORMAL))
> > || (false_edge->flags & (EDGE_FALLTHRU | EDGE_ABNORMAL))
> > || EDGE_COUNT (bb->succs) >= 3)
> > {
> > error ("wrong outgoing edge flags at end of bb %d",
> > bb->index);
> > err = 1;
> > }
> >
> > The offend bb ends with a statement like
> >
> > if (a <= b) ...
> >
> > where a & b are floating point values. With -fnon-call-exceptions,
> > floating point comparison is considered trapping so it make sense for
> > the bb to have a third exception edge.
> >
> > The test-case does not fail with TOT compiled with --enable-checking.
> > I looked at that and found that tree_could_trap_p is broken in two
> > levels. First, it does not handle COND_EXPR specially. It just looked
> > at the TREE_TYPE for COND_EXPR (void_type_node) to compute
> > fp_operation. I added a code to recurse with the condition in
> > COND_EXPR and it was still broken. The reason is that it uses the
> > type of a comparison tree (boolean_type_node) to compute the flag
> > fp_operation. Finally I fixed that and I got the same ICE as in the
> > tuple branch.
> >
> > I guess --enable-checking=yes and -fnon-call-exceptions do not got
> > together to make the bugs detectable. I will try relaxing the test in
> > gimple_verify_flow_info to allow for a third exception edge and see
> > how things goes.
>
> IMHO if such comparison may trap then we need to gimplify to
>
> <bb>
> ...
> bool tmp = a < b;
>
> <bb>
> if (tmp)
> ....
>
> instead. So the verification problem shows that we _do_ have a real
> problem here. No code expects another edge than the true and false
> edges from a BB ending with a COND_EXPR.
>
> Richard.
>