From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6322 invoked by alias); 11 Oct 2007 19:30:52 -0000 Received: (qmail 6311 invoked by uid 22791); 11 Oct 2007 19:30:51 -0000 X-Spam-Check-By: sourceware.org Received: from mail.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 11 Oct 2007 19:30:49 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 9D71115043; Thu, 11 Oct 2007 21:30:46 +0200 (CEST) Date: Thu, 11 Oct 2007 19:30:00 -0000 From: Michael Matz To: Richard Kenner Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, iant@google.com, mark@codesourcery.com, richard.guenther@gmail.com Subject: Re: [PATCH] Fix optimization regression in constant folder In-Reply-To: <10710111921.AA28207@vlsi1.ultra.nyu.edu> Message-ID: References: <200709171539.26653.ebotcazou@adacore.com> <200709301801.39718.ebotcazou@adacore.com> <200710010127.59677.ebotcazou@adacore.com> <10710010056.AA15609@vlsi1.ultra.nyu.edu> <10710010257.AA21585@vlsi1.ultra.nyu.edu> <10710010344.AA22633@vlsi1.ultra.nyu.edu> <470D0C50.4080506@codesourcery.com> <10710111536.AA24058@vlsi1.ultra.nyu.edu> <10710111616.AA25194@vlsi1.ultra.nyu.edu> <10710111651.AA26098@vlsi1.ultra.nyu.edu> <10710111850.AA27 912@vlsi1.ultra.nyu.edu> <10710111921.AA28207@vlsi1.ultra.nyu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes 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 X-SW-Source: 2007-10/txt/msg00680.txt.bz2 Hi, On Thu, 11 Oct 2007, Richard Kenner wrote: > > The point is that (X*c1)/c2 and X*(c1/c2) are _different_ for some values > > of X,c1 and c2 (namely sometimes but not all the time when X*c1 > > overflows). Assuming that the first value was the correct one (for > > instance zero) we will have introduced a miscompilation. We have two ways > > for fixing this: > > 1) declare the precondition (the initial overflow) to be invalid. > > 2) don't do the transformation in flow > > > > Solution (1) would require that overflow in sizetype is not ignored, but > > undefined. Then we couldn't have done the reassociation which created > > this problem. But that is something you explicitely didn't want. > > > > Solution (2) would require removing the exception for sizetype, at which > > point it again looks more like an unsigned wrapping type. > > Again, you are trying to interpret the semantics of sizetypes in terms of > those more-properly used for user-defined types. As you say, sizetypes > have the property that if the "complete" expression would overflow, the > program is illegal, so the above transformation is fine. Ehh? Above I'm explicitely showing why the transformation is _not_ fine, yet you read it as the opposite? Ciao, Michael.