[PATCH 10/16] Introduce class function_reader (v3)

[David Malcolm]

On Wed, 2016-10-05 at 18:00 +0200, Bernd Schmidt wrote:
> On 10/05/2016 06:15 PM, David Malcolm wrote:
> > 	* errors.c: Use consistent pattern for bconfig.h vs config.h
> > 	includes.
> > 	(progname): Wrap with #ifdef GENERATOR_FILE.
> > 	(error): Likewise.  Add "error: " to message.
> > 	(fatal): Likewise.
> > 	(internal_error): Likewise.
> > 	(trim_filename): Likewise.
> > 	(fancy_abort): Likewise.
> > 	* errors.h (struct file_location): Move here from read-md.h.
> > 	(file_location::file_location): Likewise.
> > 	(error_at): New decl.
> 
> Can you split these out into a separate patch as well? I'll require
> more 
> explanation for them and they seem largely independent.

[CCing Richard Sandiford]

The gen* tools have their own diagnostics system, in errors.c:

/* warning, error, and fatal.  These definitions are suitable for use
   in the generator programs; the compiler has a more elaborate suite
   of diagnostic printers, found in diagnostic.c.  */

with file locations tracked using read-md.h's struct file_location,
rather than location_t (aka libcpp's source_location).

Implementing an RTL frontend by using the RTL reader from read-rtl.c
means that we now need a diagnostics subsystem on the *host* for
handling errors in RTL files, rather than just on the build machine.

There seem to be two ways to do this:

  (A) build the "light" diagnostics system (errors.c) for the host as
well as build machine, and link it with the RTL reader there, so there
are two parallel diagnostics subsystems.

  (B) build the "real" diagnostics system (diagnostics*) for the
*build* machine as well as the host, and use it from the gen* tools,
eliminating the "light" system, and porting the gen* tools to use
libcpp for location tracking.

Approach (A) seems to be simpler, which is what this part of the patch
does.

I've experimented with approach (B).  I think it's doable, but it's
much more invasive (perhaps needing a libdiagnostics.a and a
build/libdiagnostics.a in gcc/Makefile.in), so I hope this can be
followup work.

I can split the relevant parts out into a separate patch, but I was
wondering if either of you had a strong opinion on (A) vs (B) before I
do so?

Dave