On Tue, Jun 07, 2016 at 09:51:05AM -0600, Martin Sebor wrote:
> On 06/07/2016 08:32 AM, Jason Merrill wrote:
> >On 06/06/2016 08:36 AM, Jakub Jelinek wrote:
> >>@@ -352,6 +352,35 @@ builtin_valid_in_constant_expr_p (const_
> >> case BUILT_IN_FUNCTION:
> >> case BUILT_IN_LINE:
> >>
> >>+ /* The following built-ins are valid in constant expressions
> >>+ when their arguments are. */
> >>+ case BUILT_IN_ADD_OVERFLOW:
> >>+ case BUILT_IN_ADD_OVERFLOW_P:
> >....
> >
> >Why is this necessary? builtin_valid_in_constant_expr_p is only needed
> >for builtins that can have constant values even if their operands are
> >non-constant, which doesn't apply here.
> >
> >For that matter, I don't see why we needed to add _FUNCTION et al, either.
>
> I don't remember what prompted me to change the function in either
> patch. Perhaps it was the comment above the function that says
> this:
>
> /* Test whether DECL is a builtin that may appear in a
> constant-expression. */
>
> But removing the change doesn't seem to affect the C++ test results
> for the two features so it looks like the change may not be needed.
Indeed, confirming removal of the cp/tree.c hunk doesn't affect anything in
the testsuite, nor e.g.
enum A {
B = 1,
C = 2,
D = __builtin_add_overflow_p (B, C, C)
};
int e[__builtin_add_overflow_p (B, C, C) + 1];
template <int N> int foo (int);
void
bar ()
{
foo <__builtin_add_overflow_p (B, C, C) + 1> (0);
}
That said, builtin_valid_in_constant_expr_p is used in lots of spots, and in
various of them I see that without the change it actually sets
*non_integral_constant_expression_p = true;
or something similar, but I have no idea why it still works despite of that.
Is the patch ok for trunk without the cp/tree.c hunk?
Jakub
