https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68819
--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #3)
> (In reply to David Malcolm from comment #1)
> > Is it a file with many includes? libcpp can go into a fallback mode where
> > it stops supplying column numbers, when location_t goes >=
> > LINE_MAP_MAX_LOCATION_WITH_COLS.
>
> That seems to be the case - at least, I am down to:
Thanks.
Presumably we can fix this by not issuing an error if any of the columns == 0.
We *might* want to issue a "sorry" when the limit is hit if
-Wmisleading-indentation is enabled.
> #include "some.h" // Unrelated, but includes boost and some other headers
> #include "four.h"
>
> where four.h contains '#include "three.h"' etc. until two.h, which contains
> the header file with the class which has
> unsigned int get_max_index() const { if (ul) return 4; return 0; }
>
> The compilation takes about 10s - thus, I assume g++ has quite something to
> read & process. I am going to reduce the last-mentioned header file & might
> try to mimic "some.h" by creating some nested header files - but I fear the
> latter is a bit pointless, if I have to add that many locations that one
> runs out of LINE_MAP_MAX_LOCATION_WITH_COLS.
I think any "minimal" reproducer for hitting this limit using actual code is
going to be unacceptably big.
Idea: an alternative way to reproduce this might be a compiler plugin that
injects a very large fake ordinary line map before parsing begins, so that
we've already hit the limit before the real code is parsed.
(the -fselftests/unittesting idea might be useful for injecting some more
testing of these attempts to degrade gracefully).
