http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59258
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 31289 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31289&action=edit gcc49-pr59258.patch Untested fix for the dwarf2out.c ICE. The problem is that -fsanitize=null will preserve in location_t of ADDR_EXPR a reference to a block, but the BLOCK isn't referenced from anywhere else and thus during ggc_collect removed as unused, then dwarf2out.c allocates the same GC memory for something else and finally when processing the ADDR_EXPR the old BLOCK is modified again. Either of the hunks in the patch should fix this, IMHO we want both, it doesn't make sense to provide any locus for the ADDR_EXPR of the string in the static ctor, and as ubsan_create_data compares loc to UNKNOWN_LOCATION in a bunch of places, not doing LOCATION_LOCUS there means it might not compare to UNKNOWN_LOCATION even when it actually is UNKNOWN_LOCATION just with some non-NULL associated block. Perhaps my * ubsan.c (ubsan_source_location): Don't crash on unknown locations. change will be unneeded now?