On 09/24/2015 02:15 AM, Richard Biener wrote:
On Thu, Sep 24, 2015 at 2:25 AM, David Malcolm <dmalc...@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
