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

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

[marxin at gcc dot gnu.org]

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

            Bug ID: 97172
           Summary: [11 Regression] ICE: tree code ‘ssa_name’ is not
                    supported in LTO streams since
                    r11-3303-g6450f07388f9fe57
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Starting from the revision libgexiv2 package fails:

$ cat gexiv2.i
int main_argc;
int main(char argv[main_argc + 1]) {}

$ gcc gexiv2.i -c -flto
during IPA pass: modref
gexiv2.i:2:1: internal compiler error: tree code ‘ssa_name’ is not supported in
LTO streams
    2 | int main(char argv[main_argc + 1]) {}
      | ^~~
0xc3c2ec lto_write_tree
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:554
0xc3c2ec lto_output_tree_1
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:592
0xc44c69 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:892
0xc45bdd lto_output_tree(output_block*, tree_node*, bool, bool)
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:1853
0xc3b55c write_global_stream
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:2846
0xc48726 lto_output_decl_state_streams(output_block*, lto_out_decl_state*)
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:2893
0xc48726 produce_asm_for_decls()
        /home/marxin/Programming/gcc/gcc/lto-streamer-out.c:3287
0xcc4802 write_lto
        /home/marxin/Programming/gcc/gcc/passes.c:2624
0xcc4802 ipa_write_summaries_1
        /home/marxin/Programming/gcc/gcc/passes.c:2685
0xcc4802 ipa_write_summaries()
        /home/marxin/Programming/gcc/gcc/passes.c:2740
0x97b61d ipa_passes
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2689
0x97b61d symbol_table::compile()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2776
0x97d652 symbol_table::compile()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2756
0x97d652 symbol_table::finalize_compilation_unit()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:3021
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |11.0
      Known to work|                            |10.2.0
   Last reconfirmed|                            |2020-09-23
      Known to fail|                            |11.0
     Ever confirmed|0                           |1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely a missed DECL_EXPR.

[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]

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

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The ICE triggers when streaming the main_argc used in the variable bound
expression in char argv[main_argc + 1].  The bound is included in the attribute
access added to the declaration of main by the C front end:

 <ssa_name 0x7fffea801cf0
    type <integer_type 0x7fffea8105e8 int public SI
        size <integer_cst 0x7fffea7f7f18 constant 32>
        unit-size <integer_cst 0x7fffea7f7f30 constant 4>
        align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7fffea8105e8 precision:32 min <integer_cst 0x7fffea7f7ed0 -2147483648> max
<integer_cst 0x7fffea7f7ee8 2147483647>
        pointer_to_this <pointer_type 0x7fffea8189d8>>
    visited
    def_stmt main_argc.0_1 = main_argc;
    version:1>

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

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Martin,
the infor about ipa pass being modref is stale.  It happens during the final
streamout.

[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]

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 97133 has been marked as a duplicate of this bug. ***

[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]

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
I'm not at all familiar with this part of GCC so I'm not sure what needs to be
done here.  It seems to me that the streamer is missing support for certain
trees under some conditions.  It knows how to stream SSA_NAMEs but apparently
isn't prepared for them in attributes -- I put more detail in bug 97133 comment
#4.

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |seurer at gcc dot gnu.org

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 97298 has been marked as a duplicate of this bug. ***

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vvinayag at arm dot com

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
*** Bug 97447 has been marked as a duplicate of this bug. ***

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

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Generally LTO is organized into a global stream containing types, decls etc.
and local streams containing funtion bodies and initializers.
Global stream thus can not contain references that are local to function
bodies, like SSA_NAME, beause these are not instantiated at WPA stage and thus
have no meaing.

The ICE is about SSA_NAME being refered by something that is in the global
stream. Judging from the testcase there is probably reference to variadic type
and the variadic type now has SSA_NAME in its TYPE_SIZE or so, which should not
happen.

[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]

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.)

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

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> ---
> 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.

No longer referened by something visible to the garbage collector :)
But if the attribute is linked from the decl the garbage collector
should see it.  Did you watchpoint the pointer? Perhaps the expression
is used by somehwere else and we fold/gimplify it to the version having
SSA name in it.
> 
> 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.)

This is similar to why it does not stream SSA_NAMEs. BIND_EXPR is local
to function body and thus it can not be pointed to from anything in the
global stream.  If one wants to take the random expression from funtion
body and put it into global datastrutures, one has to use
unshare_expr_without_location which strips away the pointer to blocks.

Honza

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

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
I have one more test-case that started to ICE since the same revision:

$ cat 3.i
int write_to_fftw_input_buffers_frames;
void write_to_fftw_input_buffers();

void write_to_fftw_input_buffers(short buf[write_to_fftw_input_buffers_frames *
2]) {
}

$ gcc -flto -O2 3.i -shared -fPIC
lto1: internal compiler error: Segmentation fault
0xc9f3df crash_signal
        /home/marxin/Programming/gcc/gcc/toplev.c:330
0x7ffff7889d1f ???
       
/usr/src/debug/glibc-2.32-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb40091 stream_read_tree_ref(lto_input_block*, data_in*)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1832
0xec7319 lto_input_ts_exp_tree_pointers
        /home/marxin/Programming/gcc/gcc/tree-streamer-in.c:905
0xec7319 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
        /home/marxin/Programming/gcc/gcc/tree-streamer-in.c:1087
0xb3fa59 lto_read_tree_1
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1702
0xb4013d lto_read_tree
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1743
0xb4013d lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1884
0xb403d7 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*, bool)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1772
0xb40451 lto_input_tree(lto_input_block*, data_in*)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1899
0xb424cb streamer_read_chain
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1334
0xb424cb input_function
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1364
0xb424cb lto_read_body_or_constructor
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1623
0x86eeed cgraph_node::get_untransformed_body()
        /home/marxin/Programming/gcc/gcc/cgraph.c:3936
0x87ad2d cgraph_node::expand()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:1800
0x87c32f expand_all_functions
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:1997
0x87c32f symbol_table::compile()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2361
0x7d1d25 lto_main()
        /home/marxin/Programming/gcc/gcc/lto/lto.c:653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

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

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
unsharing the tree is correct AFAICS, avoiding the attribute for VLA types
would likely also be good (are those handled in any reasonable way?).  Note
nothing will update those SSA names so they should not creep in there in the
first place (and do so from gimplifying).

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 98068 has been marked as a duplicate of this bug. ***

[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]

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

--- Comment #14 from Martin Sebor <msebor at gcc dot gnu.org> ---
I submitted a simple patch to do the unsharing as the first step toward fixing
this bug here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559770.html

I'm not sure I understand correctly what you mean by "avoiding the attribute
for VLA types would likely also be good (are those handled in any reasonable
way?)"  As I explain in the thread at the link above, the attribute is strictly
only strictly necessary for the most significant bound of a VLA parameter.  The
other bounds are encoded in the type and so don't also need to be duplicated in
the attribute (it's just more convenient/faster that way).  But even with that
change,  and with the unsharing (or with the SAVE_EXPR around it), I'd expect
the most significant bound to still be a problem for the streamer since it will
still contain the unsupported nodes.  Not SSA_NAMEs but some of the others.

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

[hubicka at ucw dot cz]

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

--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> ---
> I'm not sure I understand correctly what you mean by "avoiding the attribute
> for VLA types would likely also be good (are those handled in any reasonable
> way?)"  As I explain in the thread at the link above, the attribute is strictly
> only strictly necessary for the most significant bound of a VLA parameter.  The
> other bounds are encoded in the type and so don't also need to be duplicated in
> the attribute (it's just more convenient/faster that way).  But even with that
> change,  and with the unsharing (or with the SAVE_EXPR around it), I'd expect
> the most significant bound to still be a problem for the streamer since it will
> still contain the unsupported nodes.  Not SSA_NAMEs but some of the others.

What kind of other nodes you see?  Basically everything that makes sense
out of the function body can be streamed.  You can not refer also to
local scopes of the function, ipa-prop has unshare_expr_without_location

[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]

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

--- Comment #16 from Martin Sebor <msebor at gcc dot gnu.org> ---
The ICE in pr97133 mentions BIND_EXPR.  It's still there, even after unsharing:

$ gcc -O2 -S -flto -shared -fPIC /src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c
during IPA pass: modref
/src/gcc/master/gcc/testsuite/gcc.dg/pr88701.c:18:1: internal compiler error:
tree code ‘bind_expr’ is not supported in LTO streams

The unsharing also doesn't remove the ICE in pr97298.  The SSA_NAME is replaced
by a STATEMENT_LIST:

$ gcc -O2 -S -flto -shared -fPIC
/src/gcc/master/gcc/testsuite/gcc.dg/atomic/pr65345-4.c
during IPA pass: modref
/src/gcc/master/gcc/testsuite/gcc.dg/atomic/pr65345-4.c:58:1: internal compiler
error: tree code ‘statement_list’ is not supported in LTO streams

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

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well - you're the first to add nontrivial (non-constant) trees to attributes. 
In GIMPLE all effects are supposed to be reflected in the IL and thus things
like
variable TYPE_SIZE or TYPE_MIN/MAX_VALUE are actually gimplified with code
generated during that inserted at the respective DECL_EXPR (which is where
gimplification is triggered from for the types).

Honestly I am not sure what you think you can do with arbitrary expressions
in an attribute down the GIMPLE pipeline given there's no connection to
actual variable values.  That said, the idea of sticking this additional
information in attributes in form of some random plain tree expressions
doesn't work.  You'd have to sanitize them at least if, say, expressions
based purely on other formal function arguments is what you are after.

That would for example be done by unsharing the expressions without locations
which you could try.  But for example the PR97133 case,

    attributes <tree_list 0x7fffea94d8e8
        purpose <identifier_node 0x7fffea937910 arg spec>
        value <tree_list 0x7fffea94d898
            value <string_cst 0x7fffea936860 constant "[$]\000">
            chain <tree_list 0x7fffea94d870
                value <eq_expr 0x7fffea94d758 type <integer_type 0x7fffea8105e8
int>
                    side-effects
                    arg:0 <c_maybe_const_expr 0x7fffea94d730 type <pointer_type
0x7fffea930c78>
                        side-effects
                        arg:0 <compound_expr 0x7fffea94d708 type <void_type
0x7fffea810f18 void>
                            side-effects arg:1 <bind_expr 0x7fffea949330>>
                        arg:1 <compound_literal_expr 0x7fffea936780 type
<pointer_type 0x7fffea930c78>
                            side-effects arg:0 <decl_expr 0x7fffea936760>>>
                    arg:1 <integer_cst 0x7fffea94f030 constant 0>

certainly is missing constant evaluation (I can bet whatever is supposed
to consume the access attributes gives up on the above anyway).
C_MAYBE_CONST_EXPR is a frontend specific tree code and thus it shouldn't
even survive GENERICization.

So I would stronly suggest to revisit the way you try to record "every
information for accesses" for GCC 12 and for GCC 11 restrict the information
to CONSTANT_CLASS_P trees.

[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]

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

--- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> ---
Let me explain how this works.  The VLA bounds in function parameters are used
in two ways:
1) in the front end, to check function redeclarations involving arrays and VLAs
for equivalence,
2) in the middle end, to check function calls for out of bounds accesses.

As an example of (1) consider the following declarations of function f():

  void f (int X, int, int A[X], int B[foo()]);
and
  void f (int, int J, int A[J], int B[foo() + 1]);

The bounds in the parameters A and B are different and we'd like them
diagnosed.  The bound X is the first parameter in the first declaration of f
but J is the second parameter in the second f().  Because the bounds are also
parameters, we use their positions in the argument list to determine that they
don't match.

Likewise, the bound foo() in B is different from foo() + 1, but because neither
is a parameter the only way to determine whether they match is by comparing
them for equivalence.  The code uses operand_equal_p(..., OEP_LEXICOGRAPHIC).

(2) is done only for bounds that are parameters.  Other bounds are not used for
anything, but they're still stored in the attributes so they can be compared in
the redeclarations.

Since the "complex" bounds aren't used after the front end is done with them,
unless there's a way to remove them at some point after the front end is done
(or set them to NULL or something), the LTO streaming code could ignore them
instead of asserting on them.  Alternatively, instead of storing them in their
tree form they could be stored as strings instead.  I list these in the order
of my preference for GCC 11.

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

[Jan Hubicka]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
> 
> --- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Let me explain how this works.  The VLA bounds in function parameters are used
> in two ways:
> 1) in the front end, to check function redeclarations involving arrays and VLAs
> for equivalence,
> 2) in the middle end, to check function calls for out of bounds accesses.
> 
> As an example of (1) consider the following declarations of function f():
> 
>   void f (int X, int, int A[X], int B[foo()]);
> and
>   void f (int, int J, int A[J], int B[foo() + 1]);
> 
> The bounds in the parameters A and B are different and we'd like them
> diagnosed.  The bound X is the first parameter in the first declaration of f
> but J is the second parameter in the second f().  Because the bounds are also
> parameters, we use their positions in the argument list to determine that they
> don't match.
> 
> Likewise, the bound foo() in B is different from foo() + 1, but because neither
> is a parameter the only way to determine whether they match is by comparing
> them for equivalence.  The code uses operand_equal_p(..., OEP_LEXICOGRAPHIC).
> 
> (2) is done only for bounds that are parameters.  Other bounds are not used for
> anything, but they're still stored in the attributes so they can be compared in
> the redeclarations.
> 
> Since the "complex" bounds aren't used after the front end is done with them,
> unless there's a way to remove them at some point after the front end is done
> (or set them to NULL or something), the LTO streaming code could ignore them
> instead of asserting on them.  Alternatively, instead of storing them in their

free_lang_data should a good place to free them. In general we should
avoid storing things to IL that are not useful to middle end and keep
them there till LTO streaming.  Even if it does not make LTO streaming
to ICE it stll consumes memory, disk space and compile time. 

Honza
> tree form they could be stored as strings instead.  I list these in the order
> of my preference for GCC 11.

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

[hubicka at ucw dot cz]

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

--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
> 
> --- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Let me explain how this works.  The VLA bounds in function parameters are used
> in two ways:
> 1) in the front end, to check function redeclarations involving arrays and VLAs
> for equivalence,
> 2) in the middle end, to check function calls for out of bounds accesses.
> 
> As an example of (1) consider the following declarations of function f():
> 
>   void f (int X, int, int A[X], int B[foo()]);
> and
>   void f (int, int J, int A[J], int B[foo() + 1]);
> 
> The bounds in the parameters A and B are different and we'd like them
> diagnosed.  The bound X is the first parameter in the first declaration of f
> but J is the second parameter in the second f().  Because the bounds are also
> parameters, we use their positions in the argument list to determine that they
> don't match.
> 
> Likewise, the bound foo() in B is different from foo() + 1, but because neither
> is a parameter the only way to determine whether they match is by comparing
> them for equivalence.  The code uses operand_equal_p(..., OEP_LEXICOGRAPHIC).
> 
> (2) is done only for bounds that are parameters.  Other bounds are not used for
> anything, but they're still stored in the attributes so they can be compared in
> the redeclarations.
> 
> Since the "complex" bounds aren't used after the front end is done with them,
> unless there's a way to remove them at some point after the front end is done
> (or set them to NULL or something), the LTO streaming code could ignore them
> instead of asserting on them.  Alternatively, instead of storing them in their

free_lang_data should a good place to free them. In general we should
avoid storing things to IL that are not useful to middle end and keep
them there till LTO streaming.  Even if it does not make LTO streaming
to ICE it stll consumes memory, disk space and compile time. 

Honza
> tree form they could be stored as strings instead.  I list these in the order
> of my preference for GCC 11.

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

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 1 Dec 2020, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
> 
> --- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172
> > 
> > --- Comment #18 from Martin Sebor <msebor at gcc dot gnu.org> ---
> > Let me explain how this works.  The VLA bounds in function parameters are used
> > in two ways:
> > 1) in the front end, to check function redeclarations involving arrays and VLAs
> > for equivalence,
> > 2) in the middle end, to check function calls for out of bounds accesses.
> > 
> > As an example of (1) consider the following declarations of function f():
> > 
> >   void f (int X, int, int A[X], int B[foo()]);
> > and
> >   void f (int, int J, int A[J], int B[foo() + 1]);
> > 
> > The bounds in the parameters A and B are different and we'd like them
> > diagnosed.  The bound X is the first parameter in the first declaration of f
> > but J is the second parameter in the second f().  Because the bounds are also
> > parameters, we use their positions in the argument list to determine that they
> > don't match.
> > 
> > Likewise, the bound foo() in B is different from foo() + 1, but because neither
> > is a parameter the only way to determine whether they match is by comparing
> > them for equivalence.  The code uses operand_equal_p(..., OEP_LEXICOGRAPHIC).
> > 
> > (2) is done only for bounds that are parameters.  Other bounds are not used for
> > anything, but they're still stored in the attributes so they can be compared in
> > the redeclarations.
> > 
> > Since the "complex" bounds aren't used after the front end is done with them,
> > unless there's a way to remove them at some point after the front end is done
> > (or set them to NULL or something), the LTO streaming code could ignore them
> > instead of asserting on them.  Alternatively, instead of storing them in their
> 
> free_lang_data should a good place to free them. In general we should
> avoid storing things to IL that are not useful to middle end and keep
> them there till LTO streaming.  Even if it does not make LTO streaming
> to ICE it stll consumes memory, disk space and compile time. 

The frontend needs to make sure no frontend specific tree codes leak
into GENERIC so GENERICization is the place where the FE should clear
those.  FLD is too late and doing it there would be a hack.

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

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška <marxin at gcc dot gnu.org> ---
Just for the record, 'cava' package is also affected by this issue.

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #22 from Martin Sebor <msebor at gcc dot gnu.org> ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562318.html

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2020-09-23 00:00:00         |2021-1-22
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #23 from ktkachov at gcc dot gnu.org ---
I also see this in gcc.dg/atomic/pr65345-4.c on aarch64

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Completely untested routine that would allow unsharing expressions including
SAVE_EXPRs/TARGET_EXPRs, obviously then the result couldn't be used in the IL
for code generation, only for warnings.
It is basically unshare_expr, which afterwards when it sees SAVE_EXPRs or
TARGET_EXPRs
for the first time copies those and unshares their subtrees and when it sees
those
second and following time just reuses what it did before.

/* Helper function for fully_unshare_expr.  Copy SAVE_EXPRs and TARGET_EXPRs
   including their subtrees, but do that only once.  */

static tree
fully_unshare_expr_r (tree *tp, int *walk_subtrees, void *data)
{
  enum tree_code code = TREE_CODE (*tp);
  if (code == SAVE_EXPR || code == TARGET_EXPR)
    {
      hash_map<tree, tree> **map = (hash_map<tree, tree> **) data;
      *walk_subtrees = 0;
      if (*map == NULL)
        *map = new hash_map<tree, tree>;
      tree &cached = (*map)->get_or_insert (*tp);
      if (cached)
        {
          *tp = cached;
          return NULL_TREE;
        }
      tree t = copy_node (*tp);
      cached = t;
      int len = 1;
      if (code == TARGET_EXPR)
        len = (TREE_OPERAND (t, 3) == TREE_OPERAND (t, 1)) ? 3 : 4;
      for (int i = 0; i < len; i++)
        {
          TREE_OPERAND (t, i) = unshare_expr (TREE_OPERAND (t, i));
          walk_tree (&TREE_OPERAND (t, i), fully_unshare_expr_r, data, NULL);
        }
      if (len == 3)
        TREE_OPERAND (t, 3) = TREE_OPERAND (t, 1);
      return NULL_TREE;
    }
  /* Stop at types, decls, constants like copy_tree_r.  */
  else if (TREE_CODE_CLASS (code) == tcc_type
           || TREE_CODE_CLASS (code) == tcc_declaration
           || TREE_CODE_CLASS (code) == tcc_constant)
    *walk_subtrees = 0;
  return NULL_TREE;
}

/* Like unshare_expr, but unshare also SAVE_EXPRs and TARGET_EXPRs.
   After unsharing SAVE_EXPRs and TARGET_EXPRs, the returned expression
   shouldn't be gimplified into the IL, as that could mean evaluating
   side-effects multiple times.  */

tree
fully_unshare_expr (tree expr)
{
  hash_map <tree, tree> *map = NULL;
  expr = unshare_expr (expr);
  walk_tree (&expr, fully_unshare_expr_r, &map, NULL);
  delete map;
  return expr;
}

[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]

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

--- Comment #25 from Martin Sebor <msebor at gcc dot gnu.org> ---
Patch v3: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564411.html

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:0718336a5284dd5b40fd6691a94d6be93a80f279

commit r11-7018-g0718336a5284dd5b40fd6691a94d6be93a80f279
Author: Martin Sebor <msebor@redhat.com>
Date:   Mon Feb 1 09:08:21 2021 -0700

    Reset front end trees before they make it into the middle end (PR
middle-end/97172).

    gcc/ChangeLog:

            PR middle-end/97172
            * attribs.c (attr_access::free_lang_data): Define new function.
            * attribs.h (attr_access::free_lang_data): Declare new function.

    gcc/c/ChangeLog:

            PR middle-end/97172
            * c-decl.c (free_attr_access_data): New function.
            (c_parse_final_cleanups): Call free_attr_access_data.

    gcc/testsuite/ChangeLog:

            PR middle-end/97172
            * gcc.dg/pr97172.c: New test.

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Martin Sebor <msebor at gcc dot gnu.org> ---
Fixed.

[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]

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

--- Comment #28 from Martin Sebor <msebor at gcc dot gnu.org> ---
Follow-on patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565545.html

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:3599ecb6a0145a428def5314d2d67d2e5a88f3c4

commit r11-7301-g3599ecb6a0145a428def5314d2d67d2e5a88f3c4
Author: Martin Sebor <msebor@redhat.com>
Date:   Fri Feb 19 11:06:06 2021 -0700

    PR c/97172 - ICE: tree code 'ssa_name' is not supported in LTO streams

    gcc/ChangeLog:

            PR c/97172
            * attribs.c (init_attr_rdwr_indices): Guard vblist use.
            (attr_access::free_lang_data): Remove a spurious test.

    gcc/testsuite/ChangeLog:

            PR c/97172
            * gcc.dg/pr97172.c: Add test cases.

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

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #30 from Martin Liška <marxin at gcc dot gnu.org> ---
I still cannot build the affected package:

$ cat exiv.i
int main_argc;

void
foo(char[main_argc + 1]) {}

$ gcc exiv.i -flto -O2 -shared -fPIC
lto1: internal compiler error: Segmentation fault
0xd3de6a crash_signal
        /home/marxin/Programming/gcc/gcc/toplev.c:327
0xbc84f4 stream_read_tree_ref(lto_input_block*, data_in*)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1830
0xf8a648 lto_input_ts_exp_tree_pointers
        /home/marxin/Programming/gcc/gcc/tree-streamer-in.c:905
0xf8a648 streamer_read_tree_body(lto_input_block*, data_in*, tree_node*)
        /home/marxin/Programming/gcc/gcc/tree-streamer-in.c:1087
0xbc7c49 lto_read_tree_1
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1700
0xbc85a1 lto_read_tree
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1741
0xbc85a1 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1882
0xbc8857 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned
int*, bool)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1770
0xbc88df lto_input_tree(lto_input_block*, data_in*)
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1897
0xbcab0f streamer_read_chain
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1335
0xbcab0f input_function
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1365
0xbcab0f lto_read_body_or_constructor
        /home/marxin/Programming/gcc/gcc/lto-streamer-in.c:1621
0x8cfd91 cgraph_node::get_untransformed_body()
        /home/marxin/Programming/gcc/gcc/cgraph.c:3940
0x8dbfe1 cgraph_node::expand()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:1798
0x8dd73e expand_all_functions
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:1995
0x8dd73e symbol_table::compile()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2359
0x8dd73e symbol_table::compile()
        /home/marxin/Programming/gcc/gcc/cgraphunit.c:2270
0x8260c4 lto_main()
        /home/marxin/Programming/gcc/gcc/lto/lto.c:653
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

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

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like DECL_ARGUMENTS of the function refers to SSA names.

(gdb) p function->function_decl.arguments 
$1 = <parm_decl 0x7ffff66b1080>
(gdb) p debug_tree ($1)
 <parm_decl 0x7ffff66b1080 D.1943
    type <pointer_type 0x7ffff658ec78
        type <integer_type 0x7ffff65833f0 char public QI
            size <integer_cst 0x7ffff656adc8 constant 8>
            unit-size <integer_cst 0x7ffff656ade0 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set 0 canonical-type
0x7ffff65833f0 precision:8 min <integer_cst 0x7ffff656ae10 -128> max
<integer_cst 0x7ffff656ae40 127>
            pointer_to_this <pointer_type 0x7ffff658ec78>>
        unsigned DI
        size <integer_cst 0x7ffff656acd8 constant 64>
        unit-size <integer_cst 0x7ffff656acf0 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff658ec78 reference_to_this <reference_type 0x7ffff669a540>>
    unsigned decl_0 DI t.i:4:5 size <integer_cst 0x7ffff656acd8 64> unit-size
<integer_cst 0x7ffff656acf0 8>
    align:64 warn_if_not_align:0 context <function_decl 0x7ffff66b4000 foo>
    attributes <tree_list 0x7ffff669c8c0
        purpose <identifier_node 0x7ffff66a0780 arg spec>
        value <tree_list 0x7ffff669c870
            value <string_cst 0x7ffff667cf60 constant "[$]\000">
            chain <tree_list 0x7ffff669c848
                value <plus_expr 0x7ffff669c7d0 type <integer_type
0x7ffff65835e8 int>

                    arg:0 <ssa_name 0x7ffff65755e8 type <error_mark
0x7ffff656acc0>
                        nothrow
                        def_stmt 
                        version:1 in-free-list>
                    arg:1 <integer_cst 0x7ffff6588090 constant 1>
                    t.i:4:20 start: t.i:4:10 finish: t.i:4:22>>>> arg-type
<pointer_type 0x7ffff658ec78>>

the "arg spec" attribute refers to a released SSA name.

[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]

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

--- Comment #32 from Martin Sebor <msebor at gcc dot gnu.org> ---
The "arg spec" attribute also needs to be removed from the function arguments. 
Let me take care of that.

[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]

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

--- Comment #33 from Martin Sebor <msebor at gcc dot gnu.org> ---
Another fix:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565736.html

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #34 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:ea5a82df9ba0c9d23e386290d24fc920968a8695

commit r11-7360-gea5a82df9ba0c9d23e386290d24fc920968a8695
Author: Martin Sebor <msebor@redhat.com>
Date:   Wed Feb 24 08:57:59 2021 -0700

    PR middle-end/97172 - ICE: tree code 'ssa_name' is not supported in LTO
streams

    gcc/ChangeLog:
            PR middle-end/97172
            * attribs.c (attr_access::free_lang_data): Clear attribute arg spec
            from function arguments.

    gcc/c/ChangeLog:

            PR middle-end/97172
            * c-decl.c (free_attr_access_data): Clear attribute arg spec.

    gcc/testsuite/ChangeLog:

            PR middle-end/97172
            * gcc.dg/pr97172-2.c: New test.

[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]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #35 from Martin Sebor <msebor at gcc dot gnu.org> ---
r11-7360 clears the bounds in the arg spec attribute.  Hopefully this is the
last fix.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Christophe Lyon <clyon@gcc.gnu.org>:

https://gcc.gnu.org/g:01c2ce169a05c8e59c4182796876f7e0754e4b5c

commit r11-7393-g01c2ce169a05c8e59c4182796876f7e0754e4b5c
Author: Christophe Lyon <christophe.lyon@linaro.org>
Date:   Thu Feb 25 15:55:28 2021 +0000

    PR middle-end/97172 - ICE: tree code 'ssa_name' is not supported in LTO
streams

    Skip test when -shared is not supported.

    2021-02-25  Christophe Lyon  <christophe.lyon@linaro.org>

            gcc/testsuite/
            PR middle-end/97172
            * gcc.dg/pr97172-2.c: Add dg-require-effective-target shared.