[Bug tree-optimization/77648] [5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, the vectorized loop itself looks ok to me.  Unfortunately I can't get gdb
to
help me debugging the result array.  Looks like the 3rd invocation of
evaluate_1dim_real gets the bogus data:

-   0.0000000000000000        0.0000000000000000       -1.1904761904761946E-002
  0.0000000000000000       0.12500000000000000      -0.33333333333333331      
0.41666666666666663      -0.28571428571428570       0.10416666666666666      
-1.5873015873015872E-002
+   0.0000000000000000        0.0000000000000000       -1.1904761904761946E-002
  0.0000000000000000       0.12500000000000000      -0.33333333333333331      
0.41666666666666663      -0.28571428571428570        0.0000000000000000       
0.0000000000000000     

--param vect-max-peeling-for-alignment=0 simplifies the generated code but
doesn't fix the issue.

Adding -fno-tree-dse does.

;; Function integrate_poly_indefinite
(__poly_module_MOD_integrate_poly_indefinite, funcdef_no=17, decl_uid=3532,
cgraph_uid=17, symbol_order=17)

  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_32] = _44;
'
  Deleted dead store 'MEM[(real(kind=8)[0:] *)_14][_91] = _97;
'
integrate_poly_indefinite (struct poly & restrict p)


And:

  # .MEM_5 = VDEF <.MEM_4(D)>
  p_intD.4173.coefficientsD.3452.dataD.3438 = 0B;
...
  # .MEM_12 = VDEF <.MEM_10>
  # USE = nonlocal escaped null { D.4173 D.4174 D.7974 D.7975 D.7976 }
(nonlocal)
  # CLB = nonlocal escaped null { D.4173 }
  init_poly (&p_intD.4173, &D.4174, _11);
...
  # PT = null
  _14 = p_intD.4173.coefficients.data;

so somehow init_poly side effect is not properly reflected.  Constraints look
good:

p_int.128+64 = &NULL
...
callarg(28) = &p_int.0+96
callarg(28) = *callarg(28) + UNKNOWN
CALLUSED(26) = callarg(28)
CALLCLOBBERED(27) = callarg(28)
*callarg(28) = NONLOCAL
...
_14 = p_int.128+64

but in the end:

p_int.0+96 = { ESCAPED NONLOCAL } same as p_int.0+96
p_int.128+64 = { NULL }
p_int.192+320 = { } same as _15
p_int.512+64 = { NULL }
p_int.576+320 = { } same as p_int.576+320

so somehow callarg(28) = *callarg(28) + UNKNOWN does not have the desired
effect.