https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102511
--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #7) > (In reply to Aldy Hernandez from comment #6) > > Describing the process to get here makes it abundantly clear that we need to > > improve the process of debugging this. We need a way to turn on the solver > > debugging from the command line (--param??), and not by some magic #define. > > Also, some counter that matches the path being registered with the > > equivalent solver dump would be useful. This way someone could easily find > > the problematic thread in the solver dump. I'll look into this. > > Maybe look into dbgcnt.def and their usage. It should help with the counter > situtation :). Thanks Andrew. I've used your idea in my committed patch here: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580369.html It's not perfect, but it should help in diagnosing these issues in the future. I hope to improve the dumps in the next month, to help any stage3 bugfixing.
