On Fri, 17 Apr 2020 at 08:05, Jakub Jelinek wrote:
> One needs to use check-c++-all or GXX_TESTSUITE_STDS=98,11,14,17,2a make check
> or similar to get that though, because 11 isn't tested by default, only 98,
> 14 and 17 are ATM I think.
Right.
> Fixed thusly, committed to trunk as obvious.
On Tue, Apr 14, 2020 at 12:54:17PM +0200, Martin Liška wrote:
> On 4/14/20 10:37 AM, Jakub Jelinek wrote:
> > On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:
> > > +/* PR c++/94314. */
> > > +/* { dg-do run } */
> > > +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
On 4/14/20 10:37 AM, Jakub Jelinek wrote:
On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:
+/* PR c++/94314. */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
+/* { dg-additional-options "-fdelete-null-pointer-checks" } */
Any reason why
On Tue, Apr 14, 2020 at 09:11:37AM +0200, Martin Liška wrote:
> +/* PR c++/94314. */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -fdump-tree-cddce-details -std=c++14" } */
> +/* { dg-additional-options "-fdelete-null-pointer-checks" } */
Any reason why you want to do it for -std=c++14 only?
On 4/14/20 9:09 AM, Martin Liška wrote:
I've updated a bit the Jakub's patch.
I forgot to remove valid_pairs data structure, fixed here.
Martin
>From fb093e29d013ce0ce8e9181bd10635d14a48bcd2 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 9 Apr 2020 15:50:58 +0200
Subject: [PATCH]
On 4/10/20 11:17 AM, Jakub Jelinek wrote:
On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote:
+/* Valid pairs of new and delete operators for DCE. */
+static hash_set *valid_pairs = NULL;
+
+/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
+ and delete operators.
On Fri, Apr 10, 2020 at 10:29:29AM +0200, Martin Liška wrote:
> +/* Valid pairs of new and delete operators for DCE. */
> +static hash_set *valid_pairs = NULL;
> +
> +/* Return that NEW_CALL and DELETE_CALL are a valid pair of new
> + and delete operators. */
> +
> +static bool
>
Marc Glisse wrote:
On Fri, 10 Apr 2020, Martin Liška wrote:
On 4/9/20 10:13 AM, Jonathan Wakely wrote:
On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both
On Fri, 10 Apr 2020, Martin Liška wrote:
On 4/9/20 10:13 AM, Jonathan Wakely wrote:
On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both match the same new,
On 4/10/20 10:18 AM, Jonathan Wakely wrote:
On Fri, 10 Apr 2020 at 09:08, Martin Liška wrote:
Marc pointed out that some targets do not use the leading '_' (or use 2
dashes?) for mangled named?
Double underscore at the start. I think darwin uses that.
Ah yeah, not dashes, but underscores
On Fri, 10 Apr 2020 at 09:08, Martin Liška wrote:
> Marc pointed out that some targets do not use the leading '_' (or use 2
> dashes?) for mangled named?
Double underscore at the start. I think darwin uses that.
On 4/9/20 10:13 AM, Jonathan Wakely wrote:
On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both match the same new, IIUC.
Right.
Not sure about the nothrow
On 4/9/20 1:05 AM, Martin Liška wrote:
Hi.
We've got one another sneaky test-case (thank you Marc ;) ):
$ cat pr94314-array.C
#include
#include
int count = 0;
__attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {
++count;
return ::operator new(sz);
}
void
On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
> Note that the matching is not 1-to-1. Array vs non-array and
> aligned vs non-aligned seem important, but sized and unsized delete can
> both match the same new, IIUC.
Right.
> Not sure about the nothrow versions...
This is valid, and mixes the
On Thu, 9 Apr 2020, Richard Biener wrote:
On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote:
Hi.
We've got one another sneaky test-case (thank you Marc ;) ):
$ cat pr94314-array.C
#include
#include
int count = 0;
__attribute__((malloc, noinline)) void* operator new[](unsigned long sz)
On Thu, Apr 09, 2020 at 08:59:59AM +0200, Martin Liška wrote:
> What do you mean by 'decl flags'. We can't compare ASM names as one is ctor
> and the second one is dtor. It's about argument types that much match, right?
You can't disginguish the [] vs. non-[] from arguments, plus there are some
On Thu, Apr 9, 2020 at 9:00 AM Martin Liška wrote:
>
> On 4/9/20 8:45 AM, Richard Biener wrote:
> > On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> We've got one another sneaky test-case (thank you Marc ;) ):
> >>
> >> $ cat pr94314-array.C
> >> #include
> >> #include
On 4/9/20 8:45 AM, Richard Biener wrote:
On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote:
Hi.
We've got one another sneaky test-case (thank you Marc ;) ):
$ cat pr94314-array.C
#include
#include
int count = 0;
__attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {
On Thu, Apr 9, 2020 at 7:06 AM Martin Liška wrote:
>
> Hi.
>
> We've got one another sneaky test-case (thank you Marc ;) ):
>
> $ cat pr94314-array.C
> #include
> #include
>
> int count = 0;
>
> __attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {
>++count;
>return
Hi.
We've got one another sneaky test-case (thank you Marc ;) ):
$ cat pr94314-array.C
#include
#include
int count = 0;
__attribute__((malloc, noinline)) void* operator new[](unsigned long sz) {
++count;
return ::operator new(sz);
}
void operator delete[](void* ptr) noexcept {
On Wed, Apr 08, 2020 at 05:46:52PM +0200, Jan Hubicka wrote:
> I am not quite sure about the offloading done by openMP - I think that
> one produces new decls.
Yes, it does. It copies some FUNCTION_DECL flags over, but only selected
ones (and all attributes but removes a few afterwards).
> From 2f8ba3418f10b41bb839aadb292447bd757238d0 Mon Sep 17 00:00:00 2001
> From: Martin Liska
> Date: Tue, 7 Apr 2020 16:23:27 +0200
> Subject: [PATCH] Allow new/delete operator deletion only for replaceable.
>
> gcc/ChangeLog:
>
> 2020-04-07 Martin Liska
, 7 Apr 2020 16:23:27 +0200
Subject: [PATCH] Allow new/delete operator deletion only for replaceable.
gcc/ChangeLog:
2020-04-07 Martin Liska
PR c++/94314
* gimple.c (gimple_call_operator_delete_p): Rename to...
(gimple_call_replaceable_operator_delete_p): ... this.
On 4/8/20 9:32 AM, Jakub Jelinek wrote:
On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote:
On 4/8/20 4:47 AM, Richard Biener wrote:
On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote:
Hi.
The patch allows DCE to remove only replaceable operators new and delete.
On Wed, Apr 08, 2020 at 09:20:07AM -0400, Jason Merrill via Gcc-patches wrote:
> On 4/8/20 4:47 AM, Richard Biener wrote:
> > On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote:
> > >
> > > Hi.
> > >
> > > The patch allows DCE to remove only replaceable operators new and delete.
> > > That's
On 4/8/20 4:47 AM, Richard Biener wrote:
On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote:
Hi.
The patch allows DCE to remove only replaceable operators new and delete.
That's achieved by proper mark up of all these operators in C++ FE.
The patch also brings all tests we've collected so far
On Tue, Apr 7, 2020 at 5:01 PM Martin Liška wrote:
>
> Hi.
>
> The patch allows DCE to remove only replaceable operators new and delete.
> That's achieved by proper mark up of all these operators in C++ FE.
> The patch also brings all tests we've collected so far for the PR.
>
> Patch can
to be installed?
Thanks,
Martin
>From 815495bbd52abe0da173c8f88d1de8dcb6095ba7 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 7 Apr 2020 16:23:27 +0200
Subject: [PATCH] Allow new/delete operator deletion only for replaceable.
gcc/ChangeLog:
2020-04-07 Martin Liska
PR c++/94
28 matches
Mail list logo
