This is the mail archive of the gcc-patches@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: [pph] Stream and merge line table. (issue4836050)


OK with these changes.

As far as the trunk changes go.  Just commit your changes to the branch.
 I will get the trunk changes whenever they get approved in some future
merge.


Diego.



http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-in.c File gcc/cp/pph-streamer-in.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-in.c#newcode73
gcc/cp/pph-streamer-in.c:73: int pph_loc_offset;
   71 /* Set in pph_in_and_merge_line_table. Represents the
source_location offset
   72    which every streamed in token must add to it's serialized
source_location. */
   73 int pph_loc_offset;

Make it static.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c
File gcc/cp/pph-streamer-out.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer-out.c#newcode134
gcc/cp/pph-streamer-out.c:134: simply add them to the cache in the
preload.  */
  132   /* FIXME pph: we are streaming builtin locations, which implies
that we are
  133      streaming some builtins, we probably want to figure out what
those are and
  134      simply add them to the cache in the preload.  */

Hmm, we are streaming builtins?  The low-level streamer detects builtins
and only emits the builtin code, not the whole tree.  What builtins are
getting through?

This can be addressed on a follow-up patch.  It just sounds strange to
me that we are streaming builtins and locations.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h#newcode344
gcc/cp/pph-streamer.h:344: streamer hook back to pph_write_location.  */
 342    FIXME pph: If pph_trace didn't depend on STREAM, we could avoid
having to
 343    call this function, only for it to call lto_output_location,
which calls the
 344    streamer hook back to pph_write_location.  */

Just call pph_write_location here.  No need to call lto_output_location
anymore.   We only rely on lto_output_location calling us when it's
called from tree leaves inside the tree streamer routines.

http://codereview.appspot.com/4836050/diff/1/gcc/cp/pph-streamer.h#newcode419
gcc/cp/pph-streamer.h:419:
415 /* Read and return a location_t from STREAM.
 416    FIXME pph: If pph_trace didn't depend on STREAM, we could avoid
having to
 417    call this function, only for it to call lto_input_location,
which calls the
 418    streamer hook back to pph_read_location.  */
 419

Likewise here.

http://codereview.appspot.com/4836050/diff/1/gcc/lto-streamer-in.c
File gcc/lto-streamer-in.c (right):

http://codereview.appspot.com/4836050/diff/1/gcc/lto-streamer-in.c#newcode342
gcc/lto-streamer-in.c:342: if(streamer_hooks.input_location)
  342   if(streamer_hooks.input_location)

Space before '('

http://codereview.appspot.com/4836050/


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