* [c++-delayed-folding] fold_simple @ 2015-08-27 3:26 Jason Merrill 2015-08-27 9:22 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-08-27 3:26 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List Why does fold_simple fold so many patterns? I thought we wanted something that would just fold conversions and negations of constant values. Jason ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-27 3:26 [c++-delayed-folding] fold_simple Jason Merrill @ 2015-08-27 9:22 ` Kai Tietz 2015-08-27 10:39 ` Richard Biener 2015-08-29 5:18 ` Jason Merrill 0 siblings, 2 replies; 20+ messages in thread From: Kai Tietz @ 2015-08-27 9:22 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-27 9:22 ` Kai Tietz @ 2015-08-27 10:39 ` Richard Biener 2015-08-27 16:15 ` Kai Tietz 2015-08-29 5:18 ` Jason Merrill 1 sibling, 1 reply; 20+ messages in thread From: Richard Biener @ 2015-08-27 10:39 UTC (permalink / raw) To: Kai Tietz; +Cc: Jason Merrill, gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-27 10:39 ` Richard Biener @ 2015-08-27 16:15 ` Kai Tietz 2015-08-27 18:04 ` Richard Biener 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-08-27 16:15 UTC (permalink / raw) To: Richard Biener; +Cc: Jason Merrill, gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-27 16:15 ` Kai Tietz @ 2015-08-27 18:04 ` Richard Biener 0 siblings, 0 replies; 20+ messages in thread From: Richard Biener @ 2015-08-27 18:04 UTC (permalink / raw) To: Kai Tietz; +Cc: Jason Merrill, gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-27 9:22 ` Kai Tietz 2015-08-27 10:39 ` Richard Biener @ 2015-08-29 5:18 ` Jason Merrill 2015-08-29 14:20 ` Kai Tietz 1 sibling, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-08-29 5:18 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-29 5:18 ` Jason Merrill @ 2015-08-29 14:20 ` Kai Tietz 2015-08-31 17:57 ` Jason Merrill 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-08-29 14:20 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-29 14:20 ` Kai Tietz @ 2015-08-31 17:57 ` Jason Merrill 2015-08-31 19:29 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-08-31 17:57 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 17:57 ` Jason Merrill @ 2015-08-31 19:29 ` Kai Tietz 2015-08-31 19:43 ` Jason Merrill 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-08-31 19:29 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 19:29 ` Kai Tietz @ 2015-08-31 19:43 ` Jason Merrill 2015-08-31 19:58 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-08-31 19:43 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 19:43 ` Jason Merrill @ 2015-08-31 19:58 ` Kai Tietz 2015-08-31 20:29 ` Kai Tietz 2015-09-01 14:47 ` Jason Merrill 0 siblings, 2 replies; 20+ messages in thread From: Kai Tietz @ 2015-08-31 19:58 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 19:58 ` Kai Tietz @ 2015-08-31 20:29 ` Kai Tietz 2015-09-01 8:15 ` Kai Tietz 2015-09-01 14:47 ` Jason Merrill 1 sibling, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-08-31 20:29 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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); ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 20:29 ` Kai Tietz @ 2015-09-01 8:15 ` Kai Tietz 2015-09-01 8:43 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-09-01 8:15 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 8:15 ` Kai Tietz @ 2015-09-01 8:43 ` Kai Tietz 2015-09-01 11:17 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-09-01 8:43 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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)) . ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 8:43 ` Kai Tietz @ 2015-09-01 11:17 ` Kai Tietz 2015-09-01 13:40 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-09-01 11:17 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 11:17 ` Kai Tietz @ 2015-09-01 13:40 ` Kai Tietz 0 siblings, 0 replies; 20+ messages in thread From: Kai Tietz @ 2015-09-01 13:40 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-08-31 19:58 ` Kai Tietz 2015-08-31 20:29 ` Kai Tietz @ 2015-09-01 14:47 ` Jason Merrill 2015-09-01 15:27 ` Kai Tietz 1 sibling, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-09-01 14:47 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 14:47 ` Jason Merrill @ 2015-09-01 15:27 ` Kai Tietz 2015-09-01 15:31 ` Jason Merrill 0 siblings, 1 reply; 20+ messages in thread From: Kai Tietz @ 2015-09-01 15:27 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 15:27 ` Kai Tietz @ 2015-09-01 15:31 ` Jason Merrill 2015-09-01 15:34 ` Kai Tietz 0 siblings, 1 reply; 20+ messages in thread From: Jason Merrill @ 2015-09-01 15:31 UTC (permalink / raw) To: Kai Tietz; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [c++-delayed-folding] fold_simple 2015-09-01 15:31 ` Jason Merrill @ 2015-09-01 15:34 ` Kai Tietz 0 siblings, 0 replies; 20+ messages in thread From: Kai Tietz @ 2015-09-01 15:34 UTC (permalink / raw) To: Jason Merrill; +Cc: gcc-patches List 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-09-01 15:34 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-27 3:26 [c++-delayed-folding] fold_simple Jason Merrill 2015-08-27 9:22 ` Kai Tietz 2015-08-27 10:39 ` Richard Biener 2015-08-27 16:15 ` Kai Tietz 2015-08-27 18:04 ` Richard Biener 2015-08-29 5:18 ` Jason Merrill 2015-08-29 14:20 ` Kai Tietz 2015-08-31 17:57 ` Jason Merrill 2015-08-31 19:29 ` Kai Tietz 2015-08-31 19:43 ` Jason Merrill 2015-08-31 19:58 ` Kai Tietz 2015-08-31 20:29 ` Kai Tietz 2015-09-01 8:15 ` Kai Tietz 2015-09-01 8:43 ` Kai Tietz 2015-09-01 11:17 ` Kai Tietz 2015-09-01 13:40 ` Kai Tietz 2015-09-01 14:47 ` Jason Merrill 2015-09-01 15:27 ` Kai Tietz 2015-09-01 15:31 ` Jason Merrill 2015-09-01 15:34 ` Kai Tietz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).