On Wed, 5 Dec 2012, Jakub Jelinek wrote: > On Wed, Dec 05, 2012 at 05:10:56PM +0100, Richard Biener wrote: > > > This patch tries to handle bitfield accesses as if it were writes/reads > > > from the corresponding DECL_BIT_FIELD_REPRESENTATIVE. > > > Richard, does it make sense this way (the code will take ADDR_EXPR > > > of the COMPONENT_REF with the DECL_BIT_FIELD_REPRESENTATIVE and use > > > the size of the representative if it decides to instrument it. > > > > > > Fixes the first 4 asan_test.C failures. Ok for trunk? > > > > It makes sense apart from the address-taking - is this done early > > enough to not disrupt aliasing / TREE_ADDRESSABLE? Thus, before > > gimplifying? > > It is done far later than that (except for -Og and -O0 right after PRE), > but I thought that isn't a big deal, it takes address for everything > to be instrumented, and AFAIK tree-ssa-operands.c will take care of > calling mark_addressable on it if needed. Asan doesn't actually dereference > that pointer ever, all it does is compute from that address the shadow > address (addr >> 3) + (1L << 44) or similar, and dereferences that. > And for asan, we want to instrument > char p[32]; > for (int i = 0; i < n; i++) > p[i] = 0; > even when p isn't TREE_ADDRESSABLE (ditto for bitfields). So, all in all, > even if the address is taken, it will never escape because of the asan > instrumentation.
Ok. > Doesn't e.g. ivopts also cause non-addressable vars to become addressable, > if it replaces ARRAY_REFs with taking address of the array before the loop > and using MEM_REF/TARGET_MEM_REF in the loop? Yes, but it also doesn't make them escape (autopar does, for example, which is why it has to re-set points-to info ...). Richard.
