On Fri, Dec 6, 2024 at 7:27 AM Sam James <s...@gentoo.org> wrote: > > Jeremy Bettis <jbet...@google.com> writes: > > > Patch to fix known bug from > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 > > > > diff -ur gcc-clean/gcc-14.2.0/libcpp/files.cc gcc-14.2.0/libcpp/files.cc > > --- gcc-clean/gcc-14.2.0/libcpp/files.cc 2024-08-01 08:17:17.000000000 +0000 > > +++ gcc-14.2.0/libcpp/files.cc 2024-10-18 18:42:42.293245597 +0000 > > Please ideally use git-send-email and see > https://gcc.gnu.org/contribute.html#patches wrt ChangeLog format and so on. > > > @@ -1005,6 +1005,11 @@ > > && type < IT_DIRECTIVE_HWM > > && (pfile->line_table->highest_location > > != LINE_MAP_MAX_LOCATION - 1)); > > + if (decrement && LINEMAPS_ORDINARY_USED (pfile->line_table)) { > > + const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP > > (pfile->line_table); > > + if (map && map->start_location == pfile->line_table->highest_location) > > + decrement = false; > > + } > > if (decrement) > > pfile->line_table->highest_location--; > > Note that I suspect this may be fixed by the 64-bit location_t work that > is ongoing for trunk but it may still be desirable for 14 anyway.
The 64-bit location_t will be merged this weekend BTW. I think that Jeremy's patch is still good to have on top of that for GCC 15, though, since technically we will still have the same issue in theory, just it will apply only to impractically large sources. There is a plugin-based test in the testsuite that can be used to still test this change with 64-bit location_t too. (location_overflow_plugin.cc). -Lewis
