From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-105596-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 1756 invoked by alias); 23 Nov 2004 01:55:20 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 1678 invoked from network); 23 Nov 2004 01:55:08 -0000
Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39)
  by sourceware.org with SMTP; 23 Nov 2004 01:55:08 -0000
Received: from [192.168.1.103] (pcp03532053pcs.sntafe01.nm.comcast.net[68.35.5.34])
          by comcast.net (rwcrmhc13) with ESMTP
          id <20041123015505015000smeje>; Tue, 23 Nov 2004 01:55:06 +0000
Message-ID: <41A2987B.70604@swarm.org>
Date: Tue, 23 Nov 2004 02:10:00 -0000
From: "Marcus G. Daniels" <mgd@swarm.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Dale Johannesen <dalej@apple.com>
CC: Andrew Pinski <pinskia@physics.uc.edu>, 
 Joe Buck <Joe.Buck@synopsys.com>,
 Michael Matz <matz@suse.de>, Steve Naroff <snaroff@apple.com>, 
 Mark Mitchell <mark@codesourcery.com>,
 Ziemowit Laski <zlaski@apple.com>, Matt Austern <austern@apple.com>, 
 gcc mailing list <gcc@gcc.gnu.org>,
 Mike Stump <mrs@apple.com>
Subject: Re: generalized lvalues -- patch outline
References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <20041117212847.A26376@synopsys.com> <6F5FC748-7BBD-44B9-8DDC-246949F16102@apple.com> <20041118102741.A8347@synopsys.com> <77E8D36A-C0C2-4B03-964C-BEE0FE7BBBC3@apple.com> <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> <Pine.LNX.4.58.0411192234480.29201@wotan.suse.de> <CAE3B44A-3A8C-11D9-9070-000D9330C50E@apple.com> <20041119170011.A30410@synopsys.com> <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> <20041119174042.A1311@synopsys.com> <90DC5074-3A96-11D9-9070-000D9330C50E@apple.com> <9CD04F70-3CC6-11D9-B847-000D9330C50E@apple.com> <7688EB08-3CC7-11D9-AEB4-000A95D692F4@physics.uc.edu> <BCD08631-3CCC-11D9-8AF3-000A95AA5E5E@apple.com> <41A27FA4.2000107@codesourcery.com> <DCE78ED4-3CEC-11D9-9441-000393B2ABA2@apple.com> <41A2900B.3040103@codesourcery.com> <EA3281A1-3CEE-11D9-BE99-000A95D7CD40@apple.com> <273940E4-3CF0-11D9-AEB4-000A95D692F4@physics.uc.edu> <F7E2C83A-3CF0-11D9-BE99-000A95D7CD40@apple.com>
In-Reply-To: <F7E2C83A-3CF0-11D9-BE99-000A95D7CD40@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-11/txt/msg00789.txt.bz2

Dale Johannesen wrote:

> Maybe so, but the file is included as part of the 176.gcc benchmark, 
> and caused
> compilation errors when gcc dropped support for this (mis)feature.

Fwiw, I ran in to the problem with an Objective C application.   It's 
convenient to store predispatched methods as function pointers, with all 
of their argument types.  However, the Objective method lookup methods 
return a generic IMP type which doesn't have that information.  So 
casting on the LHS means that the pointer is stored to the right 
function pointer type, but the RHS is doesn't need to reiterate it (the 
function pointer can be quite complicated).