[commit: testsuite] master: Fix capi_value on Windows (832fa64)

[Simon Marlow]

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<marlowsd at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc