From patchwork Tue Oct 2 11:10:30 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Basile Starynkevitch X-Patchwork-Id: 188453 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]) by ozlabs.org (Postfix) with SMTP id EA0202C008A for ; Tue, 2 Oct 2012 21:10:47 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1349781048; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition:User-Agent:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=vdd2T5N82W7TtIqNpC3Px57n320=; b=QrX3sVpUAAaZiZz D0zmhG4PxefKvFHqZO0yKHY00UR4NIplukgsVPSpCCBYW8UK25383tRxQfZqYgpx hw0I7IAUWEoP0luqO4SIjv8I5fQp0QuOqZQB2qQE74Bqi/NsDf0eauorWP6XOjnZ 0X30rHWzHcGFOxBawtIeho6Ptj/U= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=KPfhgLAg9URooQy5v7PbzfuzQmftnJgfFhAJH2zRpm/v6fNwFMs4POMshlYSKa RxbKwXNIdWHxVZxMBqSlut3BM2ALRGxoUPs6TYv5wSOTwEjLlmMVfDwUO9FDqVP7 tSI+cvX1KLZ5iOzrrEMlfHDH6M27W+sZdLeN9NONOceyg=; Received: (qmail 22236 invoked by alias); 2 Oct 2012 11:10:42 -0000 Received: (qmail 22220 invoked by uid 22791); 2 Oct 2012 11:10:40 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, TW_SV X-Spam-Check-By: sourceware.org Received: from smtp-102-tuesday.noc.nerim.net (HELO mallaury.nerim.net) (178.132.17.102) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 02 Oct 2012 11:10:34 +0000 Received: from hector.lesours (ours.starynkevitch.net [213.41.244.95]) by mallaury.nerim.net (Postfix) with ESMTPS id 68EA9153448; Tue, 2 Oct 2012 13:10:26 +0200 (CEST) Received: from basile18 by hector.lesours with local (Exim 4.80) (envelope-from ) id 1TJ0Mx-0000ZF-2j; Tue, 02 Oct 2012 13:10:31 +0200 Date: Tue, 2 Oct 2012 13:10:30 +0200 From: Basile Starynkevitch To: gcc-patches@gcc.gnu.org Cc: laurynas.biveinis@gmail.com, dnovillo@google.com Subject: PATCH trunk: gengtype honoring mark_hook-s inside struct inide union-s Message-ID: <20121002111030.GA1872@hector.lesours> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 Hello All, As I observed in http://gcc.gnu.org/ml/gcc/2010-07/msg00248.html and in http://gcc.gnu.org/ml/gcc/2012-10/msg00003.html the mark_hook GTY annotation is sometimes incorrectly ingored by gengtype. The example in http://gcc.gnu.org/ml/gcc/2012-10/msg00003.html demonstrates that incorrect behavior of gengtype (both with gengtype from GCC 4.7, and with the current trunk's gengtype). For simplicity, here is it again: /* file tmarkh.h */ #define MYUTAG 1 union GTY ((desc("%0.u_int"))) myutest_un { int GTY((skip)) u_int; struct mytest_st GTY ((tag("MYUTAG"))) u_mytest; }; static GTY(()) union myutest_un *myutestptr; static inline void mymarker(struct mytest_st*s) { s->myflag = 1; } /* eof tmarkh.h */ when running gengtype (the one from the trunk, or the gcc-4.7 one) with gengtype -D -v -r gtype.state -P _g-tmarkh.h tmarkh.h you can observe that the generated _g-tmarkh.h don't contain any call to mymarker. If the static variable (here myutestptr) is declared with the struct mytest_st* type, the marker is emitted. The reason of that bug is that for GTY-ed union members which are themselves GTY-ed struct, the marking of the nested struct is generated inline (for the union) and in that case the mark_hook annotation was not used. The attached patch to trunk svn rev 191972 solves this issue (with it, the generated _g-tmarkh.h is correctly calling mymarker). The gcc/ChangeLog entry is: ############ 2012-10-02 Basile Starynkevitch * gengtype.c (walk_type): Emit mark_hook when inside a struct of a union member. ############ Ok for trunk? Regards. Index: gcc-trunk-bstarynk/gcc/gengtype.c =================================================================== --- gcc-trunk-bstarynk/gcc/gengtype.c (revision 191972) +++ gcc-trunk-bstarynk/gcc/gengtype.c (working copy) @@ -2810,6 +2810,7 @@ walk_type (type_p t, struct walk_type_data *d) const char *oldval = d->val; const char *oldprevval1 = d->prev_val[1]; const char *oldprevval2 = d->prev_val[2]; + const char *structmarkhook = NULL; const int union_p = t->kind == TYPE_UNION; int seen_default_p = 0; options_p o; @@ -2833,7 +2834,14 @@ walk_type (type_p t, struct walk_type_data *d) if (!desc && strcmp (o->name, "desc") == 0 && o->kind == OPTION_STRING) desc = o->info.string; + else if (!structmarkhook && strcmp(o->name, "mark_hook") == 0 + && o->kind == OPTION_STRING) + structmarkhook = o->info.string; + if (structmarkhook) + oprintf (d->of, "%*s/*structmarkhook %s */ %s (&%s));\n", + d->indent, "", t->u.s.tag, structmarkhook, oldval); + d->prev_val[2] = oldval; d->prev_val[1] = oldprevval2; if (union_p)