https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70693
--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
The issue occurs due to a stray carriage return aka '\r' aka ^M, occurring
towards the end of line 35 of attachment 38289 - but not at the end itself.
This carriage return confuses our line numbering.
When lexing attachment 38289, the "break" token is recorded as being
at line 55 column 8:
(gdb) p next_tinfo
$1 = (const token_indent_info &) @0x7fffffffd3d0: {location = 382052, type =
CPP_KEYWORD, keyword = RID_BREAK}
...but input.c (and thus diagnostic-show-locus) are accessing the line beyond
for "line 55":
(gdb) call inform (382052, "'break' token is here")
../../src/attachment-38289.cc: In member function ‘bool
{anonymous}::SgmlFilter::process_char(FilterChar::Chr)’:
../../src/attachment-38289.cc:55:8: note: 'break' token is here
55 |
| ^
"cat -n" and emacs both agree with this latter numbering, showing the "break;"
as being on line 54, and with line 55 as that blank line.
This discrepancy between the lexer's line numbering and input.c's line
numbering leads to an out-of-range read in get_visual_column (trying to read
column 8, to locate the "break;", but finding the next line, which is only 4
characters long).
