From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51766 invoked by alias); 15 Jul 2018 17:49:17 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 51582 invoked by uid 89); 15 Jul 2018 17:48:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=H*i:sk:c334652, H*f:sk:c334652, advised X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 15 Jul 2018 17:48:40 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 6970DB84; Sun, 15 Jul 2018 19:48:23 +0200 (CEST) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6oONzcHz8OoA; Sun, 15 Jul 2018 19:47:51 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p54ACF3B0.dip0.t-ipconnect.de [84.172.243.176]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id B6FE4B81; Sun, 15 Jul 2018 19:47:50 +0200 (CEST) From: Rainer Orth To: Thomas Koenig Cc: Dominique =?utf-8?Q?d'Humi=C3=A8res?= , Nicolas Koenig , gfortran , gcc-patches Subject: Re: [patch, fortran] Asynchronous I/O, take 3 References: Date: Sun, 15 Jul 2018 17:49:00 -0000 In-Reply-To: (Thomas Koenig's message of "Sun, 15 Jul 2018 16:52:20 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-07/txt/msg00037.txt.bz2 Hi Thomas, >> However, I still don't understand why you insist on the hack with >> putting the async_io_*.f90 tests into the libgomp testsuite. Why not >> just make the pthread requirement explicit with >> >> { dg-require-effective-target pthread } >> { dg-additional-options "-pthread" } >> >> and put them in gfortran.dg where they belong? > > Because this does not appear to work with Linux. I, like > most gfortran developers, work on Linux, and I would like to > catch any failure during regression-testing on my own system, > if possible. huh, what doesn't work? I've just finished an x86_64-pc-linux-gnu bootstrap with your patch included, added the above to the async_io_?.f90 tests, linked them to gfortran.dg and ran the tests there (both 32 and 64-bit multilibs), all PASSed and I verified that they were linked with -lpthread. > We have had this discussion with Jakub, and he advised > us to put all the stuff requiring pthreads into libgomp. Do you have a pointer to that previous discussion? > It is debatable if this is a good thing, or if we should > at least make one round of tests with -pthread enabled. > However, this is something for the future, and requires knowledge > of dejagnu that I don't currently have :-) First of all, we need to see and understand the failure mode, if any. Making this work with the testsuite is a secondary matter only, and I can certainly help with that if necessary. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University