From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10303 invoked by alias); 15 Oct 2007 00:03:02 -0000 Received: (qmail 10295 invoked by uid 22791); 15 Oct 2007 00:03:01 -0000 X-Spam-Check-By: sourceware.org Received: from VLSI1.ULTRA.NYU.EDU (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org (qpsmtpd/0.31) with SMTP; Mon, 15 Oct 2007 00:02:59 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA21358; Sun, 14 Oct 07 20:07:17 EDT From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10710150007.AA21358@vlsi1.ultra.nyu.edu> Date: Mon, 15 Oct 2007 02:12:00 -0000 To: richard.guenther@gmail.com Subject: Re: [PATCH] Fix optimization regression in constant folder Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, iant@google.com, mark@codesourcery.com, matz@suse.de In-Reply-To: <84fc9c000710140608r6e86aa58wdacfb9e91cbbb3b8@mail.gmail.com> References: <200709171539.26653.ebotcazou@adacore.com> <10710120240.AA03734@vlsi1.ultra.nyu.edu> <200710141225.08559.ebotcazou@adacore.com> <84fc9c000710140331t5b1bf94cr3a19b395c19faa22@mail.gmail.com> <10710141128.AA13909@vlsi1.ultra.nyu.edu> <84fc9c000710140608r6e86aa58wdacfb9e91cbbb3b8@mail.gmail.com> 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/msg00854.txt.bz2 > Set? I thought we would have > > #define TYPE_IGNORE_OVERFLOW (type) TYPE_IS_SIZETYPE (type) I don't see what that would serve. > Where does it do that? I am not aware of any such relation in > middle-end code. Not middle-end code, but front end. The point is that sizetype must have the same signedness and precision as the C size_t. > It's an "issue" because it makes optimizations performed on Ada > sizetype expressions different than C sizetype expressions. But that's wrong and where this whole thread started: if the code tests TYPE_IS_SIZETYPE then it doesn't matter if it's signed or unsigned. > Right. So ssizetype and sizetype have the same semantics? Not sure what "semantics" means in this context. One might be signed and one might be unsigned. If you mean "same semantics in the way we generate expressions for them", then yes. > Why do we have both of them if nobody cares about signedness of > sizetype? Who said nobody cares? We don't care about it for optimization purposes but we certainly do in terms of the types themselves. > The point is the current situation is 1) confusing 2) redundant 3) a mess > (IMHO). It's not confusing to me and it's been this way for decades. There's a major burden that must be met on a proposal to change it. > I want to reduce the mess, not add to it. It is already hard > enough to judge what flags you need to test on optimizations on integer > types, now you want to add another one that should be considered? No. I want the optimizations to correctly take into account a flag that's been around for decades. I am *not* proposing linking these with the other flags: indeed I'm specifically *against* doing that for just the reasons you mention.