In message <20050307171501.GA15936@old.davidb.org> David Brown
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