RE: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite support

["Kempke, Nils-Christian" <nils-christian.kempke@intel.com>]

> -----Original Message-----
> From: Tom de Vries <tdevries@suse.de>
> Sent: Wednesday, June 1, 2022 9:32 AM
> To: Kempke, Nils-Christian <nils-christian.kempke@intel.com>; Andrew
> Burgess <aburgess@redhat.com>; gdb-patches@sourceware.org
> Cc: JiniSusan.George@amd.com
> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx testsuite
> support
> 
> On 6/1/22 09:10, Kempke, Nils-Christian wrote:
> >
> >
> >> -----Original Message-----
> >> From: Gdb-patches <gdb-patches-bounces+nils-
> >> christian.kempke=intel.com@sourceware.org> On Behalf Of Kempke,
> Nils-
> >> Christian via Gdb-patches
> >> Sent: Wednesday, June 1, 2022 8:44 AM
> >> To: Tom de Vries <tdevries@suse.de>; Andrew Burgess
> >> <aburgess@redhat.com>; gdb-patches@sourceware.org
> >> Cc: JiniSusan.George@amd.com
> >> Subject: RE: [PATCH v2 00/16] Fortran compiler identification and ifx
> testsuite
> >> support
> >>
> >>> -----Original Message-----
> >>> From: Tom de Vries <tdevries@suse.de>
> >>> Sent: Wednesday, June 1, 2022 7:14 AM
> >>> To: Andrew Burgess <aburgess@redhat.com>; Kempke, Nils-Christian
> >> <nils-
> >>> christian.kempke@intel.com>; gdb-patches@sourceware.org
> >>> Cc: JiniSusan.George@amd.com
> >>> Subject: Re: [PATCH v2 00/16] Fortran compiler identification and ifx
> >> testsuite
> >>> support
> >>>
> >>> On 6/1/22 06:54, Tom de Vries wrote:
> >>>> On 5/31/22 21:33, Tom de Vries via Gdb-patches wrote:
> >>>>> I'm seeing regressions with check-read1 (haven't tried native yet),
> >>>>> I'm guessing because of this patch series:
> >>>>> ...
> >>>>> FAIL: gdb.fortran/allocated.exp: gdb_breakpoint: set breakpoint at
> >>>>> unknown
> >>>>
> >>>> I could reproduce this with native, but only when running the entire
> >>>> testsuite, not just the test-case.
> >>>>
> >>>> This looks like problems due to the caching of compiler_info, which
> >>>> doesn't take the language argument of proc get_compiler_info into
> >>> account.
> >>>>
> >>>
> >>> That's confirmed.  I did a run with caching disabled, and these FAILs
> >>> disappeared.
> >>>
> >>> Thanks,
> >>> - Tom
> >>>
> >>>> So, if I run the entire test suite, compiler_info is set to gcc-7-5-0
> >>>> and stays that way due to the caching, and because of this series gcc is
> >>>> no longer matched in proc fortran_main, so we run into FAILs.
> >>>>
> >>>> Thanks,
> >>>> - Tom
> >>
> >> Hi,
> >>
> >> Sorry for this, I could not see any of these regressions in our CI nor in the
> >> runs
> >> I did manually. I assume something is different in the way I am running
> the
> >> Testsuite. I thought the caching would only ever happen for each
> individual
> >> test rather than multiple ones. But apparently there is a way this can be
> done
> >> cached over different tests?
> >>
> >> I/CI ran the testsuite like
> >>
> >>    make check TESTS="gdb.*/*.exp" FORCE_PARALLEL='1' -j $(nproc --
> ignore
> >> 1)
> >>
> >> as well as
> >>
> >>    make check TESTS="gdb.*/*.exp" RUNTESTFLAGS='--
> target_board="unix" \
> >>      CC_FOR_TARGET='gcc' CXX_FOR_TARGET='gcc' \
> >>      F90_FOR_TARGET="gfortran"' FORCE_PARALLEL='1' -j $(nproc --ignore
> 1)
> >>
> >> (and then the same for unix/-m32, and native-gdbserver and
> >> native-extended-gdbserver)
> >>
> >> and
> >>
> >>    make check -j $(nproc --ignore 1)
> >>
> >> I assume I am somewhat running the testsuite differently.
> >>
> >> Could you tell me how to run the testsuite instead?
> >>
> >> Thanks,
> >> Nils
> >
> > Ok, so apparently running the testsuite in any kind of parallel mode
> disables this
> > caching?
> >
> 
> I don't think it's that.
> 
> But if there's an error in caching, the first invocation becomes
> significant, and with parallel testing each parallel instance does its
> own first invocation, so it's possible that you get different results
> between parallel and non-parallel.
> 
> > I can reproduce these with plain
> >
> >    make check
> >
> > Sorry for missing this. I'll try an push a patch to fix this - not sure if we
> should
> > revert until then as the series seems to cause regressions on all of the
> Fortran
> > testsuite...
> 
> No problem of course, it happens.
> 
> I suppose the thing we really want to fix is the caching which needs to
> be made language-specific.
> 
> But I imagine some simple workaround like this:
> ...
> diff --git a/gdb/testsuite/lib/fortran.exp b/gdb/testsuite/lib/fortran.exp
> index 9ee4208fb88..aa3882794a9 100644
> --- a/gdb/testsuite/lib/fortran.exp
> +++ b/gdb/testsuite/lib/fortran.exp
> @@ -177,6 +177,7 @@ proc fortran_character1 {} {
> 
>   proc fortran_main {} {
>       if {[test_compiler_info {gfortran-*} f90]
> +       || [test_compiler_info {gcc-*} f90]
>          || [test_compiler_info {ifort-*} f90]
>          || [test_compiler_info {ifx-*} f90]
>          || [test_compiler_info {flang-llvm-*} f90]} {
> ...
> will already take care of the regressions.

It will take care of a bunch (all the runto_main ones) but there are the compiler
dependent output names for Fortran intrinsic types as well. Basically all the
checks in fortran.exp would need this fallback.

Also, there exist compiler dependent tests and KFAILs in the gdb.fortran
testsuite which would fail to identify the compiler correctly.
 
I have prepared two patches that make the compiler info caching language
specific. I am not sure whether these fix all regressions seen but I'll post
them (after checking for regressions) and hope these fix all problems seen
with this series.

Thanks,
Nils

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