From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68175 invoked by alias); 9 Jun 2016 22:07:39 -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 68162 invoked by uid 89); 9 Jun 2016 22:07:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=family X-HELO: mail-oi0-f46.google.com Received: from mail-oi0-f46.google.com (HELO mail-oi0-f46.google.com) (209.85.218.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 09 Jun 2016 22:07:28 +0000 Received: by mail-oi0-f46.google.com with SMTP id e72so85540188oib.1 for ; Thu, 09 Jun 2016 15:07:28 -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=Kr8wlAtELiPyHwiX7hzQ4Blm+vlLOb8Aw3DtiEGJZos=; b=Ab3pFwy4m0seatdXAQKXwgX8DOybdJ4724rReviq6xUy1U7UnR2ddW6txxeR95SKEU GaJut2hzrdBZ4s80lRAVViR2QzFwRNIyaBDFf7lNoEraZZl6vTiIhuJBmpLh15CJsKCG GYHXgN1IHfzpJNVqWsv1bIOZWt0PqRux7dz0vXzJYX8u0DHE6qjKz9cnPAYwYI7YbDoN b7zKVBXPAo3HkvNX8bpaTso16vKrhIgWivgsGPuzCcdsY4zajZ+23WoN0Wg2ifi+Uwut 9rMVG2n7LLrWGxuyg6RKZ4R/SoB4YQd9zIW1buTnK/pjSsMqWBZxztKf91MYrQ74mwoV xwuQ== X-Gm-Message-State: ALyK8tK2QLYuwhMeLUJEhYaeJCTcExqdTqWw3Pd2oxS2SLiI1XFyvSbk9MgvthlYzbHjuQJhGwuAHLuDuV/mxoAR X-Received: by 10.157.52.253 with SMTP id t58mr6591182otd.150.1465510046283; Thu, 09 Jun 2016 15:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.141.42 with HTTP; Thu, 9 Jun 2016 15:07:06 -0700 (PDT) In-Reply-To: References: <20160609071553.GM7387@tucnak.redhat.com> From: Jason Merrill Date: Thu, 09 Jun 2016 22:07: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/msg00760.txt.bz2 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. Jason