https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #8) > Note that this first started to ICE with r223470, which is also the first > revision where it starts opening cmds-check.c (which also premature to me, > because no warning is actually emitted; I'd think that it should do that > only if the warning is actually going to be emitted and needs it, otherwise > it is an unnecessary compile time slowdown); that ICE got later fixed in > r224236, but later reappeared (in r230331). I added the linemap_assert_fails to catch QOI issues with this function, that is, cases where we should return the correct offset but we don't for some reason. This is why it is not enabled in release mode. Since nobody seems to have time or interest to fix these QOI issues, a better approach than removing the asserts completely would be to replace linemap_assert_fails with some equivalent macro which only enables the asserts if explicitly requested. This way, if someone someday decides to improve the offsets, they could re-enable the asserts and see which of the cases where we give up because something went wrong is the one triggering. Most code in c-format.c is only necessary if -Wformat is enabled, but it is run nevertheless. Note also that -w only disables printing the warning text quite late in the diagnostics machinery, it doesn't change the value of any warning option.
