Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org>
To: Nils-Christian Kempke <nils-christian.kempke@intel.com>,
	gdb-patches@sourceware.org
Cc: JiniSusan.George@amd.com
Subject: Re: [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile
Date: Wed, 11 May 2022 11:10:37 +0100	[thread overview]
Message-ID: <87czgkl6qq.fsf@redhat.com> (raw)
In-Reply-To: <20220510142437.1397399-5-nils-christian.kempke@intel.com>


I think the subject would be better as 'move local variable ....etc...'

Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
writes:

> The procedure gdb_compile used to query its options via
>
>    [lsearch -exact $options getting_compiler_info]
>
> to check whether or not it was called in with the option
> getting_compiler_info.  If it was called with this option it would
> preprocess some test input to try and figure out the actual compiler
> version of the compiler used.  While doing this we cannot again try
> figure out the current compiler version via the 'getting_compiler_info'
> options as this would cause infinite recursion.  As some parts of the
> procedure do recursively test for the compiler version to e.g. set
> certain flags, at several places gdb_compile queried its options for
> this setting.
>
> In the procedure, there was already a variable 'getting_compiler_info'.
> It was set to the result of the above lsearch, but too late within
> the code.  This lead to a mixture of querying 'getting_compiler_info' or
> doing an lserach on the options passed to the procedure.
>
> I found this inconsistent and instead moved the variable getting_compiler_info
> to the front of the procedure.

Am I correct that this is just a clean up?  And doesn't fix an actual
bug?  That's not a problem, and I think this is a good cleanup, I just
wasn't 100% sure after reading the above.

>                                  It is set to 0 or 1 depending on whether or
> not the argument is found in the procedure's options (just as before)
> and queried instead of doing an lsearch on the procedure options in the
> rest of the procedure.

You can actually use 'true' and 'false' in tcl, and just treat the
variable as a boolean, so....

> ---
>  gdb/testsuite/lib/gdb.exp | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index a6f2d847a5..639a0cd1be 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4378,6 +4378,13 @@ proc gdb_compile {source dest type options} {
>  
>      set outdir [file dirname $dest]
>  
> +    # If this is set, calling test_compiler_info will cause recursion.
> +    if { [lsearch -exact $options getting_compiler_info] == -1 } {
> +	set getting_compiler_info 0

   set getting_compiler_info false

> +    } else {
> +	set getting_compiler_info 1

   set getting_compiler_info true
 
> +    }
> +
>      # Add platform-specific options if a shared library was specified using
>      # "shlib=librarypath" in OPTIONS.
>      set new_options {}
> @@ -4394,7 +4401,7 @@ proc gdb_compile {source dest type options} {
>      # default, unless you pass -Wno-unknown-warning-option as well.
>      # We do that here, so that individual testcases don't have to
>      # worry about it.
> -    if {[lsearch -exact $options getting_compiler_info] == -1
> +    if {$getting_compiler_info == 0

   if {!$getting_compiler_info
       && .... etc ....

Which I think makes it clearer that this is a boolean flag.


>  	&& [lsearch -exact $options rust] == -1
>  	&& [lsearch -exact $options ada] == -1
>  	&& [lsearch -exact $options f90] == -1
> @@ -4405,7 +4412,7 @@ proc gdb_compile {source dest type options} {
>  
>      # Treating .c input files as C++ is deprecated in Clang, so
>      # explicitly force C++ language.
> -    if { [lsearch -exact $options getting_compiler_info] == -1
> +    if { $getting_compiler_info == 0
>  	 && [lsearch -exact $options c++] != -1
>  	 && [string match *.c $source] != 0 } {
>  
> @@ -4426,7 +4433,7 @@ proc gdb_compile {source dest type options} {
>      # Place (and look for) Fortran `.mod` files in the output
>      # directory for this specific test.  For Intel compilers the -J
>      # option is not supported so instead use the -module flag.
> -    if { [lsearch -exact $options f90] != -1 } {
> +    if { $getting_compiler_info == 0 && [lsearch -exact $options f90] != -1 } {
>  	# Fortran compile.
>  	set mod_path [standard_output_file ""]
>  	if [test_compiler_info "gcc-*"] {
> @@ -4439,7 +4446,6 @@ proc gdb_compile {source dest type options} {
>  
>      set shlib_found 0
>      set shlib_load 0
> -    set getting_compiler_info 0
>      foreach opt $options {
>          if {[regexp {^shlib=(.*)} $opt dummy_var shlib_name]
>  	    && $type == "executable"} {
> @@ -4471,8 +4477,8 @@ proc gdb_compile {source dest type options} {
>  	} elseif { $opt == "shlib_load" && $type == "executable" } {
>  	    set shlib_load 1
>  	} elseif { $opt == "getting_compiler_info" } {
> -	    # If this is set, calling test_compiler_info will cause recursion.
> -	    set getting_compiler_info 1
> +	    # Ignore this setting here as it has been treated in the very
> +	    # beginning of this procedure.  Do not append it to new_options.

I think this comment should be reworded as:

	    # Ignore this setting here as it has been handled earlier in
            # this procedure.  Do not append it to new_options as this
            # will cause recursion.


Thanks,
Andrew


>          } elseif {[regexp "^text_segment=(.*)" $opt dummy_var addr]} {
>              if { [linker_supports_Ttext_segment_flag] } {
>                  # For GNU ld.
> -- 
> 2.25.1
>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://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


  reply	other threads:[~2022-05-11 10:11 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 14:24 [PATCH 00/18] Fortran compiler identification and ifx testsuite support Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 01/18] gdb/testsuite: remove F77_FOR_TARGET support Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 02/18] gdb/testsuite: Use -module option for Intel Fortran compilers Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 03/18] gdb/testsuite: Fix fortran types for Intel compilers Nils-Christian Kempke via Gdb-patches
2022-05-11  9:49   ` Andrew Burgess via Gdb-patches
2022-05-11  9:57     ` Kempke, Nils-Christian via Gdb-patches
2022-05-10 14:24 ` [PATCH 04/18] gdb/testsuite: add local variable for passing 'getting_compiler_info' to gdb_compile Nils-Christian Kempke via Gdb-patches
2022-05-11 10:10   ` Andrew Burgess via Gdb-patches [this message]
2022-05-11 14:24     ` Kempke, Nils-Christian via Gdb-patches
2022-05-10 14:24 ` [PATCH 05/18] gdb/testsuite: add Fortran compiler identification to GDB Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 06/18] gdb/testsuite: rename intel next gen c/cpp compilers Nils-Christian Kempke via Gdb-patches
2022-05-11 11:23   ` Andrew Burgess via Gdb-patches
2022-05-11 14:28     ` Kempke, Nils-Christian via Gdb-patches
2022-05-10 14:24 ` [PATCH 07/18] gdb/testsuite: disable charset.exp for intel compilers Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 08/18] testsuite, fortran: make print-formatted.exp more robust Nils-Christian Kempke via Gdb-patches
2022-05-11 11:32   ` Andrew Burgess via Gdb-patches
2022-05-11 14:32     ` Kempke, Nils-Christian via Gdb-patches
2022-05-10 14:24 ` [PATCH 09/18] testsuite, fortran: add required external keyword Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 10/18] testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 11/18] testsuite, fortran: Add '-debug-parameters all' when compiling with ifx Nils-Christian Kempke via Gdb-patches
2022-05-11 11:56   ` Andrew Burgess via Gdb-patches
2022-05-11 14:36     ` Kempke, Nils-Christian via Gdb-patches
2022-05-10 14:24 ` [PATCH 12/18] testsuite/lib: add check_optional_entry for GDBInfoSymbols Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 13/18] testsuite, fortran: fix info-types for intel compilers Nils-Christian Kempke via Gdb-patches
2022-05-11 12:06   ` Andrew Burgess via Gdb-patches
2022-05-11 15:20     ` Kempke, Nils-Christian via Gdb-patches
2022-05-11 16:43       ` Kempke, Nils-Christian via Gdb-patches
2022-05-30 10:33         ` Andrew Burgess via Gdb-patches
2022-05-30 10:32       ` Andrew Burgess via Gdb-patches
2022-05-10 14:24 ` [PATCH 14/18] testsuite, fortran: Add type info of formal parameter for Intel compilers Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 15/18] testsuite, fortran: allow additional completions in module.exp Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 16/18] gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 17/18] gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers Nils-Christian Kempke via Gdb-patches
2022-05-10 14:24 ` [PATCH 18/18] gdb/testsuite: fixup common-block.exp for intel compilers Nils-Christian Kempke via Gdb-patches
2022-05-11 13:29   ` Andrew Burgess via Gdb-patches
2022-05-11 15:31     ` Kempke, Nils-Christian via Gdb-patches
2022-05-16  6:36       ` George, Jini Susan via Gdb-patches
2022-05-16  7:59         ` Kempke, Nils-Christian via Gdb-patches
2022-05-11 13:32 ` [PATCH 00/18] Fortran compiler identification and ifx testsuite support Andrew Burgess via Gdb-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czgkl6qq.fsf@redhat.com \
    --to=gdb-patches@sourceware.org \
    --cc=JiniSusan.George@amd.com \
    --cc=aburgess@redhat.com \
    --cc=nils-christian.kempke@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox