From: "Richard Guenther" <richard.guenther@gmail.com>
To: "Mark Mitchell" <mark@codesourcery.com>
Cc: "Joe Buck" <Joe.Buck@synopsys.com>,
"Ross Smith" <r-smith@ihug.co.nz>,
"GCC Mailing List" <gcc@gcc.gnu.org>
Subject: Re: [RFC] Marking C++ new operator as malloc?
Date: Sun, 09 Sep 2007 20:04:00 -0000 [thread overview]
Message-ID: <84fc9c000709091304o1a1aafa1m5325bda8c46e90cd@mail.gmail.com> (raw)
In-Reply-To: <46E44FE9.9040306@codesourcery.com>
On 9/9/07, Mark Mitchell <mark@codesourcery.com> wrote:
> Joe Buck wrote:
>
> >> In the case of "malloc", and assuming that all of the machinery for
> >> malloc is hidden away in some piece of the program we're not talking
> >> about, all three definitions apply. Each pointer returned by malloc is
> >> an island unto itself; there's no conforming way to get there except by
> >> using the pointer just returned.
> >
> > The key point is that the mechanism is hidden away. This might become
> > more of an issue with LTO, so the question is how to make such guarantees
> > make sense to an optimizer that can see the full program.
>
> Correct. The "malloc" attribute is only applicable to "malloc" because
> we can't see how "malloc" is implemented.
>
> >> This seems like a useful optimization to me, and I understand that it
> >> will work 99.99% of the time, and it's in the spirit of the standard --
> >> but how do we actually make it safe? If the attribute only applied to
> >> other values returned from the same function, then it would be safe --
> >> but less useful. Can we do better?
> >
> > Maybe "pool", if exported, would have to be marked as aliasing the "new"
> > calls, possibly with some new attribute "malloc_implementation" or
> > something like that.
>
> It's worse than that:
>
> char *pool;
> void set_pool(char *p) { pool = p; }
> void *operator new(size_t s) { // return stuff from pool. }
>
> bool f() {
> char *p = new char[1024];
> set_pool (p);
> char *i = new char;
> return (p == i);
> }
>
> In other words, pointers from any part of the program can potentially be
> "laundered" through set_pool and return via the new operator. I don't
> see any way to make this fully safe, in general, without the limitation
> I imposed: the no-aliasing guarantee only applies to the values returned
> from the function called.
But in this case an access to *i through *p is invalid. [I suppose both
new calls are actually different implementations here] Each new
call starts lifetime of a new object, the previous object lifetime is
terminated. Even comparing both pointers here for this reason
would lead to undefined behavior.
I know it's easy to play games to trick optimizers into doing something,
but creating a not undefined testcase that goes wrong is hard ;) At
least iff you remember to transform 'malloc' attributes to a dynamic type
change if you inline a malloc.
Richard.
next prev parent reply other threads:[~2007-09-09 20:04 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 20:54 Martin Jambor
2007-09-08 1:26 ` Kaveh R. GHAZI
2007-09-08 1:30 ` Chris Lattner
2007-09-08 5:12 ` Joe Buck
2007-09-08 5:50 ` Gabriel Dos Reis
2007-09-08 14:45 ` H.J. Lu
2007-09-09 2:33 ` Martin Jambor
2007-09-08 20:06 ` Chris Lattner
2007-09-08 20:17 ` Basile STARYNKEVITCH
2007-09-09 1:36 ` Joe Buck
2007-09-09 1:44 ` Martin Jambor
2007-09-08 20:21 ` Richard Guenther
2007-09-08 21:26 ` Gabriel Dos Reis
2007-09-09 1:35 ` Joe Buck
2007-09-09 2:33 ` Gabriel Dos Reis
2007-09-09 17:34 ` Ross Smith
2007-09-09 17:49 ` Richard Guenther
2007-09-09 19:24 ` Mark Mitchell
2007-09-09 19:42 ` Joe Buck
2007-09-09 19:56 ` Mark Mitchell
2007-09-09 20:04 ` Richard Guenther [this message]
2007-09-09 20:22 ` Mark Mitchell
2007-09-09 20:27 ` Richard Guenther
2007-09-09 20:32 ` Mark Mitchell
2007-09-09 20:38 ` Richard Guenther
2007-09-09 20:41 ` Richard Guenther
2007-09-09 21:05 ` Mark Mitchell
2007-09-09 20:46 ` Mark Mitchell
2007-09-09 21:00 ` Richard Guenther
2007-09-09 21:13 ` Mark Mitchell
2007-09-09 21:32 ` Richard Guenther
2007-09-09 22:23 ` Mark Mitchell
2007-09-10 6:56 ` Richard Guenther
2007-09-11 4:17 ` Mark Mitchell
2007-09-11 9:16 ` Richard Guenther
2007-09-11 12:17 ` Gabriel Dos Reis
2007-09-11 12:24 ` Richard Guenther
2007-09-11 22:09 ` Mark Mitchell
2007-09-10 14:43 ` Tom Tromey
2007-09-10 17:40 ` Daniel Berlin
2007-09-09 21:27 ` Gabriel Dos Reis
2007-09-09 21:25 ` Gabriel Dos Reis
2007-09-10 12:18 ` Martin Jambor
2007-09-09 19:51 ` Richard Guenther
2007-09-09 20:08 ` Richard Guenther
2007-09-12 1:15 ` Ian Lance Taylor
2007-09-12 8:01 ` Richard Guenther
2007-09-12 15:14 ` Ian Lance Taylor
2007-09-12 15:18 ` Richard Guenther
2007-09-09 21:22 ` Gabriel Dos Reis
2007-09-09 19:15 ` Joe Buck
2007-09-09 2:10 ` Martin Jambor
2007-09-09 2:38 ` Gabriel Dos Reis
2007-09-13 23:38 ` Andrew Pinski
2007-09-14 0:29 ` Gabriel Dos Reis
2007-09-14 1:00 ` Andrew Pinski
2007-09-14 1:33 ` Gabriel Dos Reis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84fc9c000709091304o1a1aafa1m5325bda8c46e90cd@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=Joe.Buck@synopsys.com \
--cc=gcc@gcc.gnu.org \
--cc=mark@codesourcery.com \
--cc=r-smith@ihug.co.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).