Windows breakage -- again

Johan Tibell johan.tibell at gmail.com
Wed Jul 16 19:15:00 UTC 2014


I'll be out until Tuesday.

I would much appreciate if someone with a Windows setup could help me debug
this. These symbols are supposed to be defined by GCC somewhere (as GCC is
outputting these when it cannot convert __sync_fetch_and_add into assembly
instructions.)


On Wed, Jul 16, 2014 at 9:08 PM, Niklas Larsson <metaniklas at gmail.com>
wrote:

> Oh, wait, it isn't the system linker that is complaining, it's the ghc rts
> linker. Maybe we just have to tell it to leave those symbols alone.
>
> Niklas
>
>
> 2014-07-16 20:57 GMT+02:00 Niklas Larsson <metaniklas at gmail.com>:
>
> I get the same failure when I try to build HEAD. Turns out the error
>> occurs on the 32-bit Windows build, and my successful build was a 64-bit
>> build. My 64-bit build still succeeds.
>>
>> Also, gcc is 4.5.2 on 32-bit, not 4.6.3 as on 64-bit.
>>
>> Niklas
>>
>>
>>
>> 2014-07-16 14:48 GMT+02:00 Niklas Larsson <metaniklas at gmail.com>:
>>
>>   I have built ghc on windows after that was added with no issue.
>>>
>>> I can take a look this evening and  see how HEAD works for me.
>>>
>>> The standard gcc in the tarballs is 4.6.3, which is getting long in the
>>> tooth, there is an issue on trac to upgrade it.
>>>
>>> -- Niklas
>>>
>>>  ------------------------------
>>> Från: Johan Tibell <johan.tibell at gmail.com>
>>> Skickat: ‎2014-‎07-‎16 09:57
>>> Till: Simon Peyton Jones <simonpj at microsoft.com>
>>> Kopia: ghc-devs at haskell.org
>>> Ämne: Re: Windows breakage -- again
>>>
>>> You can rollback the commit (git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49)
>>> and push that to the repo if you wish. I will try to re-add the primop
>>> again after I figure out what's wrong.
>>>
>>>
>>> On Wed, Jul 16, 2014 at 9:37 AM, Johan Tibell <johan.tibell at gmail.com>
>>> wrote:
>>>
>>>> I added some primops about a month ago
>>>> (4ee4ab01c1d97845aecb7707ad2f9a80933e7a49) that call __sync_fetch_and_add,
>>>> a gcc/llvm builtin. I'm a bit surprised to see this error. The GCC manual
>>>> [1] says:
>>>>
>>>> > " Not all operations are supported by all target processors. If a
>>>> particular operation cannot be implemented on the target processor, a
>>>> warning will be generated and a call an external function will be
>>>> generated. The external function will carry the same name as the builtin,
>>>> with an additional suffix `_n' where n is the size of the data type."
>>>>
>>>> I'm a bit surprised by this error for two reasons:
>>>>
>>>>  * A call to that symbol should only be generated if the CPU doesn't
>>>> support the atomic instructions. What CPU model does Windows report that
>>>> you have?
>>>>
>>>>  * gcc should define such a symbol. For me the following test program
>>>> compiles:
>>>>
>>>>  #include <stdint.h>
>>>>
>>>> uint8_t test(uint8_t* ptr, uint8_t val) {
>>>>   return __sync_fetch_and_add_1(ptr, val);
>>>> }
>>>>
>>>> int main(void) {
>>>>   uint8_t n;
>>>>   return test(&n, 1);
>>>> }
>>>>
>>>> Does that compile for you? Which version of GCC do we end up using on
>>>> Windows?
>>>>
>>>> The reported symbol (___sync_fetch_and_add_1) has three leading
>>>> underscores, that looks weird. Can you compile just
>>>> libraries/ghc-prim/cbits/atomic.c and see if it's indeed GCC that generates
>>>> a reference to that symbol?
>>>>
>>>>  1. http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
>>>>
>>>>
>>>>  On Wed, Jul 16, 2014 at 12:29 AM, Simon Peyton Jones <
>>>> simonpj at microsoft.com> wrote:
>>>>
>>>>>   Aargh!  The Windows build has broken – again.  I can’t build GHC on
>>>>> my laptop any more.
>>>>>
>>>>> A clean ‘sh validate’ finishes as below.  What on earth is
>>>>> `___sync_fetch_and_add_1'?
>>>>>
>>>>> Can anyone help?  Thanks!
>>>>>
>>>>> Simon
>>>>>
>>>>> "inplace/bin/ghc-stage2.exe" -hisuf hi -osuf  o -hcsuf hc -static
>>>>> -H32m -O -Werror -Wall -H64m -O0    -package-name vector-0.10.9.1
>>>>> -hide-all-packages -i -ilibraries/vector/.
>>>>> -ilibraries/vector/dist-install/build
>>>>> -ilibraries/vector/dist-install/build/autogen
>>>>> -Ilibraries/vector/dist-install/build
>>>>> -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include
>>>>> -Ilibraries/vector/internal   -optP-DVECTOR_BOUNDS_CHECKS -optP-include
>>>>> -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package
>>>>> base-4.7.1.0 -package deepseq-1.3.0.2 -package ghc-prim-0.3.1.0 -package
>>>>> primitive-0.5.2.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O2 -O
>>>>> -dcore-lint -fno-warn-deprecated-flags  -no-user-package-db -rtsopts
>>>>> -Wwarn     -odir libraries/vector/dist-install/build -hidir
>>>>> libraries/vector/dist-install/build -stubdir
>>>>> libraries/vector/dist-install/build   -c
>>>>> libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o
>>>>> libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o
>>>>>
>>>>> Loading package ghc-prim ... linking ... ghc-stage2.exe: unable to
>>>>> load package `ghc-prim'
>>>>>
>>>>> ghc-stage2.exe:
>>>>> C:\code\HEAD\libraries\ghc-prim\dist-install\build\HSghc-prim-0.3.1.0.o:
>>>>> unknown symbol `___sync_fetch_and_add_1'
>>>>>
>>>>> libraries/vector/ghc.mk:5: recipe for target
>>>>> 'libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o'
>>>>> failed
>>>>>
>>>>> make[1]: ***
>>>>> [libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o]
>>>>> Error 1
>>>>>
>>>>>
>>>>>
>>>>> I
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140716/839fc16d/attachment.html>


More information about the ghc-devs mailing list