On 9/7/07, Chris Lattner [EMAIL PROTECTED] wrote:
It is unclear whether this is safe. Nothing in the standard AFAIK
requires the operator new be implemented in terms of malloc, and
users are allowed to override it.
I was looking for something else in the standard and found this (5.3.4/7):
Andrew Pinski [EMAIL PROTECTED] writes:
| On 9/7/07, Chris Lattner [EMAIL PROTECTED] wrote:
|
| It is unclear whether this is safe. Nothing in the standard AFAIK
| requires the operator new be implemented in terms of malloc, and
| users are allowed to override it.
|
| I was looking for
On 13 Sep 2007 19:37:27 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Do you believe that allocator is prohibited by the C++ standard?
Yes just because it points to another object at that point.
Now people do these tricks, I know but I guess most of them don't
understand C++ that much to
On Thu, 13 Sep 2007, Andrew Pinski wrote:
| On 13 Sep 2007 19:37:27 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
| Do you believe that allocator is prohibited by the C++ standard?
|
| Yes just because it points to another object at that point.
I'm afraid that is too dense for me. Please
On 11 Sep 2007 18:14:21 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] writes:
On 9/9/07, Richard Guenther [EMAIL PROTECTED] wrote:
Which brings back the fact that you cannot implement malloc in C
(you certainly remember the discussions about C++
Richard Guenther [EMAIL PROTECTED] writes:
CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
we need __attribute__ ((change_dynamic_type))?
Or actually of course __attribute__ ((malloc)) is fine but we could
throw in a CHANGE_DYNAMIC_TYPE_EXPR after any call to such a
On 12 Sep 2007 08:13:31 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] writes:
CHANGE_DYNAMIC_TYPE_EXPR has the target type, of course. So perhaps
we need __attribute__ ((change_dynamic_type))?
Or actually of course __attribute__ ((malloc)) is
On 9/11/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
Well, we have that now:
int *q = new int;
delete q;
int *p = new int;
delete p;
if (q != p)
cout different;
we cannot optimize the test to be always true. The point is that alias
Richard Guenther [EMAIL PROTECTED] writes:
[...]
| I think I'm getting confused. Perhaps you could sum up in a single
| email the argument for why putting this attribute in our standard
| headers is safe, even in view of possible replacement in user programs?
|
| My argument goes like We
On 11 Sep 2007 07:24:44 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Richard Guenther [EMAIL PROTECTED] writes:
[...]
| I think I'm getting confused. Perhaps you could sum up in a single
| email the argument for why putting this attribute in our standard
| headers is safe, even in
Richard Guenther wrote:
So, for something like:
char *pool;
void *operator new[] (size_t s) { /* return memory from pool */ }
...
pool = new char[1024];
char *c = new char[16];
IIUC, your claim is that if pool and c now have the same value, then any
indirection through pool is
Richard Guenther [EMAIL PROTECTED] writes:
On 9/9/07, Richard Guenther [EMAIL PROTECTED] wrote:
Which brings back the fact that you cannot implement malloc in C
(you certainly remember the discussions about C++ placement new
handling wrt aliasing). To re-use the machinery we invented
On 9/10/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
What is an example program in that meets the requirements I gave above
-- i.e., allows the compiler to prove that two same-typed pointers do
not alias (whether by the compiler's cleverness, use of restrict, or
Hi,
On Sun, Sep 09, 2007 at 12:56:25PM -0700, Mark Mitchell wrote:
For a particular implementation of operator new (such as the one in
libstdc++), you can of course make it safe in the same way as malloc;
hide the implementation somewhere the rest of the program can't see it
(modulo LTO).
Mark == Mark Mitchell [EMAIL PROTECTED] writes:
Mark If the compiler treats:
Mark int *p = new int;
Mark any differently from:
Mark int r = *new int;
Mark then we're missing an optimization opportunity.
AFAIK we don't have a way to mark a function as cannot return NULL.
This is PR 20318.
On 9/10/07, Tom Tromey [EMAIL PROTECTED] wrote:
Mark == Mark Mitchell [EMAIL PROTECTED] writes:
Mark If the compiler treats:
Mark int *p = new int;
Mark any differently from:
Mark int r = *new int;
Mark then we're missing an optimization opportunity.
AFAIK we don't have a way to mark
Richard Guenther wrote:
Well, we have that now:
int *q = new int;
delete q;
int *p = new int;
delete p;
if (q != p)
cout different;
we cannot optimize the test to be always true. The point is that alias
analysis tells us something about accesses to *q and *p, but
Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| Richard Guenther [EMAIL PROTECTED] writes:
|
| | On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
| | I understand, but allowing users to override new means
On 9/9/07, Ross Smith [EMAIL PROTECTED] wrote:
Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| Richard Guenther [EMAIL PROTECTED] writes:
|
| | On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
| |
On Mon, Sep 10, 2007 at 05:33:24AM +1200, Ross Smith wrote:
[...] If the request succeeds, the value returned shall be a nonnull
pointer value (4.10) p0 different from any previously returned value
p1, unless that value p1 was subsequently passed to an operator delete.
That's not
Richard Guenther wrote:
Probably the most common use of a custom new is to allocate memory from
a user-controlled pool instead of the standard free store. Somewhere in
the program there will be a pointer to the complete pool, which aliases
every pointer returned by that version of new. Any
On Sun, Sep 09, 2007 at 12:24:13PM -0700, Mark Mitchell wrote:
The term cannot alias is not fully defined. It could mean cannot
have the same value as any other pointer of the same type. It could
mean cannot have the same value as any other pointer, when both
pointers are cast to `void *'.
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
Probably the most common use of a custom new is to allocate memory from
a user-controlled pool instead of the standard free store. Somewhere in
the program there will be a pointer to the complete pool, which aliases
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
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] 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
On 9/9/07, Richard Guenther [EMAIL PROTECTED] wrote:
Which brings back the fact that you cannot implement malloc in C
(you certainly remember the discussions about C++ placement new
handling wrt aliasing). To re-use the machinery we invented there
we would need to place a
Richard Guenther wrote:
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
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
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;
Richard Guenther wrote:
I don't know of any place we would use such information. At least
int *p = new int;
int *q = new int;
if (p == q)
cannot be simplified as both pointers may be NULL?
They cannot be NULL; new-expressions throw an exception if the
allocation fails. (Of
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
I don't know of any place we would use such information. At least
int *p = new int;
int *q = new int;
if (p == q)
cannot be simplified as both pointers may be NULL?
They cannot be NULL;
On 9/9/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
I don't know of any place we would use such information. At least
int *p = new int;
int *q = new int;
if (p == q)
cannot be simplified as
Richard Guenther wrote:
We should optimize away things like:
int *p = new int;
if (!p)
cerr Could not allocate memory\n;
We don't I believe.
That's a missed-optimization, and independent of any attributes on
operator new. It's a property of the new *expression*, not of the
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
But, I don't think that even the C meaning is safe in C++ for use with
the library declaration of new. I'm also somewhat skeptical of the
idea that we will never do any optimization on pointer comparisons.
What design principle in the
Richard Guenther wrote:
A better one:
int *p = new int;
foo(p);
int *q = new int;
if foo deletes p then q may be equal to p. But alias analysis still
(validly!) says they don't alias.
Yes, I agree that this is safe. (Either p is still valid and
therefore different from q, or it
Richard Guenther wrote:
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
But, I don't think that even the C meaning is safe in C++ for use with
the library declaration of new. I'm also somewhat skeptical of the
idea that we will never do any optimization on pointer comparisons.
What design
Mark Mitchell [EMAIL PROTECTED] writes:
[...]
| This seems like a useful optimization to me, and I understand that it
| will work 99.99% of the time
Except for people writing allocators :-)
-- Gaby
Richard Guenther [EMAIL PROTECTED] writes:
[...]
| 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 =
Richard Guenther [EMAIL PROTECTED] writes:
[...]
| I don't know of any place we would use such information. At least
|
| int *p = new int;
| int *q = new int;
| if (p == q)
|
| cannot be simplified as both pointers may be NULL?
The above does not use the no-throw operator new, so
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
But, I don't think that even the C meaning is safe in C++ for use with
the library declaration of new. I'm also somewhat skeptical of the
idea that we will never do
Richard Guenther wrote:
What is an example program in that meets the requirements I gave above
-- i.e., allows the compiler to prove that two same-typed pointers do
not alias (whether by the compiler's cleverness, use of restrict, or
whatever), but where the compiler must still assume that
On Sat, Sep 08, 2007 at 12:57:13AM -0500, Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
| [ giving operator new the malloc property ]
|
| On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
| It is unclear
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute
malloc.
-Chris
http://nondot.org/sabre
http://llvm.org
On Sep 7, 2007, at 10:12 PM, Joe Buck [EMAIL PROTECTED] wrote:
On Sep 7, 2007, at 1:53 PM,
Chris Lattner wrote:
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute malloc.
-Chris
On Sep 7, 2007, at 10:12 PM, Joe Buck [EMAIL PROTECTED] wrote:
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
[
On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute
malloc.
Well, you can argue that all hell breaks lose if you do so. A sane ::new
is required for almost
Richard Guenther [EMAIL PROTECTED] writes:
| On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
| I understand, but allowing users to override new means that the actual
| implementation may not honor the aliasing guarantees of attribute
| malloc.
|
| Well, you can argue that all hell breaks
On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
Richard Guenther [EMAIL PROTECTED] writes:
| On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
| I understand, but allowing users to override new means that the actual
| implementation may not honor the aliasing guarantees
On Sat, Sep 08, 2007 at 10:16:41PM +0200, Basile STARYNKEVITCH wrote:
Maybe it could make sense to give the malloc attribute only to
::operator new but not to other new-s, in particular not to the
placement new?
It would be completely wrong to give the attribute to placement new,
as the
Hi,
On Sat, Sep 08, 2007 at 10:16:41PM +0200, Basile STARYNKEVITCH wrote:
Chris Lattner wrote:
I understand, but allowing users to override new means that the actual
implementation may not honor the aliasing guarantees of attribute malloc.
-Chris
Maybe it could make sense to give the
Hi,
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as
Hi,
On Sat, Sep 08, 2007 at 07:45:32AM -0700, H.J. Lu wrote:
On Sat, Sep 08, 2007 at 12:57:13AM -0500, Gabriel Dos Reis wrote:
I seem to remember we had had this discussion before -- in connection
with optimizations related to 'malloc' attribute -- and decided not to
apply the attribute
Joe Buck [EMAIL PROTECTED] writes:
| On Sat, Sep 08, 2007 at 04:33:50PM -0500, Gabriel Dos Reis wrote:
| Richard Guenther [EMAIL PROTECTED] writes:
|
| | On 9/8/07, Chris Lattner [EMAIL PROTECTED] wrote:
| | I understand, but allowing users to override new means that the actual
| |
Martin Jambor [EMAIL PROTECTED] writes:
[...]
| The reason why I believe the patch is safe not only in practice but
| also in principle
However, I do not believe it is sufficient. The reason being that
if the user does not include a header that pulls in that declaration,
then that
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be to mark the new operator function with the
malloc
On Fri, 7 Sep 2007, Martin Jambor wrote:
Index: libstdc++-v3/libsupc++/new
===
--- libstdc++-v3/libsupc++/new(revision 128207)
+++ libstdc++-v3/libsupc++/new(working copy)
@@ -92,7 +92,8 @@
* Placement new
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
[ giving operator new the malloc property ]
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
It is unclear whether this is safe. Nothing in the standard AFAIK
requires the operator new be implemented in terms of malloc, and
Joe Buck [EMAIL PROTECTED] writes:
| On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
| [ giving operator new the malloc property ]
|
| On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
| It is unclear whether this is safe. Nothing in the standard AFAIK
| requires the operator
57 matches
Mail list logo
