From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16385 invoked by alias); 28 Mar 2002 15:06:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 16357 invoked by uid 71); 28 Mar 2002 15:06:01 -0000 Date: Thu, 28 Mar 2002 07:06:00 -0000 Message-ID: <20020328150601.16355.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Nicola Pero Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880 Reply-To: Nicola Pero X-SW-Source: 2002-03/txt/msg01080.txt.bz2 List-Id: The following reply was made to PR c/3711; it has been noted by GNATS. From: Nicola Pero To: Richard Henderson Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, GNUstep Developers Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880 Date: Thu, 28 Mar 2002 15:02:54 +0000 (GMT) > > Hmmm ... well this testcase arrives from a real example ... forwarding > > code in some advanced OO stuff which worked perfectly well with all GCC > > releases up to now (code from mframe.m in gnustep-base). > > No it didn't. It worked perfectly well *with some particular abi*, > which is not the same thing. Ok ... but I still think the original intention was that it worked on all platforms. > > So I can use SMSmessages in place of a struct {char text[255];} everywhere > > I want, but I can't pass it in place of a struct {char text[255];} to a > > function ? > > Correct. Ok - would it make sense then to add a GCC extension allowing to do it ? Even if not efficiently, at least possible :-) Like telling the compiler - I want to call this method and here I put a variable size struct but I want you to make the call as if it were a fixed size struct of this size. Efficiency is not a major issue here - at least for us - creating a temporary struct to make the call is ok or whatever trick you could use here. > > I think you understood what the function in the testcase "wants/needs" to > > do - which is that it can be called with an arbitrary struct (fixed size) > > as the second argument, and it is informed of the size of the struct from > > the first argument (which is just to say, a source providing the info at > > runtime), and it needs to be able to access the bytes in the struct. > > Why don't you just pass a pointer to the structure all the time? because we don't control callers and functions we forward to. it's basically a 'universal' forwarding function -- it might be forwarding to any function -- and if that function takes a struct as argument, there's nothing we can do -- it takes a struct as argument, and we need to forward it. 'forwarding', in C terms, means you call a function, and that function is able to save the stack in some way, and call another function which takes the same parameters, copying them from stack. the other function returns something, and the first function returns that same something (copying from stack again). So - the first function has 'forwarded' its invocation to the second one. this can be done using gcc extensions, __builtin_apply etc if you know the details. now in building very general OO frameworks you end up with more general requirements - building like a 'universal' forwarding function, and saving in memory invocations (and examining them), and rerunning them later on. all this complicated stuff (or part of it - the other part requires stack assembly tricks I think) used to be possible with GCC < 3.1 - at least on some platforms as you say ... now this change is making it impossible to do it with structs (it still works with other types). are there at least any plans to build up GCC extensions allowing to do this without messing manually with the stack ? I'm not much into this myself :-) so my description of the actual details might be incomplete or imprecise but I could figure out better if needed. I'm not sure how Apple does forwarding stuff in its Objective-C runtime, but it would be cool if GCC would provide a simple powerful C extension allowing to do the basic forwarding operations on all platforms. Then both the Apple Objective-C runtime/Foundation library and the GNU Objective-C runtime/gnustep-base could use the same API and it would be more portable ... we're not concerned with other compilers. It would also be good to have those C extensions available for the C compiler as well ... might be useful to people. Anyway, I'm likely missing something, but I'd like to underline here that there is a need for this kind of forwarding facilities and GCC extensions, and something which used to be possible (or at least theoretically possible) is no longer so - and we likely need - I think - new extensions.