From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34659 invoked by alias); 6 Aug 2016 15:08:39 -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 34650 invoked by uid 89); 6 Aug 2016 15:08:39 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 06 Aug 2016 15:08:38 +0000 Received: by mail-wm0-f47.google.com with SMTP id i5so73694636wmg.0 for ; Sat, 06 Aug 2016 08:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:from:date:to:message-id; bh=4A6Mo14Mj3xA+mqk0Bj74tLy8D54YhmmQsgrhvuwO8g=; b=dyqo/PgOwkG/31lAIGrfYm5+HUuuHWzckgvk/4tPmR7bBRqoIM7V8bqabQw4wP64BF 6LwjdQbVEGR+ZamTnaP+RUpqXsfhxGPUdCfeGIuYJ5c+IRWQ4ECXapnzkDgldVRvqot9 rDesQQXRCHfMbn4oXKu4gbcgZoM7IL5Qj7xhkrk3tg0cOfPfgOyVvYtc/7Fh9p4Zsxkd H5CzW8xxSKrVM/bIAQfUHtiqk+w0jWftpcICACfwW5zK/7EZICrAaNws3h/r6DOlEB1z SYz4cxS8QSK7MwINcfTj42WDjFz4pdlmoY7iFsqQJxeQSAh6jnzgPDlyDvuU3+NwP3ME KHBg== X-Gm-Message-State: AEkoousUoOL5NyGLnPArudIBOphTno8wqQuNSqcgVq/Itj+zCAubFbpWV+dM4BzzvIXEgQ== X-Received: by 10.28.27.211 with SMTP id b202mr8737027wmb.12.1470496114416; Sat, 06 Aug 2016 08:08:34 -0700 (PDT) Received: from 192-168-178-29.fritz.box (p5DC9A447.dip0.t-ipconnect.de. [93.201.164.71]) by smtp.gmail.com with ESMTPSA id ub8sm23337233wjc.39.2016.08.06.08.08.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Aug 2016 08:08:32 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <57A5B8BE.2000004@redhat.com> References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <1470420954.639.64.camel@t-online.de> <44EE0FB0-A8B9-43F9-BF58-C4D7D27DA944@gmail.com> <57A5B8BE.2000004@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: protected alloca class for malloc fallback From: Richard Biener Date: Sat, 06 Aug 2016 15:08:00 -0000 To: Aldy Hernandez ,Oleg Endo ,Martin Sebor ,gcc-patches Message-ID: <941D179C-146F-4004-BECB-9FB066DDCC8D@gmail.com> X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00532.txt.bz2 On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez wrote: >On 08/05/2016 04:07 PM, Richard Biener wrote: >> On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo > wrote: >>> On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote: >>> >>>> >>>> Please don't use std::string. For string building you can use >>>> obstacks. >>>> >>> >>> Just out of curiosity ... why? I remember there was some discussion >>> about it, what was the conclusion? Is that now a general rule or >does >>> it depend on the context where strings are used? >> >> Because you make a messy mix of string handling variants. >Std::string is not powerful enough to capture all uses, it is vastly >more expensive to embed into structs and it pulls in too much headers. >> (Oh, and I hate I/o streams even more) > >Oh, and there is prior use in ipa-chkp.c, although I suppose it >could've >crept in: Definitely. > > std::string s; > > /* called_as_built_in checks DECL_NAME to identify calls to > builtins. We want instrumented calls to builtins to be > recognized by called_as_built_in. Therefore use original > DECL_NAME for cloning with no prefixes. */ > s = IDENTIFIER_POINTER (DECL_NAME (fndecl)); > s += ".chkp"; > DECL_NAME (new_decl) = get_identifier (s.c_str ()); > >You can't tell me obstacks are easier on the eyes for this ;-). Even strcat is shorter and cheaper. Richard. >Aldy