Re: [PATCH v3 0/4] diagnostics: libcpp: Overhaul locations for _Pragma tokens

[David Malcolm <dmalcolm@redhat.com>]

On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote:
> Hello-
> 
> This is an update to the v2 patch series last sent in January:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609473.html
> 
> While I did not receive any feedback on the v2 patches yet, they did
> need some
> rebasing on top of other recent commits to input.cc, so I thought it
> would be
> helpful to send them again now. The patches have not otherwise
> changed from
> v2, and the above-linked message explains how all the patches fit in
> with the
> original v1 series sent last November.
> 
> Dave, I would appreciate it very much if you could please let me know
> what you
> think of this approach? I feel like the diagnostics we currently
> output for _Pragmas are worth improving. As a reminder, say for this
> example:
> 
> =====
>  #define S "GCC diagnostic ignored \"oops"
>  _Pragma(S)
> =====
> 
> We currently output:
> 
> =====
> file.cpp:2:24: warning: missing terminating " character
>     2 | _Pragma(S)
>       |                        ^
> =====
> 
> While after these patches, we would output:
> 
> ======
> <generated>:1:24: warning: missing terminating " character
>     1 | GCC diagnostic ignored "oops
>       |                        ^
> file.cpp:2:1: note: in <_Pragma directive>
>     2 | _Pragma(S)
>       | ^~~~~~~
> ======
> 
> Thanks!

Hi Lewis; sorry for not responding to the v2 patches.

I've started looking at the v3 patches in detail, but I have some high-
level questions about memory usage:

Am I right in thinking that the effect of this patch is that for every
_Pragma in the source we will create a new line_map_ordinary, and a new
buffer for the stringified content of that _Pragma, and that these
allocations will persist for the rest of the compilation?  (plus a
little extra allocation within the "location_t" space from 0 to
0x7fffffff).

It sounds like this will probably be a rounding error that won't be
noticable in profiling, but did you attempt any such measurement of the
memory usage before/after this patch on some real-world projects?

Thanks
Dave