[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #17)
> On Thu, 21 Mar 2024, ubizjak at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
> > 
> > --- Comment #16 from Uro? Bizjak <ubizjak at gmail dot com> ---
> > (In reply to Richard Biener from comment #13)
> > > The original testcase is fixed, appearantly slapping 'extern' on the int
> > > makes it not effective.
> > > 
> > > Possibly better amend the
> > > 
> > >   if (VAR_P (inner) && DECL_HARD_REGISTER (inner))
> > >     return;
> > > 
> > > check though.  As indicated my fix fixed only VAR_DECL cases, there's
> > > still pointer-based accesses (MEM_REF) to consider.  So possibly even
> > > the following is necessary
> > 
> > I must admit that to create the patch from Comment #11 I just mindlessly
> > searched for DECL_THREAD_LOCAL_P in asan.cc and amended the location with
> > ADDR_SPACE_GENERIC_P check.
> 
> It might be that the DECL_THREAD_LOCAL_P handling is similarly broken
> in that
> 
> int foo (int *p)
> {
>   return *p;
> }

No, that is not broken.  __thread/thread_local is something that applies solely
to variables.  If you take address of a TLS variable, the result is a normal
address space pointer even if TLS uses separate address spaces.  Pointer to TLS
var is e.g. on x86-64 load from %gs:0 with offset added to it, while load/store
of a TLS var is load/store from %gs:offset.
So, we actually wouldn't need to punt on DECL_THREAD_LOCAL_P variables, we can
just check their addresses.
We actually don't insert red zones in between the TLS var, so doing it wouldn't
make significant sense.