This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linemap and pph


Alright, so after looking even more at the linemap code, here is what
I'm thinking now:

So the main problem is:
with the linemap logic is that linemap_line_start adds a new table
entry if line_delta < 0 (I don't understand why this is needed, my
assumption is that it is because the rest of the logic depends on
set->highest_location, thus we want to make sure we are higher than
the highest so far? can someone clarify why we need this?)

My solution:
I will add a boolean flag to linemap_line_start's parameters,
allowEarlierStartLineStart, which when true, will not create a new
entry in the line_table even if the line_delta < 0.

Instead of relying on highest_location to find the current line's
source location, it will use the start_location and add to it the
delta between to_line and map->to_line).

I will also add a new linemap function,
linemap_position_for_line_and_column, which will be just like
linemap_position_for_column, except that it won't assume the
highest_line in the set is the one we are currently on (this function
will thus allow us to get a source_location without depending on the
current assumptions on the order these functions are called in).

This solution would not modify the actual final result of the entries,
at the end of parsing, as far as I understand (I would also of course
only use this new flag in the call from lto_input_location (which we
use in pph to get our source_location from the streamed
expanded_location))

Let me know what you think,
Gabriel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]