From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WEznKHZ3emIidAUAWB0awg (envelope-from ) for ; Tue, 10 May 2022 10:32:22 -0400 Received: by simark.ca (Postfix, from userid 112) id A48031E21F; Tue, 10 May 2022 10:32:22 -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=maqKFTKP; 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 F10241E01D for ; Tue, 10 May 2022 10:32:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 697EE3954466 for ; Tue, 10 May 2022 14:32:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 697EE3954466 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1652193141; bh=bu7JmlCU80bMlo4QR9Y0Eo1Cz6XxExfYHA8gHLw3M9M=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=maqKFTKPg0uh8otFVmSogr2Es7mzbWt8f1Za61EaEKGV9TZY3DlyTLkOqMDuWZsVm KXgPu+ADj1480yjMD0FAGeKLPmzKba50F1SWcIf8Lf3jwQvDoNz2C7uAzEJUdVePj2 7J+3P29bW3IyGE/TmkWxIQZaxg3MpdcCaBoUjXJQ= Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by sourceware.org (Postfix) with ESMTPS id F1A31395383A for ; Tue, 10 May 2022 14:25:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1A31395383A X-IronPort-AV: E=McAfee;i="6400,9594,10342"; a="266976695" X-IronPort-AV: E=Sophos;i="5.91,214,1647327600"; d="scan'208";a="266976695" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2022 07:25:54 -0700 X-IronPort-AV: E=Sophos;i="5.91,214,1647327600"; d="scan'208";a="570695038" Received: from labpcdell3650-003.iul.intel.com (HELO localhost) ([172.28.49.87]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 May 2022 07:25:53 -0700 To: gdb-patches@sourceware.org Subject: [PATCH 15/18] testsuite, fortran: allow additional completions in module.exp Date: Tue, 10 May 2022 16:24:34 +0200 Message-Id: <20220510142437.1397399-16-nils-christian.kempke@intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220510142437.1397399-1-nils-christian.kempke@intel.com> References: <20220510142437.1397399-1-nils-christian.kempke@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: Nils-Christian Kempke via Gdb-patches Reply-To: Nils-Christian Kempke Cc: JiniSusan.George@amd.com, aburgess@redhat.com Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" For ifort, ifx, and flang the tests "complete modm" and "complete modmany" fail. This is because all three emit additional completion suggestions. These additional suggestions have their origin in symbols emitted by the compilers which can also be completed from the respective incomplete word (modm or modmany). For this specific example gfortran does not emit any additional symbols. For example, in this test the linkage name for var_a in ifx is "modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead. Since modmany_mp_var_a can be completed from modm and also modmany they will get displayed, while gfortran's symbol starts with "__" and thus will be ignored (it cannot be a completion of a word starting with "m"). Similar things happen in flang and ifort. Some example output is shown below: FLANG (gdb) complete p modm p modmany p modmany::var_a p modmany::var_b p modmany::var_c p modmany::var_i p modmany_ IFX/IFORT (gdb) complete p modm p modmany p modmany._ p modmany::var_a p modmany::var_b p modmany::var_c p modmany::var_i p modmany_mp_var_a_ p modmany_mp_var_b_ p modmany_mp_var_c_ p modmany_mp_var_i_ GFORTRAN (gdb) complete p modm p modmany p modmany::var_a p modmany::var_b p modmany::var_c p modmany::var_i I want to emphasize: for Fortran (and also C/C++) the complete command does not actually check whether its suggestions make sense - all it does is look for any symbol (in the minimal symbols, partial symbols etc.) that a given substring can be completed to (meaning that the given substring is the beginning of the symbol). One can easily produce a similar output for the gfortran compiled executable. For this look at the slightly modified "complete p mod" in gfortran: (gdb) complete p mod p mod1 p mod1::var_const ... p mod_1.c p modcounter p mode_t p modf ... p modify_ldt p modmany p modmany::var_a p modmany::var_b p modmany::var_c p modmany::var_i p module p module.f90 p module_entry p moduse p moduse::var_x p moduse::var_y Many of the displayed symbols do not actually work with print: (gdb) p mode_t Attempt to use a type name as an expression (gdb) p mod_1.c No symbol "mod_1" in current context. (gdb) I think that in the given test the output for gfortran only looks nice "by chance" rather than is actually expected. Expected is any output that also contains the completions p modmany p modmany::var_a p modmany::var_b p modmany::var_c p modmany::var_i while anythings else can be displayed as well (depending on the compiler and its emitted symbols). This, I'd consider all three outputs as valid and expected - one is just somewhat lucky that gfortran does not produce any additional symbols that got matched. The given patch improves test performance for all three compilers by allowing additional suggested completions inbetween and after the two given blocks in the test. I did not allow additional print within the modmany_list block since the output is ordered alphabetically and there should normally not appear any additional symbols there. For flang/ifx/ifort I each see 2 failures less (which are exactly the two complete tests). As a side note and since I mentioned C++ in the beginning: I also tried the gdb.cp/completion.exp. The output seems a bit more reasonable, mainly since C++ actually has a demangler in place and linkage symbols do not appear in the output of complete. Still, with a poor enough to-be-completed string one can easily produce similar results: (gdb) complete p t ... p typeinfo name for void p typeinfo name for void const* p typeinfo name for void* p typeinfo name for wchar_t p typeinfo name for wchar_t const* p typeinfo name for wchar_t* p t *** List may be truncated, max-completions reached. *** (gdb) p typeinfo name for void* No symbol "typeinfo" in current context. (gdb) complete p B p BACK_SLASH p BUF_FIRST p BUF_LAST ... p Base p Base::Base() p Base::get_foo() p bad_key_err p buf p buffer p buffer_size p buflen p bufsize p build_charclass.isra (gdb) p bad_key_err No symbol "bad_key_err" in current context. (compiled with gcc/g++ and breaking at main). This patch is only about making the referenced test more 'fair' for the other compilers. Generally, I find the behavior of complete a bit confusing and maybe one wants to change this at some point but this would be a bigger task. --- gdb/testsuite/gdb.fortran/module.exp | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gdb/testsuite/gdb.fortran/module.exp b/gdb/testsuite/gdb.fortran/module.exp index b00122a037..1895a20079 100644 --- a/gdb/testsuite/gdb.fortran/module.exp +++ b/gdb/testsuite/gdb.fortran/module.exp @@ -118,9 +118,10 @@ gdb_test "print var_z" " = 31" "print var_x value 31" gdb_test "ptype modmany" "type = module modmany" proc complete {expr list} { + set n_lines "\(?:\\r\\n.*\)*" set cmd "complete p $expr" - set expect [join [concat [list $cmd] $list] "\r\np "] - gdb_test $cmd $expect "complete $expr" + set expect [join [concat [list $cmd] $list] $n_lines] + gdb_test $cmd "$expect$n_lines" "complete $expr" } set modmany_list {modmany::var_a modmany::var_b modmany::var_c modmany::var_i} complete "modm" "modmany $modmany_list" -- 2.25.1 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