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: Better GCC diagnostics


"Manuel LÃpez-IbÃÃez" <lopezibanez@gmail.com> writes:

> Let's try to focus on what needs to be done looking for specific
> features (or fixes) and how we could do it:

Thanks for writing this up.

> A) Printing the input expression instead of re-constructing it. As
>    Joseph explained, this will fix the problems that Aldy mentioned
>    (PR3544[123] and PR35742) and this requires:
>
>   1) For non-preprocessed expr we need at least two locations per expr
>      (beg/end). This will require changes on the build_* functions to
>      handle multiple locations.

This is probably obvious, but can you outline why we need two
locations for each expression?  The tools with which I am familiar
only print a single caret.  What would use the two locations for?


>      b) Re-open the file and fseek. This is not trivial since we need
>         to do it fast but still do all character conversions that we
>         did when libcpp opened it the first time. This is
>         approximately what Clang (LLVM) does and it seems they can do
>         it very fast by keeping a cache of buffers ever reopened. I
>         think that thanks to our line-maps implementation, we can do
>         the seeking quite more efficiently in terms of computation
>         time.  However, opening files is quite embedded into CPP, so
>         that would need to be factored out so we can avoid any
>         unnecessary CPP stuff when reopening but still do it
>         *properly* and *efficiently*.

If we are going to reopen the file, then why do we need to record the
locations in the preprocessed token stream?

If we keep, for each source line, the file offset in the file of the
start of that source line, then I think that printing the line from
the source file would be pretty fast.  That would not be free but it
would be much cheaper than keeping the entire input file.  Various
optimizations are possible--e.g., keep the file offset for every 16th
line. Conversely, perhaps we could record the line number and the
charset conversion state at each 4096th byte in the file; that would
let us quickly find the page in the file which contains the line.

Ian


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