[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11

["dmalcolm at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.