public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 0/2] Fix regressions introduced by Fortran compiler identification series
@ 2022-06-03  8:54 Nils-Christian Kempke
  2022-06-03  8:54 ` [PATCH 1/2] gdb/testsuite: use test_compiler_info in gcc_major_version Nils-Christian Kempke
  2022-06-03  8:54 ` [PATCH 2/2] gdb/testsuite: cache compiler_info on a per language basis Nils-Christian Kempke
  0 siblings, 2 replies; 3+ messages in thread
From: Nils-Christian Kempke @ 2022-06-03  8:54 UTC (permalink / raw)
  To: gdb-patches; +Cc: aburgess, JiniSusan.George, tdevries, Nils-Christian Kempke

After pushing a series that introduced a separate Fortran compiler
identification mechanism to the testsuite

https://sourceware.org/pipermail/gdb-patches/2022-May/189604.html

Regressions were found as noted here

https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html

and here

https://sourceware.org/pipermail/gdb-patches/2022-June/189679.html

The first email noted, that running the whole testsuite would cause
regressions.  Likely due to the caching of the compiler info throughout
the testsuite.

When running the whole testsuite the fist call to get_compiler_info or
test_compiler_info would set the global compiler_info variable.  Every
subsequent call to get/test_compiler_info would simply check wether
compiler_info had already been set and, if so, omit running the actual
compiler identification and return compiler_info instead.

I changed this behavior to now have several cache variables, one for
each language that can be passed to get/_test_compiler_info (which
would be the default C, Cpp and Fortran).

I could only reporduce the regressions by running

  make check

without any parallelism in the testsuite folder.  Running with any amount
of thread via

  make ckeck -jN

where N could even be 1 in my tests (if I did not make some kind of
mistake here).  I still feel like running make check with any kindo of
parallelism run every single testcase individually (likely distributed
to the available threads).

Either way, after this patch the regressions I could reproduce with make
check are gone and testsuite performance should be ok again.

As to the second part of these regressions: I noticed that after running
`make check` with failing gdb.fortran test additional `.mod` files were
created in the gdb/testsuite directory.  I think these ended up there
for the same reason we saw the regressions.  In gdb.exp the `-J` option
is set for the executable whenever compiling with gfortran - it indicates
the target directory for the compiled module files gfortran generates (or
read in if they are already compiled).  As the compiler was firstly
identified as `gcc..` this parameter was not set when compiling the
Fortran test and, as a result, all mod files ended up in the current
working directory.  This did not seem to have any effect on the first
run.  However, any subsequent run of the testsuite would now show this
fail (even when running gdb.fortran/info-types.exp individually):

  gdb compile failed, /.../gdb//testsuite/gdb.fortran/info-types.f90:47:14:

     47 |   type (m1t1) :: var_b
        |              1
  Error: Derived type 'm1t1' at (1) is being used before it is defined
  /.../gdb/testsuite/gdb.fortran/info-types.f90:50:9:

     50 |   var_b%b = 2
        |         1
    Error: Symbol 'var_b' at (1) has no IMPLICIT type

additonal fails, as compiling the executables would attempt to use these
`.mod` already in the directory.  The m1t1 type is declared in a module
called `mod1`, which also is being used in the failed tests
nested-funcs.exp and module.exp.  For the last two, mod1 actually looks
the exact same - only the version for info-types.exp differs.  The mod1
file in the directory (for me at least) was created by the latter 2 - so
while the latter 2 tests would pass, the info-types.exp could not as
`mod1.mod` does not contain the necessary definitions.

This error should not happen anymore after this series as the original
problems with caching the compiler name should have been eliminated.
Another solution here would be to simply delete the `.mod` file in the
testsuite directory.

Cheers,

Nils


Nils-Christian Kempke (2):
  gdb/testsuite: use test_compiler_info in gcc_major_version
  gdb/testsuite: cache compiler_info on a per language basis

 gdb/testsuite/lib/compiler.F90 | 14 ++++----
 gdb/testsuite/lib/compiler.c   | 18 +++++-----
 gdb/testsuite/lib/compiler.cc  | 18 +++++-----
 gdb/testsuite/lib/gdb.exp      | 66 +++++++++++++++++++++++++++-------
 4 files changed, 78 insertions(+), 38 deletions(-)

-- 
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


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-06-03  8:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-03  8:54 [PATCH 0/2] Fix regressions introduced by Fortran compiler identification series Nils-Christian Kempke
2022-06-03  8:54 ` [PATCH 1/2] gdb/testsuite: use test_compiler_info in gcc_major_version Nils-Christian Kempke
2022-06-03  8:54 ` [PATCH 2/2] gdb/testsuite: cache compiler_info on a per language basis Nils-Christian Kempke

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).