[c++-delayed-folding] fold_simple

[c++-delayed-folding] fold_simple

[Jason Merrill]

Why does fold_simple fold so many patterns?  I thought we wanted 
something that would just fold conversions and negations of constant values.

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
> Why does fold_simple fold so many patterns?  I thought we wanted something
> that would just fold conversions and negations of constant values.

Yes, initial variant was handling much less patterns.  But actually we
need for functions (eg. like build_vec_init in init.c) a simple
routine to perform basic constant-value arithmetics (sizeof * / + -
trunc, etc) to avoid call of maybe_constant_value.  Also for
overflow-diagnostics we want at least to resolve such simple patterns
for constant-values only.  We could change those calls to use
maybe_constant_value instead, but the overhead (and some of its
folding) leads much further then working on constant-values only (as
fold_simple does).

It might be that we can remove the ternary vector-cond expression from
this routine, The cond-expr itself seems to be necessary to resolve
patterns like (1 == 1 ? 32 : 64), which can appear pretty often via
macro-code.  I will check if I what patterns I can remove here.

> Jason


Kai

Re: [c++-delayed-folding] fold_simple

[Richard Biener]

On Thu, Aug 27, 2015 at 11:21 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> Why does fold_simple fold so many patterns?  I thought we wanted something
>> that would just fold conversions and negations of constant values.
>
> Yes, initial variant was handling much less patterns.  But actually we
> need for functions (eg. like build_vec_init in init.c) a simple
> routine to perform basic constant-value arithmetics (sizeof * / + -
> trunc, etc) to avoid call of maybe_constant_value.  Also for
> overflow-diagnostics we want at least to resolve such simple patterns
> for constant-values only.  We could change those calls to use
> maybe_constant_value instead, but the overhead (and some of its
> folding) leads much further then working on constant-values only (as
> fold_simple does).
>
> It might be that we can remove the ternary vector-cond expression from
> this routine, The cond-expr itself seems to be necessary to resolve
> patterns like (1 == 1 ? 32 : 64), which can appear pretty often via
> macro-code.  I will check if I what patterns I can remove here.

Note that fold-const.c has constant-only folding routines (handling only
constant operands).  const_unop, const_binop (no const_ternop split
out yet).

Richard.

>> Jason
>
>
> Kai

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-27 12:34 GMT+02:00 Richard Biener <richard.guenther@gmail.com>:
> On Thu, Aug 27, 2015 at 11:21 AM, Kai Tietz <ktietz70@googlemail.com> wrote:
>> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>> Why does fold_simple fold so many patterns?  I thought we wanted something
>>> that would just fold conversions and negations of constant values.
>>
>> Yes, initial variant was handling much less patterns.  But actually we
>> need for functions (eg. like build_vec_init in init.c) a simple
>> routine to perform basic constant-value arithmetics (sizeof * / + -
>> trunc, etc) to avoid call of maybe_constant_value.  Also for
>> overflow-diagnostics we want at least to resolve such simple patterns
>> for constant-values only.  We could change those calls to use
>> maybe_constant_value instead, but the overhead (and some of its
>> folding) leads much further then working on constant-values only (as
>> fold_simple does).
>>
>> It might be that we can remove the ternary vector-cond expression from
>> this routine, The cond-expr itself seems to be necessary to resolve
>> patterns like (1 == 1 ? 32 : 64), which can appear pretty often via
>> macro-code.  I will check if I what patterns I can remove here.
>
> Note that fold-const.c has constant-only folding routines (handling only
> constant operands).  const_unop, const_binop (no const_ternop split
> out yet).
>
> Richard.

Thanks for the point.  I will take a look into cons_unop/binop.  I
just expect that this routines would fail if they get c++-expressions,
aren't they?

>>> Jason

Kai

Re: [c++-delayed-folding] fold_simple

[Richard Biener]

On August 27, 2015 6:07:59 PM GMT+02:00, Kai Tietz <ktietz70@googlemail.com> wrote:
>2015-08-27 12:34 GMT+02:00 Richard Biener <richard.guenther@gmail.com>:
>> On Thu, Aug 27, 2015 at 11:21 AM, Kai Tietz <ktietz70@googlemail.com>
>wrote:
>>> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>> Why does fold_simple fold so many patterns?  I thought we wanted
>something
>>>> that would just fold conversions and negations of constant values.
>>>
>>> Yes, initial variant was handling much less patterns.  But actually
>we
>>> need for functions (eg. like build_vec_init in init.c) a simple
>>> routine to perform basic constant-value arithmetics (sizeof * / + -
>>> trunc, etc) to avoid call of maybe_constant_value.  Also for
>>> overflow-diagnostics we want at least to resolve such simple
>patterns
>>> for constant-values only.  We could change those calls to use
>>> maybe_constant_value instead, but the overhead (and some of its
>>> folding) leads much further then working on constant-values only (as
>>> fold_simple does).
>>>
>>> It might be that we can remove the ternary vector-cond expression
>from
>>> this routine, The cond-expr itself seems to be necessary to resolve
>>> patterns like (1 == 1 ? 32 : 64), which can appear pretty often via
>>> macro-code.  I will check if I what patterns I can remove here.
>>
>> Note that fold-const.c has constant-only folding routines (handling
>only
>> constant operands).  const_unop, const_binop (no const_ternop split
>> out yet).
>>
>> Richard.
>
>Thanks for the point.  I will take a look into cons_unop/binop.  I
>just expect that this routines would fail if they get c++-expressions,
>aren't they?

They fail for everything they do not handle.

Richard.

>>>> Jason
>
>Kai

Re: [c++-delayed-folding] fold_simple

[Jason Merrill]

On 08/27/2015 05:21 AM, Kai Tietz wrote:
> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> Why does fold_simple fold so many patterns?  I thought we wanted something
>> that would just fold conversions and negations of constant values.
>
> Yes, initial variant was handling much less patterns.  But actually we
> need for functions (eg. like build_vec_init in init.c) a simple
> routine to perform basic constant-value arithmetics (sizeof * / + -
> trunc, etc) to avoid call of maybe_constant_value.  Also for
> overflow-diagnostics we want at least to resolve such simple patterns
> for constant-values only.  We could change those calls to use
> maybe_constant_value instead, but the overhead (and some of its
> folding) leads much further then working on constant-values only (as
> fold_simple does).

For build_vec_init, since whether maxindex is constant has semantic 
meaning, I think we want maybe_constant_value.

I think we also want it for overflow warnings, to get better diagnostics.

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-29 6:45 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/27/2015 05:21 AM, Kai Tietz wrote:
>>
>> 2015-08-27 4:57 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> Why does fold_simple fold so many patterns?  I thought we wanted
>>> something
>>> that would just fold conversions and negations of constant values.
>>
>>
>> Yes, initial variant was handling much less patterns.  But actually we
>> need for functions (eg. like build_vec_init in init.c) a simple
>> routine to perform basic constant-value arithmetics (sizeof * / + -
>> trunc, etc) to avoid call of maybe_constant_value.  Also for
>> overflow-diagnostics we want at least to resolve such simple patterns
>> for constant-values only.  We could change those calls to use
>> maybe_constant_value instead, but the overhead (and some of its
>> folding) leads much further then working on constant-values only (as
>> fold_simple does).
>
>
> For build_vec_init, since whether maxindex is constant has semantic meaning,
> I think we want maybe_constant_value.

So you mean that handling of constexprs within vector-init is
something we need.  Ok. I will test a replace.

> I think we also want it for overflow warnings, to get better diagnostics.

Hmm, I don't think we want to call maybe_constant_value in functions
like cp_build_binary_op. We are interested in overflow only on
constant-values anyway, I don't see that we want to have here any
constexpr-logic, nor specific address-manipulation logic.  So I see
here not much advantage in using maybe_constant_value.  Maybe I simply
not seeing the obvious here.  Do you have a specific testcase, which
shows what diagnostics could be missed?

> Jason
>

Kai

Re: [c++-delayed-folding] fold_simple

[Jason Merrill]

On 08/29/2015 10:10 AM, Kai Tietz wrote:
> Hmm, I don't think we want to call maybe_constant_value in functions
> like cp_build_binary_op. We are interested in overflow only on
> constant-values anyway, I don't see that we want to have here any
> constexpr-logic, nor specific address-manipulation logic.  So I see
> here not much advantage in using maybe_constant_value.  Maybe I simply
> not seeing the obvious here.  Do you have a specific testcase, which
> shows what diagnostics could be missed?

#include <limits.h>
constexpr int f() { return INT_MAX; }
int main()
{
   return f()+2; // { dg-warning "overflow" }
}

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-31 19:52 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/29/2015 10:10 AM, Kai Tietz wrote:
>>
>> Hmm, I don't think we want to call maybe_constant_value in functions
>> like cp_build_binary_op. We are interested in overflow only on
>> constant-values anyway, I don't see that we want to have here any
>> constexpr-logic, nor specific address-manipulation logic.  So I see
>> here not much advantage in using maybe_constant_value.  Maybe I simply
>> not seeing the obvious here.  Do you have a specific testcase, which
>> shows what diagnostics could be missed?
>
>
> #include <limits.h>
> constexpr int f() { return INT_MAX; }
> int main()
> {
>   return f()+2; // { dg-warning "overflow" }
> }
>
> Jason
>

Ok.  Following patch should allow this missed diagnostics

I will need to verify that this patch doesn't introduce regressions.
The wacky thing here is the encapsulation of overflowed-arguments in
maybe_constant_value function by nop-expr.

Kai

Index: typeck.c
===================================================================
--- typeck.c    (Revision 227339)
+++ typeck.c    (Arbeitskopie)
@@ -5070,8 +5070,12 @@ cp_build_binary_op (location_t location,
   result = build2 (resultcode, build_type, op0, op1);
   if (final_type != 0)
     result = cp_convert (final_type, result, complain);
-  op0 = fold_simple (op0);
-  op1 = fold_simple (op1);
+  op0 = maybe_constant_value (op0);
+  op1 = maybe_constant_value (op1);
+  /* Strip added nop-expression for overflow-operand introduced by
+     maybe_constant_value.  */
+  STRIP_NOPS (op0);
+  STRIP_NOPS (op1);
   result_ovl = fold_build2 (resultcode, build_type, op0, op1);
   if (TREE_OVERFLOW_P (result_ovl)
       && !TREE_OVERFLOW_P (op0)

Re: [c++-delayed-folding] fold_simple

[Jason Merrill]

On 08/31/2015 03:08 PM, Kai Tietz wrote:
> I will need to verify that this patch doesn't introduce regressions.
> The wacky thing here is the encapsulation of overflowed-arguments in
> maybe_constant_value function by nop-expr.

Do we need to worry about that?  If one of the operands is overflowed, 
we don't care whether the result is overflowed.

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>
>> I will need to verify that this patch doesn't introduce regressions.
>> The wacky thing here is the encapsulation of overflowed-arguments in
>> maybe_constant_value function by nop-expr.
>
>
> Do we need to worry about that?  If one of the operands is overflowed, we
> don't care whether the result is overflowed.

Well, we would introduce, if we don't see in condition that operand
already overflowed, double overflow-warning, which seems to be
something we avoided until now.  So I would say, it matters.

Kai

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-31 21:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>
>>> I will need to verify that this patch doesn't introduce regressions.
>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>> maybe_constant_value function by nop-expr.
>>
>>
>> Do we need to worry about that?  If one of the operands is overflowed, we
>> don't care whether the result is overflowed.
>
> Well, we would introduce, if we don't see in condition that operand
> already overflowed, double overflow-warning, which seems to be
> something we avoided until now.  So I would say, it matters.
>
> Kai

Similar to the binary-operation we want to do then the same for
unary-operations, too.

Eg. testcase:

#include <limits.h>

constexpr int f() { return INT_MIN; }

int main()
{
  return -f(); // { dg-warning "overflow" }
}
With following patch we do diagnostics for it.

Kai

Index: semantics.c
===================================================================
--- semantics.c (Revision 227339)
+++ semantics.c (Arbeitskopie)
@@ -2553,9 +2553,11 @@ finish_unary_op_expr (location_t loc, enum tree_co
   tree result = build_x_unary_op (loc, code, expr, complain);
   tree result_ovl =  result;

-  expr_ovl = fold_simple (expr_ovl);
-  result_ovl = fold_simple (result);
-
+  expr_ovl = maybe_constant_value (expr_ovl);
+  result_ovl = maybe_constant_value (result);
+  /* Strip nop-expressions added by maybe_constant_value on overflow.  */
+  STRIP_NOPS (expr_ovl);
+  STRIP_NOPS (result_ovl);
   if ((complain & tf_warning)
       && TREE_OVERFLOW_P (result_ovl) && !TREE_OVERFLOW_P (expr_ovl))
     overflow_warning (input_location, result_ovl);

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-08-31 22:19 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
> 2015-08-31 21:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>>
>>>> I will need to verify that this patch doesn't introduce regressions.
>>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>>> maybe_constant_value function by nop-expr.
>>>
>>>
>>> Do we need to worry about that?  If one of the operands is overflowed, we
>>> don't care whether the result is overflowed.
>>
>> Well, we would introduce, if we don't see in condition that operand
>> already overflowed, double overflow-warning, which seems to be
>> something we avoided until now.  So I would say, it matters.
>>
>> Kai
>
> Similar to the binary-operation we want to do then the same for
> unary-operations, too.
>
> Eg. testcase:
>
> #include <limits.h>
>
> constexpr int f() { return INT_MIN; }
>
> int main()
> {
>   return -f(); // { dg-warning "overflow" }
> }
> With following patch we do diagnostics for it.
>
> Kai
>
> Index: semantics.c
> ===================================================================
> --- semantics.c (Revision 227339)
> +++ semantics.c (Arbeitskopie)
> @@ -2553,9 +2553,11 @@ finish_unary_op_expr (location_t loc, enum tree_co
>    tree result = build_x_unary_op (loc, code, expr, complain);
>    tree result_ovl =  result;
>
> -  expr_ovl = fold_simple (expr_ovl);
> -  result_ovl = fold_simple (result);
> -
> +  expr_ovl = maybe_constant_value (expr_ovl);
> +  result_ovl = maybe_constant_value (result);
> +  /* Strip nop-expressions added by maybe_constant_value on overflow.  */
> +  STRIP_NOPS (expr_ovl);
> +  STRIP_NOPS (result_ovl);
>    if ((complain & tf_warning)
>        && TREE_OVERFLOW_P (result_ovl) && !TREE_OVERFLOW_P (expr_ovl))
>      overflow_warning (input_location, result_ovl);

I committed patches for binary & unary operations together with
testcases.  Regression-run still running.  There seems to be
additional expressions needed in constexpr for this.  For now we have
a bootstrap-issue due cast_expr in cxx_eval_constant_expression.
There might be more of them ...

Kai

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-09-01 10:15 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
> 2015-08-31 22:19 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>> 2015-08-31 21:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>>>
>>>>> I will need to verify that this patch doesn't introduce regressions.
>>>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>>>> maybe_constant_value function by nop-expr.
>>>>
>>>>
>>>> Do we need to worry about that?  If one of the operands is overflowed, we
>>>> don't care whether the result is overflowed.
>>>
>>> Well, we would introduce, if we don't see in condition that operand
>>> already overflowed, double overflow-warning, which seems to be
>>> something we avoided until now.  So I would say, it matters.
>>>
>>> Kai
>>
>> Similar to the binary-operation we want to do then the same for
>> unary-operations, too.
>>
>> Eg. testcase:
>>
>> #include <limits.h>
>>
>> constexpr int f() { return INT_MIN; }
>>
>> int main()
>> {
>>   return -f(); // { dg-warning "overflow" }
>> }
>> With following patch we do diagnostics for it.
>>
>> Kai
>>
>> Index: semantics.c
>> ===================================================================
>> --- semantics.c (Revision 227339)
>> +++ semantics.c (Arbeitskopie)
>> @@ -2553,9 +2553,11 @@ finish_unary_op_expr (location_t loc, enum tree_co
>>    tree result = build_x_unary_op (loc, code, expr, complain);
>>    tree result_ovl =  result;
>>
>> -  expr_ovl = fold_simple (expr_ovl);
>> -  result_ovl = fold_simple (result);
>> -
>> +  expr_ovl = maybe_constant_value (expr_ovl);
>> +  result_ovl = maybe_constant_value (result);
>> +  /* Strip nop-expressions added by maybe_constant_value on overflow.  */
>> +  STRIP_NOPS (expr_ovl);
>> +  STRIP_NOPS (result_ovl);
>>    if ((complain & tf_warning)
>>        && TREE_OVERFLOW_P (result_ovl) && !TREE_OVERFLOW_P (expr_ovl))
>>      overflow_warning (input_location, result_ovl);
>
> I committed patches for binary & unary operations together with
> testcases.  Regression-run still running.  There seems to be
> additional expressions needed in constexpr for this.  For now we have
> a bootstrap-issue due cast_expr in cxx_eval_constant_expression.
> There might be more of them ...

I had to add for now that cxx_eval_constant_expr ignores on CAST_EXPR,
STATIC_CAST_EXPR, OVERLOAD, and TREE_LIST.  Additionally we need to
handle for increments that offset is NULL_TREE (TREE_OPERAND (,1)) .

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-09-01 10:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
> 2015-09-01 10:15 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>> 2015-08-31 22:19 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>> 2015-08-31 21:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>>> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>>>>
>>>>>> I will need to verify that this patch doesn't introduce regressions.
>>>>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>>>>> maybe_constant_value function by nop-expr.
>>>>>
>>>>>
>>>>> Do we need to worry about that?  If one of the operands is overflowed, we
>>>>> don't care whether the result is overflowed.
>>>>
>>>> Well, we would introduce, if we don't see in condition that operand
>>>> already overflowed, double overflow-warning, which seems to be
>>>> something we avoided until now.  So I would say, it matters.
>>>>
>>>> Kai
>>>
>>> Similar to the binary-operation we want to do then the same for
>>> unary-operations, too.
>>>
>>> Eg. testcase:
>>>
>>> #include <limits.h>
>>>
>>> constexpr int f() { return INT_MIN; }
>>>
>>> int main()
>>> {
>>>   return -f(); // { dg-warning "overflow" }
>>> }
>>> With following patch we do diagnostics for it.
>>>
>>> Kai
>>>
>>> Index: semantics.c
>>> ===================================================================
>>> --- semantics.c (Revision 227339)
>>> +++ semantics.c (Arbeitskopie)
>>> @@ -2553,9 +2553,11 @@ finish_unary_op_expr (location_t loc, enum tree_co
>>>    tree result = build_x_unary_op (loc, code, expr, complain);
>>>    tree result_ovl =  result;
>>>
>>> -  expr_ovl = fold_simple (expr_ovl);
>>> -  result_ovl = fold_simple (result);
>>> -
>>> +  expr_ovl = maybe_constant_value (expr_ovl);
>>> +  result_ovl = maybe_constant_value (result);
>>> +  /* Strip nop-expressions added by maybe_constant_value on overflow.  */
>>> +  STRIP_NOPS (expr_ovl);
>>> +  STRIP_NOPS (result_ovl);
>>>    if ((complain & tf_warning)
>>>        && TREE_OVERFLOW_P (result_ovl) && !TREE_OVERFLOW_P (expr_ovl))
>>>      overflow_warning (input_location, result_ovl);
>>
>> I committed patches for binary & unary operations together with
>> testcases.  Regression-run still running.  There seems to be
>> additional expressions needed in constexpr for this.  For now we have
>> a bootstrap-issue due cast_expr in cxx_eval_constant_expression.
>> There might be more of them ...
>
> I had to add for now that cxx_eval_constant_expr ignores on CAST_EXPR,
> STATIC_CAST_EXPR, OVERLOAD, and TREE_LIST.  Additionally we need to
> handle for increments that offset is NULL_TREE (TREE_OPERAND (,1)) .

Issue was easier to resolve by checking in binary/unary
overflow-checking-functions that we aren't processing template
declarations.  If we aren't within template-declaration processing we
can call maybe_constant_value.  This avoids that we feed
maybe_constant_value with mentioned C++-template specific expressions.

Bootstrap ran successful, regression-testing still running for it.  I
committed additional check already to branch.

Kai

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-09-01 13:17 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
> 2015-09-01 10:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>> 2015-09-01 10:15 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>> 2015-08-31 22:19 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>>> 2015-08-31 21:43 GMT+02:00 Kai Tietz <ktietz70@googlemail.com>:
>>>>> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>>>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>>>>>
>>>>>>> I will need to verify that this patch doesn't introduce regressions.
>>>>>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>>>>>> maybe_constant_value function by nop-expr.
>>>>>>
>>>>>>
>>>>>> Do we need to worry about that?  If one of the operands is overflowed, we
>>>>>> don't care whether the result is overflowed.
>>>>>
>>>>> Well, we would introduce, if we don't see in condition that operand
>>>>> already overflowed, double overflow-warning, which seems to be
>>>>> something we avoided until now.  So I would say, it matters.
>>>>>
>>>>> Kai
>>>>
>>>> Similar to the binary-operation we want to do then the same for
>>>> unary-operations, too.
>>>>
>>>> Eg. testcase:
>>>>
>>>> #include <limits.h>
>>>>
>>>> constexpr int f() { return INT_MIN; }
>>>>
>>>> int main()
>>>> {
>>>>   return -f(); // { dg-warning "overflow" }
>>>> }
>>>> With following patch we do diagnostics for it.
>>>>
>>>> Kai
>>>>
>>>> Index: semantics.c
>>>> ===================================================================
>>>> --- semantics.c (Revision 227339)
>>>> +++ semantics.c (Arbeitskopie)
>>>> @@ -2553,9 +2553,11 @@ finish_unary_op_expr (location_t loc, enum tree_co
>>>>    tree result = build_x_unary_op (loc, code, expr, complain);
>>>>    tree result_ovl =  result;
>>>>
>>>> -  expr_ovl = fold_simple (expr_ovl);
>>>> -  result_ovl = fold_simple (result);
>>>> -
>>>> +  expr_ovl = maybe_constant_value (expr_ovl);
>>>> +  result_ovl = maybe_constant_value (result);
>>>> +  /* Strip nop-expressions added by maybe_constant_value on overflow.  */
>>>> +  STRIP_NOPS (expr_ovl);
>>>> +  STRIP_NOPS (result_ovl);
>>>>    if ((complain & tf_warning)
>>>>        && TREE_OVERFLOW_P (result_ovl) && !TREE_OVERFLOW_P (expr_ovl))
>>>>      overflow_warning (input_location, result_ovl);
>>>
>>> I committed patches for binary & unary operations together with
>>> testcases.  Regression-run still running.  There seems to be
>>> additional expressions needed in constexpr for this.  For now we have
>>> a bootstrap-issue due cast_expr in cxx_eval_constant_expression.
>>> There might be more of them ...
>>
>> I had to add for now that cxx_eval_constant_expr ignores on CAST_EXPR,
>> STATIC_CAST_EXPR, OVERLOAD, and TREE_LIST.  Additionally we need to
>> handle for increments that offset is NULL_TREE (TREE_OPERAND (,1)) .
>
> Issue was easier to resolve by checking in binary/unary
> overflow-checking-functions that we aren't processing template
> declarations.  If we aren't within template-declaration processing we
> can call maybe_constant_value.  This avoids that we feed
> maybe_constant_value with mentioned C++-template specific expressions.
>
> Bootstrap ran successful, regression-testing still running for it.  I
> committed additional check already to branch.

All tests passed as expected.

Kai

Re: [c++-delayed-folding] fold_simple

[Jason Merrill]

On 08/31/2015 03:43 PM, Kai Tietz wrote:
> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>
>>> I will need to verify that this patch doesn't introduce regressions.
>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>> maybe_constant_value function by nop-expr.
>>
>>
>> Do we need to worry about that?  If one of the operands is overflowed, we
>> don't care whether the result is overflowed.
>
> Well, we would introduce, if we don't see in condition that operand
> already overflowed, double overflow-warning, which seems to be
> something we avoided until now.  So I would say, it matters.

I would rather handle this by checking whether the folded operands are 
constant before even building the folded result.

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-09-01 16:47 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 08/31/2015 03:43 PM, Kai Tietz wrote:
>>
>> 2015-08-31 21:29 GMT+02:00 Jason Merrill <jason@redhat.com>:
>>>
>>> On 08/31/2015 03:08 PM, Kai Tietz wrote:
>>>>
>>>>
>>>> I will need to verify that this patch doesn't introduce regressions.
>>>> The wacky thing here is the encapsulation of overflowed-arguments in
>>>> maybe_constant_value function by nop-expr.
>>>
>>>
>>>
>>> Do we need to worry about that?  If one of the operands is overflowed, we
>>> don't care whether the result is overflowed.
>>
>>
>> Well, we would introduce, if we don't see in condition that operand
>> already overflowed, double overflow-warning, which seems to be
>> something we avoided until now.  So I would say, it matters.
>
>
> I would rather handle this by checking whether the folded operands are
> constant before even building the folded result.

I rewrote binary/unary overflow-check logic so, that we avoid double
checking-s.  I think this address things as you intend, beside the
checking for constant value.  We would need to check for *_CST
tree-codes.  Is there a macro we could use, which is just checking for
those?

> Jason
>

Kai

Re: [c++-delayed-folding] fold_simple

[Jason Merrill]

On 09/01/2015 11:27 AM, Kai Tietz wrote:
> I rewrote binary/unary overflow-check logic so, that we avoid double
> checking-s.  I think this address things as you intend, beside the
> checking for constant value.  We would need to check for *_CST
> tree-codes.  Is there a macro we could use, which is just checking for
> those?

Yes, CONSTANT_CLASS_P.

Jason

Re: [c++-delayed-folding] fold_simple

[Kai Tietz]

2015-09-01 17:31 GMT+02:00 Jason Merrill <jason@redhat.com>:
> On 09/01/2015 11:27 AM, Kai Tietz wrote:
>>
>> I rewrote binary/unary overflow-check logic so, that we avoid double
>> checking-s.  I think this address things as you intend, beside the
>> checking for constant value.  We would need to check for *_CST
>> tree-codes.  Is there a macro we could use, which is just checking for
>> those?
>
>
> Yes, CONSTANT_CLASS_P.
>
> Jason


Thanks, I found it too :]  I applied a patch short-cutting check for
cases that operands aren't of constant-class.

Kai