From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118407 invoked by alias); 5 Aug 2016 17:56:07 -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 118390 invoked by uid 89); 5 Aug 2016 17:56:07 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=growth X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 05 Aug 2016 17:56:06 +0000 Received: by mail-wm0-f50.google.com with SMTP id i5so47412487wmg.0 for ; Fri, 05 Aug 2016 10:56:05 -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=xW2qlEo20iklWkaPhvJ/tkoC/uXJ1AbBlqWJ5VjAlQE=; b=YVwI+3PB5B/4S4d9rTldAPo1OLkVhCFpNILRhwfYZGTTOI5LiPyBOk3yz3FkG32WJ/ d81fzp3LfdEvngnrMoVBjtHoHtR6iiK8ypnCPyeFa2iZSx+ubTs62eRB++CjFokO6BeO 5Tb/jMd3RN1XismY00t2Ash4zt1C+02z0Fddsrq91WNR1Vel8BszDf3VyJ2zIxhLE9yf 2FCxeLftRoGqcJd+6m7OStGrAgxmMWN8R+hlrx1s+QO93+KnIVYfl0xiBLCYIQEEoqXb 4vIUzoJkWqliSh2Xr0aZNhEVEdVdk4+lChlc82SqgzyjEBFjaHJE+Bc4o7eg3OOjqIAP Bpfg== X-Gm-Message-State: AEkooutfd2Ap38EQP/HwHAcLzfwjzbaiR4C2oiUMaf97ITMUv5YUGJKrLO7owOHYw9oRBg== X-Received: by 10.194.148.81 with SMTP id tq17mr71835535wjb.67.1470419762952; Fri, 05 Aug 2016 10:56:02 -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 jc4sm18921480wjb.6.2016.08.05.10.56.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 10:56:02 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <57A4A5E8.90205@redhat.com> References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@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: Fri, 05 Aug 2016 17:56:00 -0000 To: Aldy Hernandez ,Martin Sebor ,gcc-patches Message-ID: X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00485.txt.bz2 On August 5, 2016 4:42:48 PM GMT+02:00, Aldy Hernandez wrote: > >> I was surprised by the always_inline trick. I suppose it makes >> sense but I wouldn't have expected to be able to rely on it. Out >> of curiosity I tested it with other compilers. It turns out that >> it only works with some like GCC and IBM XLC++, but not others >> like Clang or Sun CC. In recursive calls, they don't seem to >> hold on to the memory allocated via alloca by the class ctor in >> the caller. > >Well, it was surprising to me as well, hence the comment. I expected >it >to just work, and when it didn't I had to hunt in the inliner code to >find out why it was selectively inlining: > > case GIMPLE_CALL: > /* Refuse to inline alloca call unless user explicitly forced so as > this may change program's memory overhead drastically when the > function using alloca is called in loop. In GCC present in > SPEC2000 inlining into schedule_block cause it to require 2GB of > RAM instead of 256MB. Don't do so for alloca calls emitted for > VLA objects as those can't cause unbounded growth (they're always > wrapped inside stack_save/stack_restore regions. */ > >As Richi pointed out, if the constructor doesn't get inlined (as you're > >seeing in Clang and Sun CC), we could potentially clobber freed memory. > > So much for that idea... > >> >> FWIW, rather than creating a new class around alloca and putting >> effort into changing code to use it I think that investing time >> into replacing the function's uses with an existing C++ container >> class (either GCC's own or one from the STL) might be a better >> way to go. > >Yes, I suggested a combination of auto_vec<> (gcc's) and std::string >down thread. Please don't use std::string. For string building you can use obstacks. Richard. >Thanks for checking out the result from other compilers. Much >appreciated. > >Aldy