https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109109
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Without an actual self-contained reproducer hard to guess. The above mentioned change changes the content of _ZN9page_id_tC2Ejj _Z22trx_undo_get_first_recRK11fil_space_tjtjRPK11buf_block_tP5mtr_tP7dberr_t _ZN5trx_t9apply_logEv _Z17trx_undo_add_pageP10trx_undo_tP5mtr_tP7dberr_t _ZL18trx_undo_free_pageP10trx_rseg_tbjjP5mtr_tP7dberr_t functions from what I can see, so which one of these it is? Another possible way to narrow it down a little bit would be to undo the i386.md hunks from that commit one by one and see which one it is, all the 4 changes are optimizations and all of them are independent of each other (any of them dependent on the i386-expand.cc change which shouldn't change anything on its own). If you narrow it down to one function, then I guess we need to turn it into a self-contained reproducer, add dummy wrapper which calls that function from main with the right arguments and supply dummy callees for the function for functions which aren't inlined.
