[PATCH 0/5] RFC: Overhaul of diagnostics (v2)
Jeff Law
law@redhat.com
Fri Sep 25 16:50:00 GMT 2015
On 09/24/2015 02:15 AM, Richard Biener wrote:
> On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm <dmalcolm@redhat.com> wrote:
>
> LTO code does support ad-hoc locations but they are "restored" only
> when reading function bodies and stmts (by means of COMBINE_LOCATION_DATA).
>
>> The obvious simplification would be, as you suggest, to not bother
>> storing range information with LTO, falling back to just the existing
>> representation. Then there's no need to extend LTO to serialize ad-hoc
>> data; simply store the underlying locus into the bit stream. I think
>> that this happens already: lto-streamer-out.c calls expand_location and
>> stores the result, so presumably any ad-hoc location_t values made by
>> the v2 patches would have dropped their range data there when I ran the
>> test suite.
>
> Yep. We only preserve BLOCKs, so if you don't add extra code to
> preserve ranges they'll be "dropped".
Right, but as David pointed out, most of the interesting uses for ranges
(at least right now) are in the front-end diagnostics. So losing them
at this point isn't a major loss IMHO.
jeff
More information about the Gcc-patches
mailing list