From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72559 invoked by alias); 17 May 2017 21:01:05 -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 72545 invoked by uid 89); 17 May 2017 21:01:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=bf X-HELO: mail-qt0-f180.google.com Received: from mail-qt0-f180.google.com (HELO mail-qt0-f180.google.com) (209.85.216.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 May 2017 21:01:02 +0000 Received: by mail-qt0-f180.google.com with SMTP id f55so19984713qta.3 for ; Wed, 17 May 2017 14:01:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DUUhmDOw8yPDgZOmlyLd7pDrTNo5I9qLYoPI7MrhrJ8=; b=g1FAk71Fj6xZD+yaiuhYAqeBlqD0GCkDAgUos0mNLBcIwiSirYC6WQVmg7hs7INRF2 J3f8EhdCbB17eH7oR7GK4hbvnGVZJduDrSkFtBoBLYq82kOY6gQ6NvmuPnwSlPeulj9i IMrJYz/7ANRiz+adOeBNzoxeGM3Z8LuvHFrlES2mxwXiUTyy+WXK8mMuc0UFpEDi4hSE wdn3drtBaZBPCFnSxHOeHP6wjjHtA1oCaZ05fglOAiTJo0Y0AL0Xs8eWDwTl4TUTADvW MNWVqsKwH/WYQ8ZOt23sbYJQXytsgee04XT0KSKYxRBPyB4Lu/szcdas92nmqpt27FP6 oVLA== X-Gm-Message-State: AODbwcCtJIKcxYAbe7/UYWFuSlr/DHSOOEkWrCM5WmueykoX7BNsJY9G pC/7AfaBRxvS3w== X-Received: by 10.200.39.215 with SMTP id x23mr788274qtx.155.1495054864341; Wed, 17 May 2017 14:01:04 -0700 (PDT) Received: from localhost.localdomain (97-118-111-137.hlrn.qwest.net. [97.118.111.137]) by smtp.gmail.com with ESMTPSA id q95sm2236331qkq.22.2017.05.17.14.01.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 14:01:03 -0700 (PDT) Subject: Re: [RFC] propagate malloc attribute in ipa-pure-const pass To: Prathamesh Kulkarni , gcc Patches , Jan Hubicka , Richard Biener References: From: Martin Sebor Message-ID: <89e261a6-1ebd-0e8a-fdf3-4fce98a40ca8@gmail.com> Date: Wed, 17 May 2017 21:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg01423.txt.bz2 > The patch passes bootstrap+test on x86_64 and found a few functions in > the source tree (attached func_names.txt) that could be annotated with > malloc (I gave a brief look at some of the functions and didn't appear > to be false positives but I will recheck thoroughly) virtual char* libcp1::compiler::find(std::__cxx11::string&) const The virtual on the list of your candidates gave me pause. Consider this completely contrived example: struct B { virtual void* f (unsigned n) { return new char [n]; } }; void* foo (B &b, unsigned n) { return b.f (n); } Based on these definitions alone both functions are candidates for attribute malloc. But suppose foo is called with an object of a type derived from B that overrides f() to do something wacky (but strictly not invalid) like: struct D: B { char buf[32]; virtual void* f (unsigned n) { if (n < 32) return n <= 32 ? buf : B::f (n); } Breaking foo's attribute malloc constraint. In other words, I think virtual functions need to be excluded from the list (unless they're defined in a class marked final, or unless we know they're not overridden to break the constraint like above). Martin