Bug 26475 - tree-ssa loses line numbers for initializations (constants for PHIs)
Summary: tree-ssa loses line numbers for initializations (constants for PHIs)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.0.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2006-02-26 20:22 UTC by Daniel Jacobowitz
Modified: 2018-12-10 09:51 UTC (History)
4 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-02-10 14:50:21


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Jacobowitz 2006-02-26 20:22:17 UTC
Here's a simple testcase.  Compile with -O2 and look at the -fdump-tree-all-lineno dumps:

int foo (int);
int bar (int a)
{
  int ndir = 0;
  int b;

  b = foo (a);
  while (b--)
    ndir = foo (ndir);
}

Early on, the ndir = 0 assignment is marked for line 4.  Then the 0 gets propogated into a phi without a line number, which ends up associated with the while loop (in a larger testcase, with the end of the instruction before the loop instead of the start of the loop - not sure why a difference).  The original assignment is DCE'd.

Then an exactly identical initialization is rematerialized (not surprising), and the closest line number we could find was the line number of the statement before the phi.

Obviously stepping over this in GDB looks unnecessarily strange.

Perhaps some PHI arguments could have line number information to be used on edges when coming out of SSA?

FYI, original testcase comes from GDB's selftest.exp; we get a very surprising line number associated with the first real instruction.
Comment 1 Daniel Jacobowitz 2006-02-27 20:44:44 UTC
Dan Berlin, Diego, and I bounced this around on IRC a little.  A couple of things that came up:

  - Diego suggested putting locuses on unshared INTEGER_CSTs as another possible approach.

  - I suggested that if we want line numbers to be useful with optimization, we need to enforce and verify setting locuses.

  - Dan Berlin responded:

I think then a start may be to propose that we require EXPR_LOCATIOn on every modify_expr to be non-null and verified by verify_stmts.  That will break pretty much everywhere inserting code without locuses (which i know includes PRE :P) As we discover where we need to propagate more info around (phi args, wherever), we come up with a design for what needs to be done where.  The only thing i know tries to keep line number info sane is tree-sra.c.  Things like PRE should be using the line-number preserving sra_* functions (moved somewhere else and renamed bsi_*_with_location).  Anyhoo, that's how i'd approach it.  As you've said, there is no point in trying to put more information in places if we don't keep the basic stmt info up to date :)
Comment 2 Manuel López-Ibáñez 2008-02-10 14:50:21 UTC
I think this is confirmed.
Comment 3 Manuel López-Ibáñez 2009-07-24 23:40:30 UTC
(In reply to comment #1)
> Dan Berlin, Diego, and I bounced this around on IRC a little.  A couple of
> things that came up:
> 
>   - Diego suggested putting locuses on unshared INTEGER_CSTs as another
> possible approach.

What would be the cost of this? This will help to give accurate diagnostics even without optimization.
Comment 4 Richard Biener 2009-07-25 09:50:17 UTC
I don't like unsharing constants.  Instead we could force all constants to
be assigned to SSA names so they have their own statement.  For PHI nodes
I believe Andrew has added location slots for each arg as part of the
debuglocus effort.
Comment 5 Andrew Macleod 2009-07-30 18:40:08 UTC
I just checked in the code to track locations through PHI arguments.

Comments and patch is located:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html
Comment 6 Eric Gallager 2018-03-09 01:59:46 UTC
(In reply to Andrew Macleod from comment #5)
> I just checked in the code to track locations through PHI arguments.
> 
> Comments and patch is located:
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html

Thread said it was checked it as r150267 apparently?
Comment 7 Eric Gallager 2018-12-09 14:56:54 UTC
(In reply to Eric Gallager from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > I just checked in the code to track locations through PHI arguments.
> > 
> > Comments and patch is located:
> > http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html
> 
> Thread said it was checked it as r150267 apparently?

Andrew, can this be closed?
Comment 8 Richard Biener 2018-12-10 09:51:21 UTC
Fixed.