Re: [GHC] #4993: getDirectoryContents goes into an infinite loop

2011-03-02 Thread GHC 
#4993: getDirectoryContents goes into an infinite loop
---+
 Reporter:  bos|  Owner: 
 Type:  bug| Status:  closed 
 Priority:  normal |  Component:  libraries/directory
  Version:  7.0.1  | Resolution:  invalid
 Keywords: |   Testcase: 
Blockedby: | Os:  Linux  
 Blocking: |   Architecture:  x86
  Failure:  Runtime crash  |  
---+

Comment(by bos):

 I filed a bug against boxgrinder:
 https://issues.jboss.org/browse/BGBUILD-172

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #4994: Deprecate Control.Exception.blocked in favour of getMaskingState

2011-03-02 Thread GHC 
#4994: Deprecate Control.Exception.blocked in favour of getMaskingState
-+--
Reporter:  basvandijk|   Owner:
Type:  task  |  Status:  new   
Priority:  normal|   Component:  libraries/base
 Version:  7.0.1 |Keywords:
Testcase:|   Blockedby:
  Os:  Unknown/Multiple  |Blocking:
Architecture:  Unknown/Multiple  | Failure:  None/Unknown  
-+--
 I [http://www.haskell.org/pipermail/libraries/2011-February/015859.html
 proposed] deprecating `Control.Exception.blocked` in
 favour of `getMaskingState`.

 The term "blocked" refers to the old way of dealing with asynchronous
 exceptions (`block`/`unblock`). It can also be a bit confusing to which
 "blocked" property it refers: blocked asynchronous exceptions, or a
 blocked thread.

 Note that `blocked` is already listed in the section
 [http://hackage.haskell.org/packages/archive/base/4.3.0.0/doc/html
 /Control-Exception.html#12 "(deprecated) Asynchronous exception control"]

 There were no objections and one +1 from Simon Marlow.

 The patch is attached.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4993: getDirectoryContents goes into an infinite loop

2011-03-02 Thread GHC 
#4993: getDirectoryContents goes into an infinite loop
---+
 Reporter:  bos|  Owner: 
 Type:  bug| Status:  closed 
 Priority:  normal |  Component:  libraries/directory
  Version:  7.0.1  | Resolution:  invalid
 Keywords: |   Testcase: 
Blockedby: | Os:  Linux  
 Blocking: |   Architecture:  x86
  Failure:  Runtime crash  |  
---+
Changes (by bos):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 I've got it figured out. It's not a GHC bug, and it's quite subtle.

 So. On a 32-bit system, glibc relies on being able to do tricks like
 %gs:-1234 to get negative offsets from the TLS (thread-local storage)
 base. But in fact that's really gsbase + (big positive number), and glibc
 relies on wraparound to get the resulting negative value. But the CPU only
 does that iff the segment limit is a full 4G.

 Under Xen, segments are clipped to protect the hypervisor, so we need a
 version of glibc which spends a couple more instructions to compute the
 negative offset without relying on segment wrapping.

 This is done via an {{{ld.so.conf}}} entry:

 {{{
 hwcap 1 nosegneg
 }}}

 The above directs {{{ldconfig}}} and {{{ld.so}}} to use the Xen-friendly
 version of glibc.

 So this isn't really a GHC bug at all, but perhaps a boxgrinder bug. In
 any case, the symptom is appearing in GHC :-(

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #4993: getDirectoryContents goes into an infinite loop

2011-03-02 Thread GHC 
#4993: getDirectoryContents goes into an infinite loop
---+
Reporter:  bos |   Owner: 
Type:  bug |  Status:  new
Priority:  normal  |   Component:  libraries/directory
 Version:  7.0.1   |Keywords: 
Testcase:  |   Blockedby: 
  Os:  Linux   |Blocking: 
Architecture:  x86 | Failure:  Runtime crash  
---+
 This is a really peculiar bug. Prepare for some fun!

 I'm using a tool called boxgrinder to create a virtual machine image for
 running in Amazon's EC2 compute environment. The virtual machine is
 intended to contain GHC and a few libraries. I'm running boxgrinder itself
 in an EC2 virtual machine.

 boxgrinder works fine on a 64-bit virtual machine, when creating a 64-bit
 virtual machine, but gets stuck forever when I try to run it in a 32-bit
 VM to create a 32-bit image.

 The reason for boxgrinder hanging is that when installing {{{GHC}}},
 {{{ghc-pkg}}} is going into an infinite loop. I've got a super simple
 reproduction:

 {{{
 import System.Directory

 main = getDirectoryContents "." >>= print
 }}}

 If compiled, the above command runs fine in the regular 32-bit system
 image, but not in the {{{chroot}}} filesystem created by boxgrinder. In
 there, it goes into an infinite loop right after reading some of the
 directory contents:

 {{{
 ... everything looks normal ...
 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
 getdents64(3, /* 25 entries */, 32768)  = 640
 getdents64(3, /* 0 entries */, 32768)   = 0
 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 --- SIGVTALRM (Virtual timer expired) @ 0 (0) ---
 sigreturn() = ? (mask now [])
 ... and no more life! ...
 }}}

 I have verified that this infinite loop occurs both with 6.12.3 and 7.0.2
 RC2. Investigating further at the moment.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop

2011-03-02 Thread GHC 
#4978: Continuation passing style loop doesn't compile into a loop
-+--
Reporter:  tibbe |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  7.2.1   
   Component:  Compiler  |  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 Here's my example boiled down as much as I can.

 {{{
 module Fac (fac) where

 newtype Par a = Par {
 runCont :: (a -> Trace) -> Trace
 }

 instance Monad Par where
 return a = Par $ \c -> c a
 m >>= k  = Par $ \c -> runCont m (\a -> runCont (k a) c)

 data Sched = Sched

 type Trace = Sched -> IO ()

 fac :: Int -> Par Int
 fac n = if n <= 1 then return 1
   else do x <- fac (n-1)
   return (x * n)
 }}}

 which yields this for `fac` with today's HEAD:

 {{{
 a2_rnD :: (GHC.Types.Int -> ParFib.Trace) -> ParFib.Trace
 [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType C(S)]
 a2_rnD = \ (c_agZ :: GHC.Types.Int -> ParFib.Trace) -> c_agZ a1_rnC

 Rec {
 ParFib.$wfac [Occ=LoopBreaker]
   :: GHC.Prim.Int# -> (GHC.Types.Int -> ParFib.Trace) -> ParFib.Trace
 [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType L]
 ParFib.$wfac =
   \ (ww_snb :: GHC.Prim.Int#) ->
 case GHC.Prim.<=# ww_snb 1 of _ {
   GHC.Types.False ->
 let {
   a3_sno :: (GHC.Types.Int -> ParFib.Trace) -> ParFib.Trace
   [LclId, Str=DmdType]
   a3_sno = ParFib.$wfac (GHC.Prim.-# ww_snb 1) } in
 \ (c_ah2 :: GHC.Types.Int -> ParFib.Trace) ->
   a3_sno
 (\ (a4_ah3 :: GHC.Types.Int) ->
c_ah2
  (case a4_ah3 of _ { GHC.Types.I# x_ams ->
   GHC.Types.I# (GHC.Prim.*# x_ams ww_snb)
   }));
   GHC.Types.True -> a2_rnD
 }
 end Rec }
 }}}

 It looks like the arity analyser should infer an arity of at least 2
 (ultimately we want 3) for `fac`, but it has inferred only 1.  The `case`
 should look cheap, and the `let` is for the recursive call.

 I have tried eta-expanding `return` and `>>=`, to no avail. (that might
 still be necessary to get to arity 3, I'm not sure).

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #68: Warnings for unitialized fields

2011-03-02 Thread GHC 
#68: Warnings for unitialized fields
--+-
  Reporter:  nobody   |  Owner:  
  Type:  feature request  | Status:  infoneeded  
  Priority:  normal   |  Milestone:  _|_ 
 Component:  Compiler |Version:  None
Resolution:  None |   Keywords:  warnings
  Testcase:   |  Blockedby:  
Difficulty:  Easy (less than 1 hour)  | Os:  Unknown/Multiple
  Blocking:   |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown |  
--+-
Changes (by ste):

 * cc: stefan@… (added)
  * status:  new => infoneeded


Comment:

 To get started with ghc hacking I created this patch. If this patch (or
 something similar) should be added to ghc, just tell me and I will add the
 necessary documentation and test cases. (This patch breaks test case
 ds041.hs due to a changed warning text.)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4385: Type-level natural numbers

2011-03-02 Thread GHC 
#4385: Type-level natural numbers
+---
Reporter:  diatchki |Owner:  diatchki
Type:  feature request  |   Status:  new 
Priority:  normal   |Milestone:  7.2.1   
   Component:  Compiler (Type checker)  |  Version:  
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Unknown/Multiple | Blocking:  
Architecture:  Unknown/Multiple |  Failure:  None/Unknown
+---

Comment(by jeltsch):

 Replying to [comment:3 simonpj]:
 > I really, really want to make operators into type '''constructors'''
 rather than (as at present) type '''variables'''.  So that we can write a
 type `(a + b)` rather than `(a :+ b)`.  See
 http://hackage.haskell.org/trac/haskell-prime/wiki/InfixTypeConstructors.
 Doing this is, I think, straightforward, but it still needs doing.

 Really nice. What GHC version can be expected to have this feature? I’d
 like to use it.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4989: build error on mingw if pthreads is installed

2011-03-02 Thread GHC 
#4989: build error on mingw if pthreads is installed
-+--
Reporter:  int-e |Owner:  simonmar   
Type:  bug   |   Status:  new
Priority:  high  |Milestone:  7.2.1  
   Component:  Build System  |  Version:  7.1
Keywords:| Testcase: 
   Blockedby:|   Difficulty: 
  Os:  Windows   | Blocking: 
Architecture:  Unknown/Multiple  |  Failure:  Building GHC failed
-+--
Changes (by simonmar):

  * owner:  => simonmar
  * priority:  normal => high
  * milestone:  => 7.2.1


Comment:

 we should get rid of WANT_NATIVE_WIN32_THREADS and ignore `pthreads.h` on
 Windows.  I'll fix.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4970: time002 and time004 (ghci) test failures on OS X 64 bit

2011-03-02 Thread GHC 
#4970: time002 and time004 (ghci) test failures on OS X 64 bit
---+
Reporter:  gwright |   Owner:  gwright
Type:  bug |  Status:  new
Priority:  normal  |   Component:  GHCi   
 Version:  7.0.1   |Keywords: 
Testcase:  |   Blockedby: 
  Os:  MacOS X |Blocking: 
Architecture:  x86_64 (amd64)  | Failure:  Incorrect result at runtime
---+

Comment(by gwright):

 Some notes to self:

 The error occurs before the microseconds values from `gettimeofday` is
 multiplied by
 100 to convert to picoseconds.  Here's the source in `Time.hs` (the
 preprocessed `Time.hsc`):
 {{{
 getClockTime :: IO ClockTime

 {-# LINE 249 "libraries/old-time/./System/Time.hsc" #-}
 getClockTime = do
   allocaBytes (16) $ \ p_timeval -> do
 {-# LINE 251 "libraries/old-time/./System/Time.hsc" #-}
 throwErrnoIfMinus1_ "getClockTime" $ gettimeofday p_timeval nullPtr
 sec  <- ((\hsc_ptr -> peekByteOff hsc_ptr 0))  p_timeval :: IO CTime
 {-# LINE 253 "libraries/old-time/./System/Time.hsc" #-}
 usec <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) p_timeval :: IO CTime
 {-# LINE 254 "libraries/old-time/./System/Time.hsc" #-}
 return (TOD (realToInteger sec) ((realToInteger usec) * 100))
 }}}
 Either `usec` is not getting the right value or something is wrong with
 `realToInteger`.  I'm guessing it's the former.

 I've located where the multiplication by 100 is in the assembly code:
 {{{
 .text
 .align 3
 _s7ja_info_dsp:
 .quad   0
 .quad   32
 _s7ja_info:
 LcfET:
 movq %rbx,%r14
 leaq _r4N2_closure(%rip),%rax
 leaq 1(%rax),%rsi
 addq $8,%rbp
 jmp _integerzmgmp_GHCziInteger_timesInteger_info
 .long  _s7ja_info - _s7ja_info_dsp
 }}}
 and where `gettimeofday` is called:
 {{{
 .text
 .align 3
 _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info_dsp:
 .quad
 
_oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_srt-(_oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info)+0
 .quad   8589934596
 .quad   0
 .quad   133143986191
 .globl _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info
 _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info:
 LcfGM:
 leaq -16(%rbp),%rax
 cmpq %r15,%rax
 jb LcfGO
 movq %r14,%rax
 movq %rax,%rdi
 xorl %esi,%esi
 movl $0,%eax
 call ___hscore_gettimeofday
 movq %r14,-8(%rbp)
 movslq %eax,%rax
 cmpq $-1,%rax
 jne LcfGQ
 leaq _r4S3_closure(%rip),%r14
 leaq _s7jh_info(%rip),%rax
 movq %rax,-16(%rbp)
 addq $-16,%rbp
 jmp _base_ForeignziCziError_throwErrno1_info
 LcfGO:
 leaq _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_closure(%rip),%rbx
 jmp *-8(%r13)
 LcfGQ:
 addq $-16,%rbp
 jmp _s69Q_info
 .long  _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info -
 _oldzmtimezm1zi0zi0zi6_SystemziTime_zdwa3_info_dsp
 }}}
 Now I need to do a bisection search to locate the bad relocation.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4992: LLVM trashes registers for primitive calls

2011-03-02 Thread GHC 
#4992: LLVM trashes registers for primitive calls
+---
Reporter:  scpmw|Owner:  davidterei@…
Type:  bug  |   Status:  patch   
Priority:  normal   |Milestone:  
   Component:  Compiler (LLVM)  |  Version:  7.1 
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Linux| Blocking:  
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash   
+---

Comment(by scpmw):

 I have attached my best shot at reproducing the problem with just "tan".
 It generates roughly the following code before the patch:

 {{{
 subq$72, %rsp
 movq%r15, 40(%rsp)  # 8-byte Spill
 movq%r14, 32(%rsp)  # 8-byte Spill
 movq%r12, 24(%rsp)  # 8-byte Spill
 movq%rbp, 8(%rsp)   # 8-byte Spill
 movq%r13, 16(%rsp)  # 8-byte Spill
 movaps  %xmm5, %xmm0
 callq   tan
 cvttsd2siq  %xmm0, %rax
 movq%rax, 56(%rsp)  # 8-byte Spill
 }}}

 And then goes on using all available registers, which is clearly
 dangerous. With the patch applied, a lot more registers are saved on top
 of the stack.

 I'm unsure though how to craft an actually failing program out of this.
 Maybe somebody with a better overview can put in the missing piece?

 (Fun fact: The program actually manages to crash the LLVM optimizer both
 with and without the patch. Compiling without -O works.)

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by maeder):

 I've found the error, it was a setting in my build.mk!

 {{{
 INSTALL_PROGRAM = $(INSTALL) -s -m 755
 }}}

 that overwrote

 {{{
 INSTALL_PROGRAM = $(INSTALL) -m 755 $1 $2 $(call MK_INSTALL_DEST,$3)
 }}}

 in install.mk

 Please make a release.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

testing 7.02-candidate

2011-03-02 Thread Serge D. Mechveliani 
Dear GHC team,

I am testing the  7.02 candidate  of  ghc-7.0.1.20110217
-- compiled from source, compiled by itself, on Debian Linux,
i386-family.

On my DoCon program, it reports the following.

1. It requires  `-fcontext-stack=_'  to increase a certain stack:

...
[67 of 83] Compiling Pfact__( Pfact__.hs, dist/build/Pfact__.o )
[68 of 83] Compiling RsePol_( RsePol_.hs, dist/build/RsePol_.o )

RsePol_.hs:214:28:
Context reduction stack overflow; size = 21
Use -fcontext-stack=N to increase stack size to N
  $dSet :: Set (UPol (ResidueE Integer))
  $dAddSemigroup :: AddSemigroup (UPol (ResidueE Integer))
  $dAddMonoid :: AddMonoid (UPol (ResidueE Integer))
...
  $dCast :: Prelude_.Cast
  (ResidueE (UPol (Pfact__.RseUPolRse Integer)))
  (UPol (Pfact__.RseUPolRse Integer))
In the first argument of `(.)', namely `ct c1'
In the expression: ct c1 . toOverK . resRepr
In an equation for `toC': toC = ct c1 . toOverK . resRepr
---

So, I add  -fcontext-stack=30  to the  ghc-options  line in 
docon.cabal.

Which one is better at this point,  7.0.1  or  7.0.1.20110217 ?


2. Then, DoCon is built, and the commands
   cd demotest
   ghc $doconCpOpt -O -rtsopts --make Main

need to `make' the DoCon test under the DoCon library. This reports

[ 1 of 17] Compiling T_detinterp  ( T_detinterp.hs, T_detinterp.o )
[ 2 of 17] Compiling T_sphGeo ( T_sphGeo.hs, T_sphGeo.o )
[ 3 of 17] Compiling T_cubeext( T_cubeext.hs, T_cubeext.o )

T_cubeext.hs:143:9:
Overlapping instances for LinSolvRing (UPol k)
  arising from a use of `ct'
Matching instances:
  instance [overlap ok] EuclideanRing a => LinSolvRing (UPol a)
-- Defined in docon-2.12:Pol2_
  instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) =>
LinSolvRing (UPol (Pol a))
-- Defined in docon-2.12:Pol3_
(The choice depends on the instantiation of `k'
 To pick the first instance above, use -XIncoherentInstances
 when compiling the other instance declarations)
In the first argument of `(.)', namely `ct unE'
In the expression: ct unE . kToB
In an equation for `kToE': kToE = ct unE . kToB



This looks like a bug of the kind appeared in a couple of earlier GHC 
versions.
ghc-7.0.1  is free of both of these effects.

What is your opinion about this?

http://www.botik.ru/pub/local/Mechveliani/ghcBugs/702candBug.zip

is the archive with the project to make and run under  ghc-7.0.1,
and  ghc-7.0.1.20110217  (follow  install.txt).

Regards,

-
Serge Mechveliani
mech...@botik.ru


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by maeder):

 Right, setting SHELL to /bin/bash did also not help, but why are the
 parameters ignored (just for me)?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by igloo):

 `$(call ..)` doesn't use the shell. It calls a user-defined makefile
 function.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by maeder):

 Replying to [comment:13 maeder]:

 I've no explanation for the failure. I've reinstalled GNU Make 3.82 and
 GNU Make 3.81 with the same failure. Within the "for" loop, all parameters
 following "$(call INSTALL_PROGRAM" are simply ignored. The shell used by
 make is indeed /bin/sh, which is different from /bin/bash.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for x86_64_apple_darwin)

2011-03-02 Thread GHC 
#4987: darcs: internal error: stg_ap_v_ret (GHC version 7.0.1 for
x86_64_apple_darwin)
---+
Reporter:  guest   |Owner:   
Type:  bug |   Status:  new  
Priority:  normal  |Milestone:   
   Component:  Compiler|  Version:  7.0.1
Keywords:  | Testcase:   
   Blockedby:  |   Difficulty:   
  Os:  MacOS X | Blocking:   
Architecture:  x86_64 (amd64)  |  Failure:  Runtime crash
---+

Comment(by simonmar):

 Thanks for the report.  Without a reproducible test case there isn't
 anything we can do with it right now, but I'll leave the ticket open for a
 while in case more evidence emerges.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4163: Make cross-compilation work

2011-03-02 Thread GHC 
#4163: Make cross-compilation work
-+--
Reporter:  simonmar  |Owner:  simonmar
Type:  task  |   Status:  patch   
Priority:  high  |Milestone:  7.2.1   
   Component:  Build System  |  Version:  6.12.3  
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  Difficult (2-5 days)
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 A few quick comments:

 Igloo's patch isn't right - it changes `*_HOST_ARCH` to `*_TARGET_ARCH` in
 the RTS, and we eventually agreed that is the wrong thing (IIRC).

 We have some conflict resolutions in there (merger patches), would be good
 to get rid of those.  Basically I think Igloo's patches need to be rebased
 on HEAD.

 You have some whitespace changes in there, which makes it hard to review
 the patch, could you separate them out please?

 In general, I have concerns that passing DynFlags everywhere will be too
 painful, and I wonder whether we should put the target architecture in a
 static flag instead (i.e. something in `main/StaticFlags.hs`).  The
 downsides are minimal - you wouldn't be able to fire up two GHC sessions
 using the GHC API and generate code for two different platforms, but I
 don't expect anyone would want to do that.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4978: Continuation passing style loop doesn't compile into a loop

2011-03-02 Thread GHC 
#4978: Continuation passing style loop doesn't compile into a loop
-+--
Reporter:  tibbe |Owner:  
Type:  bug   |   Status:  new 
Priority:  normal|Milestone:  7.2.1   
   Component:  Compiler  |  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by simonmar):

  * milestone:  => 7.2.1


Comment:

 Just a note to say that I have exactly the same problem in my parallelism
 monad ([https://github.com/simonmar/monad-par]).  I believe I've tried a
 recent HEAD and couldn't get a loop to optimise correctly, just like
 tibbe's first example.  I'll follow up with some concrete details and code
 shortly.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by kgardas):

 Replying to [comment:23 kgardas]:
 > Replying to [comment:13 maeder]:
 > > I could create a binary dist, but "make install" failed as follows:
 >
 > I've installed "entire group" Solaris 10 update 8 into VirtualBox for
 verification and while I'm able to verify that shared libs are not working
 well, I'm certainly able to compile whole GHC 7.0.2 snapshot including its
 installation. However, I have to point out that this is really stock
 Solaris 10 as provided by Oracle/Sun and I have not installed any
 Blastwave package. The only one package I've installed was GNU Make 3.82
 and of course ghc 6.10.4 to bootstrap 7.0.1 which was used to bootstrap
 7.0.2 snapshot.

 Also my PATH looks like:
 {{{
 /usr/xpg4/bin:/usr/ccs/bin:/usr/local/bin:/opt/ghc-7.0.1/bin:/usr/bin:.
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4973: building ghc7.0.1.20110217 under x86 solaris fails

2011-03-02 Thread GHC 
#4973: building ghc7.0.1.20110217 under x86 solaris fails
--+-
  Reporter:  maeder   |  Owner: 
  Type:  bug  | Status:  new
  Priority:  highest  |  Milestone:  7.0.2  
 Component:  Compiler |Version:  7.0.1  
Resolution:   |   Keywords: 
  Testcase:   |  Blockedby: 
Difficulty:   | Os:  Solaris
  Blocking:   |   Architecture:  x86
   Failure:  Building GHC failed  |  
--+-

Comment(by kgardas):

 Replying to [comment:13 maeder]:
 > I could create a binary dist, but "make install" failed as follows:

 I've installed "entire group" Solaris 10 update 8 into VirtualBox for
 verification and while I'm able to verify that shared libs are not working
 well, I'm certainly able to compile whole GHC 7.0.2 snapshot including its
 installation. However, I have to point out that this is really stock
 Solaris 10 as provided by Oracle/Sun and I have not installed any
 Blastwave package. The only one package I've installed was GNU Make 3.82
 and of course ghc 6.10.4 to bootstrap 7.0.1 which was used to bootstrap
 7.0.2 snapshot.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4992: LLVM trashes registers for primitive calls

2011-03-02 Thread GHC 
#4992: LLVM trashes registers for primitive calls
+---
Reporter:  scpmw|Owner:  davidterei@…
Type:  bug  |   Status:  patch   
Priority:  normal   |Milestone:  
   Component:  Compiler (LLVM)  |  Version:  7.1 
Keywords:   | Testcase:  
   Blockedby:   |   Difficulty:  
  Os:  Linux| Blocking:  
Architecture:  x86_64 (amd64)   |  Failure:  Runtime crash   
+---

Comment(by scpmw):

 Producing a test case for isn't straightforward... It would have to
 construct a situation where LLVM is pressured for (non-floating-point)
 registers while at the same time making heavy use of LLVM primitives. At
 the moment, these all concern floating-point operations, which makes this
 hard. Using "round", for example, makes the code pieces end up in
 different thunks. I suppose that's the reason why this problem hasn't
 shown up so far.

 It might be possible to come up with something by addressing the primops
 directly and using unsafeCoerce in order to force GHC to pull some ints
 out of nowhere... But I'm not really sure the testcase would even be
 useful at that point.

 The problem surfaced for me when I tried to add a primop for querying the
 cycle counter (llvm.readcyclecounter), which always uses two integer
 registers and therefore quickly ends up overwriting important stuff.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4977: Warning about unqualified implicit imports

2011-03-02 Thread GHC 
#4977: Warning about unqualified implicit imports
-+--
Reporter:  Lemming   |Owner:  
Type:  feature request   |   Status:  new 
Priority:  normal|Milestone:  
   Component:  Compiler  |  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--

Comment(by simonmar):

 I believe it does exactly what you want - that is, it warns about

 {{{
 import M
 import M hiding (x,y)
 }}}

 but not

 {{{
 import M (x,y)
 }}}

 The documentation is missing though, so we should fix that before closing
 this ticket.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs