Windows breakage -- again

Niklas Larsson metaniklas at gmail.com
Thu Jul 17 06:37:45 UTC 2014


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 <johan.tibell at gmail.com>:

> A perhaps silly question, *should* ghc-prim be built with i386 or i686?
>
> On Thu, Jul 17, 2014 at 8:33 AM, Niklas Larsson <metaniklas at gmail.com>
> 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 <pali.gabor at gmail.com>:
> >
> >> 2014-07-17 0:51 GMT+02:00 Páli Gábor János <pali.gabor at gmail.com>:
> >> > 2014-07-17 0:47 GMT+02:00 Niklas Larsson <metaniklas at gmail.com>:
> >> >> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140717/2bc8bd28/attachment-0001.html>


More information about the ghc-devs mailing list