<div dir="ltr"><br>| 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.<br>
| <br>| 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.<div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Niklas<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-07-17 20:06 GMT+02:00 Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Simon<div class="HOEnZb"><div class="h5"><br>
<br>
On 17/07/2014 07:39, Johan Tibell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alright, then which Make file do we need to fix to make sure GCC is<br>
called correctly? Also, I remember reading that some time during the<br>
4.x GCC series GCC switched to auto-detecting the arch to be that of<br>
the machine being used. Could someone try to just switch GCC to a<br>
newer version and see if it automatically stops trying to use i386,<br>
leading to Simon's problem?<br>
<br>
On Thu, Jul 17, 2014 at 8:37 AM, Niklas Larsson <<a href="mailto:metaniklas@gmail.com" target="_blank">metaniklas@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It certainly shouldn't be built with i386, because that is generating code<br>
for a processor that lacks all these fancy atomic instructions. The first of<br>
them appears on the 486.<br>
<br>
i686 should be safe, it goes all the way back to Pentium Pro.<br>
<br>
<br>
2014-07-17 8:33 GMT+02:00 Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A perhaps silly question, *should* ghc-prim be built with i386 or i686?<br>
<br>
On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson <<a href="mailto:metaniklas@gmail.com" target="_blank">metaniklas@gmail.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just found exactly the same thing! Well, I used i686 instead.<br>
<br>
Sounds like it's worthwhile to see if this is limited to ghc-prim or if<br>
there's more stuff that's built with i386.<br>
<br>
<br>
2014-07-17 8:21 GMT+02:00 Páli Gábor János <<a href="mailto:pali.gabor@gmail.com" target="_blank">pali.gabor@gmail.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014-07-17 0:51 GMT+02:00 Páli Gábor János <<a href="mailto:pali.gabor@gmail.com" target="_blank">pali.gabor@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014-07-17 0:47 GMT+02:00 Niklas Larsson <<a href="mailto:metaniklas@gmail.com" target="_blank">metaniklas@gmail.com</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I hope they can just be done away with at the source, that is to<br>
make<br>
gcc<br>
generate the assembly primitives. GHC should already be built with<br>
i686, but<br>
does that reach ghc-prim?<br>
</blockquote>
<br>
This depends on GCC -- if no -march=XXX is explicitly set, I guess it<br>
will take its default, which may vary platform by platform.<br>
</blockquote>
<br>
All right, I have finally got a Windows (x64) machine and installed<br>
the msys2 environment by the GHC wiki [1].  This has GCC 4.5.2 (as<br>
Niklas wrote earlier), where the default -march is i386.  You should<br>
see this line when trying to compile Johan's test program with the -v<br>
flag set:<br>
<br>
COLLECT_GCC_OPTIONS= ... '-v' '-mtune=i386' '-march=i386'<br>
<br>
With the -march=i586 flag explicitly set in the command line, no<br>
__sync_fetch_and_add_n() calls are generated.<br>
<br>
[1]<br>
<br>
<a href="https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2" target="_blank">https://ghc.haskell.org/trac/<u></u>ghc/wiki/Building/Preparation/<u></u>Windows/MSYS2</a><br>
</blockquote>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div></div>