On Wed, 8 Apr 2020 at 08:35, Richard Biener wrote:
> Ah, so __builtin_operator_new isn't a function but an alternate
> new expression syntax?
No, not a new-expression, because a new-expression calls operator new
to obtain storage *and* begins the lifetime of one or more objects in
that storage. __
On Tue, Apr 7, 2020 at 5:17 PM Jonathan Wakely wrote:
>
> On Tue, 7 Apr 2020 at 12:57, Richard Biener
> wrote:
> >
> > On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely
> > wrote:
> > >
> > > On Tue, 7 Apr 2020 at 12:40, Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Apr 7, 2020 at 1:30 PM
On Tue, 7 Apr 2020 at 12:57, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote:
> >
> > On Tue, 7 Apr 2020 at 12:40, Richard Biener
> > wrote:
> > >
> > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely
> > > wrote:
> > > >
> > > > On Mon, 6 Apr 2020 at 13:45, Nath
On 4/7/20 7:29 AM, Jonathan Wakely wrote:
On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
The both operator new and operator delete are looked up in the same
manner. The std does not require a 'matching pair' be found. but it is
extremely poor form for a class to declare exactly one of oper
On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote:
>
> On Tue, 7 Apr 2020 at 12:40, Richard Biener
> wrote:
> >
> > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely
> > wrote:
> > >
> > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > > The both operator new and operator delete are
On Tue, 7 Apr 2020 at 12:40, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote:
> >
> > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > The both operator new and operator delete are looked up in the same
> > > manner. The std does not require a 'matching pai
On Tue, 7 Apr 2020 at 10:29, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wrote:
> >
> > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > >
> > > On 4/6/20 4:34 AM, Martin Liška wrote:
> > >
> > > >
> > > > May I please ping Jason, Nathan and Jonathan who can h
On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote:
>
> On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > The both operator new and operator delete are looked up in the same
> > manner. The std does not require a 'matching pair' be found. but it is
> > extremely poor form for a class to d
On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> The both operator new and operator delete are looked up in the same
> manner. The std does not require a 'matching pair' be found. but it is
> extremely poor form for a class to declare exactly one of operator
> {new,delete}.
There are unfortu
On 4/6/20 2:45 PM, Nathan Sidwell wrote:
On 4/6/20 4:34 AM, Martin Liška wrote:
May I please ping Jason, Nathan and Jonathan who can help us here?
On IRC Martin clarified the question as essentially 'how do you pair up
operator new and operator delete calls?' (so you may delete them if the
On 4/7/20 12:22 PM, Richard Biener wrote:
On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote:
Well, the question is how to identify "operator new and operator delete at the
point of the new-expression and delete-expression". Currently we're
just matching up "is this a new/delete operator" an
On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote:
>
> >
> > Well, the question is how to identify "operator new and operator delete at
> > the
> > point of the new-expression and delete-expression". Currently we're
> > just matching up "is this a new/delete operator" and the dataflow of the
> >
>
> Well, the question is how to identify "operator new and operator delete at the
> point of the new-expression and delete-expression". Currently we're
> just matching up "is this a new/delete operator" and the dataflow of the
> pointer. In the PR it was suggested the actual called methods shou
On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wrote:
>
> On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> >
> > On 4/6/20 4:34 AM, Martin Liška wrote:
> >
> > >
> > > May I please ping Jason, Nathan and Jonathan who can help us here?
> >
> > On IRC Martin clarified the question as essential
On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
>
> On 4/6/20 4:34 AM, Martin Liška wrote:
>
> >
> > May I please ping Jason, Nathan and Jonathan who can help us here?
>
> On IRC Martin clarified the question as essentially 'how do you pair up
> operator new and operator delete calls?' (so you
On Mon, Apr 6, 2020 at 5:27 AM Richard Biener via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote:
> >
> > Hi,
> > thinking a bit of the problem, I guess we could match in addition to
> > DECL_CONTEXT the whole inline stack of both statements and s
On 4/6/20 4:34 AM, Martin Liška wrote:
May I please ping Jason, Nathan and Jonathan who can help us here?
On IRC Martin clarified the question as essentially 'how do you pair up
operator new and operator delete calls?' (so you may delete them if the
object is not used).
I am not sure you'
On Sat, Apr 4, 2020 at 1:53 PM Jan Hubicka wrote:
>
> Hi,
> thinking a bit of the problem, I guess we could match in addition to
> DECL_CONTEXT the whole inline stack of both statements and see if there
> are inlined new/delete operators and if so if they are always in
> matching pairs.
>
> The in
On 4/3/20 5:26 PM, Jan Hubicka wrote:
On 3/31/20 2:29 PM, Jan Hubicka wrote:
Well, I basically went through all pointers and tried to get rid of as
many of them as possible. CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merg
Hi,
thinking a bit of the problem, I guess we could match in addition to
DECL_CONTEXT the whole inline stack of both statements and see if there
are inlined new/delete operators and if so if they are always in
matching pairs.
The inline stack is available as
for (tree block = gimple_block (call);
Hi,
and this is the streaming fix
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index e4077b58890..dd9645723c1 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -646,6 +647,19 @@ degenerate_phi_p (gimple *phi)
return true;
}
+/* Return true if C1 and C2 are matching contexts
> On 3/31/20 2:29 PM, Jan Hubicka wrote:
> > Well, I basically went through all pointers and tried to get rid of as
> > many of them as possible. CONTEXT pointers do increase size of SCCs
> > that increases chance they will not get merged and also processing time
> > of merging algorithm. I guess
On 3/31/20 2:29 PM, Jan Hubicka wrote:
Well, I basically went through all pointers and tried to get rid of as
many of them as possible. CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merging algorithm. I guess if we need to s
> On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch ensures that a deleted new/delete pair has a same context.
> > That will fix the issue presented in the PR.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> I think this will bre
On Mon, 30 Mar 2020, Martin Liška wrote:
The patch ensures that a deleted new/delete pair has a same context.
That will fix the issue presented in the PR.
DECL_CONTEXT seems good for that example (assuming it is still available
in the middle-end), but shouldn't we also check if both are array
On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote:
>
> Hi.
>
> The patch ensures that a deleted new/delete pair has a same context.
> That will fix the issue presented in the PR.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I think this will break the DCE with LTO
Hi.
The patch ensures that a deleted new/delete pair has a same context.
That will fix the issue presented in the PR.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-03-30 Martin Liska
PR c++/94314
27 matches
Mail list logo
