https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-debug
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-01-24
Ever confirmed|0 |1
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Ian Lance Taylor from comment #4)
> 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.
stmts with no location just get the location of whatever was there before.
This might not work very well for stmts at the beginning of a basic block.
Do we leave the "whatever was there before" to the assembler? If so we
should probably have some heuristic, like setting the location of the
first stmt of a basic block to either its own or the first stmt with a
location?
Note that not assigning a location to "artificial" stmts is exactly to avoid
jumping around when those stmts move -- they are not supposed to influence
the experienced "debug flow". But as said, this might not work as designed
for the start of a basic block. What happens when there is no stmt with
a location in side a basic block? Is there a way to tell the
debugger/assembler
"this stmt has no line information"?
