From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102651 invoked by alias); 10 Oct 2016 18:53:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 102640 invoked by uid 89); 10 Oct 2016 18:53:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:209.85.215.66, H*RU:209.85.215.66, Implementing, subsystem X-HELO: mail-lf0-f66.google.com Received: from mail-lf0-f66.google.com (HELO mail-lf0-f66.google.com) (209.85.215.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 18:53:08 +0000 Received: by mail-lf0-f66.google.com with SMTP id p80so11583904lfp.1 for ; Mon, 10 Oct 2016 11:53:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=ODdtyAkzNkj+TN/IZZ3fZzshaFgXO119svBBCeYBVVY=; b=KFx3mMMLTveNddJiLsysg+ASQxz64SFfsMsw/wea212wJGkxmD6FuaJ16W8GH/6MV/ e9bAxQQkGcXEVd696bD0g9Nq1bz1VMQB/woaQgEUSsB3Qzk+sUYlUaGOAF3g4VA0Abxf 91W3S2R+nhMsfZHdvVWNI7FDmMb0ZaMmZ7yc4P1ODLv8p6mKb7uF5M2HbMPWQaV5oj/N EQeMw5U+dC93X7TFrWRNWZzNYsOBQZMNNmWkblVvfptZZO08uoHPF99Dp8MH+0g1apCb 05doWxXXSdlwhPysHVEFH+kxTrNPdU3JNHvYnssmxIjF3Q43cvsZ9Ai47j/nIOl3d4uk vHRQ== X-Gm-Message-State: AA6/9RmtJUpH3hY0fCLjRV6P7DTYe6O50wGxAm/NDTWccTz5OwPMz8DBtTwa6fbuPWCp4w== X-Received: by 10.194.235.103 with SMTP id ul7mr36236129wjc.201.1476125585693; Mon, 10 Oct 2016 11:53:05 -0700 (PDT) Received: from localhost ([95.144.14.157]) by smtp.googlemail.com with ESMTPSA id vx7sm42328217wjc.1.2016.10.10.11.53.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 10 Oct 2016 11:53:05 -0700 (PDT) From: Richard Sandiford To: David Malcolm Mail-Followup-To: David Malcolm ,Bernd Schmidt , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 10/16] Introduce class function_reader (v3) References: <1475684110-2521-1-git-send-email-dmalcolm@redhat.com> <1475684110-2521-11-git-send-email-dmalcolm@redhat.com> <65a31370-0fe5-c7d9-2262-f6a4d7107c57@redhat.com> <1475847845.30303.35.camel@redhat.com> Date: Mon, 10 Oct 2016 18:53:00 -0000 In-Reply-To: <1475847845.30303.35.camel@redhat.com> (David Malcolm's message of "Fri, 07 Oct 2016 09:44:05 -0400") Message-ID: <87bmysqbn3.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-10/txt/msg00648.txt.bz2 David Malcolm writes: > 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? (A) sounds fine to me FWIW. And sorry for the slow reply. Thanks, Richard