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
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
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.
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
> .fetch
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
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, illeg
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
&g
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 other
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
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 min
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=i6
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 v
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.
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
| 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 ther
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
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
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 sil
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:
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
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+
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
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:4
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
wi
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
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
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
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'
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
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
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)
>
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 We
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 add
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. T
: 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 ou
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
> (4ee4ab
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 i
38 matches
Mail list logo
