From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37290 invoked by alias); 27 Sep 2016 17:39:07 -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 37272 invoked by uid 89); 27 Sep 2016 17:39:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=dee, untyped, newexpressions, allocates X-HELO: mail-yb0-f173.google.com Received: from mail-yb0-f173.google.com (HELO mail-yb0-f173.google.com) (209.85.213.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 27 Sep 2016 17:39:05 +0000 Received: by mail-yb0-f173.google.com with SMTP id z8so10259156ybh.3 for ; Tue, 27 Sep 2016 10:39: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:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HUc04C3b4EHk6U050GNqwR7mqpJAGqRSE0m63AuEskk=; b=LNP87NcHfRxcp2L7hNnZxaJQOtvjzs4QfGYgNuiLBkc2IZ3Je0xL/QWIDLYlk3tseo OPfY4kbst+kCBJ+bo1jFZ3rHIyNzOh7wtBgzQTaiCcCYQ2gz0vnQVMMBRt6aGeZ8Xs7l Vvb08APG+U/gRVg3A/cIZN3HbmYvnoCL5HdJ/zyjWWmUnyiaBQdpJ6XJnUQKRFxgz+qm ZJyHE5Ie1weaLSUoXWxPPVmbdzeuqqmhFLk+vY0Q9Ml/5iJqjH61ixBPujp4T7rcxBG1 7nOoag3yzgfjQqxS4+oKGKMyqzxs0YpSXQXWkYDHPD7Nfa5W/mosTE1JRxTHAlQoNoas 4Lkg== X-Gm-Message-State: AE9vXwNdQvE44zqVrC6zsEUfRvfdd3aGQL5gPWpvEenferNH+N4aXhA/e1JhyIOTggZH8g== X-Received: by 10.37.196.194 with SMTP id u185mr21044395ybf.181.1474997943951; Tue, 27 Sep 2016 10:39:03 -0700 (PDT) Received: from [192.168.123.205] ([66.0.53.120]) by smtp.googlemail.com with ESMTPSA id p74sm1357124ywp.37.2016.09.27.10.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Sep 2016 10:39:01 -0700 (PDT) Subject: Re: Optimization question To: Jonathan Wakely , gcc-help References: <87zimt5pza.fsf@mid.deneb.enyo.de> From: Nikolaus Dunn Message-ID: <4e4b52d1-d9fd-ef2b-6e53-99f4b68a9c4b@gmail.com> Date: Tue, 27 Sep 2016 17:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00107.txt.bz2 Maybe I'm using the wrong terminology then or am possibly confused. I am under the impression that std::allocator points to std::new_allocator by default. In fact, in debugging with gdb, I've gotten into new_allocator.h. At any rate, in trying to contrive the smallest possible test program, I learned some new things that in my original pass, I mistook. It turns out that std::vector seems to work fine with -O2 or without it. 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=c++14 -Wl,-wrap,malloc -Wl,-wrap,free Test.c -o test.exe Test.c: #include #include #include extern "C" void *__real_malloc(size_t); extern "C" void __real_free(void *); extern "C" void *__wrap_malloc(size_t nbytes) { printf("wrap_malloc: %ld bytes\n", nbytes); void * foo = __real_malloc(nbytes); printf("wrap_malloc address: %ld\n", foo); return foo; } extern "C" void __wrap_free(void *ptr) { printf("wrap_free: %ld\n", ptr); __real_free(ptr); } void* operator new (std::size_t size) throw (std::bad_alloc) { printf("new: %ld bytes\n", size); void *p = __wrap_malloc(size); printf("new address: %ld\n", p); return p; } void operator delete (void *p) { printf("delete: %ld\n", p); __wrap_free(p); } void operator delete (void *p, std::size_t) { printf("delete with size: %ld\n", p); __wrap_free(p); } int main(int argc, char ** argv) { printf("Creating new vector\n\n"); std::vector foo; printf("pushing an element\n\n"); foo.push_back(5); printf("Creating new ostringstream\n\n"); std::ostringstream msg2; printf("pushing once\n\n"); msg2 << "Blah blah blah "; printf("pushing twice\n\n"); msg2 << "boo dee doo" << std::endl; printf("printing it out\n\n"); std::cout << msg2.str(); } On 09/27/2016 01:10 PM, Jonathan Wakely wrote: > * Nikolaus Dunn: >> I've run into an issue where turning on compiler optimization using >> -O1 or higher causes an issue in my program. Specifically, I am >> replacing the new and delete operators globally to perform some real >> time allocation tracking. When I compile with -O1 or -O2, my >> implementation of new is not being called by STL classes, via the >> std::allocator. My version of delete IS being called. > That doesn't make much sense, because std::allocator doesn't use > new or delete for objects of type T, so neither should be called. > > Instead std::allocator allocates untyped memory (e.g. via malloc) > and then constructs objects into it with placement new-expressions. > > What do you replacement new and delete operators look like?