On 27/05/2012 15:10, Ian Lynagh wrote:
On Tue, May 01, 2012 at 04:52:37AM -0500, Gabriel Dos Reis wrote:
On Tue, May 1, 2012 at 3:05 AM, Simon Marlow<marlo...@gmail.com> wrote:
This appears to be a bug in the gcc that we're currently using.
Compiling this, with -O:
const int i;
int f(void) {return i;}
results in this assembly:
pushl %ebp
movl %esp, %ebp
movl $0, %eax<--- the $0 is wrong, should be _i
leave
ret
I think the asm is actually correct. We've declared a variable 'i',
which either can or must (I don't know what the standard says OTTOMH) be
initialised to 0. We can't change it as it's const, so as long as it's
being initialised to 0, returning 0 is right.
AIUI, a declaration like
const int i;
is a "common" declaration, such that if in another compilation unit there is
const int i = 3;
then the two things refer to the same entity. So even though we can't
change i, we also can't assume that it has the value zero.
I did try to look it up in the C standard but failed to find the right
bit amongst all the stuff about "linkage", so maybe I'm wrong here.
Cheers,
Simon
Turning off -O makes it work.
Maybe time to update our mingw gcc bundles?
yes, it is a bug in that version of GCC/gcc. Does explicit use of 'extern'
makes the bug go away? E.g.
extern const int i;
(that should be semantically equivalent to the original program.)
extern does both give the behaviour that Simon expected, and fix
capi_value on Windows.
Thanks
Ian
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
