https://dev.gentoo.org/~sam/bugs/gcc/123229/Unified_cpp_accessible_base1.ii.xz

219                   gcc_assert (chk_estimates.size == size
(gdb) p chk_estimates
$6 = {
  size = 42,
  min_size = 3,
  time = {
    m_sig = 841186566,
    m_exp = -24
  },
  nonspecialized_time = {
    m_sig = 938852680,
    m_exp = -24
  },
  hints = 32,
  loops_with_known_iterations = {
    m_sig = 0,
    m_exp = -536870911
  },
  loops_with_known_strides = {
    m_sig = 0,
    m_exp = -536870911
  }
}
(gdb) list
214                   && !opt_for_fn (callee->decl, flag_profile_partial_training)
215                   && !callee->count.ipa_p ())
216                 {
217                   ipa_call_estimates chk_estimates;
218                   ctx.estimate_size_and_time (&chk_estimates);
219                   gcc_assert (chk_estimates.size == size
220                               && chk_estimates.time == time
221                               && chk_estimates.nonspecialized_time == nonspec_time
222                               && chk_estimates.hints == hints);
223                 }
(gdb) p size
$7 = 44
(gdb) p time
$8 = {
  m_sig = 925072646,
  m_exp = -24
}
(gdb) p nonspec_time
$9 = {
  m_sig = 1022738760,
  m_exp = -24
}
(gdb) p hints
$10 = 32

-fno-devirtualize-speculatively works. Reducing but it is very slow...

This is also a recent regression, works with `16.0.0 20251214`.

(In reply to Andrew Pinski from comment #4)
> This is also a recent regression, works with `16.0.0 20251214`.

But ICEs with `16.0.0 20251216`.

Maybe https://gcc.gnu.org/cgit/gcc/commit/?id=7b3af2bfa1dee9a3e90de4d1c4bc03d73f825898 .

No, I'm sorry. To my surprise, it is r16-6149-g14ee9a2b41bafa. I double checked.

In cgraph, the dump is harder to read with some whitespace + indentation issues:

@@ -432525,10 +432445,8 @@ _ZN16nsTextEquivUtils28AppendFromAccessibleChildrenEPKN7mozilla4a11y10Accessible
   Function flags: body
   Called by: _ZN16nsTextEquivUtils20AppendFromAccessibleEPN7mozilla4a11y10AccessibleEP12nsTSubstringIDsE/67878 _ZN16nsTextEquivUtils18GetNameFromSubtreeEPKN7mozilla4a11y15LocalAccessibl
eER12nsTSubstringIDsE/67869
   Calls: long int __builtin_expect(long int, long int)/118568 _Z14NS_FAILED_impl8nsresult/663 _ZN16nsTextEquivUtils20AppendFromAccessibleEPN7mozilla4a11y10AccessibleEP12nsTSubstringIDsE/67878 _ZNK12nsTHashtableI12nsPtrHashKeyIKN7mozilla4a11y10AccessibleEEE8ContainsEPS4_/83629 _ZL17GetReferencedAccsv/67868
-   Polymorphic indirect call of type const struct Accessible token:3num speculative call targets: 0
-    Outer type (dynamic):struct Accessible (or a derived type) (maybe in construction) offset 0
-   Polymorphic indirect call of type const struct Accessible token:6num speculative call targets: 0
-    Outer type (dynamic):struct Accessible (or a derived type) (maybe in construction) offset 0
+       indirect polymorphic callsite, vptr_changed, calling param -1, offset 0otr_token 3, otr_type const struct Accessible, context     Outer type (dynamic):struct Accessible (or a derived type) (maybe in construction) offset 0, flags 0, num speculative call targets: 0
+       indirect polymorphic callsite, vptr_changed, calling param -1, offset 0otr_token 6, otr_type const struct Accessible, context     Outer type (dynamic):struct Accessible (or a derived type) (maybe in construction) offset 0, flags 0, num speculative call targets: 0

The probability is gone from the dumps too:

-   Indirect call(speculative) (386547056 (estimated locally),0.36 per call) num speculative call targets: 2
-   Indirect call(speculative) (386547056 (estimated locally),0.36 per call) num speculative call targets: 2
+       indirect polymorphic callsite, vptr not changed, calling param -1, offset 0otr_token 67, otr_type , context     Outer type (dynamic):struct Accessible (or a derived type) offset 0, flags 0, num speculative call targets: 2
+       indirect polymorphic callsite, vptr not changed, calling param -1, offset 0otr_token 67, otr_type , context     Outer type (dynamic):struct Accessible (or a derived type) offset 0, flags 0, num speculative call targets: 2

Created attachment 63106 [details]
Reduced testcase

Created attachment 63108 [details]
Reduced slightly more

.

The code checks that cache is contains current values.  It seems that in all places we remove speculations cache is updated, but perhaps estimate_edge_devirt_benefit diverges since we remove the callee making speculation less useful...

libcryptopp has the same issue.

$ gcc/inst/libexec/bin/g++ -O2 -flto=auto -c dll.ii
$ gcc/inst/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto1 -quiet dll.o
during IPA pass: inline
lto1: internal compiler error: in estimate_calls_size_and_time, at ipa-fnsummary.cc:3821
0x23fd7ed internal_error(char const*, ...)
        /home/jmelcr/gcc/src/gcc/diagnostic-global-context.cc:787
0x9b1e8d fancy_abort(char const*, int, char const*)
        /home/jmelcr/gcc/src/gcc/diagnostics/context.cc:1805
0x7fa0be estimate_calls_size_and_time
        /home/jmelcr/gcc/src/gcc/ipa-fnsummary.cc:3821
0xd5495a ipa_call_context::estimate_size_and_time(ipa_call_estimates*, bool, bool)
        /home/jmelcr/gcc/src/gcc/ipa-fnsummary.cc:4128
0xd6a9fb do_estimate_edge_time(cgraph_edge*, sreal*)
        /home/jmelcr/gcc/src/gcc/ipa-inline-analysis.cc:233
0xd6b2b9 do_estimate_edge_size(cgraph_edge*)
        /home/jmelcr/gcc/src/gcc/ipa-inline-analysis.cc:326
0xd6cbb2 estimate_edge_size(cgraph_edge*)
        /home/jmelcr/gcc/src/gcc/ipa-inline.h:79
0xd6cbb2 estimate_edge_growth(cgraph_edge*)
        /home/jmelcr/gcc/src/gcc/ipa-inline.h:100
0x21e3264 want_inline_small_function_p
        /home/jmelcr/gcc/src/gcc/ipa-inline.cc:1017
0x21e537c update_caller_keys
        /home/jmelcr/gcc/src/gcc/ipa-inline.cc:1634
0x21e77dd inline_small_functions
        /home/jmelcr/gcc/src/gcc/ipa-inline.cc:2457
0x21e77dd ipa_inline
        /home/jmelcr/gcc/src/gcc/ipa-inline.cc:2911
0x21e77dd execute
        /home/jmelcr/gcc/src/gcc/ipa-inline.cc:3434
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

Only at -O2 and above.

Created attachment 63470 [details]
libcryptopp reproducer

(In reply to Sam James from comment #3)
> -fno-devirtualize-speculatively works. Reducing but it is very slow...

So maybe fixed by r16-7075-gfe050fa9d1249a?

(In reply to Sam James from comment #17)
> (In reply to Sam James from comment #3)
> > -fno-devirtualize-speculatively works. Reducing but it is very slow...
> 
> So maybe fixed by r16-7075-gfe050fa9d1249a?

No. The testcase in comment #12 still reproduces (ICEs) on the trunk with -O3.

There's also the broken dumps too, so I shouldn't have commented that before.

(In reply to Andrew Pinski from comment #18) 
> No. The testcase in comment #12 still reproduces (ICEs) on the trunk with
> -O3.

I'm looking into this.

I'm testing this fix:
https://inbox.sourceware.org/gcc-patches/ri6ikbimqst.fsf@virgil.suse.cz/T/#u

The master branch has been updated by Martin Jambor <jamborm@gcc.gnu.org>:

https://gcc.gnu.org/g:431453e3364bde20f3c6af72300137321bd98420

commit r16-7756-g431453e3364bde20f3c6af72300137321bd98420
Author: Martin Jambor <mjambor@suse.cz>
Date:   Fri Feb 27 14:26:13 2026 +0100

    ipa-prop: Reset param_index of indir. edge when there are no jfuncs (PR123229)
    
    In my commit r16-6149-g14ee9a2b41bafa I have added an early exit to
    update_indirect_edges_after_inlining which was however wrong, as
    demonstrated by the PR123229 testcase.  This patch reverts that change,
    restoring the previous behavior in this regard.
    
    In the testcase, the edge being inlined is a call to a thunk, which do
    not have jump functions associated with them.  This means that with
    the early exit we neither reset the parameter index associated with
    the indirect edge nor update the edges and the usage flags associated
    with them
    
    In the testcase, this meant that the param_used_by_indirect_call flag
    was not updated, which in turn meant that the inlining edge cost cache
    did not copy necessary information into the context which led to the
    fact that two contexts which were not the same were considered the
    same, and the checking code that evaluations in the cache should match
    a re-evaluation triggered.  But unfortunately this bug can probably
    have all sorts of weird and unexpected consequences.
    
    The testcase also shows that inlined thunks are a barrier to
    devirtualization which is something I will try to address next stage1.
    
    gcc/ChangeLog:
    
    2026-02-27  Martin Jambor  <mjambor@suse.cz>
    
            PR ipa/123229
            * ipa-prop.cc (update_indirect_edges_after_inlining): Reset parameter
            index associated with an indirect edge if the inlined edge does not
            have any jump functions.
    
    gcc/testsuite/ChangeLog:
    
    2026-02-27  Martin Jambor  <mjambor@suse.cz>
    
            PR ipa/123229
            * g++.dg/ipa/pr123229.C: New test.

(In reply to Andrew Pinski from comment #18)
[...]
> No. The testcase in comment #12 still reproduces (ICEs) on the trunk with
> -O3.

This is now also fixed.  Sorry that it took me so long, I half-hoped this would be another known issue.