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.

Reply via email to