RE: FW: RE: x86_64 port

2005-03-08 Thread Simon Marlow
On 07 March 2005 18:01, Kurt Roeckx wrote: On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: $ cat bug.c register void * R1 __asm__(%r13); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $ And take a look at the generated assembly

Re: FW: RE: x86_64 port

2005-03-07 Thread Kurt Roeckx
On Fri, Mar 04, 2005 at 11:13:28AM -0600, John Goerzen wrote: Do any of you know if this is a known problem? - Forwarded message from Simon Marlow [EMAIL PROTECTED] - From: Simon Marlow [EMAIL PROTECTED] Date: Fri, 4 Mar 2005 17:03:31 - To: John Goerzen [EMAIL PROTECTED] Cc:

RE: FW: RE: x86_64 port

2005-03-07 Thread Simon Marlow
On 04 March 2005 17:32, Kurt Roeckx wrote: I have no idea what ghc has too do with gcc, A bit of background: GHC uses gcc as a backend compiler. GHC generates C code that is compiled using gcc (we also have a native code generator for some platforms; but not for x86_64 yet). or what the

Re: FW: RE: x86_64 port

2005-03-07 Thread David Brown
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: $ cat bug.c register void * R1 __asm__(%r13); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $ And take a look at the generated assembly for the function f: f: .LFB2:

RE: FW: RE: x86_64 port

2005-03-07 Thread Simon Marlow
On 07 March 2005 16:18, David Brown wrote: On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: $ cat bug.c register void * R1 __asm__(%r13); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $ And take a look at the generated assembly

RE: FW: RE: x86_64 port

2005-03-07 Thread Simon Marlow
On 07 March 2005 16:40, Simon Marlow wrote: On 07 March 2005 16:18, David Brown wrote: On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: $ cat bug.c register void * R1 __asm__(%r13); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $

Re: FW: RE: x86_64 port

2005-03-07 Thread David Brown
On Mon, Mar 07, 2005 at 04:59:38PM -, 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; }

Re: FW: RE: x86_64 port

2005-03-07 Thread Duncan Coutts
In message [EMAIL PROTECTED] David Brown [EMAIL PROTECTED] writes: On Mon, Mar 07, 2005 at 04:59:38PM -, 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

Re: FW: RE: x86_64 port

2005-03-07 Thread Kurt Roeckx
On Mon, Mar 07, 2005 at 11:47:31AM -, Simon Marlow wrote: $ cat bug.c register void * R1 __asm__(%r13); extern void g(void); static void f(void) { R1 = g; goto *R1; } $ gcc -S -O bug.c $ And take a look at the generated assembly for the function f: f: .LFB2:

Re: FW: RE: x86_64 port

2005-03-07 Thread Kurt Roeckx
On Mon, Mar 07, 2005 at 09:15:01AM -0800, David Brown wrote: gcc 3.3.4 on AMD64 appears to generate correct code when the dummy call is present. Ick. It generates the following code here: subq$8, %rsp movl$g, %r13d movl$0, %eax calldummy

Re: FW: RE: x86_64 port

2005-03-07 Thread David Brown
On Mon, Mar 07, 2005 at 07:01:16PM +0100, Kurt Roeckx wrote: Also, it should be a movq $g, %rax instead of movl. The default x86_64 model on gcc is -mcmodel=small, which assumes that all symbols are within the first 2GB. If you compile it with -mcmodel=medium it'll generate: movabsq $g,