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".