From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16939 invoked by alias); 28 May 2015 11:32:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16907 invoked by uid 89); 28 May 2015 11:32:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f52.google.com Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 28 May 2015 11:32:46 +0000 Received: by qgg60 with SMTP id 60so14503591qgg.2 for ; Thu, 28 May 2015 04:32:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Cbf4Ca0AGTG7J2nEqfZuqq2ZXERnkSfIFpfFINi9h4o=; b=mvAiiGiujC+JtJQctl5tMCAjMaRa+xUD0lH9BFOmKls4njsrIq9WoJG/C/kCrApmM9 SfvCem3hAZBi2/pk6ZfKOGcmF2g6QePkvM3IeeoUWyuxXgAG7XGxqMj10rSGFuR3X1Cv RtVVFsz4+grJsRCvrgD9/QJssH2pyxFOLs/68ehoAhwAQql/yx/yu6ycJ1wF6bxmVweM wLiUhjDf5rozPK2x4nO04kS6GsPJVx0VzQnQZvGRiXyQC43HOjIeadq85MKOS2taX2YV 9z0CaEKNRJn7+N8aAE3p4YYHVJ4WS3a3cBR+w6S9FpjY4vCoTULn5W+NlLF88TMldAXs MpKA== X-Gm-Message-State: ALoCoQmT3PH23rieXtc9ukvxfmkjDC464G5DVo+IXhp5+M6m1SGm2nL8m9bjv7O/UoqMUG0HBDVO MIME-Version: 1.0 X-Received: by 10.140.237.67 with SMTP id i64mr2498262qhc.86.1432812764409; Thu, 28 May 2015 04:32:44 -0700 (PDT) Received: by 10.140.102.164 with HTTP; Thu, 28 May 2015 04:32:44 -0700 (PDT) In-Reply-To: <5566EC4C.6060204@arm.com> References: <5537D241.1000606@arm.com> <5537DC12.1050201@arm.com> <55649E74.6020600@arm.com> <5566EC4C.6060204@arm.com> Date: Thu, 28 May 2015 11:53:00 -0000 Message-ID: Subject: Re: [PATCH 13/14][ARM/AArch64 testsuite] Use gcc-dg-runtest in advsimd-intrinsics.exp From: Christophe Lyon To: Alan Lawrence Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg02617.txt.bz2 On 28 May 2015 at 12:22, Alan Lawrence wrote: > Christophe Lyon wrote: >> >> On 26 May 2015 at 18:25, Alan Lawrence wrote: >>> >>> I don't see this symptom - I am able to execute such subsets with either >>> my, >>> or Sandra's, advsimd-intrinsics.exp. >> >> >> I didn't try to run with your patch, I thought it was an oversight of >> yours. >> >> Sorry, indeed I've just checked that gcc-dg-runtest includes the filter. >> >>> Is it that you have to check runtest_file_p because you are setting >>> gcc_parallel_test_enable to 0? >>> >>> I'm doing more testing now, but I think I can drop my >>> advsimd-intrinsics.exp >>> changes altogether; I'll post an updated patch series shortly. >>> >>> In the meantime I'm curious as to why you found the >>> gcc_parallel_test_enable >>> necessary? (And is it safe to reset it to 1 afterwards, rather than to a >>> saved value?) >> >> See https://gcc.gnu.org/ml/gcc/2014-10/msg00081.html > > > So after working through the differences between Sandra's and my patch, I > find the existing advsimd-intrinsics.exp achieves pretty much the same > thing, and preserves the same list of test variants (e.g. the -Og -g from > set-torture-options which I had removed). > > However, I've tried testing advsimd-intrinsics.exp (both the whole thing, > and individual tests using RUNTESTFLAGS) with and without this hunk: > > @@ -57,20 +57,7 @@ set-torture-options $C_TORTURE_OPTIONS {{}} > $LTO_TORTURE_OPTI > set additional_flags [add_options_for_arm_neon ""] > > # Main loop. > -foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] { > - # If we're only testing specific files and this isn't one of them, skip > it. > - if ![runtest_file_p $runtests $src] then { > - continue > - } > - > - # runtest_file_p is already run above, and the code below can run > - # runtest_file_p again, make sure everything for this test is > - # performed if the above runtest_file_p decided this runtest > - # instance should execute the test > - gcc_parallel_test_enable 0 > - gcc-dg-runtest $src "" $additional_flags > - gcc_parallel_test_enable 1 > -} > +gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] "" > ${additional_flags} > > and find exactly the same tests are run and pass. My hypothesis is thus that > you only need the explicit loop, manual checking of runtest_file_p, and > gcc_parallel_test_enable, in order to do *both* c-torture-execute *and* > gcc-dg-runtest; since we are now only doing the latter, this is unnecessary. > Does that make sense? (If you agree, I'll propose that as a standalone > cleanup patch.) > Indeed I think you are right. Since we no longer call c-torture-execute, we no longer need to call runtest_file_p here. Having only one remaining call to runtest_file_p in gcc-dg-runtest is parallel-safe. Thanks for the cleanup. Christophe. > Cheers, Alan >