From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5CBgC9jne2JErgUAWB0awg (envelope-from ) for ; Wed, 11 May 2022 12:44:08 -0400 Received: by simark.ca (Postfix, from userid 112) id 1DD451E220; Wed, 11 May 2022 12:44:08 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=bdzUAVM5; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DE7091E00D for ; Wed, 11 May 2022 12:44:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5778B385E02E for ; Wed, 11 May 2022 16:44:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5778B385E02E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1652287443; bh=587CYJOTl57OJ5fF4e17EqQPhmB2KYxXvHyNt5J+RcE=; h=To:Subject:Date:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=bdzUAVM5Jee36bStrpUo6gKY5eraCyTuDBeXfjVTtJ8gftLSOPWFF5ZsmFRPTatMC 6jGpzlPEDdtHquqlDymK4cACqEk79wM0dA7mOPQYTxXF1NOl+/PFuThmXWkcL3haTb XFy7+fAMiXgFDLDG3VOyaWbLzZ7KoX6sXZoy/pz8= Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by sourceware.org (Postfix) with ESMTPS id C1D273858CDA for ; Wed, 11 May 2022 16:43:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C1D273858CDA X-IronPort-AV: E=McAfee;i="6400,9594,10344"; a="267338367" X-IronPort-AV: E=Sophos;i="5.91,217,1647327600"; d="scan'208";a="267338367" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 May 2022 09:43:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,217,1647327600"; d="scan'208";a="895420705" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga005.fm.intel.com with ESMTP; 11 May 2022 09:43:38 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 11 May 2022 09:43:37 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 11 May 2022 09:43:36 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Wed, 11 May 2022 09:43:36 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.109) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Wed, 11 May 2022 09:43:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MWm2zzAohK4D6R3sNL4bQsc21VVuVc6Xp2bXkFLmAjXjUXpCxINQUtjUUc8OD+AkOa3ppWRLBlt3VVbj+62MnymYIWB/5eks/+IQCPioNuezMpEmAlYm+9vj9qPHBBz+aaXVuNP2zLbJmElcPVn5IASr6hGgat6IfMfIoDvd5bJ0ADRsCfWVH+g0zeYWc/7gZbzN9aTj3HryGJHaX3uMMMKKEJjKFbZNqeQ6Doz7sOjc2Bnm5uWPKbkwyGf1Q+S7GPZi6RctYCJS4kW2bGPVvwkn0AzCUy+GlDCDZxuDscJVNHNtHw6x0XLFK1KUU8N+SFpddSMvrtWI4T/PMAJ6+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uai3mb7NyrY1tVyc0y3dVYqGjDK6AQni2VjLk+95jjY=; b=W11uKpPa8OXWI63wChEVOELmAr0Doi8M98wk6iFzFz9tse8yPYz5gIlNBxB4F0nJjz+8mjdpsJgzBuLdBg0IGCGAOzJjtclJasi75j5JauFK9vJchNLBtam9ukt30dvZzmK8RQC9BolG0ZjIF2wabfBTdem633HfAEXfsiSgs1JPrr7wT+yA7r2HrLdpj/IsehoD+KM3z/lQVYSx2Cd/nsPO6trtoQkGUJ0acBrTRH/4a6XRgrRNCdK1f15HRYiq+8LUzXzbALtNDE8srvBySSIpp5FPIf1V+Ld/rgPwnaoVh8yGwU7nABhysK3wcnxsNL3SYIBo6EU14iVcQNYlgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from CY4PR1101MB2071.namprd11.prod.outlook.com (2603:10b6:910:1a::10) by DM5PR11MB1514.namprd11.prod.outlook.com (2603:10b6:4:7::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13; Wed, 11 May 2022 16:43:33 +0000 Received: from CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::403f:f9f0:74f2:c5b9]) by CY4PR1101MB2071.namprd11.prod.outlook.com ([fe80::403f:f9f0:74f2:c5b9%10]) with mapi id 15.20.5250.013; Wed, 11 May 2022 16:43:33 +0000 To: "Kempke, Nils-Christian" , Andrew Burgess , "gdb-patches@sourceware.org" Subject: RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Thread-Topic: [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Thread-Index: AQHYZHne4/ymlWBrvkCCRr2YwCAvkq0ZliGAgAAp/GCAABuDYA== Date: Wed, 11 May 2022 16:43:33 +0000 Message-ID: References: <20220510142437.1397399-1-nils-christian.kempke@intel.com> <20220510142437.1397399-14-nils-christian.kempke@intel.com> <87zgjojmt8.fsf@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.401.20 dlp-reaction: no-action x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13a0fca3-6de1-4f8b-720a-08da336d6344 x-ms-traffictypediagnostic: DM5PR11MB1514:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dByH88TA74LuGb2Xns34fdD16icGa1xaO40CsWYLiBM+DTPpaceqQnQ4NJu7Jlpn+ORNXxmB8iLUkQdNbplvT2c0/GLxQrEGHcx1M+wtf7rBlfRurmk5x2m/fujhdD8b1THyLUmFmUXpE6XRm6/h6EyVuKHGyXnvLbzdaXtaOCVMPo3bMY/1lXqfs5IKAElSXxFttrr1vKXAtbcHV0234OZEwMpWa6asiUkm9yPks/kNIQAHLwYgGtj73dczF9fgB0uJ/WuqZgOfXARVPil6SsTR0QqMhjJkdeTp3/d5T5y1VnXUgwysRb1Ba0wWuEIB15iXYRz2JJ2eCbe0u3m/A08NLGEmrj4yPQGs/XJAwCqvMNcQCpDkj8ojKLIJ7zr5rwEWHsmKgiaFLcX98IJ5vEkJxHB5xYZtP4Lo/0QOSKevbWZhrVYwwSVb2UVU2X9iXWL27iyU690SgMZEx9ceWSWpWIaU8lBPNn+afTA29yiLaI6F8f/KUJMrzMVweRflTDeyu8aFdA10MAWc+wX771BsqX9y8VvVx88b6dAGXmzL31nTPZKkSYaFPqERuqfEh3HveaNAzs2e1JjPsKftRinwVk6wyxkT2LTUG1ovE+7NzsPEESp9JwL37uS43XtV/K6eNZHnL76Lorrx8Eea3bxU11CgXujEL8XTuOXDg2g+lO2qdY37d1WtPcimlsuSLru8HVNK59uP4oa5Tk5Jtk0+LtYCU0rwrfvayAKHad8qsmz9oja0Eo1+2XhdTqtYX4ZtaDgAY0QSe/9iyeSovTx2jIHcpksNRLEfhhLFOKA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2071.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(52536014)(2906002)(86362001)(966005)(2940100002)(110136005)(26005)(9686003)(71200400001)(53546011)(316002)(186003)(6506007)(55016003)(66476007)(8676002)(66946007)(66446008)(66556008)(64756008)(76116006)(82960400001)(30864003)(508600001)(5660300002)(8936002)(33656002)(83380400001)(7696005)(122000001)(38100700002)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?krK5wO+D5MQBtHAEm874DHm8p5ATEx1TjwgO7l0VUiqOMV91q4W1Wscn0Chr?= =?us-ascii?Q?8NIf+j0HuQ8g8hoi4y42tgArsLDjt7PzXUUeGxFemKhVeGL4ORpnX9c94LFB?= =?us-ascii?Q?/hLAte6fU2wlhrYMxy3D3CohqupvpGUD7nPSKyuzAmp23aKLpcBw2ffWcNJT?= =?us-ascii?Q?bRw3JxBZzlZEHdHEyrp9OncYUeBp2+pxyDnmH+Xq7cJrDLl41aaNTjIbB1Wk?= =?us-ascii?Q?UDKLzJnB+9R8QPQi0Pi62h6rSdIcN5808FQIRt5WP6IxJD06+icfD6h/5Npk?= =?us-ascii?Q?GsLQJ/tXASE5VQxQq6AhS0haXWTwhhU99xmwmRucU1YaVoQ8+lQZw8NxcJaH?= =?us-ascii?Q?OGDQuUhLZccLCu2QYwgfuMJeSlp5kL/96XjpR6PeeDRSWFUUiZ675fN/baHU?= =?us-ascii?Q?XfZGM0nPWb7oZh1knj0aAUa4gURPpgKsSXETRHdV1wNbNNO2+d1AHlOAaZQy?= =?us-ascii?Q?gJaObQTk2+GjERd/DbE+IVTRCVap2j4HsW2o5cTZERJj+NELS0UrKkz9yxEe?= =?us-ascii?Q?9MYWV+1QJeHwRiw5K82qMqfOjvxzDMoJQjjWxZvnKd0y5yDKxtEAv5DDFYgc?= =?us-ascii?Q?+Mpi7NF0Tg47OgKc/fe84iDMpYhtxwrO3oqNevd4arKf8DZJtOVNE1FkPP8U?= =?us-ascii?Q?YEQlIgDziTzEOf9boYAz1TOvfcteS4+g/xm2f4MAXwmRVlvSeWQ2WBZfP2bo?= =?us-ascii?Q?CqULJTf6F+MXsDxxGl6WTkCKCruOSjpKurQFYw8fU5N8aKT2m44bu9f7EhFC?= =?us-ascii?Q?HTk2jNTqaaQoGgIIMVZIDnZhZIdQ3aDS4IUtM0bWX55E84/7r+GCFDrSg+G+?= =?us-ascii?Q?LQVmcmq8cAjmfo0wxzyh1YbetwBZu0gdKpG9pV/HpSOYJt4MOKRdwr9rL7vK?= =?us-ascii?Q?pBQ2bt1zI6MM2fIwEjDZTCxZ/5Tb4PSQOPNCpWEF2Y4QONtT8N+SKHNAO9i+?= =?us-ascii?Q?HJNxpxxT5D6YfNFb4MJcuo6EXtxZiAllIxfF9Bk1eFWgwExpBtQ5mENlxti/?= =?us-ascii?Q?v5c9JHqZlgx+IMRVpwMZiydkU/z843bCn6trKnrfhfGhZnbcMdrmoMi4eFzl?= =?us-ascii?Q?t4+boHNeInHGvpm8AW7Qp82WXL8wNj51/tMOWGZHlsrIy8GEhiYSE4yPrHol?= =?us-ascii?Q?X104ttJa4OHRfgjmrgG2mj8eU5av+oLVw8J7Nf412gb1Y4EIv20eJx6YG7B3?= =?us-ascii?Q?05tvlqcSVqkz/l38h6b5IRWxBM7Z7zlXNJNeQbwRi27w0fW/MSN8fI1eoamI?= =?us-ascii?Q?INLsbKt71PtPHmOtzjRjHFRWWl62qytSptvmf0xLE0mQdpqdpLyqT5OtHFZW?= =?us-ascii?Q?mBAqpdMok4WkRdMGPQMsTcSIZHawgpGBuVt168g8v5QkZvqyDsiB4zNJ8bmR?= =?us-ascii?Q?/Pa5k1wlPhuKt/g61734GE/tIaEpaIol03qfXM06jENYxI8o8i4fA/4YcwAj?= =?us-ascii?Q?Hh0yR1FuY7NaYJayRiDrC9Cw0yTnJ6QK6HrPZLSM8NuwhHnbBkX5U2k+iM8G?= =?us-ascii?Q?Bq/VrIng/CbgO4vwAG+M9gBALJem9wlT7DEVxCaRvP8V8dCWnbkgkYjCtlF+?= =?us-ascii?Q?pCv9YcugkzLDLQyyTyF8YljO3zoNzD/TPQ21VqsY1GH2juTvjLAlskdxTs2M?= =?us-ascii?Q?UPZiWQDfuuE1EcrVjeEEAPrPDfLlyevnlBe4YJNeDB6YlBFj3CECoj6gcbyl?= =?us-ascii?Q?MgGZvvDqp/7R1S93nUy3qo3ZA928WA9J9dvqIjKHiFqDg+K8OgUSbdbfNaEU?= =?us-ascii?Q?C14jT9iLj5ewWYxkwfakwQP1/rBajrc=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY4PR1101MB2071.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13a0fca3-6de1-4f8b-720a-08da336d6344 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2022 16:43:33.6072 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: shRWH+PmVexaO/JfYyqloEosfplQ5ZQAZ6bzVRuB9tyHD31HSiyMEd66NPoR7eu0Fo3Nrl5JG5/EOjn1SEDnjRySXpRGUfNAU2WTLV+Jy80= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1514 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "Kempke, Nils-Christian via Gdb-patches" Reply-To: "Kempke, Nils-Christian" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > -----Original Message----- > From: Gdb-patches christian.kempke=3Dintel.com@sourceware.org> On Behalf Of Kempke, Nils- > Christian via Gdb-patches > Sent: Wednesday, May 11, 2022 5:20 PM > To: Andrew Burgess ; gdb- > patches@sourceware.org > Subject: RE: [PATCH 13/18] testsuite, fortran: fix info-types for intel > compilers > = > > -----Original Message----- > > From: Andrew Burgess > > Sent: Wednesday, May 11, 2022 2:06 PM > > To: Kempke, Nils-Christian ; gdb- > > patches@sourceware.org > > Cc: JiniSusan.George@amd.com; Kempke, Nils-Christian > christian.kempke@intel.com> > > Subject: Re: [PATCH 13/18] testsuite, fortran: fix info-types for intel > > compilers > > > > Nils-Christian Kempke writes: > > > > > First, the emitted symbol character*1 which is checked in the test > > > is not even referenced as a type in the compiled examples. It seems > > > to be a gfortran specific check for some type that gets emitted alway= s. > > > I changed the test to use check_optional_entry here to allow the > > > symbol's absence. > > > > > > Second, the line checked for s1 was hardcoded in the test. Given that > > > the type is actually defined on line 41 (which is what is emitted by > > > ifx) it even seems wrong. I changed the line check for s1 to actually > > > check for 41 and a gfortran bug has been filed here > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105454 > > > > > > The test is now marked as xfail for gfortran. > > > > > > Third, the test was checking for s1 to be emitted by info types. This > > > would mean that the type is put into compilation unit scope in the > DWARF > > > but, as it is local to the main program this is actually not expected > > > and gfortran specific. > > > Since I already added the xfail for gfortran here, I opted to also ma= ke > > > this check gfortran specific. > > > --- > > > gdb/testsuite/gdb.fortran/info-types.exp | 10 +++++++--- > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/gdb/testsuite/gdb.fortran/info-types.exp > > b/gdb/testsuite/gdb.fortran/info-types.exp > > > index 67fe4d79c5..06770aada1 100644 > > > --- a/gdb/testsuite/gdb.fortran/info-types.exp > > > +++ b/gdb/testsuite/gdb.fortran/info-types.exp > > > @@ -41,12 +41,16 @@ set real4 [fortran_real4] > > > GDBInfoSymbols::run_command "info types" > > > GDBInfoSymbols::check_header "All defined types:" > > > > > > -GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}" > > > +GDBInfoSymbols::check_optional_entry "${srcfile}" "" "${character1}" > > > > Could we not just add a reference to character*1 type? I'm happy to > > take this change, but just adding a use might make a stronger test? > = > Yes, I'll do that. It is true, there will be a bit more coverage. > = > > > GDBInfoSymbols::check_entry "${srcfile}" "" "${integer4}" > > > GDBInfoSymbols::check_entry "${srcfile}" "" "${logical4}" > > > GDBInfoSymbols::check_entry "${srcfile}" "$decimal" "Type m1t1;" > > > GDBInfoSymbols::check_entry "${srcfile}" "" "${real4}" > > > -GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;" > > > + > > > +if { [test_compiler_info {gfortran-*} f90] } { > > > + setup_xfail *-*-* gcc/105454 > > > + GDBInfoSymbols::check_entry "${srcfile}" "41" "Type s1;" > > > +} > > > > Shouldn't the GDBInfoSymbols::check_entry call be outside of the if > > block? I think, with your change, the test will _only_ be run on > > gfortran, which is not what you wanted. > = > Mh - so actually this is what I wanted. In my opinion emitting s1 here > is actually not expected. The type s1 is defined inside the Fortran prog= ram. > E.g. ifx also emits it as a child of the program - limiting its scope to = that. > = > Gfortran on the other hand emits it at global CU scope (so not as a child= of > the program info_types_test). I think the fact that this type is visible= via info > types is not correct here. But, since this emission is also buggy I did = not want > to delete the test in order to somehow keep track of this line bug. > = > So I changed the test to only test for this type when ran with gfortran. > = > My baseline assumption here is, that gdb in the test only prints types in= the > 'info types' command that are defined at CU DWARF scope. At least it loo= ks > like this when compiling with ifx (which, as said, emits the Type s1 as a= child > of the program info_types_test). > = > When checking this compiled with ifx I see in the DWARF > = > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > <1><1d5>: Abbrev Number: 12 (DW_TAG_subprogram) > <1d6> DW_AT_low_pc : 0x4055b0 > <1de> DW_AT_high_pc : 0x42 > <1e2> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp)) > <1e4> DW_AT_linkage_name: (indirect string, offset: 0x224): MAIN__ > <1e8> DW_AT_name : (indirect string, offset: 0x22b): info_ty= pes_test > <1ec> DW_AT_decl_file : 1 > <1ed> DW_AT_decl_line : 37 > <1ee> DW_AT_external : 1 > <1ee> DW_AT_main_subprogram: 1 > ... > <2><239>: Abbrev Number: 14 (DW_TAG_structure_type) > <23a> DW_AT_name : (indirect string, offset: 0x1d4): s1 > <23e> DW_AT_byte_size : 4 > <23f> DW_AT_decl_file : 1 > <240> DW_AT_decl_line : 41 > <3><241>: Abbrev Number: 15 (DW_TAG_member) > <242> DW_AT_name : (indirect string, offset: 0x207): a > <246> DW_AT_type : <0x1ce> > <24a> DW_AT_decl_file : 1 > <24b> DW_AT_decl_line : 41 > <24c> DW_AT_data_member_location: 0 > <24d> DW_AT_accessibility: 1 (public) > <3><24e>: Abbrev Number: 0 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = > So s1 is being emitted but as a child of MAIN__. With gfortran on the oth= er > hand I get > = > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > <1><2ec>: Abbrev Number: 18 (DW_TAG_structure_type) > <2ed> DW_AT_name : s1 > <2f0> DW_AT_byte_size : 4 > <2f1> DW_AT_decl_file : 1 > <2f2> DW_AT_decl_line : 37 > <2f3> DW_AT_sibling : <0x302> > <2><2f7>: Abbrev Number: 4 (DW_TAG_member) > <2f8> DW_AT_name : a > <2fa> DW_AT_decl_file : 1 > <2fb> DW_AT_decl_line : 42 > <2fc> DW_AT_type : <0x2bf> > <300> DW_AT_data_member_location: 0 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = > emitted as a child of the whole compile unit. > = > It might be, that this is actually not the expected behavior of GDB here. > But it seems, that types defined as children of subroutines will not be > displayed by 'info types'. > = > Similarly, I looked at this in c++ and we have the same here: Compiling > = > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > int main (int argc, char *argv[]) > { > struct test {}; > = > test a; > return 0; > } > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = > With gcc -O0 -g (version 9.4.0) will emit DWARF like: > = > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram) > <2e> DW_AT_external : 1 > <2e> DW_AT_name : (indirect string, offset: 0xb4): main > <32> DW_AT_decl_file : 1 > <33> DW_AT_decl_line : 1 > <34> DW_AT_decl_column : 5 > <35> DW_AT_type : <0xf7> > <39> DW_AT_low_pc : 0x1129 > <41> DW_AT_high_pc : 0x16 > <49> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame= _cfa) > <4b> DW_AT_GNU_all_call_sites: 1 > <4b> DW_AT_sibling : <0xf7> > <2><4f>: Abbrev Number: 3 (DW_TAG_formal_parameter) > ... > <2><6d>: Abbrev Number: 4 (DW_TAG_structure_type) > <6e> DW_AT_name : (indirect string, offset: 0xf): test > <72> DW_AT_byte_size : 1 > <73> DW_AT_decl_file : 1 > <74> DW_AT_decl_line : 3 > <75> DW_AT_decl_column : 10 > <76> DW_AT_sibling : <0xe9> > <3><7a>: Abbrev Number: 5 (DW_TAG_subprogram) > ... > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = > So the type of test is not emitted at CU level, but as a child of main. > Doing > = > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > (gdb) info types > All defined types: > = > File ./c.cpp: > char > int > (gdb) start > ... > 6 return 0; > (gdb) info types test > All types matching regular expression "test": > (gdb) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > will also not emit the type. > = > So either this is wrong in GDB - or the emission of the type at global le= vel > is not quite correct here and should not even be tested. > = > I see that my commit message does not quite cover all this though. > But what do you think? > = > Thanks, > Nils > = I dug into this a bit more .. It seems indeed that the symbols are only searched at a global level. In symtab.c:add_matching_symbols which is called as a result of e.g. 'info types' we only search the symbols put into either the block GLOBAL_BLOCK, or STATIC_BLOCK. According to block.h = The GLOBAL_BLOCK contains all the symbols defined in this compilation whose scope is the entire program linked together. The STATIC_BLOCK contains all the symbols whose scope is the entire compilation excluding other separate compilations. so indeed, I would not expect these local symbols to appear when typing 'info symbols'/'info types' in GDB. So, I think the emission of s1 in 'info types' when compiled with gfortran Is wrong (and likely this should also become a GCC/gfortran bug). It does n= ot happen with ifx or flang. About the second comment on this patch: > > > -GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}" > > > +GDBInfoSymbols::check_optional_entry "${srcfile}" "" "${character1}" > > > > Could we not just add a reference to character*1 type? I'm happy to > > take this change, but just adding a use might make a stronger test? > = > Yes, I'll do that. It is true, there will be a bit more coverage. It is actually difficult to do this. I added this line to the test (in thi= s case to the program info_types_test): character(kind=3D1) :: d =3D 'c' Adding a character to the executable and compiling it with ifx or gfortran will not trigger the emission of an additional type though. In fact, neith= er, gfortran, nor ifx emit the type of variable d as ${character1}, e.g. charac= ter*1: gfortran this type is described as ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <2><32e>: Abbrev Number: 21 (DW_TAG_variable) <32f> DW_AT_name : d <331> DW_AT_decl_file : 1 <332> DW_AT_decl_line : 45 <333> DW_AT_type : <0x365> ... <1><365>: Abbrev Number: 25 (DW_TAG_string_type) <366> DW_AT_byte_size : 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and IFX will describe the character type not with a = ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <2><24f>: Abbrev Number: 13 (DW_TAG_variable) <250> DW_AT_name : (indirect string, offset: 0x1f7): d <254> DW_AT_type : <0x286> <258> DW_AT_decl_file : 1 <259> DW_AT_decl_line : 45 <25a> DW_AT_location : 9 byte block: 3 a0 f3 48 0 0 0 0 0 (DW= _OP_addr: 48f3a0) <264> DW_AT_linkage_name: (indirect string, offset: 0x205): info_type= s_test_$D ... <1><286>: Abbrev Number: 18 (DW_TAG_string_type) <287> DW_AT_name : (indirect string, offset: 0x1f9): CHARACTER= _0 <28b> DW_AT_byte_size : 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I also tried lines like character*1 :: d =3D 'c' and character :: d =3D 'c' but all three were emitted as the same string_type in DWARF. So, to conclude, I do not even know whether it is possible to actually get gfortran to emit a type called character*1 naturally.. The only place within the Fortran testsuite where a check for the compiler dependent type fortran_character1 exists is info-types. The problem with the emission as DW_TAG_string_type is that this will not make GDB generate a symbol for the type - in read.c it says /* These dies have a type, but processing them does not create a symbol or recurse to process the children. Therefore we can read them on-demand through read_type_die. */ So for this part, I think the type should not be emitted at all. I do also= not think that it is wrong DWARF to emit the character*1 as a string_type of length 1. Btw. when printing the type in gdb this is hidden as Fortran string types are printed as character*DW_AT_byte_size, so for ifx or gfortran we get (gdb) ptype d type =3D character*1 I lastly checked this with flang and here, finally, we get a character base= type emitted as ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <2><29b>: Abbrev Number: 16 (DW_TAG_variable) <29c> DW_AT_name : (indirect string, offset: 0x1b9): d <2a0> DW_AT_type : <0x372> ... <1><372>: Abbrev Number: 10 (DW_TAG_base_type) <373> DW_AT_name : (indirect string, offset: 0x1ad): character <377> DW_AT_encoding : 5 (signed) <378> DW_AT_byte_size : 1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ which, rightfully, made GDB emit a type called 'character' in the 'info typ= es'. I think we should keep the check for the character type optional, even when adding a line that actually uses it to the test (as only flang DWARF emits = it). The other alternative is to remove this check completely which I also think= is ok. There should be a gfortran bug filed about the emission of this character*1= , too though. Cheers, Nils Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928