This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to potential_constant_expression_1.
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, 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 14:08:40 -0500
- 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> <5149fa17 dot 064d340a dot 7a66 dot 13adSMTPIN_ADDED_BROKEN at mx dot google dot com>
On Wed, Mar 20, 2013 at 1:03 PM, James Greenhalgh
<james.greenhalgh@arm.com> wrote:
> Is that be sensible? It certainly seems like someone intended to
> explicitly enumerate all the possible cases and ensure that they were
> correctly handled.
That someone would be me.
We need to catch loudly any front-end tree code, e.g. ASTs, object
we may have missed, as opposed to silently ignoring them with
possible miscompilation and pray that someone might be sufficiently
pissed off and report it as a bug.
What is wrong isn't that the front-end inserts internal coverage
check; rather it is the fact that we don't have enough separation
between front-end asts and middle-end stuff.
The convenience of adding a middle-end optimization (which this
essentially is) should not trump correctness of the implementation
of standard semantics.
-- Gaby