From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1891 invoked by alias); 2 Mar 2017 21:40:56 -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 1877 invoked by uid 89); 2 Mar 2017 21:40:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=site X-HELO: mail-yw0-f196.google.com Received: from mail-yw0-f196.google.com (HELO mail-yw0-f196.google.com) (209.85.161.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 Mar 2017 21:40:53 +0000 Received: by mail-yw0-f196.google.com with SMTP id s15so5362571ywg.0 for ; Thu, 02 Mar 2017 13:40:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k+vStXnwY8zbIs+uT0r5T/7gXpHngZQnhAUK3U3cNWM=; b=Yqka0jv8/OEanVCzuVfQ0ciYPYjtxsQyF0H67oROXCLhHJga78F1Xdgd/+M++iayod NG607/cO1D2fVZaPrRZvXqVs0LLoObsoCSY7+VkZwTBD36v66JZtTAwJa26kOtS1tJkk b+9qs5XTcf6URJGs/ryQ2+Ay4UqPIcKX3XkVPb/OLTOmXFuajYJH4v2HRK3sEf+OATcP ORggEsbOU2X176HOf7pslP9cLEIIWARHcTXCCDRgZDIYYxb/F9qjS1B5aF+oDPrMZJpH wwTxkOXYvRr3LYsNCVG/dEo/W5QDoDiP/E8F1cHBMeCPmB9THsB/Jp2sCPTb1kVRzp4d uvBg== X-Gm-Message-State: AMke39mhabyh2U8dEW+88KCTxUJU5sURU6gabW6SHKXxCT999d88qdVBm+H7kM9MzA32FtXqNP683MLVrOochA== X-Received: by 10.129.40.141 with SMTP id o135mr5902101ywo.166.1488490852839; Thu, 02 Mar 2017 13:40:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.174.101 with HTTP; Thu, 2 Mar 2017 13:40:52 -0800 (PST) In-Reply-To: <63968707-1824-0aa5-c03d-939cdb14aba5@gmail.com> References: <60d46e1a-686b-9c27-4b48-7b658f8507fa@gmail.com> <63968707-1824-0aa5-c03d-939cdb14aba5@gmail.com> From: Andrew Pinski Date: Thu, 02 Mar 2017 21:40:00 -0000 Message-ID: Subject: Re: [PATCH] free MPFR caches in gimple-ssa-sprintf.c (PR 79699) To: Martin Sebor Cc: Richard Biener , Joseph Myers , Gcc Patch List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00135.txt.bz2 On Thu, Mar 2, 2017 at 1:33 PM, Martin Sebor wrote: > On 03/02/2017 01:08 AM, Richard Biener wrote: >> >> On Thu, Mar 2, 2017 at 2:01 AM, Joseph Myers >> wrote: >>> >>> On Wed, 1 Mar 2017, Martin Sebor wrote: >>> >>>> Joseph, since you commented on the bug, do you have a suggestion >>>> for a different site for it or a guard? The only other call to >>>> the function is in the Fortran FE and it's neither guarded nor >>>> does it appear to ever be called. >>> >>> >>> I don't think a guard is needed. Arguably it should be called from an >>> atexit handler, but since we don't have such a handler calling it from >>> the >>> relevant pass seems reasonable (and I'm not sure what the right way to >>> handle such freeing of memory in the JIT context is). >> >> >> IMHO we should call it from gcc::~context > > > Thanks, that makes sense to me. The attached patch does that. Is this function call thread safe? Or rather is MPFR thread safe? I am thinking of the case where there are two gcc::context around one running in each thread. I am not saying this is the current behavior but I do know there was talk about making GCC thread safe before and I want to make sure we understand that this might cause issues in that goal. Thanks, Andrew > > Martin