From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21950 invoked by alias); 9 May 2015 11:31:50 -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 21919 invoked by uid 89); 9 May 2015 11:31:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 09 May 2015 11:31:47 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id A07BB27D1444; Sat, 9 May 2015 13:31:43 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfDEGywGP3ny; Sat, 9 May 2015 13:31:43 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 7B7FF27D143C; Sat, 9 May 2015 13:31:43 +0200 (CEST) From: Eric Botcazou To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org, Richard Biener Subject: Re: [patch 1/10] debug-early merge: Ada front-end Date: Sat, 09 May 2015 11:31:00 -0000 Message-ID: <13015161.AmsL9u3xPQ@polaris> User-Agent: KMail/4.7.2 (Linux/3.1.10-1.29-desktop; KDE/4.7.2; x86_64; ; ) In-Reply-To: <554CD4B2.3020509@redhat.com> References: <554C0417.8020300@redhat.com> <554CD4B2.3020509@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart9420114.7E8nYBpJu0" Content-Transfer-Encoding: 7Bit X-SW-Source: 2015-05/txt/msg00817.txt.bz2 --nextPart9420114.7E8nYBpJu0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 918 > My question exactly. Perhaps that was my confusion. Why is this using > ->global_decl? Because that's equivalent to ->type_decl (iter, false) in DWARF. > For example, the C front-end uses rest_of_type_compilation (see > finish_struct() in c/c-decl.c) which calls ->type_decl(), or it calls > ->type_decl() from record_builtin_type(). All right, let's follow the gospel then. :-) Patch attached and installed. > I can put the code back, but calling ->type_decl()? Assuming you folks > (Ada) don't want to use rest_of_type_compilation(). No, we don't use it for local types either (it's a no-op in DWARF in this case and we don't support STABS anymore because of the need to manually delay the generation of debug info for local types, which is a real pain in Ada). * gcc-interface/utils.c (gnat_write_global_declarations): Use type_decl method instead of global_decl for TYPE_DECLs. -- Eric Botcazou --nextPart9420114.7E8nYBpJu0 Content-Disposition: attachment; filename="p.diff" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="utf-8"; name="p.diff" Content-length: 574 Index: gcc-interface/utils.c =================================================================== --- gcc-interface/utils.c (revision 222673) +++ gcc-interface/utils.c (working copy) @@ -5211,7 +5211,7 @@ gnat_write_global_declarations (void) finalized in the right context. */ FOR_EACH_VEC_SAFE_ELT (global_decls, i, iter) if (TREE_CODE (iter) == TYPE_DECL && !DECL_IGNORED_P (iter)) - debug_hooks->global_decl (iter); + debug_hooks->type_decl (iter, false); /* Proceed to optimize and emit assembly. */ symtab->finalize_compilation_unit (); --nextPart9420114.7E8nYBpJu0--