From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85557 invoked by alias); 19 Sep 2016 18:34:42 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 85541 invoked by uid 89); 19 Sep 2016 18:34:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=MODIFY_EXPR, COND_EXPR, cond_expr, modify_expr X-HELO: mail-oi0-f42.google.com Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Sep 2016 18:34:40 +0000 Received: by mail-oi0-f42.google.com with SMTP id t83so79314975oie.3 for ; Mon, 19 Sep 2016 11:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cvYXnZc78CBAvFCpBQyzfVS9H01YjxudT7PTrLN7L10=; b=OkpMDjxZfKq2woxZIyRhsdjkKBIqJ66VKDdx1K1rbmYhVO5mbAtE/dRJH32td/L9IO ypq69Awusamff5qCw/jCNn/UxNQ096heAriMcZOvrNJSeVKhWMkbWp929GpoF81Ld3Jf +kBMQ2HQj0tVnNRf9NIaM9qmQpp+qDN0CQvEZ7YEu8TbtLnbCGW9Vu/PzPu409mhKAOJ xir4rNi6M51HLbufRzy3aqmsVDvErhQLIQc4tbQ1kUlpFnMcFHiHqzLf0E2qwcM7epMZ iv3LFaVOZa+C/67TxQFyP/aoDpFL01WkRdJ0jbCl4iAcnaRgq7bSHPyiVKG458ox82Te F6cA== X-Gm-Message-State: AE9vXwNqi+pol0izDGtpVj13m4pQp5I506OoXuWEPGu5f4VO7J4vFxg7w+4dDUGYiTRTqHlIxPJR5EIEfabPoDwj X-Received: by 10.202.73.133 with SMTP id w127mr31026276oia.24.1474310078553; Mon, 19 Sep 2016 11:34:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.105.169 with HTTP; Mon, 19 Sep 2016 11:34:17 -0700 (PDT) In-Reply-To: <20160916204408.GM7282@tucnak.redhat.com> References: <20160905171119.GU14857@tucnak.redhat.com> <20160916204408.GM7282@tucnak.redhat.com> From: Jason Merrill Date: Mon, 19 Sep 2016 18:49:00 -0000 Message-ID: Subject: Re: [C++ PATCH] Fix constexpr switch handling (PR c++/77467) To: Jakub Jelinek Cc: gcc-patches List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg01207.txt.bz2 On Fri, Sep 16, 2016 at 4:44 PM, Jakub Jelinek wrote: > On Fri, Sep 16, 2016 at 03:51:11PM -0400, Jason Merrill wrote: >> On Mon, Sep 5, 2016 at 1:11 PM, Jakub Jelinek wrote: >> > + /* If body is a statement other than STATEMENT_LIST or BIND_EXPR, >> > + it should be skipped. E.g. switch (a) b = a; */ >> > + if (TREE_CODE (body) == STATEMENT_LIST >> > + || TREE_CODE (body) == BIND_EXPR) >> >> I'm nervous about this optimization for useless code breaking other >> things that might (one day) wrap a case label; I think I'd prefer to >> drop the condition. > > By droping the condition you mean unconditionally call > cxx_eval_constant_expression (ctx, body, false, > non_constant_p, overflow_p, jump_target); > ? That is known not to work, that breaks the > +constexpr int > +bar (int x) > +{ > + int a = x; > + switch (x) > + a = x + 1; > + return a; > +} > handling in the testcase, where body is the MODIFY_EXPR which doesn't have > the label and thus needs to be skipped. The problem is that all the logic for > skipping statements until the label is found is in cxx_eval_statement_list > only. Ah, right. > For STATEMENT_LIST that is called by cxx_eval_constant_expression, > for BIND_EXPR if we are lucky enough that BIND_EXPR_BODY is a STATEMENT_LIST > too (otherwise I assume even my patch doesn't fix it, it would need to > verify that). If body is some other statement, then it really should be > skipped, but it isn't, because cxx_eval_constant_expression ignores it. > I wonder if we e.g. cxx_eval_constant_expression couldn't early in the > function for if (*jump_target) return immediately unless code is something > like STATEMENT_LIST or BIND_EXPR with BIND_EXPR_BODY being STATEMENT_LIST, > or perhaps in the future other construct containing other stmts. We might assert !jump_target before the call to cxx_eval_store_expression, to make sure we don't accidentally evaluate one when we're trying to jump. > I've beeing thinking about TRY block, but at least on the testcases I've > tried it has been rejected in constexpr functions, I think one can't branch > into statement expressions, so that should be fine, OpenMP/OpenACC > constructs are hopefully also rejected in constexpr, what else? LOOP_EXPR, COND_EXPR? Jason