From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93041 invoked by alias); 28 Sep 2016 10:13:24 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 93025 invoked by uid 89); 28 Sep 2016 10:13:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-yb0-f171.google.com Received: from mail-yb0-f171.google.com (HELO mail-yb0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Sep 2016 10:13:22 +0000 Received: by mail-yb0-f171.google.com with SMTP id v83so2279037ybv.0 for ; Wed, 28 Sep 2016 03:13:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PSeRtIDaiTaffo1xfWDXTHRr87nOdkOs5s74/iQJFfY=; b=PFyNctR9GHUW5qZg79EWSSoGkT1s1o2zoWED+3kkmEm5m1BQIWDKcDKpfuxJ2MPHQp JH0fuEqnESueIbDkaKwj2XVgCZtDiJG1bNBXCAbApNGiFYoZQNKHMIAZ8mZO0VJsrRf5 VSS8hb7G4MQDwQkurnZzhBWBKJjfZyqnxsK3NQDUG5ZV6TTFtY3fhb66nNB4hOQWRh9n aeKqZFls04c1ZGDtRfkTzaAnmmPVtA9IRPsULV+xujEn32ksoLp4uKgAhhZkkGRFKwbq nNfSt0rrb19E8AC6PG7eLcVn13CjiPBYsRAqsINYpbNNLPO/Afvajo9mHzLkzny3gegX GZKg== X-Gm-Message-State: AA6/9Rn7p/0iSYqE3cOfU/0OkmAbBQJw18pqBCKgKUBz9HbQSgTXXCnXT67YIMIaIhOWPPvFQHaQY7iJd8Yg1g== X-Received: by 10.37.171.39 with SMTP id u36mr230638ybi.131.1475057600639; Wed, 28 Sep 2016 03:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.252.34 with HTTP; Wed, 28 Sep 2016 03:13:20 -0700 (PDT) In-Reply-To: <87zimtxkg6.fsf@mid.deneb.enyo.de> References: <87zimt5pza.fsf@mid.deneb.enyo.de> <4e4b52d1-d9fd-ef2b-6e53-99f4b68a9c4b@gmail.com> <87zimtxkg6.fsf@mid.deneb.enyo.de> From: Jonathan Wakely Date: Wed, 28 Sep 2016 10:13:00 -0000 Message-ID: Subject: Re: Optimization question To: Florian Weimer Cc: Nikolaus Dunn , gcc-help Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00111.txt.bz2 On 27 September 2016 at 19:32, Florian Weimer wrote: > * Nikolaus Dunn: > >> std::ostringstream however does not call my new OR delete with no >> optimization. With -O2, it calls only my delete. >> >> If I do not attempt to wrap malloc and free, I get the same >> result. std::vector calls my new and delete, ostringstream calls >> neither. >> >> The command line I used to compile it is: >> g++ -g -O2 --std=3Dc++14 -Wl,-wrap,malloc -Wl,-wrap,free Test.c -o test.= exe > > =E2=80=9C-Wl,-wrap,malloc -Wl,-wrap,free=E2=80=9D is only effective for n= ewly-compiled > code. Your example probably uses some template instantiations which > are supplied by libstdc++, and these will keep calling the unwrapped > malloc/free implementations. Right, std::stringstream doesn't allocate any memory itself, but std::string does, and that is instantiated in the libstdc++.so library. > I don't know if there are mechanisms on mingw which are comparable to > ELF symbol interposition.