On 06/08/2009 03:14, Manuel M T Chakravarty wrote:
I guess this broke during the recent RTS cleanup...
"/usr/bin/ghc" -optc-O -optc-Wall -optc-Werror
-optc-DTABLES_NEXT_TO_CODE -optc-Iincludes -optc-Irts -H32m -O -Wall
-Werror -H64m -O0 -fasm -i -iincludes/.
-iincludes/dist-derivedconstants/buil
I guess this broke during the recent RTS cleanup...
"/usr/bin/ghc" -optc-O -optc-Wall -optc-Werror -optc-
DTABLES_NEXT_TO_CODE -optc-Iincludes -optc-Irts -H32m -O -Wall -
Werror -H64m -O0 -fasm -i -iincludes/. -iincludes/dist-
derivedconstants/build -iincludes/dist-derivedconstants/build/
Matthias Kilian wrote:
[sent to ian only by accident; resending to the list]
On Sun, Jan 18, 2009 at 12:17:28PM +, Ian Lynagh wrote:
In fact, looking at pthread.h on Linux:
#ifdef __USE_UNIX98
,
PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RE
[sent to ian only by accident; resending to the list]
On Sun, Jan 18, 2009 at 12:17:28PM +, Ian Lynagh wrote:
> In fact, looking at pthread.h on Linux:
>
> #ifdef __USE_UNIX98
> ,
> PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
> PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
>
On Sun, Jan 18, 2009 at 11:04:53AM +0100, Matthias Kilian wrote:
> On Sat, Jan 17, 2009 at 11:21:03PM +, Ian Lynagh wrote:
> > OK, that mostly worked, but ffi014 timed out.
> >
> > It turns out that "hello world" linked with -threaded -debug deadlocks
> > at:
> > ASSERT_LOCK_HELD(&sched_mu
On Sat, Jan 17, 2009 at 11:21:03PM +, Ian Lynagh wrote:
> OK, that mostly worked, but ffi014 timed out.
>
> It turns out that "hello world" linked with -threaded -debug deadlocks
> at:
> ASSERT_LOCK_HELD(&sched_mutex);
> at the start of newBoundTask. This is doing
> ASSERT(pthread_mute
On Sat, Jan 17, 2009 at 02:42:28AM +, Ian Lynagh wrote:
>
> I think I've found the problem: file_lock_mutex wasn't initialised. I'll
> validate etc tomorrow.
OK, that mostly worked, but ffi014 timed out.
It turns out that "hello world" linked with -threaded -debug deadlocks
at:
ASSERT_LO
On Sat, Jan 17, 2009 at 02:42:28AM +, Ian Lynagh wrote:
> > I still don't understand why this failure does happen at all.
> > Running a build with -DLOCK_DEBUG may help to discover what's going
> > on, but you'll need a lot of disk space for the build log. I can't
> > help here much, because I'
On Sat, Jan 17, 2009 at 10:46:38PM +1100, Manuel M T Chakravarty wrote:
> Thanks for writing the patch. Nobody assumed you did that for no
> reason. However, a patch that fixes one and breaks another
> architecture ultimately does not fix the problem. From what you are
> writing, it doesn'
Matthias Kilian:
On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
Configuring installPackage-1.0...
ghc: internal error: RELEASE_LOCK: I do not own this lock:
posix/FileLock.c 90
(GHC version 6.11.20090115 for i386_apple_darwin)
Please report this as a GHC bug:
http://www.hask
Simon Marlow:
Manuel M T Chakravarty wrote:
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -
O0 -fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -
package-name rts -static -I../gmp/gmpbuild -I../libffi/build/
include -I. -
On Fri, Jan 16, 2009 at 09:35:53PM +0100, Matthias Kilian wrote:
> On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
> > >Configuring installPackage-1.0...
> > >ghc: internal error: RELEASE_LOCK: I do not own this lock:
> > >posix/FileLock.c 90
> > >(GHC version 6.11.20090115 for i
On Fri, Jan 16, 2009 at 03:20:59PM +, Simon Marlow wrote:
> >Configuring installPackage-1.0...
> >ghc: internal error: RELEASE_LOCK: I do not own this lock:
> >posix/FileLock.c 90
> >(GHC version 6.11.20090115 for i386_apple_darwin)
> >Please report this as a GHC bug:
> >http://w
Manuel M T Chakravarty wrote:
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS
-package-name rts -static -I../gmp/gmpbuild
-I../libffi/build/include -I. -dcmm-lint -hisuf
Simon Marlow:
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-
name rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -
dcmm-lint -hisuf debug_hi -hcsuf debug_hc -os
Manuel M T Chakravarty wrote:
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0
-fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name
rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint
-hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-D
/Users/chak/Code/ghc-test/ghc/stage1-inplace/ghc -Werror -H64m -O0 -
fasm -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name
rts -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-
lint -hisuf debug_hi -hcsuf debug_hc -osuf debug_o -optc-DDEBUG -c
PrimOps.cmm -o
Roman Leshchinskiy wrote:
This is caused by this patch:
Sun Jul 8 12:44:23 PDT 2007 Simon Marlow <[EMAIL PROTECTED]>
* Fix the +RTS -V0 option introduced recently; it didn't work at
all, now it does.
Also, I documented it. +RTS -V0 disables the internal RTS timer
completely, which
Manuel, Simon,
Manuel M T Chakravarty wrote:
I just tried the new validate script on MacOS/Intel and it fails when
linking the stage2 compiler with the appended error messages. Any idea
what could be the problem?
This is caused by this patch:
Sun Jul 8 12:44:23 PDT 2007 Simon Marlow <[E
I just tried the new validate script on MacOS/Intel and it
fails when linking the stage2 compiler with the appended
error messages. Any idea what could be the problem?
Manuel
-=-
../compiler/stage1/ghc-inplace -H64m -Onot -fasm -package
ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-t
20 matches
Mail list logo
