From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31158 invoked by alias); 27 Aug 2010 14:43:57 -0000 Received: (qmail 31149 invoked by uid 22791); 27 Aug 2010 14:43:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Aug 2010 14:43:51 +0000 Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o7REhmW2004869 for ; Fri, 27 Aug 2010 07:43:49 -0700 Received: from pwi10 (pwi10.prod.google.com [10.241.219.10]) by kpbe13.cbf.corp.google.com with ESMTP id o7REhllv032399 for ; Fri, 27 Aug 2010 07:43:47 -0700 Received: by pwi10 with SMTP id 10so1171906pwi.32 for ; Fri, 27 Aug 2010 07:43:47 -0700 (PDT) Received: by 10.142.106.17 with SMTP id e17mr1199771wfc.305.1282920226968; Fri, 27 Aug 2010 07:43:46 -0700 (PDT) Received: from coign.google.com ([66.109.106.2]) by mx.google.com with ESMTPS id q27sm4516380wfc.18.2010.08.27.07.43.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 07:43:45 -0700 (PDT) From: Ian Lance Taylor To: jeremie.salvucci@free.fr Cc: gcc , laurynas , basile Subject: Re: Gengtype : strange code in output_type_enum References: <1360893126.445931282912919305.JavaMail.root@zimbra30-e5.priv.proxad.net> Date: Fri, 27 Aug 2010 15:02:00 -0000 In-Reply-To: <1360893126.445931282912919305.JavaMail.root@zimbra30-e5.priv.proxad.net> (jeremie salvucci's message of "Fri, 27 Aug 2010 14:41:59 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00398.txt.bz2 jeremie.salvucci@free.fr writes: > While hacking on gengtype with Basile, we noticed a strange piece of code at line 2539 in gcc/gengtype.c r162692 > > static void > output_type_enum (outf_p of, type_p s) > { > if (s->kind == TYPE_PARAM_STRUCT && s->u.s.line.file != NULL) /* Strange code @@*/ > { > oprintf (of, ", gt_e_"); > output_mangled_typename (of, s); > } > else if (UNION_OR_STRUCT_P (s) && s->u.s.line.file != NULL) > { > oprintf (of, ", gt_ggc_e_"); > output_mangled_typename (of, s); > } > else > oprintf (of, ", gt_types_enum_last"); > } > > We think that the enum type_kind discriminates fields union in struct type. So for TYPE_PARAM_STRUCT we believe that > the param_struct field of union u inside struct type is used. If this is true, the test s->u.s.line.file != NULL is meaningless when s->kind == TYPE_PARAM_STRUCT, it should be s->u.param_struct.line.file != NULL instead in our opinion. I agree that this is wrong. > However, the existing code appears to work but we don't understand why. That one is fairly easy. If you look at the generated code, you will see that those values are only used to pass to gt_pch_note_object. From there they will eventually be passed to either ggc_pch_count_object or ggc_pch_alloc_object. The default page allocator ignores this type. The zone allocator does use the type, but nobody uses that allocator. And even if you do use the zone allocator, it will work correctly if perhaps suboptimally as long as it always gets the same type for a given struct, which I believe will happen. You should send in a tested patch to fix that problem (and nothing else). Ian