From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54000 invoked by alias); 9 Jun 2016 06:50:31 -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 53980 invoked by uid 89); 9 Jun 2016 06:50:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=12000, family X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Thu, 09 Jun 2016 06:50:19 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7EA1FAC0C; Thu, 9 Jun 2016 06:50:16 +0000 (UTC) Date: Thu, 09 Jun 2016 06:50:00 -0000 From: Richard Biener To: Jason Merrill cc: gcc-patches List Subject: Re: [PATCH] Fold x/x to 1, 0/x to 0 and 0%x to 0 consistently In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2016-06/txt/msg00646.txt.bz2 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. So can you clarify on "We don't want to fold away undefined behavior in a constexpr"? Thanks, Richard.