Re: Windows breakage -- again
I suggest we continue the discussion on the ticket: https://ghc.haskell.org/trac/ghc/ticket/9346 Summary so far is that LOCK is not a valid prefix to MOV, but the x86 code generator doesn't emit any LOCKs before MOVs so I'm not sure how that instruction got there. On Tue, Jul 22, 2014 at 12:41 PM, Niklas Larsson wrote: > That's true, I used mingw. > > I have created a ticket https://ghc.haskell.org/trac/ghc/ticket/9346#ticket. > > > 2014-07-22 12:22 GMT+02:00 Páli Gábor János : > >> 2014-07-22 11:49 GMT+02:00 Johan Tibell : >> > Is this on FreeBSD only or does it happen elsewhere? >> >> I would say it happens everywhere (on 32 bits). I guess Niklas was >> debugging the mingw32 version. > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
That's true, I used mingw. I have created a ticket https://ghc.haskell.org/trac/ghc/ticket/9346#ticket. 2014-07-22 12:22 GMT+02:00 Páli Gábor János : > 2014-07-22 11:49 GMT+02:00 Johan Tibell : > > Is this on FreeBSD only or does it happen elsewhere? > > I would say it happens everywhere (on 32 bits). I guess Niklas was > debugging the mingw32 version. > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-22 11:49 GMT+02:00 Johan Tibell : > Is this on FreeBSD only or does it happen elsewhere? I would say it happens everywhere (on 32 bits). I guess Niklas was debugging the mingw32 version. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
On Tue, Jul 22, 2014 at 9:50 AM, Niklas Larsson wrote: > AtomicPrimOps.hs flakes out for: > fetchAndTest > fetchNandTest > fetchOrTest > fetchXorTest > casTest > > but not for fetchAddSubTest and readWriteTest. > > If I step through it, the segfault comes at line 166, it doesn't reach the > .fetchXXXIntArray function that was called from the thread (at least ghci > doesn't hit a breakpoint set at it). > > GDB says the bad instruction is: > 4475:f0 8b 4c 24 40 lock mov 0x40(%esp),%ecx Is this on FreeBSD only or does it happen elsewhere? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
AtomicPrimOps.hs flakes out for:
fetchAndTest
fetchNandTest
fetchOrTest
fetchXorTest
casTest
but not for fetchAddSubTest and readWriteTest.
If I step through it, the segfault comes at line 166, it doesn't reach the
.fetchXXXIntArray function that was called from the thread (at least ghci
doesn't hit a breakpoint set at it).
GDB says the bad instruction is:
4475:f0 8b 4c 24 40 lock mov 0x40(%esp),%ecx
Niklas
2014-07-22 6:53 GMT+02:00 Páli Gábor János :
> 2014-07-21 21:31 GMT+02:00 Johan Tibell :
> > Great. Thanks all for your help!
>
> I am afraid we are not done with this yet. Yesterday I have also
> committed the fix for the FreeBSD platform, but today I noticed that
> the corresponding test case ("AtomicPrimops") is failing due to
> SIGILL, that is, illegal instruction. And it has been happening for
> all the 32-bit platforms, including Linux [1], SmartOS [2], and
> Solaris [3].
>
> I do not know yet why it goes wrong.
>
> [1]
> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/34/10.html
> [2] http://haskell.inf.elte.hu/builders/smartos-x86-head/73/21.html
> [3] http://haskell.inf.elte.hu/builders/solaris-x86-head/116/21.html
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-21 21:31 GMT+02:00 Johan Tibell :
> Great. Thanks all for your help!
I am afraid we are not done with this yet. Yesterday I have also
committed the fix for the FreeBSD platform, but today I noticed that
the corresponding test case ("AtomicPrimops") is failing due to
SIGILL, that is, illegal instruction. And it has been happening for
all the 32-bit platforms, including Linux [1], SmartOS [2], and
Solaris [3].
I do not know yet why it goes wrong.
[1] http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/34/10.html
[2] http://haskell.inf.elte.hu/builders/smartos-x86-head/73/21.html
[3] http://haskell.inf.elte.hu/builders/solaris-x86-head/116/21.html
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Great. Thanks all for your help!
On Sat, Jul 19, 2014 at 2:04 AM, Austin Seipp wrote:
> Thanks Niklas, this is now committed.
>
> On Fri, Jul 18, 2014 at 9:21 AM, Niklas Larsson wrote:
>> I posted a working and tested patch last night. Please feel free to commit
>> it, I haven't the rights to do it.
>>
>> Niklas
>>
>> Från: Simon Peyton Jones
>> Skickat: 2014-07-18 15:55
>> Till: Niklas Larsson; Johan Tibell
>> Kopia: ghc-devs@haskell.org
>> Ämne: RE: Windows breakage -- again
>>
>> Thank you all for pursuing this. I gather that you know what is going on,
>> so no further info needed from me. Yell if it is otherwise.
>>
>>
>>
>> Meanwhile, is the fix imminent, or should we revert Johan’s patch?
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Niklas Larsson [mailto:metanik...@gmail.com]
>> Sent: 16 July 2014 19:58
>> To: Johan Tibell; Simon Peyton Jones
>> Cc: ghc-devs@haskell.org
>> Subject: Re: Windows breakage -- again
>>
>>
>>
>> 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 :
>>
>> 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
>> Skickat: 2014-07-16 09:57
>> Till: Simon Peyton Jones
>> Kopia: ghc-devs@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
>> 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
>>
>>
>>
>> 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
>> wrote:
>>
>> Aargh! The Windows build has broken – again. I can’t build GHC on my
>> laptop any more.
>>
>>
>> [Hela det ursprungliga meddelandet tas inte med.]
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Thanks Niklas, this is now committed.
On Fri, Jul 18, 2014 at 9:21 AM, Niklas Larsson wrote:
> I posted a working and tested patch last night. Please feel free to commit
> it, I haven't the rights to do it.
>
> Niklas
>
> Från: Simon Peyton Jones
> Skickat: 2014-07-18 15:55
> Till: Niklas Larsson; Johan Tibell
> Kopia: ghc-devs@haskell.org
> Ämne: RE: Windows breakage -- again
>
> Thank you all for pursuing this. I gather that you know what is going on,
> so no further info needed from me. Yell if it is otherwise.
>
>
>
> Meanwhile, is the fix imminent, or should we revert Johan’s patch?
>
>
>
> Simon
>
>
>
> From: Niklas Larsson [mailto:metanik...@gmail.com]
> Sent: 16 July 2014 19:58
> To: Johan Tibell; Simon Peyton Jones
> Cc: ghc-devs@haskell.org
> Subject: Re: Windows breakage -- again
>
>
>
> 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 :
>
> 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
> Skickat: 2014-07-16 09:57
> Till: Simon Peyton Jones
> Kopia: ghc-devs@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
> 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
>
>
>
> 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
> wrote:
>
> Aargh! The Windows build has broken – again. I can’t build GHC on my
> laptop any more.
>
>
> [Hela det ursprungliga meddelandet tas inte med.]
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
--
Regards,
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: Windows breakage -- again
Thank you all for pursuing this. I gather that you know what is going on, so
no further info needed from me. Yell if it is otherwise.
Meanwhile, is the fix imminent, or should we revert Johan’s patch?
Simon
From: Niklas Larsson [mailto:metanik...@gmail.com]
Sent: 16 July 2014 19:58
To: Johan Tibell; Simon Peyton Jones
Cc: ghc-devs@haskell.org
Subject: Re: Windows breakage -- again
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
mailto:metanik...@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<mailto:johan.tib...@gmail.com>
Skickat: 2014-07-16 09:57
Till: Simon Peyton Jones<mailto:simo...@microsoft.com>
Kopia: ghc-devs@haskell.org<mailto:ghc-devs@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
mailto:johan.tib...@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
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
mailto:simo...@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<http://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@haskell.org<mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Yes, ultimately the problem is that the mingw-gcc that is in the tarball git has a too low target. But that is a rather larger fix than setting the arch targetted in configure. 2014-07-17 22:50 GMT+02:00 Páli Gábor János : > 2014-07-17 22:05 GMT+02:00 Niklas Larsson : > > The bug is that the mingw32 build is generating > > code for i386, which lacks these assembler primitives. > > I think this might be a feature instead. As I wrote earlier, on > FreeBSD/i386, arch is set to i486 in GCC's configure script [1]. > Hence, whatever version I install from the Ports Collection, it will > target i486 by default. > > [1] https://github.com/mirrors/gcc/blob/master/gcc/config.gcc#L2899 > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 22:05 GMT+02:00 Johan Tibell : > Can someone see if adding > > Cc-options: -march=i686 > > To ghc-prim.cabal resolves the issue? Yes, I can confirm that it works. However, it shall be prefixed with a conditional such as (os(windows) && arch(i386)) as x86_64 does not support -march=i686. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 22:05 GMT+02:00 Niklas Larsson : > The bug is that the mingw32 build is generating > code for i386, which lacks these assembler primitives. I think this might be a feature instead. As I wrote earlier, on FreeBSD/i386, arch is set to i486 in GCC's configure script [1]. Hence, whatever version I install from the Ports Collection, it will target i486 by default. [1] https://github.com/mirrors/gcc/blob/master/gcc/config.gcc#L2899 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Now I have an extremely simple patch that I have confirmed is working. As it is in the autoconfig stuff, one needs to run: autoreconf make distclean ./boot and so on As apparently everything has been built with i386 before, I'm curious about if there's a performance increase when going i686. I'll have to measure that, but not tonight. Niklas 2014-07-17 22:05 GMT+02:00 Johan Tibell : > Can someone see if adding > > Cc-options: -march=i686 > > To ghc-prim.cabal resolves the issue? > On Jul 17, 2014 9:06 PM, "Simon Marlow" wrote: > >> gcc has -march=native which uses the current CPU's architecture, but I >> think it would be a really bad idea to turn that on by default, because it >> would mean that we have to be really careful which machine we build the >> distributions on. >> >> On my Linux box, gcc -v says it was configured with --with-arch-32=i686, >> which means that -march=i686 is the default for 32-bit code. We shouldn't >> go any later than that IMO. >> >> Anyway, this is all beside the point, if we aren't able to run the code >> generated by gcc (in whatever mode) then there's a bug somewhere. >> >> Cheers, >> Simon >> >> On 17/07/2014 07:39, Johan Tibell wrote: >> >>> Alright, then which Make file do we need to fix to make sure GCC is >>> called correctly? Also, I remember reading that some time during the >>> 4.x GCC series GCC switched to auto-detecting the arch to be that of >>> the machine being used. Could someone try to just switch GCC to a >>> newer version and see if it automatically stops trying to use i386, >>> leading to Simon's problem? >>> >>> On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson >>> wrote: >>> It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell : A perhaps silly question, *should* ghc-prim be built with i386 or i686? > > On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson > wrote: > >> I just found exactly the same thing! Well, I used i686 instead. >> >> Sounds like it's worthwhile to see if this is limited to ghc-prim or >> if >> there's more stuff that's built with i386. >> >> >> 2014-07-17 8:21 GMT+02:00 Páli Gábor János : >> >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : >>> 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > I hope they can just be done away with at the source, that is to > make > gcc > generate the assembly primitives. GHC should already be built with > i686, but > does that reach ghc-prim? > This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. >>> >>> All right, I have finally got a Windows (x64) machine and installed >>> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as >>> Niklas wrote earlier), where the default -march is i386. You should >>> see this line when trying to compile Johan's test program with the -v >>> flag set: >>> >>> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' >>> >>> With the -march=i586 flag explicitly set in the command line, no >>> __sync_fetch_and_add_n() calls are generated. >>> >>> [1] >>> >>> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ >>> Windows/MSYS2 >>> >> >> >> 0001-Set-i686-as-the-minimum-architecture-on-32-bit-mingw.patch Description: Binary data ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Can someone see if adding Cc-options: -march=i686 To ghc-prim.cabal resolves the issue? On Jul 17, 2014 9:06 PM, "Simon Marlow" wrote: > gcc has -march=native which uses the current CPU's architecture, but I > think it would be a really bad idea to turn that on by default, because it > would mean that we have to be really careful which machine we build the > distributions on. > > On my Linux box, gcc -v says it was configured with --with-arch-32=i686, > which means that -march=i686 is the default for 32-bit code. We shouldn't > go any later than that IMO. > > Anyway, this is all beside the point, if we aren't able to run the code > generated by gcc (in whatever mode) then there's a bug somewhere. > > Cheers, > Simon > > On 17/07/2014 07:39, Johan Tibell wrote: > >> Alright, then which Make file do we need to fix to make sure GCC is >> called correctly? Also, I remember reading that some time during the >> 4.x GCC series GCC switched to auto-detecting the arch to be that of >> the machine being used. Could someone try to just switch GCC to a >> newer version and see if it automatically stops trying to use i386, >> leading to Simon's problem? >> >> On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson >> wrote: >> >>> It certainly shouldn't be built with i386, because that is generating >>> code >>> for a processor that lacks all these fancy atomic instructions. The >>> first of >>> them appears on the 486. >>> >>> i686 should be safe, it goes all the way back to Pentium Pro. >>> >>> >>> 2014-07-17 8:33 GMT+02:00 Johan Tibell : >>> >>> A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson wrote: > I just found exactly the same thing! Well, I used i686 instead. > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > there's more stuff that's built with i386. > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > > 2014-07-17 0:51 GMT+02:00 Páli Gábor János : >> >>> 2014-07-17 0:47 GMT+02:00 Niklas Larsson : >>> I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? >>> >>> This depends on GCC -- if no -march=XXX is explicitly set, I guess it >>> will take its default, which may vary platform by platform. >>> >> >> All right, I have finally got a Windows (x64) machine and installed >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as >> Niklas wrote earlier), where the default -march is i386. You should >> see this line when trying to compile Johan's test program with the -v >> flag set: >> >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' >> >> With the -march=i586 flag explicitly set in the command line, no >> __sync_fetch_and_add_n() calls are generated. >> >> [1] >> >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ >> Windows/MSYS2 >> > > > >>> >>> ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
| On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. | | Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. I've looked at it more now. The bug is that the mingw32 build is generating code for i386, which lacks these assembler primitives. The failure to link is just because gcc is sticking in these undefined symbols on the off-chance that you want to provide them yourself, they aren't included in gcc. Stick a -march=i686 in there and it works. I don't think it's reasonable to cater for processors that doesn't have support for CAS. So I'm testing a patch that just adds a -march=i686 flag for 32-bit mingw in aclocal.m4. Niklas 2014-07-17 20:06 GMT+02:00 Simon Marlow : > gcc has -march=native which uses the current CPU's architecture, but I > think it would be a really bad idea to turn that on by default, because it > would mean that we have to be really careful which machine we build the > distributions on. > > On my Linux box, gcc -v says it was configured with --with-arch-32=i686, > which means that -march=i686 is the default for 32-bit code. We shouldn't > go any later than that IMO. > > Anyway, this is all beside the point, if we aren't able to run the code > generated by gcc (in whatever mode) then there's a bug somewhere. > > Cheers, > Simon > > > On 17/07/2014 07:39, Johan Tibell wrote: > >> Alright, then which Make file do we need to fix to make sure GCC is >> called correctly? Also, I remember reading that some time during the >> 4.x GCC series GCC switched to auto-detecting the arch to be that of >> the machine being used. Could someone try to just switch GCC to a >> newer version and see if it automatically stops trying to use i386, >> leading to Simon's problem? >> >> On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson >> wrote: >> >>> It certainly shouldn't be built with i386, because that is generating >>> code >>> for a processor that lacks all these fancy atomic instructions. The >>> first of >>> them appears on the 486. >>> >>> i686 should be safe, it goes all the way back to Pentium Pro. >>> >>> >>> 2014-07-17 8:33 GMT+02:00 Johan Tibell : >>> >>> A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson wrote: > I just found exactly the same thing! Well, I used i686 instead. > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > there's more stuff that's built with i386. > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > > 2014-07-17 0:51 GMT+02:00 Páli Gábor János : >> >>> 2014-07-17 0:47 GMT+02:00 Niklas Larsson : >>> I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? >>> >>> This depends on GCC -- if no -march=XXX is explicitly set, I guess it >>> will take its default, which may vary platform by platform. >>> >> >> All right, I have finally got a Windows (x64) machine and installed >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as >> Niklas wrote earlier), where the default -march is i386. You should >> see this line when trying to compile Johan's test program with the -v >> flag set: >> >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' >> >> With the -march=i586 flag explicitly set in the command line, no >> __sync_fetch_and_add_n() calls are generated. >> >> [1] >> >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/ >> Windows/MSYS2 >> > > > >>> >>> ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
gcc has -march=native which uses the current CPU's architecture, but I think it would be a really bad idea to turn that on by default, because it would mean that we have to be really careful which machine we build the distributions on. On my Linux box, gcc -v says it was configured with --with-arch-32=i686, which means that -march=i686 is the default for 32-bit code. We shouldn't go any later than that IMO. Anyway, this is all beside the point, if we aren't able to run the code generated by gcc (in whatever mode) then there's a bug somewhere. Cheers, Simon On 17/07/2014 07:39, Johan Tibell wrote: Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson wrote: It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell : A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson wrote: I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János : 2014-07-17 0:51 GMT+02:00 Páli Gábor János : 2014-07-17 0:47 GMT+02:00 Niklas Larsson : I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Alright, then which Make file do we need to fix to make sure GCC is called correctly? Also, I remember reading that some time during the 4.x GCC series GCC switched to auto-detecting the arch to be that of the machine being used. Could someone try to just switch GCC to a newer version and see if it automatically stops trying to use i386, leading to Simon's problem? On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson wrote: > It certainly shouldn't be built with i386, because that is generating code > for a processor that lacks all these fancy atomic instructions. The first of > them appears on the 486. > > i686 should be safe, it goes all the way back to Pentium Pro. > > > 2014-07-17 8:33 GMT+02:00 Johan Tibell : > >> A perhaps silly question, *should* ghc-prim be built with i386 or i686? >> >> On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson >> wrote: >> > I just found exactly the same thing! Well, I used i686 instead. >> > >> > Sounds like it's worthwhile to see if this is limited to ghc-prim or if >> > there's more stuff that's built with i386. >> > >> > >> > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : >> > >> >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : >> >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : >> >> >> I hope they can just be done away with at the source, that is to >> >> >> make >> >> >> gcc >> >> >> generate the assembly primitives. GHC should already be built with >> >> >> i686, but >> >> >> does that reach ghc-prim? >> >> > >> >> > This depends on GCC -- if no -march=XXX is explicitly set, I guess it >> >> > will take its default, which may vary platform by platform. >> >> >> >> All right, I have finally got a Windows (x64) machine and installed >> >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as >> >> Niklas wrote earlier), where the default -march is i386. You should >> >> see this line when trying to compile Johan's test program with the -v >> >> flag set: >> >> >> >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' >> >> >> >> With the -march=i586 flag explicitly set in the command line, no >> >> __sync_fetch_and_add_n() calls are generated. >> >> >> >> [1] >> >> >> >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 >> > >> > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
It certainly shouldn't be built with i386, because that is generating code for a processor that lacks all these fancy atomic instructions. The first of them appears on the 486. i686 should be safe, it goes all the way back to Pentium Pro. 2014-07-17 8:33 GMT+02:00 Johan Tibell : > A perhaps silly question, *should* ghc-prim be built with i386 or i686? > > On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson > wrote: > > I just found exactly the same thing! Well, I used i686 instead. > > > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > > there's more stuff that's built with i386. > > > > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > > > >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : > >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > >> >> I hope they can just be done away with at the source, that is to make > >> >> gcc > >> >> generate the assembly primitives. GHC should already be built with > >> >> i686, but > >> >> does that reach ghc-prim? > >> > > >> > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > >> > will take its default, which may vary platform by platform. > >> > >> All right, I have finally got a Windows (x64) machine and installed > >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as > >> Niklas wrote earlier), where the default -march is i386. You should > >> see this line when trying to compile Johan's test program with the -v > >> flag set: > >> > >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' > >> > >> With the -march=i586 flag explicitly set in the command line, no > >> __sync_fetch_and_add_n() calls are generated. > >> > >> [1] > >> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 > > > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
i686 has been out for so long that worrying about i386 support is silly. MinGW-w64 uses i686 by default. Even i586 is *incredibly* conservative. On Jul 16, 2014 11:34 PM, "Johan Tibell" wrote: > A perhaps silly question, *should* ghc-prim be built with i386 or i686? > > On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson > wrote: > > I just found exactly the same thing! Well, I used i686 instead. > > > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > > there's more stuff that's built with i386. > > > > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > > > >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : > >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > >> >> I hope they can just be done away with at the source, that is to make > >> >> gcc > >> >> generate the assembly primitives. GHC should already be built with > >> >> i686, but > >> >> does that reach ghc-prim? > >> > > >> > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > >> > will take its default, which may vary platform by platform. > >> > >> All right, I have finally got a Windows (x64) machine and installed > >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as > >> Niklas wrote earlier), where the default -march is i386. You should > >> see this line when trying to compile Johan's test program with the -v > >> flag set: > >> > >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' > >> > >> With the -march=i586 flag explicitly set in the command line, no > >> __sync_fetch_and_add_n() calls are generated. > >> > >> [1] > >> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 > > > > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
A perhaps silly question, *should* ghc-prim be built with i386 or i686? On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson wrote: > I just found exactly the same thing! Well, I used i686 instead. > > Sounds like it's worthwhile to see if this is limited to ghc-prim or if > there's more stuff that's built with i386. > > > 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János : >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : >> >> I hope they can just be done away with at the source, that is to make >> >> gcc >> >> generate the assembly primitives. GHC should already be built with >> >> i686, but >> >> does that reach ghc-prim? >> > >> > This depends on GCC -- if no -march=XXX is explicitly set, I guess it >> > will take its default, which may vary platform by platform. >> >> All right, I have finally got a Windows (x64) machine and installed >> the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as >> Niklas wrote earlier), where the default -march is i386. You should >> see this line when trying to compile Johan's test program with the -v >> flag set: >> >> COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' >> >> With the -march=i586 flag explicitly set in the command line, no >> __sync_fetch_and_add_n() calls are generated. >> >> [1] >> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 > > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
I just found exactly the same thing! Well, I used i686 instead. Sounds like it's worthwhile to see if this is limited to ghc-prim or if there's more stuff that's built with i386. 2014-07-17 8:21 GMT+02:00 Páli Gábor János : > 2014-07-17 0:51 GMT+02:00 Páli Gábor János : > > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > >> I hope they can just be done away with at the source, that is to make > gcc > >> generate the assembly primitives. GHC should already be built with > i686, but > >> does that reach ghc-prim? > > > > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > > will take its default, which may vary platform by platform. > > All right, I have finally got a Windows (x64) machine and installed > the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as > Niklas wrote earlier), where the default -march is i386. You should > see this line when trying to compile Johan's test program with the -v > flag set: > > COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' > > With the -march=i586 flag explicitly set in the command line, no > __sync_fetch_and_add_n() calls are generated. > > [1] > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 0:51 GMT+02:00 Páli Gábor János : > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : >> I hope they can just be done away with at the source, that is to make gcc >> generate the assembly primitives. GHC should already be built with i686, but >> does that reach ghc-prim? > > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > will take its default, which may vary platform by platform. All right, I have finally got a Windows (x64) machine and installed the msys2 environment by the GHC wiki [1]. This has GCC 4.5.2 (as Niklas wrote earlier), where the default -march is i386. You should see this line when trying to compile Johan's test program with the -v flag set: COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386' With the -march=i586 flag explicitly set in the command line, no __sync_fetch_and_add_n() calls are generated. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
it looks like the atomics available differ in older gccs https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Atomic-Builtins.html#Atomic-Builtins https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Atomic-Builtins.html#Atomic-Builtins On Wed, Jul 16, 2014 at 6:51 PM, Páli Gábor János wrote: > 2014-07-17 0:47 GMT+02:00 Niklas Larsson : > > I hope they can just be done away with at the source, that is to make gcc > > generate the assembly primitives. GHC should already be built with i686, > but > > does that reach ghc-prim? > > This depends on GCC -- if no -march=XXX is explicitly set, I guess it > will take its default, which may vary platform by platform. > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-17 0:47 GMT+02:00 Niklas Larsson : > I hope they can just be done away with at the source, that is to make gcc > generate the assembly primitives. GHC should already be built with i686, but > does that reach ghc-prim? This depends on GCC -- if no -march=XXX is explicitly set, I guess it will take its default, which may vary platform by platform. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
I think it all works ok if the object files goes the normal way, the gnu linker knows what to do with those symbols when it links with the gcc lib. But for some reason (template haskell?) the ghc linker gets involved when compiling the vector library, and it pukes on those symbols. I hope they can just be done away with at the source, that is to make gcc generate the assembly primitives. GHC should already be built with i686, but does that reach ghc-prim? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
On Thu, Jul 17, 2014 at 12:23 AM, Páli Gábor János wrote: > 2014-07-16 23:56 GMT+02:00 Johan Tibell : >> My reading of the docs was that if the platform doesn't support the needed >> instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1, >> where that function *is provided by GCC* as a fallback. > > I guess GCC would expect that somebody else will implement the given > functionality by an external function. > >> Now I'm wondering if I'm supposed to supply that fallback. > > I was told that you cannot reliably emulate those operations in user > mode, without loss in performance. I think loss on performance is OK on i386, but not loss of correctness. In my mind we have 3 options: 1. Raise a compile time error saying that these operations aren't supported on your platform (somewhat hard to detect as it depends on GCC). 2. Raise a runtime error saying the same (easy to detect, just raise from the fallback functions). 3. Provide some fallback. I don't know how to do (3), but it seems like the best option if possible. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-16 23:56 GMT+02:00 Johan Tibell : > My reading of the docs was that if the platform doesn't support the needed > instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1, > where that function *is provided by GCC* as a fallback. I guess GCC would expect that somebody else will implement the given functionality by an external function. > Now I'm wondering if I'm supposed to supply that fallback. I was told that you cannot reliably emulate those operations in user mode, without loss in performance. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
This bug report might shed some light on this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47460 I wonder if I've misunderstood the GCC docs at https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins. My reading of the docs was that if the platform doesn't support the needed instructions then GCC will generated a call to e.g. __sync_fetch_and_add_1, where that function *is provided by GCC* as a fallback. Now I'm wondering if I'm supposed to supply that fallback. On Wed, Jul 16, 2014 at 9:32 PM, Páli Gábor János wrote: > 2014-07-16 20:57 GMT+02:00 Niklas Larsson : > > 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. > > Perhaps you should specify -march=i586 for the C compiler? > > I have tried Johan's test program (posted in this thread earlier) with > -march=i386 and it generates a function call for > __sync_fetch_and_add_1(). (No cmpxchg?) In case of -march=i486, > __sync_fetch_and_add_8() is generated (this cpu type does have a > cmpxchg8b instruction). > > I faced this error earlier because the FreeBSD/i386 builder has been > failing for a while [1] as it assumes -march=i486 by default. With > -march=i586, everything builds just fine. On GNU/Linux, it is not a > problem as it builds C code with -march=i686. > > [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/317/10.html > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
2014-07-16 20:57 GMT+02:00 Niklas Larsson : > 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. Perhaps you should specify -march=i586 for the C compiler? I have tried Johan's test program (posted in this thread earlier) with -march=i386 and it generates a function call for __sync_fetch_and_add_1(). (No cmpxchg?) In case of -march=i486, __sync_fetch_and_add_8() is generated (this cpu type does have a cmpxchg8b instruction). I faced this error earlier because the FreeBSD/i386 builder has been failing for a while [1] as it assumes -march=i486 by default. With -march=i586, everything builds just fine. On GNU/Linux, it is not a problem as it builds C code with -march=i686. [1] http://haskell.inf.elte.hu/builders/freebsd-i386-head/317/10.html ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
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
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 :
>
> 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 :
>>
>> 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
>>> Skickat: 2014-07-16 09:57
>>> Till: Simon Peyton Jones
>>> Kopia: ghc-devs@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
>>> 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
>>>>
>>>> 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 <
>>>> simo...@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/vecto
Re: Windows breakage -- again
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 :
> 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
> Skickat: 2014-07-16 09:57
> Till: Simon Peyton Jones
> Kopia: ghc-devs@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
> 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
>>
>> 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 <
>> simo...@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@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Simon M, do I need to add atomic.c in any other place than ghc-prim.cabal?
I for example found this file includes/stg/Prim.h that list some other
primops.
On Wed, Jul 16, 2014 at 6:36 PM, Johan Tibell
wrote:
> We are on x86(-64), but not on other archs. Simon, which arch are you on?
>
>
> On Wed, Jul 16, 2014 at 5:58 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> Huh. We're not generating the atomics assembly directly ourselves?
>>
>>
>> On Wednesday, July 16, 2014, Johan Tibell 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
>>>
>>> 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 <
>>> simo...@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@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
We are on x86(-64), but not on other archs. Simon, which arch are you on?
On Wed, Jul 16, 2014 at 5:58 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:
> Huh. We're not generating the atomics assembly directly ourselves?
>
>
> On Wednesday, July 16, 2014, Johan Tibell 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
>>
>> 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 <
>> simo...@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@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Huh. We're not generating the atomics assembly directly ourselves?
On Wednesday, July 16, 2014, Johan Tibell 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
>
> 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 <
> simo...@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@haskell.org
>>
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
Simon, does a clean checkout of HEAD, with a default mk/build.mk (i.e. no
funny linking options), lead to this failure for you?
On Wed, Jul 16, 2014 at 2:48 PM, Niklas Larsson
wrote:
> 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
> Skickat: 2014-07-16 09:57
> Till: Simon Peyton Jones
> Kopia: ghc-devs@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
> 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
>>
>> 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 <
>> simo...@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@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
I won't have time to fix this today and I will be out until Tuesday so I
suggest you run
git revert 4ee4ab01c1d97845aecb7707ad2f9a80933e7a49
and push the result to origin/master to unblock yourself (and any other GHC
devs on Windows?)
On Wed, Jul 16, 2014 at 9:56 AM, Johan Tibell
wrote:
> 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
> 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
>>
>> 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 <
>> simo...@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@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
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
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
>
> 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 <
> simo...@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@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows breakage -- again
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
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
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@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
