Re: [GHC] #5899: RTS crash w/ strange closure type 603975781 on OS X 10.8

2012-03-22 Thread GHC
#5899: RTS crash w/ strange closure type 603975781 on OS X 10.8
---+
Reporter:  dylukes |   Owner:   

Type:  bug |  Status:  new  

Priority:  high|   Milestone:  
7.4.2
   Component:  Runtime System  | Version:  
7.4.1
Keywords:  rts, strange closure, internal error, os x  |  Os:  
MacOS X  
Architecture:  x86_64 (amd64)  | Failure:  
Runtime crash
  Difficulty:  Unknown |Testcase:   

   Blockedby:  |Blocking:   

 Related:  |  
---+
Changes (by Irene):

 * cc: ireney.knapp@… (added)


Comment:

 I tried the sample program above:

 {{{
 main = print $ reverse [1,2,3]
 }}}

 GHC 7.4.1 (from the .pkg version of the prebuilt binaries, but it's
 probably identical to the tarball version?) compiled successfully but the
 output crashed; here is the OS X crash report:

 {{{
 Process: Main [37094]
 Path:/Users/USER/*/Main
 Identifier:  Main
 Version: 0
 Code Type:   X86-64 (Native)
 Parent Process:  bash [29186]
 User ID: 501

 Date/Time:   2012-03-22 20:24:06.768 -0400
 OS Version:  Mac OS X 10.8 (12A154q)
 Report Version:  10

 Interval Since Last Report:  166904 sec
 Crashes Since Last Report:   12
 Per-App Crashes Since Last Report:   1
 Anonymous UUID:  15C338D1-9CE8-40B1-8287-60D878AF6A68

 Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x00022bbe8a30

 VM Regions Near 0x22bbe8a30:
 VM_ALLOCATE00010bd0-00010be0 [ 1024K]
 rw-/rwx SM=PRV
 -->
 MALLOC_TINY7fc3d840-7fc3d8411000 [   68K]
 rw-/rwx SM=COW

 Application Specific Information:
 objc[37094]: garbage collection is OFF

 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   Main0x00010bbf0617 stg_ap_pp_fast
 + 31

 Thread 0 crashed with X86 Thread State (64-bit):
   rax: 0x23fff065  rbx: 0x00010bc0ad58  rcx:
 0x00010bbf0708  rdx: 0x00010bd041d8
   rdi: 0x00010bc21e98  rsi: 0x00010bc087c0  rbp:
 0x00010bd05358  rsp: 0x7fff540c8ab8
r8: 0x0001   r9: 0x0017  r10:
 0x0001  r11: 0x0246
   r12: 0x00010bd041e0  r13: 0x00010bc21e98  r14:
 0x00010bc087e0  r15: 0x00010bd050c0
   rip: 0x00010bbf0617  rfl: 0x00010202  cr2:
 0x00022bbe8a30
 Logical CPU: 6

 Binary Images:
0x10bb33000 -0x10bc07fef +Main (0)
  /Users/USER/*/Main
 0x7fff6b733000 - 0x7fff6b7678e7  dyld (209.1) <7F330FEF-C9C5-38D8
 -9C3D-FBDCC0C28BDA> /usr/lib/dyld
 0x7fff868d6000 - 0x7fff869ed827  libobjc.A.dylib (526)
  /usr/lib/libobjc.A.dylib
 0x7fff869fa000 - 0x7fff86a46ff7  libauto.dylib (185)
  /usr/lib/libauto.dylib
 0x7fff86b6b000 - 0x7fff86b70fff  libcompiler_rt.dylib (30)
 
 /usr/lib/system/libcompiler_rt.dylib
 0x7fff8717a000 - 0x7fff871e2ff7  libc++.1.dylib (61) <5C289258
 -570C-3D3E-ACAB-88CB1C01804B> /usr/lib/libc++.1.dylib
 0x7fff87b24000 - 0x7fff87b27ff7  libdyld.dylib (209.1)
 <94E58E38-AC20-36DB-A84E-DAFA8D4E41E2> /usr/lib/system/libdyld.dylib
 0x7fff890e7000 - 0x7fff890e8fff  libremovefile.dylib (23)
  /usr/lib/system/libremovefile.dylib
 0x7fff89148000 - 0x7fff8914afff  libquarantine.dylib (48)
  /usr/lib/system/libquarantine.dylib
 0x7fff898b8000 - 0x7fff898b9fff  libsystem_blocks.dylib (57.2)
 <7014BC27-D424-3E9B-9535-3CAA6C956337>
 /usr/lib/system/libsystem_blocks.dylib
 0x7fff89934000 - 0x7fff8994fff7  libsystem_kernel.dylib
 (2050.2.33) 
 /usr/lib/system/libsystem_kernel.dylib
 0x7fff8995 - 0x7fff89951ff7  libsystem_sandbox.dylib (206)
 
 /usr/lib/system/libsystem_sandbox.dylib
 0x7fff8a3e6000 - 0x7fff8a3e7ff7  libSystem.B.dylib (169.1)
  /usr/lib/libSystem.B.dylib
 0x7fff8a52a000 - 0x7fff8a558ff7  libsystem_m.dylib (3022.4)
  /usr/lib/system/libsystem_m.dylib
 0x7fff8a559000 - 0x7fff8a5c0fff  libcommonCrypto.dylib (60007)
 
 /usr/lib/system/libcommonCrypto.dylib
 0x7fff8c958000 - 0x7fff8c95dfff  libcache.dylib (53)  /usr/lib/system/libcache.dylib
 0x7fff8e589000 - 0x7fff8e656fef  libsystem_c.dylib (825.12.1)
 <626CC4B4-4865-3179-B743-93CEDF4A8802> /usr/lib/system/libsystem_c.dylib
 0x7fff8ec1c000 - 0x7fff8ec23fff  libcopyfile.dylib (89)
 <8E286594-B745-32B5-89FE-0529963

Re: [GHC] #5790: Missing document about .eventlog's u flag

2012-03-22 Thread GHC
#5790: Missing document about .eventlog's u flag
-+--
Reporter:  shelarcy  |   Owner:  duncan   
Type:  bug   |  Status:  merge
Priority:  highest   |   Milestone:  7.4.2
   Component:  Documentation | Version:  7.4.1-rc1
Keywords:|  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple  | Failure:  Documentation bug
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--
Changes (by duncan):

  * status:  new => merge


-- 
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] #5790: Missing document about .eventlog's u flag

2012-03-22 Thread GHC
#5790: Missing document about .eventlog's u flag
-+--
Reporter:  shelarcy  |   Owner:  duncan   
Type:  bug   |  Status:  new  
Priority:  highest   |   Milestone:  7.4.2
   Component:  Documentation | Version:  7.4.1-rc1
Keywords:|  Os:  Unknown/Multiple 
Architecture:  Unknown/Multiple  | Failure:  Documentation bug
  Difficulty:  Unknown   |Testcase:   
   Blockedby:|Blocking:   
 Related:|  
-+--

Comment(by duncan@…):

 commit 050f714150282695746534174c4550c90c2d9f4e
 {{{
 Author: Duncan Coutts 
 Date:   Thu Mar 22 23:24:57 2012 +

 Update the user guide with details on new flag +RTS -lu

 It's for user events emitted from Haskell code, like traceEvent.
 Fixes #5790

  docs/users_guide/runtime_control.xml |   43
 +++--
  1 files changed, 25 insertions(+), 18 deletions(-)
 }}}

-- 
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] #5959: GHC Panic: nameModule

2012-03-22 Thread GHC
#5959: GHC Panic: nameModule
+---
 Reporter:  mightybyte  |  Owner:
 Type:  bug | Status:  new   
 Priority:  normal  |  Component:  Compiler  
  Version:  7.4.1   |   Keywords:
   Os:  Linux   |   Architecture:  x86_64 (amd64)
  Failure:  Compile-time crash  |   Testcase:
Blockedby:  |   Blocking:
  Related:  |  
+---
 ghc: panic! (the 'impossible' happened)
   (GHC version 7.4.1 for x86_64-unknown-linux):
 nameModule b_a2PR{tv}

 While working on this project https://github.com/mightybyte/snaplet-
 postgresql-simple I encountered a GHC panic.  To reproduce, check out
 revision 6573d4359c5cb7699c931c44ebf1bf135099f83b (currently HEAD of the
 master branch), cabal install it, then go to the example directory and
 build with "ghc --make Site.hs".

 This has caused the crash for me on two different Linux systems with GHC
 7.4.1.  I realize it requires building a large number of package
 dependencies, but I have no idea of how to construct a smaller test case.
 It should be pretty easy to build these dependencies with cabal or cabal-
 dev.

-- 
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] #5059: Pragma to SPECIALISE on value arguments

2012-03-22 Thread GHC
#5059: Pragma to SPECIALISE on value arguments
-+--
Reporter:  batterseapower|   Owner:  
Type:  feature request   |  Status:  new 
Priority:  low   |   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.0.3   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

 * cc: johan.tibell@… (added)
  * difficulty:  => Unknown


Comment:

 Johan Tibell writes: While looking at the
 [http://gcc.gnu.org/gcc-4.7/changes.html GCC 4.7 release notes] I saw
 something that's perhaps worth stealing. Taken from the release notes:
 {{{
 The inter-procedural constant propagation pass has been rewritten. It
 now performs generic function specialization. For example when
 compiling the following:

 void foo(bool flag)
 {
   if (flag)
 ... do something ...
   else
 ... do something else ...
 }
 void bar (void)
 {
   foo (false);
   foo (true);
   foo (false);
   foo (true);
   foo (false);
   foo (true);
 }


 GCC will now produce two copies of foo. One with flag being true,
 while other with flag being false. This leads to performance
 improvements previously possibly only by inlining all calls. Cloning
 causes a lot less code size growth.
 }}}
 I found myself wanting something like this just today. A common pattern I
 see in code is this:
 {{{
 data Options = Options { ... }

 defaultOptions :: Options
 defaultOptions = ...

 foo :: ...
 foo = fooWith defaultOptions

 fooWith :: Options -> ...
 fooWith = ...
 }}}
 It'd be nice if we could get foo to specialize on its input arguments,
 without having to mark all of fooWith as INLINE.

 -- Johan

-- 
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] #5800: hp2ps produces unescaped backslashes for nested functions

2012-03-22 Thread GHC
#5800: hp2ps produces unescaped backslashes for nested functions
-+--
Reporter:  jkff  |   Owner: 
Type:  bug   |  Status:  merge  
Priority:  normal|   Milestone:  7.4.2  
   Component:  Profiling | Version:  7.4.1-rc1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by pcapriotti):

  * status:  new => merge


-- 
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] #5800: hp2ps produces unescaped backslashes for nested functions

2012-03-22 Thread GHC
#5800: hp2ps produces unescaped backslashes for nested functions
-+--
Reporter:  jkff  |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  7.4.2  
   Component:  Profiling | Version:  7.4.1-rc1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by p.capriotti@…):

 commit ee8bf699516dd8e603e26a7c862538e83da2c250
 {{{
 Author: Paolo Capriotti 
 Date:   Thu Mar 22 20:16:27 2012 +

 hp2ps: escape backslashes when generating output file (#5800).

  utils/hp2ps/Key.c |   22 --
  1 files changed, 20 insertions(+), 2 deletions(-)
 }}}

-- 
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] #5958: Follow mtl upstream

2012-03-22 Thread GHC
#5958: Follow mtl upstream
-+--
Reporter:  igloo |   Owner:  
Type:  task  |  Status:  new 
Priority:  high  |   Milestone:  7.6.1   
   Component:  Build System  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
 As per http://projects.haskell.org/pipermail/haskell-
 platform/2012-March/001760.html we should be tracking
 https://github.com/ekmett/mtl.git (which may mean asking upstream to merge
 our patches, if we have any) and will also need to track
 http://code.haskell.org/~ross/transformers

-- 
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] #5900: Git HEAD on PowerPC : Error: operand out of range

2012-03-22 Thread GHC
#5900: Git HEAD on PowerPC : Error: operand out of range
-+--
Reporter:  erikd |   Owner:  pcapriotti 
Type:  bug   |  Status:  patch  
Priority:  high  |   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.5
Keywords:|  Os:  Linux  
Architecture:  powerpc   | Failure:  Building GHC failed
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--
Changes (by igloo):

  * owner:  => pcapriotti
  * priority:  normal => high
  * milestone:  => 7.4.2


Comment:

 This apparently also affects 7.4. Paolo, would you be able to take a look
 please?

-- 
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] #5921: Two GHC linkers running in parallel on Windows goes wrong

2012-03-22 Thread GHC
#5921: Two GHC linkers running in parallel on Windows goes wrong
-+--
  Reporter:  NeilMitchell|  Owner:  
  Type:  bug | Status:  closed  
  Priority:  normal  |  Milestone:  7.4.2   
 Component:  Compiler|Version:  7.4.1   
Resolution:  fixed   |   Keywords:  
Os:  Windows |   Architecture:  Unknown/Multiple
   Failure:  Compile-time crash  | Difficulty:  Unknown 
  Testcase:  |  Blockedby:  
  Blocking:  |Related:  
-+--
Changes (by pcapriotti):

  * status:  merge => closed
  * resolution:  => fixed


Comment:

 Merged as 00ae9a91b82de53a22bd55fe026f42842a3713a0.

-- 
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] #5951: Panic on Malformed instance A => B => C

2012-03-22 Thread GHC
#5951: Panic on Malformed instance A => B => C
-+--
Reporter:  br1   |   Owner:
Type:  bug   |  Status:  new   
Priority:  normal|   Milestone:  7.6.1 
   Component:  Compiler  | Version:  7.4.1 
Keywords:|  Os:  Unknown/Multiple  
Architecture:  Unknown/Multiple  | Failure:  Compile-time crash
  Difficulty:  Unknown   |Testcase:
   Blockedby:|Blocking:
 Related:|  
-+--
Changes (by pcapriotti):

  * difficulty:  => Unknown
  * milestone:  => 7.6.1


-- 
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] #5954: Performance regression 7.0 -> 7.2 (still in 7.4)

2012-03-22 Thread GHC
#5954: Performance regression 7.0 -> 7.2 (still in 7.4)
-+--
Reporter:  simonmar  |   Owner: 
Type:  bug   |  Status:  new
Priority:  high  |   Milestone:  7.4.2  
   Component:  Compiler  | Version:  7.4.1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Runtime performance bug
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by simonmar):

 It looks like the simplifer has duplicated some primops.  The program is
 making more calls to `exp()` at runtime than it was with 7.0.  I've spent
 some time peering at the Core but it's quite complicated, and I haven't
 been able to narrow down the exact bit of problematic code yet.  I suggest
 we look at it together when you have a chance.

 (strong possibility that this is the same as #5623)

-- 
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] #5957: signatures are too permissive

2012-03-22 Thread GHC
#5957: signatures are too permissive
--+-
 Reporter:  maeder|  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Component:  Compiler (Type checker)
  Version:  7.4.1 |   Keywords: 
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple   
  Failure:  None/Unknown  |   Testcase: 
Blockedby:|   Blocking: 
  Related:|  
--+-
 ghc should reject the following (accidentally mistyped) signature, unless
 `-XFlexibleContexts` is used.

 {{{
 flex :: Int -> Show a => a -> String
 flex i a = show a ++ show i
 }}}

 hugs and ghc version below 7 rejected this correctly:

 {{{
 All of the type variables in the constraint `Show a'
 are already in scope (at least one must be universally quantified
 here)
 (Use -XFlexibleContexts to lift this restriction)
 In the type signature for `flex':
   flex :: Int -> (Show a) => a -> String
 }}}

 It is not Haskell98 nor Haskell2010 (I believe).

-- 
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] #5956: Annotate heap profile at certain times

2012-03-22 Thread GHC
#5956: Annotate heap profile at certain times
--+-
 Reporter:  nomeata   |  Owner:  
 Type:  feature request   | Status:  new 
 Priority:  normal|  Component:  Profiling   
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
 Just an idea I’d like to note down: When looking at a heap profile, I
 often have to guess what phase is what. It would be useful if there is a
 {{{
 GHC.Exts.annotateHeapProfile :: String -> IO ()
 }}}
 function where a vertical line shows up in the heap profile every time the
 function is called, and is labeled by the given string.

-- 
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