[Bug sanitizer/110099] New: GCC's Address Sanitizer misses 'stack-use-after-scope' when accessing variable from the same scope

[Bug sanitizer/110099] New: GCC's Address Sanitizer misses 'stack-use-after-scope' when accessing variable from the same scope

[egor_suvorov at mail dot ru]

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

            Bug ID: 110099
           Summary: GCC's Address Sanitizer misses 'stack-use-after-scope'
                    when accessing variable from the same scope
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: egor_suvorov at mail dot ru
                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: ---

Consider the following code:

int main() {
    struct S {
        int *x;
        ~S() { *x = 10; }
    } s;
//    {
        int x;
        s.x = &x;
//    }
}

I believe `s`'s destructor tries to access variable `x` when it is already
destroyed, so it should be a 'stack-use-after-scope' error.

GCC 12 and 13 do not seem to catch it when compiled with `-fsanitize=address`,
but Clang and Visual Studio 2019 do: https://godbolt.org/z/7MqGr8Y3r

If I uncomment curly brackets, `x` ends up in its own scope and now all three
compilers are able to detect the error. Maybe GCC calls destructors first and
marks variables as unavailable for ASan later?

[Bug sanitizer/110099] GCC's Address Sanitizer misses 'stack-use-after-scope' when accessing variable from the same scope

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-06-02
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The order of making the variable as POSION is in the wrong order and not before
the finally.

Also can be repdoceud using the attribute cleanup:
```
void g(void *a)
{
  *(int*)a = 10;
}

int main() {
  int *t __attribute__((cleanup(g)));
  int x = 0;
  t = &x;
}

```