From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8592 invoked by alias); 14 Oct 2007 15:46:39 -0000 Received: (qmail 8584 invoked by uid 22791); 14 Oct 2007 15:46:38 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 14 Oct 2007 15:46:32 +0000 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id l9EFk4Is026118; Sun, 14 Oct 2007 08:46:04 -0700 Received: from smtp.corp.google.com (spacemonkey2.corp.google.com [192.168.120.114]) by zps35.corp.google.com with ESMTP id l9EFk3nG000687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Oct 2007 08:46:04 -0700 Received: from localhost.localdomain.google.com (adsl-76-249-168-94.dsl.pltn13.sbcglobal.net [76.249.168.94]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id l9EFk25o013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Oct 2007 08:46:03 -0700 To: "Richard Guenther" Cc: "Eric Botcazou" , "Richard Kenner" , gcc-patches@gcc.gnu.org, mark@codesourcery.com, matz@suse.de Subject: Re: [PATCH] Fix optimization regression in constant folder References: <200709171539.26653.ebotcazou@adacore.com> <10710120240.AA03734@vlsi1.ultra.nyu.edu> <200710141225.08559.ebotcazou@adacore.com> <84fc9c000710140331t5b1bf94cr3a19b395c19faa22@mail.gmail.com> From: Ian Lance Taylor Date: Sun, 14 Oct 2007 16:07:00 -0000 In-Reply-To: <84fc9c000710140331t5b1bf94cr3a19b395c19faa22@mail.gmail.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 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/msg00838.txt.bz2 "Richard Guenther" writes: > On 10/14/07, Eric Botcazou wrote: > > > The flags aren't fixed in stone. In fact, I just introduced them > > > earlier this year. So all this tells me is that we need to change the > > > flags. I already proposed such a change > > > (http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00053.html). Nobody has > > > yet explained why my proposal wouldn't work. > > > > From my point of view, your proposal (TYPE_IGNORE_OVERFLOWS + > > TYPE_OVERFLOW_WRAPS) is OK. > > I don't want to have TYPE_IGNORE_OVERFLOWS. Matters are complicated > enough already. I also like you to revisit the decision to make Ada sizetype > signed. If there are optimization regressions for expressions created by > stor-layout.c solve them there, as that is the place where enough knowledge > about the involved magnitudes is available. The point of TYPE_IGNORE_OVERFLOWS is not for signed vs. unsigned, but is rather to permit retaining the optimization currently done for TYPE_IS_SIZE_TYPE in extract_muldiv_1. If we have an unsigned type that is not a sizetype, we cannot do this since it will change the result if the original computation overflowed. We don't want to set TYPE_OVERFLOW_UNDEFINED for sizetypes, because we want to overflow to wrap, and in particular because we want to permit reassociation. We need some way to indicate that this type does not overflow. Ian