2015-08-31 19:52 GMT+02:00 Jason Merrill <ja...@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)
