I think I found a bug...

[Mark Grosberg <myg at tempest dot din dot net>]

Hello all,

I have some code that I have had in a compiler I have been writing for
quite some time now. I think it is perfectly legal ANSI C.  It has been
compiling fine on older versions of GCC, but recently I tried compiling my
compiler on several machines with a newer GCC (and EGCS) compiler and I
ran into some problems.

Apparently, on gcc v2.95.2 (i386) and egcs v2.91.66 (PowerPC) when
compiling the file sys_unix.c of my compiler the GCC compiler seemed to
spin allocating memory. I noticed GCC using around 200MB and killed it. If I 
compile without any optimizations, the file compiles fine. 

So, I kept removing code from the file until I found the offending
routine. It is the following code:

-------------------------------------------------------------------------------

static struct utsname *get_unix_info(void)
{
  static BOOL              got_it = FALSE;
  static struct utsname    uinfo;

  if (got_it)
    return &uinfo;
  else
  {
    if (uname(&uinfo) >= 0)
      got_it = TRUE;
    else
      strcpy(uinfo.sysname,
        strcpy(uinfo.nodename,
        strcpy(uinfo.release,
        strcpy(uinfo.machine,  "*unknown*"))));

    return &uinfo;
  }
}

-------------------------------------------------------------------------------

Okay. It may seem silly how I nested the strcpy()'s like that, but
according to ANSI C, it should work fine (it's only an error case anyhow). 

However, the nested strcpy()'s seem to be causing the problem. At first I
thought the GCC optimizer was being thrown into an endless loop. However,
I discussed the problem on the gcc-bugs mailing list and they said that
given sufficient virtual memory GCC does complete the compile.

It seems that the problem really stems from glibc's inline string
intrinsics. While the GCC compiler should not use vast amounts of virtual
memory to compile such an itty-bitty routine, the GCC people suspect that
something in glibc is tickling some nasty behavior in GCC.

So I am writing here because I was told this is where I should report
glibc errors..

----------------------------------------------------------------------------

BTW: The compiler in question can be obtained from:

   http://www.conman.org/software/amc

If you wish to verify the results your self. In the mean time, I will be
changing the code so that it does not cause the compilations to fail. 

Thanks,
Mark G.