On Thu, Oct 8, 2015 at 11:10 PM, Richard Henderson <r...@redhat.com> wrote: > On 10/08/2015 09:20 PM, Richard Biener wrote: >> >> On Thu, Oct 8, 2015 at 6:59 AM, Richard Henderson <r...@redhat.com> wrote: >>> >>> * target.def (TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): New. >>> * targhooks.h (default_addr_space_zero_address_valid): Declare. >>> * targhooks.c (default_addr_space_zero_address_valid): New. >>> * doc/tm.texi, doc/tm.texi.in: Update. >>> * config/i386/i386.c (ix86_addr_space_zero_address_valid): New. >>> (TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): New. >>> * fold-const.c (const_unop) [ADDR_SPACE_CONVERT_EXPR]: Disable >>> folding of 0 when it is a valid address for the source space. >>> * gimple.c (check_loadstore): Disable noticing dereference when >>> 0 is a valid address for the space. >> >> >> I think this is incomplete and you need to look at all places that check >> for >> flag_delete_null_pointer_checks (ick, the ubsan abuse looks >> interesting...). >> We'd best abstract that flag check somewhere, only doing the address-space >> check for ! ADDR_SPACE_GENERIC. > > > I did a fair survey of the uses of f_d_n_p_c. Most of them are tests for > explicit symbols that are weak, etc. I suppose we should probably then > check to see if the symbol is placed in a non-default address space, but in > the context of the code I was working on, that never comes up.
One I know about is tree-ssa-structalias.c:get_constraint_for_1 which treats zero address specially. A zero_address_valid_p predicate taking a pointer (type) would be nice to have to abstract those flag checks appropriately. >> I also wonder about the const_unop change - if the target address-space >> has a valid 0 but the source has not then you create a valid object >> address >> from an invalid one? > > > I guess we would, but ... what else can you do when there's no invalid > address? True ... maybe a less likely valid one? (0xfff...ff?) >> The check_loadstore change should instead have adjusted the >> flag_delete_null_pointer_checks guard in >> infer_nonnull_range_by_dereference. > > > Nope, that doesn't work. You have to wait until you see the actual MEM > being dereferenced before you can look at it's address space. Well, as we are explicitely looking for the pointer 'op' we know the address-space beforehand, no? TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (op)))? Richard. > > r~
