From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17446 invoked by alias); 12 Oct 2007 11:42:42 -0000 Received: (qmail 17437 invoked by uid 22791); 12 Oct 2007 11:42:41 -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; Fri, 12 Oct 2007 11:42:34 +0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA09759; Fri, 12 Oct 07 07:47:09 EDT From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10710121147.AA09759@vlsi1.ultra.nyu.edu> Date: Fri, 12 Oct 2007 11:42:00 -0000 To: iant@google.com Subject: Re: [PATCH] Fix optimization regression in constant folder Cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, mark@codesourcery.com, matz@suse.de, richard.guenther@gmail.com In-Reply-To: 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> 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/msg00718.txt.bz2 > 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. Why? As I keep saying, we already HAVE a flag to denote sizetypes: we don't need another one but can just use THAT one. Why muck around with flags that are designed for an entirely different purpose, namely to characterize user-visible types. > Again, it's a big deal because at the moment most of the gcc > maintainers don't understand the semantics. After all this discussion > I still barely have a handle on what you want. You are talking in > vague generalities, and you are unable to give us any actual code. > It's no wonder we remain confused. It is indeed hard to characterize the semantics of sizetypes in anything other than a case-by-case manner, as this discussion has shown. But, as I said, "the code" is in stor-layout.c: that's where the vast majority of the sizetype operations are found. I think the C front end has almost none, the Ada front end has only a few (mostly related to zero-length arrays), and I don't know how many the C++ front-end has, but I doubt it's very many either. So if we need to understand what types of operations are being done and what those operations are entitled to assume, stor-layout is the place to look.