https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91157

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-07-15
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |10.0
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Vector lowering doesn't seem to know how to deal with

 <ssa_name 0x7ffff6884cf0
    type <vector_type 0x7ffff6a2c348
        type <boolean_type 0x7ffff6a2c2a0 public QI
            size <integer_cst 0x7ffff687adc8 constant 8>
            unit-size <integer_cst 0x7ffff687ade0 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6a2c2a0 precision:2 min <integer_cst 0x7ffff6977198 -2> max <integer_cst
0x7ffff6a35d68 1>>
        QI size <integer_cst 0x7ffff687adc8 8> unit-size <integer_cst
0x7ffff687ade0 1>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6a2c348 nunits:4>
    visited
    def_stmt _1 = _5;
    version:1>

defs.  Or rather with VEC_COND_EXPR lowering since seemingly the
comparison itself is fine (resulting in this vector type).

  vector(4) <unnamed type> D.2953;
  vector(4) <unnamed type> _1;
  vector(4) __int128 _2;
  vector(4) long double _3;
  vector(4) <unnamed type> _5;

  <bb 2> :
  _5 = gl_4(D) == { 0.0, 0.0, 0.0, 0.0 };
  _1 = _5;
  _2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
  _3 = VIEW_CONVERT_EXPR<v4ldbl>(_2);
  <retval> = _3;

w/o the exception stuff the comparison is moved inside the VEC_COND_EXPR
and everything is supported by the target.

I guess moving this out is premature and the root-cause of the issue
(still the lowering is broken).  Note the need to factor out the
compare is for IL consistency wrt exceptions but ultimatively it is
a target dependency of whether the condition evaluation is a separate
instruction from the VEC_COND_EXPR.

enum gimplify_status
gimplify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
               bool (*gimple_test_f) (tree), fallback_t fallback)
{
...
        case VEC_COND_EXPR:
          {
            enum gimplify_status r0, r1, r2;

            r0 = gimplify_expr (&TREE_OPERAND (*expr_p, 0), pre_p,
                                post_p, is_gimple_condexpr, fb_rvalue);

the re-use of is_gimple_condexpr might not be the best idea.

Reply via email to