Testsuite integration for devel/coarray_native

Testsuite integration for devel/coarray_native

[Thomas König]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Hi,

I'm currently trying to put together a testsuite for the shared coarray
branch.  What I have so far is a directory 
gcc/testsuite/gfortran.dg/caf-shared
which contains the attached dejagnu file plus the test cases

This works with the command

make check-fortran RUNTESTFLAGS="cas.exp=num_images_1.f90"

but I am not sure if this is the right way to go about this
(would this work in the absence of an installed caf_shared library,
would this cause lots of failures on systems without pthreads, ...?)

On some systems, we need librt for shm_open. Since most shared
coarray tests run at the number of CPUs by default, the tests
should probably not be run in parallel.

Might it be better to put the test cases under the libgomp
directory?  If so, what should it look like, and how would it
then be invoked if only testing for shared coarrays was needed?

Any help would be appreciated.

Best regards

	Thomas


[-- Attachment #2: cas.exp --]
[-- Type: text/plain, Size: 1968 bytes --]

# Copyright (C) 2020 Free Software Foundation, Inc.

# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GCC; see the file COPYING3.  If not see
# <http://www.gnu.org/licenses/>.
#
# Contributed by Thomas König <tkoenig@gcc.gnu.org>

# Test shared coarray support.

load_lib gfortran-dg.exp

set blddir [lookfor_file [get_multilibs] libcaf_shared]
puts $blddir

dg-init

global gfortran_test_path
global gfortran_aux_module_flags
set gfortran_test_path $srcdir/$subdir

# Return true if the rt library is supported on the target.
proc check_effective_target_librt_available { } {
    return [check_no_compiler_messages librt_available executable {
	int main (void) { return 0; }
    } "-lrt"]
}

set maybe_rt_lib ""
if [check_effective_target_librt_available] {
    set maybe_rt_lib "-lrt"
}

# Main loop.
foreach test [lsort [glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]] {
    # If we're only testing specific files and this isn't one of them, skip it.
    if ![runtest_file_p $runtests $test] then {
	continue
    }
    set option_list [list { -O2 } ]

    set nshort [file tail [file dirname $test]]/[file tail $test]
    list-module-names $test

    foreach flags $option_list {
	verbose "Testing $nshort (libcaf_single), $flags" 1
        set gfortran_aux_module_flags "-pthread -fcoarray=shared $flags -lcaf_single"
	dg-test $test "-pthread -fcoarray=shared $flags -lcaf_shared $maybe_rt_lib" ""
	cleanup-modules ""
    }
}

[-- Attachment #3: num_images_1.f90 --]
[-- Type: text/x-fortran, Size: 147 bytes --]

! { dg-do run }
! { dg-set-target-env-var GFORTRAN_NUM_IMAGES "2" }
program main
  implicit none
  if (num_images() /= 2) stop 1
end program main

Re: Testsuite integration for devel/coarray_native

[Thomas König]

Am 06.12.20 um 18:37 schrieb dhumieres.dominique@free.fr:
> Hi Thomas,
> 
>> I'm currently trying to put together a testsuite for the shared coarray
>> branch.  What I have so far is a directory
>> gcc/testsuite/gfortran.dg/caf-shared
>> which contains the attached dejagnu file plus the test cases
> 
> I don't see the point to introduce a new directory.
> IMO all the tests for coarray should pass for shared coarray

The problem is that there is a significantly different ABI (there was
no reasonable choice to use the existing one), so there are different
(and, as of now, many more :-) bugs.

The policy is to have no failing test cases, so we need something
separate during development at least.

Also, the current tests do not actually implement multi-image coarrays,
unlike what the shared library does.

> and a simple test would be to add
> 
>      foreach flags $option_list {
>      verbose "Testing $nshort (libcaf_single), $flags" 1
>          set gfortran_aux_module_flags "-fcoarray=shared $flags 
> -lcaf_shared"
>      dg-test $test "-fcoarray=shared $flags -lcaf_shared 
> $maybe_atomic_lib" ""
>      cleanup-modules ""
>      }
> 
> at the end of gfortran.dg/coarray/caf.exp.
> This will cover the check of more than 60 programs.

With ~ 40 failures, at the moment :-)

> In addition greping for "fcoarray=" in gfortran.dg shows 200 programs
> which should be moved to gfortran.dg/coarray/.

Some of them are duplicates.

>> but I am not sure if this is the right way to go about this
>> (would this work in the absence of an installed caf_shared library,
>> would this cause lots of failures on systems without pthreads, ...?)
> 
> Presently if shared coarray is not supported it is impossible to bootstrap.
What goes wrong?  Do you have an idea how to fix it?  The build
magic should have taken care of it, but of course if there is
no access to a system where things fail (and not even a feedback that
this is the case, until what you just wrote), it is almost impossible
to debug.

This is, of course, a fundamental problem of developing for
platforms where people don't have access to. Asynchronous I/O
was plagued by similar problem.  We had been hoping for concrete
bug reports, but little luck so far, with the exception of
pthread barriers on MacOS, which was fixed.

> IMO for the moment it is putting "la charrue avant le boeufs" (the plow
> before the oxen) to discuss what to do for the tests before having
> a solution to bootstrap without -lcaf_shared.

What exactly is the failure?  Is it possible to get access to a
system where this failure occurs?  I tried bootstrapping on all BSD
systems in the gcc compile farm, but apart from a few days
of wasted work and a few bootstrap PRs, that didn't result in anything
useful.

Having said that, I have actually committed the cas.exp to the branch
(with Nicolas' approval) so it is now possible to run a regression-test.
When you're doing things to the scalarizer and to array descriptors,
this is a must, regressions come easy and fast in that area...

So far, there is a grand total of 19 tests which pass.

> I don't thing the shared coarray tests should go under libgomp.

libgomp has the infrastructursts, which is also good - it makes little
sense to run on 16 CPUs for ee to run pthreads, which is also required.
It also doesn't parralelize teach test case in parallel with
make -j16 check-fortran.

This is, for example, why the asynchronous I/O tests, which also
require pthreads, are found under libgomp.

Best regards

	Thomas