From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16293 invoked by alias); 27 Aug 2010 12:42:17 -0000 Received: (qmail 16277 invoked by uid 22791); 27 Aug 2010 12:42:16 -0000 X-SWARE-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtp3-g21.free.fr (HELO smtp3-g21.free.fr) (212.27.42.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Aug 2010 12:42:08 +0000 Received: from zimbra30-e5.priv.proxad.net (unknown [172.20.243.180]) by smtp3-g21.free.fr (Postfix) with ESMTP id 7A732818167; Fri, 27 Aug 2010 14:42:00 +0200 (CEST) Date: Fri, 27 Aug 2010 12:49:00 -0000 From: jeremie.salvucci@free.fr To: gcc Cc: laurynas , basile Message-ID: <1360893126.445931282912919305.JavaMail.root@zimbra30-e5.priv.proxad.net> Subject: Gengtype : strange code in output_type_enum MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated-User: jeremie.salvucci@free.fr 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/msg00388.txt.bz2 Hello all, 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. However, the existing code appears to work but we don't understand why. Or can a type have a kind TYPE_PARAM_STRUCT and only have s->u.s valid? It might be related to the code in new_structure near line 638 of gengtype.c which sets ls->kind = TYPE_LANG_STRUCT. Perhaps TYPE_PARAM_STRUCT has two different roles. If that is indeed the case, we have to distinguish them when serializing gengtype's state. Cheers. -- Jeremie Salvucci & Basile Starynkevitch