From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85034 invoked by alias); 13 May 2015 14:19:19 -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 85018 invoked by uid 89); 13 May 2015 14:19:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.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; Wed, 13 May 2015 14:19:16 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 48542AC5D; Wed, 13 May 2015 14:19:12 +0000 (UTC) Date: Wed, 13 May 2015 14:19:00 -0000 From: Richard Biener To: Marek Polacek cc: Jakub Jelinek , GCC Patches , Joseph Myers Subject: Re: [PATCH] Don't fold away division by zero (PR middle-end/66127) In-Reply-To: <20150513141115.GC27320@redhat.com> Message-ID: References: <20150513134111.GA27320@redhat.com> <20150513135509.GE1751@tucnak.redhat.com> <20150513141115.GC27320@redhat.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2015-05/txt/msg01233.txt.bz2 On Wed, 13 May 2015, Marek Polacek wrote: > On Wed, May 13, 2015 at 03:55:10PM +0200, Jakub Jelinek wrote: > > On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote: > > > As discussed in the PR, match.pd happily folds 0 * whatever into 0. That > > > is undesirable from the C/C++ FE POV, since it can make us accept invalid > > > initializers. > > > > > > So fixed in match.pd -- I'd hope there's a better way to do this, but this > > > seems to work. There was some fallout, but nothing unexpected or surprising. > > > > Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by > > zero isn't immediately the operand of mult, but somewhere deeper? > > It won't handle e.g. 0 * (unsigned) (1 / 0). > > > Also, can't the divisor be optimized into 0 only later on, so your code > > would still see !integer_zerop there and fold into 0? > > Perhaps the answer is that in both cases we'd have simplified those already > > into a division by zero. > > Yes, it's a dumb attempt. > > I don't know how to reliably fix this :(. We really want > ... Yeah, I think we can't reliably "avoid" folding away traps like this so any attempt is useless (and we should simply not do this). The only way I see is to make all expressions that might trap set TREE_SIDE_EFFECTS on the expression, so we'd fold it to a, 0. Richard. -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)