[Lto-team] Fwd: [tuples] reduced testcase of the libjava build failure
Richard Guenther
richard.guenther@gmail.com
Fri May 2 09:07:00 GMT 2008
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.
More information about the Gcc-patches
mailing list