From patchwork Wed Oct 8 14:00:29 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: max X-Patchwork-Id: 397642 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D59991400B2 for ; Thu, 9 Oct 2014 01:01:02 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; q=dns; s=default; b=o1CuA9o5l8p5Rmtxo odWtOOPZHRZQEJwCNBQBUAQpx2TGNANozBjTaPvlQKn42xmRaij0kDMJ3DBMwYU1 +4Sp07J9tk9LMvEcETPPJX9uoY80og70UptD1jzLjPe1SBnqaZ/VL+bU14Zv5dbZ SrP+k37Q2UW7y1iriPMx1BqLxY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type; s=default; bh=3FcMsmgsi7u8Qwhpg1eyqyl ld8w=; b=pRgUYsCTZNPnvRIhv/i/061WfqmFECpCb8o5p8t1MEEqsNd0JUvuvYB A/ZqvI2R/54lJZHlI3HGVpIDfzKfQNp1WtEy0pI10trcPwDmJF2sPMMm88/cX9f+ 6LxZb3y6qD7qhtPvY1eK/kEwTRZCBbcI4i1adQcdGwmygbKSSoEk= Received: (qmail 12024 invoked by alias); 8 Oct 2014 14:00:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 11957 invoked by uid 89); 8 Oct 2014 14:00:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailout3.w1.samsung.com Received: from mailout3.w1.samsung.com (HELO mailout3.w1.samsung.com) (210.118.77.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Wed, 08 Oct 2014 14:00:34 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0ND400204PPM4H00@mailout3.w1.samsung.com> for gcc-patches@gcc.gnu.org; Wed, 08 Oct 2014 15:03:22 +0100 (BST) Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id BB.97.25543.E7345345; Wed, 08 Oct 2014 15:00:30 +0100 (BST) Received: from [106.109.128.198] by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0ND400A71PKTLG50@eusync3.samsung.com>; Wed, 08 Oct 2014 15:00:30 +0100 (BST) Message-id: <5435437D.4020407@partner.samsung.com> Date: Wed, 08 Oct 2014 18:00:29 +0400 From: Maxim Ostapenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-version: 1.0 To: Marcus Shawcroft Cc: GCC Patches , pinskia@gmail.com, Jakub Jelinek , Yury Gribov , Slava Garbuzov , Maxim Ostapenko Subject: Re: [PATCH] PR58867 ASan and UBSan tests not run for installed testing. References: <542BA26C.4000509@partner.samsung.com> <542BA8C0.2080509@partner.samsung.com> <54350D97.1020509@partner.samsung.com> In-reply-to: Content-type: multipart/mixed; boundary=------------060408070908020301060804 X-IsSubscribed: yes Hm, as I see, others testsuites such as gfortran.exp, go.exp etc. do not call restore_ld_library_path at all. Perhaps we could simply follow this way? Would failing tests still fail if remove restore_ld_library_path from {asan, tsan, ubsan}_finish? On 10/08/2014 03:40 PM, Marcus Shawcroft wrote: > On 8 October 2014 11:10, Maxim Ostapenko > wrote: >> Does it work without restore_ld_library_path in {asan, ubsan, tsan}_finish? >> >> I see two opportunities to fix the issue: >> >> 1) Implement a stack of saved contexts. >> >> 2) Implement new functions, say {asan, ubsan, tsan}_restore_ld_library_path, >> to be able {asan, ubsan, tsan}_finish functions restore context correctly. >> >> What solution is preferable? > Option 1 has the advantage that it places all of the context save and > restore in one place rather than spreading it around the > infrastructure. > > Please can we revert this patch while a correct implementation is being worked? > > Cheers > /Marcus > diff --git a/gcc/testsuite/lib/asan-dg.exp b/gcc/testsuite/lib/asan-dg.exp index 9769138..c98fd3c 100644 --- a/gcc/testsuite/lib/asan-dg.exp +++ b/gcc/testsuite/lib/asan-dg.exp @@ -132,7 +132,6 @@ proc asan_finish { args } { unset TEST_ALWAYS_FLAGS } } - restore_ld_library_path_env_vars } # Symbolize lines like diff --git a/gcc/testsuite/lib/tsan-dg.exp b/gcc/testsuite/lib/tsan-dg.exp index 54ec404..6f7a4d9 100644 --- a/gcc/testsuite/lib/tsan-dg.exp +++ b/gcc/testsuite/lib/tsan-dg.exp @@ -143,5 +143,4 @@ proc tsan_finish { args } { } else { unset dg-do-what-default } - restore_ld_library_path_env_vars } diff --git a/gcc/testsuite/lib/ubsan-dg.exp b/gcc/testsuite/lib/ubsan-dg.exp index 5a7a653..87c460f 100644 --- a/gcc/testsuite/lib/ubsan-dg.exp +++ b/gcc/testsuite/lib/ubsan-dg.exp @@ -114,5 +114,4 @@ proc ubsan_finish { args } { unset TEST_ALWAYS_FLAGS } } - restore_ld_library_path_env_vars }