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

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

[Richard Henderson]

The following reply was made to PR c/3711; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: gcc-gnats@gcc.gnu.org, nicola@brainstorm.co.uk, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880
Date: Mon, 25 Mar 2002 16:25:56 -0800

  > 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3711
 
 Incidentally, I believe this test case to be in error.  The type of the 
 argument in the caller and the callee is different.  In particular, the 
 size of the argument is static in the caller and variable in the callee. 
  Whether or not an argument has variable size affects calling 
 conventions, and thus affects how the callee should find the argument in 
 varargs.
 
 A correct test case would have the caller have a variable sized 
 structure as well.
 
 
 r~
 

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

[rth]

Synopsis: ICE in instantiate_virtual_regs_1, at function.c:3880

State-Changed-From-To: analyzed->closed
State-Changed-By: rth
State-Changed-When: Thu Apr 25 23:14:22 2002
State-Changed-Why:
    Fixed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3711

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

[Richard Henderson]

The following reply was made to PR c/3711; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: Nicola Pero <nicola@brainstorm.co.uk>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   GNUstep Developers <gnustep-dev@gnu.org>
Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880
Date: Thu, 28 Mar 2002 09:24:13 -0800

 On Thu, Mar 28, 2002 at 03:02:54PM +0000, Nicola Pero wrote:
 > Ok - would it make sense then to add a GCC extension allowing to do it ?
 
 No, because ...
 
 > 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.
 
 ... that's what libffi is for.
 
 
 r~

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

[Nicola Pero]

The following reply was made to PR c/3711; it has been noted by GNATS.

From: Nicola Pero <nicola@brainstorm.co.uk>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   GNUstep Developers <gnustep-dev@gnu.org>
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.
 

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

[Richard Henderson]

The following reply was made to PR c/3711; it has been noted by GNATS.

From: Richard Henderson <rth@redhat.com>
To: Nicola Pero <nicola@brainstorm.co.uk>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   GNUstep Developers <gnustep-dev@gnu.org>
Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880
Date: Tue, 26 Mar 2002 09:41:07 -0800

 On Tue, Mar 26, 2002 at 11:53:03AM +0000, Nicola Pero wrote:
 > 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.
 
 > 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.
 
 > This is very confusing for users I must say.  And it is not how it worked
 > in previous versions of the compiler.
 
 Yes it is.  Like I said, this has *never* worked on sparc64, and
 never will.
 
 > 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?
 
 
 r~

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

[Nicola Pero]

The following reply was made to PR c/3711; it has been noted by GNATS.

From: Nicola Pero <nicola@brainstorm.co.uk>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   GNUstep Developers <gnustep-dev@gnu.org>
Subject: Re: c/3711: ICE in instantiate_virtual_regs_1, at function.c:3880
Date: Tue, 26 Mar 2002 11:53:03 +0000 (GMT)

 >  > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3711
 > 
 > Incidentally, I believe this test case to be in error.  The type of the 
 > argument in the caller and the callee is different.  In particular, the 
 > size of the argument is static in the caller and variable in the callee. 
 >  Whether or not an argument has variable size affects calling 
 > conventions, and thus affects how the callee should find the argument in 
 > varargs.
 > 
 > A correct test case would have the caller have a variable sized 
 > structure as well.
 
 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).
 
 If that is wrong, other code is wrong ... and well variable size structs
 are much less useful ... are you meaning that if I have
 
 int size = 255;
 
 struct
 {
   char text[size];
 } SMSmessage;
 
 then I can't pass the SMSmessage to a function accepting a struct {char
 text[255]; } as argument ?
 
 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 ?
 
 This is very confusing for users I must say.  And it is not how it worked
 in previous versions of the compiler.
 
 Anyway - if that does not longer work on GCC 3.1, at least let me know how
 do we make our code to work with GCC 3.1.
 
 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.
 
 This is needed to implement proper forwarding of methods when there are
 structs.
 
 I guess there might be other problems then - here is an excerpt of code
 needing to return a struct of a certain (fixed) size, which is only known
 when the function is called -
 
     case _C_ARY_B:
     case _C_STRUCT_B:
     case _C_UNION_B:
       {
 	typedef struct {
 	  char	val[size];
 	} block;
 	inline block retframe_block(void *rframe)
 	{
 	  __builtin_return (rframe);
 	}
 	*(block*)buffer = retframe_block(retframe);
 	break;
       }
 
 This works with GCC < 3.1.  If what you say is true, this will no longer
 work with GCC 3.1, because 'block' is a variable size struct, and can't
 replace a fixed size struct as the return type.
 
 So - question - since this stuff which worked fine on all previous
 compilers no longer works, and you say the code is broken - ok then how do
 we fix the code ?