Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Mar 15, 2013 at 08:00:50AM -0500, Gabriel Dos Reis wrote:
> On Fri, Mar 15, 2013 at 3:51 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> >> On Thu, 14 Mar 2013, Jakub Jelinek wrote:
> >>
> >>> I wonder if it wouldn't be better to fold the target builtins only later
> >>> on
> >>> (e.g. guard the folding with cfun && gimple_in_ssa_p (cfun) (or if we have
> >>> any predicate that is set starting with gimplification or so)).
> >>> Having all the FEs have to deal with myriads of weird tree codes etc.
> >>> isn't
> >>> IMHO desirable.
> >>
> >>
> >> Wouldn't that prevent from using those builtins in constant expressions?
> >> That seems undesirable. Maybe an alternative could be to push some of the
> >> functionality from potential_constant_expression_1 to the middle-end?
> >
> > True, but is that bad?
> >
> > If we want to delay such folding then please don't do it with a magic flag
> > but instead do the folding only via fold_stmt - that is, add a new target hook
> > that folds a gimple call.  I bet we have only a very limited set of target call
> > foldings, so transitioning them all to fold gimple calls would be easy.
> 
> upon reflection, I think we don't want to delay.  the C++ front-end
> needs to know (while type checking) whether a certain operation
> can be evaluated at compile time and possibly get the value of the
> operation.

If all arguments to the target builtin constant, then it better not be
folded into REDUC_PLUS_EXPR, but instead just some constant.  That is just
fine.  If all arguments to the target builtin aren't constant, then it won't
be a constant expression anyway, there is no point in showing all those
weird tree codes to the FE.

	Jakub