OK.
Jason
On Wed, 2 Oct 2013, Jason Merrill wrote:
On 10/02/2013 08:33 AM, Marc Glisse wrote:
+ if (flag_delete_null_pointer_checks && !flag_check_new
You can't use flag_check_new in language-independent code without moving it
from c.opt to common.opt.
New version, tested with bootstrap+testsu
On Wed, Oct 02, 2013 at 04:12:24PM +0300, Marc Glisse wrote:
> On Wed, 2 Oct 2013, Jason Merrill wrote:
>
> >On 10/02/2013 08:33 AM, Marc Glisse wrote:
> >>+ if (flag_delete_null_pointer_checks && !flag_check_new
> >
> >You can't use flag_check_new in language-independent code without
> >moving
On Wed, 2 Oct 2013, Jason Merrill wrote:
On 10/02/2013 08:33 AM, Marc Glisse wrote:
+ if (flag_delete_null_pointer_checks && !flag_check_new
You can't use flag_check_new in language-independent code without moving it
from c.opt to common.opt.
Thanks, that makes sense and I'll do that
On 10/02/2013 08:33 AM, Marc Glisse wrote:
+ if (flag_delete_null_pointer_checks && !flag_check_new
You can't use flag_check_new in language-independent code without moving
it from c.opt to common.opt.
Jason
New version after Jakub's comment, bootstrap and testsuite on x86_64.
2013-10-03 Marc Glisse
PR c++/19476
gcc/
* calls.c (alloca_call_p): Use get_callee_fndecl.
* fold-const.c (tree_expr_nonzero_warnv_p): Handle operator new.
* tree-vrp.c (gimple_stmt_nonzero_w
On Wed, 2 Oct 2013, Jakub Jelinek wrote:
On Mon, Sep 09, 2013 at 10:49:40PM +0200, Marc Glisse wrote:
--- fold-const.c(revision 202413)
+++ fold-const.c(working copy)
@@ -16171,21 +16171,31 @@ tree_expr_nonzero_warnv_p (tree t, bool
case MODIFY_EXPR:
case BIND_EXPR:
On Mon, Sep 09, 2013 at 10:49:40PM +0200, Marc Glisse wrote:
> --- fold-const.c (revision 202413)
> +++ fold-const.c (working copy)
> @@ -16171,21 +16171,31 @@ tree_expr_nonzero_warnv_p (tree t, bool
> case MODIFY_EXPR:
> case BIND_EXPR:
>return tree_expr_nonzero_warnv_p
It isn't a front-end patch, but it is still a C++ patch, maybe Jason will
have comments? Anyone else?
On Mon, 16 Sep 2013, Marc Glisse wrote:
Nobody has expressed concern for a week, so it may be worth doing an official
review ;-)
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
On M
Nobody has expressed concern for a week, so it may be worth doing an
official review ;-)
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00676.html
On Mon, 9 Sep 2013, Marc Glisse wrote:
I have now tested bootstrap+testsuite and there was no regression.
2013-09-07 Marc Glisse
PR c++
I have now tested bootstrap+testsuite and there was no regression.
2013-09-07 Marc Glisse
PR c++/19476
gcc/
* fold-const.c (tree_expr_nonzero_warnv_p): Handle operator new.
* tree-vrp.c (gimple_stmt_nonzero_warnv_p, stmt_interesting_for_vrp):
Likewise.
On Mon, Sep 9, 2013 at 12:54 PM, Mike Stump wrote:
> On Sep 9, 2013, at 10:25 AM, Gabriel Dos Reis
> wrote:
>> On Mon, Sep 9, 2013 at 11:16 AM, Mike Stump wrote:
>>> You've failed to understand g++. Please seek to understand the compiler,
>>> before you weigh in.
>>
>> Gee Mike, see a medical
On Mon, Sep 9, 2013 at 11:16 AM, Mike Stump wrote:
> You've failed to understand g++. Please seek to understand the compiler,
> before you weigh in.
Gee Mike, see a medical assistance for your and our benefits.
-- Gaby
On Sep 9, 2013, at 10:25 AM, Gabriel Dos Reis
wrote:
> On Mon, Sep 9, 2013 at 11:16 AM, Mike Stump wrote:
>> You've failed to understand g++. Please seek to understand the compiler,
>> before you weigh in.
>
> Gee Mike, see a medical assistance for your and our benefits.
Seems overly hostile
On Sep 7, 2013, at 2:00 PM, Marc Glisse wrote:
> @@ -16171,21 +16171,31 @@ tree_expr_nonzero_warnv_p (tree t, bool
> + if (TREE_CODE (fndecl) != FUNCTION_DECL) return false;
> + if (!flag_check_new
> + && DECL_IS_OPERATOR_NEW (fndecl)
> + && !TREE_NOTHROW (fndecl))
> +
On Sep 7, 2013, at 1:03 PM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Mike Stump wrote:
>
>>
>> On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
>> wrote:
>>
>>> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
> On Sep 7, 2013, at 3:33 AM,
On Sep 7, 2013, at 5:34 PM, Gabriel Dos Reis
wrote:
> On Sat, Sep 7, 2013 at 2:46 PM, Mike Stump wrote:
>>
>> On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
>> wrote:
>>
>>> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
> On Sep 7, 20
On Sep 9, 2013, at 5:41 AM, Gabriel Dos Reis
wrote:
> On Mon, Sep 9, 2013 at 4:06 AM, Richard Biener
> wrote:
>> On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
>
> Now flag_check_n
On Mon, Sep 9, 2013 at 4:19 AM, Marc Glisse wrote:
> On Mon, 9 Sep 2013, Richard Biener wrote:
>
>> On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
>>>
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
>
>
> Now flag_check_new shou
On Mon, Sep 9, 2013 at 4:06 AM, Richard Biener
wrote:
> On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>
>>> On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
>>>
>>>
>>> Yes, thi
On Mon, 9 Sep 2013, Richard Biener wrote:
On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
Yes, this why my point.
Ok, here it is (a
On Sat, Sep 7, 2013 at 11:00 PM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Mike Stump wrote:
>
>> On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
>>>
>>> Now flag_check_new should probably disable this optimization…
>>
>>
>> Yes, this why my point.
>
>
> Ok, here it is (again, no proper testing un
On Sat, Sep 7, 2013 at 2:46 PM, Mike Stump wrote:
>
> On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
> wrote:
>
>> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
>>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>>
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
>
> this patch teaches
On Sat, 7 Sep 2013, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
Can this throw:
void *operator new (long unsigned int s) {
return 0;
}
? Is this allowed to return 0?
I think using this function is illegal. It isn't marked noexcept, so it isn't
allowed to return 0.
And if
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
Now flag_check_new should probably disable this optimization…
Yes, this why my point.
Ok, here it is (again, no proper testing until bootstrap is fixed)
2013-09-07 Marc Glisse
PR c++/19476
gc
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
wrote:
On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
this patch teaches the compiler that operator new, when i
On Sep 7, 2013, at 12:27 PM, Marc Glisse wrote:
> Now flag_check_new should probably disable this optimization…
Yes, this why my point.
On Sep 7, 2013, at 12:37 PM, Gabriel Dos Reis
wrote:
> On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
>> On Sat, 7 Sep 2013, Mike Stump wrote:
>>
>>> On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw,
isn't
On Sat, Sep 7, 2013 at 2:27 PM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Mike Stump wrote:
>
>> On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
>>>
>>> this patch teaches the compiler that operator new, when it can throw,
>>> isn't allowed to return a null pointer.
>>
>>
>> You sure:
>>
>> @item -
On Sat, 7 Sep 2013, Mike Stump wrote:
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw, isn't
allowed to return a null pointer.
You sure:
@item -fcheck-new
@opindex fcheck-new
Check that the pointer returned by @code{operat
On Sat, Sep 7, 2013 at 12:59 PM, Marc Glisse wrote:
>> Furthermore, I do think that the compiler should have special nodes
>> for both standard placement new and the global operator new functions,
>
>
> That's one way to do it. Since this is the first time I look at those, I
> don't really see th
On Sep 7, 2013, at 3:33 AM, Marc Glisse wrote:
> this patch teaches the compiler that operator new, when it can throw, isn't
> allowed to return a null pointer.
You sure:
@item -fcheck-new
@opindex fcheck-new
Check that the pointer returned by @code{operator new} is non-null
before attempting t
On Sat, 7 Sep 2013, Gabriel Dos Reis wrote:
On Sat, Sep 7, 2013 at 11:42 AM, Marc Glisse wrote:
On Sat, 7 Sep 2013, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw,
isn't allowed to return a null pointer. Note that it doesn't work for
placement new (th
On Sat, Sep 7, 2013 at 11:42 AM, Marc Glisse wrote:
> On Sat, 7 Sep 2013, Marc Glisse wrote:
>
>> this patch teaches the compiler that operator new, when it can throw,
>> isn't allowed to return a null pointer. Note that it doesn't work for
>> placement new (that one may have to be handled in the
On Sat, 7 Sep 2013, Marc Glisse wrote:
this patch teaches the compiler that operator new, when it can throw, isn't
allowed to return a null pointer. Note that it doesn't work for placement new
(that one may have to be handled in the front-end or the inliner),
Placement new is a completely dif
On Sat, 7 Sep 2013, Basile Starynkevitch wrote:
On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
Hello,
this patch teaches the compiler that operator new, when it can throw,
isn't allowed to return a null pointer. Note that it doesn't work for
placement new (that one may have to be handle
On Sat, Sep 7, 2013 at 6:44 AM, Basile Starynkevitch
wrote:
> On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
>> Hello,
>>
>> this patch teaches the compiler that operator new, when it can throw,
>> isn't allowed to return a null pointer. Note that it doesn't work for
>> placement new (that
On Sat, 2013-09-07 at 12:33 +0200, Marc Glisse wrote:
> Hello,
>
> this patch teaches the compiler that operator new, when it can throw,
> isn't allowed to return a null pointer. Note that it doesn't work for
> placement new (that one may have to be handled in the front-end or the
> inliner), a
38 matches
Mail list logo
