https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #8)
> Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I
> suggest we make all of these P5 or Wont fix.
Please don't make them wont-fix.
An ICE is always a bug, as we used to explain everybody who asked,
and I still consider it that way.
If you must, make them P5, but didn't we have P5 for enhancements,
or (missing/wrong) diagnostics?
Also, an ICE-on-invalid input that confuses the parser points at a
different part of the compiler than an ICE that happens during resolution,
simplification, frontend-optimization, translation.
In several cases, an ICE in one of the trans*.cc was caused by an issue
much earlier in the process.
One problem is that there are lots of PRs that are - either seemingly or
likely - related. A good (better?) classification of bugs to find those
that might be connected or near-duplicates would be helpful.
I once tried to edit the summary of some bugs that were e.g. coarray-related,
or OOP; not sure if that was appreciated.
(We could more aggressively mark PRs as F2018 or F2023.)
Also, there are several bugs pertaining only to CLASS. Some of those
would be addressed along with the fix for PR106856. Tobias' patch plus
some minor fixup to it seems to solve many of them.
However, that patch creates a regression in one ("invalid") testcase because
of a corruption of one list, leading to a segfault in restore_old_symbol.
I think it is not the right way to try to make the cleanup more robust; this
would only sweep the actual issues under the rug. It's the cause of
corruption of lists etc. that should matter.
Recovering memory or garbage collection should really be lower on our list.
