https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83252
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Dmitry Babokin from comment #6)
> > I'm not insisting on such functionality, as my bugs were always analysed and
> > fixed in timely manner (unlike with other compilers). But I still think gcc
> > would benefit from such mechanism a lot.
>
> The problem with GCC (and sometimes other compilers) is latent bugs in
> passes after where the change happened. A lot of the time for GCC, this has
> been true. Especially when we are talking about GCC's RTL passes; some of
> which date from the mid to late 1990s (e.g. combine). And even some of the
> RTL passes don't have an option flag to enable/disable (e.g. combine).
>
> Also there are other things like disabling the late VRP or another pass
> which uses the VRP data that was not updated which causes the bug to show up.
>
> Just a few examples of why this functionality is not very useful in GCC and
> also it gets abused by some users of it to workaround a bug in one specific
> version of GCC rather than reporting the bug :).
I suppose one could try scripting something with -fdisable-{tree,rtl}-$dump
and seeding the list of passes to enable/disable with -fdump-{tree,rtl}-all.
Of course some -fdisable-* are "invalid" and will cause "interesting"
downstream
effects...
Sometimes I do this manually for cases where it isn't obvious who's doing sth
wrong...
