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

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Apr 10, 2013 at 12:50 PM, James Greenhalgh
<james.greenhalgh@arm.com> wrote:
>
>> -----Original Message-----
>> From: dosreis@gmail.com [mailto:dosreis@gmail.com] On Behalf Of Gabriel
>> Dos Reis
>> Sent: 20 March 2013 19:09
>> To: James Greenhalgh
>> Cc: Jakub Jelinek; Richard Biener; gcc-patches@gcc.gnu.org; Jason
>> Merrill; mark@codesourcery.com
>> Subject: Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to
>> potential_constant_expression_1.
>>
>> 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.
>
> So, as far as I can see no decision came out of this thread as to
> what should be done. In that time I had to add another few tree cases
> as I added more things to TARGET_FOLD_BUILTIN.
>
> I'd like to start pushing some of these TARGET_FOLD_BUILTIN patches
> upstream, but they currently all hinge on resolving this discussion.

I still think getting rid of TARGET_FOLD_BUILTIN and replacing it with
TARGET_FOLD_STMT that only operates on GIMPLE is the way to go.

One of the issues we hit is that it's not well-defined what tree codes are
supposed to be part of GENERIC and which only part of GIMPLE
(in case we want to support GENERIC tree codes not being a superset
of GIMPLE tree codes at all).  If they are part of GENERIC then the
C++ frontend needs to handle them as folding can introduce all
GENERIC tree codes.

Richard.

> Would it be OK for this patch to go in, I know the thread started
> well for me with:
>
>> -----Original Message-----
>> From: Jason Merrill [mailto:jason@redhat.com]
>> Sent: 14 March 2013 18:52
>> To: James Greenhalgh; gcc-patches@gcc.gnu.org
>> Cc: mark@codesourcery.com
>> Subject: Re: [C++11][4.9] Add missing REDUC_PLUS_EXPR case to
>> potential_constant_expression_1.
>>
>> On 03/14/2013 09:48 AM, James Greenhalgh wrote:
>> > Is this OK to commit to 4.9 when stage 1 opens up?
>>
>> Yes, but please add the other new tree codes as well.
>>
>> Jason
>
> But quickly moved on to discussion, so I didn't commit the patch.
>
> Thanks,
> James Greenhalgh
> Graduate Engineer
> ARM
>
> ---
> gcc/
>
> 2013-04-09  James Greenhalgh  <james.greenhalgh@arm.com>
>
>         * cp/semantics.c
>         (potential_constant_expression_1): Add cases for REDUC_PLUS_EXPR,
>         REDUC_MIN_EXPR, REDUC_MAX_EXPR.