https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
Ian Lance Taylor <ian at airs dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ian at airs dot com
--- Comment #4 from Ian Lance Taylor <ian at airs dot com> ---
Sure, we can fix the test case. But in general Go is intended to provide
accurate tracebacks, and this is a case where it is failing to do so. This is
independent of the fact that the loop is heavily optimized; that doesn't matter
here. The point is that anywhere in the loop should be in the same basic
block. I don't think that accurate tracebacks are an unreasonable goal so I'd
like to push back a bit.
The problem with the statement with no location is that due to future
optimizations it winds up at the start of the basic block. The eventual effect
is that the first statement of the basic block appears to be in the preceding
block. That makes no sense, as the block is a loop. By the time we get to
232t.optimized, the block looks like this:
<bb 4> [local count: 1063004407]:
# ivtmp_7 = PHI <2147483647(3), ivtmp_1(4)>
# DEBUG j => (int) (2147483647 - ivtmp_7)
# DEBUG D#1 => (int) (2147483648 - ivtmp_7)
[foo.go:6:31] # DEBUG j => D#1
# DEBUG j => D#1
ivtmp_1 = ivtmp_7 + 18446744073709551615;
[foo.go:6:17] if (ivtmp_1 != 0)
goto <bb 4>; [98.99%]
else
goto <bb 3>; [1.01%]
Perhaps it is correct that the `ivtmp_1 =` line shouldn't have a location, but
it does after all get a location in the end. That location shouldn't be in an
entirely differently basic block.
