Re: gcc 3.0 or bug ?

[Richard Frith-Macdonald]

On Friday, May 4, 2001, at 10:01 AM, Dennis Leeuw wrote:

> gcc-3.1 ? I took a CVS snapshot at the same date from the 3.0 branch,
> didn't know there was 3.1, hmmm
>
> Okay I took a new snapshot from base and compiled with both gcc-3.0 and
> gcc-2.95.2.
> 2.95.2 went fine, no problems at all and gcc-3.0 now gives me:
>
> mframe.m: In function `mframe_decode_return':
> mframe.m:1737: Internal compiler error in make_decl_rtl, at varasm.c:591
> Please submit a full bug report, with preprocessed source if 
> appropriate.
> See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> make[3]: *** [shared_obj/ix86/linux-gnu/gnu-gnu-gnu/mframe.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [libgnustep-base.build] Error 2
> make[1]: *** [libgnustep-base.all.library.variables] Error 2
> make[1]: Leaving directory `/opt/src/core/base/Source'
> make: *** [internal-all] Error 2
>
> Is gcc-3.x more memory sensitive ?

I believe that the latest version of either branch is supposed to work.
However, there is currently a compiler bug which crashes (as above) at 
the code -

    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 can be safely commented out if you are building with the ffcall 
library.


There is also a compiler bug that causes link-time failures where nested 
functions
are used and declared inline.  That means you need to hack mframe.h to 
remove the 'inline'
type specifier from any nested function declarations.

Given those two hacks ... things should work.


Since both compiler bugs have been reported, and both effect C and C++ 
compiles as well
as objc, so there is a good hope that the final 3.0 release will build 
GNUstep without
needing any hacks.