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&root=gcc&view=rev
Log:
Extend DCE to remove unnecessary new/delete-pairs (PR c++/23383).
2019-0
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 all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Andrew Pinski changed:
What|Removed |Added
CC||vincenzo.innocente at cern dot
ch
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #24 from 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 2012-01-05
> 18:11:18 UTC --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #23 from 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 changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #22 from davidxl 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 something else?
> I think i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #20 from davidxl 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 davidxl 2012-01-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #19 from 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 2012-01-04
> 17:11:26 UTC --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #18 from davidxl 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 davidxl 2012-01-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #17 from 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 2012-01-04
> 00:28:55 UTC --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- Comment #16 from davidxl 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 used, because if realloc re
--- 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 t
--- 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 corre
--- 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 #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 #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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
--- 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 optimiz
--- 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 s
--- 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, whic
--- 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 #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 si
--- 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 return
--- 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 #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
