From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66852 invoked by alias); 10 Jun 2016 16:16:01 -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 66815 invoked by uid 89); 10 Jun 2016 16:15:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=family X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Jun 2016 16:15:47 +0000 Received: by mail-oi0-f51.google.com with SMTP id k23so119726926oih.0 for ; Fri, 10 Jun 2016 09:15:47 -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=VltKwmlN+/8pSKbQpA9zqH+w76NhpcG9coQGvTZW39I=; b=XM9bqnHYRlSOnxs3dKMERW63wNkKujwiSBcprvrR9537yq9W3wL5vfxP4Gq7LdOtWR NUql608r4WQZYwNXXjoTi5aK4aiXW/lVHTPnuUj7jbJEFAStjhvVfmUDhy5bSqhCDbEh U2zAS/mpH9KZTYkY8P/AExnpzOEeE8BTXwpIlgaDqAQhiqDgi4vMOO9vpukp3Q8LTEqP Zw9PqubP5/wJwHvTz5zSt+Cl1jG/IohS5NJRIbZslmjKghDfT8iKOeDp8HIG6hznIEbB uq2JKN0JT7ImPz2hDjTan3T8ZED2ctbTcbymTbZFP5KLZyqjnLn/h/S8bFBtxDzkxnER og/g== X-Gm-Message-State: ALyK8tKJtdfpZDaN9aP7Nycbm554MoedyDc98bqyNmPFy/JarybT4PgIlB8uczIBlNF5jMUFDJAs8zZtrUxJ6MEe X-Received: by 10.202.48.18 with SMTP id w18mr1446940oiw.61.1465575345295; Fri, 10 Jun 2016 09:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.141.42 with HTTP; Fri, 10 Jun 2016 09:15:25 -0700 (PDT) In-Reply-To: References: <20160609071553.GM7387@tucnak.redhat.com> From: Jason Merrill Date: Fri, 10 Jun 2016 16:16:00 -0000 Message-ID: Subject: Re: [PATCH] Fold x/x to 1, 0/x to 0 and 0%x to 0 consistently To: Richard Biener Cc: Jakub Jelinek , gcc-patches List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00825.txt.bz2 On Fri, Jun 10, 2016 at 3:11 AM, Richard Biener wrote: > On Thu, 9 Jun 2016, Jason Merrill wrote: > >> On Thu, Jun 9, 2016 at 3:39 AM, Richard Biener wrote: >> > On Thu, 9 Jun 2016, Jakub Jelinek wrote: >> > >> >> On Thu, Jun 09, 2016 at 08:50:15AM +0200, Richard Biener wrote: >> >> > On Wed, 8 Jun 2016, Jason Merrill wrote: >> >> > >> >> > > On Wed, Jun 8, 2016 at 11:16 AM, Marc Glisse wrote: >> >> > > > On Wed, 8 Jun 2016, Richard Biener wrote: >> >> > > > >> >> > > >> The following works around PR70992 but the issue came up repeatedly >> >> > > >> that we are not very consistent in preserving the undefined behavior >> >> > > >> of division or modulo by zero. Ok - the only inconsistency is >> >> > > >> that we fold 0 % x to 0 but not 0 % 0 (with literal zero). >> >> > > >> >> >> > > >> After folding is now no longer done early in the C family FEs the >> >> > > >> number of diagnostic regressions with the patch below is two. >> >> > > >> >> >> > > >> FAIL: g++.dg/cpp1y/constexpr-sfinae.C -std=c++14 (test for excess errors) >> >> > > >> >> > > Yep. We don't want to fold away undefined behavior in a constexpr >> >> > > function, since constexpr evaluation wants to detect undefined >> >> > > behavior and treat the expression as non-constant in that case. >> >> > >> >> > Hmm. So 0 / x is not constant because x might be zero but 0 * x is >> >> > constant because it can never invoke undefined behavior? Does this mean >> >> > that 0 << n is not const because n might be too large (I suppose >> >> > 0 << 12000 is not const already)? Is 0 * (-x) const? x might be INT_MIN. >> >> >> >> E.g. for the shifts the C++ FE has cxx_eval_check_shift_p which should >> >> optionally warn and/or set *non_constant_p. 0 * (-INT_MIN) would be >> >> non-constant too, etc. >> >> constexpr int foo (int x) { return -x; } >> >> constexpr int bar (int x) { return 0 * (-x); } >> >> constexpr int a = foo (-__INT_MAX__ - 1); >> >> constexpr int b = bar (-__INT_MAX__ - 1); >> >> shows that we don't diagnose the latter though, most likely because >> >> constexpr evaluation is done on the folded tree. >> >> I don't think there's any folding before constexpr evaluation in this >> case, since this doesn't involve a call. >> >> >> So, either whatever cp_fold does (which uses fold* underneath) should avoid >> >> folding such cases, or the constexpr evaluation should be done on a copy >> >> made before folding. Then cp_fold doesn't have to prohibit optimizations >> >> and it is a matter of constexpr.c routines to detect all the undefined >> >> behavior. After all, I think doing constexpr evaluation on unfolded trees >> >> will have also the advantage of better diagnostic locations. >> > >> > Yes, I think constexpr diagnostic / detection should be done on >> > unfolded trees (not sure why we'd need to a copy here, just do folding >> > later?). If cp_fold already avoids folding 0 * (-x) then it should >> > simply avoid folding 0 / x or 0 % x as well (for the particular issue >> > this thread started on). >> >> The issue is with constexpr functions, which get delayed folding like >> any other function before they are used in constant expression >> evaluation. The copy would be to preserve the unfolded trees through >> cp_fold_function. I've been thinking about doing this anyway; this >> may be the motivation to go ahead with it. > > Or delay the folding until genericization - that is, after all parsing > is complete. Not sure what this would do to memory usage or compile-time > when we keep all unfolded bodies (or even re-use them in template > instantiation). Genericization happens at the end of each (non-template) function, not at EOF. Do you mean delay until gimplification? Jason