[Bug sanitizer/108963] New: ASAN produces wrong line number in the report

[Bug sanitizer/108963] New: ASAN produces wrong line number in the report

[shaohua.li at inf dot ethz.ch]

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

            Bug ID: 108963
           Summary: ASAN produces wrong line number in the 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, ASAN at -O1 and above always produces the wrong line
number. I've found quite some cases that have this issue.

Compiler explorer: https://godbolt.org/z/hscP9T78M

% cat a.c
union a {
  int b;
};
char c;
int d;
static long e(int *f) {
  for (; c <= 1;c++)
    *(f + 1) |= 2;
  return 0;
}
int main() {
  union a g = {};
  e(&d);
  &g;
}
%
% gcc-tk -O0 -fsanitize=address a.c && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000404184
at pc 0x0000004011d6 bp 0x7ffea18cbe60 sp 0x7ffea18cbe58
READ of size 4 at 0x000000404184 thread T0
    #0 0x4011d5 in e /a.c:8
    #1 0x4012f1 in main /a.c:13
...
% 
% gcc-tk -O1 -fsanitize=address a.c && ./a.out
=================================================================
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000404144
at pc 0x000000401289 bp 0x7ffff4114850 sp 0x7ffff4114848
READ of size 4 at 0x000000404144 thread T0
    #0 0x401288 in main /a.c:12
...
%

Maybe a fundunmentally similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023

[Bug sanitizer/108963] ASAN produces wrong line number in the report

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-02
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108023
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Yes, I can see it's very similar to the other problem as I can see a LIM
happening in the output:

  <bb 3> [local count: 955630224]:
  d__lsm.8_9 = MEM[(int *)[pr108963.c:13:3] &d + 4B];
  _18 = c.3_12 + 1;
  ivtmp.12_23 = (unsigned char) _18;

  <bb 4> [local count: 8687547547]:
  # d__lsm.8_5 = PHI <[pr108963.c:8:14] _4(4), d__lsm.8_9(3)>
  # ivtmp.12_3 = PHI <ivtmp.12_17(4), ivtmp.12_23(3)>
  [pr108963.c:8:14] _4 = d__lsm.8_5 | 2;
  [pr108963.c:7:12 discrim 1] ivtmp.12_17 = ivtmp.12_3 + 1;
  [pr108963.c:7:12 discrim 1] if (ivtmp.12_17 != 3)
    goto <bb 4>; [89.00%]
  else
    goto <bb 5>; [11.00%]