https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to rguent...@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.
