[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Got it, if I print pointer value of streamed trees I see:

BAD:

Creating output block for jmpfuncs
     Encoding indexable  <integer_type # int>  as 0 
     Encoding indexable  <pointer_type #>  as 1 
     Encoding indexable  <pointer_type #>  as 2 
    Streaming SCC of  <addr_expr #> (0x7ffff6af78a0)
     Streaming  <addr_expr #>  to jmpfuncs
     Streaming  <string_cst #>  to jmpfuncs
     Encoding indexable  <array_type #>  as 3 
     Encoding indexable  <pointer_type #>  as 4 
    Existing SCC of  <string_cst #> (0x7ffff6ade5c8)
    Finished SCC of  <addr_expr #>

    Streaming SCC of  <integer_cst # 0> (0x7ffff6af25a0)
    Finished SCC of  <integer_cst # 0>

    Existing SCC of  <integer_cst # 0> (0x7ffff6af25a0)
    Streaming SCC of  <addr_expr #> (0x7ffff6af7900)
     Streaming  <addr_expr #>  to jmpfuncs
     Encoding indexable  <pointer_type #>  as 5 
     Encoding indexable  <function_decl # exit>  as 0 
    Finished SCC of  <addr_expr #>

    Streaming SCC of  <integer_cst # 0> (0x7ffff6af25b8)
    Finished SCC of  <integer_cst # 0>

    Existing SCC of  <integer_cst # 0> (0x7ffff6af25b8)
    Streaming SCC of  <addr_expr #> (0x7ffff6af7940)
     Streaming  <addr_expr #>  to jmpfuncs
     Encoding indexable  <var_decl # M_var>  as 0 
    Finished SCC of  <addr_expr #>

    Streaming SCC of  <integer_cst # 0> (0x7ffff6ae1d20)
    Finished SCC of  <integer_cst # 0>

    Existing SCC of  <integer_cst # 0> (0x7ffff6ae1d20)

GOOD:

Creating output block for jmpfuncs
     Encoding indexable  <integer_type # int>  as 0 
     Encoding indexable  <pointer_type #>  as 1 
     Encoding indexable  <pointer_type #>  as 2 
    Streaming SCC of  <addr_expr #> (0x7ffff6af99c0)
     Streaming  <addr_expr #>  to jmpfuncs
     Streaming  <string_cst #>  to jmpfuncs
     Encoding indexable  <array_type #>  as 3 
     Encoding indexable  <pointer_type #>  as 4 
    Existing SCC of  <string_cst #> (0x7ffff6ade640)
    Finished SCC of  <addr_expr #>

    Streaming SCC of  <integer_cst # 0> (0x7ffff6af3690)
    Finished SCC of  <integer_cst # 0>

    Existing SCC of  <integer_cst # 0> (0x7ffff6af3690)
    Streaming SCC of  <addr_expr #> (0x7ffff6af9a20)
     Streaming  <addr_expr #>  to jmpfuncs
     Encoding indexable  <pointer_type #>  as 5 
     Encoding indexable  <function_decl # exit>  as 0 
    Finished SCC of  <addr_expr #>

    Streaming SCC of  <integer_cst # 0> (0x7ffff6af36a8)
    Finished SCC of  <integer_cst # 0>

    Existing SCC of  <integer_cst # 0> (0x7ffff6af36a8)
    Streaming SCC of  <addr_expr #> (0x7ffff6af9a40)
     Streaming  <addr_expr #>  to jmpfuncs
     Encoding indexable  <var_decl # M_var>  as 0 
    Finished SCC of  <addr_expr #>

    Existing SCC of  <integer_cst # 0> (0x7ffff6af3690)
    Existing SCC of  <integer_cst # 0> (0x7ffff6af3690)

So as seen, the integer_cst in GOOD version points to same tree
(0x7ffff6af3690),
while in the bad one, there are multiple integer constants.

Martin I thought there's some caching happening in IPA CP?