https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> --- 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; } is instrumented even when p is a pointer to thread local storage? But maybe that works fine and it handled in the runtime. But of course the runtime can't handle non-generic address-spaces at all unless we can convert all those addresses to ones in the generic address-space (given suitable overlap of course). > However, ASAN should back off from annotating *any* gs: prefixed address. > > I'll test your patch from Comment #13 ASAP.
