https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #28 from Martin Liška ---
Author: marxin
Date: Thu Jul 25 09:36:38 2019
New Revision: 273791
URL: https://gcc.gnu.org/viewcvs?rev=273791=gcc=rev
Log:
Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383).
2019-07-25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #27 from Marc Glisse ---
(In reply to Andrew Pinski from comment #0)
> the return is not turned into 1
It is now. I didn't check since when.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #26 from Antony Polukhin ---
> That said, it would be fine to add support for this
> under a non-standards-mode option of some sort of course.
C++14 allows to merge and remove global allocations [expr.new]:
"An implementation is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #23 from rguenther at suse dot de rguenther at suse dot de
2012-01-09 08:37:21 UTC ---
On Thu, 5 Jan 2012, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Jakub Jelinek jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #24 from rguenther at suse dot de rguenther at suse dot de
2012-01-09 08:39:37 UTC ---
On Thu, 5 Jan 2012, xinliangli at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #20 from davidxl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de
2012-01-05 08:39:57 UTC ---
On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #18 from davidxl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #20 from davidxl xinliangli at gmail dot com 2012-01-05 18:11:18
UTC ---
(In reply to comment #19)
On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #18 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #22 from davidxl xinliangli at gmail dot com 2012-01-05 18:54:51
UTC ---
(In reply to comment #21)
But can't a valid code also compare the result from realloc with the old
pointer, and if they are equal, do something, otherwise do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #17 from rguenther at suse dot de rguenther at suse dot de
2012-01-04 09:43:13 UTC ---
On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from davidxl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #18 from davidxl xinliangli at gmail dot com 2012-01-04 17:11:26
UTC ---
(In reply to comment #17)
On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from davidxl xinliangli at gmail dot com 2012-01-04 00:28:55
UTC ---
A related topic - aliasing property of realloc -- the malloc attribute is not
applied in the glibc header and the comment is like
/* __attribute_malloc__ is not
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-06-04 07:58
---
Interesting things start to happen once you inline allocator functions as well.
See PR29286 and PR33407 which we still don't handle 100% correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #13 from davidxl at gcc dot gnu dot org 2008-06-04 16:48
---
(In reply to comment #12)
Interesting things start to happen once you inline allocator functions as
well.
See PR29286 and PR33407 which we still don't handle 100% correct.
I browsed through the two bugs --
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-06-04 17:03
---
We do the exact opposite - type-based rules override points-to must-alias
information (or really may-alias information). Also for the proposed scheme
to work you need to guarantee that you always can compute
--- Comment #15 from davidxl at gcc dot gnu dot org 2008-06-04 17:34
---
(In reply to comment #14)
We do the exact opposite - type-based rules override points-to must-alias
information (or really may-alias information). Also for the proposed scheme
to work you need to guarantee
--- Comment #4 from sabre at nondot dot org 2008-06-04 03:21 ---
This would not be legal, there is no reason operator new can't return a pointer
that already exists in the program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #5 from xinliangli at gmail dot com 2008-06-04 04:15 ---
(In reply to comment #4)
This would not be legal, there is no reason operator new can't return a
pointer
that already exists in the program.
This is certainly a flaw in the C++ standard (it requires p returned
--- Comment #6 from sabre at nondot dot org 2008-06-04 04:32 ---
This has been extensively discussed on the C++ reflector. They decided
(informally, on the reflector) that people should be able to globally override
operator new to do logging, etc, which can make malloc have arbitrary
--- Comment #7 from sabre at nondot dot org 2008-06-04 04:32 ---
That said, it would be fine to add support for this under a non-standards-mode
option of some sort of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #8 from xinliangli at gmail dot com 2008-06-04 04:46 ---
(In reply to comment #6)
This has been extensively discussed on the C++ reflector. They decided
(informally, on the reflector) that people should be able to globally override
operator new to do logging, etc, which
--- Comment #9 from sabre at nondot dot org 2008-06-04 04:48 ---
This isn't possible. The user can override operator new at the very last
minute: e.g. by interposing a shared object with LD_PRELOAD. There is no way
that a compiler or even LTO optimizing linker can know about this. A
--- Comment #10 from xinliangli at gmail dot com 2008-06-04 05:23 ---
(In reply to comment #9)
This isn't possible. The user can override operator new at the very last
minute: e.g. by interposing a shared object with LD_PRELOAD. There is no way
that a compiler or even LTO
--- Comment #11 from sabre at nondot dot org 2008-06-04 05:34 ---
Expecting people to modify their source is bad news.
LLVM's LTO does nothing for operator new, it treats it as any other external
function with undefined behavior.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-12 20:29 ---
*** Bug 35559 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-05 07:48 ---
*** Bug 35467 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:34 ---
Confirmed:
*a = 1;
*b = 2;
t = *a;
operator delete (a);
operator delete (b);
return t;
--
What|Removed |Added
30 matches
Mail list logo
