From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2792 invoked by alias); 9 Sep 2015 21:14:38 -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 2736 invoked by uid 89); 9 Sep 2015 21:14:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Sep 2015 21:14:31 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1ZZmhH-0006tk-P6 from Jonathan_Roelofs@mentor.com ; Wed, 09 Sep 2015 14:14:27 -0700 Received: from galois.local (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Wed, 9 Sep 2015 14:14:27 -0700 Subject: Re: [PATCH] Make ubsan tests less picky about ansi escape codes in diagnostics. To: Andrew Pinski , Mike Stump References: <55DF92B6.6020802@codesourcery.com> <55E87206.6030500@codesourcery.com> <20150903161711.GY1847@tucnak.redhat.com> <55E8792A.8010909@codesourcery.com> CC: Jakub Jelinek , GCC Patches , Kostya Serebryany From: Jonathan Roelofs Message-ID: <55F0A132.3020203@codesourcery.com> Date: Wed, 09 Sep 2015 21:23:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2015-09/txt/msg00618.txt.bz2 On 9/9/15 9:20 AM, Andrew Pinski wrote: > On Wed, Sep 9, 2015 at 11:11 PM, Mike Stump > wrote: >> On Sep 3, 2015, at 9:45 AM, Jonathan Roelofs >> wrote: >>> Moral of the story is: these tests fail in our environment, but >>> only because the regexes do not expect the presence of the ansi >>> color codes, and we can't trick the runtime into not emitting >>> them. >> >> When the user says, I don’t want color; is color emitted? If so, There's two ways to prevent emission of these color codes: 1) Set an env var 2) Make the output stream not a tty Both of these pathways work. >> that’s a bug, and needs to be fixed. If the user can, then, >> dejagnu can. When it says, don’t use color, that should be The issue is that I've got a remote target, and there are two limitations of DejaGnu that prevent me from triggering either (1) or (2): a) As Andrew says, DejaGnu can't set env vars for remote programs under test. b) DejaGnu makes itself appear to the remote program under test as if it were a tty. >> respected; just as if the user had said it. Anyway, a | decolor >> more a la prune should be able to remove color, even if there were >> no other way. Are you suggesting that I use `dg-prune-output` to filter out these color codes? I tried several variations on spellings of: /* { dg-prune-output "\033\[[0-9\;]+[mK]" } */ but couldn't get any of them to work. (I'm not certain I got the escaping correct, nor what it should be). Jon > > The issue is dejagnu cannot (at least in the current implementation > of the remotes), cannot set an env that stays alive before invoking > the program (though maybe it could use the env program to do the > invoking). > >> >> I’m not a fan of the changes as is. -- Jon Roelofs jonathan@codesourcery.com CodeSourcery / Mentor Embedded