A little while ago, I mentioned a possible codegen bug in egcs on the
sparc (different from all other sparc codegen bugs I am aware of).

I now have a bit more info.  In particular, I have a small test case.

Given egcs-bug.c as enclosed below, when this is built with the pre-1.4
userland, it works; with the 1.4 userland, it cores (all work done on
the same hardware under the same, 1.4 vintage, kernel).  Specifically,

% ./egcs-bug		# built with pre-1.4 userland ("2.7.2.2+myc1")
start
wrap(0) -> 1
wrap(1) -> 0
% /mnt/egcs-bug		# built with 1.4 userland (ie, egcs)
start
wrap(0) -> 1
Segmentation fault (core dumped)
% 

I'd appreciate it if someone else could try this.  While similar
conditions (identical hardware and kernel, differing userland) would of
course be preferable, I'd be interested in results from anyone.  I'd be
especially interested to hear if this is for real in 1.4 but has been
fixed in something later.

Here's egcs-bug.c, up to my signature.

#include <stdio.h>

static void (*failfn)(void);

#define FAIL ((*failfn)())

static int wrap(void (*fn)(unsigned char), unsigned char arg)
{
 __label__ fail;

 static void _fail(void)
  { goto fail;
  }

 if (0)
  {
fail:;
    return(0);
  }
 failfn = &_fail;
 (*fn)(arg);
 return(1);
}

static void testfn(unsigned char x)
{
 if (x != 0) FAIL;
}

int main(void);
int main(void)
{
 int v;

 printf("start\n");
 fflush(stdout);
 v = wrap(testfn,0);
 printf("wrap(0) -> %d\n",v);
 fflush(stdout);
 v = wrap(testfn,1);
 printf("wrap(1) -> %d\n",v);
 fflush(stdout);
 exit(0);
}

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B