https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89692
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The type that is not processed by free_lang_data_in_type is created with:
#1 0x000000000180f42c in copy_node (node=<record_type 0x7fffea94c9d8 ln>) at
../../gcc/tree.c:1183
#2 0x000000000182555e in build_distinct_type_copy (type=<record_type
0x7fffea94c9d8 ln>) at ../../gcc/tree.c:6532
#3 0x00000000018256d7 in build_variant_type_copy (type=<record_type
0x7fffea94c9d8 ln>) at ../../gcc/tree.c:6566
#4 0x00000000018254c4 in build_aligned_type (type=<record_type 0x7fffea94c9d8
ln>, align=8) at ../../gcc/tree.c:6517
#5 0x0000000000fa6007 in gimple_fold_builtin_memory_op (gsi=0x7fffffffcfb0,
dest=<addr_expr 0x7fffea95a4e0>, src=<addr_expr 0x7fffea95a580>,
endp=0) at ../../gcc/gimple-fold.c:1010
#6 0x0000000000fad8c7 in gimple_fold_builtin (gsi=0x7fffffffcfb0) at
../../gcc/gimple-fold.c:3851
#7 0x0000000000fafc2b in gimple_fold_call (gsi=0x7fffffffcfb0, inplace=false)
at ../../gcc/gimple-fold.c:4357
#8 0x0000000000fb2b4d in fold_stmt_1 (gsi=0x7fffffffcfb0, inplace=false,
valueize=0xfb326c <no_follow_ssa_edges(tree_node*)>)
at ../../gcc/gimple-fold.c:5022
#9 0x0000000000fb32f4 in fold_stmt (gsi=0x7fffffffcfb0) at
../../gcc/gimple-fold.c:5177
#10 0x000000000210bee5 in lower_stmt (gsi=0x7fffffffcfb0, data=0x7fffffffd150)
at ../../gcc/gimple-low.c:387
We do free_lang_data_in_type the 0x7fffea94c9d8 variant.
Note, the gimple_fold_builtin_memory_op code actually doesn't insert that type
into the IL at all, it builds a MEM_REF with that type, but later throws it
away and builds a different MEM_REF with a different type (instead of struct ln
with 8-bit alignment a char array of the right size).
Now, even if it would keep it in the IL, it could be in some statement that is
optimized away before fld, or it could be build_aligned_type called from the FE
and again not kept in the IL in any way.
Then we free lang data and then comes SRA and calls build_aligned_type
(0x7fffea94c9d8, 8) - that is again the original type that got through fld, but
build_aligned_type looks through type variants and finds ah, we have one
aligned variant here already and returns that.
So, this is not a SRA bug, but free_lang_data, it needs to
free_lang_data_in_type also all type variants of all types it is processing,
otherwise any time after free_lang_data anything uses any of the build*type
tree.c function a non-free_lang_data_in_type processed type can reappear in the
IL.
