From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29987 invoked by alias); 15 Oct 2007 10:52:19 -0000 Received: (qmail 29979 invoked by uid 22791); 15 Oct 2007 10:52:18 -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 10:52:17 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA28470; Mon, 15 Oct 07 06:56:55 EDT From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10710151056.AA28470@vlsi1.ultra.nyu.edu> Date: Mon, 15 Oct 2007 11:36:00 -0000 To: matz@suse.de Subject: Re: [PATCH] Fix optimization regression in constant folder Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, iant@google.com, mark@codesourcery.com, richard.guenther@gmail.com In-Reply-To: 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> <10710150007.AA21358@vlsi1.ultra.nyu.edu> 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/msg00879.txt.bz2 > we know that sizetypes _definitely_ are a problem for the middle-end > because of their peculiar semantics. That may be, but those are the properties and semantics that they such objects DO have from a conceptual point of view and any other way we do it they would have the same semantics! (I'm not saying this very well, but what I'm trying to say is that those semantics are intrinsic to the type of calculations that need to be done.) One can argue that it's too hard to implement them properly, so we ought to do some subsetting. But if we do that, then we CERTAINLY should leave the flag the way it is so that if somebody later wants to do it properly, they at least have the data to do so. > I question your assertion that you _really_ understand > where sizetypes are involved or not, or should be involved. A point to > support that is http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00038.html , > where you couldn't even be bothered to look at the current GCC sources > yourself, to look for where sizetypes should have been used too. I'm sorry, I don't understand the above. Sizetypes are used for sizes and positions, so I understand your point. > They aren't special cased in any of the new optimization passes, new > being something like newer than 5 years. And that's a bug that we're trying to fix by this thread.