From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.163]) by sourceware.org (Postfix) with ESMTPS id 4BB743858012; Sun, 6 Dec 2020 21:52:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4BB743858012 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tkoenig.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=tk@tkoenig.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1607291524; s=strato-dkim-0002; d=tkoenig.net; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=KgXJbCaBsHyI+IsU6IiRSREDmqmLfumfq59qKPXqBNI=; b=o83Z+nhLB9C3JdcZJB3r4o40isbcr4bMR4ScOVyCv5+mS27JZ8TKdDMNBuqKM7nzS6 2Xh0/rWkJa95arrWwigevIGiHef/hHMcKIbB2bL/FJYaKdEdNLzrds0buppMQ9Cf7yNH djPyLuACSPT/TrFSyR54UlArxBa2ubXyu3q5Bd6u7JPAK8wB422NEfB5kiN1cna/5Vke yU9V3fdAkmZmA8reWN0kMyt/EYoJzT4zILrHuBUT3AKOl7RQnR+Xho+MkGQuvbCKrdXY Ql9qS207OMzU2O0eOVysNe6Nf4hSSYxB4/qVvvUpsrLgrq2GU4FGxmYGMFcVRVQK/5Up +0yw== X-RZG-AUTH: ":OGckYUunfvGNVUL0FlRnC4eRM+bOwx0tUtYTrJ/xeZX+ZVM2s+qedn5zhTzJSaOjNY7GcoAVvpFX7mQ413y27/ryC11tLJA=" X-RZG-CLASS-ID: mo00 Received: from linux-p51k.fritz.box by smtp.strato.de (RZmta 47.3.4 AUTH) with ESMTPSA id e005c8wB6Lq39ac (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 6 Dec 2020 22:52:03 +0100 (CET) Subject: Re: Testsuite integration for devel/coarray_native To: dhumieres.dominique@free.fr Cc: "fortran@gcc.gnu.org" , gcc@gcc.gnu.org References: <5eaa24071eda33fe3512c28610cd71f5@free.fr> From: =?UTF-8?Q?Thomas_K=c3=b6nig?= Message-ID: <0261cfa4-bad4-a0a0-ebc8-a03d02f736f8@tkoenig.net> Date: Sun, 6 Dec 2020 22:52:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 MIME-Version: 1.0 In-Reply-To: <5eaa24071eda33fe3512c28610cd71f5@free.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 21:52:07 -0000 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