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#_0.... 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

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.

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.

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

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

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

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

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 >

| 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

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