From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14907 invoked by alias); 31 Jul 2018 13:08:16 -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 14897 invoked by uid 89); 31 Jul 2018 13:08:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Jul 2018 13:08:14 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 599FD7A7ED; Tue, 31 Jul 2018 13:08:13 +0000 (UTC) Received: from redhat.com (dhcp-17-19.bos.redhat.com [10.18.17.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 31B1C10EE781; Tue, 31 Jul 2018 13:08:13 +0000 (UTC) Date: Tue, 31 Jul 2018 13:08:00 -0000 From: Marek Polacek To: Richard Biener Cc: David Malcolm , GCC Patches Subject: Re: [PATCH 4/5] c-family: clean up the data tables in c-format.c Message-ID: <20180731130811.GI3264@redhat.com> References: <1532730752-10525-1-git-send-email-dmalcolm@redhat.com> <1532730752-10525-5-git-send-email-dmalcolm@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) X-SW-Source: 2018-07/txt/msg01944.txt.bz2 On Tue, Jul 31, 2018 at 02:56:29PM +0200, Richard Biener wrote: > On Fri, Jul 27, 2018 at 11:48 PM David Malcolm wrote: > > > > The format_char_info tables in c-format.c for our own formats contain > > a lot of repetition. > > > > This patch adds a macro to express the conversion specifiers implemented > > within pp_format, making it clearer which are custom ones added by the > > various diagnostic_format_decoder callbacks. > > > > Doing so uncovered a few mistakes in the data (based on comparison with > > the source of the diagnostic_format_decoder callbacks, and the notes > > below), which the patch fixes: > > > > - gcc_diag_char_table didn't have 'Z', but it *is* implemented by pp_format. > > > > - removed erroneous 'G' and 'K' entries from gcc_diag_char_table: they're > > implemented by default_tree_printer (and thus in "tdiag") and by the > > C/C++ FEs, but not in pp_format. > > > > - removed "v" (lower case) from gcc_tdiag_char_table and > > gcc_cxxdiag_char_table > > > > Notes: > > > > pretty-print.h uses this for ATTRIBUTE_GCC_PPDIAG, used by pp_printf > > and pp_verbatim: > > > > whereas diagnostic-core.h uses this for ATTRIBUTE_GCC_DIAG, used by > > the various diagnostic functions: > > > > /* If we haven't already defined a front-end-specific diagnostics > > style, use the generic one. */ > > > > Hence I'm assuming that __gcc_diag__ is for use for when we don't > > know what kind of diagnostic_format_decoder we have, and we can > > only rely on pp_format's core functionality, where __gcc_tdiag__ > > is allowed to assume default_tree_printer. > > OK if nobody objects. Looks fine to me, too. Marek