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.
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?
Jakub
