https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71962
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #6) > The difference between success and failure is due to this bit of code in > symtab.c: > > /* With !flag_delete_null_pointer_checks we assume that symbols may > bind to NULL. This is on by default on embedded targets only. > > Otherwise all non-WEAK symbols must be defined and thus non-NULL or > linking fails. Important case of WEAK we want to do well are comdats. > Those are handled by later check for definition. > > When parsing, beware the cases when WEAK attribute is added later. */ > if (!DECL_WEAK (decl) > && flag_delete_null_pointer_checks) > { > refuse_visibility_changes = true; > return true; > } > > But the address of a static local variable can never be null so the test > above is unnecessarily restrictive. The following patch relaxes the test, > letting GCC accept the test case even with -fsanitize=undefined. I didn't > spot any obvious failures in the test suite with it. -fno-delete-null-pointer-checks is an option that allows violating the C requirements and a user variable can live at address 0. That is something people need on various DSPs etc. where e.g. the data or rodata section can start at NULL. So this change is wrong. Whether automatic variables can have NULL addresses is a separate question. Now, as I said before, we could change the options handling not to force flag_delete_null_pointer_checks = 0; for the sanitizers and review the places that check flag_delete_null_pointer_checks and in most of them check also the corresponding sanitizer options. then we could on a case by case decide what is and what isn't possible.