[Bug sanitizer/108023] New: Incorrect line number in ASAN's report

[Bug sanitizer/108023] New: Incorrect line number in ASAN's report

[shaohua.li at inf dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023

            Bug ID: 108023
           Summary: Incorrect line number in ASAN's report
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: shaohua.li at inf dot ethz.ch
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

For the following code, GCC's ASAN at -O1 and above produce incorrect line
numbers in the final reports (Line 15 v.s. Line 8).

Compiler explorer: https://godbolt.org/z/4953EPr78

% cat a.c
int a, b, c, g, f;

static long d(int);

long d(int h) {
  int **j = (int**)malloc(sizeof(int *) * sizeof(int));
  for (int i = 0; i < sizeof(int); i++)
    j[i] = malloc(sizeof(f));

  int *k = malloc(sizeof(int) * sizeof(g));

  for (h=0; h <= 2; h++) {
    free(k);
    for (b=0; b <= 2; b++)
      k[3] = j[0][h];
  }
  return k[a];
}

void e() { 
    c = d(0); 
}

int main() { 
    e();  
    return c;
}
%
% gcc-tk -O0 -fsanitize=address -w -g a.c && ./a.out
=================================================================
==3175968==ERROR: AddressSanitizer: heap-use-after-free on address
0x60200000009c at pc 0x00000040130f bp 0x7ffd47fc9fd0 sp 0x7ffd47fc9fc8
WRITE of size 4 at 0x60200000009c thread T0
    #0 0x40130e in d /a.c:15
    #1 0x4013a3 in e /a.c:21
    #2 0x4013ba in main /a.c:25
...
%
%  gcc-tk -O2 -fsanitize=address -w -g a.c && ./a.out
================================================================
==3254785==ERROR: AddressSanitizer: heap-use-after-free on address
0x60200000009c at pc 0x000000401354 bp 0x7ffce8fa2e80 sp 0x7ffce8fa2e78
WRITE of size 4 at 0x60200000009c thread T0
    #0 0x401353 in d /a.c:8
    #1 0x4010e8 in e /a.c:21
    #2 0x4010e8 in main /a.c:25
...
%

[Bug tree-optimization/108023] Incorrect line number in ASAN's report

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|sanitizer                   |tree-optimization
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-12-08

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
LIM loses the line #.
We go from:
  <bb 6> [local count: 955630225]:
  # b.1_46 = PHI <_16(6), [/app/example.cpp:16:17 discrim 1] 0(5)>
  [/app/example.cpp:17:7] # DEBUG BEGIN_STMT
  [/app/example.cpp:17:17] _9 = *j_1;
  [/app/example.cpp:17:19] _11 = (long unsigned int) h_45;
  [/app/example.cpp:17:20] _12 = _11 * 4;
  [/app/example.cpp:17:20] _13 = _9 + _12;
  [/app/example.cpp:17:20] _14 = *_13;
  [/app/example.cpp:17:12] MEM[(int *)k_8 + 12B] = _14;
  [/app/example.cpp:16:5 discrim 3] # DEBUG BEGIN_STMT
  [/app/example.cpp:16:5 discrim 3] _16 = b.1_46 + 1;
  [/app/example.cpp:16:5 discrim 3] b = _16;
  [/app/example.cpp:16:17 discrim 1] # DEBUG BEGIN_STMT
  [/app/example.cpp:16:17 discrim 1] if (_16 <= 2)
    goto <bb 6>; [89.00%]
  else
    goto <bb 7>; [11.00%]

To:
  <bb 6> [local count: 955630225]:
  # b.1_46 = PHI <_16(10), [/app/example.cpp:16:17 discrim 1] 0(5)>
  [/app/example.cpp:17:7] # DEBUG BEGIN_STMT
  [/app/example.cpp:17:12] k__lsm.10_48 = _14;
  [/app/example.cpp:16:5 discrim 3] # DEBUG BEGIN_STMT
  [/app/example.cpp:16:5 discrim 3] _16 = b.1_46 + 1;
  [/app/example.cpp:16:5 discrim 3] b_lsm.11_26 = _16;
  [/app/example.cpp:16:17 discrim 1] # DEBUG BEGIN_STMT
  [/app/example.cpp:16:17 discrim 1] if (_16 <= 2)
    goto <bb 10>; [89.00%]
  else
    goto <bb 7>; [11.00%]

  <bb 10> [local count: 850510901]:
  goto <bb 6>; [100.00%]

  <bb 7> [local count: 118111600]:
  # b_lsm.11_36 = PHI <b_lsm.11_26(6)>
  # k__lsm.10_6 = PHI <k__lsm.10_48(6)>
  MEM[(int *)k_8 + 12B] = k__lsm.10_6;
  b = b_lsm.11_36;

Seems like LIM could in theory copy the line # but that might even confuse
people while debugging ....

I don't know what the best appoarch here really.
Just use -Og instead?

[Bug tree-optimization/108023] Incorrect line number in ASAN's report

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
LIM store-motion combines possibly multiple store locations into a single one,
and I agree it's possibly confusing to assign the location to the real store in
this way.