From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29409 invoked by alias); 3 Dec 2012 19:09:16 -0000 Received: (qmail 29399 invoked by uid 22791); 3 Dec 2012 19:09:16 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_LV X-Spam-Check-By: sourceware.org Received: from qmta15.emeryville.ca.mail.comcast.net (HELO qmta15.emeryville.ca.mail.comcast.net) (76.96.27.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 19:09:10 +0000 Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta15.emeryville.ca.mail.comcast.net with comcast id X77V1k0021zF43QAF79AmA; Mon, 03 Dec 2012 19:09:10 +0000 Received: from bag6-1-pt.tunnel.tserv3.fmt2.ipv6.he.net ([IPv6:2001:470:1f04:ae1::2]) by omta24.emeryville.ca.mail.comcast.net with comcast id X7981k0020P3DwE8k7998i; Mon, 03 Dec 2012 19:09:10 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [PATCH] asan unit tests from llvm lit-test From: Mike Stump In-Reply-To: <20121203110018.GR2315@tucnak.redhat.com> Date: Mon, 03 Dec 2012 19:09:00 -0000 Cc: Wei Mi , GCC Patches , David Li , Diego Novillo , Kostya Serebryany , Dodji Seketeli Content-Transfer-Encoding: quoted-printable Message-Id: <6A035ADC-7D20-4017-9DBF-7943C68F2E1C@comcast.net> References: <20121128101420.GG2315@tucnak.redhat.com> <20121203110018.GR2315@tucnak.redhat.com> To: Jakub Jelinek X-IsSubscribed: yes 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 X-SW-Source: 2012-12/txt/msg00154.txt.bz2 On Dec 3, 2012, at 3:00 AM, Jakub Jelinek wrote: > Mike, CCing you especially on the proposed lib/gcc-dg.exp dg-env-var > changes and I have one question about cleanup of files (file delete > vs. remote_file target (or is that host or build) delete). > But of course if you could eyeball the rest and comment, I'd be even happ= ier. >> +file delete dlclose-test-1.exe-so.so >> +file delete shared-lib-test-1.exe-so.so=20 >=20 > Ah, it is here, but wonder what it will do for cross testing. > Shouldn't that be remove_file ? delete where ? is either target, or host,= or > build (not sure which one). Mike? Sounds about right. >> # >> @@ -287,6 +327,10 @@ proc search_for { file pattern } { >> # as c-torture does. >> proc gcc-dg-runtest { testcases default-extra-flags } { >> global runtests >> + global set_env_var >> + >> + # Init set_env_var >> + set set_env_var [list] >>=20 >> # Some callers set torture options themselves; don't override those. >> set existing_torture_options [torture-options-exist] >=20 > For this, I'd appreciate Mike's input. When documented, it will say if you want to change the environment variable= s on the host, target or build machines. When it says which one, it will b= e apparent when tested, if it does as documented. Since I don't know what = you guys want to do (better not to imagine one thinks they know)=85 I'd le= ave it to you guys to figure it out and test. Also, if untested, I'd not s= ee any reason for it to work; but, maybe I'm just cautious that way. If yo= u can only test native, just bail out if not native, and try and recruit so= meone that can test canadian or cross. > If it is useful for all tests > generally (I'd say it is, we could use it e.g. for testing some of the > libgomp env vars), then it should stay here or so, otherwise it would need > to be moved into asan-dg.exp and have asan in the name. >=20 > More importantly, I'm wondering about dg-env-var vs. cross testing, I gue= ss > env var is set on host only, not remotely set on the target. So, either > we should mark all tests that use dg-env-var with some special effective > target that would be basically [is_native] Ick, no. > - or what is the way to limit tests to native testing only, roughly: if [is3way] || ! [isnative] return > or dg-evn-var itself should arrange to just > make the whole test unsupported if not native (don't call ${tool}_load > at all and return something else?). If you want to expend the energy, it is easier to just fix the two lines th= at are wrong and find some way to smuggle variables to the target. In the = end, if there is no existing way, you'd need to add a way and use it, and i= f that way doesn't exist, either omit it, or unsupport it. Of course, that= presupposes you want environment variables on the target.