Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880

[Nicola Pero <nicola at brainstorm dot co dot uk>]

> > 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.