https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952
--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Root cause of the crash in comment #0 is an out-of-bounds memory write in the RTL dump reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set. What's happening is that gcc/read-rtl-function.c:selftest::test_loading_symbol_ref loads SRCDIR "/gcc/testsuite/selftests/symbol-ref.rtl" which contains a "(symbol_ref)" with flags with SYMBOL_FLAG_HAS_BLOCK_INFO set. Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol, which has: /* Create the extended SYMBOL_REF. */ size = RTX_HDR_SIZE + sizeof (struct block_symbol); A normal SYMBOL_REF has the RTX_HDR_SIZE plus two rtunion (which on a x86_64 host is 8 + (2 * 8) = 24 bytes), whereas a SYMBOL_REF with SYMBOL_REF_HAS_BLOCK_INFO_P () has RTX_HDR_SIZE + sizeof (struct block_symbol); (which on a x86_64 host is 8 + 32 = 40 bytes) So the reader allocates a 24-byte symbol_ref, and then this line: 1142 SYMBOL_REF_BLOCK (x) = NULL; implicitly assumes we have a 40-byte allocation, and writes zeros to whatever is in memory after the 24-byte allocation. In my tests, this happened to hit a cached INTEGER_CST for the "int" type, converting its code to 0 (ERROR_MARK), and hence chaos ensues; in particular, this leads to a crash in the garbage-collector when the pointer-walking visits the corrupted tree, and attempts to access fields for the wrong TREE_CODE. I'm testing a fix.