https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122686
--- Comment #19 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Haochen Jiang from comment #18)
> I forgot to attach the gimple it stuck at:
>
> It stuck here:
>
> (gdb) p *(gimple*)(0x7fe446e45320)
> $4 = {code = GIMPLE_CALL, no_warning = 0, visited = 1, nontemporal_move = 0,
> plf = 1, modified = 0, has_volatile_ops = 0, ilf = 0, subcode = 0, uid = 2,
> num_ops = 6, location = 4611686018427388158, bb = 0x7fe4470e4240,
> next = 0x7fe4473fe660, prev = 0x7fe44739e660}
huh. That seems very weird. The tracebacks are all in range_of_range_op,
meaning there is a handler.. but calls are handled by range_of_call (). And
we don't process arguments of calls either.
OH!... but we do handle calls that are builtins in
gimple_range_op_handler::maybe_builtin_call by creating custom handlers for
specific calls. So this is most likely a builtin call, so we'll want to check
the handler.
Its also odd that its appears to be in an infinite loop, yet does not blow the
stack. It must be cycling between the same set of statements. What is the
CALL statement? its also trying to get ranges on an edge, so presumably at
least one of the parameters to this builtin are coming from a different basic
block. perhaps the cache propagator is getting confused by the CFG state?
Can you attach both the .optimized and what there is of .expand listings?
and print_gimple_stmt (stderr, stmt, 0, 0) on that statement that we are not
getting past... I want to know which statement in the listing we are stuck on
I'll look to see if there is anything odd, and then probably have more
questions :-p
