[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172

--- Comment #9 from Martin Sebor <msebor at gcc dot gnu.org> ---
To each declaration of a function with one or more VLA parameters the C front
end adds attribute access that includes the expressions that specify the
top-level variable bounds.  So the declaration of main() in

  int main_argc;
  int main(char argv[main_argc + 1]) {}

will have attribute access attached to it that references the main_argc + 1
expression:

 <tree_list 0x7fffea924f28
    value <tree_list 0x7fffea924d20
        value <plus_expr 0x7fffea924c80 type <integer_type 0x7fffea8105e8 int>
            arg:0 <var_decl 0x7ffff7ffbb40 n>
            arg:1 <integer_cst 0x7fffea815090 constant 1>
            /build/tmp/z.c:2:48 start: /build/tmp/z.c:2:46 finish:
/build/tmp/z.c:2:50>>>

The expression is then used by the middle end to check calls to these functions
to make sure the VLA has the number of elements indicated by the expression.

What seems to be happening in this PR is that the PLUS_EXPR is actually garbage
collected by the middle end and ends up looking like an SSA_NAME:

 <tree_list 0x7fffea924ed8
    value <tree_list 0x7fffea924cf8
        value <plus_expr 0x7fffea924c80 type <integer_type 0x7fffea8105e8 int>

            arg:0 <ssa_name 0x7fffea801cf0 type <error_mark 0x7fffea7f7cc0>
                nothrow
                def_stmt 
                version:1 in-free-list>
            arg:1 <integer_cst 0x7fffea815090 constant 1>
            /build/tmp/z.c:2:55 start: /build/tmp/z.c:2:45 finish:
/build/tmp/z.c:2:57>>>

Unsharing the expression in the front end, before it's added to the attribute,
prevents this ICE, but I wouldn't expect that to be necessary.  From what
little I know about how garbage collection in GCC works I would think nodes
would only become eligible for collection after they were no longer referenced.

Unsharing also doesn't solve the problem in pr97133 where the expression that
causes the LTO ICE is a BIND_EXPR (bug 97133 comment #4 has more detail).  Why
is BIND_EXPR not handled by the streamer?  Is it because it references the
function's parameter?  Would that make other expressions that reference
function parameters a problem too? (In my limited testing most don't seem to
be.)