Re: Two days old build breakage on i386.

2014-06-30 Thread Johan Tibell
I fixed the x86 issue and re-commited my work as
4ee4ab01c1d97845aecb7707ad2f9a80933e7a49.

On Fri, Jun 27, 2014 at 1:27 PM, Simon Marlow  wrote:
> On 27/06/2014 12:23, Johan Tibell wrote:
>>
>> On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow  wrote:
>>>
>>> The problem is that this instruction requires three separate registers,
>>> but
>>> cmpxchgl already reads and writes %eax leaving only two free registers
>>> (%ecx
>>> and %edx).
>>>
>>> You'll need to arrange to not use the complicated addressing modes with
>>> cmpxchg on i386, and keep the number of free regs required <= 2.
>>
>>
>> Where's the best place to arrange for that? If I switch from using
>> getAmode to computing the address into a temp register in StgCmmPrim
>> will that ensure that the address is simple, or could some
>> optimization replace my temp register computation with a complex
>> address again?
>
>
> There aren't any optimisations that happen on the instructions after
> codegen, and if there were, they would have to respect the same rule. So
> using a register is the right thing, yes.
>
> Cheers,
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-27 Thread Simon Marlow

On 27/06/2014 12:23, Johan Tibell wrote:

On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow  wrote:

The problem is that this instruction requires three separate registers, but
cmpxchgl already reads and writes %eax leaving only two free registers (%ecx
and %edx).

You'll need to arrange to not use the complicated addressing modes with
cmpxchg on i386, and keep the number of free regs required <= 2.


Where's the best place to arrange for that? If I switch from using
getAmode to computing the address into a temp register in StgCmmPrim
will that ensure that the address is simple, or could some
optimization replace my temp register computation with a complex
address again?


There aren't any optimisations that happen on the instructions after 
codegen, and if there were, they would have to respect the same rule. 
So using a register is the right thing, yes.


Cheers,
Simon

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-27 Thread Johan Tibell
On Fri, Jun 27, 2014 at 1:14 PM, Simon Marlow  wrote:
> The problem is that this instruction requires three separate registers, but
> cmpxchgl already reads and writes %eax leaving only two free registers (%ecx
> and %edx).
>
> You'll need to arrange to not use the complicated addressing modes with
> cmpxchg on i386, and keep the number of free regs required <= 2.

Where's the best place to arrange for that? If I switch from using
getAmode to computing the address into a temp register in StgCmmPrim
will that ensure that the address is simple, or could some
optimization replace my temp register computation with a complex
address again?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-27 Thread Simon Marlow
The problem is that this instruction requires three separate registers, 
but cmpxchgl already reads and writes %eax leaving only two free 
registers (%ecx and %edx).


You'll need to arrange to not use the complicated addressing modes with 
cmpxchg on i386, and keep the number of free regs required <= 2.


Really we ought to have 4 usable regs, but for that to happen we need to 
change the calling convention and swap R1 with Sp, but we can't easily 
do that because it needs a change in LLVM too (sigh).


Cheers,
Simon

On 26/06/2014 19:39, Johan Tibell wrote:

Here's some more debug output. Can someone interpret it:

genRaInsn
cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4)
 r_dying  =  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
 w_dying  =  []
 virt_read=  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
 virt_written =  []
 freeregs =  FreeRegs 4282318848
 assig=  [n1nD :-> InMem 0,
  n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg
(RealRegSingle 3)]
ghc-stage1: panic! (the 'impossible' happened)
   (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

 allocating vreg:  VirtualRegI n1nD
 assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
 freeRegs: FreeRegs 4282318848
 initFreeRegs: FreeRegs 4282318861

(i.e. it's the cmpxchg instruction which is causing the failure.)


On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell mailto:johan.tib...@gmail.com>> wrote:

I'm trying to understand the output from the register allocator:

   (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

 allocating vreg:  VirtualRegI n1nD
 assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
 freeRegs: FreeRegs 4282318848
 initFreeRegs: FreeRegs 4282318861

Without understanding exactly what's wrong, the message above
suggests that we're trying to allocate a reg for n1nD, but there's
already an assignment for that virtual reg, is that right?



On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell
mailto:johan.tib...@gmail.com>> wrote:

Herbert pushed my revert for me a minute ago. Everyone should be
good once they sync.


On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell
mailto:johan.tib...@gmail.com>> wrote:

I guess you don't have
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed
this morning) which is fine. You should be in a good state
now when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.


On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones
mailto:simo...@microsoft.com>> wrote:

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 

[master f958079] Revert "Add more primops for atomic ops
on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644
testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644
testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 

fatal: bad object
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $

What now?

Simon

__ __

*From:*Johan Tibell [mailto:johan.tib...@gmail.com
<mailto:johan.tib...@gmail.com>]
*Sent:* 26 June 2014 13:25
        *To:* Simon Peyton Jones
*Cc:* Karel Gardas; ghc-devs
*Subject:* Re: Two days old build breakage on i386.

__ __

Just to make sure this is the same breakage, are you on
an i386 Windows machine? If so git
revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get
unstuck.

__ __

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones
mailto:simo...@microsoft.com>>
wrote:

Aaaargh!  Once again the Windows build is broken.  I
am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now
*silently* do nothing.  At least they should elicit
warnings saying that they are disabled pending 

RE: Two days old build breakage on i386.

2014-06-26 Thread Simon Peyton Jones
Thank you!!

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 14:06
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Herbert pushed my revert for me a minute ago. Everyone should be good once they 
sync.

On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
mailto:johan.tib...@gmail.com>> wrote:
I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed 
this morning) which is fine. You should be in a good state now when 
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.

On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell 
[mailto:johan.tib...@gmail.com<mailto:johan.tib...@gmail.com>]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org<mailto:ghc-devs-boun...@haskell.org>] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4<http://ghc.mk:4>: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

2014-06-26 Thread Simon Peyton Jones
After your reversion, I can build again.  Thanks!

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:51
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I pushed 
this morning) which is fine. You should be in a good state now when 
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.

On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:

git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell 
[mailto:johan.tib...@gmail.com<mailto:johan.tib...@gmail.com>]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org<mailto:ghc-devs-boun...@haskell.org>] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4<http://ghc.mk:4>: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
Here's some more debug output. Can someone interpret it:

genRaInsn
cmpxchgl %vI_n1nF,8(%vI_n1nD,%vI_n1nE,4)
r_dying  =  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
w_dying  =  []
virt_read=  [%vI_n1nD, %vI_n1nE, %vI_n1nF]
virt_written =  []
freeregs =  FreeRegs 4282318848
assig=  [n1nD :-> InMem 0,
 n1nE :-> InReg (RealRegSingle 2), n1nF :-> InReg
(RealRegSingle 3)]
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

allocating vreg:  VirtualRegI n1nD
assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861

(i.e. it's the cmpxchg instruction which is causing the failure.)


On Thu, Jun 26, 2014 at 8:17 PM, Johan Tibell 
wrote:

> I'm trying to understand the output from the register allocator:
>
>   (GHC version 7.9.20140626 for i386-unknown-linux):
>  RegAllocLinear.allocRegsAndSpill: no spill candidates
>
> allocating vreg:  VirtualRegI n1nD
> assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
> 2)),(n1nF,InReg (RealRegSingle 3))]
> freeRegs: FreeRegs 4282318848
> initFreeRegs: FreeRegs 4282318861
>
> Without understanding exactly what's wrong, the message above suggests
> that we're trying to allocate a reg for n1nD, but there's already an
> assignment for that virtual reg, is that right?
>
>
>
> On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell 
> wrote:
>
>> Herbert pushed my revert for me a minute ago. Everyone should be good
>> once they sync.
>>
>>
>> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
>> wrote:
>>
>>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which
>>> I pushed this morning) which is fine. You should be in a good state now
>>> when d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>>>
>>>
>>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones <
>>> simo...@microsoft.com> wrote:
>>>
>>>>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>>>
>>>> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>>>>
>>>> 23 files changed, 86 insertions(+), 1016 deletions(-)
>>>>
>>>> rewrite compiler/nativeGen/CPrim.hs (62%)
>>>>
>>>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>>>>
>>>> delete mode 100644
>>>> testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>>>>
>>>> delete mode 100644
>>>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>>>>
>>>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>>
>>>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>>
>>>> HEAD $
>>>>
>>>> What now?
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>>>> *Sent:* 26 June 2014 13:25
>>>> *To:* Simon Peyton Jones
>>>> *Cc:* Karel Gardas; ghc-devs
>>>> *Subject:* Re: Two days old build breakage on i386.
>>>>
>>>>
>>>>
>>>> Just to make sure this is the same breakage, are you on an i386 Windows
>>>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>>>>
>>>>
>>>>
>>>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
>>>> simo...@microsoft.com> wrote:
>>>>
>>>>  Aaaargh!  Once again the Windows build is broken.  I am utterly
>>>> stalled.
>>>>
>>>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.
>>>>  At least they should elicit warnings saying that they are disabled pending
>>>> the fix to X and Y.
>>>>
>>>> Please can someone bisect to find out which patch is the culprit?
>>>>
>>>> I wish we had a more systematic way to find this out. I hate being the
>>>> main person who gets stuck because some unrelated change has broken the
>>>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>>>
>>>> Thanks
>>>>
>>>> Simon
>>>>
>>>>
>>

Re: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
I'm trying to understand the output from the register allocator:

  (GHC version 7.9.20140626 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates

allocating vreg:  VirtualRegI n1nD
assignment:   [(n1nD,InMem 0),(n1nE,InReg (RealRegSingle
2)),(n1nF,InReg (RealRegSingle 3))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861

Without understanding exactly what's wrong, the message above suggests that
we're trying to allocate a reg for n1nD, but there's already an assignment
for that virtual reg, is that right?



On Thu, Jun 26, 2014 at 3:05 PM, Johan Tibell 
wrote:

> Herbert pushed my revert for me a minute ago. Everyone should be good once
> they sync.
>
>
> On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
> wrote:
>
>> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
>> pushed this morning) which is fine. You should be in a good state now when
>> d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>>
>>
>> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones <
>> simo...@microsoft.com> wrote:
>>
>>>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>>
>>> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>>>
>>> 23 files changed, 86 insertions(+), 1016 deletions(-)
>>>
>>> rewrite compiler/nativeGen/CPrim.hs (62%)
>>>
>>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>>>
>>> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>>>
>>> delete mode 100644
>>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>>>
>>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>
>>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>>
>>> HEAD $
>>>
>>> What now?
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>>> *Sent:* 26 June 2014 13:25
>>> *To:* Simon Peyton Jones
>>> *Cc:* Karel Gardas; ghc-devs
>>> *Subject:* Re: Two days old build breakage on i386.
>>>
>>>
>>>
>>> Just to make sure this is the same breakage, are you on an i386 Windows
>>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>>>
>>>
>>>
>>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
>>> simo...@microsoft.com> wrote:
>>>
>>>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>>
>>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.
>>>  At least they should elicit warnings saying that they are disabled pending
>>> the fix to X and Y.
>>>
>>> Please can someone bisect to find out which patch is the culprit?
>>>
>>> I wish we had a more systematic way to find this out. I hate being the
>>> main person who gets stuck because some unrelated change has broken the
>>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>>
>>> Thanks
>>>
>>> Simon
>>>
>>>
>>> | -Original Message-
>>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>>> Karel
>>> | Gardas
>>> | Sent: 26 June 2014 09:56
>>> | To: ghc-devs; Johan Tibell
>>> | Subject: Two days old build breakage on i386.
>>> |
>>> |
>>> | Hello,
>>> |
>>> | builders running on i386 building for this platform caught issue which
>>> | shows as a build breakage:
>>> |
>>> | ghc-stage1: panic! (the 'impossible' happened)
>>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>>> | allocating vreg: VirtualRegI n1Q6
>>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>>> | freeRegs: FreeRegs 4282318848
>>> | initFreeRegs: FreeRegs 4282318861
>>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>>> | make[1]: ***
>>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>>> |

Re: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
Herbert pushed my revert for me a minute ago. Everyone should be good once
they sync.


On Thu, Jun 26, 2014 at 2:51 PM, Johan Tibell 
wrote:

> I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
> pushed this morning) which is fine. You should be in a good state now when
> d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.
>
>
> On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones  > wrote:
>
>>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>>
>> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>>
>> 23 files changed, 86 insertions(+), 1016 deletions(-)
>>
>> rewrite compiler/nativeGen/CPrim.hs (62%)
>>
>> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>>
>> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>>
>> delete mode 100644
>> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>>
>> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>
>> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>>
>> HEAD $
>>
>> What now?
>>
>> Simon
>>
>>
>>
>> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
>> *Sent:* 26 June 2014 13:25
>> *To:* Simon Peyton Jones
>> *Cc:* Karel Gardas; ghc-devs
>> *Subject:* Re: Two days old build breakage on i386.
>>
>>
>>
>> Just to make sure this is the same breakage, are you on an i386 Windows
>> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>>
>>
>>
>> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones <
>> simo...@microsoft.com> wrote:
>>
>>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>
>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
>> least they should elicit warnings saying that they are disabled pending the
>> fix to X and Y.
>>
>> Please can someone bisect to find out which patch is the culprit?
>>
>> I wish we had a more systematic way to find this out. I hate being the
>> main person who gets stuck because some unrelated change has broken the
>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>
>> Thanks
>>
>> Simon
>>
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
>> | Gardas
>> | Sent: 26 June 2014 09:56
>> | To: ghc-devs; Johan Tibell
>> | Subject: Two days old build breakage on i386.
>> |
>> |
>> | Hello,
>> |
>> | builders running on i386 building for this platform caught issue which
>> | shows as a build breakage:
>> |
>> | ghc-stage1: panic! (the 'impossible' happened)
>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>> | allocating vreg: VirtualRegI n1Q6
>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> | freeRegs: FreeRegs 4282318848
>> | initFreeRegs: FreeRegs 4282318861
>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> | make[1]: ***
>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>> |
>> | Have a look for example on linux-i386 buildot log here:
>> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>> |
>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> | it's OS independent and probably 32bit/i386 platform specific and it's
>> | two days old breakage now. The last two night builds fail on all
>> | mentioned buildbots. I'm not sure but perhaps:
>> |
>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> | Author: Johan Tibell 
>> | Date:   Mon Jun 9 11:43:21 2014 +0200
>> |
>> | triggers that issue? I'm not claiming that the commit is actual culprit,
>> | this may be just recently un-hidden issue in linear regs allocator on
>> | i386!
>> |
>> | Thanks!
>> | Karel
>>
>> | ___
>> | 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: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
I guess you don't have 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 (which I
pushed this morning) which is fine. You should be in a good state now when
d8abf85f8ca176854e9d5d0b12371c4bc402aac3 is reverted.


On Thu, Jun 26, 2014 at 2:49 PM, Simon Peyton Jones 
wrote:

>  git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>
> [master f958079] Revert "Add more primops for atomic ops on byte arrays"
>
> 23 files changed, 86 insertions(+), 1016 deletions(-)
>
> rewrite compiler/nativeGen/CPrim.hs (62%)
>
> delete mode 100644 libraries/ghc-prim/cbits/atomic.c
>
> delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs
>
> delete mode 100644
> testsuite/tests/concurrent/should_run/AtomicPrimops.stdout
>
> HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>
> fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177
>
> HEAD $
>
> What now?
>
> Simon
>
>
>
> *From:* Johan Tibell [mailto:johan.tib...@gmail.com]
> *Sent:* 26 June 2014 13:25
> *To:* Simon Peyton Jones
> *Cc:* Karel Gardas; ghc-devs
> *Subject:* Re: Two days old build breakage on i386.
>
>
>
> Just to make sure this is the same breakage, are you on an i386 Windows
> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>
>
>
> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
> wrote:
>
>  Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>
> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
> least they should elicit warnings saying that they are disabled pending the
> fix to X and Y.
>
> Please can someone bisect to find out which patch is the culprit?
>
> I wish we had a more systematic way to find this out. I hate being the
> main person who gets stuck because some unrelated change has broken the
> Windows build.  (Thanks for Karel, who got to it a day before me.)
>
> Thanks
>
> Simon
>
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
> | Gardas
> | Sent: 26 June 2014 09:56
> | To: ghc-devs; Johan Tibell
> | Subject: Two days old build breakage on i386.
> |
> |
> | Hello,
> |
> | builders running on i386 building for this platform caught issue which
> | shows as a build breakage:
> |
> | ghc-stage1: panic! (the 'impossible' happened)
> | (GHC version 7.9.20140624 for i386-unknown-linux):
> | RegAllocLinear.allocRegsAndSpill: no spill candidates
> | allocating vreg: VirtualRegI n1Q6
> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> | freeRegs: FreeRegs 4282318848
> | initFreeRegs: FreeRegs 4282318861
> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> | make[1]: ***
> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
> | libraries/ghc-prim/ghc.mk:4: recipe for target
> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
> |
> | Have a look for example on linux-i386 buildot log here:
> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
> |
> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> | it's OS independent and probably 32bit/i386 platform specific and it's
> | two days old breakage now. The last two night builds fail on all
> | mentioned buildbots. I'm not sure but perhaps:
> |
> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> | Author: Johan Tibell 
> | Date:   Mon Jun 9 11:43:21 2014 +0200
> |
> | triggers that issue? I'm not claiming that the commit is actual culprit,
> | this may be just recently un-hidden issue in linear regs allocator on
> | i386!
> |
> | Thanks!
> | Karel
>
> | ___
> | 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: Two days old build breakage on i386.

2014-06-26 Thread Simon Peyton Jones
git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3

[master f958079] Revert "Add more primops for atomic ops on byte arrays"

23 files changed, 86 insertions(+), 1016 deletions(-)

rewrite compiler/nativeGen/CPrim.hs (62%)

delete mode 100644 libraries/ghc-prim/cbits/atomic.c

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.hs

delete mode 100644 testsuite/tests/concurrent/should_run/AtomicPrimops.stdout

HEAD $ git revert 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

fatal: bad object 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177

HEAD $
What now?
Simon

From: Johan Tibell [mailto:johan.tib...@gmail.com]
Sent: 26 June 2014 13:25
To: Simon Peyton Jones
Cc: Karel Gardas; ghc-devs
Subject: Re: Two days old build breakage on i386.

Just to make sure this is the same breakage, are you on an i386 Windows 
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3 and 
04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.

On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
mailto:simo...@microsoft.com>> wrote:
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs 
[mailto:ghc-devs-boun...@haskell.org<mailto:ghc-devs-boun...@haskell.org>] On 
Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
|
|
| Hello,
|
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
|
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4<http://ghc.mk:4>: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
|
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
|
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
|
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell mailto:johan.tib...@gmail.com>>
| Date:   Mon Jun 9 11:43:21 2014 +0200
|
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
|
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

2014-06-26 Thread Simon Peyton Jones
Thanks.  It’s blocking me from building GHC at all on my laptop, so temporary 
reversion would be great
Thank you!
Simon


From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell
Sent: 26 June 2014 11:38
To: Karel Gardas
Cc: Simon Marlow; ghc-devs
Subject: Re: Two days old build breakage on i386.

I think it's reasonable to say my change triggers the issue, but I don't know 
why and I need someone who understand the register allocator better (e.g. Simon 
M) to at least give me some pointers on how to debug this. If this is causing 
more trouble than build bot breakages (which is bad enough), let me know and 
I'll either revert temporarily and or try to work around the issue.

Also, how do I repro this if I don't have a x86 machine lying around? Have 
people been successful working on these kind of issues in a VM?

On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
mailto:karel.gar...@centrum.cz>> wrote:

Hello,

builders running on i386 building for this platform caught issue which shows as 
a build breakage:

ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem 
1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 
1
libraries/ghc-prim/ghc.mk:4<http://ghc.mk:4>: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed

Have a look for example on linux-i386 buildot log here: 
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html

Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so it's OS 
independent and probably 32bit/i386 platform specific and it's two days old 
breakage now. The last two night builds fail on all mentioned buildbots. I'm 
not sure but perhaps:

commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell mailto:johan.tib...@gmail.com>>
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual culprit, this 
may be just recently un-hidden issue in linear regs allocator on i386!

Thanks!
Karel

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Herbert Valerio Riedel
On 2014-06-26 at 13:42:47 +0200, Karel Gardas wrote:
> On 06/26/14 12:37 PM, Johan Tibell wrote:
[...]

>> Also, how do I repro this if I don't have a x86 machine lying around?
>> Have people been successful working on these kind of issues in a VM?
>
> My simplest way is to install VirtualBox and inside it i386-ubuntu,
> give it 2 GB RAM, 15GB drive and this should get you going really
> quickly. Then you will need to:

Fwiw, on Ubuntu I'd rather recommend something more lightweight such as
schroot or using LXC, i.e.

  https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-basic-usage

as using such a container seems to have less SMP-scheduling overhead and
memory overhead.

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
I'm going to push a revert to HEAD. I'm validating the commit now so it
should reach HEAD soonish.


On Thu, Jun 26, 2014 at 2:24 PM, Johan Tibell 
wrote:

> Just to make sure this is the same breakage, are you on an i386 Windows
> machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.
>
>
> On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones  > wrote:
>
>> Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>>
>> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
>> least they should elicit warnings saying that they are disabled pending the
>> fix to X and Y.
>>
>> Please can someone bisect to find out which patch is the culprit?
>>
>> I wish we had a more systematic way to find this out. I hate being the
>> main person who gets stuck because some unrelated change has broken the
>> Windows build.  (Thanks for Karel, who got to it a day before me.)
>>
>> Thanks
>>
>> Simon
>>
>> | -Original Message-
>> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
>> | Gardas
>> | Sent: 26 June 2014 09:56
>> | To: ghc-devs; Johan Tibell
>> | Subject: Two days old build breakage on i386.
>> |
>> |
>> | Hello,
>> |
>> | builders running on i386 building for this platform caught issue which
>> | shows as a build breakage:
>> |
>> | ghc-stage1: panic! (the 'impossible' happened)
>> | (GHC version 7.9.20140624 for i386-unknown-linux):
>> | RegAllocLinear.allocRegsAndSpill: no spill candidates
>> | allocating vreg: VirtualRegI n1Q6
>> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
>> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> | freeRegs: FreeRegs 4282318848
>> | initFreeRegs: FreeRegs 4282318861
>> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> | make[1]: ***
>> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
>> | libraries/ghc-prim/ghc.mk:4: recipe for target
>> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
>> |
>> | Have a look for example on linux-i386 buildot log here:
>> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>> |
>> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> | it's OS independent and probably 32bit/i386 platform specific and it's
>> | two days old breakage now. The last two night builds fail on all
>> | mentioned buildbots. I'm not sure but perhaps:
>> |
>> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> | Author: Johan Tibell 
>> | Date:   Mon Jun 9 11:43:21 2014 +0200
>> |
>> | triggers that issue? I'm not claiming that the commit is actual culprit,
>> | this may be just recently un-hidden issue in linear regs allocator on
>> | i386!
>> |
>> | Thanks!
>> | Karel
>> | ___
>> | 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: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
On Thu, Jun 26, 2014 at 2:31 PM, Mateusz Kowalczyk 
wrote:

> On 06/26/2014 12:37 PM, Johan Tibell wrote:
> > I think it's reasonable to say my change triggers the issue, but I don't
> > know why and I need someone who understand the register allocator better
> > (e.g. Simon M) to at least give me some pointers on how to debug this. If
> > this is causing more trouble than build bot breakages (which is bad
> > enough), let me know and I'll either revert temporarily and or try to
> work
> > around the issue.
> >
> > Also, how do I repro this if I don't have a x86 machine lying around?
> Have
> > people been successful working on these kind of issues in a VM?
> >
>
> I can give you shell access to the machine in the OP but it's not the
> fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it.


Thanks, but I'll try to see if I can install VirtualBox on my OS X machine
first.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Mateusz Kowalczyk
On 06/26/2014 12:37 PM, Johan Tibell wrote:
> I think it's reasonable to say my change triggers the issue, but I don't
> know why and I need someone who understand the register allocator better
> (e.g. Simon M) to at least give me some pointers on how to debug this. If
> this is causing more trouble than build bot breakages (which is bad
> enough), let me know and I'll either revert temporarily and or try to work
> around the issue.
> 
> Also, how do I repro this if I don't have a x86 machine lying around? Have
> people been successful working on these kind of issues in a VM?
> 

I can give you shell access to the machine in the OP but it's not the
fastest thing in the world (3GHz Core 2 Duo). Let me know if you want it.

> 
> On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
> wrote:
> 
>>
>> Hello,
>>
>> builders running on i386 building for this platform caught issue which
>> shows as a build breakage:
>>
>> ghc-stage1: panic! (the 'impossible' happened)
>> (GHC version 7.9.20140624 for i386-unknown-linux):
>> RegAllocLinear.allocRegsAndSpill: no spill candidates
>> allocating vreg: VirtualRegI n1Q6
>> assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem
>> 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
>> freeRegs: FreeRegs 4282318848
>> initFreeRegs: FreeRegs 4282318861
>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
>> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o]
>> Error 1
>> libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-
>> install/build/GHC/PrimopWrappers.o' failed
>>
>> Have a look for example on linux-i386 buildot log here:
>> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>>
>> Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
>> it's OS independent and probably 32bit/i386 platform specific and it's two
>> days old breakage now. The last two night builds fail on all mentioned
>> buildbots. I'm not sure but perhaps:
>>
>> commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
>> Author: Johan Tibell 
>> Date:   Mon Jun 9 11:43:21 2014 +0200
>>
>> triggers that issue? I'm not claiming that the commit is actual culprit,
>> this may be just recently un-hidden issue in linear regs allocator on i386!
>>
>> Thanks!
>> Karel
>>
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
Just to make sure this is the same breakage, are you on an i386 Windows
machine? If so git revert d8abf85f8ca176854e9d5d0b12371c4bc402aac3
and 04dd7cb3423f1940242fdfe2ea2e3b8abd68a177 to get unstuck.


On Thu, Jun 26, 2014 at 2:13 PM, Simon Peyton Jones 
wrote:

> Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.
>
> Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At
> least they should elicit warnings saying that they are disabled pending the
> fix to X and Y.
>
> Please can someone bisect to find out which patch is the culprit?
>
> I wish we had a more systematic way to find this out. I hate being the
> main person who gets stuck because some unrelated change has broken the
> Windows build.  (Thanks for Karel, who got to it a day before me.)
>
> Thanks
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
> | Gardas
> | Sent: 26 June 2014 09:56
> | To: ghc-devs; Johan Tibell
> | Subject: Two days old build breakage on i386.
> |
> |
> | Hello,
> |
> | builders running on i386 building for this platform caught issue which
> | shows as a build breakage:
> |
> | ghc-stage1: panic! (the 'impossible' happened)
> | (GHC version 7.9.20140624 for i386-unknown-linux):
> | RegAllocLinear.allocRegsAndSpill: no spill candidates
> | allocating vreg: VirtualRegI n1Q6
> | assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
> | 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> | freeRegs: FreeRegs 4282318848
> | initFreeRegs: FreeRegs 4282318861
> | Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> | make[1]: ***
> | [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
> | libraries/ghc-prim/ghc.mk:4: recipe for target
> | 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
> |
> | Have a look for example on linux-i386 buildot log here:
> | http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
> |
> | Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> | it's OS independent and probably 32bit/i386 platform specific and it's
> | two days old breakage now. The last two night builds fail on all
> | mentioned buildbots. I'm not sure but perhaps:
> |
> | commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> | Author: Johan Tibell 
> | Date:   Mon Jun 9 11:43:21 2014 +0200
> |
> | triggers that issue? I'm not claiming that the commit is actual culprit,
> | this may be just recently un-hidden issue in linear regs allocator on
> | i386!
> |
> | Thanks!
> | Karel
> | ___
> | 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: Two days old build breakage on i386.

2014-06-26 Thread Simon Peyton Jones
Aaaargh!  Once again the Windows build is broken.  I am utterly stalled.

Moreover -fregs-graph and -fregs-iterative now *silently* do nothing.  At least 
they should elicit warnings saying that they are disabled pending the fix to X 
and Y.

Please can someone bisect to find out which patch is the culprit?  

I wish we had a more systematic way to find this out. I hate being the main 
person who gets stuck because some unrelated change has broken the Windows 
build.  (Thanks for Karel, who got to it a day before me.)

Thanks

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Karel
| Gardas
| Sent: 26 June 2014 09:56
| To: ghc-devs; Johan Tibell
| Subject: Two days old build breakage on i386.
| 
| 
| Hello,
| 
| builders running on i386 building for this platform caught issue which
| shows as a build breakage:
| 
| ghc-stage1: panic! (the 'impossible' happened)
| (GHC version 7.9.20140624 for i386-unknown-linux):
| RegAllocLinear.allocRegsAndSpill: no spill candidates
| allocating vreg: VirtualRegI n1Q6
| assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
| 0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
| freeRegs: FreeRegs 4282318848
| initFreeRegs: FreeRegs 4282318861
| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| make[1]: ***
| [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
| libraries/ghc-prim/ghc.mk:4: recipe for target
| 'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed
| 
| Have a look for example on linux-i386 buildot log here:
| http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
| 
| Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
| it's OS independent and probably 32bit/i386 platform specific and it's
| two days old breakage now. The last two night builds fail on all
| mentioned buildbots. I'm not sure but perhaps:
| 
| commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
| Author: Johan Tibell 
| Date:   Mon Jun 9 11:43:21 2014 +0200
| 
| triggers that issue? I'm not claiming that the commit is actual culprit,
| this may be just recently un-hidden issue in linear regs allocator on
| i386!
| 
| Thanks!
| Karel
| ___
| 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: Two days old build breakage on i386.

2014-06-26 Thread Karel Gardas

On 06/26/14 12:37 PM, Johan Tibell wrote:

I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M) to at least give me some pointers on how to debug this.
If this is causing more trouble than build bot breakages (which is bad
enough), let me know and I'll either revert temporarily and or try to
work around the issue.


it does not hurt me as long as it does not go to 7.10 release so it's 
enough time to fix that. So feel free not to revert your patch 
especially if you do have some time to look into real culprit in regs alloc.



Also, how do I repro this if I don't have a x86 machine lying around?
Have people been successful working on these kind of issues in a VM?


My simplest way is to install VirtualBox and inside it i386-ubuntu, give 
it 2 GB RAM, 15GB drive and this should get you going really quickly. 
Then you will need to:


sudo apt-get install gcc ghc make git (in ubuntu)

which should be enough and then just follow ghc's wiki to obtain source 
tree and bootstrap on linux...


Roughly it should be that IMHO. If not, I may do that myself and send 
you exact stepts to follow...


Thanks!
Karel




On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas mailto:karel.gar...@centrum.cz>> wrote:


Hello,

builders running on i386 building for this platform caught issue
which shows as a build breakage:

ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.__allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3)
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug:
http://www.haskell.org/ghc/__reportabug

make[1]: ***
[libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4 : recipe for target
'libraries/ghc-prim/dist-__install/build/GHC/__PrimopWrappers.o' failed

Have a look for example on linux-i386 buildot log here:
http://haskell.inf.elte.hu/__builders/validator1-linux-x86-__head/18/7.html


Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386
so it's OS independent and probably 32bit/i386 platform specific and
it's two days old breakage now. The last two night builds fail on
all mentioned buildbots. I'm not sure but perhaps:

commit d8abf85f8ca176854e9d5d0b12371c__4bc402aac3
Author: Johan Tibell mailto:johan.tib...@gmail.com>>
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual
culprit, this may be just recently un-hidden issue in linear regs
allocator on i386!

Thanks!
Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Páli Gábor János
2014-06-26 12:37 GMT+02:00 Johan Tibell :
> Also, how do I repro this if I don't have a x86 machine lying around? Have
> people been successful working on these kind of issues in a VM?

For what it is worth, the FreeBSD/i386 builder actually runs in jail
with a 32-bit userland on a 64-bit host, and it apparently can
reproduce the problem.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Re: Two days old build breakage on i386.

2014-06-26 Thread Johan Tibell
I think it's reasonable to say my change triggers the issue, but I don't
know why and I need someone who understand the register allocator better
(e.g. Simon M) to at least give me some pointers on how to debug this. If
this is causing more trouble than build bot breakages (which is bad
enough), let me know and I'll either revert temporarily and or try to work
around the issue.

Also, how do I repro this if I don't have a x86 machine lying around? Have
people been successful working on these kind of issues in a VM?


On Thu, Jun 26, 2014 at 10:55 AM, Karel Gardas 
wrote:

>
> Hello,
>
> builders running on i386 building for this platform caught issue which
> shows as a build breakage:
>
> ghc-stage1: panic! (the 'impossible' happened)
> (GHC version 7.9.20140624 for i386-unknown-linux):
> RegAllocLinear.allocRegsAndSpill: no spill candidates
> allocating vreg: VirtualRegI n1Q6
> assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 0),(n1Q6,InMem
> 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]
> freeRegs: FreeRegs 4282318848
> initFreeRegs: FreeRegs 4282318861
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o]
> Error 1
> libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-
> install/build/GHC/PrimopWrappers.o' failed
>
> Have a look for example on linux-i386 buildot log here:
> http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html
>
> Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so
> it's OS independent and probably 32bit/i386 platform specific and it's two
> days old breakage now. The last two night builds fail on all mentioned
> buildbots. I'm not sure but perhaps:
>
> commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
> Author: Johan Tibell 
> Date:   Mon Jun 9 11:43:21 2014 +0200
>
> triggers that issue? I'm not claiming that the commit is actual culprit,
> this may be just recently un-hidden issue in linear regs allocator on i386!
>
> Thanks!
> Karel
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


Two days old build breakage on i386.

2014-06-26 Thread Karel Gardas


Hello,

builders running on i386 building for this platform caught issue which 
shows as a build breakage:


ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140624 for i386-unknown-linux):
RegAllocLinear.allocRegsAndSpill: no spill candidates
allocating vreg: VirtualRegI n1Q6
assignment: [(c1PV,InMem 2),(n1Q5,InBoth (RealRegSingle 3) 
0),(n1Q6,InMem 1),(n1Q7,InMem 3),(n1Q9,InReg (RealRegSingle 2))]

freeRegs: FreeRegs 4282318848
initFreeRegs: FreeRegs 4282318861
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** 
[libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o' failed


Have a look for example on linux-i386 buildot log here: 
http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/18/7.html


Anyway, this happens on Linux, FreeBSD and Solaris buildbots on i386 so 
it's OS independent and probably 32bit/i386 platform specific and it's 
two days old breakage now. The last two night builds fail on all 
mentioned buildbots. I'm not sure but perhaps:


commit d8abf85f8ca176854e9d5d0b12371c4bc402aac3
Author: Johan Tibell 
Date:   Mon Jun 9 11:43:21 2014 +0200

triggers that issue? I'm not claiming that the commit is actual culprit, 
this may be just recently un-hidden issue in linear regs allocator on i386!


Thanks!
Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs