[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