This is the mail archive of the
mailing list for the GCC project.
RE: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
- From: "James Greenhalgh" <james dot greenhalgh at arm dot com>
- To: "'Jakub Jelinek'" <jakub at redhat dot com>, "Gabriel Dos Reis" <gdr at integrable-solutions dot net>
- Cc: "Richard Biener" <richard dot guenther at gmail dot com>, <gcc-patches at gcc dot gnu dot org>, "Jason Merrill" <jason at redhat dot com>, <mark at codesourcery dot com>
- Date: Wed, 20 Mar 2013 18:03:49 -0000
- Subject: RE: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
- References: <1363268930-22910-1-git-send-email-james dot greenhalgh at arm dot com> <51421C32 dot 2060204 at redhat dot com> <20130314185528 dot GH12913 at tucnak dot redhat dot com> <alpine dot DEB dot 2 dot 02 dot 1303142159180 dot 7704 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc3S-JGE1xN6K8yDMGrteEJU++7M+5A9iRxmZ-adv1-iDQ at mail dot gmail dot com> <CAAiZkiAJPRqxvkizdF847c7YJRSobkiQt4Y7wVSUVzPLuWtbHA at mail dot gmail dot com> <20130315130534 dot GL12913 at tucnak dot redhat dot com>
> From: Jakub Jelinek [mailto:email@example.com]
> Sent: 15 March 2013 13:06
> 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
> > <firstname.lastname@example.org> wrote:
> > > On Thu, Mar 14, 2013 at 10:08 PM, Marc Glisse
> <email@example.com> 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
> > >>> isn't
> > >>> IMHO desirable.
> > >>
> > >>
> > >> Wouldn't that prevent from using those builtins in constant
> > >> That seems undesirable. Maybe an alternative could be to push some
> of the
> > >> functionality from potential_constant_expression_1 to the middle-
> > >
> > > 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
> > 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
> fine. If all arguments to the target builtin aren't constant, then it
> be a constant expression anyway, there is no point in showing all those
> weird tree codes to the FE.
So based on this argument, while a front-end may not need to implement
all the weird tree codes it should at least have a sensible default
case for an tree code which it doesn't understand.
That would suggest the correct fix would be to change
potential_constant_expression_1 to simply return false if it encounters
a tree it doesn't know about, rather than the current gcc_unreachable ().
The argument would be; if we found an unexpected tree code then
it must have been introduced by folding. If it was a constant,
folding would have returned the constant not the expression. So it must
not be a constant.
Is that be sensible? It certainly seems like someone intended to
explicitly enumerate all the possible cases and ensure that they were
I have some other patches kicking around which will fold to REDUC_MAX_EXPR,
which will be another unhandled tree code. The approach of adding a case
in potential_constant_expression_1 each time a shiny new tree code appears
just feels wrong.