Re: How GCC treats ice-on-invalid-code?

[Richard Sandiford <richard.sandiford@arm.com>]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> It's fine to file these ice-on-invalid bugs, but don't be surprised if
>> nobody has time to work on bugs that are only triggered by unrealistic
>> garbage input.
>
> Right, an ICE is a perfectly valid outcome for garbage input and there are 
> hundreds of assertions in the compiler precisely for this purpose.

You mean, an ICE is perfectly valid as the first (and obviously then
only) error diagnostic the compiler prints for “garbage input”?
If so, I don't think that's true.  What counts as “garbage” seems
a bit too subjective for that anyway.

E.g. deleting a chunk of lines from a file creates something that makes
no sense and might be considered garbage, but that can easily happen
with a botched resolution to a merge conflict (or being too trigger-happy
with git rerere :-)).  I don't think it's OK for the compiler simply to
crash without first giving the user an idea of what's wrong.

I agree ICEs are mostly OK as a downstream effect of an error that has
already been reported, but in the context of the quote above, those cases
are error-recovery rather than ice-on-invalid-code.

Thanks,
Richard