https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69985
--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #6)
> Bingo! With both files present I can even reproduce it on my x86_64 machine.
Unfortunately, I cannot reproduce it with r230753, so it seems quite a recent
regression. (something is broken in the machine of the compile farm that I use
for development and I cannot build a more recent GCC).
If you want to investigate further, add a breakpoint just before calling
linemap_position_for_loc_and_offset(), figure out if the arguments passed make
sense and if they do, why the corresponding assert is triggering.
The assert triggering is one of these two:
if (linemap_assert_fails (r <= set->highest_location)
|| linemap_assert_fails (map == linemap_lookup (set, r)))
This may be because the line-tables are somehow messed up, the offset we passed
was larger than it should be or because we think that r should be encoded in
map "map", but somehow this is wrong. The function tries to account for these
cases, but perhaps I missed some corner-case.
It should also be possible to minimize the original .c file by removing headers
and stuff, but probably the bug depends a lot on the line-table structure,
which is quite sensitive to the locations of what is parsed. Nonetheless, some
automatic tool may be able to produce another smaller reproducer
(https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction).
In any case, this should only happen with checking enabled, since the assert is
disabled otherwise. (The assert is there mostly to catch QOI issues, thus it is
harmless to disable it in release builds).
BTW, this code should not even be reached with "-w", since that disables all
warnings, and this code is only used to print precise columns numbers in
warnings. Does not using -Wall at all trigger the bug also?
