From patchwork Wed Nov 5 15:48:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Malcolm X-Patchwork-Id: 407062 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 22AB1140079 for ; Thu, 6 Nov 2014 02:52:45 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references; q=dns; s= default; b=AV4gyl2EtA9K+WXKxTkY3j6QlOND//LMlDGcJOJXFNRY1gThrfjLo 9mxmApvgdjZtnqF10+62dMooDWiVfS4BI7/G5VnghUwQubIYvjfbymwgKVm7kQd7 a+7OGvA6g6Ty87VdiFje45Zxp4rWi4LTvBLEw2rGYJe9iOWL9SlxQU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references; s= default; bh=Fn1UY+e9rRDsCjQvozhPS0pfNz4=; b=RPyPbjhfZMsZkxp4MuSN 5/XacwONhJLLyFIg8/gZtjy1R786jQMXUdxgCSdwZzS722Yx4KlqHHGRc3RXaHXT AALTz4j2khpAexm5gUHRd2T/HookOffbICYrkHqtull3ua8hgCsJxdOQHgez2OnH jzsl5XAi6nyCIFHZOiL5TlM= Received: (qmail 23352 invoked by alias); 5 Nov 2014 15:52:36 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 23251 invoked by uid 89); 5 Nov 2014 15:52:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 05 Nov 2014 15:52:34 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA5FqWHf022549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 5 Nov 2014 10:52:32 -0500 Received: from surprise.redhat.com (vpn-235-98.phx2.redhat.com [10.3.235.98]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sA5FqVx6018406; Wed, 5 Nov 2014 10:52:31 -0500 From: David Malcolm To: Jeff Law Cc: gcc-patches@gcc.gnu.org, jit@gcc.gnu.org, David Malcolm Subject: [jit] Use ISALPHA and ISALNUM rather than writing our own Date: Wed, 5 Nov 2014 10:48:08 -0500 Message-Id: <1415202488-1461-1-git-send-email-dmalcolm@redhat.com> In-Reply-To: <545947AE.2070606@redhat.com> References: <545947AE.2070606@redhat.com> X-IsSubscribed: yes On Tue, 2014-11-04 at 14:39 -0700, Jeff Law wrote: > On 11/04/14 09:57, David Malcolm wrote: > >>> +#define IS_ASCII_DIGIT(CHAR) \ > >>> + ((CHAR) >= '0' && (CHAR) <='9') > >>> + > >>> +#define IS_ASCII_ALNUM(CHAR) \ > >>> + (IS_ASCII_ALPHA (CHAR) || IS_ASCII_DIGIT (CHAR)) > >> Can't we rely on the C library to give us equivalents? > > > > I've been burned in the past by the C library using locales, in > > particular the two lowercase "i" variants in Turkish. > > > > These macros are used by gcc_jit_context_new_function to enforce C's > > naming restrictions, to avoid errors from the assembler. The comment I > > put there was: > > > > /* The assembler can only handle certain names, so for now, enforce > > C's rules for identifiers upon the name. > > Eventually we'll need some way to interact with e.g. C++ name mangling. */ > > > > Am I right in thinking that for the assembler we need to enforce the C > > naming rules specifically on *ASCII*. > > > > (clearly another comment is needed here). > I guess you've got to do it somewhere. Presumably there isn't something > already in GCC that enforces an input character set? I guess I just > dislike seeing something that feels like it ought to already be available. It turns out that locale-independent tests for this did already exist in libiberty, in safe-ctype.h, so I've committed this to the jit branch: gcc/jit/ChangeLog.jit: * libgccjit.c: Include safe-ctype.h from libiberty. (IS_ASCII_ALPHA): Delete. (IS_ASCII_DIGIT): Delete. (IS_ASCII_ALNUM): Delete. (gcc_jit_context_new_function): Replace use of IS_ASCII_ALPHA and IS_ASCII_ALNUM with ISALPHA and ISALNUM respectively, from libiberty. --- gcc/jit/ChangeLog.jit | 10 ++++++++++ gcc/jit/libgccjit.c | 24 +++++++----------------- 2 files changed, 17 insertions(+), 17 deletions(-) diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit index 90fccdb..3d6361c 100644 --- a/gcc/jit/ChangeLog.jit +++ b/gcc/jit/ChangeLog.jit @@ -1,3 +1,13 @@ +2014-11-05 David Malcolm + + * libgccjit.c: Include safe-ctype.h from libiberty. + (IS_ASCII_ALPHA): Delete. + (IS_ASCII_DIGIT): Delete. + (IS_ASCII_ALNUM): Delete. + (gcc_jit_context_new_function): Replace use of IS_ASCII_ALPHA and + IS_ASCII_ALNUM with ISALPHA and ISALNUM respectively, from + libiberty. + 2014-10-30 David Malcolm * dummy-frontend.c (jit_langhook_init): Remove some dead code. diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c index 286a85e..d9f259e 100644 --- a/gcc/jit/libgccjit.c +++ b/gcc/jit/libgccjit.c @@ -22,24 +22,12 @@ along with GCC; see the file COPYING3. If not see #include "system.h" #include "coretypes.h" #include "opts.h" +#include "safe-ctype.h" #include "libgccjit.h" #include "jit-common.h" #include "jit-recording.h" -#define IS_ASCII_ALPHA(CHAR) \ - ( \ - ((CHAR) >= 'a' && (CHAR) <='z') \ - || \ - ((CHAR) >= 'A' && (CHAR) <= 'Z') \ - ) - -#define IS_ASCII_DIGIT(CHAR) \ - ((CHAR) >= '0' && (CHAR) <='9') - -#define IS_ASCII_ALNUM(CHAR) \ - (IS_ASCII_ALPHA (CHAR) || IS_ASCII_DIGIT (CHAR)) - struct gcc_jit_context : public gcc::jit::recording::context { gcc_jit_context (gcc_jit_context *parent_ctxt) : @@ -589,13 +577,15 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt, RETURN_NULL_IF_FAIL (return_type, ctxt, loc, "NULL return_type"); RETURN_NULL_IF_FAIL (name, ctxt, loc, "NULL name"); /* The assembler can only handle certain names, so for now, enforce - C's rules for identiers upon the name. - Eventually we'll need some way to interact with e.g. C++ name mangling. */ + C's rules for identiers upon the name, using ISALPHA and ISALNUM + from safe-ctype.h to ignore the current locale. + Eventually we'll need some way to interact with e.g. C++ name + mangling. */ { /* Leading char: */ char ch = *name; RETURN_NULL_IF_FAIL_PRINTF2 ( - IS_ASCII_ALPHA (ch) || ch == '_', + ISALPHA (ch) || ch == '_', ctxt, loc, "name \"%s\" contains invalid character: '%c'", name, ch); @@ -603,7 +593,7 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt, for (const char *ptr = name + 1; (ch = *ptr); ptr++) { RETURN_NULL_IF_FAIL_PRINTF2 ( - IS_ASCII_ALNUM (ch) || ch == '_', + ISALNUM (ch) || ch == '_', ctxt, loc, "name \"%s\" contains invalid character: '%c'", name, ch);