Re: Status of rich location work (was Re: [PATCH 06/10] Track expression ranges in C frontend)

[Dodji Seketeli <dodji@redhat.com>]

> Talking about risks: the reduction of the space for ordinary maps by a
> factor of 32, by taking up 5 bits for the packed range information
> optimization (patch 10):
>  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02539.html
> CCing Dodji: Dodji; is this reasonable?

FWIW, I am definitely to get this (patch 10/10 of the series) if other
agrees.  I just have some minor questions to ask about that patch and
I replied to the patch to ask.

As for the "reduction of the space for ordinary maps by a factor of 32,
by taking up 5 bits for the packed range information" that you mention,
I think it's a trade off I'd live with.

Ultimately, if it shows that we really move out of space with this, we
should probably explore the impact of just moving to a 64 bits size for
source_location.

Until then, a possible mitigation strategy could be to add an option to
disable the range tracking altogether (even at the preprocessor's lexer
level), to provide an escape path to users running low on resources.  A
bit what we do with -ftrack-macro-expansion=0.

Cheers,

-- 
		Dodji