https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 31 May 2024, law at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115298 > > --- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> --- > What still doesn't make sense is why nds32 would be special here. It doesn't > do anything special with flag_delete_null_pointer_checks and I don't think it > uses any of the address space hooks. So why does nds32 behave differently > than > x86? /* Implement TARGET_OPTION_OPTIMIZATION_TABLE. */ static const struct default_options nds32_option_optimization_table[] = { #if TARGET_LINUX_ABI == 0 /* Disable -fdelete-null-pointer-checks by default in ELF toolchain. */ { OPT_LEVELS_ALL, OPT_fdelete_null_pointer_checks, NULL, 0 }, #endif that's in common/config/nds32/nds32-common.cc, a place to easily overlook. So it should be nds32-elf only. And yeah, points-to should use TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID but since it tracks pointers across integer conversions we have to decide on integer zero as well where we do not know what address-space is affected. I guess we could use the default address space and try to be clever with ADDR_SPACE_CONVERT. So points-to only checks flag_delete_null_pointer_checks at the moment.