FW: RE: x86_64 port

[Duncan Coutts]

In message <20050307171501.GA15936 at old.davidb.org> David Brown
<haskell at davidb.org> writes:
> On Mon, Mar 07, 2005 at 04:59:38PM -0000, Simon Marlow wrote:
> 
> > The mystery as to why this doesn't affect us on x86 is solved: on x86 we
> > generate slightly different C code, including a dummy function call:
> > 
> > extern void g(void);
> > static void f(void) {
> >   R1 = g;
> >   dummy();
> >   goto *R1;
> > }
> > 
> > the call to dummy() (which we filter out from the assembly later) is
> > enough to force gcc to emit the assignment to R1.  That dummy function
> > call has been there for ever, and the original reason for it has been
> > lost in the mists of time... comments in the source code seemed to
> > indicate that it was probably not necessary any more, so for x86_64 I
> > removed it.  It looks like I'll have to reinstate it to work around this
> > bug, though.

This all appears to be the same for Sparc. With:

register void * R1 __asm__("%g7");

extern void g(void);
static void f(void) {
 R1 = g;
 goto *R1;
}

(BTW I have no idea if register g7 is a sensible choice here! So this test may
be meaningless!)

We get:

sethi   %hi(g), %g1
jmp     %g1+%lo(g)
nop

While with the dummy() call inserted:

sethi   %hi(g), %g1
call    dummy, 0
or      %g1, %lo(g), %g7
jmp     %g7
nop

we actually get any mention of %g7 at all.

This is with gcc 3.3.5 on Sparc Linux (Gentoo).

Duncan