On 10/24/2021 8:15 PM, Jeff Law wrote:
On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
On 10/18/21 12:52 AM, Jeff Law wrote:
On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
The following patch converts the strlen pass from evrp to ranger,
leaving DOM as the last remaining user.
So is there any reason why we can't convert DOM as well? DOM's use
of EVRP is pretty limited. You've mentioned FP bits before, but my
recollection is those are not part of the EVRP analysis DOM uses.
Hell, give me a little guidance and I'll do the work...
Not only will I take you up on that offer, but I can provide 90% of
the work. Here be dragons, though (well, for me, maybe not for you
;-)).
[ ... ]
So the failure I see it a bootstrap comparison failure affecting
omp-expand.c and cp/cp-gimplify.c. We end up generating different
code with and without debug symbols.
Replying to myself....
So we're getting different results from a call to fold_range_internal
for this statement in bb #35 of expand_omp_target:
(gdb) p debug_gimple_stmt (stmt)
if (loop_171 != 0B)
259 res = fold_range_internal (r, s, NULL_TREE);
(gdb) n
283 if (idx)
(gdb) p res
$60 = true
(gdb) p r
$61 = (irange &) @0x7fffffffdb20: {m_num_ranges = 1 '\001',
m_max_ranges = 2 '\002', m_kind = VR_RANGE, m_base = 0x7fffffffdb30}
vs
259 res = fold_range_internal (r, s, NULL_TREE);
(gdb)
283 if (idx)
(gdb) p res
$16 = true
(gdb) p r
$17 = (irange &) @0x7fffffffdba0: {m_num_ranges = 1 '\001', m_max_ranges
= 2 '\002', m_kind = VR_VARYING,
m_base = 0x7fffffffdbb0}
Anyway, not sure when I'll be able to look at this again, perhaps
Wednesday. But my sense is something isn't right WRT the range of loop_171.
Jeff
