[Lto-team] Fwd: [tuples] reduced testcase of the libjava build failure

[Richard Guenther]

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.